Don’t count on others to test.

Do your job and be responsible.

Test everything you write and review. All of the code you work on, whether you are the primary developer, the pairing partner, or the code reviewer, you need to test. Be responsible for all the code you are participate in.

It’s extremely bad behavior to depend on others to test. This usually results in certain parts of the code not being tested, and bugs introduced into the production code base. And then you’re no longer delivering working software. And if your’e not going to deliver working software, then why are you here?

It’s your job to ensure the quality of your code. Own it.

Testing can find bugs, but it can’t prove the absence of bugs.

It can certainly find bugs, but it is not proof that all is well.

Getting all green lights on a test suite does not necessarily mean that everything is okay. It is quite possible for bugs to still exist in a system, even when the code coverage is quite extensive.

Still, it is worth trying to cover all the known cases. More coverage and test cases is better than less.

You just have to remain vigilant. Don’t put all your faith in the testing machine.

Never ignore an error.

You can’t simply pretend it didn’t happen.

Silent failures will screw you over. They will lead to corrupt data in the system, and it will be incredibly hard to track down the source of the corruption. It can also lead to huge financial losses as well.

If you can’t handle the error, signal the failure up to the calling method. The buck has to stop somewhere. Pretending things will be okay is a major rookie mistake.

Comments should discuss the current functionality.

Don’t let your comments ramble on about the past or future.

Don’t have comments describing what a function used to do. That information is in the version control. Instead, the comments should only discuss why the current functionality is the way it is.

Similarly, don’t speculate on the future. You don’t know what the future business requirements will be. (cf. YAGNI)

When you update your code, update the comments as well. Don’t turn the comments into lies.

Don’t use comments as version control.

Instead, use version control software, like git.

Some developers leave blocks of commented-out code. Maybe that’s the previous version of the code, or maybe it’s the future version. In worse cases, multiple versions are commented out. This confuses the reader greatly.

Blocks of commented-out code are confusing, misleading, and trouble. Someone will uncomment the code and reintroduce it at the wrong time. It will lead to bugs and faults.

If you don’t need code anymore, delete it. Deleted code has fewer bugs.

And if you really need to look back at prior versions, they are available in the git history.

Avoid comments at the end of a code block.

Your block is probably too big.

If you feel the need to put comments at the end of a block of code then your block of code is probably too big. Some developers put this at the end of for and while loops to indicate which block is actually ending. If this isn’t obvious at a glance, then your block is probably too long.

Extract out the logic in the block to a method. This will make it a lot smaller, or possibly eliminate the need for a block altogether. It’s okay to have more methods, the code will be more readable this way. Plus, the new methods can be tested separately.

Also, never trust the comment you see at the end of a block. Errors in coding or later changes can turn such a comment into a lie.

Comments cannot enforce types or usage.

Use code for this.

Don’t make a comment saying a variable should be a certain type. Although the statement is true, this will lead to bugs when the “rule” is violated.

Enforce rules with types, objects, assertions, logic, and other code constructs. Make the code work at validating itself.

Note this doesn’t apply to some annotations, these actually work. These are a special kind of comment that gets read by the preprocessor and turned into code.

Don’t make local versions.

Avoid making local versions of third party or open source tools and libraries.

You won’t be able to keep up with maintenance release, bug fixes, security enhancements, and so on. The overhead of trying to keep these tools in sync with current versions will require development efforts that most teams do not have the resources for.

Instead, use the provided versions from the source. Extend the library with a wrapper. Do not modify the library. This is also an example of the Open/Closed Principle.

Don’t repeat code logic in the comments.

Logic should appear in only one place.

Keep it DRY: don’t repeat yourself.

Comments should explain why, not what or how. If the reader needs to know what the formula is for this code, they should look at the source code, not the comments. If they want to know why that algorithm was chosen over some other, then they should find that answer in the comments.