Adam Bien's Weblog

Tuesday Nov 20, 2007

Month or MonthOfYear? - participate in the naming of the New Date and Time (JSR-310)!

The New Date And Time (JSR-310) targeted for JDK 1.7 will provide an object oriented - fluent API, in contrary to currently available java.util.Date and java.util.GregorianCalendar. However we are discussing now different naming options, which are summarized here. The first option is more consistent and uses a generic scheme (a context) for the naming of the classes. The second option is shorter, more fluent but not always consistent. So what do you prefer? Participate in the discussion and influence one of the core JDK 1.7-APIs!


[my tweets]  Rss My book: Real World Java EE - Rethinking Best Practices

Kommentare:

I think I prefer the second option becasue the names are shorter. But an important thing missing from this discussion is the arguments, in January month=0 or month=1, is year 2007 or 107 (to denote 2007). Frankly, I have never understood why sensible defaults such as 1=january, 2007 = year 2007 etc. has never been enforced before. Also the whole clutter about 24 hour times where hours can be 0-23 or 1-24... this is really confusing, as eg. hour "16" you don't know if this is 4 pm or 3pm (depending on 0-23 or 1-24 hour format is used).

In conclusion, use sensible arguments and sensible defualts. I think this is far more important than the wording of the method names (now that the suggested alternatives are so closely related).

Dr. Kasper Graversen

Gesendet von kasper Graversen am November 21, 2007 at 01:36 PM CET #

JSR-310 will use January=1, December=12, year 2007=2007, and hours from 0 to 23.

Gesendet von Stephen Colebourne am November 21, 2007 at 04:03 PM CET #

Option 1 is very clear. Dr. Graversen, I think that clarity is much more important than brevity. In fact, I think that brevity is the least important attribute of any name in java.

Option 1 increases readability, understandability, and therefore reliability, and modifiability. Be shorter names hinder all of these software development goals.

Gesendet von Mike am November 21, 2007 at 05:09 PM CET #

I am for option 2 if DayOfMonth would be refactored to Day (if not than option 1).
If we are talking about seconds, minutes, days, month, years everyone has already the correct bounding unit in mind.

>JSR-310 will use January=1, December=12, year 2007=2007, and hours from 0 to 23.<
month are starting at 1 and hours at 0?
what about minutes and seconds or are hours the sole exception?

Gesendet von Michael Bien am November 21, 2007 at 07:40 PM CET #

Clarity is more important than brevity, but there's no need to go overboard. I'd go for option 2 as well, using 'Day' instead of 'DayOfMonth' and 'Weekday' instead of 'DayOfWeek'. Not sure that you need 'MinuteOfDay' since it's easily calculated (hour * 60 + minute) and probably not often required. Likewise HourOfMeridiem. If you want to include every conceivable option, you'll need a boolean (or an enum if you prefer) specifying the meridiem.

Gesendet von Andy am November 22, 2007 at 05:29 PM CET #

I think Option2 is the more direct than going on being redundant in the explanation of names for second minute, etc.

Gesendet von sujal am February 27, 2008 at 01:22 PM CET #

Senden Sie einen Kommentar:
  • HTML Syntax: Ausgeschaltet
Meta-stuff / Interviews
My Recent Book
Java One 2009
CommunityOne East N.Y.C
JavaONE 2008 Interview
Search
...the last 150 posts
...the last 10 comments
greenfire.dev.java.net
Links
my.netbeans.org
Visitors
License