Thanks, I figured you were listening :-)
I updated https://wiki.eclipse.org/Coding_Conventions and added
the following:
For Eclipse projects, there is no policy
that requires a specific coding format or style, though the
Eclipse style in the formatter and cleanup is preferred.
Project teams typically determine their own styles and then
commit the appropriate files. One way is to commit files on a
per-project basis, the other is to have a central set of files
that should be imported by each committer.
All: please feel free to edit the wiki directly as you see fit.
Mainly, I wanted to be sure that there was no specific
requirement for coding style from the Eclipse Foundation for
releases.
I'll chat with Erwin the next time we have a call and we can nail
down a proposal for the Triquetrum coding style.
_Christopher
On 6/20/16 11:30 AM, Wayne Beaton
wrote:
The EF is listening :-)
There is no policy that makes any requirements regarding
formatting style. This is an issue to be resolved by the project
team, or possibly by the PMC (though most PMCs don't dig down
into that level of detail).
Wayne
On 20/06/16 11:39 AM, Christopher
Brooks wrote:
Hi Erwin,
I guess I always thought that that all the Eclipse projects
would be cleaned using the Eclipse style formatter and cleaner
as part of the release process. Apparently, that is not the
case. I was hoping someone from the Eclipse Foundation would
chime in on this, but I'll take silence as an indication that
style policy is up to the individual project.
I see the point that running a formatter during the commit
process is not desired.
I definitely feel that the coding style should be enforced
using a tool so that the style is consistent. In academia, we
see code as a form of publication. Publications get spell
checked and grammar checked, so the same thing should happen
with code. Code that has a consistent style is easier to read
and more likely to be reused.
I agree that some sections of the code will not want to be
automatically formatted. For example, ASCII art in comments
should not be formatted.
For sections of code that should not be formatted, we could
use tags, see https://stackoverflow.com/questions/1820908/how-to-turn-off-the-eclipse-code-formatter-for-certain-sections-of-java-code
_Christopher
On 6/18/16 7:52 AM, erwindl0 wrote:
Hi,
I think both are important, and docs probably more indeed.
But some consistency in code style is needed as well.
Although I don't believe style "rules" can be 100%
absolute.
I would not be willing to submit to a fully automated
styling police, that erases my choices.
In some (exceptional) cases I want to maintain the choice to
adapt specific blocks/parts in whatever way that I think is
more appropriate.
regards
erwin
Op 18/06/2016 om 10:18 schreef arcanefoam@xxxxxxxxx:
Hi,
Code styling is important, but getting to a
consensus on what is good/bad is as close as religious war
as you can get. At the end what matters is consistency.
What ever you decide as your coding standards
(indentation, line wrap, opening brackets location, etc)
just make sure it's consistent.
My two cents, and what IMHO is most important,
is documentation. If you really want your project to be
opened sourced and to get people contributing and helping
out, more than having nice styled code, having proper
documentation is best.
Cheers.
_______________________________________________
incubation mailing list
incubation@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/incubation
_______________________________________________
incubation mailing list
incubation@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/incubation
--
Christopher Brooks, PMP University of California
Academic Program Manager & Software Engineer US Mail: 337 Cory Hall
CHESS/iCyPhy/Ptolemy/TerraSwarm Berkeley, CA 94720-1774
cxh@xxxxxxxxxxxxxxxxx, 707.332.0670 (Office: 545Q Cory)
_______________________________________________
incubation mailing list
incubation@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/incubation
--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
_______________________________________________
incubation mailing list
incubation@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/incubation
--
Christopher Brooks, PMP University of California
Academic Program Manager & Software Engineer US Mail: 337 Cory Hall
CHESS/iCyPhy/Ptolemy/TerraSwarm Berkeley, CA 94720-1774
cxh@xxxxxxxxxxxxxxxxx, 707.332.0670 (Office: 545Q Cory)
|