The main 3 rules of software development are: reuse, reuse, and reuse (aka. DRY, DRY, and DRY). DRY = Don’t Repeat Yourself. Do not reinvent the wheel multiple times. Reuse will make your code much more maintainable.

Other 3 important rules of software development: encapsulation, encapsulation, and encapsulation. This is one of the most effective ways of meeting the reuse rule above.

Use meaningful names. The name of a class, methode, or variable should cover what it is or does. Do spend some time on thinking of a meaningful name, as it will impact all the code you write afterward. See also the next rule.

Code should be self-explanatory. If you need to add javadoc or inline comments it usually means you have to refactor your code. Javadoc and even more so inline comments should be rare.

Always use a layers or hexagonal architecture. This wil make the internal dependencies and the flow through the code much clearer. This is a great tool in avoiding spaghetti code. Writing tests is usually also easier for code structured in this way.

Never swallow exceptions! Always handle them or pass them on.

Remember: code must be readable. Code is usually read many more times than written/updated.

Stick to the single concern principle: a class or method should only have one responsibility.

Javadoc should only be used for explaining why to use a class or method, not on how it works. The how should be clear from the self-explanatory code. And this should only be needed when this is not self-evident from its name, which should be rare, see rule above.

Use Test Driven Development (TDD) to ensure high test coverage.

All these rule apply to the main and to the test code.

Mock only your boundary classes, ie. mock as little as possible.

Write your own mocks, see Write your own mocks.

KISS (Keep It Simple Stupid). It is much more difficult, but also much more valuable, to find a simple solution instead of a complex one. Take the effort to simplify your initial solution.

Less is more: less code (basically a simpler solution) is usually more useful than more code. When you refactor code you usually end up with less code capable of doing more.

YAGNI, You Ain’t Gonna Need It. Removed unused code rigorously, even if it is nice code that looks like you may wanna use it in the near future. Do not feel emotionally attached to your code. Since it is not used it will outdate fast. It is just clutter.

Delete code when cleaning up code, do not put it in comments. To see old versions of your code use your vision control system (eg. Git).

Refactor all the time, no user story is done right in one attempt.

Use the boy scout rule: leave the code neater behind than it was before. So when working on your user story, also refactor some existing code related to your user story.

Use state as little as possible, ie. all beans should be stateless.

Fail fast: when something is wrong with given arguments or state throw an exception immediately. Do not try to be lenient and proceed anyway. Because that will usually just lead to a more complicated exception later on, with the root cause (the exception you did not throw earlier) gone.

Use unchecked exceptions only. Checked exception clutter your code too much. Very often you want your exception to be passed on. To make that easier it is convenient not having to add it the every method’s signature in the call chain.

Do not use nullable fields in composite database indexes or constraints. If a field needs to be in such an index use a special value to indicate it is not set, eg. when it is of type VARCHAR use 'UNKNOWN'. Rationale: different databases behave differently when comparing null value. Some say null matches nothing except other nulls, some say null matches nothing not even another null.