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)
|