Channels ▼

Andrew Koenig

Dr. Dobb's Bloggers

Dark Corners and Social Forces

November 09, 2011

Last week I argued that because bugs hide in dark corners — that is, using tools in unusual ways tends to break them — there is social pressure on developers to avoid those corners. One important form of such pressure is stylistic restrictions, sometimes called "best practices." Such restrictions are sometimes imposed by tools that examine programs for violations, sometimes by code reviews, and sometimes in less formal ways.

An example of such a restriction might be: Never use an assignment as a condition. An example of a violation might be

if (n = f()) { /* do something */ }

It should not be hard to see what's wrong with this statement. As written, it assigns the value of f() to n and then compares that value with zero. However, its form suggests that its author might have intended to write

if (n == f()) { /* do something */ }

which compares the value of n with the value of f() without changing n. This second form is much more common than the first, which tempts the reader to believe that the author made a mistake.

It is probably wise to avoid using assignments in this way. However, if an organization elevates such avoidance to a formal rule, it creates new problems that I think may not be widely appreciated.

To see where the problem lies, consider a programming shop with a rule that all programs must compile without warnings. In effect, such a shop is telling its people not to program in C++, but rather to program in a dialect of C++ that is restricted by the compiler. Worse, the dialect is defined by a particular version of the compiler.

What happens if a new version of the compiler comes out with a warning that previous versions did not have? Now in order to comply with the no-warning rule, developers may have to change large amounts of code to avoid the new warnings. How many new bugs will those changes introduce?

There is another hazard of programming in socially-imposed dialects: In general, different organizations will have different dialects. As a result, it is possible that when one organization sends code to another, the recipient may have to change that code in order to conform to local standards.

In short, by trying to avoid dark corners altogether, we have redrawn the map of where we can travel — but we have done so differently for each different programming community. Instead of one well-defined language, we are now programming in many vaguely-defined languages.

At this point, you may be expecting me to decry this situation and argue that programmers should always feel free to program in whatever style they choose: After all, what is the point of a language standard if it doesn't define the language that we use? But that attitude won't work either, because obscure coding is more likely to encounter compiler bugs .

I think the most workable alternative is to let usage inform judgment: If you are thinking of solving a problem in an unusual way, you should have a reason for doing so. The more unusual the solution, the stronger the reason should be. As happens in so many other context, the choice of how to express ideas should be a trade-off among conflicting advantages and disadvantages, rather than a list of inflexible rules.

Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 


Video