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

311–320 of 352 posts

Re: Want cleaner code? Use the rule of six

#311

Post by klibertp »

tomlin wrote: post #262
samtheprogram wrote: post #195

Earlier quoted context omitted.

Just because it’s a different syntax than you’re used to reading in another language doesn’t make it ugly. If you’re used to reading it and work in the language regularly, it actually looks quite clean. This sounds like a Windows user who can’t stand macOS because they don’t know where anything is. Your post downvote edit assumes your opinion here is objective. It isn’t.

Parentheses as pipes is what you do when you’ve backed yourself into a corner. Ruby has decided (for some reason?) to use two ways to declare. Function(param, param) and { |param, param| } why? What is a good reason for this? It would be an anti pattern in design, not sure why Ruby gets a special hall pass.

   collect: [ :keyAndValue | (keyAndValue splitAt: '=') last ].
is why.

EDIT: (it's been a few months since I used it, so I) made a mistake in the syntax (declared local variable instead of a formal block argument), it's fixed now.

Re: Want cleaner code? Use the rule of six

#312

Post by tomlin »

klibertp wrote: post #311
tomlin wrote: post #262

Earlier quoted context omitted.

Parentheses as pipes is what you do when you’ve backed yourself into a corner. Ruby has decided (for some reason?) to use two ways to declare. Function(param, param) and { |param, param| } why? What is a good reason for this? It would be an anti pattern in design, not sure why Ruby gets a special hall pass.

collect: [ :keyAndValue | (keyAndValue splitAt: '=') last ]. is why. EDIT: (it's been a few months since I used it, so I) made a mistake in the syntax (declared local variable instead of a formal block argument), it's fixed now.

You might as well have leaned on the keyboard, it wouldn’t look much different. This is not readable code.

Re: Want cleaner code? Use the rule of six

#313

Post by extasia »

marginalia_nu wrote: post #168
nmz wrote: post #165

Earlier quoted context omitted.

its also a level of indirection... It's sad but functions often slow performance down. but this depends on the language.

Can't be many languages where that matters in 2022. Auto-inlining of short functions was a thing in the 1990s.

This may be true for compiled langs. In interpreted langs this is not the case. Function calls in Python for example are notoriously expensive.

Re: Want cleaner code? Use the rule of six

#314

Post by klibertp »

tomlin wrote: post #312
klibertp wrote: post #311

Earlier quoted context omitted.

collect: [ :keyAndValue | (keyAndValue splitAt: '=') last ]. is why. EDIT: (it's been a few months since I used it, so I) made a mistake in the syntax (declared local variable instead of a formal block argument), it's fixed now.

You might as well have leaned on the keyboard, it wouldn’t look much different. This is not readable code.

No post body was provided.

Re: Want cleaner code? Use the rule of six

#315

Post by Rexxar »

Karellen wrote: post #297
aaronbrethorst wrote: post #267

Earlier quoted context omitted.

Nah, I stand on the shoulders of generations of developers, just like everyone else here. I didn’t claim my opinion was novel, just that it’s mine. I hope others share my opinion, because I’d find codebases that fit my criteria easier to maintain than many other types. Also, do you agree or disagree with any of the ideas I put forth?

I don't disagree, I just think it's only right to credit the original authors when you use their exact phrasing.

I think we have a problem if we need now to credit the original "author" of every opinion we have.

Re: Want cleaner code? Use the rule of six

#317

Post by sidlls »

lelanthran wrote: post #285
sidlls wrote: post #91

Earlier quoted context omitted.

The first quote is an over-simplification that often does not hold in practice: one usually needs both. The exceptions are mostly trivial programs.

> The first quote is an over-simplification that often does not hold in practice: one usually needs both. The exceptions are mostly trivial programs. Depends, but not on the complexity of the application. Given the data design of even the most complex set of applications that all interact with the same data, you can almost always predict what business logic is supported by the set of applications. Given all the code…

> Given the data design of even the most complex set of applications that all interact with the same data, you can almost always predict what business logic is supported by the set of applications.

How so? Every table, file, or other data structure added increases the possible of uses with factorial complexity (think of, e.g., the traveling salesman or other graph/network problems). Without seeing something else, e.g., the code, a flowchart, or other diagrams it is impossible to predict what the program actually does. One can guess at bits and pieces of it, but not more.

It’s like saying that given a table of numbers one can predict exactly what functions produced them.

Re: Want cleaner code? Use the rule of six

#318

Post by ethbr0 »

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.

Fair. In my practical experience, it's 50/50 2x clever vs 2x time.

Mostly down to task decomposition.

Some of the stuff in compiler debugging? Just 2x clever, because you have to hold it all in your head at once to solve it.

Circuit debugging or data transformation debugging? You can break it down into smaller pieces, then methodically (and laboriously) worth through those pieces.

Re: Want cleaner code? Use the rule of six

#319

Post by nmz »

extasia wrote: post #313
marginalia_nu wrote: post #168

Earlier quoted context omitted.

Can't be many languages where that matters in 2022. Auto-inlining of short functions was a thing in the 1990s.

This may be true for compiled langs. In interpreted langs this is not the case. Function calls in Python for example are notoriously expensive.

Beat me to it. Yes, I ran a quick benchmark[0] and not running a function always wins. now, one may argue that you are running a call, but if the interpreter was smart it would convert the small function calls to just a noops.

[0]: https://github.com/Nomarian/crapbenchmarks/tree/main/call

  Summary
  'Perl/nofunc' ran
    1.63 ± 0.30 times faster than 'Perl/func'
    1.73 ± 0.34 times faster than 'Lua/nofunc'
    2.11 ± 0.55 times faster than 'Lua/func'
    9.37 ± 1.62 times faster than 'Python/nofunc'
   12.18 ± 1.90 times faster than 'TCL/nofunc'
   16.02 ± 2.58 times faster than 'TCL/func'
   18.64 ± 3.02 times faster than 'Python/func'

Re: Want cleaner code? Use the rule of six

#320

Post by lelanthran »

sidlls wrote: post #317
lelanthran wrote: post #285

Earlier quoted context omitted.

> The first quote is an over-simplification that often does not hold in practice: one usually needs both. The exceptions are mostly trivial programs. Depends, but not on the complexity of the application. Given the data design of even the most complex set of applications that all interact with the same data, you can almost always predict what business logic is supported by the set of applications. Given all the code…

> Given the data design of even the most complex set of applications that all interact with the same data, you can almost always predict what business logic is supported by the set of applications. How so? Every table, file, or other data structure added increases the possible of uses with factorial complexity (think of, e.g., the traveling salesman or other graph/network problems). Without seeing something else, e.g…

> How so? Every table, file, or other data structure added increases the possible of uses with factorial complexity (think of, e.g., the traveling salesman or other graph/network problems).

Only if they're randomly named.

> Without seeing something else, e.g., the code, a flowchart, or other diagrams it is impossible to predict what the program actually does.

Seeing a table named "invoices", which has a column named "user_id" that is a foreign key for table "user" doesn't give you at least a few clues about the business logic there?

Seriously, I want to see an example (choose an open source project) of a project where the data structures don't give any clue to what the business logic is.

Once you go looking for that example, you'll see why the data structures are more revealing than looking at the code.

Post reply on HN