xerces-j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Larson" <jlar...@waveset.com>
Subject RE: [Xerces2] Coding Conventions (warning: controversial!)
Date Tue, 10 Oct 2000 15:23:08 GMT

While we're on the subject of style, I'd like to point out something
that we find far more offensive than naming conventions.

Please, please, please do not use exceptions as part of "normal" control
flow.

Xerces-J deliberately provokes NullPointerException and
ArrayIndexOutOfBoundsException in places like
org.apache.xerces.utils.StringPool.ensureCapacity() and many other
places.

This makes it very difficult to debug NullPointerExceptions in applications
that
use Xerces.  A common and effective debugging technique is to park an
exception
breakpoint on the java.lang.NullPointerException constructor.  But when
using Xerces,
this is practically useless, since we stop inside Xerces about a hundred
times
before hitting the real error.

We're using 1.0.3, so forgive me if this has been fixed in later versions.
We'll be upgrading soon, and if this flaw is still present in the latest
release, we'll be fixing it locally.  I'll be happy to make the source
changes available.


Finally, on a lesser topic, I *like* prefixes on field names.  After
you've debugged your way out of a few silent collisions on common names
like "name", "node", "count", etc.  you come to appreciate them. I find
underscore to be marginally more readable than 'f'.   Using the prefix
'm' for C++ member variables has been commonly accepted for some time,
the reasons for doing so apply equally to Java.

Jeff

> -----Original Message-----
> From: Brett McLaughlin [mailto:brett.mclaughlin@lutris.com]
> Sent: Tuesday, October 10, 2000 9:44 AM
> To: xerces-j-dev@xml.apache.org
> Subject: Re: [Xerces2] Coding Conventions (warning: controversial!)
>
>
>
>
> Rajiv Mordani wrote:
> >
> > I had brought up this issue about 6 months ago and I was shunned off by
> > everyone. For the record
> >
> > http://archive.covalent.net/xml/xerces-j-dev/2000/04/0095.xml
> >
> > The responses are also available in the archives for those interested..
> >
> > And here we are back on the same issue..  Oh well....
> >
> > I think in general everyone follows the conventions in the link provided
> > by Pier below. I totally disagree about the 'f' for field names.... That
> > just makes the code very very hard to follow IMHO. I think that
> meaningful
> > names is all that's needed..
>
> For what it's worth, I completely agree. Other than Xalan, I don't know
> of any of the Apache projects that use that styling; personally, it
> drives me crazy ;-) I'd love to simply follow the Sun coding
> conventions, and go with that!
>
> -Brett
>
> >
> > - Rajiv
> >
> > --
> > :wq
> >
> > On Fri, 22 Sep 2000, Andy Clark wrote:
> >
> > > "Pier P. Fumagalli" wrote:
> > > > My 0.02 $... There's a very nice document at
> > > > http://java.sun.com/docs/codeconv/ that has been the BIBLE for
> > > > all of us since the very first days in wich we started writing
> > > > java code in the Apache project (back in 97/98, JServ 0.xxx).
> > >
> > > Thanks for the link! I didn't know (or remember) that such a
> > > document was available. My two main comments are:
> > >
> > > 1) They don't specify any special convention for distinguishing
> > > between fields. For the same reason people use a leading under-
> > > score for field names, there is some benefit to being able to
> > > distinguish between local method vars and object vars.
> > >
> > > The Taligent "Ms. Manners" book on programming style,
> > > _Taligent's Guide to Designing Programs_, introduces the 'f'
> > > prefix for fields. Several of our developers were Taligent
> > > engineers so that gives you a little history of why there are
> > > those blankety-blank 'f' prefixes on all those fields names. :)
> > >
> > > Using the 'f' prefix allows us to borrow code from the current
> > > Xerces implementation with less changes. The prefix could be
> > > anything to avoid the following situations:
> > >
> > >   A) String name;
> > >      public void method() {
> > >          String name;
> > >          // long snippet of code here causes programmers
> > >          // to possibly reference the wrong variable in
> > >          // the next line
> > >          name = 'foo';
> > >      }
> > >
> > >   B) String name;
> > >      public void method() {
> > >          String name;
> > >          // the following is just ugly in my opinion
> > >          this.name = 'foo';
> > >      }
> > >
> > > Option B would be fine except that what does it matter whether
> > > I use "fName", "_name", or "this.name"? At least the first two
> > > save me 4 characters. This is just an opinion, though.
> > >
> > > 2) I don't like their if-else blocks. This is just personal
> > >    preference, though, but most code I see puts the else on the
> > >    next line. This is why I put that in our coding conventions.
> > >
> > > And like I said, people don't have to follow these coding
> > > conventions. They're just for people that are going to help
> > > contribute to the concept implementation.
> > >
> > > --
> > > Andy Clark * IBM, JTC - Silicon Valley * andyc@apache.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> > > For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> > For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
>
> --
> Brett McLaughlin, Enhydra Strategist
> Lutris Technologies, Inc.
> 1200 Pacific Avenue, Suite 300
> Santa Cruz, CA 95060 USA
> http://www.lutris.com
> http://www.enhydra.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
>
>


Mime
View raw message