Recently, I've been thinking hard about what makes code maintainable, and how to write code to be maintainable. This interest has partly been driven by the mentoring of those starting out in C++ that I've been doing, both through the ACCU mentored developers program, and for work.

The principles I've identified have not really been hidden; since they've been widely documented for years, and they're actually things that most good developers do as a matter of course. However, as with many things, you don't necessarily realize their benefits until you rediscover them yourself.

Please note that participation in this competition is open to all members. The title reflects the fact that the code used is normally provided by a student as part of their course work.

This item is part of the Dialogue section of C Vu, which is intended to designate it as an item where reader interaction is particularly important. Readers' comments and criticisms of published entries are always welcome.

In the first part of this series, we looked at what it means to optimise code, and saw the cases for and against optimisation. In this article, we'll look at the process of optimisation. We'll see the correct, methodical approach that will lead to solid, worthwhile code optimisations.

This is the second of a two part article describing an experiment carried out during the 2003 ACCU conference. The first part was published in a previous issue of C Vu (15.6, December 2003) and discussed the background to the experiment and some of the applicable characteristics of the subjects taking part; this one, the second, discusses the results of the experiment.

Look at the following code and decide what is wrong with it. When you have done so, decide what it has to do with the previous section in particular and this section of C Vu in general - well actually the whole of your life.

There have been many languages for writing applications, but relatively few foundation platforms which support applications that are written in various different languages. We've had assembler (proprietary), then C (an ISO standard), and now we have the Common Language Infrastructure (CLI). The CLI standard is ISO/IEC 23271; the same content is also available online at http://www.ecma-international.org/publications/standards/Ecma-335.htm.

Files form the raw ingredients of a software system - source files, build files, configuration files, resource files, scripts etc. These files are organised into directories.

Back in 2001, the then-editor of C Vu, Francis Glassborow, announced his intention to pass the editorship of this journal on to a new volunteer, and so at the start of 2002 I took the reins. In fairness I should say that Francis gave me considerable support in putting together my first few issues, and to this day continues to invest a lot of time in preparing various sections of C Vu. Since the time I took over, a lot has happened. I personally have moved from Bournemouth to Bristol, from Bristol to San Francisco, and from San Francisco to San Diego. The last two moves are not entirely unrelated to a spirited young lass by the name of Désirée, who was also closely involved when I became engaged and then married. Between those changes and others, it is now time for me to step aside and look for a new editor for C Vu; I can no longer give the job the time and energy it warrants.

Repository of Projects

We need to program in order to develop our programming skills. Anything more than the most trivial program takes time and effort. Most students (in the broadest sense of someone who is studying) find it hard to motivate themselves with projects whose end product is of little use or interest to them. It is much easier to put in the hours doing a job properly if the result is something we have a personal interest in.

James,

I thought it was about time I wrote and introduced myself to ACCU members – it’s probably long overdue given that I’ve been production editor for the journals for a couple of years now (just over two years for Overload and eighteen months for C Vu, to be exact).

“There is more to life than increasing its speed” - Mahatma Gandhi

We live in a fast food culture. Not only must our dinner arrive yesterday, our car should be fast, and our entertainment instant. Our code should also run like lightning. I want my result. And I want it now.

Ironically, writing fast programs takes a long time.

Optimisation is a spectre hanging over software development, as W.A. Wulf observed. “More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason – including blind stupidity”.

It’s a well-worn subject, with plenty of trite soundbites bounding around, and the same advice being served time and time again. But despite this, a lot of code is still not developed sensibly. Programmers get sidetracked by the lure of efficiency and write bad code in the name of performance.

In these articles we’ll address this. We’ll tread some familiar ground and wander well-worn paths, but look out for some new views on the way. Don’t worry – if the subject’s optimisation it shouldn’t take too long...

What can be said about C’s everyday do...while loop? It just does something while some condition holds. End of story, right?

No, of course not. That would make the title of this small article silly, so let’s cover two topics.