Kommentare

mj

Technische Administration, Dinosaurier, ,
Mitglied seit
17.10.2000
Beiträge
19.529
Renomée
272
Standort
Austin, TX
Ich wollte mal nachfragen, wie ihr zu Kommentaren steht. Ich hab mir leider angewöhnt, quasi völlig auf Kommentare zu verzichten. Leider hab ich manchmal das Problem, dass ich meinen Code ansehe und wie'n Auto vor'm Wald stehe... aber ich rede hier nicht nach einigen Wochen sondern am nächsten Morgen. Ist schon oft genug passiert, dass ich in der früh aufwache, einen Blick auf meinen Programmcode von letzter Nacht werfe das einzige was mir einfällt ist "WTF!!??"

In der Regel verbringe ich die erste halbe Stunde eines Programmiertages damit, den Code von gestern Nacht zu verstehen... Wie handhabt ihr das? Schreibt ihr Kommentare? Ich hab's versucht aber festgestellt, dass ich am Ende noch viel verwirrter war weil dann meine Kommentare so ausgesehen haben:

// wird eingelesen
// wird ausgegeben
// ist trivial

Und so weiter, ich weiß da nie was ich schreiben soll :-[ Meine Meinung ist ja, "I don't comment - what was hard to write has got to be hard to read" ;)
 
Gute Quellcodekommentierung ist das A und O beim SW Entwickeln (ebenfalls die Spezifikation VOR dem codieren).
Das fängt damit an, daß man (z.B. in C) vernünftige Funktionsheader benützt, welche neben der Nutzung der Parameter, sofern vorhanden, in wenigen Sätzen beschreibt, was die Funktion macht und auf eventuelle Besonderheiten (Sideeffects, globale Variablen) hinweist. Wenn der Funktionscode dann relativ kurz ist, braucht man dann oft nicht weiter kommentieren.
Undurchsichtig wird es meist, wenn man krampfhaft versucht, Zeile für Zeile neben dem Code zu kommentieren. Besser ist es, einen Kommentarblock zur Beschreibung des nachfolgenden Codeblocks zu benutzen.
Wer im Team arbeitet, tut gut daran, seinen Code mit 1-3 anderen Leuten zu reviewen.

Ciao,
Ray
 
ich programmiere bzw. skripte zwar nur in PHP, aber dennoch sind Kommentare auch für mich unablässig.

ich schreibe dann z.b. bei bestimmten Datenbankabfragen im Zusammenhang mit IF oder ELSE Strukturen einfach mal dezent hin, was denn da so passieren soll.

So weiss ich am nächtsen morgen noch genau, was wie wo zustande kommt :)
 
Inzwischen kommentiere ich je nach Komplexität vom Code. Bei einfachen Sachen lass ich die Kommentare einfach weg, bei komplexen Sachen mach ich das ziemlich ausführlich. Dabei schreib ich aber immer in Englisch, und lasse weg was man nur weglassen kann. Manchmal nehm ich in meinem Kommentaren öfters "->" als im eigentlichen Code *buck*

So sieht zb. ein kleiner Codefetzen aus:

PHP:
	// Temp Stuff
	int i,j,k;
	
	// Counters and CountPtr
	int cnt_ptr;
	int *cnt=malloc(sizeof(int)*list_len);
	
	// Calc Number of Combinations 
	int obj_count=n_over_k(pool_size+list_len-1,list_len);
	
	// Collect a list of Objects to sum 
	int **sum_obj=malloc(sizeof(int)*obj_count);
	for(i=0;i<obj_count;i++) sum_obj[i]=malloc(sizeof(int)*list_len);
	int sum_ptr=0;
	
	// pipe info 
	char *pipe_info=malloc(sizeof(char)*obj_count);
	char *pipe=malloc(sizeof(char)*list_len);
	int pipebreak;
	pipe[0]=24;		// Init Pipe to invalid

Soviel Kommentare setze ich im Schnitt, aber die Sprache ist hier noch deutlich ausformulierter als sonst ;)

Bisher konnte ich aber immer noch durch meinen Code durchblicken, hab mir angewöhnt vor jede Funktion 2 Zeilen Kommentar zu setzen wofür das ganze eigentlich gut sein soll.

EDIT:

Hier gehts schon etwas interessanter zu ;)

