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

481–490 of 554 posts

Re: Clean Code vs. A Philosophy Of Software Design

#481

Post by overgard »

MetaWhirledPeas wrote: post #376

I think the reason most people have a problem with Uncle Bob is because they know their own practices are a far cry from his recommendations, and they take his prescriptive and uncompromising advice as a personal attack. I also wonder how many people interpret his advice as that of a mindless, pedantic dictator. My own introduction to UB was from some random YouTube video he made about programming languages, so my fi…

My problem with UB is that by promoting his brand and his style so much to junior developers (in both subtle and fairly overt ways), he's warped the mind of a lot of people in a way that effects them for a long time and the people around them. I don't really have anything personally against UB, but dealing with the code that one of his acolytes creates is deeply frustrating and often they claim it's "best practice" even though there's basically no validation around most of his claims and if you read the criticism, they're fairly common sense.

Re: Clean Code vs. A Philosophy Of Software Design

#482

Post by overgard »

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…

I really don't understand this fixation on domain modelling. It looks like a lot of UML mixed with a "*DD" (life-pro tip: pretty much any X Driven Development is something experienced programmers rarely care about. You can borrow good ideas from almost any methodology without becoming obsessed with its primary subject. Being obsessed with the One True Way is a great way to waste a lot of brain cells). Also nobody sane touches UML. Or makes big official charts of classes and their relationships. It's a massive waste of time. You might come up with some core concepts and relationships, like a B-REP, but you don't need some jargon-heavy official way to do this.

> The argument being made against anemic domain models is that a domain model without behavior fails to meet the most basic requirements of a domain model. Your domain model is just DTOs that you pass around as if the were value types, and have no behavior at all. Does it make sense to have objects without behavior? No, not in OO and elsewhere as well. Why? Because 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. You are better off just doing something entirely different which is certainly not Domain-Driven design.

I have barely any idea what you're saying, but I will agree that I'm probably better off without DDD.

> You are adopting a OO concept, which the most basic traits is that it models business domains with objects. Do you understand the absurdity of this sort of argument?

Except I'm not, because I don't care about DDD? My argument is simply: caring how much your code adheres to some third party methodology doesn't matter, what matters is if you're writing good code or not.

Re: Clean Code vs. A Philosophy Of Software Design

#483

Post by nyarlathotep_ »

ninetyninenine wrote: post #255
NeutralForest wrote: post #250

Earlier quoted context omitted.

I don't really agree, unit test should test behavior, having types of not should not be a defining factor in the coverage. I don't think patterns as a whole are good but there are known issues and structures to existing problems so boiling it down to art seems reductionist imo.

You don’t agree because you likely aren’t utilizing static checks to the extent that I do. Like there are no strings or numbers in my code. Everything is operating on strict union type boundaries. The only place where you have unbounded types like strings is on the interface to IO or state. I can code and not test behavior and have that behavior work reliably without tests. Key word is the unit trst. Typically IO and…

> "Boiling it down to an art is not reductionist. It’s true. Where is the scientific method in programming? How was a pattern deduced using the scientific method? If it was not deduced using the method then was it created from axioms and logic like math? Is it a theorem?

No. It’s all just made up. And we have no quantitative way of verifying why one design is better than another design. That’s why software technology often moves horizontally. There’s no way to verify the current design was better than the last."

Thanks for saying this. I've never stopped rolling my eyes at the assertion that web programming is an engineering discipline.

Re: Clean Code vs. A Philosophy Of Software Design

#484

Post by overgard »

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 don't know, I think the kind of person that comments on hacker news is not the average sort of programmer. I mentioned Clean Code to a more experienced colleague today and he had no idea what I was talking about, and when I mentioned the ideas to him he laughed at them. So I don't think there's some sort of pendulum swinging the other way and people are going to start writing massive functions. You'll probably just see small subcultures come up with some new idea that's obnoxious.

There have been some pendulum swinging around things like monoliths/microservices, but even then the amount of people that those things effected is actually much less than the larger community of programmers as a whole.

Re: Clean Code vs. A Philosophy Of Software Design

#485

Post by Kerrick »

valenterry wrote: post #477
Kerrick wrote: post #353

Earlier quoted context omitted.

> The customer actually asked for the order to be canceled. This is why many object-oriented programmers prefer to talk about message passing instead of method calling. It is indeed about asking for the order to be canceled, and the order can decide whether to fulfill that request.

> the order can decide whether to fulfill that request. In my world of thinking, orders don't make decisions. If I go to the business team and say "the order decided to" they'll look at me funny. And for good reasons.

Go back and read what I said about subject nouns and object nouns. When converting OO concepts to English for non-programmers, it is indeed confusing to say “the order decided not to”—you say “the order couldn’t be” instead.

