2. It worked. You changed something. It doesn't work. It's probably something you did.
3. The answer is always "yes". Sometimes, "yes, but", but always "yes".
4. Never write the same line of code twice.
5. All names (variables, functions, routines, etc.) should accurately describe what they represent as closely as possible. i.e. an intelligent user should be able to read your code and get a fairly good idea what it does.
6. No variable name should be fully self-contained within another variable name.
7. Indent however many spaces you want and use white space however you want. Who gives a shit.
8. Shop standards only count if they are published.
9. Only enter your IDE if you have actually have something to code. Otherwise go back to your pencil/paper/whiteboard (or whatever you use for analysis and design) and don't come back until you're ready.
10. Prototype something and let the user rip it to shreds. Funny how much less bashful they become when they have something to critique. It's much easier to criticize something that exists than to imagine something that doesn't.
The variables "Cust", "Cmmts", "Comments", and "Del" should have different names. What are they? I spent half a day just trying to figure out what everything was, one line at a time. You can't globally locate, edit, cut, paste, or change without fucking up everything else. (And please don't ask me to use a fancier IDE. Just name your variables so the next guy doesn't have to suffer.)
Interesting - what's your objection to auto-doc systems (4)? I assume you mean things like javadocs and python docstrings, which I make use of a lot and people I code with find helpful, too.
Almost all of these are gold and should be framed and hung in every cuce and meeting room.
But the following three should be tattooed to the forehead of each manager and executive:
* Process is no substitute for thinking.
* If everything is equally important, then nothing is very important.
* "Complex problems require complex solutions". NOT!
True, but one of the reasons it is often mistaken for thinking, or managers try to force others to use it instead of thinking, is that "process" or "rules" can substantially improve the output of novices and other lower competence people. The biggest problem with rules is that they degrade the usefulness of experts to the level of anyone who can effectively follow the process; which sort of undercuts the value of having experts in the first place.
I couldn't help but observe that these lists, read independently, would apply to any aspect of life and not only to Programming. Sure we need to replace the technical jargon with their generic counterparts.
1. Start with the answer, then work back.
2. It worked. You changed something. It doesn't work. It's probably something you did.
3. The answer is always "yes". Sometimes, "yes, but", but always "yes".
4. Never write the same line of code twice.
5. All names (variables, functions, routines, etc.) should accurately describe what they represent as closely as possible. i.e. an intelligent user should be able to read your code and get a fairly good idea what it does.
6. No variable name should be fully self-contained within another variable name.
7. Indent however many spaces you want and use white space however you want. Who gives a shit.
8. Shop standards only count if they are published.
9. Only enter your IDE if you have actually have something to code. Otherwise go back to your pencil/paper/whiteboard (or whatever you use for analysis and design) and don't come back until you're ready.
10. Prototype something and let the user rip it to shreds. Funny how much less bashful they become when they have something to critique. It's much easier to criticize something that exists than to imagine something that doesn't.