[chef] RE: Re: attribute naming for Java attributes, snake_case or CamelCase?

[RUSSELL Scott < >]

Hi,
      I would tend to agree with Zac.   Being a sysadmin who does java, then 
I would tend to be looking for Xmx, and not xmx. 

                                        Sc0tt...

_______________________________________
From: Zac Stevens 

 
Sent: 12 April 2012 13:33
To: 

 
Subject: [chef] Re: attribute naming for Java attributes, snake_case or 
CamelCase?

Hiya,

I'd like to argue the other position :)

On Thu, Apr 12, 2012 at 8:51 AM, Bryan Berry 
<
 >
 wrote:
> Java stuff all uses CamelCase while ruby uses snake_case
>
> tomcat "liferay" do
>   jvm do
>     Xms '256m'
>     Xmx '512m'
>     MaxPermSize '256m'
>   end
> end
>
> Should the attributes be named  MaxPermSize or max_perm_size?  Even harder,
> Xmx or xmx  (max jvm heap size)?

I'd suggest sticking with the naming in your example - ie, they should
match the options passed to Java.

Rationale: the DSL should match the expectations of the user.

While this generally calls for consistency, in this case I'd argue
that a user looking to specify the MaxPermSize option will expect the
attribute to be called MaxPermSize.  Requiring max_perm_size for the
sake of consistency means that the user will need to refer to the
documentation to translate  terms from the domain of the software
they're configuring (Java) into the domain of the tool they're using
to do so (Chef).

On the other hand, if your "jvm" block has other attributes which
_don't_ correspond directly to Java options, I'd use snake case for
them.  Keeping everything consistent may be more confusing, as the
user couldn't reliably infer whether an attribute directly controlled
a Java option, or whether there was some other behaviour they needed
to be aware of.  In other words, inappropriate consistency can make it
more difficult for the user to form a mental model on which to work.

There's no right or wrong answer to your question.  Imagine a typical
user of your DSL, and ask yourself what would be least surprising.


Zac