[m-dev.] proposed change to the coding style document

Mark Brown mark at cs.mu.OZ.AU
Mon Mar 21 14:47:42 AEDT 2005

On 21-Mar-2005, Julien Fischer <juliensf at cs.mu.OZ.AU> wrote:
> On Mon, 21 Mar 2005, Zoltan Somogyi wrote:
> > @@ -174,15 +177,14 @@
> >
> >  <p>
> >
> > -Code should be indented consistently.
> > -Tabs should be every 8 spaces.
> > -Indentation should be one tab per level of indentation.
> > -except for highly intended code which may be
> > -indented at 4 spaces per level of indentation.
> > +Each module should be indented consistently,
> > +with either 4 or 8 spaces per level of indentation.
> > +The indentation should be consistently done,
> > +either only with tabs or only with spaces.
> >
> You may want to give an example of the vim modeline string
> we generally use here.

Or, indeed, require a vim modeline string, at least in the case of 4 space
indentation using tabs.

> > -<h2> Standard Library Predicates </h2>
> > +<h2> Module imports </h2>
> > +
> > +Each group of :- import_module items should list only one module per line,
> > +since this makes it much easier to read diffs
> > +that change the set of imported modules.
> > +In the compiler, when e.g. an interface section imports modules
> > +from both the compiler and the standard library,
> > +there should be two groups of imports,
> > +the imports from the compiler first and then the ones from the library.
> I think it would be a good idea to suggest that compiler imports should
> be grouped by package, something like:

I agree, although this is (almost) implied by the requirement that they be
sorted.  The standard should state that a blank line is required between
the compiler imports and the library imports, and also between imports
from different packages if this is in fact the intent.


mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au

More information about the developers mailing list