Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Want cleaner code? Use the rule of six

davidamos.dev

Post reply on HN
Print view View original

201–210 of 352 posts

Re: Want cleaner code? Use the rule of six

#201

Post by readthenotes1 »

bloaf wrote: post #138

I have pretty mixed feelings about this. Personally I find it much easier to debug code that: 1) fits entirely on my screen and 2) doesn't involve much state modification Every intermediate variable is a chance for me to miss some modification (e.g. it was passed to a func that modifies its arguments) and consequently misunderstand what is happening. I've been experimenting in Python with the function chaining style…

Do you really write a very long comment after every function call?

And have you looked at code that's over a year old and modified by other people to see how poorly those comments now match the code?

Re: Want cleaner code? Use the rule of six

#202

Post by aidos »

overgard wrote: post #105
mike_hock wrote: post #48

Earlier quoted context omitted.

Yes, and a source file littered with tiny helper functions that do very specific things and don't make any sense except in the precise context in which they get called, isn't necessarily more readable. Here, "query_params" means "extract the last three query parameters, raw (i.e. not unescaped and not broken into key-value pairs)." The transformation shown makes precisely nothing more readable or easy to understand.…

Your mileage clearly varies, but I found the transformed example much easier to understand. While I suspected it was parsing a query string from the initial code, having that stated explicitly in the variable removed the guessing. I think the main problem is he just didn't go far enough, there was still more to deconstruct. I suppose the function to parse the query string could have been better, its name isn't very d…

For me that's the issue with this whole example; it kinda misses the woods for the trees.

    # not interesting (also, use stdlib instead)
    def extract_url_params(url: str) -> dict[str, str]:
        params = url.split('?')[1].split('&')
        return = dict(param.split('=') for param in params)

    # This is the thing that needs explaining!
    final_3_param_values = list(extract_url_params(url).values())[-3:]
By decomposing the problem in a more natural way, you can entirely direct the reader's attention to the thing that's causing the dissonance. For some reason it's just the the final 3 values they want (both weird requirements). Make that clear from the code!

Re: Want cleaner code? Use the rule of six

#203

Post by rekrsiv »

The original code is perfectly readable until it does something completely unexpected, and the human parser has to start over to make sure they didn't miss anything. But unfortunately, the context for that "get the last 3 parts specifically" is never explained, so the entire line never makes sense. The human has to think a lot to come up with an (hopefully correct) explanation for the "why".

The solution isn't to extract every token from the expression to separate lines, but to document the "why" of the unexpected token. That can take many forms: a new variable with a meaningful name, a new function with a meaningful name, or a meaningful comment that warns the reader about the upcoming reason for getting just the last 3 parts.

Re: Want cleaner code? Use the rule of six

#204

Post by [deleted] »

aaronbrethorst wrote: post #170

My opinion is that maintainable code is written first for reading by humans and second for executing by computers. Unless I'm writing throwaway prototype code (famous last words, lol), I try to write code such that I will be able to figure out what my intention was 6-18 months from now when I'm staring at a piece of code in a panic trying to debug a production issue. That doesn't mean I'm going to get it right when I…

[deleted]

Re: Want cleaner code? Use the rule of six

#205

Post by im3w1l »

ParetoOptimal wrote: post #194
im3w1l wrote: post #31

Give mysterious things room. In this case the most mysterious is [-3:]. That, together with the split, should have it's own line or maybe even multiple (function declaration, comment).

> [-3:]. That kind of index notation really isn't mysterious if you write a lot of python in my experience.

The mysterious part isn't what it does. The mysterious part is why. Why are we taking the last three url parameters? What are the meaning of those particular url parameters? Also url parameters are normally used as a unordered key=value dictionary, which makes it strange that we rely on a given order.

Re: Want cleaner code? Use the rule of six

#206

Post by overgard »

ParetoOptimal wrote: post #192
overgard wrote: post #178

Earlier quoted context omitted.

