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

191–200 of 335 posts

Re: Clear is better than clever [pdf]

#191

Post by stcredzero »

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…

In Smalltalk, we had return values from ifTrue:ifFalse: statements. This served the function of the ternary ( ? : ) while enabling if-then style brackets. Also, deeply nested logic and methods longer than 10 lines were regarded as "code smells" in the community, so a lot of that logic was implemented through polymorphism.

Anyone who has the experience of reading lots of highly trivial functions like those, and gotten the feeling "I've read a lot of code, and I understand what each little bit does, but what is the whole thing trying to do?" That's a symptom of excessive verbosity.

Smalltalkers sometimes solved this through executable comments. There would be some code, with a message to "debug this," and we could just highlight the code and quickly and easily walk through it in the debugger. This demonstrates one of the advantages and disadvantages of Smalltalk: Everything could be embodied in the interaction of relatively small objects, so everything tended to be modular, more easily. The disadvantage comes from the fact that the interaction has to be understood to understand the system as a whole.

Re: Clear is better than clever [pdf]

#192

Post by sagichmal »

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…

I strongly disagree that your example is better than Dave's. I would much prefer to see Dave's switch statement in a new-to-me codebase than your ternary.

Re: Clear is better than clever [pdf]

#193

Post by markrages »

maxxxxx wrote: post #58
illys wrote: post #39

Earlier quoted context omitted.

Fully agree! Combinations of if/else can seriously damage readability and maintainability. I (all the time) face verbose code that pretend to be readable and that requires lots of attention just to find out you are setting a single variable across 10-20 lines. Example: if (cond1) { myVar = 1; } else if (cond2) { if (cond3) { myVar = 10; } else { myVar = 100; } ... } else { myVar = defaultValue; } * huge number of lin…

I actually prefer the long version. But I think the real trick is to be consistent in style. Parsing ternary operators is a learned skill and so is parsing long if statements. You can get used to both.

Programmers have to learn to read different styles, to read code from other projects. So use the construction that is clearest in its local context.

Style is a matter of taste, just like writing English: there are synonyms and idioms for every idea that you want to express, so use that freedom to choose the clearest communication. Like English, programming code is meant to communicate to other humans, so don't artificially limit your vocabulary in the name of consistency.

Consistency is a hobgoblin.

Re: Clear is better than clever [pdf]

#194

Post by syn_rst »

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…

Depending on what syntax constructs are available, it's possible to achieve clarity without the verbosity or "line noise factor." For example, in Rust you could write that same code as:

  match a.cmp(&b) {
      Ordering::Equal => 0,
      Ordering::Greater => 1,
      Ordering::Less => -1
  }
It's easy to see what the possible outputs are and what is produced in each case. The compiler even checks it to make sure you didn't forget any situations.

The clarity comes at the cost of some verbosity, but there's only 4 lines of functional code (not counting the closing brace) here compared to the article's 10. You'd get around the same number if you added line breaks to make the ternary example more readable.

Re: Clear is better than clever [pdf]

#195

Post by maxxxxx »

markrages wrote: post #193
maxxxxx wrote: post #58

Earlier quoted context omitted.

I actually prefer the long version. But I think the real trick is to be consistent in style. Parsing ternary operators is a learned skill and so is parsing long if statements. You can get used to both.

Programmers have to learn to read different styles, to read code from other projects. So use the construction that is clearest in its local context. Style is a matter of taste, just like writing English: there are synonyms and idioms for every idea that you want to express, so use that freedom to choose the clearest communication. Like English, programming code is meant to communicate to other humans, so don't artifi…

I don’t think consistency is a hobgoblin (I hope I understand the meaning correctly). When you are new to a project you should follow the style of what’s already there and not do something completely different. Obviously there may be good reason but that should be discussed and you also should ask yourself if you are just not willing to adapt or if you are actually making things better.

Re: Clear is better than clever [pdf]

#196

Post by Verdex »

revvx wrote: post #190
Verdex wrote: post #163

