|
===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 |author=Multiple (wiki) |title=Best practices |url=http://docforge.com/wiki/Best_practices |accessdate=2012-11-13 |work=Docforge}}</ref> Sometimes, a developer or project manager will decide to employ more complex code for performance.
'''For example,''' consider these equivalent lines of C code:{{efn|Since true and false are not defined in regular C code, assume that the "stdbool.h" library has been included.}}
<syntaxhighlight lang="c">
if (hours < 24 && minutes < 60 && seconds < 60)
{
return true;
}
else
{
return false;
}
</syntaxhighlight>
and
<syntaxhighlight lang="c">
if (hours < 24 && minutes < 60 && seconds < 60)
return true;
else
return false;
</syntaxhighlight>
and
<syntaxhighlight lang="c">
switch (hours < 24 && minutes < 60 && seconds < 60){
case true:
return true;
break;
case false:
return false;
break;
default:
return false;
}
</syntaxhighlight>
and<syntaxhighlight lang="c">
return hours < 24 && minutes < 60 && seconds < 60 ? true : false;
</syntaxhighlight>and
<syntaxhighlight lang="c">
return hours < 24 && minutes < 60 && seconds < 60;
</syntaxhighlight>
The first approach, which is much more commonly used{{dubious|date=December 2017}}, is considerably larger than the fifth. 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 second 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 fourth form.
The third takes advantage of the C ''switch'' keyword, this is sometimes done for performance, but in some cases, such as this, it makes the code more complex with little to no increase in performance.
The fourth and fifth forms obviously minimize the size, but they may increase the complexity: The 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 fifth 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, but in some cases may be at the cost of performance.
For large, long lived programs using verbose alternatives could contribute to [[Software bloat|bloat]].{{dubious|date=December 2017}}
Compactness can allow coders to view more code per page, reducing scrolling gestures and keystrokes. Given how many times code might be viewed in the process of writing and maintaining, it might amount to a significant savings in programmer keystrokes in the life of the code. This might not seem significant to a student first learning to program but, when producing and maintaining large programs the reduction of how many lines of code there are allows for more of the code to fit on screen, minor code simplification may improve productivity{{dubious|date=December 2017}}, and also lessen finger, wrist and eye strain, which are common medical issues suffered by production coders and information workers.<ref>{{cite web|title=Repetitive Strain Injury|url=http://web.eecs.umich.edu/~cscott/rsi.html|accessdate=30 October 2016}}</ref>
Terser coding speeds compilation very slightly, as fewer symbols need to be processed. Furthermore, the third approach may allow similar lines of code to be more easily compared, particularly when many such constructs can appear on one screen at the same time.
Finally, very terse layouts may better utilize modern wide-screen computer displays, depending on monitor layout and setup. In the past, screens were limited to 40 or 80 characters (such limits originated far earlier: manuscripts, printed books, and even scrolls, have for millennia used quite short lines (see for example [[Gutenberg Bible]]). Modern screens can easily display 200 or more characters, allowing extremely long lines. Most modern coding styles and standards do not take up that entire width. Thus, if using one window as wide as the screen, a great deal of available space is wasted. On the other hand, with multiple windows, or using an IDE or other tool with various information in side panes, the available width for code is in the range familiar from earlier systems.
It is also worth noting that the human visual system is greatly affected by line length; very long lines slightly increase reading speed, but reduce comprehension [https://blog.codinghorror.com/text-columns-how-long-is-too-long/ Text Columns: How Long is Too Long?] and add to eye-tracking errors. Some studies suggest that longer lines fare better online than in print [http://www.humanfactors.com/newsletters/optimal_line_length.asp Human Factors International], but this still only goes up to about 10 inches, and mainly for raw speed of reading prose.
===Portability===
| 