On Nov 21, 2011, at 11:18 PM, Mouse wrote:
a++; // add
one to a
Totally pointless.
[...]
Certainly when I'm annotating previously
unknown assembly [...], I
tend to annotate EVERY line unless it does something stupidly obvious
[...] because I know I can't juggle all the register semantics around
in my head while I'm still discovering them.
Sure, but
incl d4 ; increment d4
is pointless even then. What helps under those circumstances - and, I
would hope, what you do - is
incl d4 ; increment array index
or
incl d4 ; increment count of...whatevers-they-are
or
incl d4 ; compensate for extra decrement inside loop
or some such.
That's what I mean about semantics; labeling the line with "increment d4"
doesn't say anything about what d4 does, while "increment index" does
(though it might seem obvious to the person that wrote it). I tend to be a lot more
verbose when annotating unknown code, mostly because I'm annotating my own assumptions
or discoveries about it ("d4 is incremented" does not count as a discovery).
Or, of course,
if you've been intentionally obtuse about your
variable names
...then, unless you're writing for the IOCCC or some such, you've got
bad code there, in at least that respect.
Well, yes. But sometimes you're given someone else's code, and changing a
variable name to make more sense is a hairy problem.
Of course, one person's "intentionally
obtuse" is another's "why
bother, it's a temporary for all of ten lines of code" or even "what do
you mean obtuse, it's perfectly clear".
Exactly. Different metrics can be a problem. I had a TA grading computer science
homework under me that complained that all the students were using one-letter variables
like i for loop indices - this is the sort of thing that can get carried away (and I
explained to the TA that i and its cousins j and k were fairly mathematically established
loop indices, so yes, it was OK).
(chances are
you should never REALLY have a variable named "a" unless
there's a very good reason to do so),
NODE *sort_nodes(NODE *list)
{
NODE *a;
NODE *b;
NODE *t;
NODE **tp;
if (!list || !list->link) return(list);
a = 0;
b = 0;
while (list)
{ t = list;
list = list->link;
t->link = a;
a = b;
b = t;
}
sort_nodes(a);
sort_nodes(b):
...(merge step omitted)...
}
I am unconvinced this is either a bad use of the names "a" and "b" or
a
case where there's "a very good reason" to use them (x and y, or s1 and
s2, or any of many other choices, would be equally good).
Well, that would fall into the "good enough reason" category for me (though if
it were me, I'd probably arbitrarily call them "left" and "right",
because I found that mildly confusing at first glance; I'd probably keep t, if only
because it is then visually distinct). Obviously, everyone has different metrics for what
makes "good" code.
- Dave