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

171–180 of 352 posts

Re: Want cleaner code? Use the rule of six

#171

Post by greenpeas »

krapp wrote: post #14
thisismyswamp wrote: post #13

Skimmed the article and the comments and got no answer - can someone tell me what the rule of six is?

The rule is literally described, in bold text, within the article. Try actually reading instead of skimming next time. Or at least skim more slowly.

I skimmed the article and missed the definition as well. Now that's certainly my fault, and I knew that if my curiosity were peaked I'd go back and read the article more carefully.

But I'd also like to say that, IMHO, the fonts, spacing, various headings, images and codeblocks with dark background are all mixed up on that page, and the *bold* text does not stand out at all. Every other sentence or piece of information on that page is highlighted in its own way.

Re: Want cleaner code? Use the rule of six

#173

Post by ParetoOptimal »

layer8 wrote: post #110
mdaniel wrote: post #103

Earlier quoted context omitted.

That may be true for less capable editors, but IntelliJ (and therefore Rubymine for the cited code block) annotates the stream type variable when it can prove what it is: https://www.jetbrains.com/help/ruby/viewing-reference-inform... regrettably doesn't show an example of what I'm talking about .map { | *String* key_value | key_value.partition... } where String shows up in light grey text indicating that IJ knows `k…

That’s nice, but it just highlights that the coding style isn’t sufficiently intelligible by itself. We can’t and shouldn’t rely on a static analyzer to be active to make code intelligible everywhere code is displayed (pull requests, diffs, ...). Doing so favors writing code over reading code, which is generally the wrong bias. Editor support is appropriate and useful to help writing readable code, but it’s bad for e…

> editor support should not become a prerequisite for existing code to be comprehensible.

I don't know... i'm frequently torn deciding between whether i think this is true or not.

On another note, readability of code is less about coding style and more about familiarity.

Re: Want cleaner code? Use the rule of six

#174

Post by mkoubaa »

A reviewer can usually tell which code is easier to understand side by side, even when it's yourself as the reviewer.

Applying rules like these to your code may or may not result to cleaner code, but that's a testable hypothesis.

I've seen all too often some clean code recommendation or other applied to code and it gets harder to understand. And the person doing the refactoring (often myself) gets caught in sunk cost.

Now my recommendation is always:

1. Use your intuition to predict if a change makes code cleaner.

2. Try to make that change, and be open to doing things a little differently that you first imagined.

3. Test your hypothesis to see what others think. Decide what to do, but be mentally willing to throw it away.

4. Repeat

Articles like this are good resources to help train your intuition, but there is no substitute to developing your personal and team "flavor profile" for what styles suit your way of thinking.

Re: Want cleaner code? Use the rule of six

#175

Post by patrick451 »

khendron wrote: post #67
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.…

One of the advantages of functions is that a well-named function is self-documenting. If you can take a bunch of lines and wrap them in a function whose name summarizes exactly what it does, then you have improved readability in my opinion. In this example, I don't really need to know the details of how the query parameters are extracted. I just want to know I've got them.

Yeah, but these little 5 line functions with one caller whose only purpose is to avoid a 50 line function somewhere else are almost never named well. At best, I can infer about 20% of what is going on without stepping into all those little helpers.

Re: Want cleaner code? Use the rule of six

#176

Post by overgard »

jstimpfle wrote: post #154
overgard wrote: post #148

Earlier quoted context omitted.

Well, you might know of that blog post, but might want to reread it, I don't think it says what you think it says. The example he steps through is very clearly bottom up. He even outright says it: > This is a very bottom-up programming methodology, a pseudo-variant of which has recently gained the monicker “refactoring”, even though that is a ridiculous term for a number of reasons that are not worth belaboring at th…

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.

Re: Want cleaner code? Use the rule of six

#178

Post by overgard »

rak1507 wrote: post #167
overgard wrote: post #142

Earlier quoted context omitted.

Here's conway's game of life in APL: life ← {⊃1 ⍵ ∨.∧ 3 4 = +/ +⌿ ¯1 0 1 ∘.⊖ ¯1 0 1 ⌽¨ ⊂⍵} Is that shorter than essentially every other language implementation. Yep! However, to even begin to understand it you have to read an article from the original writer: https://aplwiki.com/wiki/John_Scholes%27_Conway%27s_Game_of_... To me, that is objectively , not subjectively, less clear than the longer implementations.

'However, to even begin to understand it you have to read an article from the original writer' - or just know APL? If you know APL, it's clear.

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 I managed to do that. And it's hideous. Any python programmer could theoretically understand what this is doing, but I doubt they would. Bonus points if you can guess what it does without running it!

    (lambda:
        not globals().__setitem__('sys', __import__('sys'))
        and not globals().__setitem__('this', sys.modules[globals()['__name__']])
        and not globals().__setitem__('time', __import__('time'))
        and
        #program
        [setattr(this, k, v) for k,v in {
                'set_color': (lambda c: w(['*', ' '][c])),
                'abs': (lambda t: (int(t) + (int(t) >> 31)) ^ (int(t) >> 31)),
                'w': lambda x: sys.stdout.write(x) == 0,
                'smash': (lambda t: -((t * -1) >> 31)),
                'color': (lambda n,k: set_color(smash (k & (n - k)))),
                'col': (lambda n, k: k

Re: Want cleaner code? Use the rule of six

#179

Post by ParetoOptimal »

standardUser wrote: post #18

I see a troubling trend with some coworkers where they seem to stretch the limits of time and space to make every line as dense as possible, usually using lodash. I think it is a point of pride for them, but I think it's obvious that everyone's life would be easier if they just wrote their code out "long form" and, god willing, added some comments for various steps. Instead, I find myself having to re-write ultra-den…

> I see a troubling trend with some coworkers where they seem to stretch the limits of time and space to make every line as dense as possible, usually using lodash. I think it is a point of pride for them, but I think it's obvious that everyone's life would be easier if they just wrote their code out "long form"

Concision can be used for emphasis as verbosity can be used to obscure.

> Instead, I find myself having to re-write ultra-dense blobs of code in order to debug or even simply understand what's going on.

Is this problem because their method is inherently nee complex or is it due to lack of familiarity?

Perhaps they debug that code differently then you do and it's incompatible with your previous mental model?

Re: Want cleaner code? Use the rule of six

#180

Post by WalterBright »

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

D does too:

    import std.algorithm, std.array, std.stdio;
    // Print sorted lines of a file.
    void main()
    {
     auto sortedLines = File("file.txt")   // Open for reading
                        .byLineCopy()      // Read persistent lines
                        .array()           // into an array
                        .sort();           // then sort them
     foreach (line; sortedLines)
         writeln(line);
    }
Post reply on HN