Live data from Hacker News

Clean Code vs. A Philosophy Of Software Design

github.com

171–180 of 554 posts

Re: Clean Code vs. A Philosophy Of Software Design

#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 vibe I got from Uncle Bob generally. See any number of lines at the same indentation level, select them, extract method, name it vaguely for some part of what it does, repeat.

I honestly think that it comes from this type of school of thought that a function should be X lines rather than a function achieving a function. Thinking about this now, it's sort of the difference between "subroutines" and "functions".

Working on their code, I thank god for modern IDEs ability to inline. I often go through and restructure the code just to understand the full scope of what it's doing, before restoring what I can of the original to make my changes as minimal as possible.

Re: Clean Code vs. A Philosophy Of Software Design

#172

Earlier quoted context omitted.

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…

This is a good rule of thumb, but what would be a good response to have interfaces because, "what if a new scenario comes up in the future"?

If you own the code base, refactor. It's true that, if you're offering a stable interface to users whose code you can't edit, you need to plan carefully for backward compatibility.

Re: Clean Code vs. A Philosophy Of Software Design

#173

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…

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 all to do with how your brain processes what it's seeing, and the planning processes involved in getting to the next bit of information it needs. If that information is off-screen, then the mechanisms for stashing the current state and planning to move your hands in whatever way necessary to bring it onscreen will kick in, and that's a sort of disfluency.

Similarly with tokens too far from whatever you're currently focused on. There's likely to be a region (or possibly a number of tokens) around your current focal point within which your brain can accurately task your eyes to scan, and outside that, there's a seeking disfluency.

I think this is why you get weird edge cases like k and j, where they pride themselves on having All The Code in one 80x24 buffer, and it actually works for them despite breaking all the rules about code legibility.

Re: Clean Code vs. A Philosophy Of Software Design

#174
post #154
post #110

Earlier quoted context omitted.

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…

Not really, long-living projects don't adapt their complete code base with gained experience, much like the Linux Kernel probably will never be rewritten in Rust, C++ projects never transformed to C++14+, etc.

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 well across a number of projects.

Re: Clean Code vs. A Philosophy Of Software Design

#175

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.

It's important to note that Kent Beck is not one of those people, as he shipped the first unit testing library, as well as a bunch of ones in other languages later.

Like, I personally prefer the bare assert style of testing (like pytest), but the junit style is basically everywhere now.

Re: Clean Code vs. A Philosophy Of Software Design

#176
post #128

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.

But are those steps actually doing anything that can be tested? My experience with these sorts of codebases was always that most of the functions aren't doing much other than calling other functions, and therefore testing those functions ends up either with testing exactly the same behaviour in several places, or mocking so heavily as to make the test pointless.

Or worse, I've seen people break functions apart in such a way that you now need to maintain some sort of class-level state between the function calls in order to get the correct behaviour. This is almost impossible to meaningfully test because of the complex possible states and orders between those states - you might correctly test individual cases, but you'll never cover all possible behaviours with that sort of system.

Re: Clean Code vs. A Philosophy Of Software Design

#177
My take on the prime example:

    import itertools
    
    def generate_n_primes(n):
        """
        Generate n prime numbers using a modified Sieve of Eratosthenes.
    
        The algorithm keeps track of a list of primes found so far,
        and a corresponding list of 'multiples', where multiples[i] is a multiple of primes[i],
        (multiples[i] is initially set to be primes[i]**2, see the optimisations section below).
    
        The main loop iterates over every integer k until enough primes have been found,
        with the following steps:
        - For each prime found so far
        - While the corresponding multiple is smaller than k, increase it by steps of the prime
        - If the multiple is now the same as k, then k is divisible by the prime -
            hence k is composite, ignore it.
        - If, for EVERY prime, the multiple is greater than k, then k isn't divisible by any
        of the primes found so far. Hence we can add it to the prime list and multiple list!
    
        There are a few optimisations that can be done:
        - We can insert 2 into primes at the start, and only iterate over every odd k from there on
        - When we're increasing the multiple, we can now increase by 2*prime instead of 1*prime,
        so that we skip over even numbers, since we are now only considering odd k
        - When we find a prime p, we add it to the prime and multiple list. However, we can instead add
        its square to the multiple list, since for any number between p and p**2, if it's
        divisible by p then it must be divisible by another prime k = n:
                return primes
    
            # For each prime found so far
            for i in range(len(primes)):
                # Increase its corresponding multiple in steps of 2*prime until it's >= k
                while multiples[i] 
Some might find the docstring as well as comments too much - I find the comments help relate the code to the docstring. Open to suggestions!

Re: Clean Code vs. A Philosophy Of Software Design

#178
post #36

Earlier quoted context omitted.

> So if someone is 60+ year old, chances are that most of his work has never been open source Somewhat ageist? I'm 72 and have produced a number of FOSS tools.

Truly. I know plenty of people in their 60s and 70s who use Git and are still very sharp programmers.

Using Git is unrelated to whether the software you write is proprietary or open-source.

Re: Clean Code vs. A Philosophy Of Software Design

#179
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.

My middle school English teacher had 4 decades of experience writing. What she wrote was lesson plans. That doesn't make her Stephen King.

Re: Clean Code vs. A Philosophy Of Software Design

#180

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…

    > 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.
IMO, this is one of the key differences between the two books. CC has a vibe of hard and fast opinion-based rules that you must obey, whereas APoSD feels more like empirically-derived principles or guidelines.
Post reply on HN