Clean Code Notes

Book link:

https://drive.google.com/file/d/152TG4Qg8r4Vcw0utQuTbWN-zed8gJiwm/view

Chapter 17 : Smells & Heuristics- IMPORTANT

 MEANINGFUL NAMES : 

1] Choosing good names takes time but saves more than it takes. So take care with your names and change them when you find better ones.

2] Names should be meaninful , pronouncable and explain why they are created.

3] Class and Object Names should be a Noun and never a Verb .

eg - customer , manager etc

4] Method names should be a Verb.

eg - postpayment() , savepage etc

5]  Pick one word for one abstract concept and stick with it. For instance, it’s confusing to have fetch, retrieve, and get as equivalent methods of different classes.

6] Don’t be afraid to make a name long. A long descriptive name is better than a short enigmatic name.

-----------------------------------------------------------------

FUNCTIONS : 

1]  The first rule of functions is that they should be small.

2] A FUNCTION SHOULD SHOULD DO ONE THING ONLY .

3] Try avoiding writing arguments always , Ideal number of arguments for a function is ZERO.

4] AVOID CODE DUPLICATION !

-----------------------------------------------------------------

COMMENTS : 

Comments are always failures. We must have them because we cannot always figure out how to express ourselves without them,but their use is not a cause for celebration.

Clear and expressive code with few comments is far superior to cluttered and complex code with lots of comments.

1] Make a Comment Short , precise and To the POINT without any misleading /false  information.

-----------------------------------------------------------------

FORMATTING : 

1] Keep the Source files small and avoid making any one source file too large.

2] WRITE CODE LIKE A NEWSPAPER.

The name, by itself, should be sufficient to tell us whether we are in the right module or not. The topmost parts of the source file should provide the high-level concepts and algorithms. Detail should increase as we move downward, until at the end we find the lowest level functions and details in the source file.

3] Nearly all code is read left to right and top to bottom.

4] Lines of code that are tightly related should appear vertically dense. Concepts that are closely related should be kept vertically close to each other

5] INDENTATION IS IMPORTANT

6] Every programmer has his own favorite formatting rules, but if he works in a team, then the team rules. A team of developers should agree upon a single formatting style.

-----------------------------------------------------------------

ERROR HANDLING : 

Error handling is important, but if it obscures logic, it’s wrong.

Back in the distant past there were many languages that didn’t have exceptions. In those languages the techniques for handling and reporting errors were limited. You either set an error flag or returned an error code that the caller could check.

The problem with these approaches is that they clutter the caller. The caller must check for errors immediately after the call. Unfortunately, it’s easy to forget. For this rea- son it is better to throw an exception when you encounter an error. The calling code is cleaner. Its logic is not obscured by error handling.

1]  Returning null from methods is bad, but passing null into methods is worse.

-----------------------------------------------------------------

UNIT TESTS : 

Test code is just as important as production code. It is not a second-class citizen. It requires thought, design, and care. It must be kept as clean as production code.

Test One fucntionality at a Time 

The Three Laws of TDD :

First Law : 

You may not write production code until you have written a failing unit test.

Second Law : 

You may not write more of a unit test than is sufficient to fail, and not com-piling is failing.

Third Law : 

You may not write more production code than is sufficient to pass the cur-rently failing test.

F.I.R.S.T.

Clean tests follow five other rules that form the above acronym:

Fast Tests should be fast. They should run quickly. When tests run slow, you won’t want to run them frequently.

Independent Tests should not depend on each other. One test should not set up the condi-tions for the next test. You should be able to run each test independently and run the tests in any order you like.

Repeatable Tests should be repeatable in any environment. You should be able to run the tests in the production environment, in the QA environment, and on your laptop while riding home on the train without a network.

Self-Validating The tests should have a boolean output. Either they pass or fail. You should not have to read through a log file to tell whether the tests pass. You should not have to manually compare two different text files to see whether the tests pass.

Timely The tests need to be written in a timely fashion. Unit tests should be written just before the production code that makes them pass. If you write tests after the production code, then you may find the production code to be hard to test.

-----------------------------------------------------------------

CLASSES : 

A class should begin with a list of variables. Pub-lic static constants, if any, should come first. Then private static variables, followed by pri-vate instance variables.

------------------------------------------------------------------