Are there Eclipse configuration options necessary to meet any of these
winners?
One step ahead of you. See our podling web site. :)
-Adam
> And the winners are...
>
> Braces: {
> Looks like I'm outvoted on this one.
> }
>
> Indentation: 2 spaces. No tabs!
>
> Member Variables: before methods
>
> Line Length: 100 (Preferred indent after wrapping: 8 spces)
>
> Imports: do not use package imports (e.g. import org.uima.*). order
>
[ http://issues.apache.org/jira/browse/UIMA-47?page=all ]
Adam Lally resolved UIMA-47.
Resolution: Fixed
Website changes committed and extracted to people.apache.org.
> Post code style guidelines on webs
Post code style guidelines on website
-
Key: UIMA-47
URL: http://issues.apache.org/jira/browse/UIMA-47
Project: UIMA
Issue Type: Task
Components: Website
Reporter: Adam Lally
And the winners are...
Braces: {
Looks like I'm outvoted on this one.
}
Indentation: 2 spaces. No tabs!
Member Variables: before methods
Line Length: 100 (Preferred indent after wrapping: 8 spces)
Imports: do not use package imports (e.g. import org.uima.*). order
imports alphabetically
[EMAIL PROTECTED] wrote:
Braces: Each brace on a line by itself - Lally
Braces: Opening brace not on a separate line, closing one on separate
line - Schor
Braces: Opening brace not on a separate line, closing one on
separate line - Thilo (no strong feelings though)
Braces: {
>> Braces: Each brace on a line by itself - Lally
>> Braces: Opening brace not on a separate line, closing one on separate
>> line - Schor
>Braces: Opening brace not on a separate line, closing one on
> separate line - Thilo (no strong feelings though)
Braces: {
same as schor & thilo (edd
Marshall Schor wrote:
My votes:
Braces: Each brace on a line by itself - Lally
Braces: Opening brace not on a separate line, closing one on separate line -
Schor
Braces: Opening brace not on a separate line, closing one on
separate line - Thilo (no strong feelings though)
Member Varia
I agree. Another important point then is where the opening braces go,
as that will also introduce/eliminate newlines.
Adam Lally wrote:
On 11/16/06, Marshall Schor <[EMAIL PROTECTED]> wrote:
Thanks for clarifying.
Having consistent line-end wrapping styles and lengths should fix this,
right?
On 11/16/06, Marshall Schor <[EMAIL PROTECTED]> wrote:
Thanks for clarifying.
Having consistent line-end wrapping styles and lengths should fix this,
right?
Yes, that's why I started this discussion in the first place. :)
-Adam
Thanks for clarifying.
Having consistent line-end wrapping styles and lengths should fix this,
right?
-Marshall
Adam Lally wrote:
On 11/16/06, Marshall Schor <[EMAIL PROTECTED]> wrote:
Trick for handling newlines:
If the file in the repository has different nl chars from the one your
compa
On 11/16/06, Marshall Schor <[EMAIL PROTECTED]> wrote:
Trick for handling newlines:
If the file in the repository has different nl chars from the one your
comparing with in your workspace, you can easily just switch the
workspace one to match: highlight the file, and use the file menu ->
conver
My votes:
Braces: Each brace on a line by itself - Lally
Braces: Opening brace not on a separate line, closing one on separate
line - Schor
Member Variables: before methods - Lally
Member Variables: before methods - Schor
Line Length: 100 (also - default indent after wrapping: suggest 8
Trick for handling newlines:
If the file in the repository has different nl chars from the one your
comparing with in your workspace, you can easily just switch the
workspace one to match: highlight the file, and use the file menu ->
convert line delimeters to... and switch them to match.
I
So here's a list of code conventions that I think we should get
agreement on:
My votes:
Braces: Each brace on a line by itself
Member Variables: I'll add my support behind Thilo's suggestion to
put member variables before methods. However I'm not so OK with
actually having to go through an
Not sure I follow you. I admit that the "ignore whitespace" option is
less than perfect (it can't seem to handle newlines correctly, which is
a pain).
Yes, even with ignore whitespace set, the Eclipse compare shows every
change in line wrapping that was caused by your reformat. The Java
struc
Marshall Schor wrote:
...
What's the benefit of prefixing member refs with "this"? I find it
makes the code harder to read. Eclipse can be set up to "color" member
refs, in any case.
It's essentially a matter of taste. The knock-down argument for me is:
there's a Java language construct fo
Adam Lally wrote:
On 11/15/06, Thilo Goetz <[EMAIL PROTECTED]> wrote:
Yes, that file had tabs which made it unreadable. On the other hand, if
you use Eclipse, it is not at all hard to see what changed as the
structural compare will show you only logical differences.
For me, the Eclipse Java S
On 11/15/06, Thilo Goetz <[EMAIL PROTECTED]> wrote:
Yes, that file had tabs which made it unreadable. On the other hand, if
you use Eclipse, it is not at all hard to see what changed as the
structural compare will show you only logical differences.
For me, the Eclipse Java Structure Compare on
My prefs are like Adams (2 char indents, no tabs) except I don't like
using up a line for opening braces (this lets me see more code on my
screen at once). I do use up a line for the closing brace, though.
I agree with Thilo on things like running findbugs, etc. as a general
practice, and fix
Adam Lally wrote:
I noticed Thilo checked in a file (SofaTest) that showed as having
many changes in it, mostly I think due to having been reformatted in
Eclipse with Source -> Format. This makes it hard to see what
actually changed.
Yes, that file had tabs which made it unreadable. On the ot
I noticed Thilo checked in a file (SofaTest) that showed as having
many changes in it, mostly I think due to having been reformatted in
Eclipse with Source -> Format. This makes it hard to see what
actually changed.
What should we do about this? Could we agree on a common code style,
and maybe
22 matches
Mail list logo
