Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Clear is better than clever [pdf]

dave.cheney.net

Post reply on HN
Print view View original

311–320 of 335 posts

Re: Clear is better than clever [pdf]

#311

Post by rishav_sharan »

michaelcampbell wrote: post #197
pier25 wrote: post #167

Earlier quoted context omitted.

> It's not about the line count, it's about expressing the main idea clearly and succinctly I disagree. I find no clarity in using nested ternaries, but I understand it's a matter of opinion.

I find German inscrutable, and yet Germans don't. Everything's hard to read until you learn to read it.

Or don't learn German but continue speaking in English which is inherently same as German in functionality but at least you and people around you can understand each other.

Re: Clear is better than clever [pdf]

#312

Post by brigandish »

pojzon wrote: post #288
brigandish wrote: post #284

Earlier quoted context omitted.

I've not heard of the supplier pattern, any chance you would direct me to a resource about it?

Im pretty sure you know what i meant, no need for nitpicking. (Does not make me any less right)

I can't nitpick what I don't know about. I know the strategy pattern, not the supplier pattern.

It sounds interesting, that was all.

Re: Clear is better than clever [pdf]

#313

Post by Retric »

userbinator wrote: post #21

It's interesting that the comparator function is one of the examples, because that's something which shows how people often confuse verbose with clear ; I think it's best written in a single line: return a b ? 1 : 0; That's one line, compared with the 10(!) of his proposed method using a switch statement. Having worked with some "modern" codebases, I think verbosity is a bigger problem that's become especially preval…

That’s a nested if statement which stops being clear.

  return a > b ? 1 : a  b ? 1 : a == b ? 0 : -1;
  return a != b ? a > b ? -1 : 1 : 0;  
  return a != b ? a
Are all equally valid ways of writing that code. You can get used to a convention that makes it seem more clear, but reading it they are all equally easy to decode.

Re: Clear is better than clever [pdf]

#314

Post by userbinator »

Cthulhu_ wrote: post #305
userbinator wrote: post #282

Earlier quoted context omitted.

No, it doesn't. In most other industries, you are simply considered incompetent if you don't possess the skills or aren't willing to learn the ways of the trade. Look at aviation for example: pilots and ATC talk in jargon, acronyms, and abbreviations like it's a completely different dialect of English, anyone who complains that they can't understand would be laughed at and told to keep learning, and that's the way it…

> Look at aviation for example: pilots and ATC talk in jargon, acronyms, and abbreviations like it's a completely different dialect of English, anyone who complains that they can't understand would be laughed at and told to keep learning, and that's the way it should be. Yes, but the jargon and language used is standardized; pilots don't get to put their own twist on e.g. formal communication with the tower when they…

Yes, but the jargon and language used is standardized

...so is the ternary operator.

Re: Clear is better than clever [pdf]

#315

Post by [deleted] »

Cthulhu_ wrote: post #292
networkimprov wrote: post #204

Earlier quoted context omitted.

What we should be able to write in Go, but can't because the compiler (wrongly) imposes formatting: if a { v = 1 } else if b && c { v = 10 } else if b && !c { v = 100 } else { v = d }

I strongly disagree; creative formatting like this means that as a reader, you have to squint and readjust to this new style to see what is going on. I mean, this whole thread reads like a holy war about code style - something the Go developers EXPLICITLY want to avoid because discussions about code style are a waste of time. Everyone reading the above segment of code will have a different opinion on how to format it…

[deleted]

Re: Clear is better than clever [pdf]

#316

Post by drawkbox »

spectramax wrote: post #188
jacobush wrote: post #64

Earlier quoted context omitted.

Or break them out into a function, then you can "short-circuit" with a return: int logic() { if (cond1) { return 1; } if (cond2) { if (cond3) { return 10; } return 100; } // ... return defaultValue; } Since it's a function, it's also apparent that you are only touching one variable: myVar = logic(); I love the ternary operator, but I find it's harder to step it in a debugger though.

Short circuiting is poor for readability in my view because not only do you have to parse the syntax but you need to mentally walk through each case to understand what’s going on. Traditional if/else conditionals express clarity by embedding the decision for myVar and visually show how it would be assigned in various cases. As @hotBacteria said: if(cond1){ myVar = 1; } else if(cond2 && cond3){ myVar = 10; } else if(c…

Clear conditionals like this (or short circuiting) are very nice when it comes to merging.

One liners and mammoth tertiaries that are too long can lead to conflicts and more problematic merges/diffs/etc.

One operation per line makes repos and merging, as well as blaming, reading and reviewing, easier to parse.

Re: Clear is better than clever [pdf]

#317

Post by LandR »

oblio wrote: post #300
whatshisface wrote: post #115

Earlier quoted context omitted.

A lisper would say that there is absolutely no limit, and that in fact all programs should be structured like that.

And that's why lispers are at most 1% of the total number of programmers out there, 50+ years after the language was invented. You could say that most programmers are crap, but those crap programmers seem to make the world work, so they must be doing something right :-)

> You could say that most programmers are crap

Because they are

> but those crap programmers seem to make the world work

For certains value of "work". Most software is crap too and it's getting worse not better.

Re: Clear is better than clever [pdf]

#318

Post by naasking »

kazinator wrote: post #286
naasking wrote: post #259

Earlier quoted context omitted.

> It occludes the nested structure. The nesting is irrelevant to understanding the semantics, so this objection doesn't fly. The idiom is basically just a truth table with conditions on the left and the matching value on the right. You read it left-to-right, top-to-bottom, just like all other code. The first condition on the left that matches returns the value on right-hand side.

> The nesting is irrelevant to understanding the semantics The nesting is absolutely relevant to producing the semantics. The following uses deceptive whitespace to suggest a nesting that is contrary to the actual nesting, interfering with understanding: if (foo) if (bar) xyzzy(); else flop(); The ternary operator A ? B : C is the goofy invention of demented mind. In nested situations, it is mind-bendingly unreadable…

> The following uses deceptive whitespace to suggest a nesting that is contrary to the actual nesting, interfering with understanding

Fortunately, the ternary pattern doesn't exhibit this problem. So again, this objection doesn't fly.

Re: Clear is better than clever [pdf]

#319

Post by oblio »

LandR wrote: post #317
oblio wrote: post #300

Earlier quoted context omitted.

And that's why lispers are at most 1% of the total number of programmers out there, 50+ years after the language was invented. You could say that most programmers are crap, but those crap programmers seem to make the world work, so they must be doing something right :-)

> You could say that most programmers are crap Because they are > but those crap programmers seem to make the world work For certains value of "work". Most software is crap too and it's getting worse not better.

Yet it makes people's live better day by day... I feel that as insiders we don't really realize that software works quite well compared to many every day things.

Re: Clear is better than clever [pdf]

#320

Post by fjsolwmv »

brigandish wrote: post #284
pojzon wrote: post #241

Earlier quoted context omitted.

I think its a poor example. How often you are going to write something like that in RL scenario? In case of more complex data generation you could use supplier pattern and combine it with strategy. No need for any if else statements at all. Sure it requires a lot more of work but is future proof and clear.

I've not heard of the supplier pattern, any chance you would direct me to a resource about it?

A Supplier is when a function needs a value, and instead of providing a value as an argument, you pass in callable:

Foo(int x){return x+1} becomes Foo(Supplier x){return x() + 1}

Post reply on HN