I'm fairly sure that we as a community can come up with an objective measure for the phrase "clever code". Something like: Exploits implicit and/or hidden details to correctly function. However, I've never seen a convincing and objective description of clear code. Sometimes people mean that clear code is verbose code. Sometimes people mean that clear code is uniformly formatted code. [For best results we should manua…

All IMO: > However, I've never seen a convincing and objective description of clear code. I take "clever code" to mean "code that looks pretty on surface the but requires the reader to dig in in order to understand the intent". The problem with clever code is that it is misleading. It lacks empathy. You assume the next programmer will understand it at first glance just because it looks cool or pretty, but they'll str…

> When you break a method in three or four without adding REAL abstractions (a.k.a. "things you don't have to follow with the debugger to understand"), you're not making it easier to read, in fact you're making it harder because the reader has to jump around your code.

Yeah, there's competing forces involved. If you push too many things together that do not belong together, then you end up with code that is hard to comprehend. Additionally, if you spread too many things apart that should otherwise be together, then you end up with code that is hard to comprehend (your point). Finally, what things belong together and what things ought to be separated will depend on the domain and even the specific constraints within the domain.

In order to objectively determine when things have gone poorly you have to factor in a lot of external details.

For example, manual memory management is a detail that should almost always be someplace else because it isn't relevant to solving the problem at hand. So we did this with garbage collectors. However, sometimes we need this detail present (high performance computing and/or constrained hardware ie video games etc).

Re: Clear is better than clever [pdf]

#197

Post by michaelcampbell »

pier25 wrote: post #167
jimbokun wrote: post #162

Earlier quoted context omitted.

"Personally, I find that ternary example you posted to be terrible code." It's not about the line count, it's about expressing the main idea clearly and succinctly, which this code does. My nitpick would be with the language constructs themselves. The ternary operator is simply a crutch for lack of an if-then expression returning a value. if a b then 1 else 0 Or can add some white space to make the structure a little…

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

Re: Clear is better than clever [pdf]

#198

Post by elcritch »

tabtab wrote: post #189
hotBacteria wrote: post #65

Earlier quoted context omitted.

You can write it without resorting to one-line conditionals: if(cond1){ myVar = 1; } else if(cond2 && cond3){ myVar = 10; } else if(cond2 && !cond3){ myVar = 100; } else { myVar = 4; } But when I encounter this kind of situations I have other problems than code formatting anyway: with 3 conditions you have 2^3 possibilities to check: are you really really sure (!cond1 && !cond2 && cond3) should give you defaultValue…

That makes code formatting inconsistent because many prefer the other way. The VB.Net style is more compact and readable in my opinion: if cond1 then myVar = 1 else if cond2 and cond3 then myVar = 10 else if cond2 and not cond3 then myVar = 100 else myVar = 4 end if The VB.Net style also makes it easier to identify mismatched blocks because the "enders" are named differently. (One can also put the assignment on the s…

IMHO, better but it’s still confusing when you have multiple places where you name the variable. Functional programming style forces you to be more explicit and pushes you to separate out the assignment expression. In Elixir I’d do:

    myVar = 
      cond do
       cond1 -> 1
       cond2 && cond3 -> 10
       cond2 && !cond3 -> 100
       true -> 4
      end
ML languages have similar constructs.

Re: Clear is better than clever [pdf]

#199

Post by Consultant32452 »

olah_1 wrote: post #121
Consultant32452 wrote: post #110

Earlier quoted context omitted.

I'm not disagreeing with you, and maybe this is just my personal experience, but there seems to be a movement that promotes succinctness over all other qualifications. It's as if someone's comp-sci class had a competition for who could accomplish some task with the fewest bytes of code and a whole generation of programmers never got out of that mode. I've heard comedians talk about a set not having any fat in it... e…

On the contrary, I think the zeitgeist for the last 5-10ish years has been the opposite. "Verbose and explicit > Succinct and implicit". I think python and golang are largely responsible for this kind of movement in recent years. Because of that, I find languages like Perl 6 to be a breath of fresh air.

That's interesting. I wonder if that's influenced by the languages we use, as they might have different cultures. I primarily work in Java, which is famously verbose.

Re: Clear is better than clever [pdf]

#200

Post by [deleted] »

alexgmcm wrote: post #34
__s wrote: post #23

Earlier quoted context omitted.

Meanwhile I'll write (a>b)-(a<b), which is what Python suggests after having removed cmp

I mainly use Python but that would still be unclear to me. I think the ternary operator is the sweet spot between too verbose and too confusing.

[deleted]
Post reply on HN