Subscribe in a readerUsing Simple, Useful Class Names
In a previous post I complained about developers using worthless names for Classes. A couple of people called me on the fact that I never really defined what a good name is or how I come up with them.
During the application design process I’ll typically do a little domain modeling. Each problem space usually already has its own terminology and concepts. This is where I get the bulk of the names I use for Classes. For example, at a bank you may find terms like Customer, Account and Interest.
There are also common names I use when implementing a pattern. These common names are almost always used in conjunction with a domain term. A couple of quick examples:
- CustomerFactory
- HttpAdapter
- SmtpAdapter
- AccountAdapter
This is not rocket science. As an object oriented developer I want to model a solution in terms of real world objects or at least concepts from the problem domain. Why would I call an Account a PiggyBank or a Customer a John? I wouldn’t. Would you? Try asking the project stakeholder to define withdrawal rules for a John getting some spending money from the PiggyBank.
xkcd Python Comics
The greatest webcomic talks about the greatest programming language.
Announcing PyOhio - A Rockin’ Mini-Conference
The official jazz:
PyOhio, the first annual Python programming mini-conference for Ohio and surrounding areas, will take place Saturday, July 26, in Columbus, OH.
The conference is free of charge. It will include scheduled talks, Lightning Talks, and unconference-style Open Spaces.
To get more information or to volunteer, see http://pyohio.org.
Class Naming Really Does Matter
Time and time again I see programmers making up nutball names for their domain objects. This makes it really hard to understand the code without diving in. I deal with a significant amount of code on a daily basis and if I had to read every line I’d be in big trouble.
Instead I prefer to look and the classnames and imports to get a good feel for what the code does and what the relationships are. Sure sometimes I have to dig into the initializer (init) of a class and maybe a method or two. But in general I really don’t need or want to read everything all of the time.
Package names are different. I don’t mind when it is not immediately obvious what a package does when reading the name. FefiFofum is a fine name for a package. But what if that were the class name? Is it a FIFO queue? Is it a simple data object? What a pain!
For the sanity of other programmers please use good names for your classes!
Update: I have another post that explains how I come up with good names.
Google App Engine Blows My Mind
It seems like every time Google releases a product it’s a game changer. Google App Engine is just another one of those products.
GAE allows a developer to easily write an application in Python and deploy it to a massively scalable infrastructure. It seems like a step up in both power and abstraction from Amazon’s Elastic Cloud.
With so many cool things included like Python, Django and Google’s persistence backend a short blog post like this can’t possibly due it justice. If anyone has the connections to hook me up with an account I’d like to do some experimenting and blog about it.
-
Connect To Me!
-
-
Recent Tweets
Blogroll
-
