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

261–270 of 352 posts

Re: Want cleaner code? Use the rule of six

#261

Post by AnimalMuppet »

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…

> Each function becomes something new that needs to stick in your brain.

But if you don't put it in a separate function, then all that code becomes something that you have no choice but look at as part of this function, because the text of it is right there in the function.

Sticking part of the code in a sub-function gives you the choice: Do I trust that this function does what it says, with no other effects that I have to worry about? Or do I go look at it to make sure?

But not sticking the code in a sub-function gives you no choice - it's right there as part of the function you're looking at, and you have to see what that code is doing as part of understanding the function. And having that code not in a separate function makes it more likely that it has side effects that can mess up the rest of the function (separate functions is a firewall against side effects).

Re: Want cleaner code? Use the rule of six

#262

Post by tomlin »

samtheprogram wrote: post #195
tomlin wrote: post #191

Earlier quoted context omitted.

Ruby maps are so ugly. .map { |key_value| key_value.partition('=')[-1] } Reading this literally makes me sick to my stomach. Language design is much more important than language popularity, although it will be popularity that wins. (Yay downvotes for pointing out things everyone can see - highschool dynamics)

Just because it’s a different syntax than you’re used to reading in another language doesn’t make it ugly. If you’re used to reading it and work in the language regularly, it actually looks quite clean. This sounds like a Windows user who can’t stand macOS because they don’t know where anything is. Your post downvote edit assumes your opinion here is objective. It isn’t.

Parentheses as pipes is what you do when you’ve backed yourself into a corner.

Ruby has decided (for some reason?) to use two ways to declare.

Function(param, param)

and

{ |param, param| }

why? What is a good reason for this?

It would be an anti pattern in design, not sure why Ruby gets a special hall pass.

Re: Want cleaner code? Use the rule of six

#263

Post by Supermancho »

chii wrote: post #257
Supermancho wrote: post #235

Earlier quoted context omitted.

> If you are unit testing you should not have to worry about tweaking a function and it breaking everywhere else. "should" is a word loaded with authority. Why? If you believe a unit tests is for turning an impure function into a pure function (so you can just test what it's doing and no other effects), then in many cases tweaking will break existing unit tests. If the function exists, it's assumed it's used by more…

> breaks the known contracts with other units. which either forces you to fix those contracts - implying you have to go understand those contracts too. Or, you un-abstractify the function by keeping the original, and add a copy with the modifications you needed for the new feature/fix. This keeps the original contracts intact, but you add "bloat" to code - a form of tech-debt.

Indeed on both counts.

This is a demonstration of why a code change may seem simple in theory, but when you actually do it, you can see all the side effects that you didn't consider when estimating. This is one of the many ways that estimation without looking at existing code, can be completely off...not to say it will be right-on when estimating and looking at code. I have worked a company with 8 hour planning, where every single change is by committee while looking at existing code. Mercifully, this methodology didn't last more than a few months.

Re: Want cleaner code? Use the rule of six

#264

Post by quickthrower2 »

This seems a little light to me, doesn’t give me the feeling of being written by a veteran coder. Unless the idea is to dumb it down for a particular audience.

The real answer is write code like you write words: Rework it to make sense to the reader. How many newlines you need as a hint for your editor to wrap and where you put them will fall out of that.

Or autoformat! I love autoformatters!

Edit: edited to make easier to parse mentally.

Re: Want cleaner code? Use the rule of six

#265

Post by quickthrower2 »

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.

React makes it funner. [score, setScore] = useState … means you gotta think of another name for any intermediate “score”-like sub calculations in all the scope levels of the functional component. (Or yuk keep track of the scope you are in mentally). Then throw the firebase api on top of that with it’s myriad intermediate step api and fun fun fun.

Re: Want cleaner code? Use the rule of six

#266

Post by 29athrowaway »

mod wrote: post #244
29athrowaway wrote: post #107

Earlier quoted context omitted.

What is easier to read: a) 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 b) 20 If all the code in your project was written like a), how would you feel? Does it make your job easier or harder? I'll tell you how most people feel when they read code that looks like a): - The author didn't care about other maintainers. - The author is selfish and does not have empathy for others. - The aut…

If your comment were code, I think it's an example of a)

Fair enough, but a strong point had to be made.

Re: Want cleaner code? Use the rule of six

#267

Post by aaronbrethorst »

Karellen wrote: post #238
aaronbrethorst wrote: post #170

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…

> My opinion is that... You make it sound like you came up with that all by yourself

Nah, I stand on the shoulders of generations of developers, just like everyone else here.

I didn’t claim my opinion was novel, just that it’s mine. I hope others share my opinion, because I’d find codebases that fit my criteria easier to maintain than many other types.

Also, do you agree or disagree with any of the ideas I put forth?

Re: Want cleaner code? Use the rule of six

#268

Post by vbezhenar »

somehnguy wrote: post #44
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.…

Looks similar to Streams in Java. We try to use that style where appropriate as it is much more readable and compact than imperative style imo.

For me that's questionable. Yes, there's code which fits finely with streams and looks very readable. Yet there's code which looks like it was shoehorned into a Procrustean bed and looks much better with ordinary loops.

Re: Want cleaner code? Use the rule of six

#269

Post by veltas »

wizofaus wrote: post #160
jonnycomputer wrote: post #55

Earlier quoted context omitted.

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

It's been my feeling for a while that debugger technology hasn't really caught up with newer styles of coding (despite them having been around for over a decade). Only being able to set a breakpoint at a line-level or watch values that are assigned to a named variable is incredibly limiting.

gdb for a long time has been able to watch almost any expression at all. Unfortunately the visual studio debugger can't watch very much at all and that's what many of us are stuck with.
Post reply on HN