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

61–70 of 352 posts

Re: Want cleaner code? Use the rule of six

#61

Post by Karellen »

jstimpfle wrote: post #33

I like how this article explains that "clean" must be "readable for humans". However, the concerns raised are only superficial. It's much more important to get the larger scale structure right. I recommend drawing diagrams and explaining the architecture to humans. Then again, I'm not saying overdo it, because some things are hard to draw, some are hard to explain. In the end, it's important to get a complete underst…

> Show me your flowcharts (code) and conceal your tables (data structures), and I shall continue to be mystified. Show me your tables (data structures), and I won’t usually need your flowcharts (code); they’ll be obvious.

-- Fred Brooks, The Mythical Man-Month, 1975

> a computer language is not just a way of getting a computer to perform operations but rather that it is a novel formal medium for expressing ideas about methodology. Thus, programs must be written for people to read and only incidentally for machines to execute.

-- Abelson & Sussman, The Structure and Interpretation of Computer Programs, 1984

Re: Want cleaner code? Use the rule of six

#62

Post by joshuacc »

foolfoolz wrote: post #17

the only known metric for code complexity is as number of lines grows complexity grows

I’m not sure what you’re trying to say, but that’s not true at all. There are other metrics for code complexity, including fairly simple but useful ones like number of logical branches.

Re: Want cleaner code? Use the rule of six

#63

Post by hardware2win »

pavon wrote: post #20
retrocryptid wrote: post #3

in the example given, I started with 10 things to keep in working memory. now that we've added a named function or a named variable, we have 11. I suggest it is at least as important to name things well (or add comments) as it is to break lines up.

I'm working on a project that is following Uncle Bob's Clean Code guidelines of striving to having functions be ideally 3 lines or less, and nor more than say 7. I have mixed feelings about it. My initial prejudices have largely held. I do find the code harder to read and follow. Having to jump around, follow variables that change name as they are passed through functions, keeping track of state that was moved to a c…

>guidelines of striving to having functions be ideally 3 lines or less, and nor more than say 7. I have mixed feelings about it.

Dont feel bad about it

Those small functions with hard limits are just terrible advice

When you gotta know functions impl., which for me is very often

Then this approach just increases cognitive load

Re: Want cleaner code? Use the rule of six

#64

Post by upsideDownBlue »

I enjoyed the article and agreed that working memory places a fundamental limit on the intelligibility of otherwise equivalent pieces of code. As a former psychologist with experience of memory research (though not quite this area), it might be useful to others if I add that:

- The size of the short-term store is normally said to be 7 plus or minus 2 (the 'magic' number 7)

- The Working Memory model has somewhat overtaken the 'short term' memory model, and it is unusual to see them being presented alongside each other like this (though 'short term memory' remains a useful, good-enough metaphor for explaining certain key aspects of memory)

- Chunking is typically viewed as a memory-supported division of stimuli (what you're reading, hearing etc.) into meaningful units based on LTM memory representations. A good example is a chess expert 'chunking' the layout of a chess board with many pieces in perhaps one or two units (e.g. 'It's the mid game configuration of [famous players] in [famous game], except the king's position is different'). We would expect more expert programmers to 'chunk' increasingly large units, I think (e.g. 'Oh, this is just the [famous sorting algorithm]').

- A single chunk is usually considered to take up a 'slot' in short term memory

If anyone wants papers/sources for the above, let me know.

Re: Want cleaner code? Use the rule of six

#65

Post by BurningFrog »

hardwaregeek wrote: post #21

This seems perfectly reasonable advice. However I do wonder how many people actually struggle with this sort of code quality. It's certainly more than a few, since I've encountered bad code with these issues. But it's not exactly the most pressing issue either. As the author demonstrated, you can refactor this with a little thought. It's the code equivalent of tidying your room, sweeping the floors and putting your s…

My opinion is that each line of code should be easily understandable. Without that, code is very hard to work with.

You're right that other code problems can be worse. But that's no excuse to avoid doing the basics.

To clean up system design issues, you must first know what a better system design would be. It's not enough to realize that what you have is bad.

I do this a lot, and part of my approach is to always be incremental. Improve one detail/aspect at a time. The worst, very tempting, idea in this field is to throw everything away and start over...

> I also struggle to balance it with getting feature work done

FWIW, I like to spend 1/3 of my time cleaning up and refactoring.

Re: Want cleaner code? Use the rule of six

#66

Post by hedora »

I think this article is missing the forest for the trees.

I've found that dividing software into layers, and making sure that each file relies on the same set of invariants from its dependencies, and also maintains a (different) consistent set of invariants for its callers works much better.

For instance, I'd prefer a function that takes a string and confirms it is a valid URL.

That would delegate to URL character esacaping logic and DNS validation. (Are & or ? valid DNS name characters? Will they be in the future? I neither know nor care.)

On top of that, there would be a parser for key=value config file lines.

Then, the example in the article becomes something like:

keyvalue = parseConfLine(input)

URL(keyvalue.value).params[-3]

Plus a few more lines to confirm key is as expected and that value has enough query parameters.

Alternatively, I'd use a perl oneliner with a regexp. I see no purpose for code that lands in the middle ground between these extremes.

Re: Want cleaner code? Use the rule of six

#67

Post by khendron »

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.

Re: Want cleaner code? Use the rule of six

#68

Post by leobg »

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

Any way to do that in Python? Basically an anonymous function across multiple lines, which can be collapsed in the IDE view?

Re: Want cleaner code? Use the rule of six

#69

Post by layer8 »

lbriner wrote: post #59

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

There’s a balance to be struck if most of the Do methods need a common and/or interdependent set of parameters. Inlined code can be clearer because you can directly see how/why those parameters are used. You rarely have

  DoThis();
  DoThat();
  DoTheOtherThing();
Instead you usually have something like:

  x = DoThis(a, b, c);
  y, z = DoThat(c, x, a);
  w = DoTheOtherThing(a, z, x, y, b);
…and on top of that have to add error handling for those calls.

Re: Want cleaner code? Use the rule of six

#70

Post by gilch »

The article starts with some reasonable premises, but the conclusion does not follow.

I think most APL programmers would disagree with this take. Dense code has real advantages, and naming everything has real costs that are hard to see. There's nothing magic about a "line" that suddenly allows for chunking. You have to build a parse tree in your head in any case.

I'm reminded of Doug McIlroy's challenge to Knuth.[1] It's worth a read. Would you rather have 6 lines of dense shell, or 10 pages of Fabergé egg? I'll take the shell, thanks.

Look at the source code for J (an APL derivative)[2]. It's written in C, but that C was written in APL style by APL programmers. Lines leverage macros and 1–2 character names, making them extremely dense. Some files have a comment on nearly every line. For an average C programmer, this code looks absolutely insane. But it's not. The J devs find this perfectly readable and maintainable. It's clean code! If written with the typical C idioms, it could easily be 10x as long, and therefore harder to maintain. Your first impression is a snap judgement due to a difference of culture. You can learn to read this style with practice. Whatever your current style, that took practice too.

[1]: http://www.leancrew.com/all-this/2011/12/more-shell-less-egg...

[2]: https://github.com/jsoftware/jsource

Post reply on HN