Colin Adams writes:
>> Named values are just like comments, which IMO also should be kept to a
>> bare minimum. A bit tongue in cheek: If you need a name to understand
>> what a function does, or a comment to understand how it does it, then
>> your code is too complicated.
> Tongue-in-cheek? It's completely ridiculous.
I'm not saying that you shouldn't name things - just that you shouldn't
add names as a remedy for incomprehensible code. Especially when
you can instead write clear code in the first place.
E.g. I don't need a name for "\n -> n `mod` 2 == 1" to understand what
it does.
And especially in this case, naming otherwise clear code fragments just
introduces a layer of indirection, which add more opportunities for
errors and misunderstandings.
> That example above has six names in it.
And they are named because they represent common idioms that are used
all over the place, and so labeling and memorizing them improves clarity
and reusability, and since they are from the standard library, I can
expect them to be reasonably correct and efficient.
Here's another one for you: never introduce names if it increases the
size of your program. (Corrolary: don't name things that aren't
referred to at least twice)
-k
--
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
