10:39 AM
To: [EMAIL PROTECTED]
Subject: Re: Struts Coding Standard
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
-
From: Paul Speed [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 07, 2003 1:11 PM
To: Struts Developers List
Subject: Re: Struts Coding Standard
Javadocs make this argument less relevant. If you are
looking at the source then you need to see the guts.
Otherwise, use the javadocs
Message-
From: Paul Speed [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 08, 2003 10:08 AM
To: Struts Developers List
Subject: Re: Struts Coding Standard
Any .java file can be javadoced. Only takes a little time to watch
it churn through the source. It won't necessarily be useful
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
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
That's certainly not a common practice and would
: David Graham [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 07, 2003 10:39 AM
To: [EMAIL PROTECTED]
Subject: Re: Struts Coding Standard
Another practice I reciently started is placing fields at
the very end
of a
class definition, after all methods. It makes comparing the class
From: James Higginbotham [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Subject: RE: Struts Coding Standard
Date: Tue, 7 Jan 2003 12:20:30 -0600
I'm not a contributer, but just to mention about putting field at the
end of a class
On Tue, 7 Jan 2003, David Graham wrote:
Date: Tue, 07 Jan 2003 12:17:12 -0700
From: David Graham [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: RE: Struts Coding Standard
Like you said, Struts does not use the source
]
Subject: RE: Struts Coding Standard
Date: Tue, 7 Jan 2003 12:20:30 -0600
I'm not a contributer, but just to mention about putting field at the
end of a class definition, I agree.. It tends to jive better with the
concept of encapsulation.. Anyone reading the source can see what
:
;-
http://mindprod.com/unmain.html
-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 08, 2003 03:17
To: [EMAIL PROTECTED]
Subject: RE: Struts Coding Standard
Like you said, Struts does not use the source as the documentation. The
majority of people
. ;-)
--
Martin Cooper
David
From: James Higginbotham [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Subject: RE: Struts Coding Standard
Date: Tue, 7 Jan 2003 12:20:30 -0600
I'm not a contributer, but just to mention
burned on this by all involved..
James
-Original Message-
From: Martin Cooper [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 07, 2003 1:49 PM
To: Struts Developers List
Subject: RE: Struts Coding Standard
On Tue, 7 Jan 2003, David Graham wrote:
Like you said, Struts
David Graham wrote:
Member variables should be at the top if for no other reason
than that's where people expect them to be.
It's one of those acquired tastes. Like I said it's not on my list of
must haves, and that's ok! When I first saw variables at the bottom
of a class I cursed, and
List [EMAIL PROTECTED]
Subject: Re: Struts Coding Standard
Date: Mon, 06 Jan 2003 15:12:46 -0500
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
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
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
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
David Graham wrote:
Couldn't you do it just on check-in? It seems like it would take
forever to check out the project if it's always formatting the code.
Yes, it could be done just for check-in. Then we would run into the
problem of doing cvs diffs would not be too usefull if
The version
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.
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
20 matches
Mail list logo
