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

401–410 of 554 posts

Re: Clean Code vs. A Philosophy Of Software Design

#401

Post by bena »

ninetyninenine wrote: post #334
bena wrote: post #323

Earlier quoted context omitted.

That's definitionally untrue. Shitty code doesn't run or doesn't do what the author thinks it's supposed to do. You can't write genuinely shitty code and be smart. I've seen smart people get caught in trying to write "clever" code. Abusing features of a language to make the code "look" smart. And I've never seen someone I've considered smart write completely unformatted code where it matters. I may not agree with all…

[flagged]

Then say ugly. "Shitty" can be ambiguous as you see. Most people would classify buggy code as shitty code.

> Then you've never been around the smartest people. Likely you've been around smarter then average people.

This is essentially using your own belief as proof that your belief is correct. You say I haven't been around the smartest people because I say the smartest people don't do what you claim. You are saying "I'm right therefore you are wrong". Maybe you haven't been around the smartest people.

> Yeah and the smartest people structure the problem in their head in a way normal people can't easily understand. They can hold much more in their head so the structures can be complex.

Complex is easy. Simple is hard. And yes, some things are inherently more complex than others. But the goal is to hold the important things in your head. Offload as much as you can so you can focus on what matters.

> Isn't that my point? Formatting rules are a bunch of pointless minutiae to intelligent people. It doesn't assist them in readability because their intelligence allows them to parse even the shittiest code with complete ease. And I mean aesthetically shitty, not intrinsically shitty.

No. It's not the point you are making.

Also, look at to everything I said. Strict adherence to any one style is not a marker of intelligence. I explicitly said that strict adherence is essentially for people in a wide range of skills. But the best have preferences, but realize that they are more guidelines and readability matters more than the rules.

And the rules should be logical and essentially second nature. Like indenting is completely optional in most languages. But proper indenting allows you to better visualize the flow of the code. Nobody reads/writes minified JavaScript.

Re: Clean Code vs. A Philosophy Of Software Design

#402

Post by soulofmischief »

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…

On my Macbook Pro M2, having a browser window on one half of the screen, and my IDE on the other, with a file tree viewer pane and another pane for my LLM tools, a terminal pane at the bottom... I've never been more pressed for real estate for my actual code editing pane. Even 80 chars has me scrolling horizontally. Secondary monitors help but not when you frequently work away from your desk.

Re: Clean Code vs. A Philosophy Of Software Design

#403

Post by jdmoreira »

Uncle Bob probably the biggest scammer in Software. What a complete pile of garbage. So much energy wasted in all these design patterns, SOLID and other OOP bullshit.

Turns out you can just pass immutable data in and get immutable data out. Who would have guessed? The whole 90s - 00s Java OOP garbage still gives me nightmares

Re: Clean Code vs. A Philosophy Of Software Design

#404

Post by wglb »

switchbak wrote: post #370
wglb wrote: post #294

Earlier quoted context omitted.

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.

What UB's description of how to do TDD does not suggest that there are problems that require a different level of thinking and TDD as he describes, does not account for that.

Re: Clean Code vs. A Philosophy Of Software Design

#405

Post by kragen »

htk wrote: post #208
htk wrote: post #2

What a great discussion between two prominent figures in the field of software design. Thank you for posting this!

You guys really hated that I found the discussion interesting?

It seemed like a content-free comment. I was no better informed after reading it than before, and it was of no artistic or cultural value. It did not induce me to question any of my assumptions or investigate anything. It expressed your experience, but your experience was not unusual or surprising in any way, except perhaps that you did not know that "Uncle" Bob Martin was an incompetent charlatan. Possibly those were among the reasons people downvoted it.

Re: Clean Code vs. A Philosophy Of Software Design

#406

Post by ajross »

soulofmischief wrote: post #402
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…

On my Macbook Pro M2, having a browser window on one half of the screen, and my IDE on the other, with a file tree viewer pane and another pane for my LLM tools, a terminal pane at the bottom... I've never been more pressed for real estate for my actual code editing pane. Even 80 chars has me scrolling horizontally. Secondary monitors help but not when you frequently work away from your desk.

Coding on a laptop, even a name-drop-tier status shibboleth, is most of your problem. You write code on a 15" screen when you must for physical/location reasons. You shouldn't ever choose to do it or design your workflow around that constraint.

A 42" 4k TV (got it for $2-300 at the start of the pandemic) gives me four 80-90 column text windows on a mid-tier chromebook. You could not pay me enough to do that same work on a laptop, even a $4k MBP.

(But yes, even with lots of real estate 80 columns is still a net win)

Re: Clean Code vs. A Philosophy Of Software Design

#407

Post by runevault »

MobiusHorizons wrote: post #289
runevault wrote: post #34

Earlier quoted context omitted.

I always think of this as the programmer version of "No one got fired for choosing IBM." that was a common phrase about executives back in the day. Do the thing that you can just point to "experts" and blame them.

That is a helpful comparison. I guess it is risk aversion at the core. At some point risk aversion becomes abdication of decision making to others, which seems broken in roles that are specifically hired for making decisions, but that’s even more true of executives.

I completely agree with you, mind I feel the same way about the people who the original comment was talking about. They are paid the big bucks to decide how to spend money to optimize the company.

Re: Clean Code vs. A Philosophy Of Software Design

#408

Post by 0x20cowboy »

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?

Re: Clean Code vs. A Philosophy Of Software Design

#409

Post by kragen »

0xbadcafebee wrote: post #272

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

Software is unusual in that it's never finished. This makes ease of modification a critical quality of software in a way that it isn't for Formula 1 race car engines or most buildings.

Ease of modification was one of the top priorities in the design of the Model T Ford, because cars break down and must be repaired, and a car that is difficult or impossible to repair will cost its owner large sums of money. Software doesn't break down (though online services do) but for other reasons modification is a high priority.

Perhaps short-lived buildings don't need to be easy to modify, especially if the architects have a very good understanding of the needs of the users over their lifetimes. Often that is not the case, though, and Christopher Alexander was famous in large part because much of his career was devoted to figuring out how to enable inhabitants of buildings to modify them more easily, so that their needs would eventually be met even if the architects guessed wrong decades in the past. Centuries-old stone farmhouses exist, too, and ease of modification is crucial for them; if they cannot be modified they cease to function in only a century or two at most.

Whatever the goal of your software, it is crucial for the people who are modifying it over time to achieve that goal to be able to understand it.

Re: Clean Code vs. A Philosophy Of Software Design

#410

Post by bena »

kragen wrote: post #166
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 wouldn't recommend Code Complete today; I think The Practice of Programming covers most of the same material, is much shorter, is much better written, and isn't tainted by McConnell's later embrace of snake-oil methodologies, some of which made it into the second edition of CC. TPOP didn't exist when CC changed my world.

It's been a hot minute since I've read Code Complete. I don't have it on hand, but I'm pretty sure it was the second edition as it has the gray cover. And I'm pretty sure I got the second edition closer to when it was published than today.

I remember it being pretty decent back in the day. I can't remember any takes that were too hot in it. Honestly, I can only remember a general sense of satisfaction(?) with the book. If you were to ask me what exactly I took from Code Complete and applied in my job today, I couldn't tell you.

What would you classify as "snake oil" in it? Do they recommend Hungarian notation or something weird?

Post reply on HN