To a certain degree. I'd say it like this:
Too clear is not clear at all.
Too clever is not clever anymore.
Clear is better than clever [pdf]
31–40 of 335 posts
Re: Clear is better than clever [pdf]
#32It'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…
Meanwhile I'll write (a>b)-(a<b), which is what Python suggests after having removed cmp
That works nicely too, for those languages with "1-0" booleans. For languages without them (Java, C# come to mind), the ternary is the next-best way.
Re: Clear is better than clever [pdf]
#33Sometimes clever means succinct. And maintaining less lines of code can also lead to less bugs.
Re: Clear is better than clever [pdf]
#34It'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…
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.
Re: Clear is better than clever [pdf]
#35It'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…
The multi-line comparators are definitely clearer and more readable to me.
The 10(!) lines of code you referenced are actually only 8(!) lines compared to your 1(!) line because you included the function declaration and the final brace in your count. The line you proposed is 34(!!) characters wide. I wonder if your statement will continue to grow past 80(!!!) characters as your operand expressions grow in width? Will you transform it back to multi-line when that happens?
However, I'm not sure why we're exclaiming line counts at all and now, apparently, character counts.
Agreed on the semi-colons though.
Re: Clear is better than clever [pdf]
#36It'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 find your example to be on the clever spectrum.
If anything, it should remind you that clarity depends on the context.
Re: Clear is better than clever [pdf]
#37It'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…
[deleted]
Re: Clear is better than clever [pdf]
#38Sometimes clever means succinct. And maintaining less lines of code can also lead to less bugs.
Sometimes. But only sometimes. A clever one liner that is easy to misunderstand when reading it while trying to find a production issue with eyes on you is NOT fun at all. And it isn't worth the two lines it saved.
Less code does not mean less bugs.
Re: Clear is better than clever [pdf]
#39It'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…
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;
}
* not obvious (until we read all) that we setup a single variable
* combination of conditions difficult to trace for each given value
* high risk of forgetting cases...
Instead of
myVar =
(cond1) ? 1 : // comment case blabla
(cond2) && (cond3) ? 10 : // comment case bla
(cond2) && (!cond3) ? 100 : // comment case blablabla
...
defaultValue; // comment default
* operation on a single variable obvious
* match between conditions and values obvious
* high visibility on all the cases
* even more readable with proper vertical alignment
* a comment can be added on each line to document the case
[sorry for the multiple edits: I had a hard time getting { } properly display, they ate up the new lines]
Re: Clear is better than clever [pdf]
#40Earlier quoted context omitted.
Working on personal projects, not having to conform to other people’s requirements, trying a bunch of cool hacks and getting to see how things really work…that’s the most fun part of programming!
Oddly enough I find the collaboration more interesting now. Not sure if that’s a getting older thing but I like managing the PR’s, ensuring code is of a high quality and serving the needs of the users.
I do both, and they have their own unique rewards. Writing personal projects is an exercise in self-improvement–it really doesn't matter all that much how your project turns out–while working on projects with others means you need to care about how other people and your project is improving. But in return you get to interact with people, show off your skills, receive and provide help…all useful skills in their own right.