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

271–280 of 352 posts

Re: Want cleaner code? Use the rule of six

#271

Post by kristopolous »

davnicwil wrote: post #73
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.…

> the code can't be read top-to-bottom The idea of the technique is to split out code at a different level of abstraction with a clear name communicating what it does, while hiding the details of the how, because you don't need to care about that detail at all to fully grok the code in the calling function. Where this breaks down is when the code you're trying to split out is not at a different level of abstraction,…

The problem is those who create the messes to need that advice probably will take that advice and create even bigger messes

In practice, pithy adages don't get us any closer to sanity

Really the only news you can use is

1. Try to modify things with code you didn't write by not simply throwing parts away

2. If you think it's really difficult to deal with, figure out if other people agree with you.

3. understand why everybody thinks this

4. If you are doing that in your own code, then stop doing that.

You have to viscerally understand why a practice is bad and how doing it affects other people.

This is how you can intuitively avoid such practices in the future. Not through things that rhyme or acronyms that spell words but through social intelligence. It's fundamentally behavior

Re: Want cleaner code? Use the rule of six

#272

Post by geewee »

I'm really tired of hearing the 4 items +/- 2 being parroted around in cases like these. The studies that come to that number are basically "Remember these completely arbitrary things such as numbers or words in order". That's nothing like reading lines of codes where you have variable names, and you're able to construct meaning and relationship between the things in your mind.

Sure, it might be relevant if all variables were named "x", "xx", "xx", - but they're not.

Re: Want cleaner code? Use the rule of six

#273

Post by soulofmischief »

> STM and WM are small. Both can only store about 4 to 6 things at a time!

I'm sorry but this is such an asinine statement. Your brain doesn't store "things" and the number of working items depends on so many factors the complexity of the information, the level of association between items, the attention span of the individual, which can be trained, and a multitude of other things.

Neuroscience is a useful tool for self-programming but you must be careful peddling absolutist statements like this which can do more harm than good.

Re: Want cleaner code? Use the rule of six

#274

Post by danmaz74 »

davnicwil wrote: post #73
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.…

> the code can't be read top-to-bottom The idea of the technique is to split out code at a different level of abstraction with a clear name communicating what it does, while hiding the details of the how, because you don't need to care about that detail at all to fully grok the code in the calling function. Where this breaks down is when the code you're trying to split out is not at a different level of abstraction,…

I understand the idea, but it requires:

* great ability at naming methods - which isn't very common * massive discipline at RE-naming methods when they get changed even slightly to do something more

Regarding the latter, I've seen so many times methods which originally described what they were doing, but now they don't any more, that I never just trust the name to tell me what a method really does.

Re: Want cleaner code? Use the rule of six

#275

Post by rocqua »

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.

Those functions get more annoying when debugging though. Because now you have to jump to the body of the function to see if it really does what it says. And you view the body out of context so it is harder to see if there is a wrong assumption between the callee and caller.

On the whole I think such functions are valuable. But they do have downsides.

Re: Want cleaner code? Use the rule of six

#276

Post by rocqua »

twblalock wrote: post #212
layer8 wrote: post #110

Earlier quoted context omitted.

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

We should reject tools that only help us understand code that we are writing.

Put differently, we should avoid relying on functionality that isn't present in most places where we need to understand code.

Hence, static analysis should be present in many more places than just the IDE. Merge requests, commit diffs, and perhaps code blocks in discussions are prime targets.

I think this might be one case where the CLI is truly limiting us. No opportunity for contexts menus or pop-ups makes presenting the results of static analysis much harder.

Re: Want cleaner code? Use the rule of six

#277

Post by watwut »

rocqua wrote: post #275
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.

Those functions get more annoying when debugging though. Because now you have to jump to the body of the function to see if it really does what it says. And you view the body out of context so it is harder to see if there is a wrong assumption between the callee and caller. On the whole I think such functions are valuable. But they do have downsides.

Genuinely, they ate not annoying to me at all when debugging. I check whether function returned what I expected from its inputs and either look for bug there or move on.

I don't recall much jumping put and in.

Re: Want cleaner code? Use the rule of six

#278

Post by watwut »

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

No, this pipeline is not more readable. It is a annoying to have to constantly have to read it. It makes it harder to figure out what larger algorithm and design is.

Re: Want cleaner code? Use the rule of six

#279

Post by catlifeonmars »

danmaz74 wrote: post #274
davnicwil wrote: post #73

Earlier quoted context omitted.

> the code can't be read top-to-bottom The idea of the technique is to split out code at a different level of abstraction with a clear name communicating what it does, while hiding the details of the how, because you don't need to care about that detail at all to fully grok the code in the calling function. Where this breaks down is when the code you're trying to split out is not at a different level of abstraction,…

I understand the idea, but it requires: * great ability at naming methods - which isn't very common * massive discipline at RE-naming methods when they get changed even slightly to do something more Regarding the latter, I've seen so many times methods which originally described what they were doing, but now they don't any more, that I never just trust the name to tell me what a method really does.

Naming is probably the single hardest part of writing scalable, legacy code. Cache invalidation is a cakewalk in comparison. I believe this is in part because naming is a miniature exercise in empathy for future readers particular of a piece of code.

Re: Want cleaner code? Use the rule of six

#280

Post by lifeisstillgood »

lamontcg wrote: post #209
davnicwil wrote: post #73

Earlier quoted context omitted.

> the code can't be read top-to-bottom The idea of the technique is to split out code at a different level of abstraction with a clear name communicating what it does, while hiding the details of the how, because you don't need to care about that detail at all to fully grok the code in the calling function. Where this breaks down is when the code you're trying to split out is not at a different level of abstraction,…

Each function becomes something new that needs to stick in your brain. Someone that applies "MORF" to their code winds up nearly inventing their own language in the file that they're writing. All that takes up more memory when you're reading their code, because due to leaky abstractions the actual implementation of whatever the function name that you replace it with is often important. I have an actual track record o…

Err - OK - my google fu is failing me. What is MORF (I assume it's some kind of acronym for refactoring ...)
Post reply on HN