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

221–230 of 352 posts

Re: Want cleaner code? Use the rule of six

#221

Post by marginalia_nu »

dqpb wrote: post #213
marginalia_nu wrote: post #155

Earlier quoted context omitted.

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.

> Naming things is hard Naming is hard unless you have a sensible concept hierarchy, and then naming is easy. Concept hierarchies are hard, unless you have a sensible system model, and then concept hierarchies are easy. System models are hard, unless you have domain expertise, and then system models are easy.

Not everything is a neat concept though.

Look at the Porter stemming algorithm for example. It simply does not decompose into something that is easy to put names on.

Re: Want cleaner code? Use the rule of six

#222

Post by jwilliams »

All comes down to good naming in the end. The craft is finding both compact and specific names.

I think the mantra for all names to be short can be counterproductive here. If the code span of a variable is short, a long name can be fine (and very clarifying, perhaps even resulting in a comment not being needed).

Shorter names for longer spans are much better. But you’d hope they’re the very obvious subject of that span.

Re: Want cleaner code? Use the rule of six

#223

Post by overgard »

ParetoOptimal wrote: post #196
overgard wrote: post #187

Earlier quoted context omitted.

I'm not saying popularity = good, what I'm saying is that most people aren't smart or patient enough to use something like APL. Most people have a limit to the amount of density they're willing to deal with.

> Most people have a limit to the amount of density they're willing to deal with. Why? I believe if you started teaching someone APL who'd never programmed before you'd never hear "this code is too dense!".

Well, I can only hypothesize, but APL is a lot like math, visually anyway. Most people are very intimidated by math.

Math tends to be written for subject matter experts. If I'm reading a paper about graphics, I know that θ is "theta" and likely means "angle in radians". If I'm not a subject matter expert, it means nothing. Of course they can write at the top "let θ = light incident angle in radians", but I still need to hold that definition in my head while I'm trying to understand the rest of it. If I simultaneously need to remember ⍵ and ε and Δ, well, I can do that if I've seen those symbols used in similar ways previously, but it's certainly going to increase the amount of things I need to hold in my head if it's something novel. And now I have to memorize what those things mean, and I suck at memorizing personally.

In contrast, most mainstream programming languages you'd just write "angle_rads" or some variant. It's a little longer, but I don't need to remember nearly as much because it's just plain english formatted in a way that at least resembles sentences I might read. I just think APL is too unfamiliar for it to be easy to learn, and so the only people that are going to learn it are those that are very intellectually curious. That's a good thing, but if you're talking popularity? Well, I think we've seen it, and it's not just path dependence.

Re: Want cleaner code? Use the rule of six

#224

Post by layer8 »

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…

I’m all for IDEs for writing software, but not as a prerequisite for reading source code, because the latter happens in all kinds of different contexts. E.g. a software like GitLab shouldn’t require an integrated static analyzer for any or all programming languages. That would only increase the barrier to entry for all software that happens to display source code. If source code can’t be read and understood as-is anymore, that just impedes interoperability and universality of tooling.

Re: Want cleaner code? Use the rule of six

#225

Post by [deleted] »

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

[deleted]

Re: Want cleaner code? Use the rule of six

#226

Post by philipwhiuk »

aidos wrote: post #202
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…

For me that's the issue with this whole example; it kinda misses the woods for the trees. # not interesting (also, use stdlib instead) def extract_url_params(url: str) -> dict[str, str]: params = url.split('?')[1].split('&') return = dict(param.split('=') for param in params) # This is the thing that needs explaining! final_3_param_values = list(extract_url_params(url).values())[-3:] By decomposing the problem in a m…

> For some reason it's just the the final 3 values they want (both weird requirements). Make that clear from the code!

Yeh, I mean the name should really tell you what those expected to be.

`hopefully_auth_param_values` is almost a better name

Re: Want cleaner code? Use the rule of six

#227

Post by overgard »

jstimpfle wrote: post #216
overgard wrote: post #176

Earlier quoted context omitted.

> It's not stating that you should start by creating lots of little artifacts before you have a great plan (bottom-up design) Look, you can disagree with his conclusion, but that is exactly what he's saying. The post is long but it's very clear and methodical about how he's suggesting code should be designed and written. I happen to agree with him.

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 confusing and seem to exist mostly to you. I'll simplify what my definition is: bottom up programming means you write the code without any abstractions first, and then you generate the abstractions as you find commonalities and repeated patterns. I find this to be superior to the other approach, of generating abstractions first and then filling in the code. That is my opinion, I know other's believe differently. And "look" is not an insult.

Re: Want cleaner code? Use the rule of six

#228

Post by philipwhiuk »

onion2k wrote: post #199
patrick451 wrote: post #182

Earlier quoted context omitted.

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

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.

I tend to think length should be proportionate to broadness of usage within the file/project

If it's used in lots of places, go for MAXIMUM_MONSTER_DENSITY_SCORE_MULTIPLIER

If it's used in a single file/function, then maxDensityMultiplier might be okay. (You can infer the rest from context).

If it's used in a very confined section, then multiplier.

If it's a loop variable then, sure use m.

Re: Want cleaner code? Use the rule of six

#229

Post by he0001 »

overgard wrote: post #142
he0001 wrote: post #106

This is so subjective. Some people do want to write such code as that is “cleaner” because it’s compact. Some wants to explain every single step because that’s “cleaner”. Some tries to do something in between and it’s somehow “cleaner”. But in the end, it’s mostly subjective.

Here's conway's game of life in APL: life ← {⊃1 ⍵ ∨.∧ 3 4 = +/ +⌿ ¯1 0 1 ∘.⊖ ¯1 0 1 ⌽¨ ⊂⍵} Is that shorter than essentially every other language implementation. Yep! However, to even begin to understand it you have to read an article from the original writer: https://aplwiki.com/wiki/John_Scholes%27_Conway%27s_Game_of_... To me, that is objectively , not subjectively, less clear than the longer implementations.

Well, to you it is, for someone else it’s “clean”. APL is a fun language and kind of my point here. Someone thought that other languages were too verbose and tried to write a language that was more expressive which a “normal” language never can achieve.

Re: Want cleaner code? Use the rule of six

#230

Post by bloaf »

readthenotes1 wrote: post #201
bloaf wrote: post #138

I have pretty mixed feelings about this. Personally I find it much easier to debug code that: 1) fits entirely on my screen and 2) doesn't involve much state modification Every intermediate variable is a chance for me to miss some modification (e.g. it was passed to a func that modifies its arguments) and consequently misunderstand what is happening. I've been experimenting in Python with the function chaining style…

Do you really write a very long comment after every function call? And have you looked at code that's over a year old and modified by other people to see how poorly those comments now match the code?

No. I did that for people having a first exposure to this non-idiomatic currying/function chaining.

In actual code I would have put most of those on one line.

Post reply on HN