Wie findet ihr einen solchen Code-Stil?

[Neuling1]

@volkard und rest: Also ihr macht auch Get_My_Line() und nicht getMyLine() oder get_my_line() ?

Da ich noch nicht viel in der Industrie mit programmierung zu tun hatte frage ich mich eben wie es sauber wäre bzw. was die Leute gerne sehen an Stil.

Zudem ist es normal, das man Variablen erst bei ihrer ersten Verwendung deklariert.

hier würde ich gerne nochmal nachfragen:

Also variablen erst deklarieren wenn sie unmittelbar gebraucht werden? So in etwa (sinnloses beispiel aber nur als frage)?

template <class T>
int* Foo_Bar::Get_My_Line(int& a, int& b, int* arr,
                          double c, int line)
{
    double u = 3.3;

    int *arrb = Fill_Array(az, bz);
    for (int i = 0; i < 100; i++)
    {
        arrb[i] = -2;
    }

    int a = 8;
    for (int i = 0; i < a; i++)
          arrb[i] = -1;

    double c = 9.9;
    arrb[0] = c;

    return arrb;
}

[freaky]

Die Benennung pass ich der Klasse an, bzw. wenn mir aufgetragt wird, folgenden Style zu nehmen, werd ich den nehmen. Aber ich mach es eig so:

int* FooBar::get_my_line(int number)

Ja so kommt es eig. öfters bei mir vor.

Eine Variable erst zu benutzen wenn du sie brauchst, kannst du ruhig machen. Meistens mache ich es auch so.

[pumuckl]

Neuling1 schrieb:

@volkard und rest: Also ihr macht auch Get_My_Line() und nicht getMyLine() oder get_my_line() ?

die letzten beiden Varianten hab ich schon gesehen, die erste nicht. Also entweder CamelCase oder unter_striche

Neuling1 schrieb:

Also variablen erst deklarieren wenn sie unmittelbar gebraucht werden?

Ja. Zumindest nahe der Stelle wo sie deklariert werden. Dann muss man im Zweifel nicht erst hochscrollen um zu schauen von welchem Typ Variable xy nochmal war, und man hat nicht irgendwelche verwirrenden Deklarationen im Text stehen die an der Stelle noch garkeinen Sinn ergeben.

[volkard]

Neuling1 schrieb:

@volkard und rest: Also ihr macht auch Get_My_Line() und nicht getMyLine() oder get_my_line() ?
Da ich noch nicht viel in der Industrie mit programmierung zu tun hatte frage ich mich eben wie es sauber wäre bzw. was die Leute gerne sehen an Stil.

ich nehmen nur KlassenName::funktionsName. aber richtung microsoft wirste oft KlassenName::FunktionsName sehen und in nder anderen reichtung gehts bis klassen_name::funktions_name
und da gibt es kein besser oder schlechter, man macht einfach das, was im unternehmen üblich ist. kannst ja schlecht die bestehenden bibliotheken so verfummeln, daß der anwender dann

void FooBar::GetMyLine(){
  foo_bar_base::get_my_line();
  if(Error) throw Foo_Bar_Exception(Error);
}

schreiben muß.

[hartmut1164]

pumuckl schrieb:

Neuling1 schrieb:

Also variablen erst deklarieren wenn sie unmittelbar gebraucht werden?

Ja. Zumindest nahe der Stelle wo sie deklariert werden. Dann muss man im Zweifel nicht erst hochscrollen um zu schauen von welchem Typ Variable xy nochmal war, und man hat nicht irgendwelche verwirrenden Deklarationen im Text stehen die an der Stelle noch garkeinen Sinn ergeben.

Eine Funktion/Methode sollte auch nie laenger sein als eine Bildschirmseite (vielleicht noch zwei).

[pumuckl]

hartmut1164 schrieb:

Eine Funktion/Methode sollte auch nie laenger sein als eine Bildschirmseite (vielleicht noch zwei).

Das auch. wobei eine Bildschirmseite schon sehr viel ist, 10-15 Zeilen sind meist schon mehr als genug. Trotzdem gehören Deklarationen von Variablen dort hin wo sie verwendet werden, wo sie sinnvoll initialisiert werden können (meist erst unimttelbar vor der verwendung), und wo sie nicht aus dem Kontext gerissen werden (und der Kontext beginnt dort wo sie verwendet werden).

