What's In A Name?
In Object Oriented Programming it's considered to be good practice to write methods that only do one major job. One strategy you...
For further actions, you may consider blocking this person and/or reporting abuse
Loved this, thank you!
I've been ranting about a method I found in one of our old libraries for the last couple of weeks.
GetIdById(), really? What the heck is that supposed to even do?After digging into it and figuring out what it did I eventually renamed it to
GetPatientIdByChartId()You write that it is a method, not a standalone function. So it belongs to an object, probably an object of type
Patient. So what about calling itGetIdByChartId()? It makes no sense to put information into a name that is obvious from the context.Because it was a standalone function. I tend to use method and function interchangeably when I really shouldn't.
Your rename makes a lot more sense than the original. "GetIdById" sounds like the code equivalent of trying to divide something by zero if you ask me!
Ha. I wish it had just contained
return id;
I once implemented model class Room, with supported classes RoomView and of course RoomService :-)
Nice article by the way, only thing I do not like in examples here is to use "list" or any other data typ word in names. I prefer simply to use plural nouns. So instead of getListOfProducts simply getProducts.
True, you're right. Using the variable will show clearly that it's a list - it's probably a bit redunant. Thank you!
I can see using the data type in the name for some weakly typed languages. Like if you’re not on the latest Python and type annotations are a pain, it’s nice to be able to see what you’re doing.
I have no excuse, I almost exclusively write in C#. sheepish grin
There's the industry-standard Javascript hack…
var that = this;I sometimes encounter
var self = this;too, kind of annoying. I prefer to usemyFunction() { /* much stuff, very algorithm */}.bind(this)if I am in an event handler for example, much natural to work withthiseven if the bind is a bit ugly!haha "much stuff, very algorithm" :)
Thankfully I don't need to deal with this very often at this point, but I agree with you. I'll keep this style in mind and try to remember to use it whenever I encounter it again!
I think, at my current level, I'd probably just sit there and cry (or laugh maniacally) for a few minutes if I came across this.
Thank you!
One of my favorites is when we spread a single giant method across multiple methods so that the names are
UpdateCustomer,ExecuteUpdateCustomer,DoExecuteUpdateCustomer, and evenPrepareToUpdateCustomer.Great article. Curious about one thing. Have one another question. For example :
getUserNearestLocation(user)by going through it we can say it this function is going to return user location based on user information. If suppose if I have to add another parameter in function let's say hospitalgetUserNearestLocation(user,hospital)now context has change name should begetUserNearestHospitalLocation. My question is that if tomorrow I have 10 parameters. Then this function name might be very big if I keep adding parameter. Eventually function is returnuserLocationbased on parameter. In those cases what are good naming convention?Hello everyone,
Do you think that we should keep variable names the same in the method that is calling and in the method that is getting the value?
Let's say we have a main method in Scala:
@main def create_etl_project = {
println("Please enter the project name, avoid using blank spaces:")
val project_Name = readLine().replaceAll("\s", "")
Create_Project_Directories(project_Name)
}
def Create_Project_Directories(project_Name: String) = {
}
Could you please let me know what do you think would be a best practice?
Thank you in advance.
I saw a great one in a meeting today and had to share:
very.long.name.to.work.around.bug();
Totally agree with your point. Taking a step back and putting some thought on how to name a variable or a method can help your app have more SOLID foundations and save you hours of refactoring.
I feel like it saves me a lot of time when I do small refactoring as I go instead of waiting until I have a 6000 line method to break apart all at once. (not to mention the time saved debugging when the only clue you have is "thing broke in main()"
I am not talking only about breking long methods to smaller ones, but conceptual refactoring when trying to name a variable/method. Often times I find myself struggling with coming up with a name, only to end up deciding that my method needs to be a part of a better designed class (or to be extracted to a new class), even before start writing it 😃
Naming is so hard.
I'm also much better at pointing out problems in other developer's names in a PR than I am at naming things myself. 😀
What if the class name would be ”Customer” and its method name would be ”create”.
Is it good,
I think a case like this would actually make sense, because I assume you'd do something like Customer customer = new Customer(); to instantiate your class... then you would be doing customer.create() whenever you called that create method. I hadn't considered the combination of classes and their methods - you made a really good point! Thank you!