Below, please find a proposed set of fees for committing various programming transgressions.
Note: this is not a list of things you must never do, but an attempt to quantify the relative cost of employing these techniques.
Payment is due at the time of code review.
Style guide violations
Consistency in a codebase is a small but worthy goal.
Lazy commit message
Aim for future grepability. Peruse this guide to good commit messages.
Use of local variables
Most local variables are better off as extracted methods. Note: block parameters are exempt.
Methods longer than 1 line
Be deeply suspicious of methods longer than one line.
Methods longer than 5 lines
Methods should do only one thing. One thing should usually take fewer than 5 lines to do.
Making a long class longer
Follow the campsite rule: strive to leave code better than you found it. When you happen to work with a long class, take at least one small step to shrinking it.
Use of magic numbers
You're allowed to use two numbers in code: 0 and 1. Any others should be represented by a named constant.
Use of `||` or `&&` in a conditional
When you see `if foo && bar`, extract a method to explain what `foo && bar` really means.
Use of case or switch statement
It's hard to make a switch statement that does only one thing. They also tend to spread to other classes once created.
Passing a boolean parameter
Choosing a code path based on a boolean param is called control coupling, an unnecessarily high form of coupling.
Class name ending in Manager
"Manager" is a weasel word, conveying nothing. The more you want to call something a Manager, the more likely it is that your class has too many responsibilities.
Excessive fixture creation
Fee: $10/object created
Build the minimal fixture you need to excute your test. Avoid the database if at all possible by using doubles or unsaved instances.
Stubbing the system under test
Fee: $10/stubbed method
If you are testing the Foo class, you may not stub any methods on Foo. The more you want to, the more likely it is that you need to extract that behavior from Foo.
Verifying integration tests via database access
Integration tests should verify through the UI. Don't go peeking in the database.
One time in a thousand, a comment is warranted. Every other time you should improve the code until it doesn't need comments.
Comments containing TODO or FIXME
I like the occasional TODO comment in my branch, but I never merge them in. FIXME is a "fuck you" to your coworkers.
Fee: $50/"wtf" from code reviewer
Try really, really, really hard to name things well. Update and improve your names constantly as the system changes. Be eager to rename something if you've found a better choice.
Static or class methods
Fee: $100/attribute changed
Rather than mutating an existing record, can you create a new one and return that? Rather than delete something, can you record that a delete was requested? Rich Hickey has some worthy thoughts on this.
Class with multiple responsibilities
Fee: $200/extra responsibility
Classes should have just one responsibility or reason to change. Almost no one errs on the side of making their classes too small, but I'd love to see it. Shoot for that; your classes will still probably be too big.
Duplication in production code
There are virtually no rules in programming that should always be followed, but avoiding duplication comes pretty close. Duplication makes code hard to change, which is the worst quality code can have.
Duplication in test code
Programmers who would never ship major duplication in production code happily copy and paste all over their test files. Test code is not subordinate to production code; its quality is equally important. Perhaps even more so: maintaining a brittle test suite will bleed your enthusiasm dry.
Untested code is legacy code the instant it's born. It's unprofessional to write it.