Defining Useful Coding Practices?

markmcb writes "A NASA engineer recently wrote about his disappointment that despite having well-documented coding practices, 'clever' solutions still made the code he has to maintain hard to follow. This got me thinking about the overhead spent at my own company regarding our code. We too have best practices that are documented, but most seem to focus on the basics, e.g., comments, modularity, etc. While those things are good, they don't directly ensure that quality, maintainable code is written. As the author points out, an elegant one-liner coupled with a comment from a few revisions ago makes for a good headache. I'm curious what experience others have had with this, and if you've seen manageable practices that ultimately offer a lot of value to the next programmer down the line who will have to maintain the code."

Comments

Re:Soem of the complaints aren't valid

[tomhudson]

Exactly. Use ambiguous terms like erating if you want to ensure that other people are going to have to do global searches on erating in order to figure out what it means.

I would want anyone maintaining the code to look at the declaration to make sure they know what type it is, then look at any initialization code, before monkeying around with it.

That's what ctags is for.

It even supports php, javascript, perl, make and shell scripts - it's not just for c any more.

Re:Soem of the complaints aren't valid

[tomhudson]

whereas organizationEmployeeRating has an obvious meaning to it and will trigger associated memories for that concept.

... and it's SO obvious that when someone DOES change it, nobody else is even going to bother to check, because it's "obvious" what it means. Something can be both obvious and wrong, and the use of java-style retarded naming conventions in c code is a source of both consternation and bugs. c is not java. If you're not comfortable with c, go back to interpreted languages like java and perl. (yes, java is interpreted at runtime - get over it already).