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

521–530 of 554 posts

Re: Clean Code vs. A Philosophy Of Software Design

#521

Post by ben_w »

jsbg wrote: post #325
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.

Lucky.

I've had one which violated DRY and every SOLID principle…

Well, Liskov might not have been violated, but it was hard to tell what with all the other nonsense in the 120 kloc of copy-pasted pantheon of god-classes that showed flagrant disregard for things so fundamental that you wouldn't think anyone even could even get them weird, e.g. the question of "how are properties defined" being "solved" by having an array which was indexed by named constants… and because it was a god class, which items in that array ever got instantiated depended on which value was passed to the constructor.

Eventually, I found they'd blindly duplicated an entire file, including my "TODO: deduplicate this method" comments, rather than subtype — and their excuse when called out on this was the access modifier, as if changing "private" to "public" was hard.

Re: Clean Code vs. A Philosophy Of Software Design

#522

Post by soulofmischief »

notachatbot123 wrote: post #505
soulofmischief wrote: post #402

Earlier quoted context omitted.

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.

Why only use half the screen for your IDE? Your brain has to switch anyways so just make your IDE and browser fullscreen windows and alt-tab when needed.

In iterative web development the instant feedback is crucial and constantly alt-tabbing is tedious and breaks the flow. When necessary, it's simple to temporarily maximize the window.

Re: Clean Code vs. A Philosophy Of Software Design

#523

Post by narnarpapadaddy »

tremon wrote: post #431
kragen wrote: post #345

Earlier quoted context omitted.

Sounds like you haven't ever tried to implement it. But if the "case" you're thinking of is the "case" narnarpapadaddy was referring to, that takes us to their clause, "Any fewer [cases], the additional abstraction is unneeded complexity." This is obviously absurd when we're talking about the sin() function. Therefore, that can't possibly have been their intended meaning.

The alternative and more charitable interpretation, of course, is that a single function like sin() is not what said GP meant when using the word "interface". But hey, don't let me interrupt your tilting at straw men, you're doing a great job.

Appreciate the charitable interpretation. Both “complexity“ and “abstraction” take many different forms in software, and exceptions to the rule-of-thumb abound so it’s easy to come up with counter examples. Regardless, thinking in terms of complexity ratios has been a useful perspective for me. :)

IMO, a function _can_ be an interface in the broadest sense of that term. You’re just giving a name to some set of code you’d like to reuse or hide.

Re: Clean Code vs. A Philosophy Of Software Design

#524

Post by ninetyninenine »

bena wrote: post #520
ninetyninenine wrote: post #458

Earlier quoted context omitted.

It came up because we talked about Mensa and he was part of it. I asked his iq and he told me. He claimed it and I believe him. Then the other guy also said he was offered to join Mensa but didn’t. Take from that what you will.

So we're talking about two people? Not a huge sample size. Not to mention, 150+ puts one in the 99.9th percentile. One in a thousand. So out of every thousand people you meet, one of them probably had an equivalent IQ. That being said, I guarantee that there are way more people on these boards with equivalent levels of intelligence and that those people also know several people with equivalent levels of intelligence.…

[flagged]

Re: Clean Code vs. A Philosophy Of Software Design

#525

Post by kragen »

bena wrote: post #519
kragen wrote: post #449

Earlier quoted context omitted.

I read some of the more questionable parts of the second edition just now, and while I think there are a lot of things to criticize in it, I suspect that it's just rose-tinted hindsight, or ignorance, that made me not object to them in the first edition; I'm pretty sure most of these problems were already there: - All the time wasted on the dumb "construction" analogy. - The total lack of attention to open-source sof…

That is quite a bit more thorough than I either expected or wanted. So, for that, many thanks. Although in your excellent break down of the shortcomings of the book, you kind of make me want to go back and re-read it myself. Just to experience it from my current vantage point. To see where I disagree with the book now. > Code Complete's table of "Average Cost of Fixing Defects Based on When They're Introduced and Det…

You're welcome!

You, and I, and the entire software industry, it turns out.

https://buttondown.com/hillelwayne/archive/i-ing-hate-scienc... is the best summary I've found on that.

> Are Late-Stage Bugs More Expensive?

> (...) While there's no smoking gun, I think the body of research so far tentatively points in that direction, depending on how you interpret "late-stage", "bugs", and "more expensive". This is a newsletter, not a research paper, so I'll keep it all handwavey. Here's the rough approach I took to reach that conclusion:

> Some bugs are more expensive than others. You can sort of imagine it being a Gaussian, or maybe a power law: most bugs are relatively cheap, a few are relatively expensive. We'd mine existing projects to create bug classifications, or we'd interview software developers to learn their experiences. Dewayne Perry did one of these analyses and found the bugs that took longest to fix (6 or more days) were things like feature interaction bugs and unacceptable global performance, in general stuff that's easier to catch in requirements and software modeling than in implementation.

> I've checked a few other papers and think I'm tentatively confident in this line of reasoning: certain bugs take more time to fix (and cause more damage) than others, and said bugs tend to be issues in the design.

As I see it, this is not so much about how long the bug has been in the system but about what kind of bug it is. Unacceptable global performance or fundamentally incompatible requirements often kind of require you to restart your system from scratch, which means throwing away a lot of your code. But that doesn't mean that it's trivial to detect them (necessary to fix them) before you've written a lot of code, and throwing away all your code and design documents doesn't mean you're actually starting from scratch, because programming is theory building, not building construction. If writing "the same program" a second time takes you 30% of the time it took you to write it the first time (but the right way), in a sense you retained 70% of the work you did from the first time, even if not a line of code is the same. (Of course, a "bug" that costs 30% of the total project budget is a pretty big bug...)

