Brevity

Long code makes debugging harder. 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 have 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 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.

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.

You're code should be your documentation. If it's not, you probably haven't listened to the other two allies.

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 functions -- you're doing it wrong, unless you're writing a compiler, then no more than 5. Redesign your architecture.