Flattening the namespace again

In sehr frühen Zeiten der Programmierung mussten Namen von Variablen oder Funktionen mit Bedacht gewählt werden, da sie alle global sichtbar waren. Dann wurden Namensräume, d.h. Namespaces erfunden und später über Objekte und für Java auch Packages weiter verfeinert.

Das Package-System von Java, auch schonmal als “Übel Nummer Eins” bezeichnet, hielt selbst gleichnamige Klassen, beispielsweise java.awt.List und java.util.List, zuverlässig auseinander.

Mit dem Aufkommen von modernen IDEs und deren Fähigkeit zur automatischen Namensergänzung (Code Completion, Content Assist, etc.) werden die Namensräume allerdings wieder klein. Dies merkt man besonders dann, wenn man eine gutgemeinte Bibliothek integriert, die beispielsweise eine eigene Klasse File mitbringt.

Die Lösung wird sein, heuristische Verfahren für die Code Completion einzusetzen, mit Prefixen (JList, etc.) zu arbeiten oder sich wieder deutlich mehr Gedanken über die Namensgebung zu machen. Wir haben das Problem nicht gelöst, sondern nur auf eine neue Ebene gehoben.

2 thoughts on “Flattening the namespace again

  1. Hehe “In sehr frühen Zeiten der Programmiereung …”
    Ich hab ein nettes Beispiel für einen Nameskonflikt aus der SW einer namenhaften
    Automobilzuliefererfirma. Ist C-Code. Ich stolperte einmal
    über Warnings beim Übersetzen der Software, dass einige #defines in
    Header-Dateien doppelt definiert sein und überschrieben werden würden.
    Da wir prinzipiell versuchen, den Quellcode ohne auftretene
    Compiler-Warnings zu schreiben, dachte ich mir, fix ich das, war sowieso in der Nähe am codieren.

    Datei 1 sag so aus:
    #ifndef _H_ENG
    #define _H_ENG
    #define get_dsm xyz
    #endif

    Datei 2 sah so aus und bestand nur aus #defines:
    #define get_dsm abc

    Aufgerufen wurde es z.B:
    #include
    #include

    Oder aber auch nur:
    #include

    Oder aber auch nur:
    #include

    Die C-Dateien haben also unterschiedliche Inhalte der get_dsm-defines bekommen.
    Vermutlich wurde ein Teil der SW aus einem anderen Projekt übernommen. Das ganze klappt aber nur, wenn in jeder include-Kette die Reihenfolge die richtige ist und wenn Datei2 auch sicher immer eingelesen wird (deshalb kein #ifndef in Datei 2, könnte eventuell ja schon vorher eingelesen worden sein …). Das nette war, dass wenn man die Anweisung #include rausschmiss, der Code trotzdem übersetzte, wir eine Warning weniger hatten, die Software allerdings an der Stelle nicht mehr das tat, was sie sollte.

    Ich hab dann alles so gelassen wie es ist.

  2. Du kannst irgendwo in den Preferences Namensraeume (Pakete) aus der Autocompletion ausschliessen. Das macht z.B. dann Sinn, wenn Du SWT programmierst und keine AWT-Buttons etc sehen willst.

    Abgesehen davon versucht Mylyn, diese Heuristik in deiner Autocompletion zu gestalten. Ist ein fuerchterliches Feature, das die Reihenfolge der Vorschlaege fortlaufend veraendert. Kann man aber auch in den Preferencen ein- oder ausschalten.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s