Stil, typedef



  • Hallo, eine Stilfrage:

    Eine Library stellt eine Datenstruktur zur Verfügung. Für Programme, die diese
    Library verwenden, ist es typisch, daß diese in Schleifen mit der Datenstruktur
    kommunizieren und dabei Indizes verwenden. Nun scheint es mir aus Gründen der
    Lesbarkeit gut, den verschiedenen Typen von Indices über typedef einen Namen
    zu geben, also etwa

    typedef int elementIdx;
    typedef int subElementIdx;

    Findet Ihr das sinnvoll oder gibts ein Argument, das zu lassen? Was ist dafür
    ein sinnvoller Coding-Standard? elmementIdx, ElementIdx, ElementIdxType...?

    Danke



  • Was ist dadurch gewonnen? Es gibt keine zusätzlichen Typ-Überprüfungen, weil du ja den Quellcode der Bibliothek nicht verändern kannst, nehme ich mal an.
    Ich finde, das ist ein klassischer Fall von "Wähle vernünftige Variablennamen".



  • Probier es aus! Benutze Deinen Trick und benutze ihn gründlich. Sowas muß man selber durchleben, ganz ehrlich.
    Wenn Du Dir nicht daran die Hörner gründlich abstößt, wirst Du jahrelang mit solcherlei Gedanken schwanger gehen.
    Siehe auch die Diskussion über die Ungarische Notation.



  • Decimad schrieb:

    Was ist dadurch gewonnen? Es gibt keine zusätzlichen Typ-Überprüfungen, weil du ja den Quellcode der Bibliothek nicht verändern kannst, nehme ich mal an.
    Ich finde, das ist ein klassischer Fall von "Wähle vernünftige Variablennamen".

    Nein, das war unklar ausgedrückt. Ich schreibe die Library und möchte in der API diese typedefs unterbringen, damit der User-Code nicht so aussieht:

    for(int i=
    {
      for(int j=
    ..
    

    sondern

    for(elementIdx i=
    {
      for(subElementIdx j=
    ..
    


  • cp schrieb:

    Decimad schrieb:

    Was ist dadurch gewonnen? Es gibt keine zusätzlichen Typ-Überprüfungen, weil du ja den Quellcode der Bibliothek nicht verändern kannst, nehme ich mal an.
    Ich finde, das ist ein klassischer Fall von "Wähle vernünftige Variablennamen".

    Nein, das war unklar ausgedrückt. Ich schreibe die Library und möchte in der API diese typedefs unterbringen, damit der User-Code nicht so aussieht:

    for(int i=
    {
      for(int j=
    ..
    

    sondern

    for(elementIdx i=
    {
      for(subElementIdx j=
    ..
    

    Und wie wär:

    for( int element = 0; ... )
        for( int subelement = 0; ... ) {
            // ...
        }
    }
    

    ?

    Du endest ansonsten in deinen Bibliotheken mit 5000 Namen für ganzzahlige Indizes, die aber alle fröhlich ineinander konvertierbar sind, also nichts im Sinne von Sicherheit bringen. Zudem muss der Benutzer anhand der Signaturen der Funktionen immer nachschlagen, was genau da nun eigentlich gemeint ist.
    Aber Volkard hat schon Recht, probier es einfach mal aus 😉



  • Wenn man aus irgend einem Grund nicht size_t als Index-Typ verwenden kann/will, dann finde ich nix dabei einen eigenen Typ per Typedef zu definieren.

    namespace Foo
    {
    typedef int IndexType;
    }
    

    Einen eigenen Typedef für jede "Art" von Index zu machen, wenn im Endeffekt eh alle auf den selben Typ aufgelöst werden halte ich nicht für sinnvoll.

    Und wie man den Typedef nennen sollte hängt natürlich davon ab was für naming Conventions man verwendet. In der Standard-Library wird xxx_t verwendet, also dann vielleicht index_t. In Projekten die CamelCase verwenden dann vermutlich IndexT oder IndexType oder für ganz verwegene auch bloss Index.
    Manche APIs/Libraries verwenden für Typedefs auch ausschliesslich Grossbuchstaben, also dann INDEX.

    Wenn möglich würde ich allerdings einfach size_t verwenden.



  • Bei Indizes stimme ich meinen Vorgängern zu - das sind eigentlich immer Ganzzahlen und das braucht man auch nicht zu maskieren, wenn man davon ausgeht, dass sich nichts grundlegendes am Indextyp ändert.

    Anders siehts meiner Meinung nach bei IDs aus. Ich hab mal ein Framework geschrieben, bei dem verschiedene Entitäten (d.h. Klassen) mit IDs angesprochen wurden. Da gabs dann eine RuleID, CheckpointID usw.
    In meinem Fall waren das simple std::string, da das Framework aber noch weiterentwickelt werden sollte, hab ich tatsächlich mehrmals typedef std::string XyzID geschrieben - so dass bei Bedarf später z.B. long oder andere Dinge als ID benutzt werden können.

    Die frage "typedeffe ich einen simplen Datentyp?" ist also nicht pauschal zu beantworten sondern situationsabhängig.



  • Decimad schrieb:

    Und wie wär:

    for( int element = 0; ... )
        for( int subelement = 0; ... ) {
            // ...
        }
    }
    ?
    

    Auch gut, aber sinnvolle Variablennamen sind Sache des Users, während hier das
    Design der Library überdacht wird. Ich glaube, der User hat es leichter, wenn
    die Methoden der Datenstruktur Argumente haben, deren Typ nicht 'int', sondern
    'elementIdx' oder 'subElementIdx' ist.

    lg



  • Probier's aus!
    (Ich als jemand, der sich die typedefs dann auch mal anschaut, würde dann aber dazu übergehen, statt deinen typedefs eben unsigned int oder sowas zu benutzen^^)



  • pumuckl schrieb:

    Bei Indizes stimme ich meinen Vorgängern zu - das sind eigentlich immer Ganzzahlen und das braucht man auch nicht zu maskieren, wenn man davon ausgeht, dass sich nichts grundlegendes am Indextyp ändert.

    Anders siehts meiner Meinung nach bei IDs aus. Ich hab mal ein Framework geschrieben, bei dem verschiedene Entitäten (d.h. Klassen) mit IDs angesprochen wurden. Da gabs dann eine RuleID, CheckpointID usw.
    In meinem Fall waren das simple std::string, da das Framework aber noch weiterentwickelt werden sollte, hab ich tatsächlich mehrmals typedef std::string XyzID geschrieben - so dass bei Bedarf später z.B. long oder andere Dinge als ID benutzt werden können.

    Die frage "typedeffe ich einen simplen Datentyp?" ist also nicht pauschal zu beantworten sondern situationsabhängig.

    Also ich würde deine ID's jetzt so ungefähr auch als Handles verstehen - und da macht es ja durchaus Sinn, das zu typedef'en, weil man ja evtl. mal auf Hashes umsteigen möchte oder sowas. Voll einverstanden!



  • for( int element = 0; ... ;
    

    Wenn ich doch bloß wüßte, was in mit den ... gemeint ist.

    Eigentlich müßte man auf ranged for loops warten oder an sowas

    for( decltype(...) element = 0; ... ;
    

    denken.

    Und den typedef lokal machen.

    typedef decltype(...) ElementIndexType;
    for( ElementIndexType element = 0; ... ;
    

    aua, ach nee, das ist ja übel.

    💡 auto

    for( auto element = 0; ... ;
    

    So, Problem ist weg.



  • 😕
    Machst du gerade Scherze?^^


Log in to reply