The way we name our classes

simo — Fri, 01 Apr 2011 11:53:27 +0000

This minor detail has been haunting me for years. It’s not extremely significant, but really makes a difference with modern coding tools.

I’m talking about the code hinting that all decent coding tools have. It’s such a priceless feature, but for some reason I often see libs that don’t take advantage of it. Most libs are still coded in “clear English format”.

For example:

Let’s pretend for a second that you are coding as3 for the first time. You heard that there are filters, but you don’t know what sort. In this case you need to open your manual and see the filters-section and save the names of all filters into your already overloaded brains. Or at least the first words of them. This leads you to jump back and forward with the manual during your development. For example you would like to add a shadow to image. So you might try to type something like Shad and ask code hint for some guidance. What do you get? Shader this and that… Where’s the shadow filter??? After some clicking you find from your manual that the correct word is DropShadowFilter.

Instead all this could be solved with extremely simple naming solution = FilterShadowDrop. In this case you could just type Filter and the code hint would serve you a list of all filters at the lib and there could even be different sort of Shadows.

So the idea is to name your classes with type first method. Here’s an example of lib that contains Frisbee’s:

This is why I’ve named classes at evoCunningParticleEngine as follows:

And this is exactly why command-type classes are named with C-letter at front:

I don’t see why code should be clear English when instead it could be just clear code with good design patterns and named so that it’s intuitive to use. I can sure you that with this kind of naming the manual paddling will decrease fundamentally.

Or do you disagree? Am I missing something here?

I wish there would be no more constructor(params:Object)

simo — Wed, 12 Nov 2008 15:50:47 +0000

I hate this pattern and it’s very popular these days with as3 API’s:

package
{
publicclass AllMightyClass
{
publicvar _value0:String;
publicvar _value1:Array;
publicvar _value2:int;
publicvar _value3:Object;

publicfunction AllMightyClass(params:Object)
{

                        _value0 = params.value0;

                        _value1 = params.value1;

                        _value2 = params.value2;

                        _value3 = params.value3;
}
        }

}

// FROM OUTSIDE THIS WOULD LOOK LIKE:

var amclass:AllMightyClass = new AllMightyClass( 

//editor hints: AllMightyClass(params:Object)

Is this something that people use with some other language or something they learn at school?
It’s just wrong. The end user has no idea what params it wants or what’s their type.

Why not use:

package

{

        public class Test

        {

                public var value0:String;

                public var value1:Array;

                public var value2:int;

                public var value3:Object;

                public function Test(value0:String, value1:Array, value2:int, value3:Object)

                {

                        this.value0 = value0;

                        this.value1 = value1;

                        this.value2 = value2;

                        this.value3 = value3;

                }

        }

}

// FROM OUTSIDE THIS WOULD LOOK LIKE:

var amclass:AllMightyClass = new AllMightyClass( 

//editor hints: AllMightyClass(value0:String, value1:Array, value2:int, value3:Object)

You may still pass stuff to baseclass in object-format if you like and you may still check if some values are null and then turn them into default. With the first pattern API’s user need to open the class to see what parameters it swallows or even worse browse the documentation.

But there is even better way to do this:

// FIRST CREATE A VALUEOBJECT CLASS

package
{
publicclass AllMightyClassVO
{
publicvar value0:String;
publicvar value1:Array;
publicvar value2:int;
publicvar value3:Object;
publicfunction AllMightyClassVO(value0:String, value1:Array, value2:int, value3:Object)
{
this.value0 = value0;
this.value1 = value1;
this.value2 = value2;
this.value3 = value3;
}
}
}
// USE THAT TO PASS YOUR PARAMETERS

package 

{

        public class AllMightyClass

        {

                public var value0:String;

                public var value1:Array;

                public var value2:int;

                public var value3:Object;

                

                public function AllMightyClass(valueObject:AllMightyClassVO)

                {

                        this.value0 = valueObject.value0;

                        this.value1 = valueObject.value1;

                        this.value2 = valueObject.value2;

                        this.value3 = valueObject.value3;

                }

        }

}

// FROM OUTSIDE THIS WOULD LOOK LIKE:

var amclass:AllMightyClass = new AllMightyClass( 

//editor hints: AllMightyClass(valueObject:AllMightyClassVO)

// OK IT EATS AN OBJECT CALLED AllMightyClassVO (let’s write some more)

var amclass:AllMightyClass = new AllMightyClass(new AllMightyClassVO( 

//editor hints: AllMightyClassVO(value0:String, value1:Array, value2:int, value3:Object)

You can allways extend your VO class with some abstract when you want to pass it down to base classes. This way you make it look intuitive for end user.

simppa.fi/blog » design patterns

The way we name our classes

I wish there would be no more constructor(params:Object)