Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Clean Code vs. A Philosophy Of Software Design

github.com

Post reply on HN
Print view View original

21–30 of 554 posts

Re: Clean Code vs. A Philosophy Of Software Design

#21

Post by rester324 »

frozenlettuce wrote: post #8
zbentley wrote: post #4

It's striking to me how out of touch Martin seems to be with the realities of software engineering in this transcript. Stylistic refactors that induce performance regressions, extremely long and tortured method names for three-line methods, near-total animus towards comments ... regardless of who is right/wrong about what, those takes seem like sophomoric extremism at its worst, not reasoned pragmatism that can be ap…

I don't know why people take UB seriously. He never provided proof of any work experience - he claims to have worked for just a single company that... never shipped any code into production. Even his code examples on GitHub are just snippets, not even a to-do app (well, I think that his style of "just one thing per function" works as a self-fulfilling prophecy). Maybe people like him are the reason why we have to do…

Uncle Bob is one of the core contributors to Fitnesse, which had moderate success in the Java popularity era back in the day.

Also, you do understand that people worked as software engineers even before Github became popular, or open sourcing to begin with, do you? So if someone is 60+ year old, chances are that most of his work has never been open sourced, and his work was targeting use cases, platforms, services which have no utility in this age any more.

Which have all nothing to do with how good a software engineer someone is.

And finally, do you have any proof that he never shipped any code into production?

Re: Clean Code vs. A Philosophy Of Software Design

#22

Post by tikhonj »

mbo wrote: post #15
sudobash1 wrote: post #10

There is an important case for comments that neither of them touched on. Sometimes you are dealing with bugs or counterintuitive processes beyond your control. For example, I am writing some driver software for a USB device right now. It is so easy to get the device into a bad state, even when staying within the documented protocol. Every time I implement a workaround, or figure out exactly how the device expects a m…

While I am not a Uncle Bob-style "no comments"er I do love a ridiculous method name. I pay very close attention to that method and the context in which it is called because, well, it must be doing something very weird to deserve a name length like that.

There are a few Haskell functions with names like reallyUnsafePtrEquality# or accursedUnutterablePerformIO, and you know something interesting is going on :P

Re: Clean Code vs. A Philosophy Of Software Design

#23

Post by nyarlathotep_ »

Scubabear68 wrote: post #16
getnormality wrote: post #12

Uncle Bob's insistence that functions should be 2-4 lines long is baffling to me. I don't understand how he can be taken seriously. Is there a single application in the entire world with substantial functionality that conforms to this rule?

There are. A lot of Java code bases look like this. It is all as bad as you imagine. Functionality is spread out all of the place so it is very difficult to reason about how it all hangs together.

It's always fun stepping through 412 stack frames that are all 2-line long methods to figure out where the thing you're interested in actually happened.

Re: Clean Code vs. A Philosophy Of Software Design

#24

Post by MobiusHorizons »

Scubabear68 wrote: post #16
getnormality wrote: post #12

Uncle Bob's insistence that functions should be 2-4 lines long is baffling to me. I don't understand how he can be taken seriously. Is there a single application in the entire world with substantial functionality that conforms to this rule?

There are. A lot of Java code bases look like this. It is all as bad as you imagine. Functionality is spread out all of the place so it is very difficult to reason about how it all hangs together.

