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

[Maciej Piechotka]

On Wed, 2010-03-10 at 13:03 +0100, Ketil Malde wrote:
> Colin Adams <colinpauladams at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20100310/70a711f2/attachment.bin