Ok Uncle Bob, I think I can put into words now why the "I" SHOULD be prepended to Interface names

[Terence McGhee]

So of all of the teachings of UB, the one I struggled with the most (and didn't follow) was not prepending interface names with the letter "I".

So if I have an interface named Employee, I still name it IEmployee. I've read many of the arguments against this (in UB's books and in the 8th light blog), but they never really convinced me. Now keep in mind that I definitely agree with the general principle of not encoding our names and I don't encode any names other than my interfaces.

So why do I continue to do this with interfaces and nothing else? Well I can finally tell you why.

In the book Agile Principles, Patterns, and Practices in C#, Micah Martin made a profound (and unfortunately very true) statement. He says 

I can come to no other conclusion: .NET programmers tend to be weaker in agile software practices, design patterns, design principles, and so on. Often in my classes, the .NET programmers had never heard of these fundamental concepts. This has to change.

As I just mentioned, this statement is undoubtably true. Even as a senior Windows developer, I'm nowhere near as proficient as I'd like to be in the practical application of design patterns and principles. I'm still learning every day with every piece of code I write or refactor. I'm lightyears better than I was, but still not as good as I'd like to be.

 

So take the DIP. 

High level modules should not depend on low-level modules. Both should depend on abstractions.
Abstractions should not depend upon details. Details should depend upon abstractions.

Well for a beginner, or someone who is not well versed in design patterns and principles, visual aids are great tools in understanding and learning. 

For example, if in a use case interactor, I see 

Employee employee = storageOfficer.getEmployeeMatching(employeeId);

if(employee.isPayDay(today))
    Pay(employee)

I can instantly know that this code needs to be examined, because it's a high level module and I can easily see that it's depending on low-level details (a concrete employee). Now again, keep in mind that this is from the point of view of a beginner who is learning to apply design principles and patterns. 

I should add that for my example, the system from the code above only has the one type of Employee (no hourly, salaried, commissioned, etc.) for right now, but it's definitely going to change as these things always do. Now, as I gain experience, there are definitely other cues that I could use, but again, for the beginner, this simple visual aid in this instance is priceless. 

Conversely, if that same code was written as

IEmployee employee = storageOfficer.getEmployeeMatching(employeeId);

if(employee.isPayDay(today))
    Pay(employee)

I can instantly see that this code is properly depending on abstractions, all because the "I" in the interface name is a great visual aid to a newb.

So basically, the reason that I continue to decorate my interface names with the letter "I", is because it greatly helps me and other members of my team see where we need to examine decisions in the code. Once I've reached Jedi-master-status and don't need these anymore, then I still think they'd be helpful to future padawans.

[Breno Sarkis]

Hi Terence,

Though I think this is directly at Uncle Bob, allow me to tell you what I did... I had/have the same point of view as you, being a .Net developer I've never questioned the 'I' prefix, when I read clean code for the first time I thought I could easly get rid of it, but it is all around us (.net developers) the framework interfaces are declared with it... So to get a 'visual aid' as you called it I came to an agreement with my team that we'd change the colors for the interface definition, yes, I know it's weird, its not even a 'solution', but it does work, and everyday I miss the prefix less and less.

We also stopped using  the 'var' keyword for this kind of stuff.

[James Green]

Interesting. I just read somewhere that .NET developers were far better at object-oriented programming (domain style, as opposed to service-oriented) than Java developers. I imagined there would be a great deal of knowledge about patterns and principals as a result.

