Wie nennt ihr Maps?
-
Oft leben die maps so kurz, daß es egal ist. Dann paths oder irgendwas.
Langlebigere brauchen bessere Namen. routeIDToPaths oder routeToPaths.Weil irgendwann knallts sonst, weil routeIDToPaths routeNameToPaths und zwanzig weitere alle nur paths heißen wollen. Das nervt ungeheuerlich.
~(Das Problem hab ich übrigens nur mit maps.)~
-
out schrieb:
großbuchstaben schrieb:
PathMap
Den Datentyp im Name gefällt mir net.
Oder path_dictonary? oder path_lookup?
Ich finde das teilweise gar nicht schlecht.
Aber ich bin halt sowas wie der Antichrist was Programmierung angeht.
EDIT:
Gelöscht, war Quatsch.
-
paths bzw pathsById
-
routes würde ich vergeben. das gibt dann in der Anwendung routes[id], womit die Semantik dessen was "routes[id]" zurück gibt, klar ist - eine Route - und weniger, wie eine Route implementiert ist - als Pfad.
-
map
Denn idR ist es die einzige Variable die die Klasse hat.
-
Finnegan schrieb:
/ban UN schrieb:
Der Typ hat nichts im Namen zu suchen!
Sagt wer? Man kann über Sinn und Unsinn diskutieren, aber solche pauschalen Aussagen kann ich nicht gelten lassen.
Wir arbeiten noch immer im C++ Bereich mit einer IDE die keine Refactorings unterstützt. Ich kann nach vielfacher leidvoller Erfahrung in Projekten UN nur zustimmen. Es ist 1000x besser einen Sprechenden, nicht auf den Typen bezogenen Namen zu vergeben, als bei einem Typwechsel den ganzen Code abgrasen zu müssen.
-
asc schrieb:
Finnegan schrieb:
/ban UN schrieb:
Der Typ hat nichts im Namen zu suchen!
Sagt wer? Man kann über Sinn und Unsinn diskutieren, aber solche pauschalen Aussagen kann ich nicht gelten lassen.
Wir arbeiten noch immer im C++ Bereich mit einer IDE die keine Refactorings unterstützt. Ich kann nach vielfacher leidvoller Erfahrung in Projekten UN nur zustimmen. Es ist 1000x besser einen Sprechenden, nicht auf den Typen bezogenen Namen zu vergeben, als bei einem Typwechsel den ganzen Code abgrasen zu müssen.
Bei konkreten Datentpyen wie "huppifluppi_special_splay_tree_map_v12" gebe ich dir absolut recht. Mein Argument bezog sich auch auf den abstrakten Datentyp (ADT) als Teil des Namens wie eben "Map" oder "Dictionary" (beide verwende ich hier Synonym) oder "Queue" oder "Stack". Diese haben stellen nach außen das selbe Interface zur verfügung, egal wie sie konkret implementiert sind. Der ADT als Namensbestandteil gibt schnell Aufschluss darüber wie die Daten logisch organisiert sind und wie man darauf zugreift. Die Idee ist dass der Name die gesamte Familie der konzeptionell kompatiblen Typen abdeckt. Ändert sich auch der ADT, kommt man ohnehin nicht drumherum den gesamten abhängigen Code anzupassen, da sich auch das Interface ändert (ein vector<int> lässt sich nur schwer in eine map<string, int> ändern, ohne die ganzen inserts anzupassen). Namenszusätze wie "Int" oder "String" machen natürlich aus den von dir genannten Gründen keinen Sinn - obwohl es auch hier manchmal Ausnahmen gibt: In einem meiner letzten Projekte musste eine Ganzzahlige ID in einem Codeteil als String vorliegen. Während die ID-Variable lediglich "id" hieß, war der Name der String-Repräsentation "idString", was in diesem Kontext durchaus Sinn machte.
Finnegan
-
Aber "Map" beschreibt genauso wie "List" immer noch nicht einen konkreten Typ sondern nur eine Klasse von verwandten Typen.
-
noch besser ist aber, gleich die richtigen Datentypen auszuwählen - andererseits können einem ein paar Stunden Debugging oder Refactoring locker ein paar Minuten Planung einsparen
ich würde eine *Klasse* nicht "PathMap" nennen, aber ein *Member* "PathMap" in einer Klasse "Tour", warum nicht ?
-
großbuchstaben schrieb:
noch besser ist aber, gleich die richtigen Datentypen auszuwählen
Was nur dann geht, wenn keine Änderung über die Zeit eintritt, die einen Datentyp der ursprünglich "richtig" war später "falsch" ist. Und das kommt in langjähriger Produktentwicklung immer vor (Aktuelles C++ Projekt ist inzwischen mehr als 10 Jahre im Einsatz/Verkauf, letztes Projekt an dem ich mitgearbeitet habe war schon 15 Jahre alt als ich gekündigt hatte).
Da hilft auch keine Planung, das passiert nun einmal über den Lauf der Zeit.