In many years of programming I have seldom found organizations that could create any kind of coding standard and then get even a few of the programmers to adhere to said standard. And, these organizations created mountains of truly awful code. So, more power to you. I wish you luck.
I would skip over the traditional religeous wars on curly brace placement and indentation. As long as the programmer is reasonable consistant, the code can be read.
Modules and functions ought to have header comments. "Purpose:" is the most useful of all header comments. Next are descriptions of inputs and outputs. And each module ought to have the name of the author and a date. Placing header comments between the function declaration and the opening curly brace makes it clear that the header goes with this function, and saves typing in the function name as part of the header comment.
Good variable and function names go a long way toward understanding of the code. Good variable names are pronouncable to permit discussion of the program over the phone. I personally detest Hungarian notation, it obfusticates the code and preventing type clash is a chore best left to the compiler. Function names ought to be verbs, since a function is supposed to do something. Variable names should suggest the meaning of the variable. Variable names that suggest the units of measurement (Volts, Watts, etc), the axis of the variable (X, Y, roll, pitch, yaw) the source of the data (disk, network, gui, RS232 comm link) add flavor and meaning. Short variable names are a pleasure. No variable name should exceed the length of the longest word in the English language. I dislike mixed case variable names, you have to remember the capitalization as well as the spelling to type them correctly. The C convention of constants in ALL CAPS has much to recommend it.
Code ought to compile warning free, with the compiler on its pickiest setting.
The number of bugs is proportional to the number of lines of code. Anything that shortens the code makes it more robust. Rather than writing out repeatative code sequences in-line, create a function and call it repeatedly. Delete dead code. Pull common operations out of switch cases.
Avoid global variables at all costs. Likewise global typedefs, enumerated constants #defines and the like.
Don't load hexadecimal (or decimal for that matter) numbers into hardware control registers. The resulting code is unreadable. Assign meaningful names to the various control bits using #define or bit fields, so that the effect of the control register loads is obvious by reading the code.
Things should be defined once, in one place, so that when they need to be changed only one line of code need be edited.
Use the sizeof operator to prevent array over write. Use strncpy rather than strcpy for the same reason. Never use an external input to control a loop without checking said input to make sure it will not cause array over write.
Don't nest #include files.
Organize the project files (.c,.h,.lib.dll) so that the entire project can be backed up by copying ONE folder and its subfolders to CD. Do a backup each time the code reaches a stable state. Data on disk is subject to instant distruction without warning. Source code control systems eat files. Keep your own copy.
Use a source code control system. Don't allow two different programmers to check out and modify the same module at the same time. Avoid Clearcase, there are many better source code control systems. Have just ONE main branch of code under source control and insist that everyone base their "sandbox" versions of code off the main branch. Update the sandboxes at least weekly. Don't develop and test a module against an
Slashdot Mirror
Did I miss a smiley face? Somewhere?
How about
#define MOTOR_STOP_POS 456
if (shaft_pos == MOTOR_STOP_POS)
Surely you were kidding about
#define FOUR_HUNDRED_FIFTY_SIX 100
In many years of programming I have seldom found organizations that could create any kind of coding standard and then get even a few of the programmers to adhere to said standard. And, these organizations created mountains of truly awful code. So, more power to you. I wish you luck.
.h, .lib .dll) so that the entire project can be backed up by copying ONE folder and its subfolders to CD. Do a backup each time the code reaches a stable state. Data on disk is subject to instant distruction without warning. Source code control systems eat files. Keep your own copy.
I would skip over the traditional religeous wars on curly brace placement and indentation. As long as the programmer is reasonable consistant, the code can be read.
Modules and functions ought to have header comments. "Purpose:" is the most useful of all header comments. Next are descriptions of inputs and outputs. And each module ought to have the name of the author and a date. Placing header comments between the function declaration and the opening curly brace makes it clear that the header goes with this function, and saves typing in the function name as part of the header comment.
Good variable and function names go a long way toward understanding of the code. Good variable names are pronouncable to permit discussion of the program over the phone. I personally detest Hungarian notation, it obfusticates the code and preventing type clash is a chore best left to the compiler. Function names ought to be verbs, since a function is supposed to do something. Variable names should suggest the meaning of the variable. Variable names that suggest the units of measurement (Volts, Watts, etc), the axis of the variable (X, Y, roll, pitch, yaw) the source of the data (disk, network, gui, RS232 comm link) add flavor and meaning. Short variable names are a pleasure. No variable name should exceed the length of the longest word in the English language. I dislike mixed case variable names, you have to remember the capitalization as well as the spelling to type them correctly. The C convention of constants in ALL CAPS has much to recommend it.
Code ought to compile warning free, with the compiler on its pickiest setting.
The number of bugs is proportional to the number of lines of code. Anything that shortens the code makes it more robust. Rather than writing out repeatative code sequences in-line, create a function and call it repeatedly. Delete dead code. Pull common operations out of switch cases.
Avoid global variables at all costs. Likewise global typedefs, enumerated constants #defines and the like.
Don't load hexadecimal (or decimal for that matter) numbers into hardware control registers. The resulting code is unreadable. Assign meaningful names to the various control bits using #define or bit fields, so that the effect of the control register loads is obvious by reading the code.
Things should be defined once, in one place, so that when they need to be changed only one line of code need be edited.
Use the sizeof operator to prevent array over write. Use strncpy rather than strcpy for the same reason. Never use an external input to control a loop without checking said input to make sure it will not cause array over write.
Don't nest #include files.
Organize the project files (.c,
Use a source code control system. Don't allow two different programmers to check out and modify the same module at the same time. Avoid Clearcase, there are many better source code control systems. Have just ONE main branch of code under source control and insist that everyone base their "sandbox" versions of code off the main branch. Update the sandboxes at least weekly. Don't develop and test a module against an