Let's talk about conveying context and meaning through naming.
So here we have a class called Customer service.
And if we would create a method now for saving customers, one could create a method name such as safe
right.
This is you know okay.
Developers will see okay.
It's a safe method instead of a customer service.
Chances are quite high that this is about saving a customer, but still it is not the best approach.
It.
It is okay, you know, don't get me wrong, no one will hang you because you've just decided to write
down safe.
But a better way is to write down public void safe customer.
This makes it entirely obvious or super obvious that you're saving a customer customer service.
You save a customer, right?
Because there could be another method which could be called void safe customer name.
You only want to save the name, right?
Save customer ID, save customer last name, and so on.
So it's better instead of having one safe method here, right?
Because if we want to do it that way and now want to have public void safe name, now the question is
if we have a method for saving a name, what the hell does save then do does it save the entire customer
object?
Is it doing something else?
You know?
So it's always better to be very precisely with your, uh, method names, and therefore you want to
add the noun to it, for example.
So save.
But what do you want to save?
You want to save the entire customer.
Or to be even more specific, save.
You want to save the customer object.
To be more specific, the customer name property, for example.
Alrighty.
So that's the first part again for naming methods.
And the second part is that you again want to stick with conventions here for your method names it's
best to use is get set has, can and so on.
So for example the customer service we could create a public uh void here.
Set customer name.
Right.
Just like we did set customer name or has we could create a boolean, um, uh method here.
Public bool has errors.
Right.
And for can you can do something just return false here and for can just an example would be public
bool again for can you want to most of the time have a yes or no.
Can I do that.
Yes I can no I can't.
So public bool can receive emails for example.
That would be a great name to check if the customer has opted out of your emails for example.
So let's say return false.
He cannot receive any emails.
All right.
So most of the time you want to use is get set has can for your method names.
But that's just like an idea.
If you come up with a better name, which is more that is describing what the methods does in a better
way without using any of those, it's still fine to do it that way.
However, I want to mention that these words here, these naming conventions are clearly indicating
the intent of the method.