You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Scott Eade <se...@backstagetech.com.au> on 2007/04/26 03:09:32 UTC
Coding Specification - do we care?
How strongly do you guys feel about coding standards? Turbine has
always had this:
http://jakarta.apache.org/turbine/common/code-standards.html but we have
a tonne of code that simply does not conform.
I guess I am in two minds about this. On one hand I like to see
consistently formatted code - it is just easier when it looks the same
throughout a codebase. On the other hand, I don't see any of us with
the luxury of time available to dedicate to this aspect of the project
(i.e. one that doesn't really move us forward in any material way).
Corrective action has me in two minds also - we all most likely use
IDE's that provide automated code formatting facilities, so it is not
difficult to do, but on the other hand commits that do nothing but
reformat code are a hassle when it comes to reviewing changes to code
over time (IDE compare options that ignore whitespace changes go some of
the way, but we do not always look at this via an IDE).
I guess my overriding consideration has to date been that contributors
would be discouraged by a bunch of "please reformat your code" posts -
hell, we need all the contributions we can get.
So does anybody feel strongly about this or should we just continue as
we are now and just be happy to receive the commits? If we were going
to try to adhere to them more closely I would certainly want to review
the 80 character line length standard - my monitors and printer can deal
with just so much more.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Coding Specification - do we care?
Posted by Thomas Vandahl <th...@tewisoft.de>.
Scott Eade wrote:
> How strongly do you guys feel about coding standards? Turbine has
> always had this:
> http://jakarta.apache.org/turbine/common/code-standards.html but we have
> a tonne of code that simply does not conform.
I know, I tried to reformat stuff when it passed my way. Actually I *do*
care about coding standards, because they help the developer himself to
structurize his code and they help the community to understand each other.
> Corrective action has me in two minds also - we all most likely use
> IDE's that provide automated code formatting facilities, so it is not
> difficult to do, but on the other hand commits that do nothing but
> reformat code are a hassle when it comes to reviewing changes to code
> over time (IDE compare options that ignore whitespace changes go some of
> the way, but we do not always look at this via an IDE).
Reformatting is a matter of a mouse click in Eclipse, you know. Maybe we
can combine this with the re-licensing, where we need to touch all files
anyway. However there will still be a lot of JavaDocs missing and/or
wrong, especially in the Fulcrum code base.
> I guess my overriding consideration has to date been that contributors
> would be discouraged by a bunch of "please reformat your code" posts -
> hell, we need all the contributions we can get.
I understand your point and I agree with you here, for the time being.
But remember, the above-mentioned coding style is widespread *and* is
known by the name of our project, it's "Turbine Coding Style". So that
we, of all people, should be the first to adhere to it.
> So does anybody feel strongly about this or should we just continue as
> we are now and just be happy to receive the commits? If we were going
> to try to adhere to them more closely I would certainly want to review
> the 80 character line length standard - my monitors and printer can deal
> with just so much more.
-0.5 on the line length issue. I like to use screen real estate for
context information, for example. My editor window usually takes only
half of the screen width.
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: AW: Coding Specification - do we care?
Posted by Siegfried Goeschl <si...@it20one.at>.
Hi folks,
I hope that updating the headers is not done manually
+) I have a little tool for doing that
+) Jalopy can also do the job
(http://jalopy.sourceforge.net/existing/header.html)
Cheers,
Siegfried Goeschl
Juergen Hoffmann wrote:
> Hi Scott, Hi Thomas,
>
>> Scott Eade wrote:
>>> How strongly do you guys feel about coding standards? Turbine has
>>> always had this:
>>> http://jakarta.apache.org/turbine/common/code-standards.html but we
>> have
>>> a tonne of code that simply does not conform.
>> I know, I tried to reformat stuff when it passed my way. Actually I *do*
>> care about coding standards, because they help the developer himself to
>> structurize his code and they help the community to understand each
>> other.
>
> As long as opening Braces start on a new line, I do not really car.
>
>>> Corrective action has me in two minds also - we all most likely use
>>> IDE's that provide automated code formatting facilities, so it is not
>>> difficult to do, but on the other hand commits that do nothing but
>>> reformat code are a hassle when it comes to reviewing changes to code
>>> over time (IDE compare options that ignore whitespace changes go some
>> of
>>> the way, but we do not always look at this via an IDE).
>> Reformatting is a matter of a mouse click in Eclipse, you know. Maybe we
>> can combine this with the re-licensing, where we need to touch all files
>> anyway. However there will still be a lot of JavaDocs missing and/or
>> wrong, especially in the Fulcrum code base.
>
> Since I volunteered in updating the headers, and I have the formatting rules
> ready, I will do all o fit in one swoosh. (Thomas, do you mind if we just
> quickly echange the eclipse configurations of code formatting rules, just so
> we both have the same ruleset? If you agree, I will send you mine later today)
>
>>> I guess my overriding consideration has to date been that contributors
>>> would be discouraged by a bunch of "please reformat your code" posts -
>>> hell, we need all the contributions we can get.
>> I understand your point and I agree with you here, for the time being.
>> But remember, the above-mentioned coding style is widespread *and* is
>> known by the name of our project, it's "Turbine Coding Style". So that
>> we, of all people, should be the first to adhere to it.
>>
>>> So does anybody feel strongly about this or should we just continue as
>>> we are now and just be happy to receive the commits? If we were going
>>> to try to adhere to them more closely I would certainly want to review
>>> the 80 character line length standard - my monitors and printer can
>> deal
>>> with just so much more.
>> -0.5 on the line length issue. I like to use screen real estate for
>> context information, for example. My editor window usually takes only
>> half of the screen width.
>
> I would be +1 here, since I am using Fast Views for the Package Explorer,
> which gives me more space for the editor ;) and makes long statements easier
> to read.
>
> Kind regards
>
> Juergen
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: AW: Coding Specification - do we care?
Posted by Scott Eade <se...@backstagetech.com.au>.
Thomas Vandahl wrote:
> Juergen Hoffmann wrote:
>> Since I volunteered in updating the headers, and I have the
>> formatting rules
>> ready, I will do all o fit in one swoosh. (Thomas, do you mind if we
>> just
>> quickly echange the eclipse configurations of code formatting rules,
>> just so
>> we both have the same ruleset? If you agree, I will send you mine
>> later today)
>
> Yes, please do. But it's not only the formatting in Eclipse, it's
> everything CheckStyle checks for, naming of methods, fields and
> constants, magic numbers etc. etc.
We need to strike a balance here - I would mostly like to see changes
limited to whitespace and brackets.
If we are going to reformat in batch I would probably vote to retain the
80 character line length so as to reduce the overall number of changes
that result.
I would probably go for a more pragmatic approach also, say:
* Don't do it for any branch other than trunk (the licenses need to
be updated, but I see little sense addressing the formatting for
what is essentially a maintenance branch)
* Do it for turbine trunk separately to, but in close proximity to
the license update (actually, this would be the one argument for
either holding off for now or applying the standard to the 2.3
branch - efforts to keep the two in sync will be a little easier
if both are reformatted)
* Consider updating the fulcrum components as part of (or even
shortly after) their next individual release (above bracketed
concern also applies)
I guess I am still wary of pulling the rug from under the maintainers of
the existing code.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: AW: Coding Specification - do we care?
Posted by Thomas Vandahl <th...@tewisoft.de>.
Juergen Hoffmann wrote:
> Since I volunteered in updating the headers, and I have the formatting rules
> ready, I will do all o fit in one swoosh. (Thomas, do you mind if we just
> quickly echange the eclipse configurations of code formatting rules, just so
> we both have the same ruleset? If you agree, I will send you mine later today)
Yes, please do. But it's not only the formatting in Eclipse, it's
everything CheckStyle checks for, naming of methods, fields and
constants, magic numbers etc. etc.
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
AW: Coding Specification - do we care?
Posted by Juergen Hoffmann <ho...@apache.org>.
Hi Scott, Hi Thomas,
> Scott Eade wrote:
> > How strongly do you guys feel about coding standards? Turbine has
> > always had this:
> > http://jakarta.apache.org/turbine/common/code-standards.html but we
> have
> > a tonne of code that simply does not conform.
>
> I know, I tried to reformat stuff when it passed my way. Actually I *do*
> care about coding standards, because they help the developer himself to
> structurize his code and they help the community to understand each
> other.
As long as opening Braces start on a new line, I do not really car.
> > Corrective action has me in two minds also - we all most likely use
> > IDE's that provide automated code formatting facilities, so it is not
> > difficult to do, but on the other hand commits that do nothing but
> > reformat code are a hassle when it comes to reviewing changes to code
> > over time (IDE compare options that ignore whitespace changes go some
> of
> > the way, but we do not always look at this via an IDE).
>
> Reformatting is a matter of a mouse click in Eclipse, you know. Maybe we
> can combine this with the re-licensing, where we need to touch all files
> anyway. However there will still be a lot of JavaDocs missing and/or
> wrong, especially in the Fulcrum code base.
Since I volunteered in updating the headers, and I have the formatting rules
ready, I will do all o fit in one swoosh. (Thomas, do you mind if we just
quickly echange the eclipse configurations of code formatting rules, just so
we both have the same ruleset? If you agree, I will send you mine later today)
> > I guess my overriding consideration has to date been that contributors
> > would be discouraged by a bunch of "please reformat your code" posts -
> > hell, we need all the contributions we can get.
>
> I understand your point and I agree with you here, for the time being.
> But remember, the above-mentioned coding style is widespread *and* is
> known by the name of our project, it's "Turbine Coding Style". So that
> we, of all people, should be the first to adhere to it.
>
> > So does anybody feel strongly about this or should we just continue as
> > we are now and just be happy to receive the commits? If we were going
> > to try to adhere to them more closely I would certainly want to review
> > the 80 character line length standard - my monitors and printer can
> deal
> > with just so much more.
>
> -0.5 on the line length issue. I like to use screen real estate for
> context information, for example. My editor window usually takes only
> half of the screen width.
I would be +1 here, since I am using Fast Views for the Package Explorer,
which gives me more space for the editor ;) and makes long statements easier
to read.
Kind regards
Juergen
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org