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

301–310 of 352 posts

Re: Want cleaner code? Use the rule of six

#301

Post by alpaca128 »

teo_zero wrote: post #290
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…

Your example is artificially designed to make your point, but imagine a case like this: # Add the left & right margins width = calculatedWidth + 1 + 1 The "+1+1" might indeed be more readable than "+2".

Yes, I sometimes do that as well to signal a part that's non-obvious or easy to overlook. Ideally with a little comment for the reason.

Same with my (admittedly rather dirty) openSCAD designs, where I like to explicitly add tolerances to the measurements while keeping them separate, e.g. `width = 34 + 0.25;`. Especially because tolerances often have to be tweaked a couple times.

Re: Want cleaner code? Use the rule of six

#302

Post by Shorel »

ziml77 wrote: post #254
onion2k wrote: post #199

Earlier quoted context omitted.

Shorter names aren't easier to read if you have several similar names used in close proximity. More characters can reduce the congruence and make it easier to differtiate between names. I agree about fitting things onto one line though. It's usually better to break things up into to several short one line steps rather than have a long multi line statement.

More characters can make it harder to differentiate names. The longer the name is, the harder it is to see it as a single unit while reading. Also, if the long names cause many extra lines, it becomes easier to lose context from the extra distance one moves down the document while reading.

If they all start with 'factory', sure.

I would be a long name that doesn't add information that helps differentiate between different variables.

Re: Want cleaner code? Use the rule of six

#303

Post by [deleted] »

teo_zero wrote: post #292
ethbr0 wrote: post #82

Earlier quoted context omitted.

I was taking my first multi-threaded resource allocation course when I first ran into the famous Kernighan quote. > “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” It clicked and instantly disabused me of the notion that smart people write code that's any smarter than the minimum requir…

Kernighan wrongly assumed that to do something twice as hard, you need someone twice as clever. Most probably you need someone just as clever and twice the time. It's a brilliant quote, though.

[deleted]

Re: Want cleaner code? Use the rule of six

#304

Post by Shorel »

Karellen wrote: post #61
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…

> Show me your flowcharts (code) and conceal your tables (data structures), and I shall continue to be mystified. Show me your tables (data structures), and I won’t usually need your flowcharts (code); they’ll be obvious. -- Fred Brooks, The Mythical Man-Month , 1975 > a computer language is not just a way of getting a computer to perform operations but rather that it is a novel formal medium for expressing ideas abo…

Well, dealing with graph algorithms, none of them are obvious from the representation. Which is usually a matrix.

In fact, Gauss Jordan is also not obvious, just seeing a matrix.

Re: Want cleaner code? Use the rule of six

#305

Post by moffkalast »

Shorel wrote: post #299
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 can write code that's easy to understand, and it is also good for the computer to run. One thing is not in contradiction with the other. It could lower the reusability of the code, by not having many abstractions, but it will be easy to understand, concise, and it will do what it was written for very well.

It should be written so it's easy for humans to understand first.

If that's too slow, then it can be optimized so it's fast, if a bit less readable.

9 times out of 10 it won't be too slow in the first place these days, unless you know beforehand that you need maximum speed for valid reasons.

Re: Want cleaner code? Use the rule of six

#306

Post by [deleted] »

patrick451 wrote: post #182
onion2k wrote: post #94

Earlier quoted context omitted.

short names You don't really need short names. I wouldn't advocate going full Java naming but trying to compress names just to save a bit of typing is unnecessary. Your IDE will help you out. Just learn to press tab when you've entered enough of the name instead of typing the whole thing.

Short names are easier to read, because they fit on fewer lines. Doubly so if the statement fits on one line.

[deleted]

Re: Want cleaner code? Use the rule of six

#307

Post by oriolid »

BiteCode_dev wrote: post #284
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.…

I don't know, it doesn't seem very far form the python version: values = ( key_value.partition('=')[-1] for key_value in s.partition('?')[-1].split('&') )

This is already showing why the the Python list/iterator comprehension syntax isn't great. The part "s.partition('?')[-1].split('&')" reads from left to right, and then the rest is read from end to beginning. It gets even more confusing with nested comprehensions. In my opinion both the dotted pipeline style and the Lisp style where you always start from the deepest nesting level are both more readable than Python's approach with sometimes from left to right, sometimes from right to left and sometimes from middle out.

Re: Want cleaner code? Use the rule of six

#308

Post by nicoburns »

AnimalMuppet wrote: post #261
lamontcg wrote: post #209

Earlier quoted context omitted.

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

I like putting comments above paragraphs of code so that you can skim it by trusting the comments, but you can also inspect any individual paragraphs implementation without losing your context.

Re: Want cleaner code? Use the rule of six

#309

Post by oriolid »

patrick451 wrote: post #182
onion2k wrote: post #94

Earlier quoted context omitted.

short names You don't really need short names. I wouldn't advocate going full Java naming but trying to compress names just to save a bit of typing is unnecessary. Your IDE will help you out. Just learn to press tab when you've entered enough of the name instead of typing the whole thing.

Short names are easier to read, because they fit on fewer lines. Doubly so if the statement fits on one line.

A special case is when you're working on something mathematical. The articles and textbooks that describe the algorithm are all using single characters do represent things, and it is just additional mental load when you read the code and algorithm description together and have to translate between descriptive names and the paper's terminology all the time.

Re: Want cleaner code? Use the rule of six

#310

Post by IshKebab »

gilch wrote: post #115
IshKebab wrote: post #111

Earlier quoted context omitted.

Of course it's bad. Is that a serious question?

No, it was rhetorical, because it's obviously (to an APL-family programmer), not bad! Your cultural prejudice is showing. There are good reasons APL is written the way it is, and this example is simply bringing those benefits to C by writing it in the dense APL style. There are other APL derivatives, like J[1] that are written in C the same way. These projects are well-maintained. They aren't collapsing under a load…

My cultural prejudice for readable code? Yes I guess it is.

As far as I can tell the main reasons for APL being written like it is are 1. it's ancient, from the world of teletype where character count was way more critical, and 2. some programmers love code-golf write-only syntax.

It reminds me a lot of regex. You could say "there are good reasons regex is so terse" and "people successfully use regex all the time" but that doesn't change the fact that it is a very write-only syntax and would be much better if it was more verbose. There are actually a lot of recent efforts to do that.

The jsource repo you linked seems to have had only 4 contributors ever, which suggests to me that it is not a popular style and not easy to read.

As far as I can tell APL had some interesting ideas in terms of data manipulation, but there's no reason those ideas have to be expressed all on one line with no comments or spaces.

Post reply on HN