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

341–350 of 554 posts

Re: Clean Code vs. A Philosophy Of Software Design

#341

Post by wglb »

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?

It is a bit weird.

However, a friend of mine was a professional Smalltalk programmer. He claims that his median line count of methods, over his 17 year career, was 4.

It is harder to do in other languages--it seems that C would be on the order of 10.

Clearly it is a rule that can lead to complexity of too many methods, compromising whatever gain smaller methods give you.

Re: Clean Code vs. A Philosophy Of Software Design

#342

Post by yakshaving_jgt »

ninetyninenine wrote: post #329
yakshaving_jgt wrote: post #279

Earlier quoted context omitted.

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 proc…

What you’re describing isn’t exactly new territory for me. Maybe you’re writing for the room, and not immediately for my benefit.

Parsing is kind of… everywhere. Path piece instances? Parsing. Forms? Parsing. The whole point of smart constructors is parsing. Deserialising from the persistence layer? Parsing. Sure, JSON and Protobuf also, but even when relying on a robust library like aeson, we still write tests. Why wouldn’t you? The types you define can be serialised in different ways, and the way you deserialise needs to roundtrip with the way you (or an external system) serialise(s), which also necessitates more tests.

Re: Clean Code vs. A Philosophy Of Software Design

#343

Post by Pxtl »

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…

When you're writing it you have the help of the compiler and various other tools, plus you have the model of what the code is doing fully-formed in your head, and you have the recent memory of various other approaches you took and how and why they failed. When you're reading it you have none of those things.

So, code is harder to read than it is to write.

So if you write code that uses your full intellect to write it out, you are therefore by definition too dumb to read it.

Re: Clean Code vs. A Philosophy Of Software Design

#344

Post by wglb »

begueradj wrote: post #91
imjonse wrote: post #74

I am biased ( a former coworker was an Uncle Bob fan, and was bent on doing everything by the book, with layers of abstraction, patterns, hexagonal architecture, lots of unit tests, no cutting corners, even as we did not know what exactly we want to build and needed an MVP ASAP) but I'll just say this: Ousterhout wrote TCL - widely considered one of the best C codebases - besides being a professor at Standford and ha…

Let's not forget that Uncle Bob, by the time of writing "Clean Code" had 4 decades coding experience.

Are there large code bases that he has written that we know anything about?

Re: Clean Code vs. A Philosophy Of Software Design

#345

Post by kragen »

tremon wrote: post #262
kragen wrote: post #170

Earlier quoted context omitted.

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 whi…

That function covers 2⁶⁴ inputs, not cases. It handles only one case: converting an angular value to (half of) a cartesian coordinate.

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.

Re: Clean Code vs. A Philosophy Of Software Design

#346

Post by kraftman »

ctrlp wrote: 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.…

it has been years since I read the book, but I'm surprised that there's so much hatred for it here. From memory it seemed like fairly harmless things like give things good names, try to make the code readable, dont comment what the code does but why, use consistent formatting, avoid duplication.

Other than people going overboard with empty classes and inheritance Ive not really seen a problem of people breaking down functions too far.

Which parts are important to grow out of?

Re: Clean Code vs. A Philosophy Of Software Design

#347

Post by Pxtl »

hakunin wrote: post #42
mbo wrote: post #15

Earlier quoted context omitted.

While I am not a Uncle Bob-style "no comments"er I do love a ridiculous method name. I pay very close attention to that method and the context in which it is called because, well, it must be doing something very weird to deserve a name length like that.

That’s exactly why you should save that length only for a method that’s indeed doing something weird. If every method is long, the codebase turns into noise. (IOW I agree)

I used to work this way, but I found that every non-trivial method involves edge-cases and workarounds documenting them the method name destroyed readability.

Re: Clean Code vs. A Philosophy Of Software Design

#348

Post by layer8 »

CyberDildonics wrote: post #247
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 r…

The problem with collapsing is that you need to know a priori which sub-scopes are independent and hence collapsible and which aren’t. Meaning, you have to analyze the unfamiliar code first in order to know which sub-scopes you might want to collapse. And, given an already-collapsed sub-scope, due to it being collapsed you can’t see if it reads or mutates some local variable. The benefit of extracted functions is that you know that they are independent of the implementation details of the caller (i.e. can’t possibly depend on or modify local variables of the caller other the ones passed as arguments).

Too many arguments can become a problem. Nested functions can help here, because they allow you to move their implementation “out of the way” while still having access to shared variables. And sometimes a collection of parameters can sensibly become its own class.

IDE affordances are fine, but I’m opposed to requiring reliance on them for reading and understanding code, as opposed to writing.

Re: Clean Code vs. A Philosophy Of Software Design

#349

Post by Pxtl »

Copenjin wrote: post #129
WalterBright wrote: post #40

Earlier quoted context omitted.

Too often I see functions that are shells that reshuffle the arguments and pass them to another function, which also reshuffles the arguments and forwards them to another, and on and on. One was 11 layers deep.

And a lot of people doesn't understand how dangerous shuffling parameters is, especially in languages that do not have named parameters...

Powershell is an awful language but it has made me fall in love with named parameters. Name all the things.

Re: Clean Code vs. A Philosophy Of Software Design

#350

Post by wglb »

rester324 wrote: post #89
overgard wrote: post #80

Earlier quoted context omitted.

"It's not object oriented programming" is only a good case to make if you think object oriented programming is synonomous with good. I don't think that's true. It's sometimes good, often not good. Why would focusing on OO be a goal? The goal is to write good software that can be easily maintained. Nobody outside of book writers are shipping UML charts

Why would you not focus on writing OO code in an OO language for example? Would you start writing OO code in a functional langugage? No you wouldn't, because it would be pointless. There are programming paradigms for a reason

> Why would you not focus on writing OO code in an OO language

It should be the best solution to the problem direct whether or not use of OO is best, not the language.

Post reply on HN