IInterface? I don't think so!
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!

