User:Average/Compactness
Long code makes debugging harder. Sorting out your logic so it's tight is one of the trademarks of the hacker. Want to make a super-optimized function that no one understands but is only 1 line long? Cool--just remember the companion to this rule is TightCoupling, so you better make some tests to couple with your supercode, because no one wants to decrypt your code when they're busy working on their own. Good tests (doctests!) are the best way for them to know that it works. Perhaps they'll even add their own test that is specific to their use-case.
Your code should be your documentation. If it's not, you probably haven't listened to the other two allies.
Excessively long code looks dumb to experienced programmers. Got some really awesome /*multi-line headers*/? Tighten it up, assrub. Turn those comments into tests, so that we can be sure it runs as documented after version 20. The only thing you should need is:
- function or object name
- docstring that is returned with object or function is queried
- doctests that show with complete clarity what your function/object does and should do.
Learn how to be precise -- maximum amount of knowledge in the fewest words possible.
Oh, and if you're pushing more than 4 parameters into your function -- you're doing it wrong, unless you're writing a compiler, then no more than 5. Re-engineer your design.
Contracts? Contracts are for agreements between other people. Same with code: if you're writing for yourself, don't use them. But then, should you write for yourself?
Asserts are excellent for TightCoupling, but can be shut-off (removed) for your whole environment when you don't want the extra overhead and you've established that your code is >safe in the wild<. Refer to the Gospel of Object Oriented Programming.
