Suggest Variable Name?

[Immortal Nephi]

You could have heard Hungarian Notation. The Complete Code book said
Hungarian Notation is no longer used anymore, but Microsoft continues
to use it.
I can’t think how to name that variable. The algorithm has two tasks
to convert data from integer number to real number or from real number
to integer number back and forth.
There are two version of classes. One class uses integer number and
another one use real number.
For example, Dollars_Cents class has two separated classes. First
version of Dollars_Cents class uses integer number and second version
of Dollars_Cents class uses real number (floating precision). Do not
use template.
Sometimes, floating precision is not accurate when you use number
division, but integer number is very accurate.
How do you name that class? The variable name might look like that
below.

class Integer_DollarsCents { … };
class Real_DollarsCents { … };

Integer_DollarsCents is better choice because integer number saves
more memory space, but floating precision wastes a lot of memory space
because it uses either 4 byte length or 8 byte length.

 

[Francesco S. Carta]

You could have heard Hungarian Notation. The Complete Code book said
Hungarian Notation is no longer used anymore, but Microsoft continues
to use it.
I can’t think how to name that variable. The algorithm has two tasks
to convert data from integer number to real number or from real number
to integer number back and forth.
There are two version of classes. One class uses integer number and
another one use real number.
For example, Dollars_Cents class has two separated classes. First
version of Dollars_Cents class uses integer number and second version
of Dollars_Cents class uses real number (floating precision). Do not
use template.
Sometimes, floating precision is not accurate when you use number
division, but integer number is very accurate.
How do you name that class? The variable name might look like that
below.

class Integer_DollarsCents { … };
class Real_DollarsCents { … };

Integer_DollarsCents is better choice because integer number saves
more memory space, but floating precision wastes a lot of memory space
because it uses either 4 byte length or 8 byte length.

Apart that I would run far away from real numbers when dealing with
money, I would suggest not to mix up different naming styles.

"integer" is a word so common that shortening it to "int" is
straightforward, so - having to comply to your requirements - I would
pick either
"IntDollarCents, RealDollarCents"
or
"Int_dollar_cents, Real_dollar_cents"

(the "dollars" to "dollar" change is intentional, I prefer the latter)

Breaking one of the requirements I would make a template out of it, but
having to implement it all from scratch I would stick to using just
integers.

 

[Jonathan Lee]

        You could have heard Hungarian Notation.  The Complete Code book said
Hungarian Notation is no longer used anymore, but Microsoft continues
to use it.

As a guideline I would say "don't use Hungarian Notation to indicate
types". However, in this case you have different *behaviors*. Having
an iDollars and fDollars might make sense. For instance, in my code
I distinguish between "integer square root" and "square root" by
naming the former "isqrt" and the latter "sqrt". The "i" does not
indicate type -- it indicates behavior. isqrt and sqrt are not the
same function.

In the case of dollars, it's reasonable that someone might want
one behavior or the other. Assuming this is the interface you
want to provide, I don't see a big problem.

There are two version of classes.  One class uses integer number and
another one use real number.

Besides the naming convention, the whole idea of providing
two classes is a bit debatable. Personally, I would template
the integer class to provide a general fixed point representation.
Then you wouldn't have the problem at all.

i.e., Integer_DollarCents becomes DollarCents<100>, with the 100
indicating 1/100 of a dollar is your precision. Assuming your
Integer_DollarsCents class is even reasonably designed, it should
be trivial to replace this with 1000, 10000, etc or any template
parameter.

I can't say for sure, but I think financial software tends to
use fixed point arithmetic underneath. So templating may actually
be closer to common practice than using floats or doubles.

--Jonathan

 

[Öö Tiib]

        You could have heard Hungarian Notation.  The Complete Code book said
Hungarian Notation is no longer used anymore, but Microsoft continues
to use it.

It is good that Microsoft does it in strange way. If you use different
naming conventions in your application logic layer it makes it easy to
see what is platform-specific or framework-specific and what is your
application logic. It is ugly (for visually obvious reasons) when used
as mix so you have natural urge to separate platform/framework and
application logic with translation layer. Having such layer is
extremely profitable later.

        I can’t think how to name that variable.  The algorithm has two tasks
to convert data from integer number to real number or from real number
to integer number back and forth.
        There are two version of classes.  One class uses integer number and
another one use real number.
        For example, Dollars_Cents class has two separated classes.  First
version of Dollars_Cents class uses integer number and second version
of Dollars_Cents class uses real number (floating precision).  Do not
use template.
        Sometimes, floating precision is not accurate when you use number
division, but integer number is very accurate.
        How do you name that class?  The variable name might look like that
below.

class Integer_DollarsCents { … };
class Real_DollarsCents { … };

I would use "Money". How Money holds the monetary values internally is
not good to show externally. Also it is bad to tie down these are
dollars. What dollars? Canada, Singapore or East Timor? Keep currency
unit as property or template parameter (depending if it may change
dynamically) of it.

        Integer_DollarsCents is better choice because integer number saves
more memory space, but floating precision wastes a lot of memory space
because it uses either 4 byte length or 8 byte length.

How you hold them internally is best to hide. It may be that the law
demands you store full cents, it may be that law demands you keep it
in tenths of cents. Accuracy should be also property or template
parameter. Holding monetary values as any floating point (float,
double, long double) feels wrong because floating point values
accuracy does float with that point. Monetary value feels wrong as
argument for arccosine, exponential function, hypotenuse, natural
logarithm, raise to power, square root and so on functions for what
you usually use floating point values. I would use it simply as 64 bit
int internally then the usual billions will fit.

