On Wed, 2010-03-10 at 13:03 +0100, Ketil Malde wrote: > Colin Adams <colinpaulad...@googlemail.com> 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. >
Hmm - good for you if you understand. I had to read and think (ok.
something like 0.03s but it appeared non-obvious - it seem strange but n
`mod` k == 0 where k is constant would be obvious).
If you write
some very complicate expression . filter odd . other expression
It is IMHO much clearer then:
some very complicate expression .
filter (\n -> n `mod` 2 == 1) . other expression
> > 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
Well - my rule of thumb (for imperative programs):
"If function is longer then 24 lines then it should be splitted into
sub-functions [even if they are called only once]".
Due to much more expressiveness and density of functional code the
boundary is much lower.
It is good to do because:
- I can test function separately. I mane that if I have
// Lots of code in function
while (...) {
...
// Here it prints the wrong value
...
}
// Lots of code
I don't have idea if the problem is in loop or outside. If the loop is
in smaller function I can test it separately.
- it provides separation of possible different functions. Like:
void main() {
init();
while (Event *e = poolEvent ()) {
processEvent (e);
}
cleanup();
}
Now imagine that init have 15 lines, cleanup 10, poolEvent 10 and
processEvent 30. We have 65-line mess which is unmaintainable ;) Ok -
this is extrem example but still .
- It clarifies the levels of abstraction. If I'm reading the code of
server message processing I might just be interested in the general
processing (it gets message, filter through antivirus etc.).
The actual code of I/O, filtering would make it less clear even if they
are called once and increase size of program.
Regards
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
