C++ mit stil?

kiba91

hiho, beschäftige mich gearde damit meine Stil zu verbessern und hab da eine Fragen zu coden.

Bei Membervaraiblen solle man ja immer "m_" angeben, aber wie sieht es mit public Varaiblen aus?

hund.m_gewicht = 25.3;
hund.m_name = "Ralph";

hund.gewicht = 25.3;
hund.name = "Ralph";

Was sollte man besser benutzen bei privaten Variablen:
this-> vs. m_

Hab noch gehört das es keine public Varaiblen geben darf sonder nur Getter und Setter Methoden.
Wofür soll dann noch public gut sein?

Jeder Getter und Setter Methoden sollte inline sein.
Aber wie sieht es mit Methoden aus die länger als eine Zeile sind.
Und wie sieht es mit Librarys aus sollte man da inline benutzen?
z.b.

inline void setColor(int p_red){
   p_red = min(p_red,-255);
   p_red = max(p_red,255);
   this->red = p_red;
}

Wie viel Kommetar sollte in einen Code erhalten sein?

/**
*@param a blabla
*@param b blabla
*@param c blabla
*@param d blabla
*@brief blabla
*blabla
*/
void funk(int a ,int b, int c,int d);

/**
*@param var blabla
*@param var2 blabla
*@brief blabla
*blabla
*/
void funk2(Obj var ,Obj var2);

Das wird das ja eine Endloser Code.

Hab ihr noch weitere Tipps und gibt es eine Seite bzw. Anleitung an der sich jeder Programmier halten sollte welchen Stil man benutzen sollte.

unskilled

Wiedermal nen wunderschönes Streitthema

Bei Membervaraiblen solle man ja immer "m_" angeben

Wer sagt denn, dass man das soll?
Manche machen es und andere finden es überflüssig und finden, dass es dann einfach scheiße aussieht - z.Bsp. ich ^^

aber wie sieht es mit public Varaiblen aus

Gibt es nicht.

Wofür soll dann noch public gut sein?

schon mal was von funktionen gehört? ^^

Jeder Getter und Setter Methoden sollte inline sein.

1. stimmt das nicht
2. wird jeder vernünftige compiler selbst entscheiden, wann er etwas inline machen möchte und wann nicht - dazu bedarf es imho nicht mal dieses schlüsselwortes...

Wie viel Kommetar sollte in einen Code erhalten sein?

In Headern so viel, damit man so viel wie möglich dort nachlesen kann. Aber selbst da sollte es nicht all zu viel zu kommentieren geben - wenn man mit Doxygen o.ä. arbeitet und jede Fkt dokumentieren möchte, dann ist das eben so, dass es viel Quellcode wird - bzw. viele Kommentare.
Ansonsten kommentiert man nur das, was nötig ist - z.bsp. warum man Algorithmus xyz genommen hat und nicht den abc.

bb

Kauf dir "Die C++ Programmiersprache" von Bjarn. Da steht das alles drin.

drakon

unskilled schrieb:

aber wie sieht es mit public Varaiblen aus

Gibt es nicht.

Gibt es sehr wohl..
Wo und wann man sie einsetzt ist aber ein anderes Thema..

kiba91

Wann sollte man den public einsetzen oder getter/Setter Methoden, oder ist das stil sache.

pair

unskilled

@drakon
ok - war ein wenig (sehr) unüberlegt ^^

kiba91 schrieb:

Wann sollte man den public einsetzen oder getter/Setter Methoden, oder ist das stil sache.

nein.
je nach dem, was sinnvoller ist - also eigtl immer getter+setter - es sei denn, es ist nur ne kleine hilfsklasse - für nen listenknoten z.bsp.

bb

Nexus

kiba91 schrieb:

Bei Membervaraiblen solle man ja immer "m_" angeben, aber wie sieht es mit public Varaiblen aus?

Nein, sollte man nicht. public -Variablen hast du eher selten. In diesen Fällen entscheidest du - wie auch in fast allen anderen Stilfragen - selbst, wie du die Bezeichner wählst (es sei denn, du musst dich aufgrund der Arbeit oder so an einen Stil halten).

kiba91 schrieb:

Jeder Getter und Setter Methoden sollte inline sein.

Nein.

kiba91 schrieb:

Wie viel Kommetar sollte in einen Code erhalten sein?

Pauschale Richtlinien à la Javadoc halte ich für lächerlich. Ein Beispiel:

/**
 * Gibt den Wert an der Stelle index zurück.
 * @param index Index, an dessen Stelle man den Wert will
 * @return Wert an der Stelle index
 */
int my_array::at(int index)
{
   // ...
}

Nein wirklich. Ich finde es gut, wenn man über eine Funktion kurz schreibt, was sie macht. Aber oft ist das auch unnötig, zum Beispiel, wenn der Funktionsname bereits alles aussagt. Allgemein ist es eigentlich überflüssig, zu kommentieren, wenn sich der Sinn direkt aus dem Kontext ergibt und leicht ersichtlich ist. Das ist teilweise sogar gefährlich, nämlich wenn man etwas an der Funktionalität ändert und vergisst, den Kommentar anzupassen. Dann sind keine Informationen immer noch besser als falsche.

kiba91 schrieb:

Hab ihr noch weitere Tipps und gibt es eine Seite bzw. Anleitung an der sich jeder Programmier halten sollte welchen Stil man benutzen sollte.

Ja. Am wichtigsten davon ist wohl, dass (vorausgesetzt, du hast die Möglichkeit) du dir nicht von irgendeiner Leitlinie deinen Stil vorschreiben lässt und beginnst, in Gut und Schlecht zu unterteilen.

Hab ihr noch weitere Tipps und gibt es eine Seite bzw. Anleitung an der sich jeder Programmier halten sollte welchen Stil man benutzen sollte.

konsequent den stil durch zu ziehen
ist wohl das wichtigste
am besten schaust du mal hier im forum hier gibts einige beiträge und diskusionen dazu. wenn du dich damit beschäftigst findest du deinen persönlichen stil der aber am besten nicht zu extravagant ist