Standards/reasonable programming practices

I am deliberately posting this here instead of to a programming or standards NG in hopes that some of my co-workers may by chance see this and understand where I'm coming from when I get on my soap-box about standards, in particular documentation! I was told in a response to a message that I posted on our intranet news server that it is an "informal standard" to document return values, files generated, (basically all input/output) of all programs at the top of the program. (I didn't even bother to mention that I strongly believe this should be done for every single function, no matter how simple.) When I spend several hours just figuring out what the purpose of a simple function with references to a host of mod-scope variables and database fields, and then briefly document that in 10-or-so lines, I feel that because others have failed to comment, I wasted (and no doubt countless others have wasted) hours of billable time, just to make a 1-2 line modification or bug-fix. Well, it's hard enough to get people to pay attention to formal standards, let alone "informal standards" (whatever that is...I would think it is an informal standard to not program bugs, but then again nobody's perfect, and I've made enough bugs to overwhelm the mosquito population of the Mississipi basin [yes, I hope I have exagerrated on that point]. This feeling dates back to the time before I had any formal education, which consistently reiterated that you comment, comment, comment, up to the point where one grad-level prof. instructed us that we should "not be ashamed to show this code to our mothers" (meaning it should be neat and well-kempt, as well as functional). It was grilled into me that every function should contain 4 basic comments even before any code is written (Inputs (arguments passed), Outputs (return values, files generated), Side Effects (mod-scope variables modified), and a description of the purpose of the function.) These should be written before any coding is even attempted (think back if you ever went thru "Introductory programming and never spent a moment in preparation before walking into the lab, and then witnessing a fellow student spend a total of 5 hours in the lab for "Concurrency and Real-Time", mostly typing in what he did away from the terminal (while I spent 70 hours in the lab debugging what I had produced off-site, and I was probably only slightly better than average in this respect).) Further reading on good programming practice, netted me the following heuristic "we get worried if a function spans more than 2 pages"...this is not a direct quote, and my distaste for the company which published this book prevents me from revealing it's source (Windows crashes way too much and is so much more confusing than UNIX (of any flavour) for me to give Microsoft any credit for anything). But the real world seems to have no 2nd thoughts about using "Cut-and-Paste" as a valid programming method and it leads to inefficient, difficult to maintain code. I was astounded about a year ago (not my current employer), when I saw database fields with the same information declared as float and as character fields (the designer of this mess swore it wasn't because of rounding problems, which BTW were rampant.) They had also extensively employed triggers to implement application level functionality and programmed if-else's as follows: if (blah-blah-blah) { ... } else if (....) { ... } else if (...) { ... } else if etc...ad infinitum...ad nausem (I kid you not.) you get the idea, I hope. Am I just too anally-retentive, or are companies hiring apathetic and/or ignorant and/or incompetent coders who only wish to blow-and-go and say "It works, see!" and when there is a problem, they inevitably blame it on the user (or in cases of year 2000 problems, perhaps they blame it on mgmt., who didn't anticipate that their code would last for more than 10 years.) I could continue ad naseum (as if I hadn't already), but I'd really rather focus on how to avoid this kind of thing in the first place. I'm not looking for any "magic bullets", but surely there are reasonable ways of preventing bad code from being put into production (other than a massive QA department [Okay, I'll give it up, "Writing Solid Code" from Microsoft Press addresses this issue very well...basically you don't want the programmers pointing fingers at QA, while QA points fingers back at the programmers.] Another very good source is "What's wrong with software" Byte magazine December 1995. Can anyone share what works for them in this regard? Thanks in advance, Danny Wright (company name withheld for fear of admitting that even we have the occasional (lol) spaghetti strand in our own code.) #include <StdDisclaimers.h>