Coding convention

[Martin Desruisseaux <ma...@geomatys.fr>]

Hello all

This may be small details, but can we agree on Java coding convention?
We really have this requirement from industrial users who perform
quality analysis on our code: they ask us to have uniform rules. They
are not telling us which rule to use, but they are telling us "please
agree on some rules and applied them uniformly".

My proposal is to enforce widely-accepted Java convention rules. I'm not
proposing here anything "personal" or unusual, only the recommendations
or usages that anyone can find in Oracle documentation, tools, various
books and tutorial:

  * Indentation is 4 spaces (some Shapefile code has 3 spaces).
  * Standard keyword orders: "public static", not "static public".
  * There is a space after keywords ("if", "for", "while", "catch", etc.)
  * Curly bracket { } in "if", "else", "for", etc. blocks are mandatory
    except when the statement is on a single line (e.g. "else if").
  * Long lines are splitted. We do not have strict line length limit (I
    try to not exceed 120 characters, while sometime I do). But
    Shapefile and some other classes currently have lines up to 338
    characters long that could easily be splitted.
  * No "m_" prefix in member fields.


If peoples agree, I would like to configure a Checkstyle plugin for the
Maven build. I would start with almost no rules enabled, and would
enable some rules progressively only after we agreed on them.

    Martin

Re: Coding convention

[Martin Desruisseaux <ma...@geomatys.fr>]

Hello Marc

I saw that you committed changes for coding convention, thanks a lot for
doing that!

    Martin

Re: Coding convention

[Martin Desruisseaux <ma...@geomatys.fr>]

Le 05/01/15 09:59, Marc LE BIHAN a écrit :
> Ok to remove m_ prefix, but every member variable should prefixed by this.
> :
> this.x = y;
> to avoid confusion.

Thanks. I guess that prefixing with "this." is up to the developer (I'm
not aware of any rule on that). The "this." prefix is probably not
necessary in small methods, and its usefulness probably increase with
the method size. The frontier between "not needed" and "needed" would be
up to developer appreciation.

    Martin

Re: Coding convention

[Marc LE BIHAN <ml...@gmail.com>]

No "m_" prefix in member fields.

I use m_ prefixing because most of the line I see are of this kind :
x = y;

is  x
a local variable,
a member variable,
or a local hiding a member variable ?

Ok to remove m_ prefix, but every member variable should prefixed by this.
:
this.x = y;
to avoid confusion.

Marc.


2015-01-05 9:46 GMT+01:00 Martin Desruisseaux <
martin.desruisseaux@geomatys.fr>:

> Hello all
>
> This may be small details, but can we agree on Java coding convention?
> We really have this requirement from industrial users who perform
> quality analysis on our code: they ask us to have uniform rules. They
> are not telling us which rule to use, but they are telling us "please
> agree on some rules and applied them uniformly".
>
> My proposal is to enforce widely-accepted Java convention rules. I'm not
> proposing here anything "personal" or unusual, only the recommendations
> or usages that anyone can find in Oracle documentation, tools, various
> books and tutorial:
>
>   * Indentation is 4 spaces (some Shapefile code has 3 spaces).
>   * Standard keyword orders: "public static", not "static public".
>   * There is a space after keywords ("if", "for", "while", "catch", etc.)
>   * Curly bracket { } in "if", "else", "for", etc. blocks are mandatory
>     except when the statement is on a single line (e.g. "else if").
>   * Long lines are splitted. We do not have strict line length limit (I
>     try to not exceed 120 characters, while sometime I do). But
>     Shapefile and some other classes currently have lines up to 338
>     characters long that could easily be splitted.
>   * No "m_" prefix in member fields.
>
>
> If peoples agree, I would like to configure a Checkstyle plugin for the
> Maven build. I would start with almost no rules enabled, and would
> enable some rules progressively only after we agreed on them.
>
>     Martin
>
>