I am finally done , reading this book ”Clean Code: A Handbook of Agile Software Craftsmanship” by Robert C. Martin.

It was an excellent read.
I think it has changed the way I will look at software development in future…

It’s a collection of very practical advice- difficult to argue. Most of the stuff is what you have realized at some point or other while programming. reading it in the print- gives words to those thoughts

The projects in this book – I skipped. I am sure they are good and effective way of putting this in practice- but I would rather read the code that I have written and look for smells there.

There were only two things that I didn’t agree with
One: On TDD. I cant reconcile to the way of programming the way as prescribed by TDD. Its way too much for me
Second: Importing java classes by using * rather than importing classes by specific names
I like to use specific class names- it keeps the dependencies well defined rather than keep them generic. It also makes it easier to search for dependencies by using plain search rather than using IDE.

And with all these fancy editors- its so easy to collapse the imports and remove the ones which are not needed

And if need be – you can clearly see what is is the dependency network (without running a heart-stopping dependency search on your IDE)

Finally- I am not sure why the book has Agile in the title

All advice was practical and mostly from the trenches- right at the code level.

I see no reason why the suggestions in this book cant be adopted by someone using Waterfall methodology or any other process.

I did skip some chapters though- 14,15,16. These were detailed case studies and I didn’t feel the need to read them. Reading lines of code in books doesn’t cut it for me

Who would I recommend this book to ?
Any one who is a coder.
Though I am not sure if someone who is still in school would be able to appreciate this as much
You need to have seen the blood on the streets to be able to appreciate the walk around the park.

For review of all chapters- please see this post.

 

This is review of the 17th and the final chapter from the book-”Clean Code: A Handbook of Agile Software Craftsmanship” by Robert C. Martin.

This is the final chapter of this book.
Smell of a bad code is something that would trigger your senses to take a second look.
Some of these are plain good advice.

This chapter effectively summarizes all that was discussed before- gives you a pat on the back and you are on your own !!!

Comments

C1: Inappropriate Information
C2: Obsolete Comment
C3: Redundant Comment
C4: Poorly Written Comment
C5: Commented-Out Code

Environment

E1: Build Requires More Than One Step
E2: Tests Require More Than One Step

Functions

F1: Too Many Arguments
F2: Output Arguments
F3: Flag Arguments
F4: Dead Function

General

G1: Multiple Languages in One Source File
G2: Obvious Behavior Is Unimplemented
G3: Incorrect Behavior at the Boundaries
G4: Overridden Safeties
G5: Duplication
G6: Code at Wrong Level of Abstraction
G7: Base Classes Depending on Their Derivatives
G8: Too Much Information
G9: Dead Code
G10: Vertical Separation
G11: Inconsistency
G12: Clutter
G13: Artificial Coupling
G14: Feature Envy
G15: Selector Arguments
G16: Obscured Intent
G17: Misplaced Responsibility
G18: Inappropriate Static
G19: Use Explanatory Variables
G20: Function Names Should Say What They Do
G21: Understand the Algorithm
G22: Make Logical Dependencies Physical
G23: Prefer Polymorphism to If/Else or Switch/Case
G24: Follow Standard Conventions
G25: Replace Magic Numbers with Named Constants
G26: Be Precise
G27: Structure over Convention
G28: Encapsulate Conditionals
G29: Avoid Negative Conditionals
G30: Functions Should Do One Thing
G31: Hidden Temporal Couplings
G32: Don’t Be Arbitrary
G33: Encapsulate Boundary Conditions
G34: Functions Should Descend Only
One Level of Abstraction
G35: Keep Configurable Data at High Levels
G36: Avoid Transitive Navigation

Java

J1: Avoid Long Import Lists by Using Wildcards
J2: Don’t Inherit Constants
J3: Constants versus Enums

Names

N1: Choose Descriptive Names
N2: Choose Names at the Appropriate Level of Abstraction
N3: Use Standard Nomenclature Where Possible
N4: Unambiguous Names
N5: Use Long Names for Long Scopes
N6: Avoid Encodings
N7: Names Should Describe Side-Effects

Tests

T1: Insufficient Tests
T2: Use a Coverage Tool!
T3: Don’t Skip Trivial Tests
T4: An Ignored Test Is a Question about an Ambiguity
T5: Test Boundary Conditions
T6: Exhaustively Test Near Bugs
T7: Patterns of Failure Are Revealing
T8: Test Coverage Patterns Can Be Revealing
T9: Tests Should Be Fast

For review of other chapters- please see this post.

 

This is review of the 14th chapter from the book-”Clean Code: A Handbook of Agile Software Craftsmanship” by Robert C. Martin.

This is the third project in the book. Robert carefully dissects a class SerialDate – part of JCommon Library

He follows the same principle exhibited before

First make it right- then make it work

And there is also a humbling message in this chapter

All code can be bettered. Review by another developer should be taken in stride and with humility.It takes courage to put your code for public scrutiny – just like artists ,authors do every day when their work is criticized and minutely looked at by experts and laymen

For review of other chapters- please see this post.

© 2011 Technology Cafe Suffusion theme by Sayontan Sinha