Of course you can make member functions like asInt() and asFloat() to
get numeric values out of your Money.

 

[Immortal Nephi]

It is good that Microsoft does it in strange way. If you use different
naming conventions in your application logic layer it makes it easy to
see what is platform-specific or framework-specific and what is your
application logic. It is ugly (for visually obvious reasons) when used
as mix so you have natural urge to separate platform/framework and
application logic with translation layer. Having such layer is
extremely profitable later.







I would use "Money". How Money holds the monetary values internally is
not good to show externally. Also it is bad to tie down these are
dollars. What dollars? Canada, Singapore or East Timor? Keep currency
unit as property or template parameter (depending if it may change
dynamically) of it.


How you hold them internally is best to hide. It may be that the law
demands you store full cents, it may be that law demands you keep it
in tenths of cents. Accuracy should be also property or template
parameter. Holding monetary values as any floating point (float,
double, long double) feels wrong because floating point values
accuracy does float with that point. Monetary value feels wrong as
argument for arccosine, exponential function, hypotenuse, natural
logarithm, raise to power, square root and so on functions for what
you usually use floating point values. I would use it simply as 64 bit
int internally then the usual billions will fit.

Of course you can make member functions like asInt() and asFloat() to
get numeric values out of your Money.- Hide quoted text -

- Show quoted text -

Well, you have good reason to create two versions of classes instead
of template because both classes have different behavior and
operation.
The percent function or temperature degree function do not belong to
that integer class. There are many examples why you should use
floating point class instead.
You create an integer slider like range 0 to 255. You increment or
decrement the value by one. It can be used for integer RGB or general
purpose.
Also, you create a floating point slider like range 0.0 to 1.0. You
increment or decrement the value by 0.1 or 0.01 or 0.001. You add
percentage to that value because it is annoying to see 0.120, 0.241,,
0.574, etc. Better to see range 0.0 – 100.0.
You can always convert from range 0.0 – 1.0 to range 0 – 255 back and
forth. Two versions of classes make sense.

 

[Öö Tiib]

        Well, you have good reason to create two versions of classes instead
of template because both classes have different behavior and
operation.

If they are different objects with different responsibilities then
create different classes. Internal implementation details do not
matter.

        The percent function or temperature degree function do not belong to
that integer class.

Why? Can you describe what they do? You can hold data internally in
percents of degrees of Celsius. Then getPercentsOfCelsius() returns
internal data_member_value and getCelsiusDegrees() returns
data_member_value/100 or (data_member_value+50)/100 depending how you
round.

There are many examples why you should use
floating point class instead.

There are cases when floating point values are correct to use of
course. Monetary value just is clearly not one of such.

        You create an integer slider like range 0 to 255.  You increment or
decrement the value by one.  It can be used for integer RGB or general
purpose.
OK.

        Also, you create a floating point slider like range 0.0 to 1.0.  You
increment or decrement the value by 0.1 or 0.01 or 0.001.  You add
percentage to that value because it is annoying to see 0.120, 0.241,,
0.574, etc.  Better to see range 0.0 – 100.0.

Or ... you may keep internally using int with value of 0 to 1000 and
just display it like it was floating point:

#include <iostream>

int main()
{
for ( int i = 0; i <= 1000; i += 7 )
{
std::cout << i/10 << "." << i%10 << " ";
}
std::cout << "voila " << std::endl;
}

        You can always convert from range 0.0 – 1.0 to range 0 – 255 back and
forth.  Two versions of classes make sense.

Or you may not need to convert at all because as underlying type they
both use 0 - 1000000000 and only display their value of position
depending on some "diplaying parameters".

 

[James Kanze]

You could have heard Hungarian Notation. The Complete Code
book said Hungarian Notation is no longer used anymore, but
Microsoft continues to use it.

I can’t think how to name that variable. The algorithm has
two tasks to convert data from integer number to real number
or from real number to integer number back and forth.

There are two version of classes. One class uses integer
number and another one use real number.
For example, Dollars_Cents class has two separated classes.
First version of Dollars_Cents class uses integer number and
second version of Dollars_Cents class uses real number
(floating precision). Do not use template.
Sometimes, floating precision is not accurate when you use
number division, but integer number is very accurate.

No handling of currency can be 100% accurate. (Think of
compound interest.) The problem with machine floating point
isn't that it isn't accurate; it is that the rounding rules it
uses don't correspond to the rounding rules specified by the
standard bookkeeping practices in the country you're in. (In
many cases, the problem may be that double is too accurate.)

How do you name that class? The variable name might look like
that below.

class Integer_DollarsCents { … };
class Real_DollarsCents { … };

Integer_DollarsCents is better choice because integer number
saves more memory space, but floating precision wastes a lot
of memory space because it uses either 4 byte length or 8 byte
length.

The algorithms using float or double are very different from
those using integral types. In this case, however, what I'd
suggest is a template, with a very simple selection between the
two basic forms, e.g.:

template<typename BaseType>
class DollarCents : public DollarCentsImpl<BaseType,
std::numeric_limits<BaseType>::is_integer>,

Then use partial specialization for the integral and
non-integral forms. (If you expect future specialization for
things like BigDecimal, you might want to add a parameter for
std::numeric_limits<BaseType>::radix as well.)