A road named NoNameUno

In part one, I focused mainly on organization of files and functions. Here I will try to point out some of the finer aspects ...

Global variables are something it watch for. When you go to system programming space, you will find its danger. As an example, reentrant code should never have use of global variables. You might wonder why is this?. As I found time and again, unless I start to think about something and tryout different possiblities I never learn. It's okay to make mistake, but not learing from it is not okay. Any serious programmer should think about not using globals. If there are lots of globals in a program it not only makes the functions non-reentrant but also it makes the program incomprehensbile. I've seen it way too many times, and I hate any designer who does that.

In any function, if there are mulitple exit points I grade it as bad code. Well there are some nicely written code that has more than one exit point but not too many exit points in a function.  Usually return statement from all over a function is a bad idea at its best days.

Naming variables and other namable objects should be thoughtful. Giving short names are fine as long as it is used in an obvious way. For example variable i,j,k are mostly indication of indices which follows the convention from the fortran or earlier days. But if those variables are used to hold a load of intermediate and or final results of the computations then it is another badness of a program.

If a switch statement has more than 10 to 12 switch points, it is a bad programming style. Refactoring should group some of these.

Implicit casting when results from one types of data is implicitly casted to another type by compiler loss of information is possible. Usually compilers have flags to catch these sort of badness.

Too long of a name is always a bad practice. What is too long? I don't name variables more than 15 to 18 chars when I'm in right mind. Usally 8 to 10 char serves my tastes. Function and methods can have longer names, but if it goes beyond 40 to 50 chars I tend to get a stomach ache.

Pointers or any sort of indirections of 3 or more steps makes me stop for a while. Usually, a pointer to pointer is sufficient in most cases. Try writing some moderate amount of logic using pointer to pointer to pointer and see for yourself. Remember the next person to own your code for maintenance or enhancement might not comprehend easily. And when you are not there, to solve a debugging problem could take a bit longer than usual when such pointers with 3 or more depths are used. Once I had that problem myself, and some other people started calling me point dexter :-).

Interesting comments are for example: If we are here, screw the user, and all sorts of other comments that are personal frustration and / or anger. Frankly there is no need for any of these. It's only a matter of time when the owner would be long gone from the projects, and those littered comments would still be around.