Geeks With Blogs

L. Charles Andersen
One of the things that I consider fundamental concerns a method or function. Historically, a method does exactly one thing, which its name describes. It starts at the top and ends at the bottom; i.e., it has exactly one entrance and one exit.

With such a simple guideline, how can anybody submit a method that deviates from it? For example, the following method names tell when it happens, not what it does:

  • AfterGetProductListCallback
  • OnUpdateLayoutComplete

Interestingly, these names do not seem to tell us anything:

  • RadDockingPanelPaneStateChange
  • FilesSelectedCellsChangedClick

One reason that I have observed that causes difficulty for programmers to choose an appropriate name is that their method violates the “one thing” part of the guideline. Their methods do several different things.

So, how can a programmer know if the method they wrote meets these guidelines? They should be able to explain:

  • first, what the method does (this should take a very few words, and the method name should already prep us for that)
  • next, (from a high level) the algorithm they used (this will take more words than the introduction, but not many more)

If they cannot do that, it is possibly a sign that the code is not ready for review. Send it back for refactoring. A method with more than 10 lines is probably not ready for review. The programmer will not be able to do those two things above.

A junior programmer might not yet have developed the skills to get all of his method to fewer than ten lines. A code review should help with that. Ideally, methods should be less than about five lines.

When you write a short method, it is hard to make it do more than one thing, and easy to give it a descriptive name.

Posted on Tuesday, January 8, 2013 12:51 PM | Back to top

Comments on this post: Fundamental Aspects of Methods

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © L. Charles Andersen | Powered by: