You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by David Graham <dg...@hotmail.com> on 2003/01/06 17:48:53 UTC
Struts Coding Standard
There's been some talk of formalizing the coding standard we follow so
here's a starting point for discussions.
1. Follow the Java standard coding practices. This includes putting
opening braces on the same line like if (true) {.
All IDEs support formatting code to this standard and all Java coders
already know it.
2. Enclose all blocks in braces, even one liners. This makes the code
easier to follow and decreases bugs.
Currently we should be following the Java standard but we should explicitly
state this for the project.
Thoughts?
Dave
_________________________________________________________________
The new MSN 8 is here: Try it free* for 2 months
http://join.msn.com/?page=dept/dialup
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Struts Coding Standard
Posted by Paul Speed <ps...@progeeks.com>.
Spaces instead of tabs. </me ducks>
As I recall, Sun's standard has 8 char tabs 4 space indentions. It's
the only part I routinely throw out.
Actually, just checkint the latest:
http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html
Construction of indentation is unspecified now. It avoids wars to
be specific, though.
$0.02,
-Paul
P.S.: I sometimes find the need to add naming guidlines such as
avoiding MS-COMisms like "public interface IMyInterface", ie: 'I' is
bad.
David Graham wrote:
>
> There's been some talk of formalizing the coding standard we follow so
> here's a starting point for discussions.
>
> 1. Follow the Java standard coding practices. This includes putting
> opening braces on the same line like if (true) {.
> All IDEs support formatting code to this standard and all Java coders
> already know it.
>
> 2. Enclose all blocks in braces, even one liners. This makes the code
> easier to follow and decreases bugs.
>
> Currently we should be following the Java standard but we should explicitly
> state this for the project.
>
> Thoughts?
>
> Dave
>
> _________________________________________________________________
> The new MSN 8 is here: Try it free* for 2 months
> http://join.msn.com/?page=dept/dialup
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Struts Coding Standard
Posted by Robert Leland <rl...@apache.org>.
Craig R. McClanahan wrote:
> the functional changes, and created a lot
> of "noise" in the commit diffs. You'd think this would go away after each
> file has been checked out and updated at least once, but that never really
> seems to happen (because the formatting rules often get tweaked).
That is why I had suggested that the files get formatted on
checkout & checkin then doing a diff always works.
-Rob
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Struts Coding Standard
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
Just as a data point to this discussion, the XDoclet project uses
Pretty to do code formatting during the build process. It seems to
work fine, and of course, only touches files that should be touched
(the ones you're working on). Its odd sometimes to pop back to an IDE
from a command-line build and see the files refresh and change slightly.
But in general this gives the code consistency and I'm pleased with how
it works.
Erik
On Monday, January 6, 2003, at 04:28 PM, Craig R. McClanahan wrote:
>
>
> On Mon, 6 Jan 2003, Robert Leland wrote:
>
>>
>> I suggested before having the code
>> automatically formatted when a checkin or
>> checkout happens.
>>
>
> I've worked on a couple of projects that tried this, and we ultimately
> gave up on it as being unsatisfactory. The problem was that the
> formatting changes would obscure the functional changes, and created a
> lot
> of "noise" in the commit diffs. You'd think this would go away after
> each
> file has been checked out and updated at least once, but that never
> really
> seems to happen (because the formatting rules often get tweaked).
>
> Craig
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Struts Coding Standard
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 6 Jan 2003, Robert Leland wrote:
>
> I suggested before having the code
> automatically formatted when a checkin or
> checkout happens.
>
I've worked on a couple of projects that tried this, and we ultimately
gave up on it as being unsatisfactory. The problem was that the
formatting changes would obscure the functional changes, and created a lot
of "noise" in the commit diffs. You'd think this would go away after each
file has been checked out and updated at least once, but that never really
seems to happen (because the formatting rules often get tweaked).
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Struts Coding Standard
Posted by Robert Leland <rl...@apache.org>.
Martin Cooper wrote:
> In any case, I'd prefer to separate the discussion of a set of coding
> conventions from the discussion on whether or not to automate them around
> the checkout/checkin process.
+1, I'll table the auto discussion for now.
My only pet peeves on formatting is
no spaces between method names and their parameters
I like:
methodName(params);
I flinch at:
methodName (params);
I can live with any formatting of the variables are their types, speces
before, after, none.
Another practice I reciently started is placing fields at the very end
of a class definition, after all methods. It makes comparing the class
and it's interface. But since struts doesn't use many interfaces this
isn't a must
for me.
-Rob
> I think we need to do the former first, and
> then we can talk more about the latter.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Struts Coding Standard
Posted by Martin Cooper <ma...@apache.org>.
On Mon, 6 Jan 2003, Robert Leland wrote:
> I suggested before having the code
> automatically formatted when a checkin or
> checkout happens.
Based on past experience, I'm not too comfortable with this idea. I had a
similar experience to Craig, and also found that some things just didn't
work out properly when left to an automated tool. Getting the formatter to
agree with the analyser was harder than we expected. ;-)
I would argue that once the code base has been brought into compliance
with the agreed coding conventions, and a tool is in place to easily
verify such compliance, the need for an automated process is significantly
diminished.
In any case, I'd prefer to separate the discussion of a set of coding
conventions from the discussion on whether or not to automate them around
the checkout/checkin process. I think we need to do the former first, and
then we can talk more about the latter.
--
Martin Cooper
>
> This could be done in 2 places:
> 1) The Jakarta script that
> checks to see if a user has access to one of
> the Jakarta projects.
>
> 2)CVS provides hooks/calls to be made
> before or after any check out, or checkin operations.
>
> The wrapper could look for the existance of
> ${Project}/conf/format.dat
> where Project = jakarta-struts in our case
> and if the 'format.dat' file exists automatically format the
> code if it is a .java, .xml, or .xslt file.
>
> Formatting on both checkin & checkout has the
> advantage when doing a CVS diff between
> an earlier version if struts code that wasn't formatted,
> and a current version that is formatted.
> In both cases both versions are in the same format.
> Also if we change the formatting over time, all
> previous versions would presented in the most current version.
>
>
> -Rob
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Struts Coding Standard
Posted by Robert Leland <rl...@apache.org>.
I suggested before having the code
automatically formatted when a checkin or
checkout happens.
This could be done in 2 places:
1) The Jakarta script that
checks to see if a user has access to one of
the Jakarta projects.
2)CVS provides hooks/calls to be made
before or after any check out, or checkin operations.
The wrapper could look for the existance of
${Project}/conf/format.dat
where Project = jakarta-struts in our case
and if the 'format.dat' file exists automatically format the
code if it is a .java, .xml, or .xslt file.
Formatting on both checkin & checkout has the
advantage when doing a CVS diff between
an earlier version if struts code that wasn't formatted,
and a current version that is formatted.
In both cases both versions are in the same format.
Also if we change the formatting over time, all
previous versions would presented in the most current version.
-Rob
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Struts Coding Standard
Posted by Martin Cooper <ma...@apache.org>.
On Mon, 6 Jan 2003, Ted Husted wrote:
> The "project" is technically Jakarta, and it is explicitly stated:
>
> http://jakarta.apache.org/site/source.html
>
> Though, I suppose we could link to that from the roadmap.
>
> We do have to forbid tab characters since it screws up the CVS emailings
> otherwise.
>
> Personally, I like the Elements of Java Style since it is more
> comprehensive. It also works like a superset of Sun, so there is no
> conflict there.
I'm happy with the Sun coding conventions. Craig mentioned that there were
a couple of tweaks to those that he prefers, and I'd be willing to listen
to those. I'm not familiar with what the Elements of Java Style promotes,
but I'm also willing to listen to what you have in mind, especially if
it's something that can be codified for Checkstyle to verify. And I agree with
everyone on the "no tabs" rule. ;-)
--
Martin Cooper
>
> -Ted.
>
>
> David Graham wrote:
> > There's been some talk of formalizing the coding standard we follow so
> > here's a starting point for discussions.
> >
> > 1. Follow the Java standard coding practices. This includes putting
> > opening braces on the same line like if (true) {.
> > All IDEs support formatting code to this standard and all Java coders
> > already know it.
> >
> > 2. Enclose all blocks in braces, even one liners. This makes the code
> > easier to follow and decreases bugs.
> >
> > Currently we should be following the Java standard but we should
> > explicitly state this for the project.
> >
> > Thoughts?
> >
> > Dave
> >
> > _________________________________________________________________
> > The new MSN 8 is here: Try it free* for 2 months
> > http://join.msn.com/?page=dept/dialup
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> Ted Husted,
> Struts in Action <http://husted.com/struts/book.html>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Struts Coding Standard
Posted by Ted Husted <hu...@apache.org>.
The "project" is technically Jakarta, and it is explicitly stated:
http://jakarta.apache.org/site/source.html
Though, I suppose we could link to that from the roadmap.
We do have to forbid tab characters since it screws up the CVS emailings
otherwise.
Personally, I like the Elements of Java Style since it is more
comprehensive. It also works like a superset of Sun, so there is no
conflict there.
-Ted.
David Graham wrote:
> There's been some talk of formalizing the coding standard we follow so
> here's a starting point for discussions.
>
> 1. Follow the Java standard coding practices. This includes putting
> opening braces on the same line like if (true) {.
> All IDEs support formatting code to this standard and all Java coders
> already know it.
>
> 2. Enclose all blocks in braces, even one liners. This makes the code
> easier to follow and decreases bugs.
>
> Currently we should be following the Java standard but we should
> explicitly state this for the project.
>
> Thoughts?
>
> Dave
>
> _________________________________________________________________
> The new MSN 8 is here: Try it free* for 2 months
> http://join.msn.com/?page=dept/dialup
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
--
Ted Husted,
Struts in Action <http://husted.com/struts/book.html>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>