11–20 of 41 posts
Also, the "tax" argument is the tax _rate_. "tax" in this instance I would expect to mean the final amount. So I'd call that parameter "taxRate".
(And I'd use ints for everything, of course)
Firstly, it's too verbose - a nice middle ground would have been better: calculateTransferTax(Double transferValue, Double tax). It's fairly clear what the tax is being calculated over.
Secondly, I'd say that "tax" is a bad name for the tax percentage since it doesn't describe that what actually is (the percentage / rate of tax), and since it's a Double, I'd expect it to be "0.2" for a 20% tax rather than 20.0 which appears to be what the method would actually expect.
I would have called the function "calculateTransferTax". It's shorter while providing the same meaning. Also, the "tax" argument is the tax _rate_. "tax" in this instance I would expect to mean the final amount. So I'd call that parameter "taxRate". (And I'd use ints for everything, of course)
I would have called the function "calculateTransferTax". It's shorter while providing the same meaning. Also, the "tax" argument is the tax _rate_. "tax" in this instance I would expect to mean the final amount. So I'd call that parameter "taxRate". (And I'd use ints for everything, of course)
How would you use ints when there's division in the code? I've heard it's usually better to prefer ints to floating points, but in my limited experience I've found that it's easier said than done.
You 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
This sort of thing is probably why such examples are always blandly about cars and their colors and shapes and their areas.
You 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 would now have to look up the implementation of Money and TaxPercentage to be sure of what it does, whereas if you move the type names into the variable names like in the following examples: 'double total_money' and 'double tax_percentage' I would immediately understand what's going on.
I do see how a TaxPercentage type allows you to create a type that restricts itself to percentages. I feel that it is serves readability better to leave this checking to the function using the value itself rather than having the type do it.
You 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.
Reasonable support here mostly means that you can implement operator overloads, so that you can define e.g. a Money type that can be added but not multiplied.
Money handling may not actually be such a good example for this, because you should really have proper unit testing there anyway. I did work on a codebase that had types for SI units, and it was quite a nice experience.
Local variable names should be short, and to the point. If you have random integer loop counter, it should probably be called "i". Calling it "loop_counter" is non-productive, if there is no chance of it being mis-understood. Similarly, "tmp" can be just about any type of variable that is used to hold a temporary value.
If you are afraid to mix up your local variable names, you have another problem, which is called the function-growth-hormone-imbalance syndrome. See chapter 6 (Functions).
Source: Linux kernel coding style - https://www.kernel.org/doc/Documentation/CodingStyle
I would have called the function "calculateTransferTax". It's shorter while providing the same meaning. Also, the "tax" argument is the tax _rate_. "tax" in this instance I would expect to mean the final amount. So I'd call that parameter "taxRate". (And I'd use ints for everything, of course)
How would you use ints when there's division in the code? I've heard it's usually better to prefer ints to floating points, but in my limited experience I've found that it's easier said than done.
As you said, easier said than done; but you really don't want FP errors popping up in financial calculations :-)
[1]: https://en.wikipedia.org/wiki/Non-decimal_currency