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

231–240 of 554 posts

Re: Clean Code vs. A Philosophy Of Software Design

#231

Post by sam_bishop »

One of my beefs with Clean Code is its name.

There is no objective measure of code cleanliness. So if "clean code" is your goal, then you have no meaningful criteria to evaluate alternatives. (Including those pitched by Bob Martin.)

It gets worse, though. There's a subconscious element that causes even more trouble. It's obviously a good thing to write "clean code", right? (Who's going to argue otherwise?) And to do otherwise would be a moral failing.

The foundation on which "Uncle Bob" tries to build is rotten from the get-go. But it's a perfect recipe for dogmatism.

Re: Clean Code vs. A Philosophy Of Software Design

#232

Post by ninetyninenine »

NeutralForest wrote: post #221
ninetyninenine wrote: post #205

Earlier quoted context omitted.

Well I mean they wrote books about it and one guy had the audacity to call his opinion a “philosophy” even though it’s just an arbitrary opinion. Most of software is about assigning big words and over complicated nomenclature to concepts and these things masquerade as things with deeper meaning when in reality it’s just some made up opinion. Software design is an art. It is not engineering and it is not science. That…

But there are typical practices we agree are good: using a VCS, writing tests, write comments when needed, separate different level of abstractions, etc. Right? This comes from years of common experience in software. Over time we get to find patterns, common issues and ways to fix them, etc. It doesn't have to be strict patterns but overall strategies. If we don't do that then it's just vibes right? Where's the engin…

Nothing is fixed in stone. If you have strong typing and program with pure functions and immutability while utilizing union types and matching to the full extent you typically need very few unit tests for your code to work. You just need integration and e2e tests.

I write very little unit tests as my coding style that employs static checks as viciously as possible doesn’t necessitate it.

I would say only 30 percent of patterns are good and shared. The other stuff is just artistry and opinion. Like method name length or comments or OOP.

Re: Clean Code vs. A Philosophy Of Software Design

#233

Post by SAI_Peregrinus »

ninetyninenine wrote: post #215
slotrans wrote: post #59

Earlier quoted context omitted.

> I will completely forget why I wrote it that way. This is the main reason for comments. The code can never tell you "why". Code is inherently about "what" and "how". The "why" must be expressed in prose.

Why not put the prose in the name of the function?

Function names are limited. E.g. can't provide a circuit diagram of what you're controlling in a function name. But you can do that in a comment (either with ASCII art or an image link).

Re: Clean Code vs. A Philosophy Of Software Design

#234

Post by bpicolo »

sam_bishop wrote: post #231

One of my beefs with Clean Code is its name. There is no objective measure of code cleanliness. So if "clean code" is your goal, then you have no meaningful criteria to evaluate alternatives. (Including those pitched by Bob Martin.) It gets worse, though. There's a subconscious element that causes even more trouble. It's obviously a good thing to write "clean code", right? (Who's going to argue otherwise?) And to do…

Honestly that kind of makes the word "clean" seem like a good fit to me. I can't say that measuring the cleanliness of my house is objective.

Re: Clean Code vs. A Philosophy Of Software Design

#235

Post by froh »

xeyownt wrote: post #197
cjfd wrote: post #151

Earlier quoted context omitted.

Once you notice that the primes are in the top rows, it becomes a pretty good comment.

Just learned that 9, 15, 21, ... are primes. Excellent comment ^^.

well, ackchyually, 'technically' the primes _are_ in there in that top row

just not only primes ^^

Re: Clean Code vs. A Philosophy Of Software Design

#236

Post by yxhuvud »

namuol wrote: post #110
acmj wrote: post #49

Earlier quoted context omitted.

You need to know what is good code. Opinions may vary a lot between programmers, even senior ones. The Clean Code cult would tell you to find good code there but that is the most poisonous programming book I have read.

Forget about the code itself and focus on the results. What I mean by that: Good code is code that has proven itself by surviving quietly in a long-living project that has changed a lot over many cycles of new engineers (experienced or otherwise) being onboarded. The less you hear people complain about it but the more you find people using or relying on it in some way, the better the code. If people are loud about ho…

No, because then you end up reading old C-code that are IFDEF mazes and think that is good code. No, to see good code you usually have to look at what experienced people write when they get to greenfield something new.

Re: Clean Code vs. A Philosophy Of Software Design

#237

Post by bluGill »

bob1029 wrote: post #222

I'm currently dealing with one of those codebases representative of the consequences of blindly following "Clean Code", et. al. My experience has taught me that you never want to be the first person to recommend a rewrite. Since I am a mere contractor on this one, I am strongly inclined to let it unwind on its own. There seems to be a lot of ego embedded in those pointless data access layer wrappers. I'd hate to get…

Rewrite is only useful it you get something else that you can't get otherwise. Mixing Rust and C++ in a project is hard but doable - odds are if you try it you will find enough "friction" that eventually it will be worth rewriting to get rid of one.

Re: Clean Code vs. A Philosophy Of Software Design

#238

Post by yxhuvud »

regularfry wrote: post #174
tcfhgj wrote: post #154

Earlier quoted context omitted.

Not really, long-living projects don't adapt their complete code base with gained experience, much like the Linux Kernel probably will never be rewritten in Rust, C++ projects never transformed to C++14+, etc.

The interesting thing to look for here is the parts of the codebase that don't need to adapt with gained experience. That's the key. If people aren't changing it, they haven't needed to, and that's a useful signal. Conversely, looking for the parts of a codebase with the highest churn will tell you immediately what all the devs on that codebase will complain about, if you ask them. This has worked for me extremely we…

It can also mean "We have not changed this because we don't dare to do that, or it is too much work and we just have to live with the bad decisions made 25 years ago". And that is the last code you want to copy.

Re: Clean Code vs. A Philosophy Of Software Design

#239

Post by jjice »

Lots of negative comments about Uncle Bob in this thread. I personally didn't like Clean Code and really enjoyed A Philosophy of Software Design, but I do think that some of his other books are really solid.

I accept that non-fiction books on anything will oversell the value of their way, and try to take what I can at a more moderate level. Through that lens, Clean Code didn't give me much, but Clean Architecture did. The Clean Coder is also an interesting read on professionalism in software, and Clean Agile is an interesting read on Agile roots. I don't know anyone that practices "true" agile (nor do I care to do so myself), but there are some really solid ideas in there.

I get that Clean Code kind of had a cult-like following in that people followed it blindly, but damn some of these comments are just rude about Uncle Bob. I still think he's a pretty good author and has given me some advice through his other books that helped me a lot as a fresh faced dev.

Re: Clean Code vs. A Philosophy Of Software Design

#240

Post by voidhorse »

ilitirit wrote: post #145

It still blows my mind how dogmatic some people can be about things like this. I don't understand why anyone takes these things as gospel. Who else has had to deal with idiots who froth at the mouth when you exceed an 80 line character margin? And it's not just programming styles, patterns and idioms. It's arguably even worse when it comes to tech stacks and solution architecture. It's super-frustrating when I'm deal…

I think it stems from fundamental misunderstandings about what it is one is actually trying to do when writing code.

Coding is about building a computable model of some facet of existence, usually for some business. When it comes to model building, comprehension and communication are paramount. Performance and other considerations are also important but these are arguably accidental features of machines and, in an ideal world, would not actually affect our model.

Similarly, in an ideal world, we wouldn't even need programming languages. We'd be able to devise and explain computational systems in some kind of perfect abstract language and not need to worry about their realization as programs.

I think a lot of these blanket philosophies confuse people by not emphasizing the higher level aspects of the activity enough. Instead people get hung up on particular patterns in particular paradigms/languages and forget that the real goal is to build a system that is comprehensible to the community of maintainers that need to work with it.

Post reply on HN