Also, with iterative development, a requirements or design bug can be introduced very late in the project. Emacs has been around for 40 years but only got native-code compilation for Elisp (a huge requirements and design change containing, probably, many requirements and design bugs) in the last 6 years. 85% of Emacs development was before that. And people were testing it within months of embarking on adding it.

Re: Clean Code vs. A Philosophy Of Software Design

#526

Post by WillAdams »

Jach wrote: post #498
WillAdams wrote: post #496

Earlier quoted context omitted.

I don't see that that is markedly different in function from the definition provided by Ousterhout, or at least both seem to describe to me the same concept, just using different words/terms/analogies. >For the purposes of this book ... complexity is anything related to the structure of a software system that makes it hard to understand and modify the system. >Complexity: things twisted together. You can count the th…

> Presumably twisting makes things harder to understand and having more things requires a greater effort at understanding? This is exactly the presumption that is wrong. Sometimes it's right, but often it's not. Programmers are addicted to complexity in part because in many circumstances producing more of it is so easy and convenient, especially right now -- it may make things more difficult in the long run, but not…

I am unfamiliar with your usage of "twist" in the sense you seem to be using as it relates to complexity --- the APoSD definition seemed far easier for me to understand at least.

Thank you for taking the time to discuss this --- looking forward to reading the Google book you recommended --- hopefully it will come up as a point of discussion here at some point in the future.

Re: Clean Code vs. A Philosophy Of Software Design

#527

Post by igouy »

wglb wrote: post #476
igouy wrote: post #359

Earlier quoted context omitted.

> median line count of methods Auto-generate getters and setters for every instance variable and that will drag the average down. (Maybe a lot of those getters and setters should not have existed.)

Not part of smalltalk.

fyi the Cincom Smalltalk IDE New Class dialog shows these fields and checkboxes—

     Name: MyClass
     Superclass: Core.Object
     Instance Variables: anInstVar anotherVar

     Create methods:
         Accessors
         Initializer
         Subclass responsibilities
"Accessors" aka getters.

    ~
See 1996 "Smalltalk with Style"

page 113 get method

page 117 set method

https://rmod-files.lille.inria.fr/FreeBooks/WithStyle/Smallt...

    ~
"After the creation of the class StUser, it is highly recommended that you perform automatic creation of instance variable accessors. One possible way to do this in Squeak is to use the context menu on a class among the entry more.... There, you can find create inst var accessors. Select this command to have all accessors created."

http://www.hpi.uni-potsdam.de/hirschfeld/seaside/tutorial?ch...

etc etc

Re: Clean Code vs. A Philosophy Of Software Design

#528

Post by bena »

kragen wrote: post #525
bena wrote: post #519

Earlier quoted context omitted.

That is quite a bit more thorough than I either expected or wanted. So, for that, many thanks. Although in your excellent break down of the shortcomings of the book, you kind of make me want to go back and re-read it myself. Just to experience it from my current vantage point. To see where I disagree with the book now. > Code Complete's table of "Average Cost of Fixing Defects Based on When They're Introduced and Det…

You're welcome! You, and I, and the entire software industry, it turns out. https://buttondown.com/hillelwayne/archive/i-ing-hate-scienc... is the best summary I've found on that. > Are Late-Stage Bugs More Expensive? > (...) While there's no smoking gun, I think the body of research so far tentatively points in that direction, depending on how you interpret "late-stage", "bugs", and "more expensive". This is a newsl…

> As I see it, this is not so much about how long the bug has been in the system but about what kind of bug it is.

That makes sense. Even as I was working out in my head why a bug would be more difficult to fix later, I came across the same general thought. That the problem is that by the time the bug gets to production, there's a lot of underlying support for it. And often, fixing that bug means fixing the underlying support as well.

And it's something you often don't discover until you're bitten by it.

And these bugs will naturally be found later because they are more difficult to find in the first place.

Then we get to the bit that essentially reinforces the adage from The Mythical Man-Month: Plan to throw one away, you will anyhow.

And it makes sense. It is obvious when laid out as such. And it is obvious how that section of Code Complete is at odds with The Mythical Man-Month.

Re: Clean Code vs. A Philosophy Of Software Design

#529

Post by regularfry »

yxhuvud wrote: post #238
regularfry wrote: post #174

Earlier quoted context omitted.

The interesting thing to look for here is the parts of the codebase that don't need to adapt with gained experience. That's the key. If people aren't changing it, they haven't needed to, and that's a useful signal. Conversely, looking for the parts of a codebase with the highest churn will tell you immediately what all the devs on that codebase will complain about, if you ask them. This has worked for me extremely we…

It can also mean "We have not changed this because we don't dare to do that, or it is too much work and we just have to live with the bad decisions made 25 years ago". And that is the last code you want to copy.

It is, but those cases tend to be obvious.

Re: Clean Code vs. A Philosophy Of Software Design

#530

Post by regularfry »

tremon wrote: post #252
regularfry wrote: post #173

Earlier quoted context omitted.

I believe that there is a genuine physiological effect that makes it a good idea to have the area of code that you need to think about fit entirely on one screen, without scrolling. There is probably an upper limit to the screen height where that limit is useful: I would believe a 100-line function to be above it and a 24-line function to be safely below it, but I wouldn't want to hazard a guess in the middle. It's a…

The term you're looking for is cognitive load. It's a qualitative term used to represent the amount of information a person has to keep in working memory while working on a task.

Cognitive load is part of it, but it's not the only part. If you want to scroll the page, you have to engage physical movement. That's an inefficiency in itself.
Post reply on HN