Coding best practices: Difference between revisions

Revision as of 06:45, 15 November 2023

Revision as of 06:43, 28 November 2023

Line 4:

}}

'''Coding best practices''' or '''programming best practices''' are a set of informal rules (''[[best practice]]s'') that many [[software developer]]s in [[computer programming]] follow to improve [[software quality]].<ref>{{cite book|title=Code Complete|url=https://archive.org/details/codecomplete0000mcco|url-access=registration|edition=Second|last=McConnell|first=Steve|year=2004|publisher=Microsoft Press|isbn=0-7356-1967-0}}</ref><!-- I can't access this source. --> Many computer programs remain in use for long periods of time,<ref>{{cite book|title=Software Engineering|edition=Seventh|last=Sommerville|first=Ian|year=2004|publisher=Pearson|isbn=0-321-21026-3|page=38}}</ref> so any rules need to facilitate both initial development and subsequent maintenance and enhancement of [[source code]] by people other than the original authors.

In the [[ninety–ninety rule]], Tom Cargill is credited with an explanation as to why programming projects often run late: <!-- these do add to 180%, and are meant to (=late project). See linked Ninety-ninety rule --> "The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time."<ref name="Bentley1985">{{cite journal|last=Bentley|first=Jon|year=1985|title=Programming pearls: Bumper-Sticker Computer Science|journal=Communications of the ACM|volume=28|issue=9|pages=896–901|issn=0001-0782|doi=10.1145/4284.315122|s2cid=5832776|doi-access=free}}</ref> Any guidance which can redress this lack of foresight is worth considering.

The size of a project or program has a significant effect on error rates, programmer productivity, and the amount of management needed.<ref>{{cite book|title=Code Complete|url=https://archive.org/details/codecomplete0000mcco|url-access=registration|edition=Second|last=McConnell|first=Steve|year=2004|publisher=Microsoft Press|isbn=0-7356-1967-0|pages=[https://archive.org/details/codecomplete0000mcco/page/649 649–659]}}</ref>

Line 123:

It is usually considered good practice to use descriptive names.

Example: A variable for taking in weight as a parameter for a truck can be named TrkWeight or TruckWeightKilograms, with TruckWeightKilograms being the preferable one since it is instantly recognisable. See [[camelPascal case|CamelCase]] naming of variables.

===Keep the code simple===

The code that a programmer writes should be simple. Complicated logic for achieving a simple thing should be kept to a minimum since the code might be modified by another programmer in the future. The logic one programmer implemented may not make perfect sense to another. So, always keep the code as simple as possible.<ref>{{cite web|url=http://docforge.com/wiki/Best_practices|title=Best practices|author=Multiple (wiki)|work=Docforge|accessdate=2012-11-13}}</ref>

'''For example,''' consider these equivalent lines of C code:<!-- Since true and false are not defined in regular C code, assume that the "stdbool.h" library has been included. -->

<syntaxhighlight lang="c">

Line 165:

</syntaxhighlight>

and<syntaxhighlight lang="c">

and

return hours < 24 && minutes < 60 && seconds < 60 ? true : false

</syntaxhighlight>and

<syntaxhighlight lang="c">

Line 171 ⟶ 173:

</syntaxhighlight>

The 1stfirst approach, which is much more commonly used{{dubious|date=December 2017}}, is considerably larger than the 4thfifth. In particular, it consumes 5 times more screen vertical space (lines), and 97 characters versus 52 (though editing tools may reduce the difference in actual typing). It is arguable, however, which is "simpler". The first has an explicit if/then else, with an explicit return value obviously connected with each; even a novice programmer should have no difficulty understanding it. The 2nd merely discards the braces, cutting the "vertical" size in half with little change in conceptual complexity. In most languages, the "return" statements could also be appended to the prior lines, bringing the "vertical" size to only one more line than the 4th form.

The fourth formand fifth forms obviously minimizesminimize the size, but they may increase the complexity: ItThe fourth block requires knowledge of more advanced programming topics, notably [[Ternary operation|ternary operators]], while the fifth block leaves the "true" and "false" values implicit, and intermixes the notions of "condition" and "return value". It is likely obvious to most programmers, but a novice might not immediately understand that the result of evaluating a condition is actually a value (of type Boolean or its equivalent in whatever language), and thus can be manipulated or returned. In more realistic examples, the 4thfourth form could have problems due to [[operator precedence]], perhaps returning an unexpected type, where the prior forms would, in some languages, report an error. Thus, "simplicity" is not merely a matter of length, but of logical and conceptual structure; making code shorter may make it less or more complex.

For large, long lived programs using verbose alternatives could contribute to [[Software bloat|bloat]].{{dubious|date=December 2017}}