 Hello and welcome to having coffee with Smok. I'm Smok and today we are going to talk about naming. Naming in software development. This is one of the most difficult issues there are. Right, and whenever you try to research naming anywhere, you will find this quote by Phil Carleton. There are only two hard things in computer science, caching validation and naming things. I kind of agree because naming things in software development is more like an art than concrete field that you could get right, measure and say, okay, this is an appropriate name and this is not. You need to develop certain methods around naming things. You know what? Let me close the window because, boom, back. So today coffee is with this guy. His name is Bohenek and I brought him from Seattle. So say hello, nice people from the internet. So grab yourself something nice, warm to drink, like a cup of coffee and let's get started. So let's discuss naming and why is it important? Well, there are a couple of reasons you want to have good names. They will allow you to read and understand code faster, especially when you navigate foreign code. So we name things for a reason, right? To convey meaning. If the names weren't important, we would just use memory addresses and that would be fine because, yeah, everybody knows what this address means and that's it. Unfortunately, that's not the case, right? We need good names to explain what this variable is about, what this class is about, what this method is about, what this class is about, right? That's very important, right? To have good names. So today I'm going to go deep into the naming, cover the basics of naming for beginner software developers, but also, yeah, don't click away just yet, but also I'm going to touch on the advanced topics as well that come later in the naming, especially when you already have a job and you are working with a team. So maybe your team doesn't have a good method on naming. They want to come up with some good ideas. This is exactly what this video is about. So let's start with basics. So if you can, use English names. By saying if you can, I mean if your code isn't already in different language. I think it's okay to use non-English language when you have narrow cases that exist only in your country and there is no real good reason to translate to English. Maybe that's valid case to use local language, but all others, when you don't actually need anything that is, for example, Polish, Spanish, French, like only in there, don't use this language, right? Use English because you never know what kind of software developers are going to join your project. Yeah, don't mix two languages. If you can, refactor out local language, even gradually, but do consistent work to refactor out local language if you can, use English. Second thing, classes, variables, packages are all nouns. Methods, such functions, are verbs, always, always try to have it in this sort of way, right? This is a convention, follow it. And also, classes are always singular, always car, vehicle, and then all of that, never cars, never vehicles. You need one thing because you're going to create one object, right? If you have already plural form, how are you going to create multiple objects or of cars, right? How many cars is that? What is the more plural form of already plural thing? Avoid abbreviations and acronyms. Don't use shortcuts, right? Don't do those, unless these are like very commonly known things like DB or RDS or something like that. Don't use abbreviations because, yeah, eventually you will get new people in your team and they won't know them. And every now and then there is an abbreviation and when you try to expand it, it expands to another abbreviation, which is how. Come up with something better, name it, think about names. It will pay off if you actually give enough time to come up with good names. It will save a lot of time in the future when the names are actually good, meaningful, and so on. And other thing I want to recommend and that I think everybody should do it is pick a code convention, code style. As long as you work in team, you need to agree on something. There are already code styles available online. You can just pick one, agree on it, and follow it. One of the good examples that I use myself and I recommend is Google code style. So get the package with Google code style. You will have XMLs for Eclipse, for Intel J, and so on, so forth. And it will allow you to put that in your IDE and it will automatically correct everything just to match this code style. Why is it better? Simple. Everything is consistent across the project. Use that and that's it. Never worry again. Like press format button, it will be automatically formatted for you. You don't need to worry. It just is. If your name doesn't follow the code style, you will get a squiggly line underlined and you will know, oh, yeah, I made a mistake here. So let's just correct it, right? So go get a code style. I highly recommend it. Doesn't matter which one. As long as it covers all the major use cases that your particular case needs, right? Ubiquitous. Ubiquitous enough. All right. So there is this other mistake that I want to caution you about, right? It is a commonly seen things among junior software developers and beginners, right? So don't try to save memory or CPU cycles by using less variables or less functions. You don't really save any memory by reusing the same variable, right? If you have an X and then you assign stuff to it, then you do some calculation, and then you assign it back to X and then you do even more calculation, assign it again to X. Don't do it. Never, never do it. Always come up with new variables if you can. Come up with new variables. What will happen is the compiler will inline your variables. It will actually take all of the use cases of the variable and it will try to compact the memory, right? It will solve this issue for you. You don't have to worry about allocating too much memory, unless you're working in some tightly compacted environment which is, I don't know, embedded computing on chips or something like that. Don't worry. Your computer can handle it. Don't try to optimize there because that's not actually an optimization. So what you'll end up with is having a few variables that don't really mean anything. They mean everything, basically, which is the worst kind of variable you can get, right? And same thing goes to functions. Compilers are smart enough to inline all of those functions for you and use names that you can pronounce. Don't use any of these. Like these names are wrong. These names are wrong. Don't use those. Not at all. Always use names that you can't pronounce. Try to say that out loud or even on a stand-up or in the same room. Don't avoid not. Avoid not this part. Not in the names of variables, functions, everything. Don't use that. Find an antimim. Don't use not because you'll end up with something like not not deleteable, right? Don't do this. You don't want this construction to be in the curve because on the glance, you don't know what that means. Don't do this. There is another thing that is basically a face palm in my dictionary. Never, ever use Hungarian notation. Basically, what Hungarian notation is is adding type to the name of the variable. So, for example, if you have a zero terminated string, it would be Sz as string zero terminated. And then the name has like, I don't know, first name. We are way past the times that you need that information. Ideas are so complex tools that they will tell you everything on a hover of mouse, right? You don't need to know the type just by glancing at the name. Or actually, by glancing at the name, you should know what type it might be. Most likely, you're using one of the two things in C++, for example, right? Either a string or C-style strings, which is zero terminated string. Those two, nothing else. So, pick one and use it everywhere, right? Throughout your project. And then you don't need this Hungarian notation. It makes things ugly, unreadable, and it's really hard to follow when you have more complex names. And also, try avoiding prefixes. Variable is a member of the class. You don't need to say, oh, M underscore name of the type. That's like 2010 or something. Because if your classes need prefixes, they are too big. They are too big. You have too big scope. You need to reduce your classes, split them in parts, and then you don't need prefixes because basically class will only have what is necessary in there. Your class may be too big, man. Just split them up. How long and how short your names should be? Like, should they be 10 characters? Should they be 20 or 100? How big? So, rule of thumb is for iterators. You can use one letter, right? You can use i, j, k, something. That's the common convention. It's fine. Everybody understands that. In almost any other case, you need longer name. It's all about finding an appropriate length that carries meaning. And I would say three is minimum. If you need a comment to explain what the variable does or the function does, the name is too short. And at the same time, it shouldn't be too long. I would recommend to keep function names under 64 characters just for sake of brevity, right? If you need a longer name to describe your function, most likely your function is too big. Most likely you need something that you need separate pieces. Like, so after you break this method in three smaller ones, for example, and then you call them one by one in your bigger method, come up with higher level of abstraction on what you're actually doing in there, right? If there is a shortened name explaining what the method does, use it. Use the shorter one. As long as it explains everything, including side effects. If your method has side effects that are not obvious, put them in the name of the method, even if you have to make it much longer, right? Because whoever is using your method most likely won't go into that method just to make sure that it does what it says it does, right? Most likely they will assume that nothing else happens. But if you pass an object into that and it gets modified, how did that happen? Why? Who did that? Like, no, never, never do that. Always include the side effects in your method names. Name should describe single concern. So basically one single thing should happen with that variable, with that method or anything like that. So when you have something like this, number of kilometers stored in one variable, and then you have this string that says km as kilometers, right? And you then concatenate that. Whenever you do that, call this new thing, something else, call it distance label, right? It's now a label that contains both the unit and contains the value, right? So it has a value and the unit. So that's the thing that you need to be concerned with. Remember to name it accordingly. Avoid helpers, handlers, managers, all of those things that convey no meaning. Can you tell me what the sound helper does or the file handler or the compression helper? Does it compress, uncompress? Does it look into metadata? What does it do? Can you say if your manager, for example, is responsible for invoking different things at different order, call it an orchestrator, right? It decides when each step of the process should happen. Like come up with a better name. Think it over. So sometimes it's valid to have a handler, like I don't know, file handler. What that usually means that you give a file to this handler, you pass it somehow and handler knows what to do with this. So usually this means that there is no input, a file, and handler is this thing that knows what to do with this input, right? But if you can avoid it, like instead of having a file handler, have a file store, right? That's what it does. It's a file store. It takes a file from the user and stores it. That's its job. It's simple. It's in the name. It's in the name. So there are some names that are commonly used and I want to recommend them instead of using helpers or handlers or anything like that. And I'm just going to call them out and you can figure out for yourself, do they convey any meaning for you? Do they explain what they do good enough? And then if they do, you can just pick them and use them, right? So we have like a decorator, producer, consumer, selector, orchestrator, grouper, collector, persister, loader, streamer, right? A lot of those already convey the meaning that you need. If I have a producer, most likely this will do something to produce items that perhaps could be taken by consumer. Nick Giannetakis? Nick Giannetakis? Forgive me, sorry. Nick suggests that you should run your names through the ambiguity filter. What that means is basically you ask yourself or you ask a friend what does the name mean other than what you think it means basically. So could it mean anything else? Could it be understood in a different way? That means that the name is wrong. You need to get back to the drawing board and come up with a better one, right? Simple. All right guys, so these are my naming rules that I try to follow that I recommend to everybody. And if you have other ones, if you have something that you know that is good that other people should use as well, leave notes down in the comment. Call the good recommendation you have. Let us know. We want to know what are the rules that you follow. And if you don't agree with anything I said, also let us know. We want to know. Let's build a community here. Let's discuss stuff in the comments. Right. If you enjoyed this short video, consider subscribing. Me and Bohanek are saying goodbye. And we'll see you in the next one. Cheers!