Agreement for Interface names


#1

When I came from C# to Java, I've noticed it is harder to read code. In sharp ther is agreement - all interfaces start with "I". For example IList. You do not need to go to definition to understant that. Also from this point we can refuse from long ArrayList and write List. And in many other cases names can be simplified too.

May apply this practice?

And som small qa. Why you make Integer short and String not? :slight_smile:


#2

Hi,

prefixing  an interface with an “I” was also common practice in Java for a long  time, but it was later abandonned. I don’t know exactly why. There might  be several reasons. When you programm against an interface anyway it is  nicer when for example the interface for transaction is name  Transaction as in hibernate. The most often used implementing class is  DefaulTransaction. Not calling the transaction interface ITransaction  but Transaction makes you think how to name the implementing classes  which forces you to think twice about your design: What is the purpose  of the implementing class? I can’t find a name for it? Then what is the  real purpose of it? Do I have to rethink something here?

Remember  in Microsoft MFC every class had a prefix “C”? So it was CString and  not String. For a Java developer and most OO developers this would seem  odd. It maybe made sense for C/C++ people, because they have the option  of choosing a CString or a char[]. But in a more or less plain OO world  (at least Java as a hybrid is still much more OO than C++) this does not  make sense. IMHO the same as for CString/String holds true for  ITransaction/Transaction. So my suggestion is not to prefix interfaces  with an “I”. Kotlin is Java-oriented and to Java people this seems old  fashioned.

Regards, Oliver


#3

Hmm. If I'm not mistake you are talking that all classes need to have interfaces (let thing so). That's the trick, not all code do this. In one library you have Transaction as an interface, in another as a class. And there is no way to understand it from name. Some times, using library for pretty long time, I find out that type is class instead of a interface, or vice versa.

You gave a good example - DefaultTransaction. Do we need this 7 letters if we assume default behavior? I think no. Some guys like long long names, but not me. I prefer documentation. You also told about name/design, but really how one letter can degrade it :slight_smile: ?

Look at java collections, there are a lot of AbstarctSmth classes, agreement :slight_smile: Why? Because the name speaks for itself. Can we live without it? - yes. Can it make code more clear and readable? - I think yes.

Best regards, B7W


#4

Here is an interesting article about extreme programming. See the section titled "Agile Documentation". It starts with: "We treat the need for comments as "code smells" suggesting that the code needs improvement ...".


#5

prefixing  an interface with an "I" was also common practice in Java for a long  time, but it was later abandonned.

It’s not really abandoned, it’s used in Eclipse, for example.

I like the “I” convention myself (I use it in the TestNG SPI), I feel good when I read my code and I see a lot of “I”: it makes me confident that this code is well decoupled from concrete implementations and therefore easy to inject and test.

"We treat the need for comments as "code smells" suggesting that the code needs improvement ...". I think they have some point there ;-).

I disagree, I think the agile crowd still hasn't understood the purpose of comments, which is to explain "why" and not "what".

–
CĂ©dric


#6

I disagree, I think the agile crowd still hasn't understood the purpose of comments, which is to explain "why" and not "what".

I think there is a difference between comments in the code inside a method and Javadoc-style comments attached to some method body or class. Whenever you write some comment in your code it is good practice IMHO to take this as an occasion to check whether this comment could be avoided by making the code clearer or more readable or by choosing a different approach. This helps as some heuristic to keep your code clean and consistent.I think the XP guys have some point there. Whether being extreme also automatically delivers extreme good results is a different question...

I once attended a workshop with Kent Beck many years ago. I agreed from the beginning with the attitude that you should strive for writing self-explanatory code. Whenever you write a comment to explain what is happening here, you should re-consider your design. That’s fine with me. Kent Beck was against any comments inside the code at all at all cost. I was looking for meaningful exceptions and said that writing some comment that this code was written that way to work around a known bug might me a justifiable exception. He was also against this, absolutely no discussion. The other people in the workshop looked at me as if a were technology agnostig, backwards-oriented or just dull. Nowadays you get shit from everybody when your public comments are not commented. I guess in 5 years time or so things have changed to the opposite again … :slight_smile:

/Oliver


#7

Comments is generally for "what" or so I thought. "Why" is the code itself, be it agile methodology or any other