In some recent code commits all or most of the file has been changed due to
auto-reformatting using different settings from the original code (e.g.
tabs versus spaces for indenting or reformatting of comments). This makes
it hard to diff the files to see functional changes.
To avoid this problem we need consensus either to not use auto-reformatting
or to adopt common coding conventions so that those using IDEs with
auto-reformatting don't make unnecessary changes to existing files (and
any new code should also conform to these conventions). We can document
these conventions on the website or wiki.
Please vote on whether we should use auto-reformatting with these coding
conventions (or offer other suggestions):
1. Opening brace "{" at end of the line, not the start of the next
2. indent with space (not tab)
3. each level of indent = 4 spaces
4. do not auto-reformat comments
Questions:
Should detailed comments in the implementation (i.e. non-API) be ordinary
comments or Javadoc? Probably, depends on whether we want to produce
Javadoc just for the API or for the implementation too. So far I have used
(or intend to use) Javadoc comments for API classes and methods, but only
Javadoc class comments for internal packages (i.e. with ordinary Java
comments for the methods).
Line length. Should this be restricted by auto-reformatting and to what
length. 80 char seems unnecessarily short to me for the types of GUIs
commonly used, but I'll go with the consensus. How about 100?
regards,
John Kaputin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
