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 [email protected]:
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.
On 18 Jun 2016 8:53 a.m., "Philip Wenig" <[email protected]
<mailto:[email protected]>> wrote:
We also enforce developers to use the coding styles, which are
stored in one of our Git repositories.
https://wiki.openchrom.net/index.php/Development#Edit_settings
Anyhow, it sometimes happens that people forget to format the
code. The Java editor offers an auto-format capability which is
quite nice.
Cheers,
Philip
Am 17.06.2016 um 20:56 schrieb Sam Davis:
You can configure the Java Editor to perform auto-actions
on save, potentially on a per-project basis. I have never
enabled it on my code because I have never adjusted
formatting styles to match my longer line wrapping preferences.
Some projects, notably EMF, have very esoteric code styles
which I find that I always need to emulate by hand.
Note that if code formatting is configured on a per-project
basis, this configuration is stored in git so that anyone
checking out the project and using Eclipse will automatically
check in correctly formatted code. This is how we do it in
Mylyn and it means we don't have code formatting as a part of
our release process - all the code is already always correctly
formatted.
Cheers,
Sam
_______________________________________________
incubation mailing list
[email protected] <mailto:[email protected]>
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/incubation
--
~~~~~~~~~~~~~~~~~~~~~~~~
OpenChrom - the open source alternative for chromatography / mass
spectrometry
Dr. Philip Wenig » Founder »[email protected]
<mailto:[email protected]> »http://www.openchrom.net
~~~~~~~~~~~~~~~~~~~~~~~~
_______________________________________________
incubation mailing list
[email protected] <mailto:[email protected]>
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/incubation
_______________________________________________
incubation mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/incubation
_______________________________________________
incubation mailing list
[email protected]
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
[email protected], 707.332.0670 (Office: 545Q Cory)
_______________________________________________
incubation mailing list
[email protected]
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
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/incubation
