Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #36233 > unrolled thread

Re: Uppercase methods names

Back to article view | Back to comp.lang.java.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Uppercase methods names Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-01-31 08:14 -0500
    Re: Uppercase methods names Eric Douglas <e.d.programmer@gmail.com> - 2017-01-31 06:02 -0800
    Re: Uppercase methods names Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-01-31 12:40 -0500

#36233 — Re: Uppercase methods names

On 1/30/2017 8:36 PM, Stefan Ram wrote:
>   This is not mentioned in JLS 6.1, but are
>
> public static int java.awt.Color.HSBtoRGB(float,float,float)
> public static double java.lang.Math.IEEEremainder(double,double)
> public static float[] java.awt.Color.RGBtoHSB(int,int,int,float[])
> public static long java.util.Date.UTC(int,int,int,int,int,int)
> public static native double java.lang.StrictMath.IEEEremainder(double,double)
>
>   enough prior art to derive a rule:
>
>       »When a method name starts with an acronym that usually
>       is written in all-upperase, it is still written in
>       all-uppercase when it appears at the start of a method
>       name«?

     Why bother deriving a RULE!!! from the names of a mere six
methods, one of them deprecated?

     (I suppose there's precedent for RULE!!!-making on tiny
samples.  Long years ago I was required to memorize a RULE!!!
concerning Latin semi-deponent verbs whose direct objects took
the ablative rather than the accusative case; there were five
count them five such verbs.  I still feel that making a RULE!!!
in such cases is sub-optimal; call 'em "irregular" and move on.)

-- 
esosman@comcast-dot-net.invalid
Fourteen hundred fifty days to go.

[toc] | [next] | [standalone]

#36234

On Tuesday, January 31, 2017 at 8:14:56 AM UTC-5, Eric Sosman wrote:
>      Why bother deriving a RULE!!! from the names of a mere six
> methods, one of them deprecated?
> 
>      (I suppose there's precedent for RULE!!!-making on tiny
> samples.  Long years ago I was required to memorize a RULE!!!
> concerning Latin semi-deponent verbs whose direct objects took
> the ablative rather than the accusative case; there were five
> count them five such verbs.  I still feel that making a RULE!!!
> in such cases is sub-optimal; call 'em "irregular" and move on.)
> 

There is some made up "rule" about how to spell words in the English language called "i before e except after c", and quite a few words that violate this rule.

I don't like writing method names that include an acronym.  I don't think it looks right if the letters aren't upper case, and it isn't consistent if they're not.  I expect only static constants to be all upper case, so I would at least avoid starting the method name with the upper case.  HSBtoRGB?  How about convertHSBtoRGB?  Normally to would be To in camel case but between acronyms that would look confusing.

[toc] | [prev] | [next] | [standalone]

#36236

On 1/31/2017 8:14 AM, Eric Sosman wrote:
> On 1/30/2017 8:36 PM, Stefan Ram wrote:
>>   This is not mentioned in JLS 6.1, but are
>>
>> public static int java.awt.Color.HSBtoRGB(float,float,float)
>> public static double java.lang.Math.IEEEremainder(double,double)
>> public static float[] java.awt.Color.RGBtoHSB(int,int,int,float[])
>> public static long java.util.Date.UTC(int,int,int,int,int,int)
>> public static native double
>> java.lang.StrictMath.IEEEremainder(double,double)
>>
>>   enough prior art to derive a rule:
>>
>>       »When a method name starts with an acronym that usually
>>       is written in all-upperase, it is still written in
>>       all-uppercase when it appears at the start of a method
>>       name«?
>
>     Why bother deriving a RULE!!! from the names of a mere six
> methods, one of them deprecated?

     Just for fun, I wrote a little program to examine the method
names in Java 1.8.0_121's rt.jar.  Considering only the public and
protected methods of public classes and interfaces, there are 31941
methods of which ten have names beginning with an upper-case letter:

java.awt.GridBagLayout.AdjustForGravity
java.awt.GridBagLayout.ArrangeGrid
java.awt.GridBagLayout.GetLayoutInfo
java.awt.GridBagLayout.GetMinSize

-- These four are not actually deprecated, but are "obsolete and
supplied for backwards compatibility only."  Programmers are
encouraged to use initial-lower-case equivalents instead.

javax.swing.tree.DefaultTreeCellEditor$EditorContainer.EditorContainer

-- An oddity.  The JavaDoc for this method is completely empty, and
a comment in the source says "This should not be used."

java.awt.Color.HSBtoRGB
java.awt.Color.RGBtoHSB
java.util.Date.UTC
java.lang.Math.IEEEremainder
java.lang.StrictMath.IEEEremainder

-- These are the five (not six; I can't count) noted by Stefan.

     Summary: There are ten exceptions to the initial-lower-case
standard, amounting to thirty-one thousandths of one percent of
all public and protected method names.

     Summary II: A rule that explains only half of thirty-one
thousandths of one percent of cases is more trouble than it's
worth.  (IMHO, YMMV)

-- 
esosman@comcast-dot-net.invalid
Fourteen hundred fifty days to go.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web