While I'm not going to go collect a bunch of APL programmers to confirm this (where would one even find them?), I highly doubt that claim. Knowing a language doesn't mean dense code is suddenly obvious. This is a silly example, but years ago I wanted to prove that you could write a non-trivial program in python using a single expression (because python's lambda only allows you to use expressions, not statements). And…

That example isn't like APL though because of it's verbosity. Also APL has more universal abstractions to express a lot of this kind of logic. That lack of verbosity makes it easier to pick out the intention revealing code, which isn't the case here.

Well, of course that code was meant as a joke, and I did some things intentionally weird. I mention it just to point out that a metric like "it's only a single expression!" doesn't mean that something is actually simple.

Re: Want cleaner code? Use the rule of six

#207

Post by [deleted] »

overgard wrote: post #176
jstimpfle wrote: post #154

Earlier quoted context omitted.

What he means there by saying "bottom-up", as far as I can tell, is that you "compress as you go", i.e. it is bottom-up compression, in a similar way to how you can also write bottom-up parsers. It's not stating that you should start by creating lots of little artifacts before you have a great plan (bottom-up design) nor that you should start implementing the "non-functional requirements" (another confusing term) on…

> It's not stating that you should start by creating lots of little artifacts before you have a great plan (bottom-up design) Look, you can disagree with his conclusion, but that is exactly what he's saying. The post is long but it's very clear and methodical about how he's suggesting code should be designed and written. I happen to agree with him.

[deleted]

Re: Want cleaner code? Use the rule of six

#208

Post by twblalock »

The "bad" Python code in that example is perfectly fine. I'm not a Python programmer but I can read Python a little bit, and the example uses basic programing concepts like string splitting and array ranges.

If you don't understand that, multiple smaller lines won't help you, because you just don't know what you are doing.

In addition, that code example is easily testable. Testability is more important than readability in modern programs that follow modern CI/CD principles -- and the readability is not really that bad either. Also, modern debuggers don't have issues with nested/lambda statements like these.

If the article's author had a legitimate bone to pick, they would have better examples.

Re: Want cleaner code? Use the rule of six

#209

Post by lamontcg »

davnicwil wrote: post #73
kouteiheika wrote: post #35

I don't necessarily agree with the step of putting the code in a separate function; that often works, but just as often makes it so that the code can't be read top-to-bottom anymore which hurts readability. In this case there's, I think, a better alternative; the equivalent-ish code in Ruby for the example code here would be something like this: values = s .partition('?')[-1] .split('&') .map { |key_value| key_value.…

> the code can't be read top-to-bottom The idea of the technique is to split out code at a different level of abstraction with a clear name communicating what it does, while hiding the details of the how, because you don't need to care about that detail at all to fully grok the code in the calling function. Where this breaks down is when the code you're trying to split out is not at a different level of abstraction,…

Each function becomes something new that needs to stick in your brain.

Someone that applies "MORF" to their code winds up nearly inventing their own language in the file that they're writing. All that takes up more memory when you're reading their code, because due to leaky abstractions the actual implementation of whatever the function name that you replace it with is often important.

I have an actual track record of taking code that someone had MORF'd to hell and rewriting it, and making it about 40% shorter, with much fewer concepts to process.

Inventing a term like "MORF" is probably illustrative of the problem itself. Without looking at the blog post what exactly was that acronym again? That is just one more thing for you to try to memorize. The author is riffing on things like "DRY" and "YAGNI" that are well-known, but it isn't really helping with readability when you lift it out of that context.

Re: Want cleaner code? Use the rule of six

#210

Post by overgard »

twblalock wrote: post #208

The "bad" Python code in that example is perfectly fine. I'm not a Python programmer but I can read Python a little bit, and the example uses basic programing concepts like string splitting and array ranges. If you don't understand that, multiple smaller lines won't help you, because you just don't know what you are doing. In addition, that code example is easily testable. Testability is more important than readabili…

The question isn't if you can figure it out, but how long does it take you? The simple version might take me 2 seconds to read. The original version might take me 10 to 15 seconds. Multiply that out over a day and you're hurting quite a bit.
Post reply on HN