Essentially I agree with Louis' "just throw everything into a pot" comment. I would add that it should be more than "each person's taste", but rather what makes the code easier to read in that specific circumstance.
Good programming practices can sometimes conflict. For example, the "one RETURN per subroutine" rule can sometimes create nasty code indenting, which violates the "only two levels of indenting" rule. One needs to intelligently apply the practice that would make the code easier to understand. Which brings us to why are some practices considered "good". Good practices (1) make the code easier to understand (think of your junior programmers), (2) let the compiler spot potential bugs, (3) prevent bugs from being introduced into the code, and (4) help programmers spot bugs. The end goal is to keep software production costs down by raising code quality -- bugs are cheaper to fix upstream than downstream. Again, I recommend borrowing "Code Complete" by Steve McConnell from the library for a thorough discussion of individual practices. Having a "coding standard" is really just another practice. Whether you and your team uses numeric or alphabetic labels doesn't really matter as much as that you all use it consistently. And if your "standard" isn't applied consistently, do take the time and make it so. rex ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
