John,
+1 to coding conventions for Woden. This will help make the code base readable. However, I think the only way to support this is with the assistance of tools such as Eclipse.
>1. Opening brace "{" at end of the line, not the start of the next
I'm a fan of on a new line but can live with your proposal.
>2. indent with space (not tab)
OK.
>3. each level of indent = 4 spaces
OK.
>4. do not auto-reformat comments
May be a good idea but I think the line length of comments should be set as well.
>Should detailed comments in the implementation (i.e. non-API) be ordinary comments or Javadoc?
I'd prefer to see them as JavaDoc. This will provide consistent comments and gives flexibility to create JavaDoc for our implementation and promote classes to API as needed without re-formatting all the comments.
>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?
I don't have a preference here.
There are many other coding conventions that we can put in place. (Take a look at the Eclipse Java coding convention preference page for a project. There are dozens of options.) Do you think this is enough? Does the convention need to strictly define everything or are we OK with a few conventions and differences in other places? (Given that the driving reason behind creating these conventions is to prevent the formatting problem with SVN.)
Lawrence
| John Kaputin <[EMAIL PROTECTED]>
06/13/2006 10:55 AM
|
|
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]
