Title: Professionalism in Programming Part 1

This is the first in a series of articles that will investigate professionalism in programming. Given that the ACCU exists to promote 'professionalism at all levels', these articles are going to delve into what this apparent oxymoron means. We will be addressing what makes a 'professional' programmer.

I hope that for many for you this series will be instructive. For others the issues raised here may seem 'old hat'. Please don't let that make you dismiss what will be discussed. A lot can be learned from simply seeing things that you take for granted written down.

These articles are aimed at both people who consider themselves 'professionals' and people who aspire to be professional.

Although that's the question that this whole series addresses, let's try to briefly define the term 'professionalism' at the outset. We'll also touch upon the concept of 'software engineering' on the way. The dictionary tells us that a professional is simply a person who performs a given activity as a career - i.e. for money. But that's not the spirit of what we're talking about here.

A professional field is one that requires training, experience and ability. The word implies a level of responsibility for what you do. Software engineering undoubtedly requires all of these. Being a professional implies seeking to be the best at what you do. Even if it's not your primary job function, or if you're not yet employed, it is natural and useful to aspire to this professionalism in what you do.

If professionalism involves seeking to be better, this means actively seeking to learn appropriate skills. Perhaps one of the most important qualities in a professional is to appreciate what you don't know - and to be aware of how to learn it when you need it. The skill most hackers[Dictionary] seem most proud of is the ability to blag it - pull something together at the last minute. These kinds of pieces of work are usually hideous hacks. This is not professional. This is not to say that hackers cannot be engineers.

We should also define here the term 'software engineer' since it is pivotal. It implies more than just a paid programmer. Software engineering is not just sitting at a keyboard banging out programs, software engineering is using a defined process to develop software predictably, reliably, on time and within budget (or at least aiming to ;-).

In the same way that structural engineers should follow a rigidly defined process to design and build a bridge (you wouldn't drive over it if they didn't, would you?) software engineering follows a process which leads to the development of high quality software. We'll develop this description further in a later article.

The articles in this series will not focus simply on the single word 'professionalism', but will discuss topics ranging from coding style to working practices to our attitudes. Maybe some of the topics will not seem directly related to the banner 'professionalism' (or at least no more than any of the other C Vu articles). However, what I am trying to pull out is the professional perspective that we should adopt behind each particular issue.

So onto our first topic...

The topic that I'm addressing in this article is something fundamental to the source code that we write. This could been seen as an ill advised starting point since the software engineering process starts a great deal earlier then where we actually sit down and write code. We all at least apply a little thought before we fire up our editor, don't we? However, it would be churlish to start this series with anything less contentious. Let the bun fight begin...

Coding style has been, is, and will be the subject of holy wars amongst programmers; professional, amateur, and student. Intense disagreements occur. This is not the only such 'hot potato', you could extend this article to cover editors, compilers, methodologies, the one true language , and beyond.

The point that I hope to bring out of this is that holy wars over these sorts of reasons are (on the whole) pointless exercises. As 'professionals' we should step back from such petty arguments. You should be sure of what you prefer, but not be so arrogant as to presume that you are correct. We rarely are.

So what do you think is the one true way to lay out source code? Perhaps you favour the K&R flavour:

int foo() {
    int a, b = 0;
    for (a = 0; a < MAX_A; a++) {
        b++;
    }
    return b;
}

Or perhaps you favour this:

int foo()
{
    int a;
    int b = 0;
    for (a = 0; a < MAX_A; a++)
    {
        b++;
    }
    return b;
}

Of course there is this middle ground (the Linux kernel coding style):

int foo()
{
    int a;
    int b = 0;
    for (a = 0; a < MAX_A; a++) {
        b++;
    }
    return b;
}

Or if you're really perverse:

  int foo()
  {
int a, b = 0;
for (a = 0;
     a < MAX_A;
     a++)
b++;
return b;
  }

I've seen worse, and I'm sure you could concoct something of nightmarish proportions if you tried (see the International Obfuscated C Code Contest winners for even better/worse examples [ObfuscatedC]). Do you format code to 80 or 132 column pages, or are we able to cope with more than that these days?

