Robert Martin’s “Clean Code” is an incredibly useful book which helps write code that Fits In Your Head, and, so far, is the closest to making your code look like instructions for an AI instead of random incantations directed at an elder being.
The principle that the author of this article argues against seems to be the very principle which helps abstract away the logic which is not necessary to understand the method.
Tells me all I need to know about what the method does - it calculates default commissions, and, if there are extra commissions, it calculates those, too. It doesn’t matter if there’s 30 private methods inside the class because I don’t read the whole class top to bottom.
Instead, I may be interested in how exactly the extra commissions are calculated, in which case I will go one level down, to the calculateExtraCommissions() method.
From a decade of experience I can say that applying clean code principles results in code which is easier to work with and more robust.
Edit:
To be clear, I am not condoning the use of global state that is present in some examples in the book, or even speaking of the objective quality of some of the examples. However, the author of the article is throwing a very valuable baby with the bathwater, as the actual advice given in the book is great.
I suppose that is par for the course, though, as the aforementioned author seems to disagree with the usefulness of TDD, claiming it’s not always possible…
Tells me all I need to know about what the method does
No, it only tells you what the method is supposed to do.
While that may be helpful it may also be misleading. It helps just as much as comments when debugging - and that probably is the most relevant reason for trying to figure out someone else’s code.
It also tells you nothing about the data flow or the data at all. What do these functions do? What data to they act on? It is all just pure side effects and they could be doing anything at all. That is far from what I consider clean.
“Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowchart; it’ll be obvious.” – Fred Brooks, The Mythical Man Month (1975)
Folks really trying to argue about example code. Even created “global state” straw man. Here is secret - if you are using global state then code is shit in the most cases.
As it happens, it’s just an example to illustrate specifically the “extract to method” issues the author had.
Of course, in a real world scenario we want to limit mutating state, so it’s likely this method would return a Commission list, which would then be used by a Use Case class which persists it.
I’m fairly sure the advice about limiting mutating state is also in the book, though.
At the same time, you’re likely going to have a void somewhere, because some use cases are only about mutatimg something (e.g. changing something in the database).
It’s not nitpicking, stuff like this is far more impactful than choosing between 5 lines vs 10 lines long methods, or whether the hasExtraCommissions “if” belongs inside or outside of calculateExtraCommissions. This kind of thing should immediately jump out at you as a red flag when you’re reading code, it’s not something to handwave away as a detail.
I never claimed it’s not important, I’m just saying it’s not relevant here, as there is no context to where this method was put in the code.
As I said, it might be top-level. You have to mutate state somewhere, because that’s what applications ultimately do. You just don’t want state mutations everywhere, because that makes bad code.
The whole book is like this, though, and these are specifically supposed to be examples of “good” code. The rewritten time class toward the end, a fully rewritten Java module, is a nightmare by the time Martin finishes with it. And I’m pretty sure it has a bug, though I couldn’t be bothered to type the whole thing into an editor to test it myself.
in which case I will go one level down, to the calculateExtraCommissions() method.
In which case you will discover that the calculateExtraCommissions() function also has the same nested functions and you eventually find six subfunctions that each calculate some fraction of the extra commission, all of which could have been condensed into three lines of code in the parent function.
Following the author’s idea of clean code to the letter results in a thick and incomprehensible function soup.
If there are 6 subfunctions, that means there’s 6 levels of abstraction (assuming the method extraction was not done blindly), which further suggests that maybe they should actually be part of a different class (or classes). Why would you be interested in 6 levels of abstraction at once?
But we’re arguing hypotheticals here. Of course you can make the method implementations a complete mess, the book cannot guarantee that the person applying the principles used their brain, as well.
Six levels of abstractions, sure, if you have that many, you may want 6 functions. But that contradicts Martin when he’s saying that there should be one line in an if, and everything more should be promoted to its own function. There’s no way a programmer routinely writes code so terse that you get six levels of abstraction in a dozen of lines of code. Otherwise, Martin doesn’t understand what an abstraction is.
Managing a stack in your head like a computer is very challenging as far as cognitive load is concerned. You don’t want to jump all over the place. Otherwise, when you reach your destination, you end up forgetting what got you here in the first place.
This form of code fragmentation makes debugging an absolute nightmare, and finding sources of mutation absurdly frustrating. Good tooling can help you track where a variable is used and in which order mutations happen trivially in code in a single function. It’s not as as helpful when it’s spread all over the place. You can infer so much less statically if you follow Martin’s advice.
I’m not advocating for 1000-lines functions here, mind you. When functions become too big, other challenges arise. What’s necessary is balance, which Martin’s book fails to teach.
Because abstractions leak. Heck, abstractions are practically lies most of the time.
What’s the most time-consuming thing in programming? Writing new features? No, that’s easy. It’s figuring out where a bug is in existing code.
How do abstractions help with that? Can you tell, from the symptoms, which “level of abstraction” contains the bug? Or do you need to read through all six (or however many) “levels”, across multiple modules and functions, to find the error? Far more commonly, it’s the latter.
And, arguably worse, program misbehavior is often due to unexpected interactions between components that appear to work in isolation. This means that there isn’t a single “level of abstraction” at which the bug manifests, and also that no amount of unit testing would have prevented the bug.
How do abstractions help with that? Can you tell, from the symptoms, which “level of abstraction” contains the bug? Or do you need to read through all six (or however many) “levels”, across multiple modules and functions, to find the error?
I usually start from the lowest abstraction, where the stack trace points me and don’t need to look at the rest, because my code is written well.
I hate reading code like this. It means that there is a bunch of object or global state that could be getting modified by anything all over the place that I can’t see just by looking at the method. In other words, if you say you understand this method, it is because you are making assumptions about other code that might be wrong.
I’ll take a 30 line pure function over a web of methods changing member state every time.
It makes me sad to see people upvote this.
Robert Martin’s “Clean Code” is an incredibly useful book which helps write code that Fits In Your Head, and, so far, is the closest to making your code look like instructions for an AI instead of random incantations directed at an elder being.
The principle that the author of this article argues against seems to be the very principle which helps abstract away the logic which is not necessary to understand the method.
public void calculateCommissions() { calculateDefaultCommissions(); if(hasExtraCommissions()) { calculateExtraCommissions(); } }Tells me all I need to know about what the method does - it calculates default commissions, and, if there are extra commissions, it calculates those, too. It doesn’t matter if there’s 30 private methods inside the class because I don’t read the whole class top to bottom.
Instead, I may be interested in how exactly the extra commissions are calculated, in which case I will go one level down, to the
calculateExtraCommissions()method.From a decade of experience I can say that applying clean code principles results in code which is easier to work with and more robust.
Edit:
To be clear, I am not condoning the use of global state that is present in some examples in the book, or even speaking of the objective quality of some of the examples. However, the author of the article is throwing a very valuable baby with the bathwater, as the actual advice given in the book is great.
I suppose that is par for the course, though, as the aforementioned author seems to disagree with the usefulness of TDD, claiming it’s not always possible…
I really dislike code like that. Code like that tends to lie about what it says it does and have non-explicit interactions/dependencies.
The only thing I can really be certain from that is:
doAnything(); if(doAnything2()) { doAnything3(); }I.e. almost nothing at all because the abstractions aren’t useful.
You realize this is just an argument against methods?
All methods? Of course not. Just methods like these.
No, it only tells you what the method is supposed to do.
While that may be helpful it may also be misleading. It helps just as much as comments when debugging - and that probably is the most relevant reason for trying to figure out someone else’s code.
It also tells you nothing about the data flow or the data at all. What do these functions do? What data to they act on? It is all just pure side effects and they could be doing anything at all. That is far from what I consider clean.
Folks really trying to argue about example code. Even created “global state” straw man. Here is secret - if you are using global state then code is shit in the most cases.
It’s not a strawman, though, because Martin’s actual example code in the book is like this, including a full module he rewrites toward the end.
Why is it a
voidmethod? This only tells me that some state is mutated somewhere, but the effect is neither visible nor documented.I would expect a function called “calculate” to just return a number and not have any side effects.
You’re nitpicking.
As it happens, it’s just an example to illustrate specifically the “extract to method” issues the author had.
Of course, in a real world scenario we want to limit mutating state, so it’s likely this method would return a
Commissionlist, which would then be used by a Use Case class which persists it.I’m fairly sure the advice about limiting mutating state is also in the book, though.
At the same time, you’re likely going to have a void somewhere, because some use cases are only about mutatimg something (e.g. changing something in the database).
It’s not nitpicking, stuff like this is far more impactful than choosing between 5 lines vs 10 lines long methods, or whether the
hasExtraCommissions“if” belongs inside or outside ofcalculateExtraCommissions. This kind of thing should immediately jump out at you as a red flag when you’re reading code, it’s not something to handwave away as a detail.I never claimed it’s not important, I’m just saying it’s not relevant here, as there is no context to where this method was put in the code.
As I said, it might be top-level. You have to mutate state somewhere, because that’s what applications ultimately do. You just don’t want state mutations everywhere, because that makes bad code.
The whole book is like this, though, and these are specifically supposed to be examples of “good” code. The rewritten time class toward the end, a fully rewritten Java module, is a nightmare by the time Martin finishes with it. And I’m pretty sure it has a bug, though I couldn’t be bothered to type the whole thing into an editor to test it myself.
In which case you will discover that the calculateExtraCommissions() function also has the same nested functions and you eventually find six subfunctions that each calculate some fraction of the extra commission, all of which could have been condensed into three lines of code in the parent function.
Following the author’s idea of clean code to the letter results in a thick and incomprehensible function soup.
It’s only as incomprehensible as you make it.
If there are 6 subfunctions, that means there’s 6 levels of abstraction (assuming the method extraction was not done blindly), which further suggests that maybe they should actually be part of a different class (or classes). Why would you be interested in 6 levels of abstraction at once?
But we’re arguing hypotheticals here. Of course you can make the method implementations a complete mess, the book cannot guarantee that the person applying the principles used their brain, as well.
Six levels of abstractions, sure, if you have that many, you may want 6 functions. But that contradicts Martin when he’s saying that there should be one line in an if, and everything more should be promoted to its own function. There’s no way a programmer routinely writes code so terse that you get six levels of abstraction in a dozen of lines of code. Otherwise, Martin doesn’t understand what an abstraction is.
Managing a stack in your head like a computer is very challenging as far as cognitive load is concerned. You don’t want to jump all over the place. Otherwise, when you reach your destination, you end up forgetting what got you here in the first place.
This form of code fragmentation makes debugging an absolute nightmare, and finding sources of mutation absurdly frustrating. Good tooling can help you track where a variable is used and in which order mutations happen trivially in code in a single function. It’s not as as helpful when it’s spread all over the place. You can infer so much less statically if you follow Martin’s advice.
I’m not advocating for 1000-lines functions here, mind you. When functions become too big, other challenges arise. What’s necessary is balance, which Martin’s book fails to teach.
Because abstractions leak. Heck, abstractions are practically lies most of the time.
What’s the most time-consuming thing in programming? Writing new features? No, that’s easy. It’s figuring out where a bug is in existing code.
How do abstractions help with that? Can you tell, from the symptoms, which “level of abstraction” contains the bug? Or do you need to read through all six (or however many) “levels”, across multiple modules and functions, to find the error? Far more commonly, it’s the latter.
And, arguably worse, program misbehavior is often due to unexpected interactions between components that appear to work in isolation. This means that there isn’t a single “level of abstraction” at which the bug manifests, and also that no amount of unit testing would have prevented the bug.
I usually start from the lowest abstraction, where the stack trace points me and don’t need to look at the rest, because my code is written well.
That’s great, but surely, from time to time, you have to deal with code that other people have written?
Yeah, cause silly mistakes in one place never affect another place that’s completely unrelated.
I hate reading code like this. It means that there is a bunch of object or global state that could be getting modified by anything all over the place that I can’t see just by looking at the method. In other words, if you say you understand this method, it is because you are making assumptions about other code that might be wrong.
I’ll take a 30 line pure function over a web of methods changing member state every time.