commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <p...@steitz.com>
Subject Re: [uid] Uuid
Date Sun, 04 Jan 2004 05:32:24 GMT
Tim Reilly wrote:
> I had few questions about the Uuid code and/or coding conventions:
> First, sorry to be a newbie, but I'm seeing the
> $Header tags $Header:...$ and @version $Revision: ... $ tags.
> They look like xdoclet tags perhaps, are they something a contributor should
> be adding, or is this something committers add prior to a commit? If
> contributor's should be maintaining prior to sending patches, what is the
> convention for updating the version? For example sending a patch for
> something that has version 1.1 I assume should be changed to 1.2? When or
> what determines a major version/revision 2.0?

These things get expanded by CVS when revisions get checked in. Here is a 
good general resource on CVS:

http://cvsbook.red-bean.com/cvsbook.html

Add #Keyword_Substitution__RCS_Keywords_ to the end of the URL above for 
the section on keyword substitution.

When adding new files, it is nice to put the $Revision$, $Id$ and/or 
$Header$ tags in to match the style of the surrounding code.  Don't worry 
about extra cruft already there in these tags, CVS will update when the 
source is checked in.

> 
> Second, I had some questions about the level of compliance with the
> checkstyle checks:
> I'm adding some code I normally wouldn't so that checkstyle checks pass, but
> I'm wondering if I should be doing these things (what is the expected
> checkstyle compliance?)
> 

What we should try to do is to decide on a set of checks that we are 
comfortable with and modify checkstyle.xml accordingly.  This project is 
new, so now is a good time to discuss this kind of thing (hopefully 
without getting too bogged down).

> For instance:
> To avoid magic numbers
> I changed
> {
> 	buf.insert(8, '-');
> 	buf.insert(13, '-');
> 	buf.insert(18, '-');
> 	buf.insert(23, '-');
> }
> -- to --
> public static final int TOKENS_IN_UUID = 5;
> private static final int[] FORMAT_POSITIONS = {8, 13, 18, 23};
> ...
>  for (int i = 0; i < TOKENS_IN_UUID - 1; i++) {
>                 buf.insert(FORMAT_POSITIONS[i], '-');
>             }
> but the first way seems more efficient to me.

I personally do not like having numbers other than -1, 0, 1, 2 floating 
around in code.  That's what constant definitions are for.  Of course, 
there are always exceptions.  If the "magic numbers" appear in only one 
place, for example.  In the situation above, I would probably have named 
each of the contants (unless their use could be localized to only a small 
number of occurrences, in which case I might view this as an exception).

I would not be opposed to removing the "magic numbers" check if others 
don't like it.

> ----
> Also to avoid "Definition of equals with corresponding definition of
> hashCode" warning I've added: --------
> 
> /** @see java.lang.Object#hashCode() */
>  public int hashCode() {
>     return super.hashCode();
>  }

I need more info to understand what is going on here.

> 
> Third, based on some previous discussions on this list, I think Sun
> convention is to use the UUID naming instead of Uuid. Should these be
> renamed?

That is a good question.  The fact is that Sun (and everyone else) is 
inconsistent on this.  I am +1 for renaming, but interested in others' 
opinions.

Phil
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message