3. schreibweise empfehlungen

schreibweise empfehlungen

  • E

    heiho

    ich hab mal wieder meinen aelteren code durchgeschaut, was ich in laufe der jahre so alles getippt hatte

    dabei ist mir mal wieder aufgefallen das ich staendig meine schreibweise geaendert habe
    ich hab wieder eine angewohnheit gefunden

    aber ich frag mich ob diese auch ueberhaupt gut ist
    darum frag ich, was findet ihr besser lesbar:

    // - innerhalb der klammer leerzeichen am anfang und ende
//------------------------------
int pt::affenbla( int args )
int pt::affenbla(int args)
//------------------------------

// - allgemeine leerzeichen behandlung
//------------------------------
std::vector<std::string>str;
std::vector< std::string >str;
std::vector<std::string> str;
std::vector< std::string > str;
//------------------------------

// - leerzeichen in klammer von diversen aktionen und zwischen operatoren
//------------------------------
for(int i=0; i<len; ++i)
for( int i=0; i<len; ++i )
for(int i = 0; i < len; ++i)
for( int i = 0; i < len; ++i )
//------------------------------

// - die { nach dem kopf oder auf eine neue zeile
//------------------------------
void func(){
void func()
{
//------------------------------

// - leere klammern durch ein leerzeichen deutlicher hervorheben
//------------------------------
void func()
void func( )
//------------------------------

// - operatoren mit oder ohne leerzeichen
//------------------------------
void operator+(...)
void operator + (...)
void operator+ (...)
void operator +(...)
//------------------------------

// - lange parameter untereinander
//------------------------------
int callfunc(int arg1, int arg2, int arg3, int arg4, int arg5, int arg6, int arg7, int arg8, int arg9, int arg10, int arg11, int arg12, int arg13)
int callfunc(int arg1,
             int arg2,
             int arg3,
             int arg4,
             int arg5,
             int arg6,
             int arg7,
             int arg8,
             int arg9,
             int arg10,
             int arg11,
             int arg12,
             int arg13)
//------------------------------

// - kommentieren von funktionen
//------------------------------
/*-------------------------------------
funktionsbeschreibung
-------------------------------------*/
///////////////////////////////////////
// funktionsbeschreibung
///////////////////////////////////////

//------------------------------

    in diversen buechern find ich immer verschiedene variationen
    ich hab schon soweit die angewohnheit lieber eine leerzeile mehr als alles kompakt,
    ist angenehmer zu lesen fuer das auge, find ich zumindest

    was sind denn so eure schreibweisen und was findet ihr eine "gute" schreibweise ?
    {bei den comments geht natuerlich sehr viel}

    wuerde mich ueber meinungen freuen {o;

    0
  • R

    1. Meine Schreibweise: int pt::affenbla(int args) Hier finde ich die Leerzeichen nicht unbedingt hilfreich. Die Klammern trennen imho schon genug ab und mit eingeschaltetem Syntax-Highlight erkennt man das imho sofort
    2. std::vector<std::string> str; aus Gewohnheit hier ein Leerzeichen vor dem Variablennamen, damit das mit nicht-templates gleich bleibt
    3. for(int i = 0; i < len; ++i) Ich mache immer Leerzeichen bei Binären-Operatoren, da diese sonst schnell untergehen und um < schneller von Templates unterscheiden zu können
    4. void func() { (mit einem Space dazwischen). In einer neuen Zeile mache ich die { nur, wenn ich entweder die Parameterliste umgebrochen habe oder zB Initialisierungs, try/catch oder Vererbungen habe. Ich finde das { in einer neuen Zeile nicht unbedingt förderlich fürs lesen, da man ja eh einrückt und somit mit dem Auge die erste nicht eingerückte Zeile suchen kann. Außerdem kommt man so schneller auf Fehler ala

    if(a);
{
  b();
}
    1. void func() ein Leerzeichen bringt hier imho keinen Mehrwert. Wobei ich aber bei leeren { } immer ein Leerzeichen mache. Ist aber wohl eher Gewöhnungssache
    2. void operator+(...) damit die Syntax die gleiche ist wie bei normalen Funktionen/Methoden
      7. Lange Parameter schreibe ich untereinander. Ich versuche möglichst 80 Zeichen/Zeile einzuhalten. Außerdem macht das die Liste imho
      leserlicher bei langen Parametern (wobei ich dann aber nicht unbedingt jeden Parameter in eine einzelne Zeile packe)
      8. Funktionsbeschreibungen mache ich im Doxygen Stil. Bei längeren Kommentaren /** */ und bei kurzen Kommentaren

    . Aber ich versuche die meiste Zeit den Funktionen sinnvolle Namen und sinnvolle Parameter zu geben.

    Aber das sind natürlich alles Sachen, wo man selbst abwiegen muss was einem besser gefällt. Es gibt natürlich kein absolutes Besser (außer meine Regel natürlich ;)). Vieles gewöhnt man sich ja eh ohne großes Nachdenken an.

    0
  • B

    Ein "dito" an ruedigers gesamten Beitrag.

    0
  • E

    klingt ja schon fast so wie ich das zZt angewohnt habe {seit ein paar monaten}

    // - keine leerzeichen
int pt::affenbla(int args)

// - leerzeichen vor variable
std::vector<std::string> str;

// - keine leerzeichen
for(int i=0; i<len; ++i)

// - die { in eine neue zeile
// die klammer in der selben zeile hab ich extra abgewohnt, da ich ein paar sachen hatte wo schnell die uebersicht floeten ging welche klammer zu welchen gegenpart gehoert usw - wuerde ich beibehalten
void func()
{

// - keine leerzeichen
void func()

// - keine leerzeichen
void operator+(...)

// - alles immer nebeneinander, wozu hat man 21" monitore #gg
int callfunc(int arg1, int arg2, int arg3, int arg4, int arg5, int arg6, int arg7, int arg8, int arg9, int arg10, int arg11, int arg12, int arg13)

// - kommentieren von funktionen
/*-------------------------------------
funktionsbeschreibung
-------------------------------------*/

    brauch ich mir ja nicht so viele gedanken machen #gg

    0
  • A
     

    // kurze Kommentare so, wenn genug Platz ist, in der gleichen Zeile wie die Anweisung

/*
 * längere Kommentare oder Funktionsbeschreibungen so
 * (ggf. leicht modifiziert für Dokumentationsgeneration)
 */

int* ptr; // der Typ heißt int*, nicht int, also beides nach links

int pt::affenbla (int args)
{
    return 0; // bei einfachen returns keine Klammern
}

for (int i = 0; i < len; ++i)
    ; // wenn so was schon leer ist, dann unbedingt auf eine neue Zeile

std::vector <std::list <std::string> > strlistvec; // hier wäre allerdings ein typedef vorzuziehen

void func (void)
{ }

int a = *ptr + 12; // Leerzeichen um binäre Operatoren machen den Code lesbarer

int operator + (MyType lhs, int rhs) // das gilt auch hier
/*
 * Die '{'-Klammer in der gleichen Zeile wie die Funktionssignatur zu setzen
 * (Java-Stil) stört IMHO die Symmetrie ein wenig; wenn die schließende Klammer
 * in einer eigenen Zeile steht, sollte die öffnende das auch tun
 */
{
    return (lhs.toInt () + rhs); // bei komplexeren returns lieber eine Klammer drumherum
}

/*
 * Klammern in Maßen fördern subjektives Wahrnehmen von Prioritäten und
 * verhindern, daß man sich versehentlich vertut, wenn man sich nicht ganz
 * sicher ist bei den Operatorprioritäten
 */
int b = a + (*ptr << 3); 

int callfunc (int arg1, int arg2, int arg3, int arg4,
    int arg5, int arg6, int arg7, int arg8, int arg9,
    int arg10, int arg11, int arg12, int arg13);

    ruediger schrieb:

    Aber das sind natürlich alles Sachen, wo man selbst abwiegen muss was einem besser gefällt.

    Seh ich auch so. Solange sich das in einem gewissen Rahmen hält, ist es eigentlich nicht so wichtig. Hauptsache ist, man hält sich an gewisse grundlegende Stilrichtlinien und vermeidet Dinge wie z.B. Tabs, sonst:

    while ((para[i]!=DUNKNOWN) /* not end of parameter list */
   &&(ltok!=delim)     /* not (normal) delimiter */
   &&(ltok!=END))      /* not end of source */
    {
      putback();
      if (i!=0) expect(',');
      typ=para[i] & TYPEMASK;
      if (para[i] & KREFERENCE)    /* Var parameter */
  {
    lex();
    xtype=datatype;
    /* call by reference */
    if (para[i] & KARRAY)    
      {
        /* array */
        comp_array(&xtype);
      }
    else
      {
        /* normal variable */
        comp_var(&xtype);
      }
    if (xtype!=typ) serror(22);
  }
      else
  /* call by value */
  comp_exp(typ);
      i++;
      ltok=lex();
    }

    Aber wozu gibt es Code-Formatter :p

    0
  • C

    Abgesehen von den letzten beiden Punkten würde ich mich Mr Evil anschließen, aber:

    • zu lange Parameterlisten werden unübersichtlich (spätestens wenn sie breiter sind als der Bildschirm). Wenn es wirklich nötig ist, einer Funktion soo viele Parameter mitzugeben, gruppiere ich die meist und verteile sie dann auf mehrere Zeilen.
    • Kommentare zu Funktionen mache ich im Doxygen-Stil (im Header) bzw. als Einzeiler (bei der Implementierung)

    @aucadia: Tabs sind schon sinnvoll, nur sollte man sie durchgehend verwenden. Lustig sieht es nur aus, wenn du Einrückungen mit Tab und Leerzeichen mischst - und dann die Tablänge korrigierst 😉

    0
  • A

    CStoll schrieb:

    @aucadia: Tabs sind schon sinnvoll, nur sollte man sie durchgehend verwenden. Lustig sieht es nur aus, wenn du Einrückungen mit Tab und Leerzeichen mischst - und dann die Tablänge korrigierst 😉

    Oder wenn man einen Editor verwendet, der 8 Leerzeichen automatisch durch einen Tabulator ersetzt. Das - in Verbindung mit einem Editor, in dem ich die Tabulatorlänge 2 eingestellt hatte - ergibt obiges Gräuel.
    Daher lieber einen Editor verwenden, der Tabs automatisch in Leerzeichen umwandelt 😉

    0
  • E

    @audacia

    bei dir faellt mir auf das du immer statt zusammen ein leerzeichen machst

    void call(int param)
void call (int param)

    das pers. find ich nicht so gut, wenn ich so durber schau sieht das dann immer aus wie eine variable

    @CStoll

    bzgl. den langen parametern, ich selber vermeide auch immer so viele parameter, habs auch extremst selten - mir ist das eingefallen da es in meinen WinAPI wrapper vor allem beim Create schon sehr lang wird:

    void CButtons::OnCreate(const std::tstring& strName, const ELEMPOS& pos, const DWORD& dwStyle, HWND hwndMain, const unsigned int& uiId)
{
	m_Handle = ::CreateWindow(_T("button"), strName.c_str(), dwStyle, pos.m_uiLeft, pos.m_uiTop, pos.m_uiWidth, pos.m_uiHeight, hwndMain, reinterpret_cast<HMENU>(static_cast<ULONG_PTR>(uiId)), 0, 0);

    lange kommentare mach ich ebenfalls nur im header zur kurzen beschreibung was das fuer eine klasse ist und wofuer diese ist - und spaeter fuer docus von veraenderungen {CVS}

    im qu selber mach ich eigentlich immer einzeiler

    was ich aber schon oft hier gelesen habe ist "Doxygen" - was ist das? #googlen_geh

    0
  • B

    Ist schon wieder Sommerloch? 🙄

    ObOnT: Genauso wie rüdiger, außer dass ich bei Konstrukten wie if (...), die also aussehen wie ein Funktionsaufruf, aber keiner sind, noch ein Leerzeichen zwischen Schlüsselwort und Klammer setze. Leerzeichen setze ich ansonsten um binäre Operatoren und nach Kommas und Semikolons.

    0
  • C

    Mr Evil schrieb:

    was ich aber schon oft hier gelesen habe ist "Doxygen" - was ist das? #googlen_geh

    Sowas ähnliches wie JavaDoc - ein Tool, mit dem du Dokumentationen zu deinen Funktionen vorbereiten kannst (dazu schreibst du Kommentare in '/** ... */' oder '/// ...', die dann von Doxygen ausgewertet und zu HTML-Dateien verarbeitet werden können)

    0
Anmelden zum Antworten