Save-Point
CamelCasing a Constant: Acceptable Practice? - Printable Version

+- Save-Point (https://www.save-point.org)
+-- Forum: Games Development (https://www.save-point.org/forum-4.html)
+--- Forum: Code Support (https://www.save-point.org/forum-20.html)
+--- Thread: CamelCasing a Constant: Acceptable Practice? (/thread-736.html)

CamelCasing a Constant: Acceptable Practice? - PK8 - 02-17-2010

I guess this is more of a general ruby question. So I've wrote a couple of scripts, and I can't believe this little thought hasn't hit me in the head until now... I think. But I'd like to hear it from the scripters. Constants can be CamelCased but should they? Is it an acceptable practice to CamelCase a Constant/use lowercase letters in Constants?

Edit: Wikipedia on CamelCase
Edit 2: If anyone feels it's more of a discussion thread than a support thread, feel free to report it/move it over.

CamelCasing a Constant: Acceptable Practice? - Jaberwocky - 02-17-2010

It's all up to preference.
Calling a constant FrenchFriedPotatoes doesn't tell you any more or less about it than calling it FRENCHFRIEDPOTATOES.
It might make it a bit easier to read, but it's really not a huge issue >.>

CamelCasing a Constant: Acceptable Practice? - vgvgf - 02-17-2010

As general rule all constants are written in upper case in almost all languages. If you are working with rmxp/rmvx scripts, and if you take into account that class names are constants in ruby, you should use: This_Is_A_Constant. However there are some constants in rgss/2 that are written in uppercase, like Input::SHIFT and else.
If you are working with some existing library or codes, you should addapt your code to match these library coding standard. If you aren't, create your own, but make it readable and mantain it constant.

CamelCasing a Constant: Acceptable Practice? - kyonides - 02-17-2010

Well, since I've been searching for pure ruby scripts and I joined #ruby-lang channel at freenode.net I think, the comments I can now recall make me think that in Ruby there are many "flavors" when talking about how to deal with syntax in a few aspects but one thing I'd like to mention is that Constants are supposed to be written in CamelCase or be capitalized only (Capitalized) if you're using the Constant as a class or module name. For any other purposes they're supposed to be written all in uppercase. They say it'd distinguish the use or purpose those Constants have...

One thing I only found in RGSS(2) but never in pure Ruby was the underscore. Really, I've downloaded RB files, installed Ruby Gems, etc. and I've never seen a single Constant written with an underscore in between (especially if used as a class or module name). There are some basic programming books based on Ruby saying you should never use underscore, others just ignore that the underscore even exist... except for naming methods with def end... That makes me think that Constants like This_Is_A_Constant can only be found if the scripter is someone who usually codes or works in C or any of its variants.

CamelCasing a Constant: Acceptable Practice? - Zeriab - 02-18-2010

Well put kyonides ^_^
You use underscore for upper case constants:

ThisIsAConstant
THIS_IS_A_CONSTANT

It is not convention to use This_Is_A_Constant nor THISISACONSTANT
The underscore is not needed since the CamelCasing tells you where the spaces are.
Variables and methods are lowercase.

*hugs*

CamelCasing a Constant: Acceptable Practice? - kyonides - 02-18-2010

"...methods are lowercase."

Eh... not always, check Math::PI and Math.PI, they're the same thing, possibly it's because they defined a method like this

Code:
module Anything
  def self.Mymethod
    puts 'Who cares?'
  end
end

This is a working scriptlet... It's related with triangle sides.

Code:
class TriangleError < StandardError
  def to_s; 'Wrong lengths for sides' end
end

def triangle(a, b, c)
  raise TriangleError unless TriangleSideLengthsValid?(a,b,c)
  return puts :equilateral if [a,b,c].uniq.length==1 # all sides are equal
  return puts :isosceles   if [a,b,c].uniq.length==2 # 2 sides are equal
  return puts :scalene     if [a,b,c].uniq.length==3 # no sides are equal
end

def TriangleSideLengthsValid?(a,b,c)
  ax,bx,cx=[a,b,c].sort
  return (ax+bx)>cx
end

In this example...

triangle(20,20,35) #=> isosceles

...would belong to the Object class (or BasicObject class if you prefer in Ruby 1.9.1) for those newbies who didn't know about this.

CamelCasing a Constant: Acceptable Practice? - Zeriab - 02-18-2010

I completely forgot to mention RGSS convention for class. Underscores are used for grouping.

Game_XXX
Sprite_XXX
Window_XXX

The XXX's are camel case. E.g. Window_EquipLeft.

@kyonides:
I was talking about conventions not what's possible, sorry if I wasn't clear on that.

Note that in RMXP:
Code:
p Math.PI #=> NoMethodError raised
You also get a NoMethodError in Ruby 1.8.6.

There can easily be cases where it makes sense to break the conventions. ^^

*hugs*

CamelCasing a Constant: Acceptable Practice? - kyonides - 02-19-2010

Right... I forgot that someone might have created that method like this...

Code:
module Math
  def self.PI; PI end
end

I know it was about conventions but since RGSS "convention" of using underscores like the ones you posted there is breaking Ruby conventions... and since that was the case, the triangle methods could show you all another thing you might have missed while scripting for the last few years. This also means Ruby is quite flexible even if talking about conventions...

That makes me recall another thing... When you have a very short method in Ruby you should actually write it like I did with that Math.PI method.

CamelCasing a Constant: Acceptable Practice? - Zeriab - 02-19-2010

Ruby is very dynamic even allowing idiocity like this:
Code:
def true.hello_world
  p "Hello World!"
end

def true.==(other)
  true
end

true.hello_world
p true == false

There can easily be situations where it makes sense to break the convention.
Lemme show you one percularity of using methods which starts with an upper case:
Code:
def Hello?
  p 'Hi'
end

def DIE!
  p 'dies'
end

def Happy(ans = true)
  p ans ? 'good for you' : "d'awww"
end

def SomeMethod
  p 'Yeah!'
end
  
Hello?
DIE!
Happy(true)
Happy(false)
self.SomeMethod
SomeMethod #=> NameError - uninitialized constant

I would heavily advice against having CamelCase methods unless they return a class since it would be the root of confusion.
I would call it a practice which in general leads to less managable code with higher chance of errors being present.

While your Math.PI method is useless if it stands alone it will make perfect sense if you could control the accuracy. I.e. how many decimals you want to get. Of course it won't really be a constant anymore, but conceptually keeping it as a constant may not be so bad an idea.
Thanks for mentioning the opportunities anyway. I may not have known them ^_^

*hugs*