I highly recommend reading the two books I recommended for further perspective on the topic. OO is predicated not on the idea that data is a bag of dead bits on which operations are performed, but that data is embodied within and encapsulated by anthropomorphic objects with their own behavior.

It is possible to get to that world of thinking from where you are now. But it is a different world. A different way of thinking.

Re: Clean Code vs. A Philosophy Of Software Design

#486

Post by lmm »

machine_ghost wrote: post #312
disgruntledphd2 wrote: post #175

Earlier quoted context omitted.

It's important to note that Kent Beck is not one of those people, as he shipped the first unit testing library, as well as a bunch of ones in other languages later. Like, I personally prefer the bare assert style of testing (like pytest), but the junit style is basically everywhere now.

Kent Beck is just as bad as Uncle Bob! He drank his own proverbial Kool-Aid and went all in on the crazy XP programming fad he started (... which contains brilliance like requiring pair programming for every line of code written). Look, both authors are very smart people who have great insights into development that we can all learn from ... but both also have the failing of being way too in love with their own ideas…

> which contains brilliance like requiring pair programming for every line of code written

Because it works. Have you tried it?

Re: Clean Code vs. A Philosophy Of Software Design

#487

Post by snapdaddy »

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…

FWIW (not a lot), I do believe in a lot of these principles.

For example, even with widescreen monitors, it is still useful to limit line length. Why? Because many people will have multiple source files side-by-side on one of those widescreen monitors, at which point it makes sense for them to not run on indefinitely.

And of course, that is just a guideline, one that I break regularly. However, if it's a method with many args, I'll break the args onto their own lines.

However, the overriding concern is that an organisation works to code towards a common style, whatever that may be, so that unfamiliar code is predictable and understandable.

Re: Clean Code vs. A Philosophy Of Software Design

#488

Post by snapdaddy »

0x20cowboy wrote: post #408
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…

This is just how junior and intermediate devs behave. It’s like a goth phase or something. It goes along with being into BJJ, chess, vim, keto, linters, and “the dominance hierarchy”. It’s annoying, but most everyone went through it. If you didn’t know better, how could they?

Yo! What's wrong with chess?

;-)

Re: Clean Code vs. A Philosophy Of Software Design

#489

Post by snapdaddy »

Scubabear68 wrote: post #297
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…

It is very instructional to read the source code to FitNesse framework. https://github.com/unclebob/fitnesse You can see how all his ideas come together into a ball of hundreds of almost empty classes, and gems such as "catch Throwable".

I was completely ready to agree with you, but the code that I browsed actually looked really good.

https://github.com/unclebob/fitnesse/blob/master/src/fitness...

Yup, OK, got it. The FitnessContext looks a bit rough, but no big deal.

https://github.com/unclebob/fitnesse/blob/master/src/fitness...

That's completely readable, I get it.

https://github.com/unclebob/fitnesse/blob/master/src/fitness...

Again, looks fine.

The main issue with all of these files is that there is quite a bit of boilerplate code, but that's Java's fault, not the code's fault.

I'm sorry, but I disagree. Looking for the most substantial pieces of code that I could find, and they look really good. I'm sure there are some little utils or something that look strange out of context, but I would be thrilled if I were called to work on legacy code and it was this nice.

Re: Clean Code vs. A Philosophy Of Software Design

#490

Post by valenterry »

Kerrick wrote: post #485
valenterry wrote: post #477

Earlier quoted context omitted.

> the order can decide whether to fulfill that request. In my world of thinking, orders don't make decisions. If I go to the business team and say "the order decided to" they'll look at me funny. And for good reasons.

Go back and read what I said about subject nouns and object nouns. When converting OO concepts to English for non-programmers, it is indeed confusing to say “the order decided not to”—you say “the order couldn’t be” instead. I highly recommend reading the two books I recommended for further perspective on the topic. OO is predicated not on the idea that data is a bag of dead bits on which operations are performed, bu…

> When converting OO concepts to English for non-programmers, it is indeed confusing to say “the order decided not to”—you say “the order couldn’t be” instead.

Passive language like "the order couldn't be" might be fine in some real world situations where I don't care about who caused the action. But in code I do care. Because somewhere in code the action has to be made. And yeah, you can put that logic into the Order entity, but then we are back to square one where "the order made the decision".

If we are talking about some event that happend, then sure, "the order was canceled" is perfectly fine. So making an "OrderWasCancelled" (or "OrderWasNotCancelled") object and storing it somewhere is intuitive. But we were talking about the action happening and that is a different thing.

Also, just to make that clear, I'm not talking just theoretically here. I started my career during the OOP hype time. I actually read books like head first design patterns and others about OOP. But ultimately, I found it's not productive at all, because it doesn't reflect how most people think - at least from my experience.

Therefore, I tend to write my code in the same way that non-technical people think. And it turns out, OOP is very far from that.

Post reply on HN