Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have created an ObjectParser class which parses data into strongly typed objects using an IObjectParserDataSource as the data source (the data could be an Excel file, text file, array, query string, etc).

Examples of my implementations of IObjectParserDataSource are:

  • TextFileObjectParserDataSource
  • ExcelFileObjectParserDataSource

These class names feel really long and convoluted to me.

I could name them:

  • TextFileDataSource
  • ExcelFileDataSource

But this introduces a level of ambiguity and they don't became as clearly related to IObjectParserDataSource at first glance. This becomes important because defining these data sources will happen in client code and I wish to minimize potential confusion and uncertainty.

How would you name these classes in such a scenario?

share|improve this question
I don't think your current names are too long and convoluted. – AakashM Apr 22 '13 at 16:07
I'm throwing this idea out there, but I don't recommend it: If you use the same string (such as "ObjectParserDataSource") a lot in your naming, acronym it. ExcelFileOPDS, TextFileOPDS. It saves a bit on typing and screen space, but it's opaque to someone who isn't familiar with the code. – Bobson Apr 22 '13 at 18:03
up vote 22 down vote accepted

I generally try to get around this problem by sticking all similar objects into one namespace and simplifying their names (if I can do it).

For example, would have

namespace ObjectParserDataSources
|-> class TextFileSource
|-> class ExcelFileSource

Or, if the collection of objects working with/servicing ObjectParser becomes large enough, I'd make a separate folder tree or project devoted just to ObjectParser:

namespace ObjectParser
|-> class ObjectParser
|-> interface IObjectParserDataSource
|-> namespace DataSources
|   |
|   |-> class TextFileSource
|   |-> class ExcelFileSource
|-> other stuff...

Within any given file, the import statements and the code context would usually make it pretty clear that TextFileSource is the ObjectParser data source. If there are multiple similarly named classes in the same piece of code, you can refer to TextFileSource by its full name:

var parserSource = new ObjectParser.DataSources.TextFileSource(/*...*/);

It usually occurs very rarely and I don't mind typing out extra few words.

share|improve this answer
You saved me the time of typing out that same answer :) – Michael Brown Apr 22 '13 at 16:46
+1. This solution improves readability without reducing clarity. – John Cartwright Apr 23 '13 at 5:20

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.