++C

When I graduated from university I wasn’t naive enough to think that I was a complete Software Engineer, however, I didn’t appreciate just how little I really knew about programming in the real world. I can only liken it to learning to drive. Driving instructors don’t teach you to drive, they teach you to be able to make a car go and stop, you don’t learn to drive until after you get your license. Programming is the same, when I left university I knew how to write code that would compile and run, but the code I was producing was poorly commented, inefficient, wordy (i.e. not dry) and…well, you get the idea. The best example I can think of is the postfix/prefix increment operators. When I joined my first company, every for-loop that I had ever seen, or written, had always used “i++”. The guys at work were quick to challenge this, they asked why I used “i++” instead of “++i” – considering the latter is at least as efficient as the former*. My answer was that I didn’t know and had never really considered it. Two and a bit years later and I am now just as passionate about keeping code dry as the people who challenged me at work.

Some companies will not hire graduates for the simple reason that they will have to put them through the same initiation that I experienced. This seems a tad unfair on the graduates, even if it is a sensible decision to take. I think that software companies should have a greater part to play in shaping graduates, because at the moment things are tailored to the universities e.g. the incredibly verbose commenting style that makes it easier to grade a squillion reports in a couple of hours. Chris, if aworka doesn’t work out, maybe you can start a course called “Programming in the real world”!
*Some compilers will evaluate “i++” to the same as “++i” if the return value is not used.

3 thoughts on “++C

  1. DRY stands for ‘don’t repeat yourself’. It’s not really to do with code efficiency, but I know what you mean.

    Understanding the difference in efficiency of ++i vs i++ shows a certain depth of understanding, but makes bugger all difference in practice.

    Things you should worry about instead include:

    Have you written automated unit, functional and integration tests?

    Is your code designed well? For example, if applying the Model/View/Controller pattern, do you have fat models and skinny controllers? Do you utilise helpers and presenters to improve your controller/view design?

    Is your software easy to use?

    Does your software meet its requirements?

    Has your implementation been cost effective?

    And lots more!

    If I were to provide a programming course, it would start with the ideas I listed in my blog

    I agree with your passion: code should be done right: nicely designed, easy to test, easy to maintain. Writing code that works is not enough! Cutting and pasting code to implement something similar is always wrong!

  2. The reason I used i++/++i as the example is because that is pretty much as simple as you can get. It requires no extra planning, design, or documentation to achieve that extra efficiency – it only requires that you have it in mind when you are coding. If you can’t be bothered to get this bit right then you should pack up and go home.

    I also disagree with you about DRYness and code efficiency. DRY code is more efficient because it is quicker to compile, this may not be such a benefit by todays CPU/RAM standards but is a benefit none the less. DRY code is also more mantainable, and so less prone to requiring hacks and bodges.

    The design and testing are obviously also an important part of the software development lifecycle. I am now learning how to use CPP-Unit and Lint. I am also developing and maintaining test documents alongside the code. I am also engaging in a formal design process before jumping into coding. Iterative design is a good idea, but when coupled to rapid prototyping and unrealistic deadlines it leads to the prototype being adapted to be the finished thing. This all colludes to cause the creation of a downwards spiral of buggy, inefficient and unmaintainable code.

  3. DRY code may be quicker to compile or have other benefits, but really its all about testability (leading to better reliability) and maintainability. I’m not doing compiled code anymore anyway.

    Actually, I’m in favour of evolving prototypes into production code. Rapid development doesn’t have to mean shoddy code. Keeping it dry and developing tests helps.

    The production of documentation of any sort needs careful consideration, as it can easily hamper agility.

    In the end, writing less software has got to be the way. That means reducing functionality to the useful minimum, using powerful expressive languages and collaborating on all those bits that can be common between applications.

Leave a Reply

Your email address will not be published. Required fields are marked *