6 ms·

My last company was very into Clean Code, to the point where all new hires were expected to do a book club on it. My personal take away was that there were a f

My last company was very into Clean Code, to the point where all new hires were expected to do a book club on it. My personal take away was that there were a few good ideas, all horribly mangled. The most painful one I remember was his treatment of the Law of Demeter, which, as I recall, was so shallow that he didn't even really even thoroughly explain what the law was trying to accomplish. (Long story short, bounded contexts don't mean much if you're allowed to ignore the boundaries.) So most everyone who read the book came to earnestly believe that the Law of Demeter is about period-to-semicolon ratios, and proceeded to convert something like val frobnitz = Frobnitz.builder() .withPixieDust() .withMayonnaise() .withTarget(worstTweetEver) .build(); into var frobnitzBuilder = Frobnitz.builder(); frobnitzBuilder = frobnitzBuilder.withPixieDust(); frobnitzBuilder = frobnitzBuilder.withMayonnaise(); frobnitzBuilder = frobnitzBuilder.withTarget(worstTweetEver); val frobnitz = frobnitzBuilder.build(); and somehow convince themselves that doing this was producing tangible business value, and congratulate themselves for substantially improving the long-term maintainability of the code. Meanwhile, violations of the actual Law of Demeter ran rampant. They just had more semicolons.

in9 5y ago
I love how this is clearly a contextual recommendation. I'm not a software developer, but a data scientist. In pandas, to write your manipulations in this chained methods fashing is highly encouraged IMO. It's even called "pandorable" code
- mumblemumble 5y ago
  TBH, the only context where I've seen people express a strong preference for the non-chained option is under the charismatic influence of Uncle Bob's baleful stare. Otherwise, it seems opinions typically vary between a strong preference for chaining, and rather aggressive feelings of ¯\_(ツ)_/¯
- mywittyname 5y ago
  The latter example (without the redundant assignments) is preferred by people who do a lot of line-by-line debugging. While most IDEs allow you to set a breakpoint in the middle of an expression, that's still more complicated and error prone than setting one for a line. I've been on a team that outlawed method chaining specifically because it was more difficult to debug. Even though I'm more of a method-chainer myself, I have taken to writing unchained code when I am working on a larger team. var frobnitzBuilder = Frobnitz.builder(); frobnitzBuilder.withPixieDust(); frobnitzBuilder.withMayonnaise(); frobnitzBuilder.withTarget(worstTweetEver); val frobnitz = frobnitzBuilder.build(); ...is undeniably easier to step-through debug than the chained version.
  - mumblemumble 5y ago
    Might depend on the debugger? The main ones I've used also let me go through the chained version one at a time, including seeing intermediate values.
TeMPOraL 5y ago
On that note, I've never seen an explanation of Law of Demeter that made any kind of sense to me. Both the descriptions I read and the actual uses I've seen boiled down to the type of transformation you just described, which is very much pointless. > Long story short, bounded contexts don't mean much if you're allowed to ignore the boundaries. I'd like to read more. Do you know of a source that covers this properly?
- mumblemumble 5y ago
  If you really want to dig into it, perhaps a book on domain-driven design? That's where I pulled the term "bounded context" from. My own personal oversimplification, probably grossly misleading, is that DDD is what you get when you take the Law of Demeter and run as far with it as you can.
  - TeMPOraL 5y ago
    Thanks. I have Evans' book on my bookshelf. I understand it's the book on DDD, right? I tried to read it a while ago, I got through about one third of it before putting it away. Maybe I should revisit it.
- karmakaze 5y ago
  Three things that go well together: - Law of Demeter - Tell, Don’t Ask - narrow interfaces
- vidarh 5y ago
  > Law of Demeter "Don't go digging into objects" pretty much. Talk to directly linked objects and tell them what you need done, and let them deal with their linked objects. Don't assume that you know what is and always will be involved in doing something on dependent objects of the one you're interacting with. E.g. lets say you have a Shipment object that contains information of something that is to be shipped somewhere. If you want to change the delivery address, you should consider telling the shipment to do that rather than exposing an Address and let clients muck around with that directly, because the latter means that now if you need to add extra logic if the delivery address changes there's a chance the changes leaks all over the place (e.g. you decide to automate your customs declarations, and they need to change if the destination country changes; or delivery costs needs to updated). You'll of course, as always, find people that takes this way too far. But the general principle is pretty much just to consider where it makes sense to hide linked objects behind a special purpose interface vs. exposing them to clients.
