“Stop Using Good Names in Your Code” | Code Cop #015

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments
Captions
hello everybody I'm Nick and welcome to another episode of Code cop the series where we go over questionable advice given on places like LinkedIn Twitter or blogs and we try to turn it into good advice and learn from it today I have a very interesting and very very bad piece of advice given on LinkedIn which is the worst place to get advice but it's on a topic that so many people get wrong and that is naming and people do get wrong because naming is extremely extremely hard but I think there's so much wrong with this specific spefic post that I want to explain my reasoning with naming and how I think when I'm naming things and maybe we can have a discussion in the comments down below so you tell me what you think about all the choices I'm making and why I think that this advice is wrong if you like of content and you want to see more make sure you subscribe for more training check out my courses on do tr.com okay so let me show you first some code before I show you the advice because I want to make this a bit of like an interactive experience what I have here is a customer service class and I have a register method so you have a customer registration coming in and then you have a register method and then you have some validation it doesn't matter what's happening inside the validation and then you have the customer so we get that through a mapper we convert the registration to a customer domain object or dto it doesn't matter and then we have this customers class over here and we say do save customer and we pass down the customer and then after we saved we return it I believe that this is wrong in so many levels but what I want to ask you is what do you think this customer is varable it's supposed to represent I'm going to pause for a second you can just stop and pause the video and think about it because the way it reads is it reads as a static readon collection and we can tell that by the way it is named is Pascal case and it says customers implying that it's a collection of many things that thing being the customer at least that's how I'm thinking and what's weird about that is that why would you say customers do save customer well maybe that's because this is a DB set and we're using anti framework but you can tell there's so many assumptions because I don't know what it is now I could look at the Constructor and know what it is but given that this is a class member potentially I could be anywhere in the class and I shouldn't have to go all the way up to see what it is well spoiler this is actually a customer repository which no one should have guessed so with that in mind let's take a look at the LinkedIn post costs now very very quickly before I move on I'd like to let you know that we just launched do train Pro a monthly subscription on doome train that gives you access to our entire cost catalog that's 25 courses we have right now and we also have 17 more coming until August by Massive high-profile authors that you know in love if you want to get access to the modular monolith the clean architecture domain driven design and so so much more coming like vertical architecture graphql vent design Blazer we have so much coming this is just a trial and we won't leave the monthly option open for forever we don't know when we're going to close it but get it before it's gone because currently we're evaluating having a monthly offering however if you do get it now you get to keep it until you cancel it so don't miss this opportunity get the link in the description and I hope to see you in Dom trainer okay so we have clean code tipe consider using the collection name rather than repository no but anyway for a clear presentation consider using the data sets descriptive name such as customers instead of its storage designation for example customer repository I would not CL classify that as storage designation I would classify that as more of a data access layer or transport or medium I wouldn't call it designation but let's take a look at the code advice now LinkedIn creators have gotten smart they don't like to have the bad advice and good advice now they have good advice even better advice because the code cup and in fact people actually have started tagging me under these posts and some of them get deleted before I get to make a video about them keep doing it if you see something weird just tag me I might make a video on it and I might save it early so they don't take it down but the advice is this is clear yeah okay use customer repository if you have a customer repository but it would be better if that customer repository has the name customers no it's misleading it looks like this is a collection not a repository I have more issues with this whole method by the way I'm going to go in that in a second second but let's take a look at the text accompanied with this post just to get more context so nameing conventions some prefer customer repository I would say most prefer customer repy also side note the way this is sort of named here implies that this is a property not a private readon field which is what it should be we're going to touch on that in a second but I want to mention that as well so some prefer customer poetry others opt for the simpar customers I want to point out I have never in my live seeing someone use customers to represent a customer repository every single person I've seen uses customer repository the only difference in that is when there's only one repository injected let's say you have a customer service and you only inject the customer repository the only naming difference I've seen is people call that repository as just repository because they think it's implied in that service because a customer service you could only have the customer Repository I disagree with that because you can split your repost to different responsibilities so if you have a product you might have a product catalog you might have a basket you might have pricing repository you might have so many repositories so I like to be explicit with my naming and I'm going to show you what my Approach would be here but then they say but isn't our goal to represent a stored collection of well customers no you store a repos that can act on that collection but you don't represent the collection it's like you say library Library when you inject Library a thing with books you don't say books in the method it would be as if I had a class library and I named library books no the library is the library containing or knowing how to manage books and then some code for example customer is customers. getet email address I disagree it makes sense for a collection but it doesn't make sense for a reposter for example here you wouldn't have customers. getet email address you'd have customers do or customer repository actually dot get by ID get by email and get could be a predicate as well where you can just pass down some parameters and have a Lambda function passed in no it is not Crystal Clear customers. saave is crya clear assuming customers is something like a DB set not the rep po just doesn't make any sense to me please leave a comment down below let me know what do you think about this do you think that this makes sense and let's go back into the code again because I want to touch on something else okay validate fine I don't want to argue about this this in my opinion shouldn't just be reg this should be customer registration now I wouldn't call this class over here customer registration I would call it customer registration request or whatever I I don't like how this is named because it could be many many things but this is just a request to create a customer really in the same way by the way that I don't like that the register function returns a customer that isn't nullable or it's just a customer while registration could have like a database exception what happens here or it could be like an issue with the email already being used what do you return this method has many many problems I'm going to focus on the naming and when it comes to the customer itself yeah that is you know a good name that is named well and that method here is named well in my opinion now here I wouldn't name customers customer in fact I wouldn't have it as a public uh property as well I would have a private read only customer repository and I would just call the customer repository inject it from The Constructor and then go ahead and use it even if this is a million miles away I know immediately just by looking at this that this is a customer repository and it is saving a customer and I know by this naming that this is a private field most likely read only way better naming way more explicit but I still don't like that this method is called save Customer because this is more of a create customer we clearly are adding that customer into the system save can imply both creation and modification and I don't like using the save terminology in my repository so this would be create customer but then again this is a customer repository so the context matters so if you want to create something in that repository and the parameter is the customer then clearly this will just be create so now this reads way way better because you know exactly what you're using here and you know exactly what this method is doing now if you want to go a step further and you want to use sort of the common approach of calling these methods you can have the create async method now you might not like using the async suffix that's totally okay that's completely up to you and please leave a comment down below letting me know are you using the async suffix are you not using it I really like to know last time I asked more people said yes I am using it than no but in some cases you know nowadays everything is sort of asyn so it could feel a bit redundant and now just by this small change this method in my opinion reads way way better now I should have changed so many things here but that's where I'm going to leave it please please please be explicit with your naming but also assume the context of the thing you're using for me that aspect the name of the method is as important as the name of the parameter or the variable here please a down below letting me know how would you do this differently and what do you think about this piece of advice do you think it's good or it was good in the beginning do you think now it is better how else would you change it leave a comment let me know well that's all I had for you for this video thank you very much for watching and as always keep coding
Info
Channel: Nick Chapsas
Views: 29,692
Rating: undefined out of 5
Keywords: Elfocrash, elfo, coding, .netcore, dot net, core, C#, how to code, tutorial, development, software engineering, microsoft, microsoft mvp, .net core, nick chapsas, chapsas, dotnet, .net, code cop, code cop nicik, code cop nick chapsas, Stop Using Clear Names in Your Code, bad naming code, code naming, terrible code naming
Id: 8xw5KM8AJHY
Channel Id: undefined
Length: 10min 14sec (614 seconds)
Published: Thu Mar 21 2024
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.