explorers’ club

Preface

While working on my current project, a coworker and I were discussing naming conventions. So I thought I would throw this out there for your intellectual consumption and maybe spit back some enlightenment, if you will please. This will be broken down into two sections/questions, the first dealing with instance names and the latter dealing with package naming conventions. I do realize this is a matter of personal preference however I would like to gather some input on what my fellow developers use and the pros/cons of those conventions.

Instance Naming Conventions

Coming from an old flash background I was of the school of thought that instance names would use a suffix-convention whereas let’s say a movieClip instance with a profile picture would be called something like “profilePicture_mc”, or a textField with info about a first name would be called “firstName_txt” or “firstName_tf”. That sounds great so far. I bet many are wondering why the hell this would even become a point of issue for me. The simple answer is I have OCD about things like this. The fact that half my projects might use one convention while the other half uses another would keep me awake at night in a cold sweat. Yes, I am that screwed up. But I digress…

My coworker suggested that since we are rebuilding much of our project from the ground up that we may try to take real advantage of the code hinting mechanisms in Flex Builder by switching up our naming convention. I, being a contractor/consultant, would generally capitulate on matters such as this, with the wisdom lying in that I may not be around in 3 months, he will and he should have the code as agreeable to him as much as possible.

His suggested naming convention entails a simple switch of prepending the class type before the context-specific name. So rather than “profile_img”, you would have “img_profile”. Though not semantically logical as the first system, it does leverage Flex’s code hinting in that all images would be grouped together when selecting the correct instance.

Anyway I wanted to toss that to the elder hounds of development for discussion.  It’s not as important to me as the next topic.

Package Naming Conventions

Here I stand at a crossroads in the further development of class libraries and applications. Generally my packaged libraries have the following generally accepted naming convention: com.jwopitz. followed by the typical model or controller or view sub-packages. The issue I have with this is I do own www.jwopitz.com’s domain name but really have no intention of using it for anything. Also for the level of detail I take in separating my packages out, this convention doesn’t lend itself to shorter full-class-pathnames.

So rather than using the subdomain.domain.top-lvl-domain package naming conventions I have started to mull over the idea of doing what adobe does which is basically technology.sub-package or whatever you want to call it. I’d like to have something more like: jwo.libName.sub-package or jwopitz.libName.sub-package much like flash.events or mx.core.  Here is an example of what I am dealing with currently

I started a lib called jwo_mediaCoreLib that has various interfaces and manager type classes.  Right now it has a class path appearing something like: com.jwopitz.managers.IPlaylistManagerClient.  This is great if isolated for use inside the swc.  But damned if it seems clean to use in some big application that has its own com.jwopitz.managers package.  I just don’t like how it meshes together.

Conclusion

Well after rambling on sometime about my obsessions and finally realizing I have WAY TOO MUCH TIME ON MY HANDS, I leave the topic of debate to your comments.  I would love some feedback on this.   Even if it is to berate me for being OC.

Thanks for listening to my thoughts