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 < [email protected]>: > 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 > >
