[Haskell-cafe] Re: Naming and coding style (was: First time haskell - parse error!)

On Wed, 2010-03-10 at 13:03 +0100, Ketil Malde wrote:

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.

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