Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2004-10-21 09:28:08
|
I've just noticed that we're slightly inconsistent in our naming for = getters that return boolean bean properties. Most of them are called = "isXxx", but 9 of them in the entire codebase are called "getXxx". We should find a consistent rule here. For example, should we prefer = "isProxyTargetClass" or "getProxyTargetClass"? Neither is nice English, = so I guess it's more about a convention then about nice method names. I tend to prefer the "isXxx" versions for all boolean properties. That = would also be easier in terms of affected classes, as we just have 9 = accessors that do not conform to that rule (i.e. 9 to be deprecated). On the other hand, "getXxx" might result in slightly nicer English in = some boolean cases... Opinions? Juergen |
|
From: Rod J. <ro...@in...> - 2004-10-21 12:16:37
|
Probably best to standardize on isXxx(). R jürgen höller [werk3AT] wrote: > I've just noticed that we're slightly inconsistent in our naming for getters that return boolean bean properties. Most of them are called "isXxx", but 9 of them in the entire codebase are called "getXxx". > > We should find a consistent rule here. For example, should we prefer "isProxyTargetClass" or "getProxyTargetClass"? Neither is nice English, so I guess it's more about a convention then about nice method names. > > I tend to prefer the "isXxx" versions for all boolean properties. That would also be easier in terms of affected classes, as we just have 9 accessors that do not conform to that rule (i.e. 9 to be deprecated). > > On the other hand, "getXxx" might result in slightly nicer English in some boolean cases... > > Opinions? > > Juergen > > |
|
From: Colin S. <col...@ex...> - 2004-10-21 12:33:58
|
I personally don't get that hung up about it. Both or equally valid forms (and recognized by JavaBeans tools and the like), and the reality is that sometimes you have a word which sounds horrible with is and ok with get, or vice-versa. On the other hand, if they sound ok both ways then there's nothing wrong with trying to be consistent. jürgen höller [werk3AT] wrote: >I've just noticed that we're slightly inconsistent in our naming for getters that return boolean bean properties. Most of them are called "isXxx", but 9 of them in the entire codebase are called "getXxx". > >We should find a consistent rule here. For example, should we prefer "isProxyTargetClass" or "getProxyTargetClass"? Neither is nice English, so I guess it's more about a convention then about nice method names. > >I tend to prefer the "isXxx" versions for all boolean properties. That would also be easier in terms of affected classes, as we just have 9 accessors that do not conform to that rule (i.e. 9 to be deprecated). > >On the other hand, "getXxx" might result in slightly nicer English in some boolean cases... > >Opinions? > >Juergen > > |
|
From: Rod J. <ro...@in...> - 2004-10-21 14:50:00
|
Can't say it bothers me either. I guess I choose between the two based on euphony also. But I have no issue with standardization, as it involves only deprecation at this point. R Colin Sampaleanu wrote: > I personally don't get that hung up about it. Both or equally valid > forms (and recognized by JavaBeans tools and the like), and the reality > is that sometimes you have a word which sounds horrible with is and ok > with get, or vice-versa. On the other hand, if they sound ok both ways > then there's nothing wrong with trying to be consistent. > > > jürgen höller [werk3AT] wrote: > >> I've just noticed that we're slightly inconsistent in our naming for >> getters that return boolean bean properties. Most of them are called >> "isXxx", but 9 of them in the entire codebase are called "getXxx". >> >> We should find a consistent rule here. For example, should we prefer >> "isProxyTargetClass" or "getProxyTargetClass"? Neither is nice >> English, so I guess it's more about a convention then about nice >> method names. >> >> I tend to prefer the "isXxx" versions for all boolean properties. That >> would also be easier in terms of affected classes, as we just have 9 >> accessors that do not conform to that rule (i.e. 9 to be deprecated). >> >> On the other hand, "getXxx" might result in slightly nicer English in >> some boolean cases... >> >> Opinions? >> >> Juergen >> >> > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: Dmitriy K. <dko...@ru...> - 2004-10-21 13:15:29
|
My 2c. I've always used isXxx() convention. +1 for isXxx() Regards, Dmitriy. Rod Johnson wrote: > Probably best to standardize on isXxx(). > > R > > jürgen höller [werk3AT] wrote: > >> I've just noticed that we're slightly inconsistent in our naming for >> getters that return boolean bean properties. Most of them are called >> "isXxx", but 9 of them in the entire codebase are called "getXxx". >> >> We should find a consistent rule here. For example, should we prefer >> "isProxyTargetClass" or "getProxyTargetClass"? Neither is nice >> English, so I guess it's more about a convention then about nice >> method names. >> >> I tend to prefer the "isXxx" versions for all boolean properties. >> That would also be easier in terms of affected classes, as we just >> have 9 accessors that do not conform to that rule (i.e. 9 to be >> deprecated). >> >> On the other hand, "getXxx" might result in slightly nicer English in >> some boolean cases... >> >> Opinions? >> >> Juergen >> >> > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out > more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Keith D. <kd...@cs...> - 2004-10-21 13:55:06
|
My 2c... I think it's better to use what is clearest on a case by case basis. Good names (those that are clear but not too wordy) are very important. Generally the isXxx variation should is the most readable IMO anyway, but sometimes isXxx just doesn't fit. Keith -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf = Of j=FCrgen h=F6ller [werk3AT] Sent: Thursday, October 21, 2004 11:30 AM To: spr...@li... Subject: [Springframework-developer] isXxx/getXxx for boolean properties I've just noticed that we're slightly inconsistent in our naming for = getters that return boolean bean properties. Most of them are called "isXxx", = but 9 of them in the entire codebase are called "getXxx". We should find a consistent rule here. For example, should we prefer "isProxyTargetClass" or "getProxyTargetClass"? Neither is nice English, = so I guess it's more about a convention then about nice method names. I tend to prefer the "isXxx" versions for all boolean properties. That = would also be easier in terms of affected classes, as we just have 9 accessors that do not conform to that rule (i.e. 9 to be deprecated). On the other hand, "getXxx" might result in slightly nicer English in = some boolean cases... Opinions? Juergen ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give = us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out = more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
