 Hey there, YouTube. My name is Lee Brandt. I work for Okta. Today we're going to talk about naming conventions. Now, I started my career many years ago, about 96, 97. Started off doing a little bit of Coalfusion, then quickly moved into the Microsoft space with active server pages, using Visual Interdev, if you remember those things. And back in those days, it wasn't uncommon to work for a company that used a naming convention called Hungarian Notation. Now, Hungarian Notation had been around for a while. One of the guys who was the chief architect at Microsoft had recommended it to anybody doing Microsoft stuff. And if you're not familiar with Hungarian Notation, it was a naming convention that semantically named variables to tell you what the type was. So, for instance, if you had a variable name, first name, it was usually STR first name. In the lower case, STR, and then first name. And it kind of bled into everything. So, if it was a variable that was meant to hold an object, it started with OBJ. If it was a variable meant to hold a long, it started with an L. And it bled over into database programming where tables would be called TBL and stored procedures would start with SPC or SPR. So, it kind of fell into everything. And somewhere around, I guess, the early mid-2000s, people started recommending against it. And mostly it had to do, I think, with the fact that IDs were becoming easy. They would give you the variables type on demand easily. It would just show you immediately that this is an integer variable. This is a string variable and that sort of thing. So, there wasn't really a lot of need for the extra typing. And so, it didn't really provide any more value. But one of the things that stuck around from Hungarian notation was the interface naming convention of starting the interface with the letter I. So, instead of just having an interface, it would be I interface, whatever the name is. And it's really the last wooby of Hungarian notation, the last thing that got held onto. And Microsoft still does it in the .NET framework. The interfaces are all prefixed with I. And it's pretty common. But with the advances in code editors like Visual Studio Code and Visual Studio themselves, we really don't need them anymore. But you might think, what's the harm? So, really for senior level devs, there really isn't any harm. We know it's just a naming convention. And any naming convention, as long as you've, as someone who is a consultant for most of my career, when I come into a new organization, I just figure out what their naming convention was. And I would just follow it. There's no reason not to. It's one of those things that, as a consultant, it's one of those fights that's just not worth fighting. There are plenty of other things that organizations might be doing poorly that focusing on the naming conventions of their variables is just not worth the fight. But for junior developers, and one of the things that I've noticed, I've also done a lot of training since about, oh, 2006, 2007, I've been doing a lot of training with developers. And one of the things that I noticed is that that naming convention has a tendency to provide a barrier between junior developers or maybe developers that are new to a statically typed language as to what the real power of interfaces is. I distinctly remember training a team, and so I put together this example, and I said, okay, so here's the first part of this example. I want you guys to finish this example, and I want you to use the interfaces and this kind of interface driven development that we're talking about. And one of the people came back to me with their next feature, and it was good when I looked at the solution, when I looked at the code base and the file names, they were good. They had an I-person repository and a person repository just as an example. So when I dug into the code, though, the I-person repository had no code in it whatsoever. Now, the person repository still implemented the I-person repository, but since the I-person repository had no code in it, it really didn't do anything. And it's all well and good to tell young developers that interfaces are just contracts. They are contracts that will be fulfilled by some implementer somewhere in the future, and that's great. But for me, especially when I first started, I kind of got the concept, but I didn't really understand the value, and especially when you see a lot of code bases where there is a one-to-one relationship. So I've got an I-person repository and I've got a person repository, and a lot of junior developers, especially .NET developers, their only exposure to interfaces was the I-disposable interface. Now, back in the day, that was really all you needed was the I-disposable. People weren't writing a lot of interfaces because they didn't understand the power of them, or at least I wasn't. So when I first started to understand the value of interfaces, I started doing this one-to-one thing. So it wasn't I-person repository and a person repository, and then I would put all the methods like create, read, update, and delete in my I-person repository interface, and then I'd put the implementation in the person repository class. And I never really understood why I was doing what I was doing. I never understood that this was a contract and that I needed to fulfill that contract with a person repository, but I still wasn't properly coding to abstraction, so the abstraction was a wasted abstraction on me. And when I did, there was only one thing that ever implemented the I-person repository interface, and that was the person repository interface. So a lot of the meaning was lost on me, and when I finally got it, I don't remember what exactly flipped the switch for me, but when I finally got it, it came in the guise of having a second implementation for something. And all of a sudden when I started teaching other developers, I would still say, here's the I-person repository, and here's the person repository. The I-person repository is a contract that the person repository must fill, and that's all great and wonderful. But once you start using something like a dependency injection framework back before it was built into the .NET framework, we were using things like NINJECT and Autofac and things like that that were injecting those dependencies for us. Then it started to become clearer, and I think one of the things that really gets it for junior developers, when I came across a blog post that was talking about removing the I-person interface, and if I remember correctly, it was by Jean-Paul Boudu who I followed a lot back then, and I was like, okay, well, I'm not really sure I see what's going on here, what the point is, but I'll give it a shot. And so my next small project that I was doing just for myself personally, I forced myself not to call my interfaces I-person repository, for example. And what happened was when I was forced to drop the I, my interface then became person repository, which means that now I had to find a separate name for the implementation. Now I could have put it in another namespace and it would have been okay, but it would have still become problematic when I'm using it because I just put the imports and the using statements at the top, but down below I would still be calling it person repository and I would have to fully qualify it in order to talk about a lot of typing. So I had to find a different name for the implementation class, and so I would call it seekor repository, right, or in memory person repository, whatever. Now, all of a sudden, when I'm doing that, it becomes clear to me why an interface exists and why the implementation exists because I'm injecting those interfaces and the interfaces are being used in place of those concrete classes because all that we're being told in, let's say a controller, for instance, because that's where you use it a lot. So I have a person controller that gets an I person repository injected into it, or in this case, a person repository interface injected into it. The dependency injection framework says, hey, whenever somebody asks for a person repository interface, give them the SQL person repository class. Now, I use it inside the controller as if it's just a person repository without any notion given to how it's implemented. Think of a telephone interface. So when I'm on a regular telephone and I've got those 12 buttons, right, I know how to use them. So when they put together cell phones, did they really have to give us 12 buttons? No, they could have given us anything, but the interface we were already familiar with, but the implementation behind the scenes is quite different, right? But we don't care. We just push our 10 buttons that we do for a phone number, seven if you're calling locally, right? And we don't care how the implementation happens between the touch of our finger and the registering of that number. And once I was able to kind of make this clear to junior developers, all of a sudden, I saw lights going on with junior developers. As soon as I said you cannot use I in your interface names, they immediately started, OK, well, here's my person repository. Man, what am I going to call my implementation class? Well, what is it doing? Well, it's saving it to the database, to the SQL database, right? Sure. Well, why not call it SQL person repository? Oh, OK. But what about something else? Yes, what about something else? Like an in-memory person repository. Oh, and you see the light go on with junior developers or people who have never used a statically typed language before. You see that light go on with interfaces and their implementations. And I think that that's one of the things that for me made me kind of passionate about getting rid of the I in interfaces was once I see that light go on because they were forced to drop the I from interface. And again, for senior developers, it doesn't make any difference. At the end of the day, if you've got this huge code base that uses I in interfaces, there's no reason to go back and rename everything. That would be horrific, right? But dropping the I from interfaces forces you to find a meaningful name for the implementation classes. Now I have seen, this is another kind of anti-pattern, and it's pervasive in Java, and I think the reason is because a while ago Java dropped the I from interfaces. Java developers haven't used it in a few years now. So what I saw in Java instead was they'd have a person repository, and then they'd have a person repository IMPL for implementation. So they had the person repository interface and the person repository IMPL implementation, which still doesn't help people who are trying to understand interfaces and are trying to understand how these statically typed languages work. That doesn't help them either because you still end up with almost a one-to-one relationship, which is fine if you only have one implementation trying to loosely couple, trying to pull two pieces apart from each other so they're not so tightly coupled to each other, I get having a one-to-one relationship. But the real power is in the fact that if you need to change that implementation, it's easier to do because I just write a new class that implements the interface in a new way and tell the dependency injection container that whenever somebody asks for this I person repository now or this person repository now, give them the in-memory person repository. Now, this has been super helpful in real-world scenarios. So I was doing some work for a large organization, a banking organization, so there's a lot of bureaucracy and a lot of security that goes in, there's a lot of layers there. So we needed a database. The problem was the database team was really small and they serviced like 15 or 20 different software development teams. But because of certain compliance issues, we couldn't create our own databases. We had to go through the DBAs to get a database created for us. So it took them about a month and a half because of their backlog to get a database stood up. Obviously everyone who's a developer is thinking, why would it take them a month and a half? It was just because of the backlog because they had so many things to do ahead of our request that we had to wait. Now, we could have stood around and tried to write some classes and tried to come up with a little framework of classes that we were going to use and that's all great and tried to avoid the database. But instead, we went about our business as if nothing was different, as if nothing had changed and we just used interfaces and an in-memory repository. So anytime you needed to save an order or save a transaction, we would just send it to the transaction repository interface and the in-memory transaction repository would handle it. Now, none of this is the fault of I in interfaces. They still could have been called I Transaction Repository and Transaction Repository or in-memory Transaction Repository. The I doesn't stop you from giving it a good meaningful name. But I think that the I does keep people younger developers, junior developers, people just starting out or people who just moved from another language that doesn't have interfaces. It keeps them from understanding the real power of interfaces. And people who are unfamiliar with your code base automatically understand calling it I Person Repository and Person Repository doesn't tell anybody reading the code base about what's going on inside that Person Repository class. They still have to open up the implementation to find out what's going on. But at least the name SQL Person Repository gives you some information about the class that it's saving it to a SQL database somewhere. Now, SQL is pretty pervasive, so it could be PostResql or MySQL or Oracle or SQL Server. It doesn't really tell you much more, but you know that this Person Repository is actually saving it to a SQL database or saving and retrieving from a SQL database. That helps. And having them injected into like controllers, for instance, when I'm using the Person Repository interface, I'm using it as I would any other thing, like any other concrete class, which is the way you should think about it. Now, some of the common objections I get are like, I like being able to tell immediately by looking at the name of the class that it's an interface. For me, that doesn't really hold up just because you should be using it like a concrete class anyway, right? The I-Person Repository that's injected into your Person Controller should be used as if it were the implementation anyway. You're just calling methods on it, and it's handling, however it's handling it, whether that's saving it to a SQL database, saving it to an in-memory collection somewhere, saving it to an XML file, saving it to a JSON file. I don't care. All I care about is I call the PersonRepository.save and pass it a person and it saves it for me, and I can retrieve that one again, right? So liking being able to tell that it's an interface in advance just by looking at the class name, I think it's okay, but again, it goes back to the objection that I get with that generally is more from senior developers where the I is just a naming convention, and that's fine, whatever your naming convention, again, not a fight worth having. The second objection I get, specifically from .NET developers, is that the .NET framework uses I for interfaces everywhere. And sure, the code base has been around since the late 90s. I remember messing around with some of the first betas in 99. So of course those, that was when Hungarian notation was pervasive. And not that it means anything. They had a large code base and they didn't want to go back and refactor, but they didn't drop the I's from interfaces, and so people still follow that guidance from Microsoft. And that's fine. Again, that's completely fine. I'm just saying that it may keep younger developers, and people coming from other dynamic languages from understanding the true power of an interface in a statically typed language. So, the other one that I get a lot is don't all statically typed languages use I for an interface. Like I said, Java stopped doing it a while ago. I work in a Java shop and I ask some of the Java guys, do guys still use I in interfaces? And they're like, no, that was a few years ago. We stopped doing that. So, but I think where the IMPL thing came from, where people would name it, Person Repository and Person Repository IMPL, I think that came from the people who didn't want to let go of the I in interfaces. So they just switched the naming convention over to the implementation so they could tell that this was actually an implementation. And it's not terrible. It's just, it doesn't really provide any value. IMPL only tells you that it implements Person Repository. That's fine. But calling it SQL Person Repository or XML Person Repository would at least give you a little bit more information about how it's implemented so people know what to expect when they open the file. The other objection that I get and I just got it recently because I talk about this a lot with other more seasoned developers is I like being able to find the interfaces in my code base. In my list of files, I like being able to find those interfaces because they're all right there starting with I. And that's great. But it doesn't really... There's other ways to achieve that without giving up the helpfulness of calling it Person Repository and SQL Person Repository and XML Person Repository. You can namespace it. Just namespace all your interfaces into a namespace called Interfaces or Abstractions. Something like that. Now you can find all your interfaces or in a namespace called Abstractions. And the good thing about namespaces everybody's probably got into one of those projects that has 500 or one of the solutions that has 500 projects in it, right? So, I tend to lean on the more simpler side. Start with, especially if I'm doing greenfield development. I mean, if I'm coming into a brownfield development, I usually don't mess with their conventions unless it's causing problems, causing strife, even if I don't agree with their conventions, I just follow them. It's easier to follow them than to make that fight. Especially when I know I'm going to have to fight something that may be more difficult later but it's more important. So, I start on a project with everything in one project. And I just namespace things at boundaries. So, in .NET, just namespacing it means just creating a folder. Now I've got a new namespace. But, and Visual Studio and VS Code will help you out with namespacing based on where you create the file at. You create it in the controllers folder. It's going to be prefixed with the .controllers namespace, right? So, that's a good way to change out those boundaries and having them in another namespace immediately means that I can break them out into another project fairly easily by creating a new project with that namespace and deleting that folder and I'm done, right? So, namespacing your interfaces can give you the same benefit as naming them all with I. One of the things that becomes a problem is you end up with a bunch of I interfaces. And especially if you've already namespaced them and you have them prefixed with I, now you have I's and you have to go with the second letter to find the one you're looking for, right? So, I'm not sure that naming files starting with I will help you find them better, but so the question that I get a lot is okay, so you're telling me I should go back and I've got a codebase that's 10 years old and I should go back and rename all my interfaces without an I or rename all the implementations no, I'm not saying that at all. One of the things that I'm suggesting you do is with smaller projects going forward just try it out or even in your personal projects and especially when you're training junior developers you're training people who are changing from a dynamically type language and have never used interfaces before JavaScript developers are finally getting this with a little bit of the TypeScript interfaces but people coming from Python or another language that's dynamically typed might not understand what interfaces are actually buying them and they may just see it as a bunch of extra typing so forcing them to not use the I and interfaces in a small project can help that light go on for them and help them understand how interfaces work and what their real power is what the power of that abstraction really is being able to switch out different implementations easily I think is super, super helpful and this is going to take time I don't expect that everybody on the internet is going to go, oh, Lee's right we should get rid of the I interfaces first of all I fully expect lots of vitriol in the comments I expect people to call me stupid I expect people to tell me I don't know what I'm doing I expect people to tell me that I'm a really crappy programmer that's totally fine I've been doing this for a long time I've had lots of happy clients I've had lots of happy coworkers that I've worked with and I've taught a lot of junior developers along the way that I did see the light go on when I forced them to write a small project even if we were using the I naming convention for interfaces in our main project I would force them to write a small project on their own where they couldn't use I as an interface especially if I saw that they were struggling with understanding how the interface and the implementation are kind of connected together so that's really what I'm trying to say is for junior developers and for people coming into a statically type language from a dynamically type language let's start by showing them a statically type language with interfaces that don't start with I and I think that the light will go on a lot quicker for them on why interfaces are important and why you should use them as an abstraction layer to decouple layers from each other so in the end the real question is what do you think is there some benefit to the I interface that I'm not seeing again I've been teaching this since about 2005-2006 so I feel like I've come up against just about every objection you can have but I'm always willing to learn always willing to hear somebody else's opinion if you have an opinion that's like you have to use the I interface because of this or that benefit you get is great but it's not as good as this benefit I get from using an I interface naming convention please, please tell me about it I'd love to hear about it leave it in the comments below don't forget to subscribe to the channel and hit the little bell so you get notifications when we've got new content coming up we're making lots and lots more of these videos as well as instructional videos and some of these opinion videos that are going to cause the internet to go aflame I think but go ahead and leave your comments below subscribe and hit the bell notification and we'll see you next time