Kommentare, Kommentierung, Verständlichkeit.

hustbaer

Das sind keine Kommentare, das ist ne inline Doku.

Bashar

hustbaer schrieb:

Das sind keine Kommentare, das ist ne inline Doku.

Wo wäre dabei das Problem?

Fedaykin

Reyx schrieb:

Ich habe irgendwann mal 'ne ganz gute Definition gelesen:
Kommentare sollen nicht sagen, was der Code macht -> Das sieht man am Code selbst!
Kommentare sollen erklären, warum der Code es so macht, wie er es macht!

im normalfall hat man den Quellcode ja bei bibliotheken nicht mehr vorliegen sondern nur noch den header bzw die doku

Reyx

Fedaykin schrieb:

im normalfall hat man den Quellcode ja bei bibliotheken nicht mehr vorliegen sondern nur noch den header bzw die doku

Richtig, und um die Doku geht's doch hier?

Ich glaube, das wurde von mir falsch verstanden:
Ich meinte nicht das "Kommentieren" von Quellcode, sondern das Mittel "Kommentar" in der Sprache (//, /*, */), welche bei einer Doku auch genutzt wird. Meine Aussage war also viel allgemeiner gemeint

hustbaer

Bashar schrieb:

hustbaer schrieb:

Das sind keine Kommentare, das ist ne inline Doku.

Wo wäre dabei das Problem?

Garkein Problem. Bloss weil hier so oft von "Kommentaren" geschrieben wird. Kommentare und Dokumentation sind halt 2 Paar Schuhe.
z.B. braucht man in vielen Fällen garkeine Doku (z.B. wenn jedem der komplette Sourcecode vorliegt, und alles schön verständlich und sauber und mit bezeichnenden Namen geschrieben ist). Wenn aber schon, dann kann es leicht sein dass die Doxygen/Javadoc/... Kommentare die man zum Erstellen dieser Doku schreibt in ihrer Rohform (also wenn man den Source einfach so liest) ziemlich unübersichtlich sind, und der Code dadurch z.T. schlechter lesbar wird als ganz ohne Kommentare.

Deswegen sollte man das IMHO unterscheiden. Mehr wollte ich damit nicht sagen.

Fedaykin

im Quelltext selber kommentiere ich weniger.... naja weil eben durch viele kommentare dort auch die übersichtlichkeit, vor allem bei vielen Einrückungen verloren geht. Aber im Header versuche ich immer so genau wie möglich zu dokumentieren.

Ich hab ja schon quellcode gelesen von einen assemblerprogrammierer der das erste mal mit c gearbeitet hat. Das nenne ich unübersichtlich. Variablendeklarationen in der art p_x_zi = 0; waren dort ganz normal Die sollte man dann schon kommentieren.

DEvent

bool insert(binaryTree * tree, void * data, (int(cmp*)(void*,void*));

Hat C keinen typedef?

typedef (int(cmp*)(void*,void*) vergleichsFunction;
// Oder wie auch immer das in C/C++ war, sorry lange kein C/C++ mehr geschrieben.

The use of typedef is also valuable when you want to declare things whose declaration syntax is painfully impenetrable, like ‘array of ten pointers to array of five integers’, which tends to cause panic even amongst the hardy. Hiding it in a typedef means you only have to read it once and can also help to break it up into manageable pieces:
typedef int (*a10ptoa5i[10])[5];
/* or */
typedef int a5i[5];
typedef a5i *atenptoa5i[10];

Try it out!

Operatorüberladung gibt es in C wohl auch nicht?

Bashar

DEvent schrieb:

Hat C keinen typedef?

Doch schon, aber wozu?

Operatorüberladung gibt es in C wohl auch nicht?

Nein.

Reyx schrieb:

Ich habe irgendwann mal 'ne ganz gute Definition gelesen:
Kommentare sollen nicht sagen, was der Code macht -> Das sieht man am Code selbst!
Kommentare sollen erklären, warum der Code es so macht, wie er es macht!

Finde ich sehr gut. Ich musste mal an einem Projekt weiterarbeiten, wo ständig
solche Zeilen standen:

i++;  // i wird um 1 erhöht

Da hat man die Hände öfters vorm Gesicht, als auf der Tastatur

Jockel

ten

Bashar schrieb:

DEvent schrieb:

Hat C keinen typedef?

Doch schon, aber wozu?

für selbstgemachte datentypen, z.b. solche, die auf structs und enums basieren unheimlich praktisch...

Fedaykin

/**
*Node ist die grundlegende defintion eines Eintrages in einen
*Binärbaum
*/
typedef struct
{
    void * data; /*<der Zeiger auf das Datenelement dieses Knotens*/
    node * leftChild; /*<der Zeiger auf den linken Sohn dieses Knotens (NULL) wenn es keinen linken Sohn gibt*/
    node * rightChild; /*<der Zeiger auf den rechten Sohn dieses Knotens (NULL) wenn es keinen rechten Sohn gibt*/
} node

wäre mir selber sonst zu umständlich und ist hässlicher zu lesen wenn man immer wieder struct und sowas davor schreiben muss

ten

Fedaykin schrieb:

/**
*Node ist die grundlegende defintion eines Eintrages in einen
*Binärbaum
*/
typedef struct
{
    void * data; /*<der Zeiger auf das Datenelement dieses Knotens*/
    node * leftChild; /*<der Zeiger auf den linken Sohn dieses Knotens (NULL) wenn es keinen linken Sohn gibt*/
    node * rightChild; /*<der Zeiger auf den rechten Sohn dieses Knotens (NULL) wenn es keinen rechten Sohn gibt*/
} node

wäre mir selber sonst zu umständlich und ist hässlicher zu lesen wenn man immer wieder struct und sowas davor schreiben muss

mach's besser so:

typedef struct __node /* den struct namen besser nicht weglassen */
{
    void *data; 
    struct __node *leftChild;  /* typedef kann hier noch nicht verwendet werden */
    struct __node *rightChild; /* weils erst später kommt */
} node_t; /* node_t ist hier besser. an dem _t erkennt man selbstdefinierte typen */
...
node_t myNode; /* ist etwas lesbarer aus als: node myNode */
...

Bashar

ten schrieb:

Bashar schrieb:

DEvent schrieb:

Hat C keinen typedef?

Doch schon, aber wozu?

für selbstgemachte datentypen, z.b. solche, die auf structs und enums basieren unheimlich praktisch...

Das mag sein, ich meinte es aber im bestehenden Kontext und nicht universell.

rüdiger

ten schrieb:

typedef struct __node /* den struct namen besser nicht weglassen */
{
    void *data; 
    struct __node *leftChild;  /* typedef kann hier noch nicht verwendet werden */
    struct __node *rightChild; /* weils erst später kommt */
} node_t; /* node_t ist hier besser. an dem _t erkennt man selbstdefinierte typen */
...
node_t myNode; /* ist etwas lesbarer aus als: node myNode */
...

Ne ne ne, das ist nicht ANSI/ISO kompatibel! Zwei Unterstriche in Bezeichnern sind dem Compiler vorbehalten!

ten

rüdiger schrieb:

Ne ne ne, das ist nicht ANSI/ISO kompatibel! Zwei Unterstriche in Bezeichnern sind dem Compiler vorbehalten!

stimmt, hab' ich auch schon mal gehört.
na, dann nehmen wir einfach was anderes, ein grosses X oder sowas...

Brutus

Oder node_s

CStoll

Fedaykin schrieb:

/**
*Node ist die grundlegende defintion eines Eintrages in einen
*Binärbaum
*/
typedef struct
{
    void * data; /*<der Zeiger auf das Datenelement dieses Knotens*/
    node * leftChild; /*<der Zeiger auf den linken Sohn dieses Knotens (NULL) wenn es keinen linken Sohn gibt*/
    node * rightChild; /*<der Zeiger auf den rechten Sohn dieses Knotens (NULL) wenn es keinen rechten Sohn gibt*/
} node

wäre mir selber sonst zu umständlich und ist hässlicher zu lesen wenn man immer wieder struct und sowas davor schreiben muss

Klar wäre es so klarer als mit dem struct, aber nicht ANSI-konform (der typedef-Name existiert erst am Ende der Definition, also kannst du ihn "innen" nicht verwenden. In C++ kannst du den struct-Namen ohne typedef direkt verwenden ( struct node{void*data;node*left;node*right;}; , in C benötigst du eine Forward-Deklaration dafür:

typedef struct node_ node;
struct node_
{
  void* data;
  node* left;
  node* right;
};

@ten und DEvent: Ja, C hat typedef. Aber das ersetzt auch keine Dokumentation (im Gegenteil - du mußt dem Anwender erklären, was sich hinter dem definierten Begriff verbirgt und wie er ihn einsetzen darf).

Bashar

Man kann auch einfach jeweils den gleichen Namen verwenden.

typedef struct foo { ... } foo;

ten

Bashar schrieb:

Man kann auch einfach jeweils den gleichen Namen verwenden.
typedef struct foo { ... } foo;

kannst auch 'ne instanz anlegen die so heisst:

typedef struct foo { int x; } foo;

int main()
{
  foo foo;  // jetzt blickt keiner mehr durch
}

Bashar

Im anderen Fall blickt man aber auf jeden Fall durch, da man den Struct-Namen nicht ohne das Schlüsselwort 'struct' verwenden kann. Ich frage mich immer wieder, was Menschen dazu treibt, sich die wildesten Namenskonventionen für struct-Tags auszudenken.