This is the seventh of a series of articles examining Bjarne Stroustrup’s writings about the core foundations in C++. The first part is here with links to the other parts:
A Question of Style, Rules, and Freedom
The section “Rules of Thumb” was changed to “Advice” in the third edition, starting:
“Here is a set of “rules” you might consider while learning C++. As you get more proficient you can evolve them into something suitable for your kind of application and your style of programming.” (1986 page 9) (1997 page 16)
This might sound reasonable, after all programmers should have freedom to decide matters of style for themselves. Except,‘your style of programming’ often works out to be an excuse for undisciplined programming — some will decide style does not matter at all, just write messy programs, which are hard for others to read and understand (the important point). On a project with many programmers — which OO is for — issues of style are contentious. Freedom turns into a burden, mainly for others. Programs are semantic entities, that is they convey meaning. Meaning is enhanced by format and presentation.
Freedom is a burden.
Projects and companies must develop style guides, which are often officious in tone, “do this, do that”. C and C++ do not support disciplined programming in the language, instead it must be imposed, either by programmers themselves or on a project. This is more work than in a language that supports you doing it right in the first place — something that Stroustrup would say ‘forces’, and C programmers have characterised as ‘against programmer freedom’, or ‘training wheels for beginners’. Beware of those who advocate ‘freedom’, they often don’t have your freedom in mind at all.
Lack of support is extra burden on programmers who must roll-their-own, leading to a mix of styles within a team on a project that often don’t mix, meaning extra burden. Discipline must be imposed in C and C++ rather than supported as a matter of fact in better languages. With the syntax of classes, programmers are led to believe they have something when really they don’t.
But C and C++ have always appealed to the programmer ego of being self made and not going along with what the pedagogues might be saying. Instead, do your own thing, be your own man. While computing helps us ‘think different’ and that should be encouraged, the maverick culture of C and C++ is not helpful in large-scale and complex software development. ‘Think different’ should be ‘think better’.
A language should naturally support a programmer to take care of these issues. C++, style guides are often “don’t do this, don’t do that”. Some programmers disagree over what often seem fine points, or even “well, why shouldn’t I use pointers”. A language should support paradigms and styles of programming. Direct language support, rather than vague ‘programmers can adopt their own style’ advice.
Note the word should be ‘supporting’, not ‘forcing’. The C world has often used emotive words such as ‘force’ and language such as Stroustrup used to dismiss other better-designed languages. Sadly, it has proven all-too-effective in dissuading programmers from better languages. For too long programmers have been forced to use C and C++.
When it comes to issues of style, programmers have their own preferences and should be allowed to have those preferences. The word is ‘preferences’. Style is how a program is presented. It should not be hard-coded in text layout, but a programmer should be allowed to set those preferences in their display and editing software. These become language processors in their own right, able to parse syntactic constructs and manipulate symbols and formats. Far too much programming style is based around the thinking of printing a program in fixed format on paper. But now we look at programs on screens and these are fluid. We can adapt style in an instant. Many languages are based around fixed-space ASCII typefaces. We should get away from this fixed thinking about style that is baked into old languages such as C and C++.
If one programmer prefers (rightly) underscores to separate words in an identifier, but another likes camelCase (even though it is lumpy and ugly), let both have it their way. One programmer might like 3 character indents, another 5, another 8. Sometimes it might be that changing indent spacing helps spot problems. We do not want style rules like ‘CamelCase must be used and not underscores’ (wrong as that rule is), or ‘indents must be by three spaces, no tabs allowed’.
Like a word processor has styles (style sheets), language display software should be able to easily adapt styles.
The section (in third edition) concludes with advice about advice: “Remember, this advice is only rough rules of thumb, not immutable laws. A piece of advice should be applied only “where reasonable.” There is no substitute for intelligence, experience, common sense, and good taste.” (1997 page 16) (2013 page 31)
This is very vague. It sounds sensible. If a language provides a single good way of doing things, it should seem natural to never want to do otherwise. But C++ provides a curious mix of half-baked brute-force ways of doing things. This might seem like you can be creative, until you are on a large project where modules must be combined and find they are all very different. The fixed styles mean it is difficult to read another’s code, which might be poorly formatted or according to some strange or different logic, common sense or taste. Again this is resolved by project management dictate about style. There is no individual freedom.
Such secondary issues should not be important and distract a programmer from what really is important. Elements of style should not be early bound but late bound. Making style and formatting as automatic as possible frees the programmer to think about more important issues. Those who object to format and style rules actually understand that. A programmer tells the system how they want a program displayed when they view it, although the language itself will suggest good formatting. But good formatting follows good clean syntax, which C++ is not.
But while formatting should be suggested by a language, formatting should have no effect on the semantics of a program, as in Python. However, Python’s advantage is that, in the context of fixed paper-based formatting, programmers are forced to conform to the indent style, or their program will go wrong.
A language should suggest natural and good ways to do things. These should always seem reasonable. C++’s ‘do what you think’ approach will lead to heated debates on a team. That is not productive.
As for the last part, sure there is no substitute to these things, but common sense is often rare and just an excuse for people to have wrong opinions, and C++ is hardly a case of ‘good taste’, it is rather crass. C++ again feeds programmer ego and the Dunning-Kruger Effect. Most people will rate themselves as being intelligent, experienced, and having common sense and good taste. Those with the most programming experience know we all do silly things of make mistakes in complex environments. Common sense and good taste are just subjective.
“I find rules of the form “never do this” unhelpful. Consequently, most advice is phrased as suggestions of what to do, while negative suggestions tend not to be phrased of absolute prohibitions.” (1997 page 16) (2013 page 31)
I suspect any of the uttering of this kind in the C world are rather disparaging comments about those who suggest better forms of programming because they have been there, and have learnt, so pass that on. There are some who are overly didactic, but the culture in the C world seems to encourage a kind of childish rebellion against any kind of teaching or encouraging better programming.
Good, pragmatic language design results in good and obvious ways to do things. There is no need for this advice. Again, the many officious style-guides for C++ most often come in the form “you must do this, you must not do that”. It is this kind of style rule book with “never do this” that comes out of languages like C++. So while the creator of C++ might say he does not like “never do this” rules, he has created a language where this kind of rule is in abundance.
“I know of no major feature of C++ that I have not seen put to good use.” (1997 page 16) (2013 page 31)
So why are C++ style guides full of “use this, but don’t use that”? This results in a curious mix of things that you should not use with each other. It makes programs difficult to maintain. In fact, advice point 2 at the end of chapter 2 says “You don’t have to know every detail of C++ to write good programs.” This is somewhat of an excuse. Good programmers after six months experience should be familiar with just about every nuance of a language and know what every feature is for, and when to use it. Every part of a language should be useful. But C++ excuses programmers from this.
Advice point 3 says: “Focus on programming techniques, not on language features.” Great advice, but C++ forces thinking more about the language than most other languages. But C and C++ put the languages at the centre distracting from programming techniques. The programmer and techniques, foundations, and principles should be the centre. Many of the things that ALGOL was careful to get right, like distinguishing assignment from equality were ignored in C. Furthermore programmers are expected to be loyal to C and C++ and defend them against criticism such as the current document. C/C++ programmers can dish it out against other languages, but the can’t take the truth about their own.
