What I learn from 008: book Robert Martin - Clean Code: A Handbook of Agile Software Craftsmanship

WARNING!

This is not a book review . There are many people who does book reviews . I am read book ,because … I want learn something ,so this is my loose thoughts and notes about what I learn from book .

This note will appear on my new blog soon.

WHAT I LEARN FROM :

Robert Martin's BOOK

Clean Code: A Handbook of Agile Software Craftsmanship 

CLEAN CODE is a legendary book. I should read this book few years back.
It is a best book to read and learn from after you graduate and write few projects .This book will help you point you into good directions to become a better developer.It is must read book ,if you are Java Developer.

So, what I learnt from this book ? A lot.
Below are notes of things that I should remember in future.Most of them are direct quotation from Clean Code’s book.

NAMING:

This is very challenging for me as English is not my native language. I am still working hard on improving my skills in naming. This book helps me a lot. Most valuable quotes are:

1. Boundary conditions are hard to keep track of. Put the processing for them in one place. Don’t let them leak all over the code. For example. We don’t want swarms of +1s and -1s everywhere. In this case boundary condition that should be encapsulated within a variable named something like previousXXX nextXXX
2. The name of a variable, function, or class, should answer all the big questions: why it exists, what it does, and how it is used.
3. Name must be descriptive, pronounceable and searchable. Use computer science and math terms, algorithm and pattern names and so on.
4. Pick one word for one abstract concept and stick with it. Why? Using inconsistent spellings is dis-information.
5. Names in software are 90 percent of what make software readable.

CLASSES AND FUNCTIONS:

Most of things that Martin mentioned to me in book are known for me , but example shows me how I should apply in my code.

1.  Functions should do one thing , they should do it well. They should do it only. Functions should either do something or answer something, but not both. 
2. Indent level of a function should not be greater than two.
3. The ideal number of arguments for a function is zero (niladic). Next comes one (monadic), When a function seems to need more than three arguments, it is likely that some of those arguments can be wrapped into a class of their own. It sounds like cheating, but it’s not. When groups of variables are passed together, they are likely part of a concept that deserves own name..
4. If one function calls another, they should be vertically close and the caller should be above the callee, if at all possible. It is known as dependent functions. 
5. Classes should have a small number of instance variables. Each of the methods of a class should manipulate one or more of those variables. In general the more variables a method manipulates the more cohesive that method is to its class. A class in which each variable is used by each method is maximally cohesive.

COMMENTS:

I am rarely write a comments . My aim for comments are explain hacky nature of code or explain why and reason of existence of this class. It seems my approach is ok and left some useful quotes that I usually try to follow.

1.  Comments are, at best, a necessary evil because programmers can’t realistically maintain them. 
2. Inaccurate comments are far worse than no comments at all. 
3. A comment may be used to amplify the importance of something
4. Don't comment bad code , rewrite it .
5. Comments should be reserved for technical notes about the code and design.

TEST:

I admit , I struggle with writing decent tests and doing TDD in the past . It was my aim in 2016 to be good at TDD and testing and I am happy that II made a lots progress but I haven’t write enough code to feel confident .I hope to get more opportunity in 2017.

1.  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. What makes a clean test? Three things. Readability, readability, and readability. Readability is perhaps even more important in unit tests than it is in production code. What makes tests readable? Clarity, Simplicity, and Density of expression If you don’t keep your tests clean, you will lose the very thing that keeps your production code flexible. It is unit tests that keep our code flexible, maintainable, and reusable. The reason is simple. If you have tests, you do not fear making changes to the code
2. Rules for clean tests based on FIRST rules: (FIRST is acronym for Fast, Independent , repeatable, SELF-VALIDATING, TIMELY)
1. Fast - Tests should be fast. 
2. Independent should not depend on each other. 
3. Repeatable - Tests should be repeatable in any environment.(it should run on production, QA and dev machine
4. Self-validating - The tests should have a boolean output. Either they pass or fail
5. 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. 
3. When you learn third-party APIs is a good to writes to understand how they work. These tests will come handy when you third-party APIs is updated so then you can run your tests to see is they break anything.. (Jim Newkirk calls such tests learning tests. )
4. Having dirty tests is as bad (if not worse) than, having no tests. （Dirty test means that it doesn't need follow quality standards and name convention)
5. Test boundary condition.
6. Exhaustively test near bugs. Bugs tend to congregate. When you find a bug in a function, it is wise to do an exhaustive test of that function. You’ll probably find that the bug was not alone.

GENERAL:

For end I left various important rules and tips to be a better developer that I am following or I want to follow to be a better developer.

1.  Duplication may be the root of all evil in software. I think, that’s explain why IDE like IntelliJ IDEA put lots of effort to detect duplication.
2. Team should agree to a single set of formatting rules and all members should comply. Why ? It helps to have an automated tool that can apply those formatting rules for you.
3. Treat try/catch as transactions. Your catch has to leave your program in a consistent state, no matter what happens in the try. For this reason it is good practice to start with a try-catch-finally statement when you are writing code that could throw exceptions. This helps you define what the user of that code should expect, no matter what goes wrong with the code that is executed in the try 
4. Wrapping third-party APIs is a good practice. When you wrap a third-party API, you minimize your dependencies upon it: You can choose to move to a different library in the future without much penalty. Wrapping also makes it easier to mock out third-party calls when you are testing your own code.
5. Many inexperienced programmers believe that the primary goal is to get the program working. Once it’s “working” they move on to the next task, leaving the “working” program in whatever state they finally got it to “work.” Most seasoned programmers know that this is professional suicide.
6. Use TDD to do changes step by step . One of the best ways to ruin a program is to make massive changes to its structure in the name of improvement. Some programs never recover from such “improvements.”.
7. Keeping code clean is relatively easy. If you made a mess in a module in the morning, it is easy to clean it up in the afternoon. Better yet, if you made a mess five minutes ago, it’s very easy to clean it up right now.
8. Refactoring is an iterative process full of trial and error, inevitably converging on something that we feel is worthy of a professional.
9. When you see commented-out code, delete it! Don’t worry, the source code control system still remembers it.
10. Building a project should be a single trivial operation.
11. Following “The Principle of Least Surprise,” any function or class should implement the behaviours that another programmer could reasonably expect.
12. Dead code (unused statement, method and so on) is a code that isn’t executed. Delete it (Don’t panic . VCS should remember it). The problem with dead code is that after awhile it starts to smell. The older it is, the stronger and sourer the odor becomes. This is because dead code is not completely updated when designs change. It still compiles, but it does not follow newer conventions or rules. It was written at a time when the system was different. When you find dead code, do the right thing.
13. Use Explanatory Variables . One of the more powerful ways to make a program readable is to break the calculations up into intermediate values that are held in variables with meaningful names.
14. Prefer Polymorphism to If/Else or Switch/Case
15. Replace Magic Numbers with Named Constants
16. Have a reason for the way you structure your code, and make sure that reason is communicated by the structure of the code. If a structure appears arbitrary, others will feel empowered to change it. If a structure appears consistently throughout the system, others will use it and preserve the convention
17. Single Responsibility Principle (SRP) states that a class or module should have one, and only one, reason to change. 
18. Use unchecked exception. 
19. Many people like Stephen Colebourne (author of joda time and one of the authors of time in Java) believe that using checked exception is bad because it breaks SPR principle . Streams in Java 8 doesn't support checked exception (you need wrap them with unchecked exception)

There is a last thing that I discover while I read this book . I made terrible mistake in the past that I learn how to write great things without understand reasons . It is something I will focus on from now.
You can find many talks by Robert Martin on Youtube. I recommend to watch all of them. They are super useful.