Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Code formatting & clean-up standards.

Am 14.02.2011 21:43, schrieb Miles Parker:

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.
For us it turned out that we have a small number of different project types that require different .settings (generated, not generated, doc plugins, ...). You're right that it is a maintenance nightmare to change the actual settings once they had been established for such a grop. But we don't go through the UI for that, we adjust them with the Project Properties dialog for one example and then copy the whole .settings folder to the other members of that group.

A builder that creates/merges the .settings contents from a set of "setting tags" that refer to setting "template projects" would be nicer, but hey ;-)


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
Not so nice :P

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper


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 <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 <mailto:jesse.mcconnell@xxxxxxxxx>


On Mon, Feb 14, 2011 at 12:47, Andrew Niefer <aniefer@xxxxxxxxxx <mailto:aniefer@xxxxxxxxxx>> wrote:

    The Platform Core team has http://www.eclipse.org/eclipse/platform-core/documents/coding_conventions.htmlwhere 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 <mailto:milesparker@xxxxxxxxx>>
    To: 	Cross project issues <cross-project-issues-dev@xxxxxxxxxxx <mailto: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 <mailto: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://www.esc-net.de/>
    > http://thegordian.blogspot.com <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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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




Back to the top