Points to remember
â€¢Make it easy to read,
â€¢Make the surrounding code clean,
â€¢Change one variable name for the better,
â€¢Break up one function thatâ€™s a little too large,
â€¢Eliminate one small bit of duplication,
â€¢Clean up one composite if statement.
â€¢Use meaningful names
â€¢Distinguish names in such a way that the reader knows what the differences offer
â€¢Use Pronounceable Names
â€¢Functions should be small. They should do one thing. They should do it well. They should do it only.
â€¢We want to read the code like a top-down narrative.
â€¢Use descriptive names for functions.
â€¢Switch statements should be buried deep in a low-level class and should never be repeated.
â€¢Use Descriptive names for the functions. The smaller and more focused a function is, the easier it is to choose a descriptive name.
â€¢For a function three or more arguments should be avoided. Ideal is zero arguments.
â€¢Flag arguments are ugly.
â€¢When a function needs more than two or three arguments then wrap the arguments into a class of their own.
â€¢Functions should either do something or answer something, but not both.
â€¢Extract the bodies of the try and catch blocks out into functions of their own.
â€¢Duplication may be the root of all evil in software. Many principles and practices have been created for the purpose of controlling or eliminating it.
â€¢Adding comments is not good as it shows your failure in writing an expressive code.
â€¢Either spend your time writing the comments that explain the mess youâ€™ve made or spend it cleaning that mess.
â€¢Donâ€™t Use a Comment When You Can Use a Function or a Variable
â€¢Comments are good only if they
â€“Meant for legal documentation
â€“Provide Informative value for a complex regular expression or formula
â€“Explain the intent or business requirement
â€“Clarify the third party library or API usage
â€“Warn about consequences
â€“Denote TODO tasks
â€“Amplify the importance of something
â€¢Code formatting is about communication, and communication is the professional developerâ€™s first order of business
â€¢A team of developers should agree upon a single formatting style, and then every member of that team should use that style.
â€¢The reader needs to be able to trust that the formatting gestures he or she has seen in one source file will mean the same thing in others.
â€¢Vertical Size: Small files are usually easier to understand than large files are
â€¢Source file should appear like a newspaper article.
â€¢Horizontal Size: Strive to keep our lines short