qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Johnson, Eric" <Eric.John...@iona.com>
Subject RE: [java] code style
Date Wed, 18 Oct 2006 22:30:46 GMT
>From the perspective of someone who is not a whiz bang developer and has
to pour over code in the process of writing documentation, I'm 100%
behind the idea of having a well documented and strictly enforced set of
code styles. While it may be nice if a popular and publicly published
set of style guidelines were used, it is far more important for the
rules to be clearly spelled out, in a place where they are easily found,
and enforced.
Otherwise, I pity the fool who has to dig around in the code base
without being steeped in its history. 

> -----Original Message-----
> From: Vinoski, Stephen 
> Sent: Wednesday, October 18, 2006 6:18 PM
> To: qpid-dev@incubator.apache.org
> Subject: Re: [java] code style
> 
> On Oct 18, 2006, at 5:33 PM, Robert Greig wrote:
> 
> > On 18/10/06, Steve Vinoski <vinoski@iona.com> wrote:
> >> What percentage of all the Java projects out there use coding 
> >> guidelines other than the Sun guidelines? I would guess it's very 
> >> very small, far less than 1%.
> >
> > Is that a guess? Do you have any evidence to back that up?
> 
> Well, my sentence above does use the phrase "I would guess"... ;-)
> 
> > I have just looked at a few Apache projects. Examples of 
> ones that do
> > *not* follow the Sun standards (or at least appear not to 
> based on a 
> > viewing of some randomly selected files) are BCEL, Cactus, Commons 
> > Configuration, ECS. I only looked at about 8 or 9 projects 
> so that is 
> > a rate of around 50% (in an admittedly very small sample space).
> 
> I don't know that reviewing random open source projects is 
> the best way to determine this, as many seem to be internally 
> inconsistent with respect to coding style because they don't 
> enforce it with automated rules.
> 
> >> Except that when I'm working on Qpid I have to remember to use the 
> >> right settings, which are different than all other Java 
> projects I've 
> >> ever worked on...
> >
> > My IDE of choice (Intellij) allows me to configure the 
> coding standard 
> > on a per-project basis.
> 
> IMO, nobody should ever be forced to have to rely on an IDE 
> to get things like this right.
> 
> >> >> Should it be corrected?
> >> >
> >> > You mean "changed". Corrected implies it is broken in some way.
> >>
> >> I think it's broken in the sense that it's a deviation that adds 
> >> needless complication to Qpid development.
> >
> > Only if you happen to work in an environment where everyone 
> else uses 
> > the standard you like.
> >
> >> This has nothing to do with personal preference -- I 
> personally can 
> >> adapt to any style. This has to do with putting artificial 
> hurdles in 
> >> the way of building the Qpid Java community. If 99+% of Java 
> >> developers expect to follow the Sun guidelines, then why make them 
> >> jump through hoops to work on Qpid?
> >
> > That 99% number again. My scan of other projects shows a 
> wide variety 
> > of styles being adopted. This is just change for change's sake. For 
> > every person who likes it there is likely to be someone who 
> dislikes 
> > it.
> >
> > As I said, with coding standards I think it is important 
> that we have 
> > a standard and that it is enforced.
> 
> I agree, but you're missing an extremely critical point: the 
> Sun style is publicly documented on the web. Am I to guess 
> what the rules are for the JPMC coding style used on this 
> code? Without a document somewhere either in the project 
> itself or on the wiki that explains exactly what the rules 
> are for the style we're using, we might as well have no 
> coding style whatsoever.
> 
> Also, assuming we're not changing the current style, I'd like 
> to have not only that document that explains the style rules, 
> but I'd like to put together and enforce checkstyle rules to 
> ensure consistency across the Java codebase, just as Alan's 
> trying to do in the C++ code.
> 
> --steve
> 
> 

Mime
View raw message