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

241–250 of 554 posts

Re: Clean Code vs. A Philosophy Of Software Design

#241

Post by pclmulqdq »

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…

Type systems and type-based coding patterns are very hip right now, but they weren't 6 years ago. That is partly because the type systems in the main languages in use 6 years ago were hack jobs (to put it politely).

I do expect the pendulum to swing against type systems at some point soon for the same reasons it swung against OOP: Too much heavy lifting done by something that's hidden from the programmer, encouraging people to be "too clever," etc. Like OOP, algebraic types are a tool that have to be used well, and the current users are people who really like type systems and do use them well. It's only a matter of time before the tool gets into the hands of the average programmer, and then we will see how terribly a great type system can hurt you.

Re: Clean Code vs. A Philosophy Of Software Design

#242

Post by bluGill »

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…

You have to read a lot of different code. Everyone thinks their code is good when they write it. Often old ugly code has a beautiful design still hidden behind many many requirements changes that didn't fit with the original design. Other code looks nice and beautiful but it will stand the test of requirement changes even worse than the other.

Re: Clean Code vs. A Philosophy Of Software Design

#243

Post by CyberDildonics »

lmm wrote: post #128
getnormality wrote: post #12

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?

Yes, I've worked on a couple of codebases like that. It's glorious, you break everything down little by little and every step makes sense and can be tested individually. Best jobs I've had.

These large compound statements look nice if they are perfect, but when you make giant expressions without intermediate variables, it is much more difficult to test.

When you have small expressions that have incremental results stored in variables, you can see the result in a debugger so you can see each stage.

Re: Clean Code vs. A Philosophy Of Software Design

#244

Post by hakunin »

edwardsdl wrote: post #77
hakunin wrote: post #32

Earlier quoted context omitted.

Another example of not quite pragmatic advice is Screaming Architecture. If you take some time to think about it, it’s actually not a good idea. One of the blog posts I’m working on is a counter argument to it.

I’d love for you to expand on this!

Short version: when designing new software, you don't have its architectural picture in the beginning. So when starting from scratch, the architecture shouldn't be screaming, but rather, it has to be non-committal/non-speculative to allow wiggle room for the future. (How to achieve non-committal architecture is the biggest topic I'm interested in, and I find 1 good tactic every few years). Specifically, the architecture should ephasize entry points and outputs. That's exactly what frameworks like Rails provide. You go by entry points until some sort of custom architecture starts emerging from the middle, which is when it can slowly begin "screaming" over time.

Re: Clean Code vs. A Philosophy Of Software Design

#245

Post by froh »

chillpenguin wrote: post #26
ilrwbwrkhv wrote: post #3

john ousterhout's book is the only book on how to write software that has any actual evidence behind it. i highly recommend it as the only book to read on how to write code. and uncle bob, well, best to avoid his stuff as much as possible. clean code takes away about 5 years from every dev's life as they think they need to read it to become an intermediate developer and one they realize that is not the way, can they…

"john ousterhout's book is the only book on how to write software that has any actual evidence behind it." This is false and hopefully no one takes you seriously when they read that. There are books about empirical methods for software engineering, for example, which actually seek to find real evidence for software engineering techniques. See Greg Wilson's work, for example. There are lots of other architecture/desig…

Greg Wilson indeed is tremendously helpful in facilitating "the industry" to think about our craft:

https://github.com/gvwilson

edit: wow, in his project "It will never work in theory" he's fairly sober about the ability of "the industry" to reflect on "the craft"

https://neverworkintheory.org/

> about the project:

> People have been building complex software for over sixty years, but until recently, only a handful of researchers had studied how it was actually done. Many people had opinions—often very strong ones—but most of these were based on personal anecdotes or the kind of "it's obvious" reasoning that led Aristotle to conclude that heavy objects fall faster than light ones.

in the 2024 retrospective:

> Conclusion

> The comedian W.C. Fields once said, “If at first you don’t succeed, try, try again. Then quit. There’s no point in being a damn fool about it.” Thirteen years after our first post, it is clear that our attempts to bridge the gulf between research and practice haven’t worked. We look forward to hearing what actionable plans others have that will find real support from both communities.

Re: Clean Code vs. A Philosophy Of Software Design

#246

Post by mlinhares »

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…

Because its easy to be dogmatic, you don't need to think, consider the consequences or drawbacks, you just follow whatever the Supreme Leader told you to do.

Its incredibly simple to just follow whatever someone is telling you to do, sometimes I wish I could live like this so I didn't have to fight with the people that do all the time.

Re: Clean Code vs. A Philosophy Of Software Design

#247

Post by CyberDildonics »

getnormality wrote: post #12

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?

John Carmack would disagree with Uncle Bob and John Carmack actually programs.

My own experience is that with an IDE that can collapse a new scope in the middle of a function, you can make large functions that accomplish a lot and are very clear by writing a comment and starting a new scope.

If something is going to be called multiple times a new function makes sense, but this idea that anything that can eventually return a single value needs to be it's own function is a giant pain that creates more problems than it solves.

Just makeing a new scope in the middle of the functions lets you use all the variables in the outer scope, do transformations without introducing new variables and ultimately "return" a new variable to the outer scope.

I've never understood why polluting namespaces with dozens or hundreds of names (most of which may not be very descriptive since naming a hundred small things is already going to be confusing) is seen as a good idea. You look at a list and you have no idea what is important and what was being shoved in there to satisfy some do nothing public speaker's arbitrary rules.

Re: Clean Code vs. A Philosophy Of Software Design

#248

Post by felizuno »

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.

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

Re: Clean Code vs. A Philosophy Of Software Design

#249

Post by Ma8ee »

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…

Or maybe the smartest people understand that it is as important that less smart/experienced people than them can work with the code.

Re: Clean Code vs. A Philosophy Of Software Design

#250

Post by NeutralForest »

ninetyninenine wrote: post #232
NeutralForest wrote: post #221

Earlier quoted context omitted.

But there are typical practices we agree are good: using a VCS, writing tests, write comments when needed, separate different level of abstractions, etc. Right? This comes from years of common experience in software. Over time we get to find patterns, common issues and ways to fix them, etc. It doesn't have to be strict patterns but overall strategies. If we don't do that then it's just vibes right? Where's the engin…

Nothing is fixed in stone. If you have strong typing and program with pure functions and immutability while utilizing union types and matching to the full extent you typically need very few unit tests for your code to work. You just need integration and e2e tests. I write very little unit tests as my coding style that employs static checks as viciously as possible doesn’t necessitate it. I would say only 30 percent o…

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.

Post reply on HN