[volkard]

neulich im c-forum gefunden.

//noch schnell compilierbar gemacht
template<typename T>
void toNull (T *arr,size_t size)
{
	for(size_t i=0;i!=size;++i)
		arr[i]=0;
}

int main()
{
    char szPlaintext[999], szCiphertext[999],c;
    char szKey[999];
    int i=0, j=0;

    toNull (szPlaintext, 999);
    toNull (szKey, 999);
    toNull (szCiphertext, 999);

    printf("Bitte geben sie den zu verschluesselnden Text ein!\n");
    gets(szPlaintext);
    printf("Bitte geben sie den Key ein\n");
    gets(szKey);

    c=*szPlaintext;

    while (c)
    {
        szCiphertext[i] = c^szKey[j];
        szCiphertext[i] += 65;
        i++;
        j++;
        if (szKey[j] == 0)
            j=0;
        c=szPlaintext[i];
    }

    for (j=0;j<i;j++)
        printf("%c", szCiphertext[j]);

    return 0;
}

ich würde wetten, daß das viel hübscher aussehen würde, wenn alle variablen so spät wie möglich angelegt werden würden-

[pumuckl]

volkard schrieb:

neulich im c-forum gefunden.

template<typename T>

[Neuling1]

Ja dass man schleifenvariablen kontext-mässig setzt ist mir auch klar....also for(int i...) und nicht int i; for(i...). Aber ich frage mich ob es nicht übersichtlicher ist alle variablendeklarationen am anfang zu haben als block weil so weiß man ja wo sie zu finden sind immer. Wenn man irgndwo in der mitte ein variablendeklaration sucht und erst die ganze funktion bis an die stelle laufen muss wo sie deklariert wurde könnte das, vorausgesetzt die funktion ist länger, länger dauern.

Andere Frage: Benutzt ihr Informationen für eure Variablennamen die euch den Typ verraten? Also so i für int und d für double oder p für Pointer:

int iHouse;
double dEpysilon;
int* piMyArray;

?

[volkard]

Neuling1 schrieb:

Also so i für int und d für double oder p für Pointer

nein.

[volkard]

Neuling1 schrieb:

Aber ich frage mich ob es nicht übersichtlicher ist alle variablendeklarationen am anfang zu haben als block weil so weiß man ja wo sie zu finden sind immer.

direkt vor der verwendung!

nicht

...
    c=*szPlaintext;
    while (c)
...

und mal schnell oben gucken, sondenr einfach

...
    char c=*szPlaintext;
    while(c)
...

oder wenn man lust hat, noch ein wenig lokaler

...
    while(char c=*szPlaintext)
...

[Dravere]

Neuling1 schrieb:

..., vorausgesetzt die funktion ist länger, ...

Was sie aber bekanntlich nicht sein sollte
Zudem und da kommen wir zu deiner anderen Frage:

Neuling1 schrieb:

Andere Frage: Benutzt ihr Informationen für eure Variablennamen die euch den Typ verraten? Also so i für int und d für double oder p für Pointer:

Nein, denn der Typ ist meistens nicht wichtig zu wissen. Es ist viel wichtiger, das Konzept vom Typ zu wissen und das sieht man bei der Verwendung.
Zudem kann man das oft gar nicht so genau definieren. Wie machst du sowas bei den Templates? Oder wenn du einen Smartpointer hast, setzt du da ein p davor? Oder ist das dann doch kein Zeiger?

Das einzige was ich mache ist das verpönte m_ vor Klassenvariablen. Aber das ist mehr für mich, weil ich das Gefühl habe, dass es die Übersichtlichkeit erhöht. Aber das ist Geschmacksache.

Grüssli

[C++Fan 2009]

hartmut1164 schrieb:

Eine Funktion/Methode sollte auch nie laenger sein als eine Bildschirmseite (vielleicht noch zwei).

Mit switch/case Blöcken darfs auch etwas länger sein.

[asc]

C++Fan 2009 schrieb:

Mit switch/case Blöcken darfs auch etwas länger sein.

Ganz davon abgesehen das man teils mittels OO-Techniken viele switch/case reduzieren oder gänzlich streichen kann, würde ich selbst bei solchen die sich nicht einsparen lassen lieber die Behandlung in Funktionen auslagern.