PHP:
	// compute bitposition in prime_mat entry
	int32u bitpos;		
	bitpos=prime_mod_tab1[number&0xFF]+prime_mod_tab2[(number&0xFF00)>>8]+prime_mod_tab2[(number&0xFF0000)>>16]+prime_mod_tab2[number>>24];
	
	// bailout if excluded by hardwired primes (could be removed?)
	if(prime_bit_sel[bitpos]==10) return PRIMECHK_NO_PRIME;
		
	// compute bytepos
	int32u bytepos;		// the byte in prime_mat
	bytepos=number/30;
	
	// read data for that value out of prime_mat	
	int32u bitsel;		// specs the absolute bit in given byte
	int8u bitmask;		// specs the bitmask to easy access prime_mat
	int8u valdata;		// dataset in prime_mat


Manchmal neige ich auch dazu in Pseudo-Code zu kommentieren :] (den versteh dann natürlich nur ich *chatt*)
 
Zuletzt bearbeitet:
da ich zur zeit mit delphi werkle, mach ich im vorneherein uml-diagramme als konzept und kommentiere dann den quelltext entsprechend:

Code:
{*------------------------------------------------------------------------------
  Hochkomplexe mathematische Prozedur zur Erhöhung der Chargennummer um 1.
-------------------------------------------------------------------------------}
procedure TGiessofen.Charge_Erhoehen();
begin
  inc(Charge);
  Charge_Ausgeben();
end;

;D *lol*
 
Wie stark ich kommentiere, hängt bei mir ganz von der Tagesform ab. Es passiert leider recht häufig, dass ich etwas einfach nur fertig haben will und dann auf die Kommentare gänzlich verzichte. Hin und wieder kommentiere ich meinen Code aber nachträglich noch.
 
In den Kommentaren soll ja auch nicht stehen, wie eine Funktion oder ein bestimmter Programmabschnitt etwas macht (das sollte der Code schon hergeben), sondern was die Aufgabe ist.
 
Also ich kommentiere meinen Quellcode immer erst nachträglich, damit ich am nächsten Tag sofort weiss, was ich mir gedacht habe.Ich kommentiere nur Stellen, die nicht klar ersichtlich sind, warum ich etwas so programmiert habe.Vor jeder Methode schreib ich genau auf, was sie leisten soll.
 
Naja, die Aufgabe kann ich immer aus den Namen meiner Funktionen ersehen. Ich benutze da immer so vielsagende Namen wie addNewUser, replaceExisting, deleteExisting, getSeek, getOffset, etc.
Was die Aufgabe meiner Funktionen/Methoden/Klassen ist weiß ich eigentlich immer, ich zweifle früh morgens nur immer wieder an meinem Verstand warum sie das grade SO macht und nicht anders.
 
Code:
{*------------------------------------------------------------------------------
  Hochkomplexe mathematische Prozedur zur Erhöhung der Chargennummer um 1.
-------------------------------------------------------------------------------}

*lol*

Code:
// inc chargenum

würde da bei mir wohl stehen.


Wie habt ihr es eigentlich mit der Namensgebung (ok, die Delphianer betrifft das eher weniger)?
Ich habs mir angewöhnt Funktionen immer klein und Klasse immer groß zu schreiben.
 
Ich hab mir angewöhnt beides klein zu schreiben, nur Structs schreibe ich gross.
Wie greift ihr eigentlich auf Klassenvariablen zu?
Ich nehme normalerweise immer this->, damit ich direkt sehe, dass dies eine Klassenvariable ist.
 
Klassenvariable?

Na in C ist das ganz einfach. Entweder hast du direkt eine Klasse erstellt, oder einen Zeiger auf eine Klasse.

Also auf
Code:
string a;
greifst du mit a.[xyz] zu, auf
Code:
string *a=new string();
greifst du mit a->[xyz] zu. Alternativ geht auch (*a).[xyz]

Tja, in C ist das eben alles eindeutig geregelt ;D
 
Ich hab eigentlich folgende Situation gemeint:
Code:
.h
class bestellung
{
privat:
int anzahl;
String Bestellung;
public:
void sendbestellung();
}
.cpp
void bestellung::sendbestellung()
 {
 // Entweder Zugriff auf anzahl mit anzahl=0; oder this->anzahl=0;
 }
Welche Variante nehmt ihr von den beiden?
EDIT:
Aus zugreif zugrief Zugriff gemacht.
 
