On the fifth day, God decided the earth needed a class of birds that made a neat quacking noise and were cute with white feathers, orange webbed feet and rounded orange bill. God decided to call his new creation…Cute White Feathered with Orange Bill and Orange Webbed Feet Quacker.  God realized that this name was too awkward to speak out loud in conversation, too cumbersome to write and read, and just all around too unwieldy to work with.  God then recognized that this name was not a name at all, but a description.  So God, in his infinite wisdom, created a whole new name for his Cute White Feathered Orange Bill and Orange Webbed Feet Quacker, God called it… a duck.

I use the term duck when talking about a class that needs a new name either because its name is a description or just a concatenation of all the things it contains.  I can’t recall ever thinking more about ducks prior to working on one particular project at my office. It is either the mindset of one of the other developers or it may very well be the nature of the business.  I'm not sure, but either way I am constantly biting my tongue or carefully broaching the subject when I feel the need to rid the design of any Cute White Feathered with Orange Bill and Orange Webbed Feet Quackers.

So for the record and for bad memory, here are Joe’s class-naming guidelines:

• Name your class representing a thing the same name as the business stakeholders call that thing. We had an object called a MassEmailSendee for someone who we intended to send a mass email distribution to. We did not want to use the word Recipient because it implied the person received the email. What great analysis! However, as you can imagine, everyone from the developers to the end users referred to people who are supposed to get an email as a Recipient. We went back and changed the name.
• Do not name your class based on the data it contains. If the word Address did not exist, I would hope we would invent a duck instead of calling the class CStreetWithNumberCityStateAndZip.
• When you do have a class name that at conception is nothing more than the nouns that make it up or is more like a description than a name…
• Find out if it is an actual thing from your business people. They might be able to tell you that a CPersonOnTeam can be called a CPlayer, or a CRouteWithLocationsAndPath is called a CTrip
• Your stakeholders might also be able to tell you metaphors or slang being used to describe a complex item. For example in a scuba diving app you might have a class that represents lobsters that are below the legal size ( CLobsterOfIllegalSize). The stakeholders should be able to tell you that they are often called Crickets which makes for a much nicer name.
• See if you can remove any words that do not contribute to the name being unique. Library Check Out Card can be reduced to Library Card since there isn’t another kind of library card other than the “Check out” kind.  If ever there is one, you could rename the class, or just denote the exception on the new kind of card.
• Can you turn an abbreviation for the words into a pronounceable word? The class CLightAmplificationByStimulatedEmissionOfRadiation could be called CLaser. Documents Waiting for Administrative Approval could be called Dwaps.
• If you have a class that is the concatenation of nouns, write a description of the class and there is a good chance the name will spring from that. For example, true story believe it or not, but I once had a class called Organization Import Output Object Property Input Data Table Value (COrgImportOutputObjPropInputDataTblVal). When we started using the class and clarifying its purpose in life (the description) we realized it was an Object Property Mapping. The long name was a result of designing based on data as opposed to behavior or purpose in life.
• Modern IDEs make changing names simple.
• Unless you are developing a framework to be used by people and systems you have no contact with, do not be afraid of changing names when you realize a class has a poor name. 
• We should not get hung up on names during design since changing them later is not a big deal. Even the long descriptive names or noun-concatenation names could be used until the better name is realized.  Don’t forgo trying to come up with a name, but don’t get hung up on it while designing.
• It can be argued that by naming a class a Duck you make the meaning less clear to someone as they now don’t know the details. Well, that’s what abstraction is all about.  We don't want to mislead them with the name, but we also purposely don't want to bother them with the details. When the user of the class is interested in the details they can look behind the scenes. When the user is interested in the class as it relates to other classes then the smaller “duck” name is priceless.
• Using abbreviations makes the length of a class name shorter, but not any more intelligible. Your brain deals with the same Cute White Feathered with Orange Bill and Orange Webbed Feet Quacker regardless of whether you call it that, or CuteWhtFthrdOrOrgBillOrgWbdFtQckr
• Researchers have done lots of studies on the number of things we can remember at once in our “working memory”.  It varies for different people but in general it seems to be about 4 to 7.  A class called WhiteTailedBuckedToothBeast only takes up 3 to 6 of our memory slots depending on how your brain handles the compound words, so when we are only looking at that one class it is not too awful. However, when working with a few classes all named like this then our thinking gets jumbled as our brain tackles the 20 or so nouns floating around. Call the WhiteTailedBuckedToothBeast a Rabbit.
• By using Namespaces in .Net (Packages in Java) we can organize our code in such a way that object names can be made shorter. Let's say I have an ImportWidgetControlThing and a MaintenanceWidgetControlThing. If Import and Maintenance are subsytems that we organize with Namespaces then I should be able to name them both WidgetControlThing without the preface. This only becomes an issue if the same code deals with both.