gmmeyer 5y ago
wow this is a nightmare
bostonsre 5y ago
I think following some ideas in the book, but ignoring others like the ones applicable for the law of demeter can be a recipe for a mess. The book is very opinionated, but if followed well I think it can produce pretty dead simple code. But at the same time, just like with any coding, experience plays massively into how well code is written. Code can be written well when using his methods or when ignoring his methods and it can be written badly when trying to follow some of his methods or when not using his methods at all.
javcasas 5y ago
Every time that I see a builder pattern, I see a failure in adopting modern programming languages. Use named parameters, for f*cks sake! const frobnitz = new Frobnitz({pixieDust: true, mayonnaise: true, target: worstTweetEver});
natch 5y ago
>his treatment of the Law of Demeter, which, as I recall, was so shallow that he didn't even really even thoroughly explain what the law was trying to accomplish. oof. I mean, yeah, at least explain what the main thing you’re talking about is about, right? This is a pet peeve.

in9 5y ago

I love how this is clearly a contextual recommendation. I'm not a software developer, but a data scientist. In pandas, to write your manipulations in this chained methods fashing is highly encouraged IMO. It's even called "pandorable" code

mumblemumble 5y ago
TBH, the only context where I've seen people express a strong preference for the non-chained option is under the charismatic influence of Uncle Bob's baleful stare. Otherwise, it seems opinions typically vary between a strong preference for chaining, and rather aggressive feelings of ¯\_(ツ)_/¯
mywittyname 5y ago
The latter example (without the redundant assignments) is preferred by people who do a lot of line-by-line debugging. While most IDEs allow you to set a breakpoint in the middle of an expression, that's still more complicated and error prone than setting one for a line. I've been on a team that outlawed method chaining specifically because it was more difficult to debug. Even though I'm more of a method-chainer myself, I have taken to writing unchained code when I am working on a larger team. var frobnitzBuilder = Frobnitz.builder(); frobnitzBuilder.withPixieDust(); frobnitzBuilder.withMayonnaise(); frobnitzBuilder.withTarget(worstTweetEver); val frobnitz = frobnitzBuilder.build(); ...is undeniably easier to step-through debug than the chained version.
- mumblemumble 5y ago
  Might depend on the debugger? The main ones I've used also let me go through the chained version one at a time, including seeing intermediate values.

TeMPOraL 5y ago

On that note, I've never seen an explanation of Law of Demeter that made any kind of sense to me. Both the descriptions I read and the actual uses I've seen boiled down to the type of transformation you just described, which is very much pointless. > Long story short, bounded contexts don't mean much if you're allowed to ignore the boundaries. I'd like to read more. Do you know of a source that covers this properly?

mumblemumble 5y ago
If you really want to dig into it, perhaps a book on domain-driven design? That's where I pulled the term "bounded context" from. My own personal oversimplification, probably grossly misleading, is that DDD is what you get when you take the Law of Demeter and run as far with it as you can.
- TeMPOraL 5y ago
  Thanks. I have Evans' book on my bookshelf. I understand it's the book on DDD, right? I tried to read it a while ago, I got through about one third of it before putting it away. Maybe I should revisit it.
karmakaze 5y ago
Three things that go well together: - Law of Demeter - Tell, Don’t Ask - narrow interfaces
vidarh 5y ago
> Law of Demeter "Don't go digging into objects" pretty much. Talk to directly linked objects and tell them what you need done, and let them deal with their linked objects. Don't assume that you know what is and always will be involved in doing something on dependent objects of the one you're interacting with. E.g. lets say you have a Shipment object that contains information of something that is to be shipped somewhere. If you want to change the delivery address, you should consider telling the shipment to do that rather than exposing an Address and let clients muck around with that directly, because the latter means that now if you need to add extra logic if the delivery address changes there's a chance the changes leaks all over the place (e.g. you decide to automate your customs declarations, and they need to change if the destination country changes; or delivery costs needs to updated). You'll of course, as always, find people that takes this way too far. But the general principle is pretty much just to consider where it makes sense to hide linked objects behind a special purpose interface vs. exposing them to clients.

gmmeyer 5y ago

wow this is a nightmare

bostonsre 5y ago

I think following some ideas in the book, but ignoring others like the ones applicable for the law of demeter can be a recipe for a mess. The book is very opinionated, but if followed well I think it can produce pretty dead simple code. But at the same time, just like with any coding, experience plays massively into how well code is written. Code can be written well when using his methods or when ignoring his methods and it can be written badly when trying to follow some of his methods or when not using his methods at all.

javcasas 5y ago

Every time that I see a builder pattern, I see a failure in adopting modern programming languages. Use named parameters, for f*cks sake! const frobnitz = new Frobnitz({pixieDust: true, mayonnaise: true, target: worstTweetEver});

natch 5y ago

>his treatment of the Law of Demeter, which, as I recall, was so shallow that he didn't even really even thoroughly explain what the law was trying to accomplish. oof. I mean, yeah, at least explain what the main thing you’re talking about is about, right? This is a pet peeve.