Zuletzt bearbeitet:
Die hier:

Code:
.h
class bestellung
{
privat:
int m_anzahl;
String m_Bestellung;
public:
void sendbestellung();
}
.cpp
void bestellung::sendbestellung()
 {
 m_anzahl=0;
 }
 
Da mach ich kein this-> davon - wieso auch? Ich kann doch sowieso nur auf lokale, private oder public Variablen der Klasse zugreifen (bzw. greife ich nur auf diese Variablen zu)!?

Also wenn ich dann auf irgendwas nicht-lokales zugreife (idR halte ich die Routinen in den Klassen sehr überschaubar und mach lieber noch 2 Private Funktionen dazu) muss es ja eine Variable der Klasse sein ;)
 
Original geschrieben von intel_hasser
Da mach ich kein this-> davon - wieso auch?
Ich nutzte das this-> ganz gerne, weil der Borland c++ Builder mir direkt dann alle Klassenvariablen anzeigt und ich bei längeren Namen so Zeit sparen kann, weil ich diese nicht ausschreiben muss.
@TiKu
Die Variante ist nicht schlecht, die werde ich mir glaub ich auch angewöhnen.
 
Ach so, na dann... die Zeiten sind bei mir schon lange vorbei ;D

KDevelop zeigt die Variablen glaub ich zwar auch an, aber ich nehms einfach net.
 
Moin,
javadoc kommentare sind auch nett, zb.
Code:
/**
 * @ param parameter1
 * @ throws exptionxxx
**/
mfg

Hannnibal, der wo auch äußerst kommentarfaul ist :]
 
Hmm ja, JavaDoc is eigentlich schon nicht schlecht, aber in der Regel ist ja aus den Methoden- und Parameter-Namen schon ersichtlich, was Sache ist, weshalb ich da oft etwas schreibfaul bin.
Ich kommentier eher im Code irgendwelche Abschnitte, wo nicht auf Anhieb erkennbar ist, was der Sinn der Sache ist bzw. was der Gedanke hinter bestimmten Code-Abschnitten war. "auf Anhieb erkennbar" ist hierbei natürlich immer etwas subjektiv und die Einschätzung kann sich beim späteren Angucken/Ändern schon mal ändern ;) (und wird dann auch i.d.R. korrigiert)

Welche Rolle eine Klasse oder Methode im Gesamtkunstwerk *chatt* spielt, sieht man eh besser an 'nem UML-Diagramm o.ä.
 
Javadoc, Doxygen usw. haben aber einen entscheidenden Vorteil (weswegen ich neuerdings auch Doxygen einsetze): Wenn man sich zu einer guten Kommentierung zwingt, hat man damit am Ende gleich noch ein brauchbares Handbuch bzw. eine ausführliche Übersicht über den Code.
 
UML-Diagramme sind bei mir auch so eine Sache... die Dinge, die man an der Uni programmieren muss schafft man auch blind und ohne UML-Diagramme. Allerdings arbeite ich derzeit an einem etwas größeren Projekt und merke schon, wie mir langsam die Luft und Übersichtlichkeit ausgeht :-/
 
Deshalb soll ja auch vor jedem Projekt ein Konzept her, was einem auch die Dokumentation unheimlich erleichtert.
 
Zuletzt bearbeitet:
Original geschrieben von PuckPoltergeist
Deshalb soll ja auch vor jedem Projekt ein Konzept her, was einem auch die Dokumentation unheimlich erleichtert.
Ja, und vor allem vor dem Programmieren...

Naja, zu Thema Kommentare:
* ja, unverzichtbar um den Sinn einiger Routinen zu verdeutlichen, das WIE erschließt sich meist aus dem Quellcode oder ist uninteressant, wichtiger ist oft das WARUM
* von JavaDoc u.ä. halte ich nicht viel, da: 1. umständlich zu handhaben, 2. bei guter Benamsung nicht nötig und 3. auch die Quellcodedateien enorm aufblähen (Unübersichtlichkeit)
* Verzicht auf Trivialkommentare. Ich hatte mal folgenden Fall: Eine Klasse war fast gar nioht kommentiert, es fanden sich aber etliche Kommentare folgender Art:

i++; // erhöhe i um Eins
 
In der Regel bestehen mein Vorüberlegungen darun schonmal alle Header vorzuschreiben :]
 
Zurück
Oben Unten