coding conventions : getUrl vs getURL

[Rod Widdowson]

This seems to have gone quiet.

 

Is this something for Friday? Or can we just get the agreement  mirrored
into the wiki?

 

From: dev-bounces at shibboleth.net [mailto:dev-bounces at shibboleth.net] On
Behalf Of Daniel Fisher
Sent: 12 March 2013 14:13
To: Shib Dev
Subject: Re: coding conventions : getUrl vs getURL

 

On Mon, Mar 11, 2013 at 10:39 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

Since you asked...


On 3/11/13 10:33 PM, "Tom Zeller" <tzeller at dragonacea.biz> wrote:

>How about :
>
>a) getUrl or getURL

I favor getURL on the basis that the acronym is URL, not Url. As is SAML,
not Saml, SOAP not Soap, etc. I prefer to call things what they are than
try and remember to call them something else.

A lesser consideration is the preponderance of existing code, but I know
some of the OpenSAML stuff has also changed in v3 already, so there's
probably work either way.

 

 

I've never found total consistency even in my own projects when it comes to
acronyms. There is always some exception to the rule. For instance, take the
method getLDAPURL. Two acronyms smashed together. Most coders would employ
some sort of camel casing here, but what should it be? getLdapURL,
getLDAPUrl, getLdapUrl ? I lean towards the first example, which is why my
rule is generally, use upper case acronyms if they come at the end. That
said, I've still broken this rule when I think the name looks better in some
other form. I guess my advice would be have a rule of thumb, but always use
your judgement and don't sweat it.

 

>b) apply convention to new files only or new files and existing
>

 

I would note that changing file name case in svn is a pain.

 

>c) convention may be project specific

I favor consistency, and I think we need to avoid project specific rules
because for a period of time we may be moving code back and forth.

 

I'll echo everyone else, consistency matters more than the actual rules. 

 

--Daniel Fisher

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20130320/232d778d/attachment.html