5 ms·
Code is meant to be read and incidentally to be executed. Code also should be read more often than it's written. With allegedly idiomatic Go: b := 0 f
by elgenie 9y ago
Code is meant to be read and incidentally to be executed. Code also should be read more often than it's written.
With allegedly idiomatic Go:
b := 0
for _, r := range results {
j, k := r[0], r[1]
if !k || j % 2 != 0 {
continue
}
b += j
}
... there are eight lines to read and then the reader is forced to draw
the conclusion of what the code does at a higher level:
// I see ... given an iterable of results pairs, we just sum the
// first elements that are even for the pairs in which
// the second element is truthy!
With Python, you can write the exact same code that asks for the same mental
gymnastics.
Python:
b = 0
for j, k in results:
if (not k) or (j % 2 != 0):
continue
b += j
# I see ... given an iterable of results pairs, we just sum the
# first elements that are even for the pairs in which
# the second element is truthy!
But it also allows for a more direct expression of intent by using a
higher level construct:
b = sum( ( j for (j, k) # ... sum the first elements
in results # ... of results pairs
if (k and j % 2 == 0) # ... if first elt is even and second elt is truthy
) )
The argument seems to be that "when reading and modifying code, certain lines may contain constructs that will require more attention to be paid to a line" is a very serious problem, the solution for which is to enforce that all lines are equal in that they do relatively little at the language level, which Blub (err.. Go) does.
It's further argued that lowest-level-constructs-available scaffolding that may occasionally need to be added in the moment while tinkering is worth keeping around forever despite any tax it imposes on the creation, the reading, and the ease of modification of the codebase and a great advantage of Blub (err... Go) is that it forces this to happen by only having such constructs in the first place.
- mcbits 9y agoAs a non-Go/Python user, those two snippets look practically identical to me, although I understand just enough to have written the same comments. Unfortunately, the comments don't tell me what I'd really like to know about the code if I ran across it when debugging: * What are b, j, and k? * What's so significant about even numbers - or is 2 a magic number that could just as easily have been 3? * What can I assume about results? Can it be empty, null, 10 elements, 10 million elements? With proper naming and a good, brief chunk-level comment, I could tell at a glance whether this chunk is likely to be hosting my bug or not. 5 lines vs. 8 lines don't play much into it. Actually, this really isn't what I think of when I hear "boilerplate". I think of, for example, the adapter pattern, or having to build up a finicky set of states every time some common task is done.
- elgenie 9y agoThe first python snippet was meant to be identical to the Go one and the Go one is the one from the article. > With Python, you can write the exact same code that asks for the same mental gymnastics. The second Python snippet would idiomatically be written on one line and that's what the article is railing against for unclear reasons. The comments would not appear in source code, they're supposed to illustrate the thought process of the reader as they encounter the source code.