Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [incubation] Project Release Coding Style

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.

On 18 Jun 2016 8:53 a.m., "Philip Wenig" <philip.wenig@xxxxxxxxxxxxx> 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
incubation@xxxxxxxxxxx
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 » philip.wenig@xxxxxxxxxxxxx » http://www.openchrom.net
~~~~~~~~~~~~~~~~~~~~~~~~

_______________________________________________
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





_______________________________________________
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

Back to the top