Channels ▼

Bil Lewis

Dr. Dobb's Bloggers

IInterface? I don't think so!

May 20, 2008

Back when I was a graduate student at Penn (sharing an office with the
remains of Eniac), I read some papers from IBM, extolling the virtues
of naming things according to their properties. So an integer variable
would always start with the letter I, so people would know it was an
integer, without having to check the declaration. Fortran went a step
further and actually allowed you to skip the declaration and just
assumed I, J, K, L, M, and N would all be integers.

As computer science progressed into the 60s and 70s, this convention
was dropped and things began to be named after their intended purpose,
rather than after their type or other properties. This meant that you
had to look at the declarations if you weren't sure what the type of a
variable was, but the purpose of the variable was clearer.

Fast forward to modern times.

People have begun to revive the old practices. Eclipse, for example,
names all interfaces by prefixing an "I" to the name. Other folks have
adopted the old C convention of prefixing an underscore to a name to
indicate that it is for the internal use of its module and shouldn't
be used outside of it. Still others prefix "m" to indicate an instance
variable (aka "data member").

Is this a good thing to do?

I have a clear test for these things, which you may or may not agree
with.

The most important thing about code is that it be READABLE.

That's my claim and I'm sticking by it.

If you give me buggy code and it's readable, I can fix it. If it's
slow, I can speed it up. But if I can't read it, then I can't do
anything.

So... Does prefixing things with special characters make it easier to
read code?

Let's take the extreme version and prefix all the properties, fully
spelled out onto the variable, interface, class, etc. name. Do you
like this:

class ConcreteClassArrayList implements InterfaceList {
  private int privateIntSize = 0;
  private Object[] privateObjectArrayData;

  public void publicVoidAdd(Object o) {
    if (privateIntSize == privateObjectArrayData.length)
      privateObjectArrayData = privateObjectArrayExpand();
    privateObjectArrayData[privateIntSize] = o;
    privateIntSize++;
  }

...
}


or this:

class ArrayList implements List {
  private int size = 0;
  private Object[] data;

  public void Add(Object o) {
    if (size == data.length)
      data = expand();
    data[size] = o;
    size++;
  }

...
}


Not much question about this one, is there?

If doing it all the way is clearly bad, is doing it only a little OK?

And of course, my answer is no. Things should be named after their
function in the clearest possible fashion and the details of their
implementations and properties I can easily look up if I need
to. Adding the little bits that folks like to, only makes the code a
little harder to read, but even that's too much.

This is no big deal:

  _value = _initialValue._recompute();


It will only take a extra few milliseconds for me to figure it out,
but I don't want to spend a extra few milliseconds. Moreover, it's
really easy to miss that "._" and read it as

  _value = _initialValue_recompute();

Compare to this: 

  value = initialValue.recompute();

Which is easier to read?

 So, IInterface? I don't think so!

Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 


Video