Anyone else find naming classes and methods one of the most difficult parts in programming? [closed]

Answer 1

I stick to basics: VerbNoun(arguments). Examples: GetDoc(docID).

There's no need to get fancy. It will be easy to understand a year from now, whether it's you or someone else.

Answer 2

I have to agree that naming is an art. It gets a little easier if your class is following a certain "desigh pattern" (factory etc).

Answer 3

The language you use to describe the problem, is the language you should use for the variables, methods, objects, classes, etc. Loosely, nouns match objects and verbs match methods. If you're missing words to describe the problem, you're also missing a full understanding (specification) of the problem.

If it's just choosing between a set of names, then it should be driven by the conventions you are using to build the system. If you've come to a new spot, uncovered by previous conventions, then it's always worth spending some effort on trying extend them (properly, consistently) to cover this new case.

If in doubt, sleep on it, and pick the first most obvious name, the next morning :-)

If you wake up one day and realize you were wrong, then change it right away.

Paul.

BTW: Document.fetch() is pretty obvious.

Answer 4

Sometimes there isn't a good name for a class or method, it happens to us all. Often times, however, the inability to come up with a name may be a hint to something wrong with your design. Does your method have too many responsibilities? Does your class encapsulate a coherent idea?

Answer 5

I do spend a lot of time as well worrying about the names of anything that can be given a name when I am programming. I'd say it pays off very well though. Sometimes when I am stuck I leave it for a while and during a coffee break I ask around a bit if someone has a good suggestion.

For your class I'd suggest VendorHelpDocRequester.

Answer 6

More so than just naming a class, creating an appropriate package structure can be a difficult but rewarding challenge. You need to consider separating the concerns of your modules and how they relate to the vision of the application.

Consider the layout of your app now:

• App
  • VendorDocRequester (read from web service and provide data)
  • VendorDocViewer (use requester to provide vendor docs)

I would venture to guess that there's a lot going on inside a few classes. If you were to refactor this into a more MVC-ified approach, and allow small classes to handle individual duties, you might end up with something like:

• App
  • VendorDocs
    • Model
      • Document (plain object that holds data)
      • WebServiceConsumer (deal with nitty gritty in web service)
    • Controller
      • DatabaseAdapter (handle persistance using ORM or other method)
      • WebServiceAdapter (utilize Consumer to grab a Document and stick it in database)
    • View
      • HelpViewer (use DBAdapter to spit out the documention)

Then your class names rely on the namespace to provide full context. The classes themselves can be inherently related to application without needing to explicitly say so. Class names are simpler and easier to define as a result!

One other very important suggestion: please do yourself a favor and pick up a copy of Head First Design Patterns. It's a fantastic, easy-reading book that will help you organize your application and write better code. Appreciating design patterns will help you to understanding that many of the problems you encounter have already been solved, and you'll be able to incorporate the solutions into your code.