Bjorn,
>Before I start, I should mention that I do not have any references to offer,
>only speculation.
I am beginning to think they don't exist.
>I tend to agree that reading mixing bases could necessitate a cognitive
>switch,
>if the numbers represent the same type of data. This would mean that we have
>to "parse" the numbers differently to bring them to a normalized form (for
>instance, convert the hexadecimal values into decimal).
From the computing perspective they do represent the same type of data,
some kind of integer.
Conceptually they are likely to represent different kinds of data. One is a
numeric value and the other is likely to be a pattern of bits (ok, the hex
value
may be an address value being represented in hex for convenience).
Arrays are normally used to represent a sequence of the same kind of data.
So mixing decimal and hex is suspect.
The situation can be more complex for structures. In this case individual
members can have different uses:
struct {
int some_value;
int some_bits;
int another value;
} information[ 3 ] = { { 23, 0x4f, 43},
{ 0, 0xea, 8},
{ 1, 0x00, 2}};
The list of numeric values are not paired with each other, but the members
of the struct. So mixing decimal and hex in this context makes sense.
A simple coding guideline specifying the decimal and hex literals shall
not be mixed, is too simple. Context needs to be taken into account.
Once we start looking at context we need to consider gems like:
x = y * 0x4e;
and
a = b | 73;
Why would anybody use a hex literal in the context of a multiple, or a
decimal literal in the context of a bit-wise OR operator? Very suspect.
I know what I would like to say about this usage. But having a stated
aim of basing guidelines on experimental results I am stuck between
a rock and a hard place.
>However, I also tend to believe that the cost of this switch will be reduced
>over time as one grows accustomed to the mixing bases.
But how much practice? I do now a handful of people who appear to mix
decimal and hex effortlessly. But then they have spent many years regularly
working in hex as part of their job. I would claim that very few programmers
ever have that sort of exposure to hex.
>We can easily agree that the base mixing in the cited examples (especially the
>"lazy programmer" example) are inconsistant, and can make the list harder to
>read. However, there are examples where such mixing is difficult to avoid. One
>such example is the use of octal numbers (or numbers with another radix) for
>non-printable characters in ASCII dumps.
This kind of mixing is different. Dumps contain blocks of different
representations of the contents of the same memory locations. Readers get to
pick and choose the representation they want to use for a given location.
A representation that has yet to be mentioned is floating-point. This
has the dubious advantage of looking like a decimal integer a lot
of the time (when there is no exponent notation, the presence of a decimal
point does not seem to cause any mental context switch {this is an
unsubstantiated claim}), but not having some of the properties of an integer
representation.
derek
--
Derek M Jones tel: +44 (0) 1252
520 667
Knowledge Software Ltd mailto:[EMAIL PROTECTED]
Applications Standards Conformance Testing http://www.knosof.co.uk
- Automatic footer for [EMAIL PROTECTED] ----------------------------------
To unsubscribe from this list, mail [EMAIL PROTECTED] unsubscribe discuss
To join the announcements list, mail [EMAIL PROTECTED] subscribe announce
To receive a help file, mail [EMAIL PROTECTED] help
This list is archived at http://www.mail-archive.com/discuss%40ppig.org/
If you have any problems or questions, please mail [EMAIL PROTECTED]
