Arthur,
I think the general idea is to avoid making large formatting changes when fixing bugs.
How about the reverse?
1. make real change
2. commit the change
3. autoformat code
4. commit the change
Autoformatting code should be real quick so you shouldn't need much time between 2 and 4.
Lawrence
| Arthur Ryman/Toronto/[EMAIL PROTECTED]
06/14/2006 05:07 PM
|
|
Jeremy,
What's the process then?
1. autoformat code
2. commit the change
3. make real change
4. commit the change
This might cause merge conflicts unless you can make the change (#4) really quick.
Arthur Ryman,
IBM Software Group, Rational Division
blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: [EMAIL PROTECTED]
| "Jeremy Hughes"
<[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 06/14/2006 04:56 PM
|
|
If an autoformat is done then that should be the only change in the revision - and marked up as such in the svn comment. That way we can see what the real changes (first revision) then what the autoformat changes are (second revision).
I vote +1 for autoformat changes must be isolated so that they are the only change in a revision.
Cheers,
Jeremy
On 6/14/06, Arthur Ryman <[EMAIL PROTECTED]> wrote:
John,
I am in favour of autoformatting since is makes the code more readable. However, we need to do this in a more stable way, and when we do so, we need project-wide standards.
The proposed guidelines look fine.
Arthur Ryman,
IBM Software Group, Rational Division
blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: [EMAIL PROTECTED]
| 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]
