Each language and technology has its own set of guidelines that recommend programming style and practices. Follow these rules instead of not following any rules or inventing custom ones.
Always use English names for variables, functions, classes etc. and for writing comments.
The names should reveal intentions. What the variable is for, what the function is doing.
Good function or class should be responsible for doing just one thing. If it is doing more, then it should be possible to extract a separate function or class out of it.
A piece of code, i.e. a function or a program, should fail as soon as an unrepairable erroneous condition is encountered.
All user input should be validated as soon as it enters the system. Input data should be checked for syntactic errors and context-free rule violations.
Comments can be useful for explaining why a part of code was created, not what it is doing.
Commented out code should never be committed to the repository. It should be removed.
When you commit a TODO/FIXME comment always create a new issue in the project issue tracker. A link to the issue should be added to the source code comment.
Catch an exception only when you want to handle it, to add contextual information or to throw another exception instead.
Certain tasks an application realizes need to be performed differently depending on the environment. Such tasks shouldn’t be implemented in an environment-specific way.
Use value wrappers instead of raw types to represent domain values that are constrained or express value and unit.
Use generic exception handler at top-level of the application to capture any exceptions that haven’t been handled on lower levels.