# General Practices

1. Follow standard conventions
2. Keep It SOLID Simple, Simpler is always better. Reduce complexity as much as possible
3. Boy scout rule, Leave the source code cleaner than you found it.
4. Always solve the root cause of the problem.
5. The code you written should be coding standard
6. Follow TDD as much as possible

# Naming
1. Choose descriptive unambiguous name, how long or short it is depends on the scope.
2. Make meaningful distinction
3. Use prounounceable and searchable names
4. Avoid Acronyms and confusing names
5. Replace Magic Numbers and Texts with named constants
6. Names should describe side effects

# Functions
1. Keep it small and short
2. It should only do One Thing
3. Use Descriptive names
4. Always always prefer fewer arguments (max 3)
5. No arguments should be used as an output
6. DO NOT USE FLAG/BOOLEAN as arguments.
7. Use Less switch statements.
8. Method That changes states should return void or throw exceptions (setters)
9. Method that doesn't changes state should return value(getters)
10. Avoid Duplication
11. Long methods means a class is hidden inside that method then you should refactor it.
12. Public method names are short and private are usually long and descriptive.

# Classes and Objects
Generally Objects hide the data abstraction and expose methods that operate the data.

1. The class name should represent its responsibility.
2. Should be small and do one thing.
3. Tell dont ask - It should tell what it does and should not ask how.
4. Less getter and setters
5. Hide internal structure.
6. More cohesive methods (one method changing state of many instance variables)
7. Expose less implementation so that we can use more OOPs and independent deploymentablility
8. Classes and Polymorphism are related (less switch statements)
9. Make good abstraction and encapsulation.
10. Prefer non-static methods to static methods.
11. Abstract should not know about concrete.
12. Object should have small number of instance variables.
13. Base class should know nothing about their derivatives.

# Comments
1. If you're thinking about writing a comment, then the code should be refactored.
2. Comments can be useful when placed in certain places
3. Commments should be rare ( common reasons for the comments is because the code is bad. )
4. Only by reading the code the next programmer should know what the code does
5. Every comment you write is failure to express your code
6. Comment lies and misinformation
7. Good Comments:
- Legal comments at top of the file (license).
- Informative comments: eg what a regex do.
- Warning and consequences.
- Public API document.
8. Bad Comments:
- Dont talk to yourself in the comment
- Redundant explanation.
- Journal Comments.
- Noise Comments, Banner comments .
- Closing brace comments.
- Attribution.
- HTML comments.
- Obsolete comment
- Commented out code, Remove it. We can always look at VCS
- They should not be used to indicate who changed or why, That should be in commits of VCS

# Refactoring
Process for refactoring should be as follow:
1. Write Test that fails
2. Make the test pass
3. Make the code better (Refactor)

**Guideline for refactoring:**
- Before making any kind of refactoring, it is important to have good coverage tests.
- After increasing or creating test coverage, you can begin to leave the clearest code and fix some bugs.
- Now, after leaving the code clearer, someone else can probably clean it even more.
- Follow TDD whenever wherever possible.

# Design rules
1. Keep configurable data at high levels.
2. Prefer polymorphism over to if/else or switch/case.
3. Prevent over-configurability.
4. Use dependency injection.
5. Recognize and separate the responsibilities of a system.

# Code Structure / Formatting
1. Formatting should indicate things of importance since it is a developer of communication form.
2. A messy code is hard to read.
3. The readability of the code will take effect on all of the changes that will be made.
4. Declare variables close to their usage
5. Dependent functions should be close
6. Similar Functions should be close
7. Place functions in a downward direction
8. Use White space to associate related things and diassociate weakly related
9. Don't break indentation

# Code ethics
- The code that only works is not enough to have a good code.
- Professionals who care only about the code that works cannot be considered professional.
- We should ignore that we have no time to refactor to one code. The code that was not taken care of today can become a problem after becoming a problem for the team because no one will want to mess with it.
- Try not to let the code rot. It is much cheaper to create a clean code than cleaning a rotten code, as a move in a tangle can be an arduous task.
- The solution, then, comes down to maintaining the cleanest code possible and as simply as possible without ever letting it begin to rot.
- Be consistent. If you do something a certain way,If others do something a certain way then do all similar things in the same way.