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

131–140 of 554 posts

Re: Clean Code vs. A Philosophy Of Software Design

#131

Post by lmm »

rester324 wrote: post #89
overgard wrote: post #80

Earlier quoted context omitted.

"It's not object oriented programming" is only a good case to make if you think object oriented programming is synonomous with good. I don't think that's true. It's sometimes good, often not good. Why would focusing on OO be a goal? The goal is to write good software that can be easily maintained. Nobody outside of book writers are shipping UML charts

Why would you not focus on writing OO code in an OO language for example? Would you start writing OO code in a functional langugage? No you wouldn't, because it would be pointless. There are programming paradigms for a reason

> Why would you not focus on writing OO code in an OO language for example?

That's circular logic. I wouldn't focus on writing OO code because I know from experience that the result is usually worse. If I had to use a language that was oriented towards writing OO code, I'd still try to limit the damage.

> There are programming paradigms for a reason

Nah. A lot of them are just accidents of history.

Re: Clean Code vs. A Philosophy Of Software Design

#132

Post by lmm »

motorest wrote: post #94
overgard wrote: post #80

Earlier quoted context omitted.

"It's not object oriented programming" is only a good case to make if you think object oriented programming is synonomous with good. I don't think that's true. It's sometimes good, often not good. Why would focusing on OO be a goal? The goal is to write good software that can be easily maintained. Nobody outside of book writers are shipping UML charts

> "It's not object oriented programming" is only a good case to make if you think object oriented programming is synonomous with good. I don't think that's true. It's sometimes good, often not good. See, this is the sort of lazy ignorance that adds nothing of value to the discussion, and just reads as spiteful adhominems. Domain models are fundamentally an object-oriented programming concept. You model the business d…

> Domain models are fundamentally an object-oriented programming concept.

They are not.

> You model the business domain with classes, meaning you specify in them the behavior that reflects your business domain.

I have better tools for doing that.

> In Domain-Driven design, with its basis on OO, you implement these operations at the class level, because your classes model the business domain and implement business rules.

You're still not explaining the "why". You're just repeating a bunch of dogma.

> a domain model without behavior means you are wasting all development effort building up a structure that does nothing and adds none of the benefits, and thus represents wasted effort.

I know from experience that this is completely false.

> You don't know what you're doing, and somehow you're calling it Domain-Driven design.

I don't call it domain-driven. You can call it domain-driven if you want, or not if you don't want. I don't care what it's called, I care whether it results in effective, maintainable software with low defect rates.

Re: Clean Code vs. A Philosophy Of Software Design

#133

Post by lmm »

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 worry that his approach allows a certain kind of programmer to focus on like ... aesthetic, dogmatic uniformity (and the associated unproductivity of making primarily aesthetically-motivated, dogmatic changes rather than enhancements, bugfixes, or things that other coders on a project agree improves maintainability) instead of increasing their skills and familiarity with their craft.

Funny, I find the opposite. In my experience people that are willing to take a "dogmatic" position on code style are those who are able to actually get on with implementing features and bugfixes. It's the ones who think there's a time and place for everything and you need to re-litigate the same debates on every PR who tie themselves in knots getting nothing done.

Do I agree with absolutely everything Martin writes? In principle, no. But I'd far rather work on a codebase and team that agrees to follow his standards (or any similar set of equally rigid standards, as long as they weren't insane) than one that doesn't.

Re: Clean Code vs. A Philosophy Of Software Design

#134

Post by Cthulhu_ »

randomNumber7 wrote: post #84
jbm wrote: post #83

Earlier quoted context omitted.

The Uncle Bob thing is something I'm experiencing right now. I hired a friend who was a huge Uncle Bob mark, and he kept trying to flex his knowledge during interviews with other people in the company. I didn't really think much of it and told the other interviewer that it was just his personal quirk and not to worry much. I had him work with some junior devs on a project while I took care of something more urgent. A…

I don't see how it is uncle Bob's fault that your friend misunderstood his book.

Not so much UB himself, but a developer being told a book or person is authoritative / has the final word on a subject isn't healthy.

Re: Clean Code vs. A Philosophy Of Software Design

#135

Post by imjonse »

j_san wrote: post #124
imjonse wrote: post #74

I am biased ( a former coworker was an Uncle Bob fan, and was bent on doing everything by the book, with layers of abstraction, patterns, hexagonal architecture, lots of unit tests, no cutting corners, even as we did not know what exactly we want to build and needed an MVP ASAP) but I'll just say this: Ousterhout wrote TCL - widely considered one of the best C codebases - besides being a professor at Standford and ha…

Biased against the approach of your former coworker and thus the "Clean Code" way? I assume it did not work out well, because you needed to move fast to build an MVP before trying to do it right?

yes, biased against knowing 'the best way do write software' and applying it regardless of what the current requirements and constraints are. And arguing for their position by sending people links to Uncle Bob videos for 'enlightenment'.

Re: Clean Code vs. A Philosophy Of Software Design

#136

Post by Cthulhu_ »

WalterBright wrote: post #41
ziml77 wrote: post #14

Earlier quoted context omitted.

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…

1. newbie follows the rules because he is told to 2. master follows the rules because he understands them 3. guru breaks the rules because they don't apply

There's a step between 1 and 2, someone who writes rules because he believes he understands them.

There was an era where every just-above-newbie PHP developer would start writing their own authoritative blog posts and frameworks, I strongly feel that had a big impact on the fragmentation and reputation of the PHP ecosystem as being insecure (because a lot of these authoritative blog posts demonstrated how to introduce SQL injection vulnerabilities)

Re: Clean Code vs. A Philosophy Of Software Design

#137

Post by valenterry »

Kinrany wrote: post #106
valenterry wrote: post #103

Earlier quoted context omitted.

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. You used the example of an "order" yourself, so I'll built upon it. I would never combine functionality to update an order with the data and structure of the an order. The reason is simple: the business constraints don't always live inside the order . Here's an example why such an ap…

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.

Re: Clean Code vs. A Philosophy Of Software Design

#139

Post by matsemann »

jacobsenscott wrote: post #113

I was around before the clean code movement, and like all software movements, it was a reaction to real problems in the software industry. Massive procedural functions with deeply nested conditionals, no structure, global variables, no testing at all. That was all the norm. Clean Code pushed things in a better direction, but it over-corrected. In many ways APOSD (published in 2018) is a correction against the excesse…

I think learning extremes can be useful, just don't take any one paradigm as gospel. Practicing Clean Code forces you to think in a special way, and when you've tried it, you start to get a feeling for where you should draw the line. Doing CC makes you a better programmer, but you have to figure out yourself where the tradeoffs are.

Other examples are TDD. Forcing myself to write tests for everything for a period has made all my code since better, even though I don't practice TDD now.

Re: Clean Code vs. A Philosophy Of Software Design

#140

Post by mrkeen »

WalterBright wrote: post #40
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?

Too often I see functions that are shells that reshuffle the arguments and pass them to another function, which also reshuffles the arguments and forwards them to another, and on and on. One was 11 layers deep.

If you have a 2-4 line function and you spot this, you can trivially remove it.
Post reply on HN