Der ideale Variablenname enthält so viele Informationen über den Zweck der Variable, wie möglich. Bei der Wahl des Namens sollte man den Advocatus Diaboli mit sich selbst spielen, um zu sehen, ob es Möglichkeiten gibt, den Namen falsch zu verstehen. Diese Punkte sollten dabei berücksichtigt werden:

1. Bist Du konsistent? Verwende überall den selben Namen, um Dich auf einen Sachverhalt zu beziehen. Zum Beispiel: Innerhalb des Quelltextes zum Umgang mit Bindungen in Tk Widgets, sollte ein Standardname w immer dazu verwendet werden, um sich auf das Fenster (Window) zu beziehen, welches mit dem aktuellen Ereignis verbunden ist.

2. Wenn man den Namen außerhalb des Kontextes sieht, wird man verstehen, wofür er steht, oder könnte man ihn mit etwas anderem verwechseln? Zum Beispiel: Der Prozedurname buildStructure könnte in einem anderen Teil des Systems für Verwirrung sorgen. Ein Name wie buildGraphNode beschreibt sowohl zu welchem Teil des Systems es gehört, als auch wofür er wahrscheinlich benutzt wird.

3. Könnte dieser Name mit einem anderen Namen verwechselt werden? So ist es z.B. wahrscheinlich ein Fehler zwei Variablen mit den Namen str und string in derselben Prozedur zu verwenden: es wäre für jeden schwer sich zu merken, welche Variable wofür steht. Stattdessen, sollte man die Namen so ändern, daß sie deren Funktion wiederspiegeln. Wenn die beiden Variablen z.B. als Quelle und Ziel für eine Kopierfunktion verwendet werden sollen, dann sollte man sie src und dst nennen.

4. Ist der Name derart gattungsbezogen, daß er keinerlei Informationen ausdrückt? Die Variable str aus dem letzten Absatz ist ein Beispiel dafür; durch die Änderung des Namens nach src wird der Name weniger gattungsbezogen und damit gibt er mehr Informationen wieder.