Does Programming Style Really Matter?

How important is programming style? Just how pedantic should we really be in code?

I have worked for software test tool vendors for many years -- still do, in fact. Most companies buying these expensive offerings work in a safety-critical sector, so they are looking to adhere to the kind of standards that earn them the right to sell their wares in the appropriate markets.

Many of these standards are process based. They lay down a development process to be followed for the whole application from beginning to end, and they generally include variations on their demands depending on the application's criticality or components. Examples of these process standards include ISO26262 in the automotive industry, IEC61508 in the process industries, and (perhaps the grandaddy of them all) DO-178 in aerospace.

Then there are coding standards: sets of rules that limit the syntax, constructs, and functions normally available in a high-level language such as C or C++ to avoid those most likely to give rise to error. Historically, most of them have been concerned with safety (the MISRA standards are perhaps the best known), but more recently, standards such as CERT C have applied a similar approach for those more concerned with software security.

Coding style is something different. It is not especially concerned with which parts of the languages are used. It focuses more on what the code looks like when it is completed. What is legible to some is incomprehensible to others, and style preferences can become ingrained over many years and defended with almost religious fervor.

Some even take pride in making their code as illegible as possible. It is hard to imagine a defense for that stance in a commercial environment, but the existence of the International Obfuscated C Code Contest supports the idea that writing illegible code can be an attractive brain teaser for some. (Check out Ian Phillipps' "12 days of Christmas" winner from 1988.)

One of the most notorious variations concerns the positioning of curly brackets. My background from too many years ago was in Pascal, which uses begin and end instructions to define the scope of a block of code. That is probably the reason I much prefer the first of these two programs to the second.

main()
{
printf("Hello World");
}
main() {
printf("Hello World");
}

If I find it much easier to work with the former format, why shouldn't I? And why shouldn't my colleague follow her own preferred route? Surely we will all do a better job if we follow the paths we feel most comfortable following.

The standards themselves lay down little in terms of style. DO-178B merely suggests the use of "Source code presentation standards, for example, line length restriction, indentation, and blank line usage" without mentioning the aim of doing so. Just what is required? Where do we stop? How pedantic should we be?

It is recognized that a consistent style assists programmers in understanding code written by others. However, since style is a matter for individual organizations, MISRA C does not make any recommendations related purely to programming style. It is expected that local style guides will be developed and used as part of the software development process.

In other words, there is nothing wrong with either of the "Hello World" programs. Both layouts are defensible and logical, but each is acceptable only if that style is used throughout a project or an organization. If I don't like the format of the second example, and it takes me a little time to get used to it, that is a small price to pay for the ability for any developer to pick up any code from the project and understand it without having to struggle with an unfamiliar layout.

As long as it exists, then, the detail of programming style doesn't matter at all. It is the consistency of style that is all important.

I worked as a programmer in my early career. It was very important that everyone on the programming team program in the same style. Why? (1) It allowed us as a team to serve our clients much better (2) It allowed us as a team to update/change program request quickly (3) It allowed us as a team to use our department programming style to train new employees (4) Time. Of course, I can go on and on; but programming in the same style is a must from my point-of-view if you are working within collaboration environment.

When I learned "C", everything I learned from was 1TBS (one true brace) (author's first example.) Wikipedia has an excellent summary of the variety of styles in their "Indent Style" article, it's certainly worth a visit, and discusses all the various styles with the origins of each.

The style that most directly contradicts 1TB is the WhiteSmith style (see the wikipedia article!) which makes it very difficult for a 1TB familiar to "see" when editing a WhiteSmith styled source - whereas for one who uses the Allman style (author's second example), it's more easy to adjust to the indented braces.

Anyhow, some sophisticated editors (e.g. SlickEdit) can "beautify" the code automatically to a style the editor supports - though the tab spacing can be an issue.

http://en.wikipedia.org/wiki/Indent_style

As for myself, I use 1TBS, because I like to have as much "code" on the screen at one time, rather than needing to scroll up and down just to get past all the braces.

@Mark Pitchford: As long as it exists, then, the detail of programming style doesn't matter at all. It is the consistency of style that is all important.

Precisely. The best comment I recall on the topic was in a document on coding in TCL, where a particular style was mandated. The comment was essentially "It's not whether this style is "better", it's that we all do it the same way."

Most programming is done by teams. You aren't the only one who will ever look at and perhaps modify your code. If the style you prefer is different from that used by others, you introduce friction into the process. Style matters because it affects readability and therefore code comprehension. If the project has standards for style all follow, friction is reduced.It doesn't take all that long to get used to a particular style, and your editor may well have facilities to enforce that style as you code.

And in any case, if you're writing code for money, you do it the way the people paying you want it done.

I work for a software company, and we have quite some strict rules for our software development, and that does include code conventions, but not limited to. Our focus is in safety-critical systems, and as such we have clients that do require some standards to be applied (DO-179B, ISO26262, others). In the beginning, we followed those as per clients requirement, but soon we decided to incorporate guidelines in our own internal processes.

First, let me make very clear that coding conventions are not about the overall layout of the code (the given example is not a good example of what the coding conventions are about). They exist so that the product (as source code) can be tested, maintained, and in a more general approach, allow for a concrete mapping between it (the code), the design, and the requirements.

Let's go for some examples. The first one is a classic (and forbidden by the standard MISRA rules):

Why is this code bad ? It is an infinite loop, but it cannot be tested. MISRA forbids infinite loops, but they do happen, but the main problem here is not the infinite loop itself, the problem is that you cannot ensure that you actually entered the while loop. The instrumentation tools (like LDRA) will indeed place an instrumentation call inside the while loop, but, unless you have a fancy way to go back so to report that, you're basically doomed - the code will just, well, loop. (Mark will understand this).

So, the right way to "code" that piece of block is to allow you to redefine the clause, like this:

Most standard do not actually impose a standard on you, but they impose that a standard shall be used, one that helps your code to be scrutinized and proved right, without the need to use formal methods.

However, does such critical software developpement use source control ?

This is another tool one have to trust. I assume you do not have to trust it by deciding reference for sources is what integration (or packaging or delivery or whatever name) team got when building what is to be delivered to final customer.

Then, giving conversion task to source control instead of editor does not change anything.

Anyway, I now agree with GordonScott that version control system should do that, not editor. Actually, I once worked for a company where we put hooks to version control to check source file format was in accordance to coding rule. Could as well writen the hooks to perform on the fly conversion.

Even with editor performing the conversion, you would be able to use string base code inspection tool. But better with version control perforning it, as source content will be consistent whatever the tools and/or editor(s) developper uses.

I think this just shows that a case can be made for different standards if needed to "drive" the development in one directin or another but certainly within a project or within a company there should be a standard so everyone can work together on a team.

Of course if you are the only one doing development then you get to set the standards...

Assuming that the tools are readily available and easy to use to store and retrieve source code in a style independent way, that does not address ALL aspects of coding standards. There are other aspects to coding standards besides the formatting. Variable and function naming conventions are an important part of working with a team. Also things like what should be contained in a file and commenting of functions are also very important and can't be taken care of with editor translation. A good coding standard will address these issues as well.

I could also see a problem if you were working with another developer on a piece of code and viewing it on the same screen. Who gets to decide what the format should be? Much better to have consistent standards to avoid arguments.