The document discusses principles and best practices for writing clean code, including keeping functions small and focused on a single task, using descriptive names, avoiding duplication, minimizing comments by writing expressive code, and agreeing on consistent formatting styles within a team. It emphasizes writing code that is easy to read and understand through applying these guidelines.

1. Clean Code
Prepared By : Smita Prasad

2. 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

3. Functions
• 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.

4. Comments
• 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

5. Formatting
• 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

6. Thanks