Auch wenn ich mich selbst nicht 100%ig daran halte, sind Funktions-/Methodenrümpfe die auf eine Bildschirmseite passen deutlich lesbarer, als solche die sehr lang sind - Egal aus welchem Grund. Was das Auge mit einem Blick umfassen kann ist einfach lesbarer. Ist etwa so wie ein Text mit oder ohne einzelnen Abschnitten.

cu André

[pumuckl]

C++Fan 2009 schrieb:

Mit switch/case Blöcken darfs auch etwas länger sein.

Nur wenn es mehr als halb so viele cases wie Zeilen auf dem Bildschirm gibt.

[C++Fan 2009]

asc schrieb:

C++Fan 2009 schrieb:

Mit switch/case Blöcken darfs auch etwas länger sein.

Ganz davon abgesehen das man teils mittels OO-Techniken viele switch/case reduzieren oder gänzlich streichen kann, würde ich selbst bei solchen die sich nicht einsparen lassen lieber die Behandlung in Funktionen auslagern.

Wenn man OO benutzt um ein effizientes Sprachmittel wie switch Anweisungen zu umgehen, macht man was falsch.

[Shade Of Mine]

C++Fan 2009 schrieb:

asc schrieb:

C++Fan 2009 schrieb:

Mit switch/case Blöcken darfs auch etwas länger sein.

Ganz davon abgesehen das man teils mittels OO-Techniken viele switch/case reduzieren oder gänzlich streichen kann, würde ich selbst bei solchen die sich nicht einsparen lassen lieber die Behandlung in Funktionen auslagern.

Wenn man OO benutzt um ein effizientes Sprachmittel wie switch Anweisungen zu umgehen, macht man was falsch.

Nein.

Die meisten switches sind durch dynamisches dispatching ideal zu loesen. Natuerlich gibt es Faelle wo ein switch einfach das beste ist - aber es tut nicht weh vor jedem switch sich darueber gedanken zu machen. Denn idR ist das switch nur eine auspraegung von vergessener dynamik (die nicht zwangslaeufig ueber OO implementiert werden muss).

[C++Fan 2009]

Shade Of Mine schrieb:

Die meisten switches sind durch dynamisches dispatching ideal zu loesen.

...mit viel mehr sinnlosem Overhead.

Shade Of Mine schrieb:

Denn idR ist das switch nur eine auspraegung von vergessener dynamik.

Kannst Du das genauer darstellen? Was meinst Du mit "vergessener Dynamik"?

[volkard]

C++Fan 2009 schrieb:

Shade Of Mine schrieb:

Denn idR ist das switch nur eine auspraegung von vergessener dynamik.

Kannst Du das genauer darstellen? Was meinst Du mit "vergessener Dynamik"?

zum beispiel die tastendispatchmonster

switch(key)
{
  case 'X': moveBack(); break;
  case 'A': moveLeft(); break;
  case 'D': moveRight(); break;
...
}

statt

(*keyToAction[key])();

der benutzer wünsch sich doch eh, daß er dynamisch die tasten neuzuweisen kann.

oder

switch(mob.mobType)
{
  case TROLL: runAway(); break;
  case GOBLIN: kill(mob); break;
  case ...
}

aber dafür (zum tun von was bestimmtem abhängig vom typ) gibts virtuelle methoden.

[asc]

C++Fan 2009 schrieb:

Shade Of Mine schrieb:

Die meisten switches sind durch dynamisches dispatching ideal zu loesen.

...mit viel mehr sinnlosem Overhead.

Zum Einen ist der Overhead meines Erachtens nicht so wesentlich wie du es hier darstellst. Zudem gewinnt man an Flexibilität und Wartbarkeit. Es mag sein das in deinen Anwendung jeder Prozessortakt zählt, aber in meinen Anwendungsbereich ist Geschwindigkeit zwar nicht unwichtig, aber auch nicht das Hauptaugenmerk wenn man mit etwas Overhead ein Programm dafür leicht erweitern und pflegen kann.

Ganz davon abgesehen habe ich schon das ein oder andere Mal erlebt wie der "Overhead" im Endeffekt zu einer höheren Leistung führt. Oder zumindest der Flaschenhals an einer ganz anderen Stelle liegt.

cu André