tag:blogger.com,1999:blog-741750605858169835.post7029365338920120194..comments2024-01-24T14:53:02.919+00:00Comments on Stephen Colebourne's blog: More Java prefixs and suffixesStephen Colebournehttp://www.blogger.com/profile/01454237967846880639noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-741750605858169835.post-75848427030478969292011-08-20T23:20:14.108+01:002011-08-20T23:20:14.108+01:00Bitsucker, I think that your explanation of why pr...Bitsucker, I think that your explanation of why prefix/suffix is excellent.<br /><br />On FooUtils, I find I mostly use it for interfaces these days, where there isn't necessarily an obvious alternative home for the method.Stephen Colebournehttps://www.blogger.com/profile/01454237967846880639noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-86698045205264971432011-08-19T17:49:02.811+01:002011-08-19T17:49:02.811+01:00Great topic, and good coverage, thank you, Stephen...Great topic, and good coverage, thank you, Stephen.<br /><br />@lumpynose: I advocate using both prefixes and suffixes as "name modifiers," but with a very clear heuristic to determine which is correct for a given type: a name prefix should generally be an adjective implying a "narrowing" or refinement in the specification of the role of the type (eg, BlueFoo). A prefixed Foo is a more specific kind of Foo. <br /><br />By this same rule, a name suffix isn't really a suffix at all, but instead implies a type whose role is RELATED to Foos in some manner (FooFactory, FooPrinter, BlueFooFrobbler). A suffixed Foo is NOT a Foo, but it operates on Foos somehow -- the "Foo" is actually a prefix. <br /><br />Adhering to this rule has the benefit of suggesting good names for variables of the given type: the developer (or, more often, his IDE) can just truncate prefixes from the front of the type name until arriving at the shortest possible name that uniquely identifies the variable's meaning: a BlueFoo variable may just be 'foo', or it may be blueFoo if a RedFoo is also in scope. (And when 'foo' isn't specific enough, context-specific adjectives can be prefixed on variable names as well: 'BlueFoo smallFoo') <br /><br />Similarly, the BlueFooFrobbler variable would likely just be named 'frobbler'. <br /><br />Finally, regarding FooUtils: I'd suggest that the need for such bundles of global functions is generally a bad smell; there's likely a natural refactoring that would lead to a non-static home for those methods. The only case where I find myself needing Utils any more is when dealing with third-party libs (eg, the JDK) which, unfortunately, cannot be extended in our draconian java type-system.bitsuckerhttps://www.blogger.com/profile/08606093667742884460noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-20384438822400677722011-08-19T09:33:00.137+01:002011-08-19T09:33:00.137+01:00Lumpynose, I don't think there is an inconsist...Lumpynose, I don't think there is an inconsistency here. There were two driving points in the recent blog - the overpowering colons and the problem of default params - which combine to make it less readable, particularly wrt the return type on the right. But the key point is readability. With all sensible type names, the letters in the name form a single visual blob, usually surrounded by spaces or other punctuation. So, picking out that something is a type, as opposed to a variable name or other syntactic element is relatively easy. The visual parsing of the type name itself is something where I always find I have to read the whole thing anyway, thus PrefixFoo and FooSuffix becomes a detail, which can be driven by other concerns.Stephen Colebournehttps://www.blogger.com/profile/01454237967846880639noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-92131563066778139912011-08-19T03:28:03.849+01:002011-08-19T03:28:03.849+01:00Steven, it seems to me that you're talking out...Steven, it seems to me that you're talking out of both sides of your mouth. Just recently you were taking Kotlin to task because of its "reversed" type declarations, and now you seem to be completely blase about these name modifiers being either at the end or at the beginning.<br /><br />So I think the first question to get out of the way, is, does it matter? I.e., should these name modifiers always be in one place or the other? My inclination is to have them at the beginning, but then FactoryFoo looks a bit weird. I think it's what some people commented about on your Kotlin entry; it's just something that you get used to after a while. Nevertheless, I am inclined to think that the name modifiers should all either go at the beginning or the end.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-78939623367104616412011-08-18T18:46:23.360+01:002011-08-18T18:46:23.360+01:00James, you are right about the meaning. I guess Pr...James, you are right about the meaning. I guess Proxy could be used in different ways - just generally a placeholder.<br /><br />Lawrence, FooUtils vs Foos is a tricky one, but I'm simply noting that most OSS projects I've seen choose FooUtils rather than Foos. I guess there is nothing rationale in that as an explanation, but there you go.Stephen Colebournehttps://www.blogger.com/profile/01454237967846880639noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-89627102929789358142011-08-18T17:45:41.471+01:002011-08-18T17:45:41.471+01:00Why is Foos JDK style but FooUtils non-JDK style? ...Why is Foos JDK style but FooUtils non-JDK style? Are you advocating in general that non-JDK authors stay away from JDK styles of naming? That doesn't seem right. Or do you just not like Foos? Or do you want to avoid Foos in case the JDK adds one later (like Strings or Files)?<br /><br />I always switch back and forth between FooUtils and FooUtil, though I can't defend the latter at the moment.Lawrence Kesteloothttps://www.blogger.com/profile/08175600004629340681noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-74468324937461827432011-08-18T15:58:25.123+01:002011-08-18T15:58:25.123+01:00FooProxy would have a different meaning in the net...FooProxy would have a different meaning in the networked world: there you would expect the FooProxy to implement Foo, but be doing RMI &c. inside of itself (thus implying network costs).<br /><br />If the intent is to denote lazy loading, perhaps LazyFoo would be a more direct convention?James Grahnnoreply@blogger.com