ich wollte mal fragen wie ihr eure std::map Variablen benennt?
Sagen wir ich habe so eine map:

std::map<int, std::vector<Path>> x;

Das ist jetzt eine Map von Routen ID auf vector von Pfaden. Wie würdet ihr sowas nennen?
RouteIDs? RouteMap? RouteIDToPaths? RouteIDToPathsMap? Was anderes?

PathMap

Den Datentyp im Name gefällt mir net.

Oder path_dictonary? oder path_lookup?

großbuchstaben schrieb:

PathMap

Den Datentyp im Name gefällt mir net.

Oder path_dictonary? oder path_lookup?

Und wenn du z.B. in C# programmierst, nennst du dein "path_dictionary" dann doch "path_map", weil die entsprechende Datenstruktur in C# Dictionary heisst?

Ich persönlich finde "Map" als Namensbestandteil nicht verkehrt, da weiss man wenigstens direkt worum es sich handelt ohne die IDE bemühen zu müssen, die einem dann vor lauter Templates und abhängigen Datentypen vielleicht doch nicht sagen, kann um welchen Datentypen es sich handelt und man extra nachschauen muss.

Finnegan

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.

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

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

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.

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.)~

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.

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

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

ich würde eine *Klasse* nicht "PathMap" nennen, aber ein *Member* "PathMap" in einer Klasse "Tour", warum nicht ?

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.