Saturday, October 10, 2009

The best practice for programming

I was asked about the best practice of programming.  As far as I know.  There are plenty of such documents available online. So I just list something I learned from my passed projects. Most of them are independent of any programming language, some even not direct related to coding. But I like the saying: There is more to driving than knowing how to operate a car.

1. Communication! Communication! Communication! Talk to anyone you think necessary within the development team, from expert to novice. Present the idea in diagram. Make sure all developers are working with each other, not against each other. I myself feel boring to read theory more than half day, the learning/training must be through the iteration of hands-on/discussion/thinking/reading. This is not limited to programming.  The thumb-rule is all developers must know they are coding towards the right common goal, which is more important than any so called best practice. Obviously if your organization set wrong direction, then we cannot help at this level.

2. Always define meaningful naming convention for everything, like variable, function, conditional flags. Try to make the code self-explained. I am not saying we can ignore comment, but it is hard (if not next-to-impossible) to ensure everyone always keep their comment sync with code in a large project.

3. Always define a coding style (even you are the only developer). Enforce coding style by static checking tools if necessary. There are auto-formatting tools, but I think those are useless for big project.

4. Pay attention to the default case. Assume there are 2 possibilities: A, and B. Be careful to use

   if A   do something for A;

   else   do something for B.

One day if you have possibilities: C, the above example will be a bug, and so on for switch, ..#if #else, ...  Try to make explicit condition, and create warning/generate some notice for error case;

5. Use debug macro and make sure the debug macro can be disabled per severity level or functional area, can be turned off (instead of remove) in the release code.

6. For a large project, make it clear for public or private functions, and have someway to detect error (compiler, script checker, etc) automatically.

7. A common error: if (  A=B ) instead of if( A==B ), which will assign the value of B to A, and execute the block with the new value of A, which is B. So be careful to have proper coding style, and you can check this by “grep” or script.

8. I like the Model based design, layered structure, and power-points to explain the flow in diagram, try to use these for documentation. BTW: If your model can be used to generate code, then it is a live modeling. Otherwise the development team will use it for a while for various reasons, but later the model will be dead.

9. For senior level developers/tech leaders, make sure you have a clear idea on logical partition, and software configuration management, or at least have an idea for discussion with management and developers. Make sure, more developers should mean more contribution to the final dead-line, NOT more chaos.

No comments:

Post a Comment