back to homepage

Chapter 1: Clean Code


Entity count and size

Two parts from Ron Jeffries description of clean code stood out to me. On page 10

In priority order, simple code: […] Minimizes the number of entities such as classes, methods, functions and the like — Ron Jeffries

and on the next page

I also look at whether an object or method is doing more than one thing. If it’s an object, it probably needs to be broken into two or more objects. If it’s a method. I will always use Extract Method refactoring on it, […] — Ron Jeffries

That is a very interesting opposition and probably at the center of this ongoing discussion about what “clean code” should mean. I find myself more on the “minimize the number of entities” end of that spectrum, while the programmers quoted in this chapter, including the author, are most likely on the “break things down into things” end.

Maybe none of the poles should be headed towards or used as an indicator. And I don’t mean an unoffensive and lame “find a balance” approach. I think clean code will result in many entities in one code base, but very few large ones in another. A fitting design needs to be chosen for every project and that design will result in however many entities in whatever sizes they need to be.

Schools of thought

Indeed many of the recommendations in this book are controversial. You will probably not agree with all of them. You might violently disagree with some of them. That’s fine. We can’t claim final authority. — page 13

I will still reserve my right to be mad. While I never had to work with a “clean code elitist” I heard those people do exist and treat this book like a bible. Now that the diplomatic “every one is entitled to their own opinion” disclaimer is out of the way, I expect some opinionated statements with absolutes.

I actually prefer this type of writing style but I think this is exactly what causes readers to treat your work like a bible rather than a base for discourse.

IDE playback

The vast majority of the playback was scrolling and navigating to other modules! — page 13

That might be foreshadowing for a strong opinion of mine about splitting classes and methods.