I am afraid having the I prefix is to me about as ridiculous as having an Impl postfix on implementation classes. Spring Framework actually demands it in some cases :(.

--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discu...@googlegroups.com.
To post to this group, send email to clean-code...@googlegroups.com.
Visit this group at http://groups.google.com/group/clean-code-discussion.

[Daniel Sandberg]

We do the same in our team - all interfaces and abstract classes are made italic with a slightly different Color from Concrete classes. This keeps everybody happy.

Same thing with using "this.xyz" everywhere, we simply make the field-variables bold and local variables normal (default in IntelliJ).

Keep in mind that many of the so called "best practices" for code styles are decades old, many of which was defined when we didn't have syntax high-lightning, IDE's and last but not least - tests. Just think about the {}-brackets that UB wants to erase - as soon as you have a comprehensive suite of automated tests and practices TDD, the arguments presented that you should always use brackets are pretty much becoming obsolete.

[Sebastian Gozin]

I would not be surprised to see the response argument that newbie programmers should not be allowed to program without a mentor to help them through such institutionalized confusions.

I have always been deeply frustrated with arguments against clean or proper design because it is too difficult for inexperienced programmers.
All too often it means I must write junior level crap despite my ability to do better not because anybody on the team doesn't understand but because future inexperienced programmers who aren't with us yet might not.
Going further I feel it is often assumed that all experienced programmers should and will be removed from a project as it is handed over to an inexperienced maintenance team which the company does not invest in.
I find this deeply sad.

In practice I've found that inexperienced programmers have no trouble at all understanding abstractions without the help of encodings or using List instead of Iterable.
I think we should give our younger peers the benefit of the doubt on things like this and actively teach them.

[Roberto Guerra]

Sebastian, I think that excuse is brought up just to hide their own shortcomings. They are not saying inexperienced developers might not understand it, they are really saying: "I don't understand it myself and don't think its important. Lets stick to what I know now." I've had similar experiences. The other excuse I've been given: 'Just make it work now.'

[Terence McGhee]

@Sebastian

I greatly appreciate your input, but I think you've extrapolated way beyond the point of my post. I don't know how this got misconstrued, but I'm not advocating poor design because of newbies. Whatever I said to imply that I take it back.

What I am talking about is decorating interface names so that it's easier to see the relationships between the objects in the code. I don't think there's anything improper about this. The idea is to encourage proper design and make it easier to see the relationships. This is so that proper designs can be implemented throughout the code base.

So it's not a matter of "understanding" abstractions. It's a matter of being able to easily spot them just by looking at the code.

On Tuesday, February 4, 2014 6:41:26 AM UTC-6, Sebastian Gozin wrote:

[Caio Fernando Bertoldi Paes de Andrade]

Terence,

This argument about naming is the same as the one about Hungarian Notation, and there are lots of reasons not to follow those notations, you know that.

About your visual cue argument: My IDE, using the default configuration (no fancy plugins nor anything), shows me when a type is an interface or a class when I place my cursor on it, no need to double check declarations or add letters before (or after) names.

Cheers,

Caio

[Christian Meléndez]

I think that in this case, like Daniel were saying, your IDE will help, try to create a .dotsettings file so everyone in your team has the same colors

--
Saludos,
Christian Melendez

[Terence McGhee]

Hey gang.

I definitely agree 100% that using features of Visual Studio can help with the visual aids. I think this is a great idea. However, the code is not always viewed in an IDE.

For example, my question to the group is this: Just by looking at the code fragment below, tell me is it coded to an abstraction?

GameHero hero = storageOfficer.getGameHeroMatching(gameHeroId);
hero.saveTheCity();

Sebastian, I definitely agree with you in that naming notations in general are useless and a waste of time. It's just that in the case of interfaces, I'm willing to make an exception, because I can appreciate the value in being able to see at-a-glance where the abstractions are in the code base. But in all other cases, I don't use any other notations.

[James Green]

Says nothing. GameHero could be abstract. I could create a new concrete class called IGameHero and nothing would stop me.

--

[Terence McGhee]

@James

Sure you could do that, but that's you deliberately going out of your way to cause confusion. My statements in this topic are aimed at normal situations where everyone is working together to achieve clarity.

On Tuesday, February 4, 2014 10:20:36 AM UTC-6, James Green wrote:

Says nothing. GameHero could be abstract. I could create a new concrete class called IGameHero and nothing would stop me.

On 4 February 2014 16:12, Terence McGhee <terence...@gmail.com> wrote:

Hey gang.

I definitely agree 100% that using features of Visual Studio can help with the visual aids. I think this is a great idea. However, the code is not always viewed in an IDE.

For example, my question to the group is this: Just by looking at the code fragment below, tell me is it coded to an abstraction?

GameHero hero = storageOfficer.getGameHeroMatching(gameHeroId);
hero.saveTheCity();

Sebastian, I definitely agree with you in that naming notations in general are useless and a waste of time. It's just that in the case of interfaces, I'm willing to make an exception, because I can appreciate the value in being able to see at-a-glance where the abstractions are in the code base. But in all other cases, I don't use any other notations.

--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@googlegroups.com.

[Caio Fernando Bertoldi Paes de Andrade]

Terence,

Do you remember the early episodes of Clean Code?

Clean code is simple and direct, reads like well-writen prose, and contains the utter truth about what it does.

GameHero hero = storageOfficer.getGameHeroMatching(gameHeroId);
hero.saveTheCity();

The utter truth this code tells us is that it gets a GameHero from the storageOfficer and tells it to saveTheCity.

The method doesn’t tell us whether GameHero is an interface or a concrete class, because it doesn’t care about that. That’s part of the beauty of having an abstraction.

In runtime, everything is a concretion. The dependency management is the programmer’s responsibility and is expressed in the configuration part of the application: main.

I hope this clarifies the arguments against notations, and I encourage anyone interested to reread the book Clean Code, we can always learn new things.

Caio

--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discu...@googlegroups.com.

[Terence McGhee]

@Caio

Let's try a different perspective.

Imagine that you inherited a code base that had the previous code in it.  Or let's say you're responsible for doing an audit of this code for whatever reason. The main point is that you didn't write this code and it's now It's your very first time in the code and it's up to you to make sure that the code base conforms to SOLID principles. How will you know, which of the functions / modules / classes are properly conforming to abstractions without having to trace all over the code to find out? I don't think you can.

To me, there is value in being able to easily spot where the abstractions are even if it means continuing to prepend an "I" to all interfaces. The ability to see this far outweighs any general rule against notations.

Also, because I see value in prepending the "I", doesn't automatically mean that I am a proponent for all other forms of notations. The clear labeling and distinctions of interfaces has value to me while the other forms do not.

To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@googlegroups.com.

[James Green]

It sounds to me like you are creating an artificial indicator where you actually want a static analysis tool.

To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discu...@googlegroups.com.

[Sebastian Gozin]

Terence,

My apologies, I may have been a bit too strong. It's one of my flaws.
I certainly didn't mean to imply you're not trying to pursue a clean codebase.

I understand your argument. I'm just not convinced by it. At least I am habituated to not seeing the I-prefix.
In practice I probably wouldn't make a big deal out of this particular one.

[Uncle Bob]

On Monday, February 3, 2014 11:09:41 AM UTC-5, James Green wrote:

Interesting. I just read somewhere that .NET developers were far better at object-oriented programming (domain style, as opposed to service-oriented) than Java developers. 

The statement in our book is probably over 10 years old.  Lots has changed in the .NET world since then.  The Microsoft clan is nowhere near as insular as it once was.  That's a very good thing.  

Whether .NET programmers are better at OO is something I've not seen.  I'd say they've caught up. 

[Roberto Guerra]

+1 to James Green's comment. I don't see the need to pre-pend with an I either. If you have an IDE, just hover over the name and it will tell you. If you don't use an IDE, lets say vim, just do `Ctrl-P nameOfClass' and it will open it for you and you'll see right away what it is. I think this falls under Rich Hickey's "Simple not Easy" talk. Pre-pending with I is easy but it is not the simple and elegant solution.

To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsubscri...@googlegroups.com.

To post to this group, send email to clean-code...@googlegroups.com.

Visit this group at http://groups.google.com/group/clean-code-discussion.

[Terence McGhee]

As I mentioned earlier, there are plenty of instances where we all view code and it's not in an IDE. Here are a few concrete examples.

• Books
• UB's Videos
• Webinars
• UB's Craftsman Series that Caio found (which is excellent btw)
• Blog posts

The simple fact is that you don't always have the luxury of an IDE when viewing code. There are times when I have to view code in Notepad++.  None of the IDE related suggestions (which are great when working with an IDE) address any of these other forms of viewing code.

[James Green]

None of the listed presentations are intended to help you check for abstraction use. If you want to check for something, use a tool.

Back in the days when I was looking at the donated sources to Netscape Navigator the interfaces were prepended with I. I wanted to rename them all to reflect the world, not a notation.

--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discu...@googlegroups.com.

[Juan Diego Hereñú]

I really don't get the need of knowing if it is an abstraction or not. I understand the need of working always with abstractions, but in the case you are working with concrete classes shouldn't be a problem until it is and in that moment you refactor your code. I agree with everyone that says that the expressiveness of the code is the most important. I've been working with dynamic languages for the last months and you realise that what you need to understand is what you are trying to do and not how it is done.

Juan

2014-02-05 James Green <james.m...@gmail.com>:

[Terence McGhee]

@Juan

The need to see the abstractions is for the same reasons as all of the other fundamental Clean Code principles. To clearly and easily see the author's intent.

2014-02-05 James Green <james.m...@gmail.com>:

To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@googlegroups.com.

To post to this group, send email to clean-code...@googlegroups.com.
Visit this group at http://groups.google.com/group/clean-code-discussion.

--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@googlegroups.com.

[George Dinwiddie]

Terence,

On 2/4/14, 11:47 AM, Terence McGhee wrote:
> @Caio
>
> Let's try a different perspective.
>
> Imagine that you inherited a code base that had the previous code in it.
> Or let's say you're responsible for doing an audit of this code for
> whatever reason. The main point is that you didn't write this code and
> it's now It's your very first time in the code and it's up to you to
> make sure that the code base conforms to SOLID principles. How will you
> know, which of the functions / modules / classes are properly conforming

> to abstractions *without* having to trace all over the code to find out?

> I don't think you can.

Why do you want to "make sure that the code base conforms to SOLID
principles?"

I use SOLID principles, not because they're morally superior, but
because they make my work easier. When I inherit code, I presume that
it's working "well enough" for now, or they wouldn't be using it. I
don't edit it preemptively, but only in response to having to create new
business value. When that happens, I clean as I do so to make the job
easier now and in the future.

> To me, there is value in being able to *easily spot* where the

> abstractions are even if it means continuing to prepend an "I" to all
> interfaces. The ability to see this far outweighs any general rule
> against notations.
>
> Also, because I see value in prepending the "I", doesn't automatically
> mean that I am a proponent for all other forms of notations. The clear
> labeling and distinctions of interfaces has value to me while the other
> forms do not.

The point of abstractions is that you don't need to know that it's an
abstraction. If it's important that the client code knows it's dealing
with an abstraction rather than a concrete implementation, then that
might be a smell worth investigating.

- George

>
>
>
> On Tuesday, February 4, 2014 10:35:51 AM UTC-6, Caio Fernando Bertoldi
> Paes de Andrade wrote:
>
> Terence,
>
> Do you remember the early episodes of Clean Code?
> Clean code is simple and direct, reads like well-writen prose, and
> contains the utter truth about what it does.
>
>> |GameHero hero = storageOfficer.getGameHeroMatching(gameHeroId);
>> hero.saveTheCity();|
>
> The utter truth this code tells us is that it gets a GameHero from
> the storageOfficer and tells it to saveTheCity.
>
> The method doesn’t tell us whether GameHero is an interface or a

> concrete class, because it *doesn’t care* about that. That’s part of

> the beauty of having an abstraction.
>
> In runtime, everything is a concretion. The dependency management is
> the programmer’s responsibility and is expressed in the
> configuration part of the application: main.
>
> I hope this clarifies the arguments against notations, and I
> encourage anyone interested to reread the book Clean Code, we can
> always learn new things.
>
> Caio
>
> On 4 Feb 2014, at 14:12, Terence McGhee <terence...@gmail.com

> <javascript:>> wrote:
>
>> Hey gang.
>>
>> I definitely agree 100% that using features of Visual Studio can

>> help with the visual aids. *I think this is a great idea*.

>> However, the code is not always viewed in an IDE.
>> For example, my question to the group is this: Just by looking at
>> the code fragment below, tell me is it coded to an abstraction?

>> _
>> _

>> |GameHero hero = storageOfficer.getGameHeroMatching(gameHeroId);
>> hero.saveTheCity();|

>> _
>> _
>> Sebastian, I *definitely agree with you* in that naming notations

>> in general are useless and a waste of time. It's just that in the
>> case of interfaces, I'm willing to make an exception, because I

>> can appreciate the value in being able to /see at-a-glance where
>> the abstractions are/ in the code base. But in all other cases, I

>> don't use any other notations.
>>
>> --
>> The only way to go fast is to go well.
>> ---
>> You received this message because you are subscribed to the Google
>> Groups "Clean Code Discussion" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to

>> clean-code-discu...@googlegroups.com <javascript:>.

>> To post to this group, send email to

>> clean-code...@googlegroups.com <javascript:>.

>> Visit this group at
>> http://groups.google.com/group/clean-code-discussion

>> <http://groups.google.com/group/clean-code-discussion>.

>
> --
> The only way to go fast is to go well.
> ---
> You received this message because you are subscribed to the Google
> Groups "Clean Code Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to clean-code-discu...@googlegroups.com.

> To post to this group, send email to clean-code...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clean-code-discussion.

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------