OldFart wrote:6. use of tabs. As a great mind once remarked about not setting the tabwidth to 4 (or was it 8?) is like redefining pi to something different from 3.14. His observation was quite right, but his conclusion did not match mine. My stance on this one is: don't use tabs, but spaces as they are unubiquitous.[LURKINGMODE=ON]

I prefer tabs. You can change the indentation by changing the tab width in a good editor and it's easy to convert tabs to spaces in most cases. It's just a personal preference.

I agree well with most of what has been said. I also confess that I am guilty of having no specific format for variable and function names.It's bad enough that I have asked for a "guide sheet" and I keep it open when writing new code. Also, when taking a break from writing, I often go back over the code looking for missed names.

There is one habit that I picked up deliberately, that is sometimes frowned on by others. It was suggested by a Comp-Sci professor over dinner one night. When comparing a variable to a constant,I now always put the constant first. This has the rather nice side-effect of throwing an error if I forget the second equals sign. For example:

I have only recently been back to coding C/C++ and like both those tips. I think the warning one is probably more practical for me as I have always been very OCD about warnings and cringe at the projects(scarily large production projects) I see that happily spew thousands of warnings and the teams are like "what no big deal".

Quite agree, enable all warnings and the "treat warnings as errors" state also. A module that compiles with warnings displays careless workmanship.

Another one of my favourite hates is code that is difficult or impossible to read and maintain. We are not immortal and one day, some other poor bastard is going to have to read this code and maintain it. Let's at least make his life a little easier.

I'm glad to read this and see people agree with my thoughts about "bracing". In the outside world, or open source world, it is common to split braces so they are out of alignment and the make it a coding rule for any writers. For example:

I am changing my ways there. Aside from ordering of values, I can see the bottom is more clear what it does, but because of my background I imagine the compiler producing poor code that actually checks the variable against zero instead of testing it and using the CPU Z flag. I just don't trust compilers. Which always seem to lack basic optimisation by reloading registers with what they just loaded in there a couple of instructions ago.

Hypex wrote:I am changing my ways there. Aside from ordering of values, I can see the bottom is more clear what it does, but because of my background I imagine the compiler producing poor code that actually checks the variable against zero instead of testing it and using the CPU Z flag. I just don't trust compilers. Which always seem to lack basic optimisation by reloading registers with what they just loaded in there a couple of instructions ago.

Just out of curiosity I wrote a simple program that just contains a single 'if' statement and compiled it to assembler (gcc -S test.c -o test.s) and (expression == NULL), (NULL == expression) and (!expression) all produced exactly the same assembler code. I would agree that (expression == NULL) makes it clearer what's being tested.