I once fully spelunked such a Java call stack to convert some code to golang. It was amazing, there were like 5 layers of indirection over some code that actually did what I want, but I had to fully trace it keeping arguments from the full call stack in mind to figure this out, because several of the layers of indirection had the potential of doing substantially more work with much more complex dependency graphs. I ended up with a single go file with two functions (one that reproduced the actually interesting Java code and one that called it the way it would have been called across all the layers of indirection. It was less than 100 lines and _much_ easier to understand.

Re: Clean Code vs. A Philosophy Of Software Design

#25

Post by NomDePlum »

zbentley wrote: post #4

It's striking to me how out of touch Martin seems to be with the realities of software engineering in this transcript. Stylistic refactors that induce performance regressions, extremely long and tortured method names for three-line methods, near-total animus towards comments ... regardless of who is right/wrong about what, those takes seem like sophomoric extremism at its worst, not reasoned pragmatism that can be ap…

I'm going to have to admit to never having read Clean Code. It's just never appealed to me. I did read some of UBs articles a fair number of years ago. They did make me think - which I'd say is a positive and along the lines you are putting forwards.

Rigidity and "religious" zeal in software development is just not helpful I'd agree.

I do however love consistency in a codebase, a point discussed in "Philosophy of Software Design", I always boil this down to, even if I'm doing something wrong, or suboptimal, if I do it consistently, once I realise, or it matters I only have one thing to change to get the benefit.

It's the not being able to change regardless, in the face of evidence, that separates consistency and rigidity (I hope)!

Re: Clean Code vs. A Philosophy Of Software Design

#26

Post by chillpenguin »

ilrwbwrkhv wrote: post #3

john ousterhout's book is the only book on how to write software that has any actual evidence behind it. i highly recommend it as the only book to read on how to write code. and uncle bob, well, best to avoid his stuff as much as possible. clean code takes away about 5 years from every dev's life as they think they need to read it to become an intermediate developer and one they realize that is not the way, can they…

"john ousterhout's book is the only book on how to write software that has any actual evidence behind it."

This is false and hopefully no one takes you seriously when they read that. There are books about empirical methods for software engineering, for example, which actually seek to find real evidence for software engineering techniques. See Greg Wilson's work, for example.

There are lots of other architecture/design books that use real world systems as examples. "Evidence" is definitely lacking in our field, but you can find it if you try.

Re: Clean Code vs. A Philosophy Of Software Design

#27

Post by recursivedoubts »

chillpenguin wrote: post #26
ilrwbwrkhv wrote: post #3

john ousterhout's book is the only book on how to write software that has any actual evidence behind it. i highly recommend it as the only book to read on how to write code. and uncle bob, well, best to avoid his stuff as much as possible. clean code takes away about 5 years from every dev's life as they think they need to read it to become an intermediate developer and one they realize that is not the way, can they…

"john ousterhout's book is the only book on how to write software that has any actual evidence behind it." This is false and hopefully no one takes you seriously when they read that. There are books about empirical methods for software engineering, for example, which actually seek to find real evidence for software engineering techniques. See Greg Wilson's work, for example. There are lots of other architecture/desig…

> no links

Re: Clean Code vs. A Philosophy Of Software Design

#28

Post by PlunderBunny »

getnormality wrote: post #12

Uncle Bob's insistence that functions should be 2-4 lines long is baffling to me. I don't understand how he can be taken seriously. Is there a single application in the entire world with substantial functionality that conforms to this rule?

I've seen this in what I call 'lasagna code' - multiple thin layers that seem to do nothing (or almost nothing) but each one is an implementation of some abstruse interface that exists in the mind of the original developer.

Eventually, your code has to do something. Get that thing in one place where you can look at it in its whole.

Re: Clean Code vs. A Philosophy Of Software Design

#29

Post by OnionBlender »

ziml77 wrote: post #14
ilrwbwrkhv wrote: post #3

john ousterhout's book is the only book on how to write software that has any actual evidence behind it. i highly recommend it as the only book to read on how to write code. and uncle bob, well, best to avoid his stuff as much as possible. clean code takes away about 5 years from every dev's life as they think they need to read it to become an intermediate developer and one they realize that is not the way, can they…

That book really poisons the mind. Even if there's some good things to learn in there, it's stashed among a lot of advice that is either plain bad or needs asterisks. But there aren't really any asterisks and instead it presents what look like rules that you shouldn't be breaking if you want to be a good programmer. When I first read the book I'd already been programming for 10 years, but I was in my first job out of…

Which book are you referring to? The parent comment mentioned two books.

Re: Clean Code vs. A Philosophy Of Software Design

#30

Post by the__alchemist »

zbentley wrote: post #4

It's striking to me how out of touch Martin seems to be with the realities of software engineering in this transcript. Stylistic refactors that induce performance regressions, extremely long and tortured method names for three-line methods, near-total animus towards comments ... regardless of who is right/wrong about what, those takes seem like sophomoric extremism at its worst, not reasoned pragmatism that can be ap…

I'm not familiar with the Clean Code book etc; my introduction is the article. UB seems to be advocating consistently for patterns that are not my cup of tea! For example: Functions sometimes make sense as 2-3 lines. Often 5-20. Less often, but not rarely, much more than that!

I'm also a fan of detailed doc comments on every module and function, and many fields/variants as well. And, anything that needs special note, is unintuitive, denotes units or a source etc.

Post reply on HN