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

161–170 of 554 posts

Re: Clean Code vs. A Philosophy Of Software Design

#161

Post by abirch »

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…

Remember when most people give presentations about a technology, they’re in the honeymoon stage

Re: Clean Code vs. A Philosophy Of Software Design

#162

Post by cjfd »

PDSD is correct on length of methods. The methods given in an example in CC are ridiculously short. CC is more correct on comments than PDSD. Especially mandating comments in certain places leads to very low quality and, frankly, utterly disgusting comments point out, helpfully that the 'get_height' method 'gets the height'. CC is more correct on TDD than PDSD. The noticed danger of just focussing on implementation details over the structure of the API is always there but TDD has a refactor step to fix that. The general idea of working in small steps with there being a safe state between every small step is worth its weight in gold.

Re: Clean Code vs. A Philosophy Of Software Design

#163

Post by abirch »

jacobsenscott wrote: post #113

I was around before the clean code movement, and like all software movements, it was a reaction to real problems in the software industry. Massive procedural functions with deeply nested conditionals, no structure, global variables, no testing at all. That was all the norm. Clean Code pushed things in a better direction, but it over-corrected. In many ways APOSD (published in 2018) is a correction against the excesse…

As Ben Franklin wrote "the best physician that knows the worthlessness of the most medicines."

Re: Clean Code vs. A Philosophy Of Software Design

#165

Post by raverbashing »

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?

Honestly, no better indication of a very mediocre developer

Re: Clean Code vs. A Philosophy Of Software Design

#166

Post by kragen »

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.

Re: Clean Code vs. A Philosophy Of Software Design

#167

Post by kragen »

sudobash1 wrote: post #10

There is an important case for comments that neither of them touched on. Sometimes you are dealing with bugs or counterintuitive processes beyond your control. For example, I am writing some driver software for a USB device right now. It is so easy to get the device into a bad state, even when staying within the documented protocol. Every time I implement a workaround, or figure out exactly how the device expects a m…

Have you thought about distilling your hard-earned information about the device's behavior into a simulator for the device you could test your code against?

Re: Clean Code vs. A Philosophy Of Software Design

#168

Post by kragen »

lompad wrote: post #152
Cthulhu_ wrote: post #118

Earlier quoted context omitted.

And the described use case - USB stuff with very specific exception - makes a strong case for literate programming, that is, more prose than code.

Does everything have to be pushed into a structure-prescribing set of rules? Can't we just say "comments are useful here" without trying to make it into a case for $methodology?

Literate programming isn't a structure-prescribing set of rules or a methodology. It's just making the prose primary and the code secondary.

Re: Clean Code vs. A Philosophy Of Software Design

#169

Post by kragen »

Mawr wrote: post #61
sudobash1 wrote: post #10

There is an important case for comments that neither of them touched on. Sometimes you are dealing with bugs or counterintuitive processes beyond your control. For example, I am writing some driver software for a USB device right now. It is so easy to get the device into a bad state, even when staying within the documented protocol. Every time I implement a workaround, or figure out exactly how the device expects a m…

Sounds like you should instead be making these invalid states unrepresentable by encoding them in types and/or adding assertions. Especially if you're exposing them as interfaces, as your example function names would imply.

They're invalid states inside the USB device, not inside the driver code. So nothing you do to the driver code can make them unrepresentable. The best you can do is avoid frobbing the device in the problematic ways.

Re: Clean Code vs. A Philosophy Of Software Design

#170

Post by kragen »

narnarpapadaddy wrote: post #47
marcusbuffett wrote: post #11

I strongly recommend "A Philosophy of Software Design". It basically boils down to measuring the quality of an abstraction by the ratio of the complexity it contains vs the complexity of the interface. Or at least, that's the rule of thumb I came away with, and it's incredible how far that heuristic takes you. I'm constantly thinking about my software design in these terms now, and it's hugely helpful. I didn't feel…

Implicitly, IIRC, the optimal ratio is 5-20:1. Your interface must cover 5-20 cases for it have value. Any fewer, the additional abstraction is unneeded complexity. Any more, and your abstraction is likely too broad to be useful/understandable. The example he gives specifically was considering the number of subclasses in a hierarchy. It’s like a secret unlock code for domain modeling. Or deciding how long functions s…

Maybe some examples would clarify your intent, because all the candidate interpretations I can think of are absurd.

The sin() function in the C standard library covers 2⁶⁴ cases, because it takes one argument which is, on most platforms, 64 bits. Are you suggesting that it should be separated into 2⁶⁰ separate functions?

If you're saying you should pass in boolean and enum parameters to tell a subroutine or class which of your 5–20 use cases the caller needs? I couldn't disagree more. Make them separate subroutines or classes.

If you have 5–20 lines of code in a subroutine, but no conditionals or possibly-zero-iteration loops, those lines of code are all the same case. The subroutine doesn't run some of them in some cases and others in other cases.

Post reply on HN