In a previous post (Three U's of Design Debates) I had written about how we (especially me) need to make sure we don’t get trapped in a design debate where the requirements are Unclear, the scope of the conversation is Undefined, and or Underlying opinions are not accepted. I am continually amazed that every developer does not read my blog, ok so maybe that’s not so amazing. However, I am truly amazed how prevalent another U of design debates is ignored when reading blogs or help forums and people argue about design: Unrecognized environmental factors. I decided, as a reminder to myself mostly, to append these to my previous article. Click here to read about Unrecognized environmental factors.

For what its worth, here are the books I have read the first half of this year and my humble opinions on their content.

• Object Models: Strategies, Patterns, and Applications
• Manage It!
• Object-Oriented Program Design: With Examples in C++
• Prefactoring: Extreme Abstraction, Extreme Separation, and Extreme Readability
• Building Object Applications that Work

Object Models: Strategies, Patterns, and Applications

Peter Coad

I was not planning to read this old book until I noticed its structure. The book is made up of a bunch of examples of domains and the models and thinking behind those models to represent each one. Pretty cool. It also starts off with some quotes reflecting this idea. E.G. Latin Proverb: The example educates. And another anonymous line: Educate right at the moment someone can apply it with success.

I love those two lines.

This is an older book and as can be imagined had no earth shattering realizations for me. However, when I read an older book on a topic I am very familiar with I am often just looking for a new slant on things or a hidden gem. In the end the 148 strategies listed for helping developers design a domain model may prove useful when stuck.

My favorite points from the book are:

• Data maintenance is high in volume low in content and pretty uninteresting. His point was to separate maintenance and business and to not bother writing use cases or scenarios for this stuff.
• Create a walk-able object model
• Don’t automate things just because you can

My least favorite points from the book are:

• Author’s model designs had highly mutable business objects
• Author does not objectify collections

Manage It!

By Johanna Rothman

Manage it is a solid project management book that I intend to use as a reference book when I have to manage a project that is in a different environment that I am in now. The author points out many drivers and constraints on a project and how we deal with them.

My favorite points from the book are:

• Don’t be afraid to create a project lifecycle specifically for your situation.
• Like any good book suggesting an agile approach the author stresses constant feed back through the entire process.

Prefactoring: Extreme Abstraction, extreme separation, and extreme readability

Ken Pugh

The book walks through the process of designing and implementing a CD rental system with an imaginary client. We get to read the author’s line of thinking as decisions are made. Often the reasons for the decisions tie into a development guideline that the author reproduces in an appendix in the back of the book. There is nothing too groundbreaking in the guidelines; however I don’t think I wholeheartedly disagreed with any of them. The idea behind prefactoring is that there are certain guidelines you follow to keep you from having to refactor later.  Some were even favorites that I like to advocate like: don’t describe data with primitive data types, user the client’s language in code, separate policy and implementation, etc.

I would recommend this book to younger developers who have not done anything or very little with object designs. I think most developers who have already spent a few years trying to adapt object-oriented concepts to their business applications will have already developed their own matching list of guidelines.

Object-Oriented Program Design: With Examples in C++

 Mark Mullin

Because I just can’t seem to read enough OOP books.

Not necessarily recommended unless you are a geek like me who can’t seem to get enough different views on OO programming, or possibly if you are an old school C programmer who never moved to C++.

Most interesting point was that the author objectified subsystems. It looked odd at first, but I soon realized that his subsystems were my application services. The author’s Database object would essentially be the combination of factories and a data access layer.

Building Object Applications that Work

Scott Ambler

This half year I have read 5 books, 3 of which had to do with OO development. I have to ask myself why I keep reading OO books.  I am not so naïve as to be looking for a silver bullet OO technique, and none of the past 3 or 4 OO books have shifted my way of thinking. So, I guess I am still trying to formulate and document my own personal best-approach to OO development and the common business application. I am not sure I am completely satisfied with my approach and not sure I fully understand other’s approaches. However, this book has been on my wish list for awhile and a cheap user version finally showed up on Amazon.

Like many older OO books it stressed all the same things that have been repackaged lately with new cool names: iterative development (Agile), on going testing (TDD), user and business language (Domain Driven Design), etc.

My absolute favorite line out of the book it one that I have never articulated as clear as this book. Many developers are out there right now creating tomorrow’s legacy applications.  Amen. The reason I read so much and write so much about what I read and thoroughly think through my design choices is because I don’t want to be writing tomorrow’s legacy application. In 5 years I don’t want another developer looking at my code to decide to just start from scratch. Rather I want them to be able to easily maintain and extend my application.  Even if it means rewriting just a component, layer or even tier. But what I think is most common are developers just starting over.

Compilers don’t refactor, extend, and debug code. People do.  I doubt you can find a single book written on software development guidelines that does not sate in one way or another that you should write software for people, not computers. No matter how ugly you make your code, if it is technically correct, the compiler will be able to read it. However, what should be of great concern to you is that the person who will maintain your code needs to be able to quickly read and understand your code. That person, often referred to as “the next guy” might very well be you. If you have ever looked at code you had written a year ago, or even 3 weeks ago then you know that it might as well have been written by someone else.  Make your code as readable as possible for the next guy!

I thought this was a universal truth that everyone followed, but on a continual basis I see that it is not. When reading through code I often have to translate what is written into English when I shouldn’t have to. Granted there might be some gray area between what is readable to you and what is readable to me, but seriously folks, the languages you are writing in allow you to speak near-English, please do so! I know many developers including myself have developed disdain for Visual Basic and its culture, but you have to hand it to the language designers, it is easy to read.

When writing code it is very useful to remove operators and replace them with English when possible. Sometimes this is for English-ness, other times it is just good OO encapsulation. It should darn near always be done for publicly-callable code.

//If the collection is empty then…

if (myCollection.Count == 0)

Replace with

if (myCollection.IsEmpty)

//If the collection has any items then…

if (myCollection.Count > 0)

Replace with

if (myCollection.IsNotEmpty)

or

if (myCollection.HasItems)

No translation or comments are needed

Some coding shortcuts remove the English to create functionally equivalent but more compact code.

int ValueToUse = UserEntered >= MinValue ? UserEntered: MinValue

Instead of     

int ValueToUse

if UserEntered >= MinValue then

     ValueToUse = UserEntered

else

     ValueToUse = MinValue

Or a little more compact

int ValueToUse = MinValue

if UserEntered >= MinValue then

     ValueToUse = UserEntered

I would argue the second code blocks are much easier to read while scanning code to understand functionality. There is no translation. The ternary code might look cool, but the coder looks foolish.

The only excuse for hard-to-read code is when it is an accepted convention among a development team or department. For example, often a group might decide that i can be used as a variable for a simple counter in a loop, or that ex can be used for exception in all the standard error handling routines, etc. Standard acronyms might be used that have no place outside the domain but are readable in the application’s context.  Even the ternary operator can be excused under the right circumstances, but clearly should not be used on a normal basis.

I might add this to my list of interview questions when trying to get a glimpse into a candidate’s development psyche. “Tell me your feelings about object-oriented development, auto numbers, data binding, comments, programming certifications, error handling, and ternary operators.”