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

51–60 of 352 posts

Re: Want cleaner code? Use the rule of six

#51

Post by lbriner »

mike_hock wrote: post #48
noncoml wrote: post #15

We break everything down and then we reach one of the most difficult problems in software engineering: Coming up with good and short names for all these extra intermediate variables and functions.

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

I wouldn't attack the example too much, it does seem a little contrived to make the point - the very thing I don't like about contriving examples!

It is hard to know whether the principle is valuable with such a weird example. In this example there are lots of other ways it could have been done more meaningfully but, again, don't know if the example is real.

Re: Want cleaner code? Use the rule of six

#53

Post by lbriner »

pavon wrote: post #24

Never cleaned up the most obtuse part of that code snippet - why are we only keeping the last three parameters?

I think a contrived example. In truth, there is much more likely to be a way of tidying this up with a nice reuseable function like "get_querystring_params" which returns an array and then take the first 3 with a comment like "only the first 3 parameters are used for the search".

Taking a subet of query params smells in its own right so, again, might be a bad example.

Re: Want cleaner code? Use the rule of six

#55

Post by jonnycomputer »

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

I like this style too, though it can make debugging trickier.

Re: Want cleaner code? Use the rule of six

#56

Post by layer8 »

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 issue with functional pipelines is that the reader has to keep track of what the types and the data are on each line. It’s fine for 2-3 lines, but it can get non-obvious quite quickly. Assigning intermediate points to named variables can be appropriate, or indeed factoring portions of the pipeline out into separate functions.

Re: Want cleaner code? Use the rule of six

#58

Post by rzimmerman »

“Rule of six” is generally interesting - I came upon the concept when reading the book “Nightfall” by Isaac Asimov as a kid. There’s a line in the book about the number of stars in the sky, and how people can’t really grasp numbers more than 5-10. It got me thinking about trying to visualize a set of 3, 4, or 5 distinct objects without splitting them into groups. I genuinely can’t do it for more than 5 or 6 of something.

I also remember reading about a study where chess masters and non-experts were asked to memorize chess boards. Average people could only remember 5-7 piece locations where chess masters could remember the entire board. But when the piece layout was random (rather than from real chess matches) the experts weren’t much better than the non-experts. It’s speaks to the abstractions our brain creates to deal with limited working memory.

That cumbersome line of python is a good example. As an experienced python person, I immediately found myself giving names to the chunks to understand it.

Overall very good advice. Your code should explain the steps it takes to solve a problem (or in a more functional language, explain the solution), not be as terse and clever as possible. Keystrokes are cheap; thinking is expensive.

Re: Want cleaner code? Use the rule of six

#59

Post by lbriner »

Perhaps a more helpful principle I heard a long time ago was that all methods are either a specific method doing a specific thing (like splitting up a string) or they call a series of methods of the first type. When we mix the two, it becomes harder to reason since type 1 is generally logically complex, so keeping these small makes them testable and readable, and the logic of the high level is more easily encapsulating as a series of DoThis(), DoThat(), ThenDoThat() calls.

If I've only helped one person today, it was worth it ;-)

Post reply on HN