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

[Julien Fischer]

On Mon, 21 Mar 2005, Zoltan Somogyi wrote:

> This mostly codifies what we do now, except for the one about
> :- import_module of library files. Any comments?
>

The library imports should be changed at some stage so that
they are one per line; I'll volunteer to do this if nobody
else wants to.

...

> @@ -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.

>  <p>
>
> -Each line should not extend beyond 79 characters.
> +No line should extend beyond 79 characters.
>  The reason we don't allow 80 character lines is that
>  these lines wrap around in diffs,
>  since diff adds an extra character at the start of each line.
> @@ -250,7 +252,7 @@
>
...


>  (see above).
>
> -<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:


	:- import_module parse_tree.prog_data.
	:- import_module parse_tree.prog_out.
	:- import_module parse_tree.prog_type.

	:- import_module ml_backend.mlds.
	:- import_module ml_backend.mlds_to_java.
	:- import_module ml_backend.mlds_to_c.

	<and then the library modules>


> +For the purposes of this rule,
> +consider the modules of mdbcomp to belong to the compiler.
> +Each group of import_modules should be sorted,
> +since this makes it easier to detect duplicate imports
> +and missing imports.
> +

Other than that, I agree with the additions.

Julien.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------