R9: functions/methods should do one thing and one thing only. Their names should be adjectives or based on adjectives and describe what they do. If you have problems giving a function a simple name in this manner then it probably needs refactoring.

R10: Refactor little, refactor often.

R11: Never get involved in a land war in Asia. -- but only slightly less well-known is this: R12: Never go against a Sicilian when death is on the line!

R13: Every software entity should have ONE (and only one) major responsibility. R13_A special case: Single Responsibility Principle (SRP).

R14 Break the rules sometimes but document it!

R15: Unitary testing is a very important part of testing R16: Design solutions with maintenance and day to day operations in mind

QuoteOriginally posted by: Traden4AlphaR14 Break the rules sometimes but document it!Ugggh yeah... this has been in our code for three years now without re-affirming the code below it to the correct rules:

QuoteOriginally posted by: bluetrinR16: Design solutions with maintenance and day to day operations in mindBest one yet.R17: Try to comment on anything that's non-obvious with the comment focusing on why and what rather than how.R18: Don't leave commented out code in source files; delete it and if you need it back go to version control.R19: Make sure to use logging where applicable in terms of giving the user/developer more data about what is happening internally in a function for tracing any possible errors.

QuoteR17: Try to comment on anything that's non-obvious with the comment focusing on why and what rather than how.R18: Don't leave commented out code in source files; delete it and if you need it back go to version control.R19: Make sure to use logging where applicable in terms of giving the user/developer more data about what is happening internally in a function for tracing any possible errors.I like the ASCII dragon! But it does go to show what happens when someone comments on underdeveloped code, or warns about it rather than just fixing it: It tends to stay put!R18: is a particular pet hate of mine. Whenever I see that I am like WTF! R19: So, so true. One role of exception handling is just to have everything unwind in a way that you can understand. Rather than just being left with some cryptic message (if you are lucky) from withing some forgotten recess of the bowels of the code.

R20: "Names should be pronounceable. It is hard to discuss something that cannot be pronounced."// From C++ Coding Style Guide (POCO C++ Libraries)I like this one: http://stackoverflow.com/questions/1846 ... es#tab-top

QuoteOriginally posted by: outrun"HERE BE DRAGONS"I'm currently helping out at a bank with a propper independent validation team. The team asks for docs, makes 300 remakes when they're done with the model-, tests-, docs- and code-review after 4 months, and it won't get into production before *all* remarks are adresses during all iterations.Their first remark in this case would be: can you remove that dragon ASCI ART and document what goes on below?Sadly I'm my own validation team (seriously where do these banks get the headcount and viable candidates for stuff like that?).QuoteOriginally posted by: PolterR20: "Names should be pronounceable. It is hard to discuss something that cannot be pronounced."QuoteOriginally posted by: outrunAnother handy practice is to add good descriptions about the changes you've made when committing to a repository.I put both of these in our style guide, well it says you should not use shorthand variable names (vi, vj, vk blah blah) and aim for readability.Commits with only "Update" as comment means I will yell at you. Normal for us is "[Library Component or project] - Description of change [Pair programming initials where applicable]"

R21: Maintenance is like the weather; everyone talks about it but no one does anything about it. R22: What you lose on the swings you gain on the roundabouts.