headers
Ian Lynagh | 1 Aug 2007 16:19
Picon
Gravatar

Good Haskell Style


Hi all,

I've been sitting on this for four months for various reasons, but Neil
and Duncan keep prodding me to send it, so here it is.

The numbers in the mail are probably out of date by now, due to the
start of the base splitup and general development, but I'm too lazy to
update them.

Thanks
Ian

------------------

Hi all,

My last attempt to write a contentious mail was a miserable failure, so
I'm giving it another go.

I've written up my description and rationale for what makes good Haskell
style. The full thing is at
    http://urchin.earth.li/~ian/style/haskell.html
but I'll copy the conclusion here:

* Don't leave trailing white space in your code
* Don't use tabs
* Aim to keep lines under 80 characters
* Use the CamelCase variable naming convention
* Don't use explicit braces and semicolons
(Continue reading)

Permalink | Reply | 49 comments |
headers
Duncan Coutts | 1 Aug 2007 16:50
Picon
Picon
Favicon

Re: Good Haskell Style

On Wed, 2007-08-01 at 15:19 +0100, Ian Lynagh wrote:
> Hi all,
> 
> I've been sitting on this for four months for various reasons, but Neil
> and Duncan keep prodding me to send it, so here it is.

And if we can get vague consensus we should put this guide on the
haskell.org wiki.

Duncan
Permalink | Reply | 0 comments |
headers
Simon Marlow | 1 Aug 2007 16:50
Picon

Re: Good Haskell Style

Ian Lynagh wrote:

> * Don't leave trailing white space in your code
> * Don't use tabs
> * Aim to keep lines under 80 characters
> * Use the CamelCase variable naming convention
> * Don't use explicit braces and semicolons

I'm with you all except for the 4th one:

 > * Use the CamelCase variable naming convention

I'm rather attached to the convention I use, which is

   - CamelCase for exported identifiers
   - underscores otherwise

(I'm pretty sure I don't use it consistently, so don't bother to dig up 
counter-examples though).

Why do I like this?  Ideally we'd have an IDE which would colour my 
exported identifiers differently, but since I don't use such an IDE the 
CamelCase distinction gets some of the benefit.  CamelCase for exported 
identifiers is already an established convention (which should really be 
part of a library API style guide), which leaves us with underscores for 
local identifiers.

Yes I'm aware that a single-word identifier is the same in both 
conventions; it's not perfect.
(Continue reading)

Permalink | Reply | 7 comments |
headers
Philippa Cowderoy | 1 Aug 2007 16:56

Re: Good Haskell Style

On Wed, 1 Aug 2007, Simon Marlow wrote:

> I'm rather attached to the convention I use, which is
> 
>   - CamelCase for exported identifiers
>   - underscores otherwise
<snip>
> Yes I'm aware that a single-word identifier is the same in both conventions;
> it's not perfect.
> 

How about _nonexportedIdentifier or something similar?

--

-- 
flippa <at> flippac.org

A problem that's all in your head is still a problem.
Brain damage is but one form of mind damage.
Permalink | Reply | 2 comments |
headers
Chris Kuklewicz | 1 Aug 2007 17:30

Re: Good Haskell Style

Philippa Cowderoy wrote:
> On Wed, 1 Aug 2007, Simon Marlow wrote:
> 
>> I'm rather attached to the convention I use, which is
>>
>>   - CamelCase for exported identifiers
>>   - underscores otherwise
> <snip>
>> Yes I'm aware that a single-word identifier is the same in both conventions;
>> it's not perfect.
>>
> 
> How about _nonexportedIdentifier or something similar?
> 

Leading underscores are used in pattern matches to indicate to GHC that unused
names like '_foo' should not cause a warning to be printed.  Otherwise the
warning is turned off by using just '_'  but that erases the readability of
using an actual name.

Thus:

take _  [] = []  -- no warning
take n  [] = []  -- warning that n is unused
take _n [] = []  -- no warning
Permalink | Reply | 1 comment |
headers
Seth Kurtzberg | 1 Aug 2007 17:33

RE: Good Haskell Style

