English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
Re: [Caml-list] indent 2
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2001-07-23 (00:27)
From: Brian Rogoff <bpr@b...>
Subject: Re: [Caml-list] indent 2
On Sun, 22 Jul 2001, Pierre Weis wrote:
> > On Sat, 21 Jul 2001, Alexander V. Voinov wrote:
> > > Oh, if it were that simple. The pressure of the society may be much
> > > stronger than the pressure of an external authority, which contrasts
> > > itself to the society. Because the former penetrates deeper into one's
> > > mentality. (Sorry for offtopic)
> > 
> > That's too deep for me, I'm just an American. 
> I can't resist to cite this slogan that I learnt long time ago from
> the chinese communists (I really do not remember if it were about Caml
> programming guidelines or not):

>  Always follow the party's line,
>  but don't be afraid to swim against the main stream.

Is four spaces not following the party's line, or is it just swimmming
against the main stream? 

> [...]
> > It seems that the Caml community mostly indents by two spaces, so if 
> > you'd like to be a good neighbor you should do so as well. No one will 
> > shun you if you refuse and use four spaces, and your code will still 
> > be readable. Well, OK, I'll shun you, but probably noone else :-).
> I will shun you also, but probably nobody else.

Hey, we may be onto something with this shunning thing...

> Oh yes, now I remember,
> for indentation the chinese slogan was:
>  Consistenly use one or two extra spaces when indenting,
>  but fill free to indent as you like it.
> (Sorry for not being so serious about that (in fact) important subject.)
> More seriously: Caml is a language of expressions (not blocks of
> instructions), and expressions tend to nest rather deeply. Hence it is
> not uncommon to have indentation level growing up to 5 in a regular
> program (in some bad cases it could go up to 10). 

I've never had 10, but definitely nesting 4 or 5 deep is common and ugly
with four space indenting IMO. 

> Personnaly, I use one
> space with some exceptions for 2 spaces indentation (which is
> inconsistent, I know it!) 

Well, you know what Emerson said about foolish consistencies. Then again, 
I do have a little mind!

> > PS: It would be useful to have the programming guidelines extended to
> >     cover programming with classes and modules. 
> I added some paragraph on modules. May be you can tell me what topics
> I have to add or extend about modules ? 

A little extra section on programming with functors and the interaction
with the file system would be helpful. I've read the manual and the 
libraries, and there is not really a consistency of style there. For
instance module types in the manual are UPPER_CASE, but MixedCaseWithSuffix 
in the libraries. In another document the style used "Sig" as a suffix to 
MixedCaseSuffix as opposed to Type in the libraries. Is there a preferred
style yet? I've been playing with some heavily functorized libraries
ported over from SML and since I'd like to make them Caml style I'd like
examples of the desired naming styles. 
There was also some discussion on the duplication of module information in 
the .mli and .ml files on the list which is a fine addition to either the
FAQ or style guide. 

I'm not sure why you don't mention local modules in the section on opening
modules since I think that in many cases a local open is better than a 
file/top-level-unit wide open. Is using let module this way questionable 

> For classes, I'm a bit more puzzled and I need help from people that
> use classes more than I do, and that already know what are the problems
> to avoid and the styles to recommend.

I'm still accumulating experience here. I only use classes in a few

-- Brian

Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr