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

201–210 of 554 posts

Re: Clean Code vs. A Philosophy Of Software Design

#201

Post by dgb23 »

Copenjin wrote: post #126

You just need to work on one project built by someone that implemented Uncle Bob recommendations blindly when the books came out to know how much they are worth. There were some low hanging fruits to pick at the time regarding trying to be better at software engineering and he generated some text about them. Full of terrible advices, he never wrote anything significant (in scope and notoriety) during his time as a so…

Clean code, design patterns etc. were also picked up by teachers, professors and course instructors.

I think these paradigms and patterns often operate on the wrong layer of abstraction, while mostly ignoring the things that matter the most, like efficiency, error handling and debugging.

But getting good at these things requires a lot more blood, sweat and tears, so there's no easily teachable recipe for that.

Re: Clean Code vs. A Philosophy Of Software Design

#202

Post by Kinrany »

valenterry wrote: post #137
Kinrany wrote: post #106

Earlier quoted context omitted.

Links to any existing articles on this topic would be greatly appreciated.

This is the original article from Fowler: https://martinfowler.com/bliki/AnemicDomainModel.html By searching for that term, you'll easily find lots of other takes on the matter.

> I'll reply here with a very quick example why the anemic domain model is superior in general, no matter if you do OOP or anything else.

I can search for it of course but results that aren't about OOP purism appear to be rare.

Re: Clean Code vs. A Philosophy Of Software Design

#203

Post by raverbashing »

bena wrote: post #192
einpoklum wrote: post #181

Earlier quoted context omitted.

My experience is that being fastidious about code formatting is independent of one's ability as a developer. i.e. not a good indicator either way.

I’ve noticed the worse someone is in a language, the worse they format it. People then develop fastidious code formatting rules because they realize well formatted code is easier to read and extend. Then people realize it’s the organization of the code, not the rules themselves. They have preferences, but don’t treat those preferences as “the one true way”. So people with fastidious rules are in that middle ground of…

> Then people realize it’s the organization of the code, not the rules themselves. They have preferences, but don’t treat those preferences as “the one true way”.

Yup, I agree with this

It's not about, let's say, where your curly braces stay, but being consistent

Though in some cases I'd argue that things like a very strict 80 character limit actually results in worse code (or at least worse to read code)

Re: Clean Code vs. A Philosophy Of Software Design

#204

Post by bonsaiKiller »

There’s obviously a balance. Having worked in both environments, I tend to appreciate the code of someone who at least read the books, but treats it as suggestion rather than gospel. Contrast to someone who never read the books, has no clue what’s “good” and hacks everything.

On the one hand, the books are popular because a lot of people reading them think it makes a good point, and share that view. On the other hand, just because something is popular doesn’t make it right! I think this is where AI gets so much wrong. GIGO! If you base all your code on whatever is most common, are you really really sure that common pattern is really the best? AI, and these book evangelist, often have no clue. Just parroting others.

I’d rather deal with “principles” as opposed to “rules” every time. Glean the principles from the books, and at least try to write clean code!

Re: Clean Code vs. A Philosophy Of Software Design

#205

Post by ninetyninenine »

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…

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’s why there’s so much made up bullshit. The irony is we use “art” to solve engineering problems in programming. It’s like ok we don’t actually know the most optimal way to program a solution here so we make up bs patterns and philosophies. But then let’s give this bs pattern some crazy over complicated name like Scientology or inversion of control and now everyone thinks it’s a formal and legitimate scientific concept.

Well cats out of the bag for Scientology. Not yet for a lot of the bs in software. A “philosophy” is the biggest utter bullshit word for this stuff I’ve ever seen.

Re: Clean Code vs. A Philosophy Of Software Design

#206

Post by zbentley »

motorest wrote: post #85
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…

> 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…

I'm not going to spend a long time responding to your comment, since it seems accusatory and rude; if you modify it to be more substantive I'll happily engage more.

The one specific response I have is: it's not that I

> say nothing specific or concrete: [I] only throw blanket ad hominems that sound very spiteful

...rather, it's that I'm criticizing Martin's approach to teaching rather than his approach to programming. I expand on that criticism more in an adjacent comment, here: https://news.ycombinator.com/item?id=43171470

Re: Clean Code vs. A Philosophy Of Software Design

#207

Post by jghn »

seanwilson wrote: post #57

I find the lack of discussion of type systems really surprising in these sorts of discussions and books. Effective use of type systems is a killer factor for me for creating clean, safe, readable and maintainable software designs. When used correctly, strong static type checking make certain kinds of bugs impossible, spare you from writing many kinds of tedious tests that often get in the way of refactoring, serve as…

Because the pendulum of typing hadn't swung back to static being in vogue when the Philosophy of Software Design came out. At the time you had mostly the Scala & Haskell people standing in a corner screaming until they (well, we as I was one of them) were blue in the face about reducing "certain types of bugs", and making impossible states impossible.

Since then, everyone and their brother is on the static typing train. And from that lens you're right. It seems like an omission. Give it another 10 years and people will probably think the opposite.

Re: Clean Code vs. A Philosophy Of Software Design

#209

Post by mrkeen »

samiv wrote: post #164

Instead of "Clean Code" I'd really suggest people read either - Code Complete - The Pragmatic Programmer https://en.wikipedia.org/wiki/Code_Complete https://en.wikipedia.org/wiki/The_Pragmatic_Programmer

I read Clean Code and don't remember a single thing from it. To be fair it was a while ago.

But the SOLID and Clean Architecture principles inform me almost daily.

Re: Clean Code vs. A Philosophy Of Software Design

#210

Post by leidenfrost »

hliyan wrote: post #196
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…

To restate something I've said here last month: I'm fond of saying that anything that doesn't survive the compilation process is not design but code organization. Design would be: which data structures to use (list, map, array etc.), which data to keep in memory, which data to load/save and when, which algorithms to use, how to handle concurrency etc. Keeping the code organized is useful and is a part of basic hygien…

My take is that the book also works as a source of authority for aspiring SSR and SR devs.

Comments about code style are usually subjective, and, they can be easily dismissed as a personal preference, or, in the case of a Jr dev, as a lack of skill.

Until they bring up "The Uncle Bob book". Now, suddenly, a subjective opinion from a Jr dev looks like an educated advice sourced from solid knowledge. And other people now have a reason to listen up.

All of this is totally fabricated, of course. But it's like the concept of money. It's valid only because other people accept it as valid.

Post reply on HN