I've been using Haskell daily for a long time, and I didn't know about that
underscore convention.  I knew about _ being an unspecified dummy variable,
but I didn't know you are allowed to follow it with a meaningful name.

Guess I have some reading to do.  :)

-----Original Message-----
From: libraries-bounces <at> haskell.org [mailto:libraries-bounces <at> haskell.org]
On Behalf Of Chris Kuklewicz
Sent: Wednesday, August 01, 2007 11:31 AM
To: Philippa Cowderoy
Cc: libraries <at> haskell.org; Simon Marlow
Subject: Re: Good Haskell Style

Philippa Cowderoy wrote:
> On Wed, 1 Aug 2007, Simon Marlow wrote:
> 
>> I'm rather attached to the convention I use, which is
>>
>>   - CamelCase for exported identifiers
>>   - underscores otherwise
> <snip>
>> Yes I'm aware that a single-word identifier is the same in both
conventions;
>> it's not perfect.
>>
> 
> How about _nonexportedIdentifier or something similar?
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christian Maeder | 1 Aug 2007 18:07
Picon
Favicon

Re: Good Haskell Style

Ian Lynagh wrote:
> 
> * Don't leave trailing white space in your code
> * Don't use tabs
> * Aim to keep lines under 80 characters
> * Use the CamelCase variable naming convention
> * Don't use explicit braces and semicolons

May I add:

* put a final newline in your file

http://haskell.org/haskellwiki/Programming_guidelines#File_Format

Cheers Christian
Permalink | Reply | 0 comments |
headers
Thomas Schilling | 1 Aug 2007 18:28
Gravatar

Re: Good Haskell Style


On 1 aug 2007, at 16.50, Simon Marlow wrote:
> > * Use the CamelCase variable naming convention
>
> I'm rather attached to the convention I use, which is
>
>   - CamelCase for exported identifiers
>   - underscores otherwise
>
> (I'm pretty sure I don't use it consistently, so don't bother to  
> dig up counter-examples though).
>
> Why do I like this?  Ideally we'd have an IDE which would colour my  
> exported identifiers differently, but since I don't use such an IDE  
> the CamelCase distinction gets some of the benefit.  CamelCase for  
> exported identifiers is already an established convention (which  
> should really be part of a library API style guide), which leaves  
> us with underscores for local identifiers.
>
> Yes I'm aware that a single-word identifier is the same in both  
> conventions; it's not perfect.

I don't like that convention.  It makes the code look really ugly.  I  
agree, that it'd be a good idea to have a visual indication what is  
exported and what is not, but i'd strongly opt for something less  
obtrusive.  In any case, though, this is something this should be  
done consistently or not at all; maybe we need some sort of haskell- 
lint?

So, if leading underscores are used already, what about trailing
(Continue reading)

Permalink | Reply | 1 comment |
headers
Philippa Cowderoy | 1 Aug 2007 18:32

Re: Good Haskell Style

On Wed, 1 Aug 2007, Thomas Schilling wrote:

> So, if leading underscores are used already, what about trailing underscores?
> 

I often use them where someone else would use ' as prime because my text 
editor's syntax highlighting is less than perfect. Also, there's an 
existing convention in the monad libraries using trailing underscores.

--

-- 
flippa <at> flippac.org

"The reason for this is simple yet profound. Equations of the form
x = x are completely useless. All interesting equations are of the
form x = y." -- John C. Baez
Permalink | Reply | 0 comments |
headers
Malcolm Wallace | 1 Aug 2007 19:59
Picon

Re: Good Haskell Style

> * Don't leave trailing white space in your code
> * Don't use tabs
> * Aim to keep lines under 80 characters
> * Use the CamelCase variable naming convention
> * Don't use explicit braces and semicolons

These rules seem reasonable to me, but I would finesse the second point.
Whilst tabs are undesirable in code, I do often find it useful to
precede _eol_ comments with tabs.

    "function | guard = body\t\t-- eol comment"

Tabs help to align the beginning of such comments nicely; they help to
avoid random misalignments due to minor editing of code; and in this
location they can never change the meaning of the code.

Regards,
    Malcolm
Permalink | Reply | 0 comments |

Gmane