NavigationCy/VOS
Wiki Users |
CyVos /
Coding StyleHaving personally worked with virtually every fad coding style out there, I've finally settled on one. It works extremely well for me, and I find it keeps code small and readable. IndentingIndents are set at an 8 character tab stop, on the principle that too much indenting is a sign of poorly factored code. I keep my screen at 80x58 while coding, and I stop when I reach the right margin. If something is getting uncomfortable due to tabs, something is wrong. Case statements have the nasty habit of taking up 2 entire tabs in most programming styles. I found that unacceptable, so I use this format:
switch(a) {
case 1:
// do stuff here
break;
}
Also, on occasion, a block statement will only contain another block statement and no other code. In this case, it's okay to simply place them on the same line and only use one indent:
for(y=0; y<w; y++) for(x=0; x<h; x++) {
// do stuff here
}
BracesBraces should always start on the line containing the statement to which they belong. For short groups of commands, it is acceptable to simply list the commands and place the close brace on the same line:
if(x<0) { y=-y; x=0; }
If there is only one statement in the group, the braces should be omitted entirely: if(x>0) x=0; In cases where there is only one statement, but it is long, it is acceptable to break the line and indent the one statement. When using an else clause, there are very few cases in which braces may be omitted. Generally, the presense of an else clause should yield the following form:
if(y<515) {
} else {
}
There are a few exceptions. "else break;" is an acceptable statement, and if both clauses are simple one-statement, the result can be expressed like this: if(z>6) z=6; else break; Note that the else still occupies the next line. To put the else on the same line, generally braces are stylistically indicated. NamingGlobal variables are bad. You should have no need of a naming convention for global variables, because they are bad. There should be no global variables in your programs. Local variables should be declared at the head of your function, as per C style. The average local variable should be one letter in length, and generally follows the following standard naming conventions:
Some other variables are relatively standard as well. 'tr' means "To Return" and holds a return value for the function. With regards to i,j,k,l, it is often best to use the first several for the depth of looping you are using and then use the next one as a general-purpose scratch variable. Among other benefits, this virtually guarantees efficient register allocation in the compiler. Structures should be named in all caps, using underscores if there are multiple words. If the type of structure is parametrized, put the parameter type on the end of it (for example, HASHSS for a string to string hash). Functions should be named after the structure to which they belong, in lowercase, using an underscore after the name. The use of more than one underscore is acceptable in some cases. Names like hashss_add or hashss_clear are good names. Four function name types are reserved and defined specially, these are _init, _new, _release, and _free. _init and _release set up the internal data in a static structure, while _new and _free operate on a dynamically allocated structure. Error handlingError handling should be done at the end of the function, after the function return, by use of goto.
int bob(int a) {
if(a>8) goto err;
return -a;
err:
return 0;
}
This particular example is too simple to really use this technique, and simple return of error codes should be used in this case, but whenever there is a substantial amount of cleanup to do, using goto shrinks and improves the resulting generated code substantially. Nested functionsNested functions should be used whenever a function requires a block of code that depends on local variables to be called repeatedly. When the code does not depend on local variables, using global or static functions is preferred. Nested functions, while not strictly standard C, are well supported by GCC and will be supported by CVCC. |