Layout issues are a specific part of your coding presentation style. This covers a number of things: bracket positioning, number of spaces, and whether or not to use tabs. The wider concepts of presentation style (e.g. function and variable names) tie in with other coding concerns such as program structure (don't use gotos etc) to dictate the style in which you write a program. For the sake of time and space we are not going to address all of these separate issues in the one article.

I am going to deliberately refrain from stating my particular preference for layout because I know that it isn't right or better than any other. Why? There is no one true way to indent your code. No one's going to able to claim rights to the Perfect Coding Style (TM). Although the style we chose doesn't matter, how we write our code according to our chosen style most certainly does.

It can be argued that if a C/C++ standard defined the one true coding presentation style then the world would be a better place. After all, all code would look the same. I would raise a counter argument to this: competition is a Good Thing. In a free market economy, competition will drive prices down making life better for the consumer. Monopolies foster high prices and an inferior quality product. If we had a single monopoly coding style who would be able to say that it was the best possible one? By actually having more than one existent coding style to write to, it encourages us to think and improve the way we apply a style. It encourages the style guidelines to improve. It makes us write better code.

Having stated that, I will later propose a counter argument to this counter argument.

Let us explore what is important about a code presentation style. The style is secondary in meaning to the code - after all the compiler ignores all that unnecessary whitespace and gets down to the serious business of interpreting our syntax. Our indentation is not about indicating syntactic meaning. We use it to emphasise the logical structure of the code to human readers. It is about communication and the clearer the better.

There are, in fact, three audiences for our source code.

Undoubtedly our code needs to be clearly laid out; the structure must be enhanced by the indentation strategy, not hidden. If a particular flow of control is necessarily complex (note the word necessarily) then the layout should help you to read the code. (If you've written a flow of control that is unnecessarily complex then change it immediately).

Our code layout must convey meaning rather than hide it. I suggest that these are some good metrics of the standard of an indentation style:

I've spent quite a lot of effort here describing what makes a good coding style and why we need one. But now as long as you write in a style that is 'good' it doesn't matter what style that is. And there's no point in arguing about it.

There is more than one 'good' style. The quality and applicability of styles may depend of context and culture.

Many software-writing companies have an internal 'house style' that defines, amongst other things, code presentation rules. These are important and useful for a number a reasons. If everyone sings from the same song sheet when writing code then the company can be assured that all it's source code is consistent.

What does that give it? If code is released outside the organisation then it will appear well presented, well thought out, and cohesive if every file is formatted in the same way. The company will also be assured that programs are written 'up to' a certain standard by dictating common idioms and methodologies.

The benefits of being able to instantly recognise the shape of one of your peer's code and be able to make appropriate maintenance alterations is clear.

So these house coding standards are a Good Thing. Even if you do not actually agree with the rules they mandate - if your indentation strategy is much prettier and easier to understand (in your opinion) - it should not matter to you. The benefits of everyone sharing the same style outweigh the burden on you to have to conform. If you don't agree with the standard you should still work to it.

You may be surprised to find how much of your coding style is bred from familiarity and practice. If you use a house style for a while, it soon becomes second nature and seems perfectly correct.

So what if you're working on code that originated from outside the company and doesn't conform to your house style? Well, in this kind of situation it makes more sense to write code conforming to the existing style of the source file. (This is why writing to a style that is easy to pick up is important.) The only other real alternative is to convert the file (and any others) into your own style. For most real world projects this latter course of action is just not remotely feasible, especially if you are continually being fed with source code updates.

Conform to the style of a given file/project, conform to your house style where this doesn't conflict, and sacrifice your own preferences. Don't surrender your style blindly, though: understand the benefits weighed against the costs. And what if your company doesn't have a house style? Push for one.

So engaging in 'holy wars' over code layout is a waste of time and unproductive. Can holy wars ever be useful or productive?

The answer is yes. For example, the C++ community is still not entirely sure on how best to use exceptions. Experience of their use is only just becoming mature enough, and this is after a considerable amount of effort. The pioneers of work with (and without) exceptions have been discussing their merits for years, and it is this kind of debate that is generally useful.

Having stated that, some of the discussions that I have seen have been far from useful. Expressions of pure personal opinion are largely useless, even in this pioneering context. What is needed to advance our understanding of new territories is experience presented in a quantifiable way.

This article has focused quite closely on code indenting style. Hopefully, it's been a useful journey into the topic. But it's not just about that.

Avoid creating hot air. The computers in my office do that for me. Know what you like and be prepared to defend it, to put your view across, but don't presume that you have to 'win', that you have to be right, and don't be so arrogant as to do it your way anyway. I'd like to encourage you to respond to what I have written. If you disagree then please tell me so. If you agree then it would be nice to hear. If there are certain topics that you feel should be covered here then tell me.