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

211–220 of 352 posts

Re: Want cleaner code? Use the rule of six

#211

Post by lamontcg »

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.

Emphasis also on "bunch of lines".

Usually when I see one-line functions they cost more in short term memory than they save. There's good exceptions to this with something like a horrible conditional that is necessarily horrible so you can bust it out into a method with a doc comment about the horribleness, its history, and its subtle madness. But developers that just break out one-line methods all over the place wind up writing hard to understand code.

Re: Want cleaner code? Use the rule of six

#212

Post by twblalock »

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…

> 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, ...).

Yes, we absolutely should rely on that.

Why would programmers, who are basically tool-builders, reject tools that help us write and analyze our programs? This is not the 1970s, and bare-bones text editors are not the only option. Why should we, who build tools for others, restrict ourselves to a self-imposed unreasonable simplicity?

You are free to use Vi or whatever, but don't complain when everyone else uses better tools to improve their productivity, and if the code they write is better suited for those tools that is perfectly fine.

Re: Want cleaner code? Use the rule of six

#213

Post by dqpb »

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.

> Naming things is hard

Naming is hard unless you have a sensible concept hierarchy, and then naming is easy.

Concept hierarchies are hard, unless you have a sensible system model, and then concept hierarchies are easy.

System models are hard, unless you have domain expertise, and then system models are easy.

Re: Want cleaner code? Use the rule of six

#214

Post by mlochbaum »

overgard wrote: post #198
ParetoOptimal wrote: post #188

Earlier quoted context omitted.

Can you objectively say that familiarity isn't the primary reason APL is less understandable? Put another way, if you had 2 years of APL experience and 2 years of Python experience, would you maintain that the APL code is objectively less clear? Is it really fair to judge languages we aren't familiar with to the extent of the language we are comparing to?

Well, it'd be fairly easy to test: teach a first year coding course, give one group python and the other group APL, and monitor the grades and the drop rate. I can't prove it, but I'm highly confident that python would win. Because it has a lot of analogies to things people already know: - In simple cases, you can read it as a set of commands, like a recipe. People are familiar with recipes - Syntax mostly uses well…

I know a few people who've taught APL to kids or other non-programmers and the most common remark is how much quicker they get it than students who've worked with other languages. I don't know what the result of the experiment you describe would be but you're definitely biased by your experience. And as a counterpoint to your example, here's the code to multiply several numbers by two in both Python in APL:

    x = [1,2,3]
    [n*2 for n in x]

    2 × 1 2 3
We have forums: APL Farm is the most consistently active. If you'd like to talk to real live APLers just hop in.

https://aplwiki.com/wiki/Chat_rooms_and_forums

Re: Want cleaner code? Use the rule of six

#215

Post by djbusby »

dqpb wrote: post #213
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.

> Naming things is hard Naming is hard unless you have a sensible concept hierarchy, and then naming is easy. Concept hierarchies are hard, unless you have a sensible system model, and then concept hierarchies are easy. System models are hard, unless you have domain expertise, and then system models are easy.

Domain expertise is hard.

Re: Want cleaner code? Use the rule of six

#216

Post by jstimpfle »

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.

From the post: "if the reusable code is already suitable, you just use it, but if it’s not, you decide whether or not you should modify how it works, or whether you should introduce a new layer on top of or underneath it."

I'm having a really hard time interpreting this as "you should design / program bottom-up".

If you go to Wikipedia, bottom-up design is roughly defined as taking the existing stuff and building new things on top. I still fail to see where the compression part comes in here.

Neither of the two directions will look back at the mess they've made and compress it. They're just ways to develop the system by adding to it incrementally.

But then, these terms are generally poorly understood (as evident from various discussions I've had) and I don't want to claim to have the perfect understanding either. Nor do I want to be "Look"'ed any more. So, whatever.

Re: Want cleaner code? Use the rule of six

#217

Post by macintux »

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…

> In addition, that code example is easily testable.

I'm skeptical, because typically a line like that is embedded in the middle of a larger function.

Extracting the logic into a dedicated, pure function helps with testing.

Re: Want cleaner code? Use the rule of six

#218

Post by lamontcg »

wizofaus wrote: post #156
chrisweekly wrote: post #136

Earlier quoted context omitted.

Yes! IME (24y and counting in the profession) devs reach too quickly for DRY while neglecting its counterbalancing principle: AHA (Avoid Hasty Abstractions).

I've seen this complaint before and it doesn't really align with my experience of frequently seeing literal duplication of code where no extra abstraction was required to avoid it - just selecting the code in question and factoring it out into a function, which, providing you named it sensibly, would also make the code easier to understand and debug. I could count on one hand the number of times I've seen code where…

The point isn't to maintain the repeated code forever. The point is to generate the repeated code and (maybe) live with it for a bit until you understand what the right abstraction is and then remove the duplication with the correct abstraction.

I've lost track of the number of times that I've taken badly abstracted code, reintroduced all the duplication, then refactored to remove the duplication with an entirely different abstraction and the code was many times easier to read.

And have you lived in a codebase for many years, where you've never come back to a method that you extracted and realized that you named it wrong? Or the requirements of the code grew and the duplication wasn't really at the level that you picked and you wind up with a method that grows all kinds of horrible options to change its internal behavior?

Re: Want cleaner code? Use the rule of six

#219

Post by schemathings »

For the example in the text I'd typically just include a one line comment above to show what an example string would look like and leave the code as is

# URL with params https://news.ycombinator.com/item?id=32963021&something=valu...

map(lambda x: x.split('=')[1], s.split('?')[1].split('&')[-3:])

Re: Want cleaner code? Use the rule of six

#220

Post by mafuy »

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

That avoids bugs and misunderstandings, too.

You know this, but for those unaware, in the previous example, x is not initialized to 3. Similarly, in "int* p1, p2;", p2 is an int, not an int*. Easy to misread.

Post reply on HN