The coding blog of Alastair Smith, a software developer based in Cambridge, UK. Interested in DevOps, Azure, Kubernetes, .NET Core, and VueJS.
This is a relatively short post, covering the key construction decisions Steve McConnell highlights in his book Code Complete.
The choice of programming language is an important one to get right and may be difficult to decide. It’s worth keeping in mind the team of programmers you have at your disposable, as programmers are more productive using a language familiar to them. Equally, you should aim for a higher-level language if you can, as programmers working with lower-level languages like assembler or C tend to be less productive than those working in high-level languages. Additionally, you will often find that the languages you have learned stay with you. This has the unfortunate side-effect of manifesting itself in ugly ways, such as stretching C++ to be Fortran, or C# to be Java (something I’ve seen at work), so keep an eye out for this in your own code. Scott Hanselman has a great post on this exact topic, where he tries to bend C# 3.0’s var
keyword to be VB’s Dim
keyword.
McConnell provides the following example ordering (high-level vs. low-level) of various programming languages, relative to C. The list is by no means complete (note the under-representation of Functional languages, for example), but, generally speaking, if your language isn’t on there, one very similar to it is (e.g., PHP => Perl, C# => Java):
Language | Level Relative to C |
C | 1 |
C++ | 2.5 |
Fortran 95 | 2 |
Java | 2.5 |
Perl | 6 |
Python | 6 |
Smalltalk | 6 |
Visual Basic | 4.5 |
McConnell then goes on to summarise the history of a number of languages, which I will not present here. It’s worth noting however, that McConnell’s précis is objective, and doesn’t try to “push” or “sell” one language over another. It’s an interesting read.
Programming conventions are next to fall under McConnell’s critical gaze, and he makes a good point that these conventions are important as a reflection of the system’s conceptual integrity; they also help maintain it. As such, the programming conventions to be used should be spelled out before work begins, as the details are too specific to be retrofitted.
Last of all, McConnell points to something he calls “your location on the technology wave”, because your position determines the richness of the available tools. If, for example, you compare web development today, with all its frameworks (ASP.NET MVC, Rails, Django, CakePHP, to name just a few) and languages and developer tools, with web development in the early 2000s — let alone the 1990s! — you will see that in some ways it is less desirable to be a the front of the technology wave.
“Late-wave” environments provide all manner of benefits, such as a number of programming language choices; comprehensive error checking; powerful debugging tools; automatic, reliable performance optimisation; (nearly) bug-free compilers; good documentation; integrated tools; and training. In contrast, “early-wave” environments provide the exact opposite. Programmers must invest time trying to figure out how the language works; working around bugs in the language; coping with primitive tools; fixing code broken by new compiler/framework releases; and juggling multiple tools.
That’s not to say you should avoid early-wave environments, however, as working in this space will often place you ahead of the competition. For example, Lotus 123, MS Word, and Amazon were all built in this space. And of course, the advice dispensed by Code Complete will help even more in primitive environments! Most of the important principles in Code Complete depend not on specific languages, but on the way you use them.
So, in closing, the Key Points to take away from this post are:
Boehm, Barry, et al. (2000) Software Cost Estimation with Cocomo II. Boston, MA: Addison-Wesley Jones, Capers. (1998) Estimating Software Costs. New York, NY: McGraw-Hill Prechelt, Lutz. (2000) “An Empirical Comparison of Seven Programming Languages”, IEEE Computer, October 2000 23-29.