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

Re: Clean Code vs. A Philosophy Of Software Design

#321

Post by ninetyninenine » Tue, Feb 25, 2025, 4:42 PM UTC

LudwigNagasena wrote: post #290

ninetyninenine wrote: post #225

Earlier quoted context omitted.

Yes. This works but only if the functions are pure and using pure function composition. Uncle bob doesn’t mention this. createspecialString(y) = Capitalizefirstletter . MakealllowerCase . AddNumberSuffix . removeLetterA . removeLetterB . ConcatwithWord(x) CapitalizeFirstLetter(a) = a[0].upper() + a[1:] MakeAllLowercase(a) = map(a, (t) => t.lower()) Addnumbersuffix(a) a + 3.toString() RemoveLetterA(t) = filter(t, (s)…

`createspecialString` is seven lines long though.

Then split it. All pure functions are easily decomposed into the most primitive units so even the most dogmatic ass hole can't talk shit.

   createSpecialString = createFormattedString . createNewString

   createFormattedString = 
       Capitalizefirstletter .
       MakealllowerCase .
       AddNumberSuffix .


   createNewString(y) = 
       removeLetterA .
       removeLetterB .
       ConcatwithWord(x)

Or put it all on one line.

      createspecialString(y) = Capitalizefirstletter . MakealllowerCase . AddNumberSuffix . removeLetterA . removeLetterB . ConcatwithWord(x)

The amount of lines becomes off topic once you get into this style. It's a completely orthoganol concept as it's completely irrelevant to readability and modularity.

Lines doesn't makes sense for pure non imperative functions. Lines ONLY make sense for imperative functions because each line represents an instruction.

Re: Clean Code vs. A Philosophy Of Software Design

#322

Post by [deleted] » Tue, Feb 25, 2025, 4:47 PM UTC

jghn wrote: post #207

seanwilson wrote: post #57

I find the lack of discussion of type systems really surprising in these sorts of discussions and books. Effective use of type systems is a killer factor for me for creating clean, safe, readable and maintainable software designs. When used correctly, strong static type checking make certain kinds of bugs impossible, spare you from writing many kinds of tedious tests that often get in the way of refactoring, serve as…

Because the pendulum of typing hadn't swung back to static being in vogue when the Philosophy of Software Design came out. At the time you had mostly the Scala & Haskell people standing in a corner screaming until they (well, we as I was one of them) were blue in the face about reducing "certain types of bugs", and making impossible states impossible. Since then, everyone and their brother is on the static typing tra…

[deleted]

Re: Clean Code vs. A Philosophy Of Software Design

#323

Post by bena » Tue, Feb 25, 2025, 4:48 PM UTC

ninetyninenine wrote: post #211

bena wrote: post #192

Earlier quoted context omitted.

I’ve noticed the worse someone is in a language, the worse they format it. People then develop fastidious code formatting rules because they realize well formatted code is easier to read and extend. Then people realize it’s the organization of the code, not the rules themselves. They have preferences, but don’t treat those preferences as “the one true way”. So people with fastidious rules are in that middle ground of…

Disagree. Highly disagree. Smarter people write shittier code. Clean code is for stupider people. Think about it. It’s because smart people don’t need clean code. It’s so trivial to them and so readable that they really don’t need things to be ultra clean and well formatted. So the tendency to have this ocd need to write clean code among smart people is random. They either have it or they don’t give a shit. But among…

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 of their choices, but the smartest people I've worked with tend to have the structure of the code reflect the structure of the problem as they see it in their head. And yes, that tracks, you begin to use the code itself as an assistant to your own thinking. You don't think about where things are because they are where they should be.

Forcing yourself to remember a bunch of pointless minutiae in order to write software isn't a mark of intelligence, it's a mark of someone who wants to be seen as intelligent.

Re: Clean Code vs. A Philosophy Of Software Design

#324

Post by trevor-e » Tue, Feb 25, 2025, 4:48 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…

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 some reason it always results in code that looks like the Enterprise FizzBuzz meme repo.

Re: Clean Code vs. A Philosophy Of Software Design

#325

Post by jsbg » Tue, Feb 25, 2025, 4:51 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…

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

Re: Clean Code vs. A Philosophy Of Software Design

#326

Post by ninetyninenine » Tue, Feb 25, 2025, 4:51 PM UTC

coliveira wrote: post #317

ninetyninenine wrote: post #205

Earlier quoted context omitted.

Well I mean they wrote books about it and one guy had the audacity to call his opinion a “philosophy” even though it’s just an arbitrary opinion. Most of software is about assigning big words and over complicated nomenclature to concepts and these things masquerade as things with deeper meaning when in reality it’s just some made up opinion. Software design is an art. It is not engineering and it is not science. That…

The issue is that programming is communication. Communication is indeed a form of art. Programming is not just giving instructions to machines, if that was the case we would be happily using binary code. So we have two dimensions, the first one is giving the binary instructions, but the other one is how to make these instructions understandable by humans, including ourselves.

No there are other dimensions to coding. Communication is ONE dimension only.

There is optimization and there is modularity. All 3 of these dimensions are intimately tied and correlated.

Re: Clean Code vs. A Philosophy Of Software Design

#327

Post by seanwilson » Tue, Feb 25, 2025, 4:53 PM UTC

WillAdams wrote: post #65

seanwilson wrote: post #57

I find the lack of discussion of type systems really surprising in these sorts of discussions and books. Effective use of type systems is a killer factor for me for creating clean, safe, readable and maintainable software designs. When used correctly, strong static type checking make certain kinds of bugs impossible, spare you from writing many kinds of tedious tests that often get in the way of refactoring, serve as…

That was exactly the approach taken by Prof. Ousterhout in setting up the class which lead to this book --- rather than just having students turn in working code for a grade, the code is reviewed with the student and the student then works to make it better --- in turn, the 2nd edition of the book was informed by the experience of teaching the class and the author actually changed his position based on the experience…

Why is that convincing though? Students aren't experienced coders, aren't working in large teams, and student assignments aren't like long-term large commercial projects.

If you mean the additions here https://web.stanford.edu/~ouster/cgi-bin/book.php, I read these and it still sounds like general rules of thumb you'll only really learn and understand by practicing a lot e.g. "In my experience, the sweet spot is to implement new modules in a somewhat general-purpose fashion" "Having good taste is an important part of being a good software designer".

Re: Clean Code vs. A Philosophy Of Software Design

#328

Post by felizuno » Tue, Feb 25, 2025, 4:53 PM UTC

wesselbindt wrote: post #274

felizuno wrote: post #248

Earlier quoted context omitted.

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…

I'm not seeking these people out to hate on them, but when I encounter them the social and code environments around them always exhibit the same dysfunctions. I've seen it multiple times. When your team is threatening to quit because they can't stand working with you, the problem is _probably_ with you and not them. And when you get fired and bugs go down, velocity goes up, and the morale problems disappear, it's now obvious that the problem was you. It's not a hand wavy theoretical take, it's a consistent pattern from dozens of instances at a variety of companies.

Re: Clean Code vs. A Philosophy Of Software Design

#329

Post by ninetyninenine » Tue, Feb 25, 2025, 4:54 PM UTC

yakshaving_jgt wrote: post #279

ninetyninenine wrote: post #255

Earlier quoted context omitted.

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.

Yeah. That's where it should be. Usually though you don't need much parsing as it's coming in as json or a protobuf. But the interface between IO and your code program is where exceptions and errors can occur. Beyond this boundary your code should be pure and deterministic.

Since you're doing your own parsing rather then using schema validators and existing formats like json, yes your code is doing A LOT of data processing and thus requires a lot of unit tests. Most of the time developers can trust the parsing libraries.

Re: Clean Code vs. A Philosophy Of Software Design

#330

Post by wglb » Tue, Feb 25, 2025, 4:55 PM UTC

namuol wrote: post #110

acmj wrote: post #49

Earlier quoted context omitted.

You need to know what is good code. Opinions may vary a lot between programmers, even senior ones. The Clean Code cult would tell you to find good code there but that is the most poisonous programming book I have read.

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…

> Forget about the code itself and focus on the results.

This reminds me of what Dijkstra said (paraphrasing): the computation is the important thing, not the code.