Adam Bien's Weblog

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!


NEW workshop: HTML 5 and JavaScript Essentials, Three days in April 2017: from Java EE 7 Architectures over Microservices to Performance, Troubleshooting and Monitoring
On demand workshops: Java EE 7: Bootstrap, Effective, Testing and Microservices available for streaming.

Newsletter: airhacks.news

A book about rethinking Java EE Patterns

Comments:

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

Posted by kasper Graversen on November 21, 2007 at 02:36 PM CET #

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

Posted by Stephen Colebourne on November 21, 2007 at 05: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.

Posted by Mike on November 21, 2007 at 06: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?

Posted by Michael Bien on November 21, 2007 at 08: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.

Posted by Andy on November 22, 2007 at 06:29 PM CET #

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

Posted by sujal on February 27, 2008 at 02:22 PM CET #

Post a Comment:
  • HTML Syntax: NOT allowed
realworldpatterns.com
Online Workshops
...the last 150 posts
...the last 10 comments
License