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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
