4 ms·
Nice list. Here's mine (off the top of my head in no particular order): 1. Start with the answer, then work back. 2. Name your variables so that anyone wi
by edw519 17y ago
Nice list. Here's mine (off the top of my head in no particular order):
1. Start with the answer, then work back.
2. Name your variables so that anyone will know what they are.
3. Name your functions so that anyone will know what they do.
4. Never write the same line of code twice. Use functions.
5. Assume the user doesn't know what they want.
6. Even if the user knows what they want, assume they can't verbalize it.
7. The user always knows what they don't like. Prototype often.
8. Be prepared to dig down as many levels of detail as needed to understand.
9. When you're stuck, turn off your computer.
10. Don't turn your computer on until you have a specific task.
11. Beauty is important, but delivery is more important.
12. No variable should be fully contained within another variable.
13. All variables should be at least 3 characters long.
14. Use the right tool for the right job.
15. Almost any tool can do the job. Some are better than others.
16. Benchmark often in order to learn what happens under the hood.
17. Try something that's never been done. It may be easier than you thought.
18. Remember the patterns you've used before. You'll use them again.
19. Keep it extremely simple at first. Complexify as you go.
20. Code every day.
- olliesaunders 17y agoYou really shouldn't have.
- bsaunder 17y agoCould you explain 12?
- edw519 17y agoSure. If you have the variables TodayYYYY, TodayMM, and TodayDD in your program, then you cannot also have a variable named Today, because it's fully self-contained in another variable. Why? Because it screws up global find and/or replace in a simple text editor. Lots of people have told me that this is unnecessary with a good IDE, and lots have given me lots of common examples of violations of this rule, but I still like the rule (guideline). I like my source code to be portable, easily reviewed by even the simplest tools, and I like the common tasks (reviewing every instance of a variable in a program) to be easy. One of the hardest things I ever have to do when reviewing someone else's code is to identify every use of a variable to find a bug or understand something. Violation of this guideline is the biggest culprit. (And violent, painful death to anyone who writes a 1200 line function wrapped with "for(a=b;a<c;a++){...") This is also why all variables must be 3 characters or more, or it would be very difficult to adhere to #12. (FWIW, my list comes more from many iterations than from any theory or philosophy. We can debate these forever. I just like to do what works for me. Use what you like, ignore the rest.)
- ramchip 17y agoI can think of a lot of exceptions to this though: x,y,z,i,j,t,dt,dx,in,out... all standard, least-surprise variables. In any software that processes images you just know what x and y mean, more clearly than if they were called column and row. Same for t and dt in anything that involves physics simulation. And a function like Vector add(Vector x, Vector y) really doesn't benefit from being called Vector add(Vector firstvector, Vector secondvector) or such. I think the divergence in opinions may simply come from working in different domains. In business software, I imagine the types of data may be a lot more varied than in DSP software and such, so a longer variable name may help keep track of things.
- bsaunder 17y agoAh, no variable name ... Sure, that makes sense. Don't know if it makes a top 20 though. ;) Seems like it could be a bit hard to manage beyond a local module scope.
- harto 17y agoIf you use a text editor that supports regular expressions in a find/replace, you could match on word boundaries (e.g. \bToday\b). That would avoid the first part of the problem that #12 solves.
- bendtheblock 17y agoI've been coming to grips with #11 a lot more since starting my own company. Sometimes you've just got to get something out the door. The perceived value of elegant code is minimal compared to delivering the product (although obviously elegant code has a longer term benefit in being easier to maintain and extend. I always go back and 'do it properly' afterwards. Just add it to a to do list so it's there next time you come to adding a new feature.)