Comments should be reserved for technical notes about the code and design
If you find an obsolete comment, it is best to update it or get rid of it as quickly as possible
A comment is redundant if it describes something that adequately describes itself
If you are going to write a comment, take the time to make sure it is the best comment you can write
When you see commented-out code, delete it! Don’t worry, the source code control system still remembers it.
Building a project should be a single trivial operation.
You should be able to run all the unit tests with just one command.
More than three is very questionable and should be avoided with prejudice.
Readers expect arguments to be inputs, not outputs.
Boolean arguments loudly declare that the function does more than one thing.
Methods that are never called should be discarded.
We should take pains to minimize both the number and extent of extra languages in our source files.
The Principle of Least Surprise If the code surprisingly do something else than expected, users of code lose their trust in the original author and must fall back on reading the details of the code
Don’t rely on your intuition. Look for every boundary condition and write a test for it.
Turning off safety inspections may be soothing at first. but will result endless debugging sessions
Don't repeat yourself (DRY)
Don't mix lower level and higher level of abstractions. separate them into good components.
base classes should know nothing about their derivatives.
Expose as little information as possible.
Dead code is code that isn’t executed.
Related codes must have least vertical distance from each other.
Stick to your conventions across codebase.
Redundant and unused codes makes clutter
artificial coupling is a coupling between two modules that serves no direct purpose.
Reaching other objects internals in a function.
Passing argument to a function in order to select the behavior of the function.
Using notations and symbols to shorten code would obscure our intent to reader.
Code should be placed where a reader would naturally expect it to be.
Prefer using nonstatic methods instead of static methods.
Intermediate variables make it obvious what the outputs are.
If you have to look at the implementation (or documentation) of the function to know what it does, then you should work to find a better name or rearrange the functionality.
Writing function to just work is not enough, make sure you understand how it works.
If one module depends upon another, that dependency should be physical, not just logical. The dependent module should not make assumptions (in other words, logical dependencies) about the module it depends upon. Rather it should explicitly ask that module for all the information it depends upon.
There may be no more than one switch statement for a given type of selection. The cases in that switch statement must create polymorphic objects that take the place of other such switch statements in the rest of the system.
Every team should follow a coding standard based on common industry norms.
it is a bad idea to have raw numbers in your code.
Ambiguities and imprecision in code are either a result of disagreements or laziness.
Enforce design decisions with structure over convention.
Extract functions that explain the intent of the conditional.
Negatives are just a bit harder to understand than positives.
It is often tempting to create functions that have multiple sections that perform a series of operations.
G31: Hidden Temporal Couplings
Make the temporal coupling explicit by returning result from functions and putting as argument for next operation.
Have a reason for the way you structure your code, and make sure that reason is communicated by the structure of the code.
Boundary conditions are hard to keep track of. Put the processing for them in one place.
Mixing multiple levels of abstraction make's code harder to understand and change.
If you have a constant such as a default or configuration value that is known and expected at a high level of abstraction, do not bury it in a low-level function.
In general, we don’t want a single module to know much about its collaborators. More specifically, if A collaborates with B, and B collaborates with C, we don’t want modules that use A to know about C.
If you use two or more classes from a package, then import the whole package with wildcards.
Instead of inheriting constants from interfaces, you can use static import
Prefer using enums instead of constants.
Don’t be too quick to choose a name. Make sure the name is descriptive. your name must be pretty much what reader expect it to do.
Don’t pick names that communicate implementation; choose names the reflect the level of abstraction of the class or function you are working in.
Names are easier to understand if they are based on existing convention or usage.
Choose names that make the workings of a function or variable unambiguous.
The longer the scope of the name, the longer and more precise the name should be.
Keep your names free of Hungarian pollution.
Don’t hide side effects with a name. Don’t use a simple verb to describe a function that does more than just that simple action.
The tests are insufficient so long as there are conditions that have not been explored by the tests or calculations that have not been validated.
Coverage tools reports gaps in your testing strategy.
They are easy to write and have high documentary value.
Sometimes we are uncertain about a behavioral detail because the requirements are unclear.
often get the middle of an algorithm right but misjudge the boundaries.
You’ll probably find that the bug was not alone.
Sometimes just seeing the pattern of red and green on the test report is enough to spark the “Aha!” that leads to the solution.
Looking at the code that is or is not executed by the passing tests gives clues to why the failing tests fail.
do what you must, to keep your tests fast.