This is a set of coding standards I developed before leaving a previous employer... which I quit because of the horrendous state of software development there. Some of the comments are rather specific to that company, but most of it should be pretty universally applicable.
The following sections will eventually be cleaned up and broken out into their own pages, as spare time allows. For now, they are just my scribbled notes about ideas, so don't bitch about them not being pretty. If there's something you Just Don't Understand, let me know and I'll give it a little higher priority....
don't use switch/case to test just one or two possibilities (use "if[/else]"); use "if (a) {b} else if (c) {d}", not "if (a) {b} else { if (c) {d} }".
no assignments within conditionals (incl. while) unless absolutely necessary
no gotos unless absolutely necessary
function headers (both prototype and actual definition) may be on a single line if it will fit, else stacked like var decls, and indented, w/ parens following grouper rules.
all unshared ini files should be in prog's own dir, NOT WINDOWS DIR! shared ini files should reside in a designated prog's dir, and the location should be settable in the ini file of each prog that uses it.
no weird chars! if you need a weird char literal, use the ascii code or some other way to designate it. weird chars may not survive file xfr.
no assignments within conditionals (including loop conditions), unless absolutely necessary!
when comparing an lvalue to a non-lvalue, put the non-lvalue on the left (to make sure we don't accidentally assign)
all log files should contain only one day's worth of output, NOT get written over, and have names of the form ppyymmdd.log, where pp indicates which program created the log, yy = year, mm = month, and dd = day. (if not restricted to "8.3" names, better to use yyyy!) ops personnel should be responsible for inspecting/compressing/deleting old logs as needed, and alerting the appropriate programmer(s) to any problems noticed -- with as much detail as possible, NOT just "it blew up". on the other side of the coin, the error messages must be as clear as possible -- NOT just "error 6132".
do not assume user has color monitor, especially while tai is too cheap to use them on all our internal testing machines! don't need to check and use a different palette, but do make sure there is sufficient contrast where needed even when resorting to grayscale.