[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cross-project-issues-dev] Code formatting & clean-up standards.
|
> The simple reason is that it puts the concern where it probably should
be, at the project (in the workspace sense) level and it only requires or
assumes the tooling that everyone already has.
Correct. This is not only true for formatting/style related issues. Also
Java compiler settings etc. should be set by project and stored in a
repository.
Also note that you can enable 'Save Actions' on your project(s). There is
for example a setting that allows to format only the changed lines on save
or organize the imports as specified by your project.
Dani
From:
Miles Parker <milesparker@xxxxxxxxx>
To:
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
Cc:
Jonas Ruettimann <jonas.ruettimann@xxxxxxx>
Date:
14.02.2011 21:44
Subject:
Re: [cross-project-issues-dev] Code formatting & clean-up standards.
I think that all of the suggestions that people have given along these
lines are helpful, but personally the most appealing to me so far is
Eike's. The simple reason is that it puts the concern where it probably
should be, at the project (in the workspace sense) level and it only
requires or assumes the tooling that everyone already has. I can see a bit
of a separation of concerns between build-time and design-time, but my
bias more and more is that the value of having a common way to
enforce/support/bludgeon and pushing that to development time is best. My
thinking is that the proliferation of various artifact types really makes
it difficult for people managing builds and especially for new
contributors..though in this case it was a new contributor that got me
thinking about this.
Still once we have the standards defined at the project level, it makes
sense to check them in the build and then beat (oneself probably, in my
case) when they don't match.
It is a maintenance issue though. Actually it would be nice perhaps at a
higher level -- but there is no such thing as a "product" or "release"
project. I don't think there is a way to enforce .settings that would be
applied to features. But given that there isn't a one-to-many relationship
between plugins and features that probably wouldn't be a good idea anyway.
800 characters does seems a little extreme.. ;D .. at least for our
usages. One of the problems with generated code is that often you end up
with lines that wrap dozens of conditionals and it those aren't broken up
automatically they will be impossible to scan.
On Feb 14, 2011, at 12:22 PM, David Carver wrote:
If you are using maven, you could add the maven-checkstyle plugin to your
build, and then report the number of Checkstyle violations that occur.
It's pretty humbling to those that mess things up, when they get a couple
thousand violations reported.
Dave
On 02/14/2011 02:10 PM, Jesse McConnell wrote:
in jetty we put a code format file in our admin directory in svn
http://dev.eclipse.org/viewsvn/viewvc.cgi/admin/jetty-eclipse-java-format.xml?root=RT_JETTY&view=log
as for taking in patches, when that happens we just apply it and
review...and if its egregious in its formatting issues we sometimes push
back to the submitter and tell them to adjust it to the standards of the
project.
and if someone in the project is committing code that doesn't adhere to
the formatter we beat them until their morale improves and they use the
format :)
cheers,
jesse
--
jesse mcconnell
jesse.mcconnell@xxxxxxxxx
On Mon, Feb 14, 2011 at 12:47, Andrew Niefer <aniefer@xxxxxxxxxx> wrote:
The Platform Core team has
http://www.eclipse.org/eclipse/platform-core/documents/coding_conventions.html
where there is a link to a formatting xml file which can be imported into
Eclipse.
I don't think these settings are strictly enforced, but p2 for example
uses this as project specific preferences with format-on-save to help keep
the extraneous changes to a minimum.
-Andrew
From:
Miles Parker <milesparker@xxxxxxxxx>
To:
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
Date:
02/14/2011 01:36 PM
Subject:
Re: [cross-project-issues-dev] Code formatting & clean-up standards.
Sent by:
cross-project-issues-dev-bounces@xxxxxxxxxxx
Hi guys,
No, this wasn't a push to get design by committee across all projects. ;)
I just wondered where alignment might be best made. That's an excellent
idea about putting formatting into projects. I hate to load up projects
with yet more stuff to maintain, but I think that in this and for stuff
like java compliance levels it does make sense. 120 characters is exactly
what I've hit on, so it must be correct. Now, if every Eclipse project
used 120 characters that would make the world perfect. Shall we have a
vote? <ducking/>
cheers,
Miles
On Feb 14, 2011, at 10:26 AM, Eike Stepper wrote:
> Hi Miles,
>
> We use 120 chars per line. That seems to be enought to prevent line
wraps most of the time. If not we use temporary variables to make it
shorter and more readable.
>
> My impression is that we have enough cross platform rules. Discussions
(elsewhere) about formatting in particular have never resultet in any
consesus. In my project I just dictated them and I review everything, also
to ensure that my formattting and coding standards are met. We've received
excellent feedback from the community for our code quality. I think it's
important to store the respective profiles *inside* your projects so that
they do not depend on local workspace settings.
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
> Am 14.02.2011 19:16, schrieb Miles Parker:
>> Now that I actually have the "problem" of coordinating multiple
committers, I wonder hat other projects are doing WRT to project and
cross-project code formatting standards. At one point I had all sorts of
custom things setup, but I realized that that made every change from
another platform and every code generation create report all sorts of
meaningfulness SCM modifications and I'm just discovering makes patches
and git merges that much harder to grok. So I've been moving to the
"Eclipse built-in" with one major exception -- the 80 char max line limit
just seems way to limiting given modern IDEs and creates a ton of
unnecessary and hard to read extra lines IMO. Is there / has there been
any effort to have a standard set across platforms? I know for one thing
that almost every code *generation* tool (mine included) seems to use
different formatting.
>>
>> Then there is the whole issue of Java coding standards, of which I hate
to even bring up* but I'm wondering if there has been any though about
that cross-project and if not if anyone is interested in entertaining
that..
>>
>> cheers,
>>
>> Miles
>>
>>
>> [personally I think the
>>
>> if (x)
>> do y;
>>
>> construct is a great evil, but I appear to be in the minority.. ;D]
>> _______________________________________________
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
