5 August 2024 by Phillip Johnston • Last updated 8 August 2025 ““ Quote Names are deeply meaningful to your brain, and misleading names add chaos to your code. – The Pragmatic Programmer by David Thomas and Andrew Hunt A good name is better than a good comment because it will be seen everywhere the function is used. —The Art of Readable Code by Dustin Boswell and Trevor Foucher Naming Variable Naming Distinguishability A variable with enough scope that you’d want to run a “find” or “search” operation to find all references should be named with enough context and distinguishability …
Continue reading “Naming and Organization Standards”
5 August 2024 by Phillip JohnstonDo not use “new” as part of a name. When providing an improved interface, function, etc., provide a more accurate name that describes what the new thing is and how it is differentiated from the old thing it’s related to. If you cannot find a suitable name, use a version. While inelegant, this still allows you an explicit, non-confusing reference. When referencing function that provides a “new” object, instance, etc., prefer alternatives such as “CreateX” or “AllocateX.” When referring to variables (e.g., value/new_value), use an alternative name that shows how the value differentiates from the …
Continue reading “Don’t Use ‘new’ in Names”
5 August 2024 by Phillip JohnstonMake things easier for yourself and other developers who work on the project: use consistent names and terminology across all project artifacts. Example Violations PB 560 Power-on Self Tests The PB 560 requirements, service manual, and user manual all refer to “POST”, for power-on self test, which is the standard term. However, all of the references in the code refer to “PUST”, for power-up self test. If you’re looking for the “official” term in the documentation, you will come up largely empty in your source code search. It’s only if you start manually walking through …
Continue reading “Use Names Consistently”
