Linked list traversal, compiler's symbol table and duplicate identifier checks

My "textbook" goes:

a)

Obj p = curScope.locals, last = null;
while (p != null) {
    if (p.name.equals(name)) error(name + " declared twice");
    last = p; p = p.next;
}
if (last == null) curScope.locals = obj; else last.next = obj;

Should I refactor along these lines?

b)

if (curScope.locals == null) {
  curScope.locals = obj;
} else {
  Obj p = curScope.locals;
  while (true) {
    if (p.name.equals(name))
      error(name + "declared twice");
    if (p.next == null) 
      break;
    p = p.next; // Good catch, @michaelmior
  }
  p.next = obj;
}

Edit: removed long variable names as I thought they would add clarity of intent but they did not. Thanks @danben. It's obvious that less is more.

Edit: (as I cannot comment back) yes, I should have used the same variable names in the first place. Sorry about that.

Edit:

My thoughts on b) as an "improvement" were:

• one less disposable variable name: p instead of p, last
• p goes out of scope after traversal, identifier freed
• on curScope开发者_如何学JAVA.locals == null to begin with, more logical execution path
• no need for pointer chasing like last = p; p = p.next
• closing assignment not under an if/else

but I am unsure since in b):

• the most frequently executed path is actually under an else branch

Is there a better c) ?

PS: my first question, forgive my initial confusion with the tool, I am still learning.

Now that you changed the variable names in (b), my original answer no longer applies, so I will say this:

Modern compilers are very good at optimization and can render a lot of the programmer's micro-optimizations obsolete. What they can't do, however, is make your code easier for others to understand. So a good rule of thumb to follow is to first and foremost write your code such that it is easy to read.

If, when you are done, you find that your program runs too slowly or takes up too much memory, then find the cause of that particular problem and start optimizing.

Edit: in response to your comment, my answer is that I would not worry about refactoring. The only change I would make would be to reformat (a) such that it is more readable and follows coding conventions. Something like:

Obj p = curScope.locals, last = null;
while (p != null) {
    if (p.name.equals(name)) {
        error(name + " declared twice");
        last = p;
        p = p.next;
    }
}
if (last == null) {
    curScope.locals = obj; 
} else {
    last.next = obj;
}

The extra few keystrokes will save you a lot of headache if you or anyone else decides to add a statement to one of those if or else clauses without remembering to add the braces.

(b) won't work since you never update traverseTableObjectsLinkedList and you'll have an infinite loop. So I prefer (a). Even if you fix it, I don't think there's really much difference and any choice between the two can be chalked up to personal preference.