Live data from Hacker News

Clean Code vs. A Philosophy Of Software Design

github.com

361–370 of 554 posts

Re: Clean Code vs. A Philosophy Of Software Design

#361
post #154
post #110

Earlier quoted context omitted.

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…

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.

It’s interesting that we just assume a newer language produces “better code”

Re: Clean Code vs. A Philosophy Of Software Design

#362

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?

fwiw Lines-of-Code / Method (Digitalk V/286 image, 1989) = 7

https://dl.acm.org/doi/10.1145/74878.74904

Re: Clean Code vs. A Philosophy Of Software Design

#363
post #325

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…

> Who else has had to deal with idiots who froth at the mouth when you exceed an 80 line character margin? Not once in my 11 year career. But almost every codebase I've worked on has had debilitating maintainability issues because the only principle other engineers seemed to follow was DRY, at the sacrifice of every principle in SOLID.

Most code that i clean up is a lot easier to maintain after making it a lot DRYer.

The point is not about being DRY, on itself, though. The point is that the code then has better abstractions which are easy to reason about.

UB seems to take abstractions a lot too far, replacing e.g. 2 lines of very clear code with some cleartotals abstraction.

Re: Clean Code vs. A Philosophy Of Software Design

#364

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…

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

I love reading books for different perspectives.

However, I’ve come to despise people who read books and then try to lord their book knowledge over others. These are the people who think that they have the upper hand in every situation because they read some books. They almost always assume you haven’t read them. If you point out that you have also read them, they switch the subject to another set of books they read because they don’t like when someone tries to undermine their book knowledge superiority.

It’s even worse when the person reads books outside of their domain and tries to import that book knowledge into the workplace. The absolute worst manager I had was a guy who read a lot of pop-psychology books and then tried to psychoanalyze each of us according to those books.

Re: Clean Code vs. A Philosophy Of Software Design

#365
post #90

Earlier quoted context omitted.

> Comments is a self-admission you failed to write readable code, and you can fix your failure by refactoring code into self-descriptive member functions This may be true for some cases, but I don't see a non-contrived way for code to describe why it was written in the way it does or why the feature is implemented the way it is. If all comments are bad, then this kind of documentation needs to be written somewhere el…

> This may be true for some cases, but I don't see a non-contrived way for code to describe why it was written in the way it does or why the feature is implemented the way it is. I have to call bullshit on your argument. Either you aren't even looking because you have the misfortune of only looking at bad code written by incompetent developers, or you do not even know what it looks like to be able to tell. The core p…

> I'm starting to believe all these vocal critics who criticize Uncle Bob or Eric Evans or any other author are actually talking out of sheer ignorance about things they know nothing about.

I've been programming for 60 years in many different fields. I was programming long before he was. It is possible that I have written more code than he has in more languages (36 at last count), so my criticism of his are based on real-world experience.

Re: Clean Code vs. A Philosophy Of Software Design

#366

Earlier quoted context omitted.

We have a disagreement about the core of OOP. In English, a simple sentence like "The cat eats the rat" can be broken down as follows: - Cat is the subject noun - Eats is the verb - Rat is the object noun In object-oriented programming, the subject is most often the programmer, the program, the computer, the user agent, or the user. The object is... the object. The verb is the method. So, imagine the sentence "the cu…

> So, imagine the sentence "the customer canceled the order." > - Customer is the subject noun And this is wrong. Because the customer did not cancel the order. The customer actually asked for the order to be canceled. And the order was then canceled by "the system". Whatever that system is. And that is the reason why it is not expressed as customer.cancel(order) but rather system.cancel(order, reason = "customer ask…

mrkeen mentioned dependency inversion (DI). I think it makes sense in oop for an order to have a cancel method, but the selection of this method might be better as something configured with DI. This is because the caller might not be aware of everything involved, as well.

If the system is new and there's only one way to do it, it's not worth sweating over it. But if a new requirement comes up it makes sense to choose a way to handle that.

For example, an order may be entered by a salesperson or maybe by a customer on the web. The cancellation process (a strategy, perhaps) might be different. Different users might have different permissions to cancel one order or another. The designer of the website probably shouldn't have to code all that in, maybe they just should have a cancel function for the order and let the business logic handle it. Each order object could be configured with the correct strategy.

If you don't want to use OO, that's fine, but you still have to handle these situations. In what module do you put the function the web designer calls? And how do you choose the right process? These patterns will perhaps have other names in other paradigms but the model is effectively the same. The difference is where you stuff the complexity.

Re: Clean Code vs. A Philosophy Of Software Design

#367

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 cringe thinking about PR comments I left early in my career. "akshually this should try to follow more SOLID principles" But, coming from a formal engineering background, I thought this is what it meant to be a professional software engineer. Little did I know these "principles" were just the musings of a consultant lol. Turns out most folks have good intentions and want a standardized way to write code, but for so…

The mark of a good engineer is knowing when this sort of handwaving is actually meaningful and helpful. Formality for its own sake is anti-pattern, but who am I telling?

Re: Clean Code vs. A Philosophy Of Software Design

#368
post #269

Earlier quoted context omitted.

Okay so your definition of “smart” sounds different than the definition everyone else in this thread is using. Sounds more like you’re talking about “genius” to me, specifically in a savant type way where they are incapable of relating to average people.

No. I’m talking about genius. Not savant. Savants likely can’t relate to your emotions. Geniuses can. The difference is just if it takes them 1 second to parse what takes you 5 minutes to do the same they often don’t realize this unless you tell them. That being said what I talk about lives on a gradient. The smarter you are the greater degree of tendency you have to write shitty code. The cleaner your code the highe…

This is the silliest thing I've ever heard

Re: Clean Code vs. A Philosophy Of Software Design

#369

Earlier quoted context omitted.

Code like Uncle Bob suggests is not easier to read and understand, it is harder, IMO and that of many others. Since the disagreement starts from this any further discussion is impossible.

[flagged]

> Shit-talking while hand-waving adds nothing to the discussion.

This is not presuming good faith, as he guidelines ask that we do.

Re: Clean Code vs. A Philosophy Of Software Design

#370
post #294

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…

Yes, Uncle Bob is certainly capable of being pedantic. A friend of mine, a Smalltalk Consultant, partnered with him for a while. "With Uncle Bob, it's his way or the highway." His clean code work is certainly pretty dogmatic. As I recall, he says that Java is not object oriented. But if my memory serves me correctly, his book about C++ (Designing Object-Oriented C++ Applications Using the Booch Method) has some excel…

Wasn’t that Ron Jeffries who failed to solve that?

I think that says more about the person at the keyboard and their lack of familiarity with the solution space than anything about TDD per-se. You still need insight and design with TDD, blind incrementalism was never a good idea.

Post reply on HN