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

161–170 of 352 posts

Re: Want cleaner code? Use the rule of six

#161

Post by toiletduck »

gilch wrote: post #100

At least for the contrived example from the article, the solution isn't to break up the code, but to use denser code. Use a regex. Does anybody really think that e.g. sregex[1] is better than just learning and using the regex language directly? Because that's where this kind of thinking leads. [1]: https://github.com/jwiegley/emacs-release/blob/master/lisp/o...

I know it's not the point the author is trying to make, but I couldn't help get the feeling this example isn't good enough to carry the point.

from stdlib:

  from urllib.parse import urlparse, parse_qsl

  url = 'https://www.example.com/some_pathsome_key=some_value&foo=bar'
  parsed_url = urlparse(url)
  values = [v for _, v in parse_qsl(parsed_url.query)]
  print(values)
which I guess you could oneliner back to this..

  [v for _, v in parse_qsl(urlparse(url).query]

Re: Want cleaner code? Use the rule of six

#162

Post by jstimpfle »

overgard wrote: post #98

This really resonates with me. I remember when I started programming (at like 10 or so), my dad tried to teach me Smalltalk. Smalltalk is a great language, but there were just too many concepts and abstractions happening on each line of code. To understand even basic code required understanding messages, objects, classes, blocks, etc. Maybe to an 18 year old that would have been ok, but for my 10 year old brain it wa…

3) It's also harder to edit with an editor (like vim), and (IMO) harder to read. I never even do "int x, y = 3;". I always put each variable declaration on its own line.

Re: Want cleaner code? Use the rule of six

#164

Post by _nalply »

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…

One way I try to solve that problem in Rust: use repeated `let thing = simple.invocation();`. No need to rename the variable `thing` if not neccessary. Rust allows redefining a variable with the same name. Additionally I sometimes give the thing a type which makes it even more explicit.

Something like this:

    let thing: Thing = source.prepare();
    let thing = thing.make_iterator();
    let (first, second) = thing.split();
    let first = first.filter();
    let second = second.reverse();
    let items: Vec = first.join(second);
Just to give an idea how to make a complicated ritual explicit and simple.

This simplifies debugging too. You can set a breakpoint and view the variables or you can use println!.

Re: Want cleaner code? Use the rule of six

#165

Post by nmz »

marginalia_nu wrote: post #155
khendron wrote: post #67

Earlier quoted context omitted.

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.

Emphasis on well-named. Naming things is hard. Maybe not relevant in simple toy examples, but you don't have to look far until to find a function that isn't so easy to name.

its also a level of indirection... It's sad but functions often slow performance down. but this depends on the language.

Re: Want cleaner code? Use the rule of six

#167

Post by rak1507 »

overgard wrote: post #142
he0001 wrote: post #106

This is so subjective. Some people do want to write such code as that is “cleaner” because it’s compact. Some wants to explain every single step because that’s “cleaner”. Some tries to do something in between and it’s somehow “cleaner”. But in the end, it’s mostly subjective.

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.

Re: Want cleaner code? Use the rule of six

#168

Post by marginalia_nu »

nmz wrote: post #165
marginalia_nu wrote: post #155

Earlier quoted context omitted.

Emphasis on well-named. Naming things is hard. Maybe not relevant in simple toy examples, but you don't have to look far until to find a function that isn't so easy to name.

its also a level of indirection... It's sad but functions often slow performance down. but this depends on the language.

Can't be many languages where that matters in 2022. Auto-inlining of short functions was a thing in the 1990s.

Re: Want cleaner code? Use the rule of six

#169

Post by kevin_thibedeau »

jstimpfle wrote: post #27
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.

Typically, relatively unspecific names like "i" or "size" are good enough. It's better than not naming at all and producing a complicated expression tree instead. More specific names cost energy, both inventing and reading them (because they are typically longer). Err on the side of short and not too specific.

It depends. Go spelunking through old Unix and Gnu code from the 80s and you'll see a lot of maddening usage of single and double letter variables all over the place where a descriptive name would make things much more readable.

Re: Want cleaner code? Use the rule of six

#170

Post by aaronbrethorst »

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 write this code. Instead, I'll be able to better ascertain what my assumptions were, how they fell apart in practice, and what a minimal, correct fix that doesn't make things worse might be.

Edit: Incidentally, this also applies to my commit messages. I’m writing them primarily for my future self so that I can figure out WHY I made a change, not WHAT the change was.

Post reply on HN