Hallo,
ich hoffe, es ärgert sich niemand über diese OT Diskussion...
Vorweg, wir diskutieren hier von unterschiedlichen Standpunkten:
Ich bin kein Pythonese, ich bin nicht schlau genug, um die Konzepte dahinter zu verstehen, zumal ich sie nicht wirklich brauche. Ich komme aus der C-Ecke (Steuergeräteprogrammierung), insofern ist die folgende Erkenntnis völlig richtig:
Darii hat geschrieben:Um Funktionen zusammenzufassen liefert Python ein anderes Mittel: Klassen.
<...>
In C macht man sowas nämlich nur weil es eben keine Klassen gibt.
diesch hat geschrieben:ChrisGTJ hat geschrieben:
Auf die Weise ist durch simples Sortieren ein erster klarer Überblick über die Zusammenhänge möglich.
Um Funktionen, Methoden o.ä. alphabetisch sortiert anzuzeigen benötigt man zusätzliche Werkzeuge, die nicht jeder immer griffbereit hat. Ich gruppiere daher meine Funktionen lieber im Quellcode nach Zusammenhang, so dass sich der Quellcode direkt lesen lässt.
Ist ein Mißverständnis: Die Sortierung ist natürlich im Quelltext. Durch die von Dir eingeforderte konsequente Namensgebung fällt es leicht, die Sinnzusammenhänge auch in der Position der Funktionen, Klassen und Methoden herzustellen.
Wie Du sagst: Tools stehen nicht immer zur Verfügung, vor allem nicht im LKW auf dem kleinen Laptopbildschirm.
diesch hat geschrieben:Wichtiger als die Frage, nach welchem System Bezeichner benannt werden ist IMHO aber, dass das einmal gewählte System auch konsequent durchgehalten wird und für die Zielgruppe verständlich ist.
Das sollten sich alle Entwickler hinter die Ohren schreiben, setzt aber voraus, daß man ein System definiert hat.
Die Namensgebung ist eh heikel. Wenn ich es nicht schaffe, einen prägnanten Namen für eine Funktion, Klasse oder Variable zu finden, dann ist mir selbst möglicherweise gar nicht klar, wozu die überhaupt da sein soll. Das passiert ja üblicherwise gerade dann, wenn ein Designfehler dazu führt, daß wir workarounds implementieren, weil wir das eigentliche Problem nicht vollständig verstanden oder die Lösung nicht passend ist.
EyDu hat geschrieben:ChrisGTJ hat geschrieben:Was die Benamsung angeht: Natürlich braucht eine Klasse einen Namen, der was taugt. In diesem Fall ist der Name aber relativ korrekt gewählt, denn es geht um eine Klasse, die einen allgemenien Dialog darstellt und das hinten stehende 'Class' betont das eben noch. Das 'C_' schreibe ich aus Prinzip dazu. Ich gebe Dir aber Recht: In einem normalen Programm hat sowas genau gar nichts verloren.
Was ist denn an deinem Programm so abnormal, dass es so einen Namen braucht?
Die ungarische Notation wird doch auch in C++ schon seit vielen Jahren nicht mehr verwendet, bzw. nur noch sehr sparsam.
Ich habe den Typen doch gar nicht mit reingeschrieben, insofern verstehe ich den Einwand nicht. Und noch mal: den konkreten Namen 'C_DlgClass' habe ich gewählt, um deutlich zu machen, worum es mir geht. Zumindest das mit 'deutlich' scheint gelungen zu sein...
EyDu hat geschrieben:Besonders spannend wird es immer dann, wenn sich ein Typ ändert und der Name nicht mehr stimmt.
Das hat zwei Seiten:
Wenn die Typinformation nicht unbedingt notwendig ist und trotzdem in einer globalen Schnittstelle verwendet wird, kommt es zu dem im Wikipedia Artikel über die ungarische Notation beschriebenen Problem:
Code: Alles auswählen
Win16: WndProc(HWND hW, WORD wMsg, WORD wParam, LONG lParam)
Win32: WndProc(HWND hW, UINT wMsg, WPARAM wParam, LPARAM lParam)
Das muß man sich natürlich nicht antun.
Auf der anderen Seite gibt es genug Situationen, in denen es auf den Datentypen eben doch ankommt (in nahezu jedem Steuergerät wird es in den Treibern so sein). Und dann bin ich dankbar, wenn ich allein durch die Namensgebung auf Kompatibilitätsprobleme hingewiesen werde, wenn ich auf einem schwachbrüstigen Mikrocontroller mit Bitmasken hantiere (z.B. 32 Bit vs 16 Bit). Den erhöhten Portierungsaufwand nehme ich gern in Kauf, weil es mir ggf. die Hardware eben nicht zerschießt, wenn ich zu doof war, konsequent zu programmieren. Und die Bibliotheken sind in dem Fall inkompatiebel, dann ist es auch egal, ob die Namen nicht passen.
Ich gebe aber gern zu, daß das eher kein Einsatzgebiet für Python ist und für eine API wie die WIN Api ist das natürlich auch keine Option.
Gruß,
Christoph
.
.
), sondern auf der Art (was auch ein Typ ist...).