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

151–160 of 352 posts

Re: Want cleaner code? Use the rule of six

#151

Post by overgard »

mike_hock wrote: post #147
overgard wrote: post #105

Earlier quoted context omitted.

Your mileage clearly varies, but I found the transformed example much easier to understand. While I suspected it was parsing a query string from the initial code, having that stated explicitly in the variable removed the guessing. I think the main problem is he just didn't go far enough, there was still more to deconstruct. I suppose the function to parse the query string could have been better, its name isn't very d…

It would presumably be evident from the context in which the `map` call appears what its purpose is.

And yet, I know python and have 15 years of professional experience coding, and (in the limited time I wanted to spend on it), I still don't exactly know what he was trying to accomplish. So congrats if you got it, but I'm sticking with my claim that it's fairly non-obvious. I understand that it's pulling out the last three elements. I have no idea why it's pulling out the last three elements, what purpose that serves and why it's desirable. If those elements were placed in a well named variable, I suspect it'd give a hint as to why the code is doing that. Alas.

Re: Want cleaner code? Use the rule of six

#152

Post by edgyquant »

didibus wrote: post #144

What the author is missing is that easy to read/reason/understand about is within the context of making a change to the code to fix a bug, add a feature or make some non-functional improvement to it. This is what most of the "easy to read" articles forget. Show me why it is easier to fix a bug, add a feature or make a non-functional improvement to the code with their style than without. For example, if you've extract…

If you are unit testing you should not have to worry about tweaking a function and it breaking everywhere else.

Re: Want cleaner code? Use the rule of six

#154

Post by jstimpfle »

overgard wrote: post #148
jstimpfle wrote: post #139

Earlier quoted context omitted.

It is superficial. No amount of trying to pretty up the code can fix underlying design deficiencies. That's what I said, so we're not even disagreeing here :) I know the semantic compression post, and I don't think it makes a point for bottom-up design. I find top-down and bottom-up to be quite misleading anyway. Someone told me, they don't like to think of things at the "top" and the "bottom". It's data transformati…

Well, you might know of that blog post, but might want to reread it, I don't think it says what you think it says. The example he steps through is very clearly bottom up. He even outright says it: > This is a very bottom-up programming methodology, a pseudo-variant of which has recently gained the monicker “refactoring”, even though that is a ridiculous term for a number of reasons that are not worth belaboring at th…

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 a high level before you know the platform and other functional requirements, which is top-down design.

So that's perhaps a justification why I said earlier that these terms are misleading :-)

As to the other thing that I said, that bottom-up tends to create things you don't actually need, it's almost immediately following the definition of bottom-up. You can even find this on the Wikipedia page, which states that in practice, software-development typically uses a combination of bottom-up and top-down for that reason.

(In other words, always strive to know as much as possible about requirements both at the "top" as well as at the "bottom", as early as possible. Or the risk is that the design won't fit some part of the requirements and large parts need to be redone).

I still don't see the connection with what I originally wrote, in any case.

Re: Want cleaner code? Use the rule of six

#155

Post by marginalia_nu »

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.

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.

Re: Want cleaner code? Use the rule of six

#156

Post by wizofaus »

chrisweekly wrote: post #136
e_i_pi_2 wrote: post #129

Earlier quoted context omitted.

Definitely a good point, refactoring is great and has a bunch of benefits but can also be overdone and create problems. I've heard/read Sandi Metz talk about this as "The Wrong Abstraction"[1]. The basic argument is that any time you do an extract refactor you're creating a new layer of abstraction that the next reader will have to learn and understand. This can also get worse over time as the abstractions drift away…

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 repeating logic would make more sense than any extra levels of abstraction created to avoid it.

Re: Want cleaner code? Use the rule of six

#157

Post by gilch »

overgard wrote: post #141
gilch wrote: post #70

The article starts with some reasonable premises, but the conclusion does not follow. I think most APL programmers would disagree with this take. Dense code has real advantages, and naming everything has real costs that are hard to see. There's nothing magic about a "line" that suddenly allows for chunking. You have to build a parse tree in your head in any case. I'm reminded of Doug McIlroy's challenge to Knuth.[1]…

I think the comparative rarity of APL compared to every other programming language in existence says a lot. Even if I were an expert in APL, I can't think of a single place where I could get a job writing it.

I think language popularity in industry mostly comes down to path dependence[1]. It doesn't say as much as you seem to think.

A few approaches got lucky in the rapid inflationary period of the personal computer revolution (C), and the advent of the Web (Javascript), and became deeply entrenched in industry, while superior alternatives that had been known for decades missed the boat. Industry languages still haven't caught up to where Lisp, Prolog, Smalltalk, and APL were in the 1970's, but they are clearly (if slowly) trending in that direction.

APL and derivatives are still used extensively in finance, a highly competitive field, to say the least. That's where you find the jobs.

[1]: https://en.wikipedia.org/wiki/Path_dependence

Re: Want cleaner code? Use the rule of six

#158

Post by jstimpfle »

29athrowaway wrote: post #116
iafiaf wrote: post #84

Early in my career, I took to heart such books and articles and often felt guilty and lessor-programmer when I cut corners. Here's my 2 cents now: - Some of this is the coding equivalent of "6 rules for financial freedom" or "6 ways to find your dream soulmate". Generic advice that doesn't reflect highly nuanced reality. - These rules are guidelines at best. There are justifiable reasons to break them; which I do oft…

Jonathan Blow is a creative, productive and overall smart guy, but reading his code will make you want to slam your head against the wall. What irritates me the most are the long, non-linear comments full of distracting noise. It's like reading a choose your own adventure novel.

When he talks about his approach he typically mentions the importance placed on getting feedback from an actually working prototype as quickly as possible. Don't judge him by most of the ad-hoc code you've perhaps seen on twitch. But I've seen some really good-looking stuff there as well - straight to the point, no noise, not overabstracted. I would be interested what a finished project looks like.

Re: Want cleaner code? Use the rule of six

#159

Post by niea_11 »

sdoering wrote: post #153

Offtopic: The fact that the site uses a consent solution that fakes a loading screen when trying to configure (read disable) tracking/advertising is an instant bounce for me.

It's not fake. In my case, it's not working because of my adblocker. When I disable it, it works.

Re: Want cleaner code? Use the rule of six

#160

Post by wizofaus »

jonnycomputer wrote: post #55
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 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.
Post reply on HN