Die generelle Gegenfrage lautet: Wenn man schon mit PRIVATEs und PUBLICs arbeitet - wozu dann noch der Aufwand (MEMVAR, Includes), um etwas Nörgelei des Compilers abzuschalten, die nach meinem Dafürhalten höchstens semihilfreich ist? Eine nicht deklarierte Variable wird automatisch PRIVATE. Sie ist in allen aufgerufenen Funktionen sichtbar (außer in Threads, dort nur PUBLICs). Wenn in diesen Funktionen LOCALs oder Parameter mit gleichen Namen definiert werden, werden dort diese herangezogen, nicht die PRIVATEs (LOCALs werden vom Compiler aufgelöst, PRIVATEs zur Laufzeit über eine Symboltabelle). Ich sehe eigentlich nicht, inwiefern man sich mit der Deklarationskontrolle wirklich einen Gefallen tut - ich nutze diesen Compilerschalter jedenfalls nicht. Aber ich habe auch globale und private Variablen auf eine Mindestmaß reduziert und arbeite gewissenhaft mit LOCALs.
Ansonsten stimme ich diesen Punkten zu:
Auf Felder sollte mit Aliasen zugegriffen werden (db->name), damit der Code leichter zu warten ist.
Variablen, die nur innerhalb einer Funktion verwendet werden, sollten immer LOCALs sein. Ausnahme: Sie werden in Makros verwendet.
Für Makros kann man sie jedoch verwenden.
Aber PRIVATEs und PUBLICs sind auch nicht wirklich schlimm. Wer sie für Schalterstellungen/globale Einstellungen verwendet, sollte sich ggf. mit Get-Set-Funktionen und ähnlichen Mechanismen auseinandersetzen. Wer sie verwendet, um zur Laufzeit Codeblöcke zu bauen, sollte sich in der Doku den Abschnitt zu "detached Locals" anschauen und ihn zu verstehen versuchen. Martins Erklärung hierzu, die er gerne wiederholt, ist nämlich nicht richtig.