Also, write code which calls only really well documented functions. Doing jQuery("#my-input").val() is clear enough. Doing myCrazyFramework.dom.manuplators.find.get_value('my-input') is more obscure, even though it's more verbose.
Write small chunks of code: a function over 50 lines is probably really hard to read. This is a rule of thumb, not a commandment, but I found it to be true in at least > 51% of cases.
Avoid code magic. E.g.: deleteUsers(username) should not check for whether username has the substring "test" in it to see if the user should really be deleted.
Avoid state at all cost.
Avoid timing dependence. Pretend like anything in your application can happen any time any place.
Handle all exceptions.
I'm probably wrong on at least 50% of the above, and am probably missing 10 time as much...
Write small chunks of code: a function over 50 lines is probably really hard to read. This is a rule of thumb, not a commandment, but I found it to be true in at least > 51% of cases.
Peter Seibel, in Practical Common Lisp, has a footnote about this:
"A friend of mine was once interviewing an engineer for a programming job and asked him a typical interview question: how do you know when a function or method is too big? Well, said the candidate, I don't like any method to be bigger than my head. You mean you can't keep all the details in your head? No, I mean I put my head up against my monitor, and the code shouldn't be bigger than my head."
Also, write code which calls only really well documented functions. Doing jQuery("#my-input").val() is clear enough. Doing myCrazyFramework.dom.manuplators.find.get_value('my-input') is more obscure, even though it's more verbose.
Write code that's been written before. Don't use clever patterns you found on code snippet sharing websites (http://code.activestate.com/recipes/66531-singleton-we-dont-... for example). Keep using the same pattern over and over.
Write small chunks of code: a function over 50 lines is probably really hard to read. This is a rule of thumb, not a commandment, but I found it to be true in at least > 51% of cases.
Avoid code magic. E.g.: deleteUsers(username) should not check for whether username has the substring "test" in it to see if the user should really be deleted.
Avoid state at all cost.
Avoid timing dependence. Pretend like anything in your application can happen any time any place.
Handle all exceptions.
I'm probably wrong on at least 50% of the above, and am probably missing 10 time as much...