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

241–250 of 352 posts

Re: Want cleaner code? Use the rule of six

#241

Post by 3pm »

overgard wrote: post #127
3pm wrote: post #108

Reminded me of 'Object Calisthenics' by Jeff Bay. Basically an exercise for a toy project where you adhere to 9 rules: 1. Only One Level Of Indentation PerMethod 2. Don’t Use The ELSE Keyword 3. Wrap All Primitives And Strings 4. First Class Collections 5. One Dot Per Line 6. Don’t Abbreviate 7. Keep All Entities Small 8. No Classes With More Than Two InstanceVariables 9. No Getters/Setters/Properties https://william…

Oof, these all seem absurd to me. > 1. Only One Level Of Indentation Per Method One level of indentation just leads to an explosion of tiny one-use methods with weird names, and now you can't read the code linearly. You will almost certainly never reuse these tiny methods, especially since you're likely consigning them to an instance of a class instead of a free function, so all you've done is forced people to jump a…

Please keep in mind that these were rules that you apply to a _toy_ project. You apply the rules once, blindly, even if they don't make sense to you at the moment. Then, when you work on a real thing, you may remember, for example, to create a dedicated PhoneNumber class with strict rules (e.g. E164) instead of a string that gets shuffled around with no one really knowing whats inside. Or you just forget the rules as a nonsense and move on.

You seem to be criticizing the 'rules' as if they are suggested for production code. You couldn't be seriously thinking someone suggest maximum-of-2-fields as some sort guideline for the real world.

Re: Want cleaner code? Use the rule of six

#243

Post by Teckla »

kevin_thibedeau wrote: post #169
jstimpfle wrote: post #27

Earlier quoted context omitted.

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.

Or go spelunking through modern Go code.

Variable names that are so terse it hinders reading and comprehension.

Re: Want cleaner code? Use the rule of six

#244

Post by mod »

29athrowaway wrote: post #107
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…

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)

Re: Want cleaner code? Use the rule of six

#246

Post by [deleted] »

overgard wrote: post #227
jstimpfle wrote: post #216

Earlier quoted context omitted.

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…

Honestly mate, I just don't really understand the point you're trying to make. Originally it was that it doesn't matter if the line-by-line code is understandable because the high level design is what's important. I think the line by line clarity is important, because if that's confusing in my experience the design tends to be muddled also. But then you have these definitions of bottom up and top down that are very c…

[deleted]

Re: Want cleaner code? Use the rule of six

#247

Post by dasil003 »

Although I agree the original line is a bit long, and the first refactoring is a clearly more readable, but after that it starts to feel like bike-shedding. FWIW I don't believe in refactoring things into tiny methods that are just used once—it's a lot of boilerplate which makes zero sense if you are not going to reuse it, but it's not the hill I'm going to die on.

Overall a lot of this boils down to minor style issues. I care very little if you give me 5 short lines with named intermediate steps versus a dense one-liner, however I do care very much if your code leverages pure functions, minimizes cyclomatic complexity, encapsulates messy bits, and has some form of test coverage. The former might take me a minute or two longer to grok (depending on my personal context), but the latter compounded over a wide surface area can lead to a completely unmaintainable system and a pathological fear of touching anything.

Re: Want cleaner code? Use the rule of six

#248

Post by exabrial »

The suggestions here are so not 1337. The whole point of writing code is to show off how much smarter you are. During code reviews, you can teach everyone else a lesson; you’re basically doing them a favor by making them read your 1337 code. If they can’t read your code they aren’t your equal.

Lame.

Re: Want cleaner code? Use the rule of six

#249

Post by majormajor »

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…

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

"Better names" is a good answer for a sloppy pattern that looks like this:

fun saveRecord(record){

wireRecord = record.toWireRecord();

innerSaveRecord(wireRecord)

}

fun innerSaveRecord(wireRecord){

log("saving record " + wireRecord)

saveWireRecord(wireRecord)

}

That's a stupid level of nesting instead of a reasonably-named "convertAndLogAndSaveRecord()" - then you get into debates about if logging should be in that name, otherwise it's happening despite the name not saying it, etc.

So all that to say that moving into functions alone can be good, or can be bad.

The easiest-to-define benefit of the verbosely-named "convertAndLogAndSaveRecord()" is that it becomes easily testable vs having those lines inlined somewhere. (I'm often much more ambivalent on "reuse" benefits - if your function is specific it can't be made reusable without making it less well defined.)

But as far as I know, the world doesn't offer me a way to test that the function not only does what it says but doesn't do what it doesn't say. And it's similarly hard to talk other programmers out of shoehorning new logic into existing functions - now making them harder to reason about - rather than new functions that are composed differently or with the existing ones.

Because if "checkAccountingProcessResultsAgainstAudit" is going to give you readability benefits, it damn well better do what it says every time you call it instead of becoming a maze of conditionals and optional behavior.

Re: Want cleaner code? Use the rule of six

#250

Post by jollybean »

I object to the 're-write as function'.

Functions come with abstraction overhead. You don't know who will consume them, so you may have to put up type checks, null checks other BS.

Also - functions split up the logic all over the place, it's confusing.

I think what we need are 'nested functions' which serve to kind of create a scope pushed to the stack - with an implicit 'return' - which we can then 'collapse' in the GUI etc..

I mean, it's purely cosmetic from a CS point of view, but it might help to organize things a bit better and hand off abstractions in long function implementations.

Huge projects with 1 or 2 line functions drive me crazy - you have to constantly jump around all over place to figure out what's going on. I actually believe it's a historic anti-pattern.

I make functions when we need 1) used in different places 2) meaningful abstraction.

Otherwise, well documented longer functions for me.

Post reply on HN