Choosing good names
marcelo-cure.blogspot.com
Choosing good names
1–10 of 41 posts
Re: Choosing good names
#2You could provide even more clarity by using meaningful types like Money or TaxPercentage instead of Double.
This would allow you to ensure only valid values are passed and would help avoid problematic floating point arithmetic :)
Re: Choosing good names
#3I guess the verbosity of the method's name is actually good in this case? Since it makes the function so much clearer.
I am never sure how much to abbreviate a name, but I guess if it's not going to be used much it can be long without problems.
Re: Choosing good names
#4Well thank god we fixed the naming, that will surely help when someone comes looking to find out why all the amounts don't add up.
Re: Choosing good names
#5You could provide even more clarity by using meaningful types like Money or TaxPercentage instead of Double. This would allow you to ensure only valid values are passed and would help avoid problematic floating point arithmetic :)
The general idea was to show a simple exemple. But I really appreciate your point. Thanks
Re: Choosing good names
#6I guess the verbosity of the method's name is actually good in this case? Since it makes the function so much clearer. I am never sure how much to abbreviate a name, but I guess if it's not going to be used much it can be long without problems.
If you're using a modern IDE, you shouldn't have to ever type the name out after the first time. I almost never abbreviate anything.
Re: Choosing good names
#7Often programmers instinctively name their code the same way they structure it: with as much elegance and brevity as possible.
If you think about it, elegance and brevity in naming serve no logical purpose. When reading names, understandability is the only goal; elegance and brevity do not assist in this goal. Thus, from a readability standpoint, it is better for names to be verbose and informative at the expense of elegance.
There are those out there that complain about how verbosity contributes to increased typing time and the probability of spelling errors, to which I have to say: Modern dev tools like Intellisense and autocomplete largely eliminate this type of error. Additionally, if you hate these modern tools, I still feel that, especially in extremely large and complex code bases, the benefits of writing clear and understandable code with verbose naming far outweigh the benefits one gains when using brevity in naming.
Re: Choosing good names
#8I guess the verbosity of the method's name is actually good in this case? Since it makes the function so much clearer. I am never sure how much to abbreviate a name, but I guess if it's not going to be used much it can be long without problems.
The verbosity itself shouldn't be a problem, if it someway helps to understand the class / method meaning. But, on the other hand redundancy can be a problem in my opinion, specially considering there is always a context where your code lives.
Re: Choosing good names
#9I guess the verbosity of the method's name is actually good in this case? Since it makes the function so much clearer. I am never sure how much to abbreviate a name, but I guess if it's not going to be used much it can be long without problems.
If you're using a modern IDE, you shouldn't have to ever type the name out after the first time. I almost never abbreviate anything.
When I first started using Objective-C, I noticed how verbose the signatures were when passing messages, but really liked how it read when you were scanning the source.
After that, I stopped giving a shit about how long my identifier names are and just make sure they explain in a direct (but concise!) way what that method does or what that variable is.
Re: Choosing good names
#10You could provide even more clarity by using meaningful types like Money or TaxPercentage instead of Double. This would allow you to ensure only valid values are passed and would help avoid problematic floating point arithmetic :)
I guess you mean typedefs and not separate classes for Money, TaxPercentage etc.
I recently came across a codebase that implement type classes for almost all types of things it handles and found that to be overkill. Almost always, name and age can be represented by a string and an integer respectively; separate Name and Age classes just reduce the readability in your code.