MDBitz Development Resources

Taking a break from diving into further details of Classes and Objects, I have detoured into taking a closer look at some of the naming conventions that are used in the Ruby programming language. In particular we are going to look at Constants and local, global, instance, and class variables.

Constants

In Ruby you define a constant by having it start with an uppercase character. Yes, it is that simple if you want a constant whether at the class level or on the procedural level simply start your naming with an upper case character and it is defined as a constant.

SecretNum = 13987
 
class ConstantClass
    Pass = "PASS"
    Fail = "FAIL"
end

To access the constants of a class you would simply type {ClassName::ConstantName} while non class constants are simply called like a variable.

puts SecretNum
puts ConstantClass::Pass

However as it turns out Ruby let’s you reassign the value of defined constants at any time, yes they say that you should only assign a value to it once but they let you change it. Why would you use these “constants” if they can be changed at any time? The second strange thing is that if you have a Constant defined Ruby still lets you define a method with the same name.

def SecretNum()
  puts 666
end

Now you have both a constant and a method with the same name. Where if you leave out the parenthesis the Constant is used by if you add them the method is called.

puts SecretNum    // outputs 13987
puts SecretNum() // outputs 666

Again why? Needless to say it is good practice to name your methods starting with a lower case, but if you are defining your language so that Capitals are reserved for defining constants you should enforce that either methods all start with a lowercase character or that a constant with the same name doesn’t exist.

Variables

Variables are identified by their first and or second character, in which they define the scope of where it can be utilized.

Global Variables

Global Variables are identified by starting with the $ character. These variables can be set or read from anywhere within your program even in classes and methods.

$globVar = 8
puts $globVar  // outputs 8

Local Variables

A local variable is simply a named variable. It can be accessed anywhere in the current scope it was defined. If it is defined in a method it can only be used in that method.

def testMethod( var = "testing 1 2 3" )
    puts var
end

Instance Variables

An instance Variable has it’s scope confined to the object it belongs to and begins with the @ character. These can be accessed by methods belonging to the object or set and read by their name if they are defined as accessible.

class MyClass
    def doSomething( var ) 
        @something = var
    end
    def doSomethingElse( ) 
        puts @something
    end
end

Class Variables

Perhaps the most confusing of all variables is the Class Variable. These variables are recognized by their names starting with @@. These variables can be accessed by a class and its inheriting sub classes. So if you change the variables value in a sub class the base class’s value is also changed. I’m not going to go into any further detail on this as of this moment I do not see any reason why you would ever use a Class Variable as if you needed to I don’t see why you wouldn’t just use a constant.

Those are the basics on the Naming Convention used by Ruby to identify the scope of variables and constants. Pretty basic with a few strange twists added in, once again I find myself thinking that Ruby is popular simply because it lets you do pretty much whatever you want no matter how bad design and code wise it is. However i am trying very hard to keep an open mind and will reserve judgment until my crash course is finished.

When working in applications that utilize a lot of variables I often come across interfaces containing nothing but constants. Instead of creating a class containing the constants the developers choose to define them in an interface that can be implemented by a class so that constants don’t need to be qualified to a class in the code. This is so widespread that it has been termed the Constant Interface Antipattern. To ease users into correctly defining and using interfaces Java introduced Static Import in version 1.5.

To help illustrate why people choose to use interfaces to define constants lets have a look at an example. Lets assume we have defined our constants in the following interface MyConstants.

public interface MyConstants {
    public static final String PASS= "pass";
    public static final String FAIL = "fail";
}

To use the constants one would have their class implement the interface:

public class BadConstants implements MyConstants {
    private void outputResults() {
        System.out.println("FAIL Constant is " + FAIL);
        System.out.println("PASS Constant is " + PASS);
    }
}

As can be seen in the example the reason people prefer to use this method is that they do not have to qualify the constant by instead using:

System.out.println("FAIL Constant is " + MyConstants.FAIL);

To make it easier for coders to write good code Java introduced the Static Import feature in 1.5. What this does is allow us developers to import static properties into the current class’s namespace effectively allowing you to not qualify the constants. This is down by use of the import static statement where you can import a single constant or all constants of a class.

import static com.example.MyConstants.PASS;
import static com.example.MyConstants.*;

To put it simply don’t define constants in an interface, instead create them properly in their own classes and if you really don’t want to qualify them then utilize static import to import the constants into your class.

References

• Java Docs 1.5 – Static Import