<br><br><div class="gmail_quote">2009/3/13 Heinrich Apfelmus <span dir="ltr"><<a href="mailto:apfelmus@quantentunnel.de">apfelmus@quantentunnel.de</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Francesco Bochicchio wrote:<br>
<div class="im">> Heinrich Apfelmus wrote:<br>
>><br>
>> Stylistically, one usually uses shorter variable names in Haskell.<br>
><br>
> <beginner rant><br> ...<br>
> </beginner rant><br>
><br>
> Rant apart, I notice that in my own excercises I tend to shorten names, so<br>
> maybe there is a reason for that.<br>
> Nevertheless readability tends to be a big issue in languages used in IT<br>
> industry, and my feeling is that haskell<br>
> tends to err on the laconic side of the balance.<br>
<br>
</div>The goal is of course to make code readable, that's why I recommend<br>
short names. :D<br>
<br>
Abstraction is the one driving force for very short names. For example,<br>
take the definition of foldr<br>
<br>
foldr f z [] = z<br>
foldr f z (x:xs) = f x (foldr f z xs)<br>
<br>
Since this function is polymorphic, so f , z and the xs can be<br>
anything, using more "descriptive" variable names is simply not<br>
possible; the key point of fold is its generality.</blockquote><div><br></div><div><br></div><div>Ok but one could still hint at their structure or purpose:</div><div><br></div><div>foldr function value (x:xs) = function x ( foldr function value xs )</div>
<div><br></div><div>I believe this would give a little more information to the casual reader.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
<br>
<br>
A second, and my main reason for short names, or rather against long<br>
names, is that names should be to the point. None of the names<br>
<br>
newPrimes<br>
topPrime<br>
doFactors<br>
doFilter<br>
<br>
accurately describe the object they represent. The primes are not "new",<br>
the prime is not "on top". The "do" is a prefix does not carry a meaning<br>
either, it just conveys that doFactors has something to do with<br>
factors . This is best expressed by making doFactors a local<br>
definition in the where-block of factors .</blockquote><div><br></div><div>I agree that well-documented shared name conventions are better than roll-your-own.</div><div> (x:xs) is one example of such convention, although I tend to adopt slight variations</div>
<div>like (n:nums) for list of numbers and (ch:chars) for list of characters.</div><div><br></div><div>But roll-your-own is still better than cryptic. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
<br>
The name eratosthenesFilter is ok, but since there is no other<br>
eratosthenes around, no meaning is lost by shortening it to simply<br>
eratosthenes . Not to mention that the conventional term is "sieve", not<br>
"filter". The documentation has to elaborate on it anyway.<br>
<br>
The generality of the name num hints that a single letter name is<br>
preferable.<br>
<br>
The names that I think are great because they are to the point are<br>
<br>
factors<br>
primes<br>
<div class="im"><br></div></blockquote><div>I have some resistance to use nouns for functions. In the imperative world, nouns are for</div><div>variables, verbs are for functions. I know that in pure functional programming there is not such a thing </div>
<div>as variables, but still I would reserve nouns for function parameters and bound expressions. Hence if I have a function that</div><div>find factors, I would call it findFactors rather than just factors.</div><div><br>
</div><div>One such example of misnaming - from a beginner point of view - is the length function in prelude: if it was called</div><div>count, I believe more beginners would have realized that works by actually counting the elements of</div>
<div>a list and not by accessing to some already available 'property' of the list.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
<br>
<br>
> Out of curiosity, there is any reason why you called the auxiliary function<br>
> 'go' ?<br>
<br>
</div>Convention. Often, an auxiliary function that does basically the same<br>
thing as the main function factors but with an extra parameter will be<br>
named factors' . The apostrophe has the drawback that it's easy to<br>
forget, so some people now name such auxiliary functions go instead.<br>
<div><div></div><div class="h5"><br></div></div></blockquote><div><br></div><div>I tend to use _ instead of '. Is more visible and keep conveying the idea that the auxiliary function</div><div>is just a slight variation of the main one.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div class="h5">
<br>
<br>
Regards,<br>
apfelmus<br></div></div></blockquote><div><br></div><div><br></div><div>Ciao</div><div>------</div><div>FB</div><div> </div></div>