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

181–190 of 352 posts

Re: Want cleaner code? Use the rule of six

#181

Post by ParetoOptimal »

guenthert wrote: post #32
whynotminot wrote: post #19

Earlier quoted context omitted.

I think there's a real smell with those long, dense lines of code. Tends to mean your data structures are out of control: objects with arrays that point to other objects that then also have arrays on them. My oh my. Comments being required are also another smell that the code doesn't explain itself. I know this is said so often it's a cliche, but it really is true. I think both of these things point back to the same…

Sure, if the computer can figure out what a given fragment of code is supposed to do, so can you (a sufficiently clever programmer). The question rather is, do you spend 20s reading a comment or 15m to solve the riddle? There's a real danger that comments aren't updated when code is, particularly if 3rd parties make those changes. This is one of the corners where there will never be a single answer which is right in…

> There's a real danger that comments aren't updated when code is, particularly if 3rd parties make those changes

That problem exists because no one denies pull requests or rejects code that has outdated comments.

Re: Want cleaner code? Use the rule of six

#182

Post by patrick451 »

onion2k wrote: post #94
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.

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.

Re: Want cleaner code? Use the rule of six

#183

Post by ParetoOptimal »

professorTuring wrote: post #30
standardUser wrote: post #18

I see a troubling trend with some coworkers where they seem to stretch the limits of time and space to make every line as dense as possible, usually using lodash. I think it is a point of pride for them, but I think it's obvious that everyone's life would be easier if they just wrote their code out "long form" and, god willing, added some comments for various steps. Instead, I find myself having to re-write ultra-den…

It is not new, it’s been ages since some developers try to show off by bringing “cool” one liners to solve problems. Stretching operators, bringing up imaginative uses for lambda expressions or kind of abusing parts of the language to make some other teammate or reviewer, What did you make there? I believe, definitely, that they are quite intelligent people that know a lot about the language or maths, but definitely…

At least in Haskell, I feel like this doesn't hold true.

Typically more concise code takes advantage of core language abstractions.

It is actually simpler unless you are unfamilar with core language abstractions, but I'd argue that's a you problem.

Re: Want cleaner code? Use the rule of six

#184

Post by sidlls »

edgyquant wrote: post #152
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.

Unless the test cases are incomplete. Or the CI jobs are configured to run tests independently and off-cadence so that code that would break is tested after a merge. Or the tests have a bug in them. And so on.

Re: Want cleaner code? Use the rule of six

#185

Post by ParetoOptimal »

happyweasel wrote: post #126

use statically typed programming languages. Favor composition over inheritance . Develop bottom-up (reusable classes) instead of large-scale up-front design. SOLID principles (SRP being the most important). The Bottom-up approach also favors Unittesting. Code reviews, clear code formatting rules (simple editor plugins do the trick). Use static code analyzers. IMHO this kind of object-oriented programming leads to NEW…

> Develop bottom-up (reusable classes) instead of large-scale up-front design.

I tend to really hate the UX of bottom-up designed API's and find them incoherent.

Re: Want cleaner code? Use the rule of six

#186

Post by ParetoOptimal »

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 the comparative rarity of APL compared to every other programming language in existence says a lot

That's just the whole "popularity means it must be good" argument, which I disagree with.

Re: Want cleaner code? Use the rule of six

#187

Post by overgard »

ParetoOptimal wrote: post #186
overgard wrote: post #141

Earlier quoted context omitted.

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 the comparative rarity of APL compared to every other programming language in existence says a lot That's just the whole "popularity means it must be good" argument, which I disagree with.

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.

Re: Want cleaner code? Use the rule of six

#188

Post by ParetoOptimal »

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.

Can you objectively say that familiarity isn't the primary reason APL is less understandable?

Put another way, if you had 2 years of APL experience and 2 years of Python experience, would you maintain that the APL code is objectively less clear?

Is it really fair to judge languages we aren't familiar with to the extent of the language we are comparing to?

Re: Want cleaner code? Use the rule of six

#189

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]
Post reply on HN