Coding style
I've never been dogmatic in my books about coding style. That said, however, I was a tyrant with the programmers who worked for me when I owned my own software company. For example, every method/function had to be introduced using the comment style shown in the book (e.g., p.252). This promotes consistency which makes it easier for others to read your code. Also, we wrote tools that would parse the source code, pull out these headers and record the name, parameters, source file, and page number for each method. This became documentation for the other programmers without requiring someone to read and transcribe the data. Running the tool once a month kept our documentation up to date without a hassle.
I always use braces, even on single-line if, for, while, etc. statements. It makes it easier and faster to add a temporary debug line of code when necessary, or add new statements if needed.
I tend to have longer variable names that most, in an attempt to make reading the code easier.
I only use comments if the code doesn't speak for itself. Code with no comments is rarely a good idea, but code with too many comments is just as bad--perhaps worse--as they can get in the way of understanding what's going on.
For managers: I always had team programming goals (i.e., "deadlines" is a less polite word) that rarely exceeded three weeks. Since my company was small, a "team" was usually only two people, rarely three or more. Friday mornings were always set for code review and everyone had to attend. Having a dozen eyes dissecting your code is a great learning experience and quickly shows bad habits if others can't follow you code. This is really important in a small shop as people do get sick and you need someone to be able to jump in and work on the code while you're gone. If the Friday meeting was a code review involving a three-week deadline and the goal was met and passed, lunch of beer and pizza was on me and they got the afternoon off. You'd be surprised how this fosters a team spirit. I can't tell you how many times programmers not even on a team stayed late into Thursday night to help a team get its code done. Such effort also helped keep other team members "in the loop" on what other team members were doing.
As a general rule, pick a coding style that works for you and then use it consistently in your code. It's the consistency and what works for you that matters, not what someone else thinks is right.
__________________
Jack Purdum, Ph.D.
Author: Beginning C# 3.0: Introduction to Object Oriented Programming (and 14 other programming texts)
|
