Live data from Hacker News

Clean Code vs. A Philosophy Of Software Design

github.com

181–190 of 554 posts

Re: Clean Code vs. A Philosophy Of Software Design

#181

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? Honestly, no better indication of a very mediocre developer

My experience is that being fastidious about code formatting is independent of one's ability as a developer. i.e. not a good indicator either way.

Re: Clean Code vs. A Philosophy Of Software Design

#182

You just need to work on one project built by someone that implemented Uncle Bob recommendations blindly when the books came out to know how much they are worth. There were some low hanging fruits to pick at the time regarding trying to be better at software engineering and he generated some text about them. Full of terrible advices, he never wrote anything significant (in scope and notoriety) during his time as a so…

(English tip: advice isn't a countable noun, so you don't pluralise it) I agree entirely. My encounters with Uncle Bob were as a junior developer receiving advice [no "s"] from other junior developers. And yes, I too find it suspicious how many mavens of the "Agile era" never really managed to ship anything.

Thanks for the correction, my opinion on the lack of credentials is that in the early days you just didn't need them to become popular, so little content that no one checked. I bit like it's happening nowadays with the anime profile pic twitter accounts acting like they invented AI, with zero code or achievements being shown.

Re: Clean Code vs. A Philosophy Of Software Design

#183
post #171

I have worked with a couple of people over the years who instead of breaking functions out when something would say make sense to be reused or made some sort of logical sense as a unit, instead seemingly just bundle lines whose only real relationship was that they happened to be near each other when they decided to "refactor". Having read Clean Code back in college as it was assigned reading, it was absolutely the vi…

The warning sign I see when methods are split too much is that the method boundaries start to get messy: methods take too many arguments, or state is saved into confusingly named class members, or you end up returning some struct containing a grab bag of unrelated values.

Re: Clean Code vs. A Philosophy Of Software Design

#184
post #35
post #31

Earlier quoted context omitted.

What's there to dislike so much in APOSD? The book struck me as giving mostly reasonable advice, none is which was overly prescriptive. None of the things I disagreed with struck me as egregious .

Here's mostly from what I wrote down after reading it. Indeed, the "reasonableness" is part of the problem. What's agreeable is mostly only so because it's such a straightforward platitude. "Things that are not important should be hidden, and the more of them the better. But when something is important, it must be exposed." Ok? Anyone want to argue to the contrary? This is not teaching or learning anything new or of…

What definition of complexity in the context of discussing software development and architecture would you put forward instead?

Re: Clean Code vs. A Philosophy Of Software Design

#185

It's sad that we demoted the field from engineering to philosophy. But it is what it is. Next step - fashion and belief.

It's an improvement over demagoguery and blind rule-following.

Moreover, the book argues for engineering principles (in pretty much all possible senses of that phrase).

Re: Clean Code vs. A Philosophy Of Software Design

#186

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.

Re: Clean Code vs. A Philosophy Of Software Design

#187

This was such a riveting and literary read, I enjoyed it and couldn’t put it away, like a novel where I was invested in the characters! Are there any other such reads in the software engineering field?

Knuth?

He has argued in the past that the concept of Literate Programming

http://literateprogramming.com/

is the most important work he has done, and I highly recommend his various collections of lecture notes/papers including:

https://www.goodreads.com/book/show/112245.Literate_Programm...

Re: Clean Code vs. A Philosophy Of Software Design

#189

Earlier quoted context omitted.

I'm not familiar with the Clean Code book etc; my introduction is the article. UB seems to be advocating consistently for patterns that are not my cup of tea! For example: Functions sometimes make sense as 2-3 lines. Often 5-20. Less often, but not rarely, much more than that! I'm also a fan of detailed doc comments on every module and function, and many fields/variants as well. And, anything that needs special note,…

The issue that of function length is irrelevant and incidental. Keep paying attention to what UB is saying.

I didn't get that impression from reading it. I also find the TDD approach discussed to be high inertia.

Re: Clean Code vs. A Philosophy Of Software Design

#190
post #37

I've enjoyed both books but Uncle Bob is something you grow out of. He was a bit of a cult figure at the time. Trying to actually follow the guidelines in Clean Code taught me a lot about "over-decomposition" and, ultimately, how not to write code. It reminds me it's possible to take aesthetics so far the results become ugly. Fussing over a proliferation of small functions that do only one thing is a kind of madness.…

> You are left sifting through the ashes of your program wondering "Where did I go wrong?"

Brilliantly phrased metaphor, thank you.

Post reply on HN