Wie nennt ihr Maps?

Ethon

idToPathListMapping würde ich vergeben.

Nathan

/ban UN schrieb:

paths finde ich hier den richtigen Namen. Wenn das mehrdeutig ist, wäre paths_by_id noch ok. Erst value, dann key, weil ich beim Durchlesen den Sinn des Keys kenne und mich nur der Wert interessiert. Aber sehr oft reicht nur paths.

+1

/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.

Wenn du plötzlich merkst, dass da eine unordered_map viel besser wäre weil es nicht auf die Ordnung ankommt, nennst du es dann path_unordered_map?

Eine unordered_map ist immer noch eine Map. Ich plädiere auch nicht dafür den exakten Datentypen in den Namen aufzunehmen, sondern die Bezeichnung der abstrakten Datenstruktur, die der Variablen zugrunde liegt.Dafür eignet sich bei einer assoziativen Datenstruktur wie einer std::map eben "Map" oder auch "Dictionary". Da weiss man dann, dass die DS Schlüssel auf Werte abbildet - egal ob es eine std::(unordered_)map istoder irgend eine andere Klasse, die dem selben Konzept folgt.

paths finde ich hier den richtigen Namen. Wenn das mehrdeutig ist, wäre paths_by_id noch ok. Erst value, dann key, weil ich beim Durchlesen den Sinn des Keys kenne und mich nur der Wert interessiert. Aber sehr oft reicht nur paths.

Kann man so machen, ich persönlich tendiere allerdings zum Map-Suffix bei Datenstrukturen die etwas aufeinander "abbilden", also nicht nur die reinen "Paths" enthalten. Ein Set, eine Liste oder einen vektor würde ich allerdings auch einfach nur "paths" nennen.

Finnegan

hustbaer

blockbilder schrieb:

Das ist jetzt eine Map von Routen ID auf vector von Pfaden. Wie würdet ihr sowas nennen?

Kommt drauf an.
Wenn es auf dem Kontext super-deutlich klar ist worum es sich dabei handelt, dann vielleicht einfach PathMap . Oder u.U. sogar nur Paths , wenn das zu keiner Verwechslungsgefahr führt.

Sonst lieber MapRouteIdToPaths oder MapRouteIdToPathList .
PathsByRouteId oder PathListsByRouteId ginge auch.

/ban UN schrieb:

Der Typ hat nichts im Namen zu suchen! Wenn du plötzlich merkst, dass da eine unordered_map viel besser wäre weil es nicht auf die Ordnung ankommt, nennst du es dann path_unordered_map?

Das "map" im Namen kommt ja nicht vom Typ, sondern von der Funktion.
Ich kann eine Variable "map" nennen, wenn sie verwendet wird einen Wert auf einen anderen (oder mehrere andere) abzubilden.
Ob die Variable dabei ne std::map ist ist egal. Kann genau so gut auch ein Array, eine selbst definierte Klasse oder sonstwas sein.

Und dass es in diesem Fall wirklich eine std::map ist kann sicher kein Grund sein einen guten, beschreibenden Namen der Funktion nicht zu verwenden, bloss weil zufällig der Name des Typs darin enthalten ist.

volkard

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.

Kellerautomat

paths bzw pathsById

otze

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.

Shade Of Mine

map

Denn idR ist es die einzige Variable die die Klasse hat.

asc

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.

Finnegan

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

Ethon

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 ?

asc

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.