A couple of days ago I finished reading the wonderful book by Robert Martin "Clean code". Despite all examples were on Java I dived into code in the book with a big pleasure. Robert explains things any developer should know and use every day. Closer to the end of the book he formulates all rules he told about as short and clear "code smells".
By my opinion most important of them are:
1. Understandable names of entities.
The classes, methods, variables and all entities in a code should (even must:) have good names. These names should clearly show the idea and purpose of current entity. The developer has to spent some time to choose good names. And don't be afraid to go back in code and change name if he came up with something better. Our days it's easy to do such things. I use Visual Studio + Resharper and don't have any problems with renaming.
The new thing that I learned from this book was that then bigger the area of visibility for variable then more long and detailed its name should be. Actually the idea is quite clear. When we use the variables just as counter for cycle it doesn't make much sense to give them long names. It can be even annoying to read code with such cycle's counters, so everybody use short names here. But now I see that this is just separate case of more general rule: more the area of visibility - more detailed name of variable. That's quite logically.
If there are standards of naming in company you work for - use them. If not - use general standards and common sense. To invent a bicycle is not the best idea. Extravagant or funny names can be good for you (if you are the only reader of code) but developer has to think about people which are going to read this code. Not everybody have the same sense of humor :) And not everybody want to spent time trying to figure out what the name "show_me_the_power" means (this is the name of variable from real code I worked with when I was in web development. Yep, my colleague was funny guy :)).
2. Separate different logic levels
That means to divide more and less abstract things and don't mess them up in one class\method.
That wouldn't be nice to have in one methods things like showing of some data to user and realization of some low level algorithm.
3. Move unobvious things to separate methods or involve additional variables
I know people that really like calculations and constructions which take several lines. I can't see such code without tears. It takes time to understand what author meant. Would be great to make the live a little bit easier at once, devide such long calculations to separate pieces and move them to separate variable or even methods
4. Write unit tests
This is very clear thing. Tests help a lot to catch mistakes after changes in code.
And they help to improve the structure of code. The using of dependency injection and inversion of control will come itself if developer thinks about tests in the very begining.
On the other hand here (as probably everywhere) fanatism is not required. Robert claims that developer should cover with tests as many lines of code as possible. I believe that the balanse is more important then to follow the rules blindly. If the deadline is almost here and a customer waits for his prototype, it's not time to care about 100% code covering. :) But production code requires tests of course.
There were much more smells mentioned in that book. Some of them are obvious, some - not. Anyway books like this should be read by developers from time to time. It helps to look at things wider.
If there are standards of naming in company you work for - use them. If not - use general standards and common sense. To invent a bicycle is not the best idea. Extravagant or funny names can be good for you (if you are the only reader of code) but developer has to think about people which are going to read this code. Not everybody have the same sense of humor :) And not everybody want to spent time trying to figure out what the name "show_me_the_power" means (this is the name of variable from real code I worked with when I was in web development. Yep, my colleague was funny guy :)).
2. Separate different logic levels
That means to divide more and less abstract things and don't mess them up in one class\method.
That wouldn't be nice to have in one methods things like showing of some data to user and realization of some low level algorithm.
3. Move unobvious things to separate methods or involve additional variables
I know people that really like calculations and constructions which take several lines. I can't see such code without tears. It takes time to understand what author meant. Would be great to make the live a little bit easier at once, devide such long calculations to separate pieces and move them to separate variable or even methods
4. Write unit tests
This is very clear thing. Tests help a lot to catch mistakes after changes in code.
And they help to improve the structure of code. The using of dependency injection and inversion of control will come itself if developer thinks about tests in the very begining.
On the other hand here (as probably everywhere) fanatism is not required. Robert claims that developer should cover with tests as many lines of code as possible. I believe that the balanse is more important then to follow the rules blindly. If the deadline is almost here and a customer waits for his prototype, it's not time to care about 100% code covering. :) But production code requires tests of course.
There were much more smells mentioned in that book. Some of them are obvious, some - not. Anyway books like this should be read by developers from time to time. It helps to look at things wider.
Комментариев нет:
Отправить комментарий