Clean Code vs. A Philosophy Of Software Design • Hacker News Board

Re: Clean Code vs. A Philosophy Of Software Design

#271

Post by dkarl » Tue, Feb 25, 2025, 3:33 PM UTC

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…

> Keeping the code organized is useful and is a part of basic hygiene, but it's far from the defining characteristic of the craft.

I'm with you, but I don't think it makes sense to elevate one absolutely over the other as the "defining characteristic." Either one can tank the development of a piece of software and prevent it from coming into being in a useful way.

Arguments about which aspects of software are more important than others usually arise between people who have personally suffered through different ways that projects can fail. Any aspect of software development will feel like the "defining characteristic" if it threatens to kill your project.

Re: Clean Code vs. A Philosophy Of Software Design

#272

Post by 0xbadcafebee » Tue, Feb 25, 2025, 3:36 PM UTC

> For me, the fundamental goal of software design is to make it easy to understand and modify the system. I use the term "complexity" to refer to things that make it hard to understand and modify a system.

This explains everything that's wrong with modern software.

When you design a Formula 1 race car engine, the purpose of engine design is not to "make the engine easier to modify". It's to win races. And that depends on the race - a funny car engine, a formula 1 engine, a LeMans engine, Nascar engine, etc, are all different because the races are different.

Another example: when you design a building, the goal isn't to make it easier to understand the building. The goal is to meet the requirements of the building, its uses, requirements, environment, etc. Sometimes a better building is just more complicated, and making the architect or builders' jobs easier, while nice, isn't the goal.

Some things aren't supposed to be easy to understand, because ease of understanding is not the goal of the thing. Focus on the real goal of the thing, and achieving that; don't get distracted by ancillary goals.

Re: Clean Code vs. A Philosophy Of Software Design

#273

Post by leidenfrost » Tue, Feb 25, 2025, 3:36 PM UTC

tempodox wrote: post #254

leidenfrost wrote: post #210

Earlier quoted context omitted.

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

What are “SSR and SR devs”?

Semi Senior and Senior devs

Re: Clean Code vs. A Philosophy Of Software Design

#274

Post by wesselbindt » Tue, Feb 25, 2025, 3:37 PM UTC

felizuno wrote: post #248

wesselbindt wrote: post #186

Earlier quoted context omitted.

> idiots who froth at the mouth That seems like an unnecessarily harsh way to refer to people.

Clean Code zealots are consistently some of the least likable, least productive, least pragmatic people I have ever worked with. I've had multiple clients where the whole team is threatening to quit unless the CC zealot is fired. And when they are fired guess what - bugs go down, shipped features go up, and meetings become productive. "Idiots who froth at the mouth" is an understatement IMO

This too seems like a fairly hardline stance to take. I think it's not surprising that you'd have a hard time collaborating with people you'd refer to as unlikeable, unproductive, unpragmatic, overzealous, frothy idiots.

It reminds me of the standard joke about veganism: "how do you know someone is vegan? Don't worry they'll tell you"

It's a very ironic joke, because the people I hear talking about veganism the most are non-vegans complaining about veganism. In this thread too. All I see is people complaining about how dogmatic clean code people are, and I see no examples of that in this thread. The only strong and absolute language I see is from those who are complaining about CC people.

Bear in mind, I don't have a dog in this fight. I'm not vegan, my methods are sometimes longer than four lines, and I do occasionally write a comment. But if this thread is anything to go by, the clean code folks seem a lot nicer to work with than the reactionaries.

Re: Clean Code vs. A Philosophy Of Software Design

#275

Post by jpitz » Tue, Feb 25, 2025, 3:37 PM UTC

"Do One Thing" is to me maybe best understood in the context of the Single Layer Of Abstraction Principal - it has helped me numerous times to be very intentional about following SLAP in complex code, and Do One Thing seems to fall very naturally out of it.

Re: Clean Code vs. A Philosophy Of Software Design

#276

Post by yakshaving_jgt » Tue, Feb 25, 2025, 3:38 PM UTC

wesselbindt wrote: post #186

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…

> idiots who froth at the mouth That seems like an unnecessarily harsh way to refer to people.

Maybe they had mistaken "code" for "teeth"?

Re: Clean Code vs. A Philosophy Of Software Design

#277

Post by nadam » Tue, Feb 25, 2025, 3:41 PM UTC

I was just thinking about what AI assisted coding brings to the design discussion, especially as AI become more and more powerful and we rely on it more and more. You still want to make things modular and easy to understand so that AI understands it easily and the needed info to modify a module can fit in a relatively small context window, but the difference is that it is very easy to make large scale measurement about which code style is understood better by an LLM, so maybe some of these debates will be decided relatively objectively!

For the topic: the discussed topics are relatively trivial surface level stuff, mostly I agree with POSD, but these will be handled by AI anyway. I guess humans will use the spare brain capacity to deal with the real deep design questions (for a while).

Re: Clean Code vs. A Philosophy Of Software Design

#278

Post by crabbone » Tue, Feb 25, 2025, 3:41 PM UTC

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…

Professionals in other industries don't "just" write books. In a sense that usually the field has several acclaimed authors and they put some solid work into ensuring their books make sense. While there are disagreements in other fields, or some nonsense conventions, the conventional wisdom is usually at least good enough to make you a good professional.

In programming it's the Wild West. Many claims are made based on nothing at all. It's very rare to see any kind of sensible research when it comes to the science part of CS. But following rules makes life easier. Even if rules are bad. That's kind of why conservatism exists as a political idea.

Re: Clean Code vs. A Philosophy Of Software Design

#279

Post by yakshaving_jgt » Tue, Feb 25, 2025, 3:41 PM UTC

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…

I write a big web application with a fairly type-oriented language, and I still write lots of unit tests. Mostly to do with parsing.

Re: Clean Code vs. A Philosophy Of Software Design

#280

Post by dgb23 » Tue, Feb 25, 2025, 3:42 PM UTC

bluGill wrote: post #227

dgb23 wrote: post #201

Earlier quoted context omitted.

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.

Clean Code is trying to operate at a layer far more important than efficiency: code maintenance. In the vast majority of cases computers are fast enough that you don't need to worry about efficiency. (part of this is any modern language provides all the common algorithms that are already highly optimized and easier to use than the writing them by hand and so the common places where you would want to worry are already…

From personal experience, the most time consuming maintenance issues arise because of the following things:

- third party dependencies, compatibility issues, breaking changes

- code that is bloated with abstractions and indirection

- performance issues, especially when worked around via caching etc.

- bad error handling

- inconsistent data

Simpler code that can be followed and stepped through in a straight forward manner avoids 3/5 of these from the get go. Patterns and abstractions that emerge over time are sometimes beneficial. Legacy code or third party code that overuses abstractions is really more of a hindrance and significantly slows down how fast I can understand, own and fix things.