PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Kommentare



mj
25.05.2004, 00:37
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" ;)

Ray
25.05.2004, 01:12
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

sniper.de
25.05.2004, 01:18
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 :)

i_hasser
25.05.2004, 01:27
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:


// 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 ;)


// 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*)

skyphab
25.05.2004, 09:19
da ich zur zeit mit delphi werkle, mach ich im vorneherein uml-diagramme als konzept und kommentiere dann den quelltext entsprechend:


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

;D *lol*

sniper.de
25.05.2004, 11:29
ein gutes Kommentieren im Quelltext ist eben unablässig ;D

Also D'Espice, geb dir nen Ruck und "lerne" kommentieren :P

TiKu
25.05.2004, 11:33
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.

PuckPoltergeist
25.05.2004, 11:50
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.

Dizzy_Ti
25.05.2004, 13:04
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.

mj
25.05.2004, 13:06
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.

i_hasser
25.05.2004, 13:53
{*------------------------------------------------------------------------------
Hochkomplexe mathematische Prozedur zur Erhöhung der Chargennummer um 1.
-------------------------------------------------------------------------------}

*lol*


// 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.

Dizzy_Ti
25.05.2004, 14:00
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.

i_hasser
25.05.2004, 14:06
Klassenvariable?

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

Also auf

string a;
greifst du mit a.[xyz] zu, auf

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

Dizzy_Ti
25.05.2004, 14:27
Ich hab eigentlich folgende Situation gemeint:


.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.

TiKu
25.05.2004, 14:38
Die hier:


.h
class bestellung
{
privat:
int m_anzahl;
String m_Bestellung;
public:
void sendbestellung();
}
.cpp
void bestellung::sendbestellung()
{
m_anzahl=0;
}

i_hasser
25.05.2004, 14:49
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 ;)

Dizzy_Ti
25.05.2004, 15:02
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.

i_hasser
25.05.2004, 15:23
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.

Hannnibal
25.05.2004, 18:21
Moin,
javadoc kommentare sind auch nett, zb.


/**
* @ param parameter1
* @ throws exptionxxx
**/

mfg

Hannnibal, der wo auch äußerst kommentarfaul ist :]

StrgAltEntf
26.05.2004, 00:11
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.ä.

TiKu
26.05.2004, 00:21
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.

mj
27.05.2004, 11:10
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 :-/

PuckPoltergeist
27.05.2004, 11:49
Deshalb soll ja auch vor jedem Projekt ein Konzept her, was einem auch die Dokumentation unheimlich erleichtert.

Seemann
27.05.2004, 17:44
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

i_hasser
27.05.2004, 17:50
In der Regel bestehen mein Vorüberlegungen darun schonmal alle Header vorzuschreiben :]

Seemann
27.05.2004, 18:00
Original geschrieben von intel_hasser
In der Regel bestehen mein Vorüberlegungen darun schonmal alle Header vorzuschreiben :]
Naja, immerhin besser als nix, aber ich finde gerade bei komplexen Klassenstrukturen sind UMLs doch vorteilhaft. Da hatte ich vor ein paar Tagen ein Schlüsselerlebnis: Ein Kollege will mir sein Programm erklären, er zeigt mir einige Sequenzdiagramme, einige Klassendiagramme und schwupps, der ungefähre Ablauf war mir sofort klar. Klick hats gemacht. Das hätten Codekommentare allein nie leisten können.

i_hasser
27.05.2004, 18:40
Von der Sache her sind die Header ja nix anderes als genauere UML Diagramme - nur nicht so übersichtlich, aber 'nen echten Programmierer interessiert Übersichtlichkeit eh nicht ;D ;)

Marnem
27.05.2004, 20:35
Einer meine Profs meint immer, man programmiert für den Menschen, ned für den Computer. So von wegen schneller machen kann mans immer noch, wenns zu langsam is, wenn mans aber auf ne andere Plattform bringen will, is man mit ner optimierten Version evtl aufgeschmissen.
Wahrscheinlich hat mein Prof einen wie Intel_Hasser in der Hinterhand, der den ganzen Kram dann mal zum laufen bringt. Oder es liegt daran, daß er an Markup-Sprachen wie XML forscht.

i_hasser
27.05.2004, 20:48
Na wenn andere Menschen mit meinem Stiel klarkommen... der C-Compiler tuts auf jeden Fall *chatt*

Seemann
27.05.2004, 21:46
Original geschrieben von Marnem
Einer meine Profs meint immer, man programmiert für den Menschen, ned für den Computer. So von wegen schneller machen kann mans immer noch, wenns zu langsam is, wenn mans aber auf ne andere Plattform bringen will, is man mit ner optimierten Version evtl aufgeschmissen.
Naja, das ist ja genau das, was objektorientierte Gurus wie z. B. Martin Fowler sagen (sinngemäßes Zitat): "Schreib ordentlichen, leicht verständlichen Code. Denn hast du später bessere Ansatzpunkte um zeitkrtische Stellen zu optimieren". Und da hat er Recht, Spgahetticode kannst du nicht wesentlich verbessern, leicht wartbaren Code schon - zumal noch die Marnems Plattformunabhängigkeit hinzu kommt: Saubere Kapselung von plattformspezifischen Routinen erleichtert eine einfache(re) Austauschbarkeit.

Um aufs Thema zurück zu kommen: Ein sauberes Softwaredesign erspart so manche Kommentarzeile.

PuckPoltergeist
27.05.2004, 22:46
Original geschrieben von intel_hasser
In der Regel bestehen mein Vorüberlegungen darun schonmal alle Header vorzuschreiben :]

Und das ist falsch. Bei der Konzeption hat Quellcode rein gar nichts zu suchen, nicht mal in Form von headern.

Und es stimmt, um Effizienz macht man sich als Allerletztes Gedanken. Mit einem sauberen Design und einer ordentlichen Umsetzung selbigen kann man ineffiziente Stellen auch im Nachhinein recht einfach ausmerzen. Andersherum geht es nicht.

i_hasser
27.05.2004, 22:54
Gekapselt wird nur um Code zu sparen - ganz im Sinne von C ;D

Und ich plane doch lieber in der Reihenfolge in der ich das für richtig halte - ist mir ehrlich gesagt wurscht ob da Header was zu suchen haben oder nicht. Header sind kein Code, sondern Header - basta. Bei Headern wird nix in Maschinencode übersetzt.

Im Endeffekt sind Header eben wirklich nix wirklich anderes als UML, nur für den Compiler und net schön bunt mit Diagrammen für den Menschen.

Ray
28.05.2004, 02:06
Original geschrieben von PuckPoltergeist
Und es stimmt, um Effizienz macht man sich als Allerletztes Gedanken. Mit einem sauberen Design und einer ordentlichen Umsetzung selbigen kann man ineffiziente Stellen auch im Nachhinein recht einfach ausmerzen. Andersherum geht es nicht.
Sehr gefährliche Vorgehensweise, klingt nach alter Schule. Das ist für Leute, welche ewig an ihrem Programm basteln können.

Was hat man von einem wunderschöne Konzept, welches zwar nach Implementierung die statischen Tests ohne Fehler durchläuft, aber im Echtzeitbetrieb kläglich versagt und man beim nachträglichen Versuch des Verbesserns feststellen muß, dass man eigentlich alles hätte ganz anders machen müssen... Typische Fallen bei Diplomarbeiten und den ersten SW-Projekten: Man will es besonders strukturiert und schön machen.
Effizienz und ordentlicher Entwurf müssen gleichzeitig daher kommen. Wie heisst es so schön: Optimierung an der Quelle. Es dürfen keine großartigen Optimierungen nachträglich notwendig sein - dazu hat man im wahren Programmiererleben keine Zeit!

Ciao,
Ray

i_hasser
28.05.2004, 02:31
Was hat man von einem wunderschöne Konzept, welches zwar nach Implementierung die statischen Tests ohne Fehler durchläuft, aber im Echtzeitbetrieb kläglich versagt und man beim nachträglichen Versuch des Verbesserns feststellen muß, dass man eigentlich alles hätte ganz anders machen müssen...

Aktuelle PC Spiele die 3GHZ Boliden und mehr vorraussetzen, wo die Hälfte längst genug wäre.

Wann war eigentlich mein letzer Seitenhieb auf Windows? Ist ja auch schon wieder eine Weile her... ;D

TiKu
28.05.2004, 02:39
Original geschrieben von intel_hasser
Wann war eigentlich mein letzer Seitenhieb auf Windows? Ist ja auch schon wieder eine Weile her... ;D Heißt das jetzt, dass Du Windows für gut konzipiert hältst oder hältst Du es für schnell?;) Ich glaube, der Seitenhieb war eher ein Rohrkrepierer.*buck*

i_hasser
28.05.2004, 02:54
Nö - der hat (imho) schon gepasst.

Gib m$ 10 Jahre Entwicklungszeit (wohlgemerkt darf sich sonst nix ändern) und dann kommt (vielleicht) ein ordentliches OS raus ;D


PS Gute Konzepte brauchen auch ihre Zeit *buck*

Seemann
28.05.2004, 07:40
Original geschrieben von intel_hasser
Aktuelle PC Spiele die 3GHZ Boliden und mehr vorraussetzen, wo die Hälfte längst genug wäre.

Wann war eigentlich mein letzer Seitenhieb auf Windows? Ist ja auch schon wieder eine Weile her... ;D
Ja, aber das ist doch in Wirklichkeit das Problem: Zeitdruck um etwas auf den Markt zu werfen. Die fast logische Folge: Wir fangen erst mal an zu Programmieren und schauen dann mal was rauskommt, dann wird ver(schlimm)bessert, die Testtermine werden nicht eingehalten und ein rohes Produkt kommt auf den Markt.

Besser ist es doch erst einmal einen ordentlichen Entwurf zu machen, in dem ich mögliche Eventualitäten berücksichtige und dann erst codiere. Dann brauche ich die UML-Diagramme aus der Entwurfsphase quasi nur "abschreiben". Die Folge: Die Codierung geht viel flotter. Ich habe bei meinem letzten Projekt fürs Studium damit unglaublich gute Erfahrungen gemacht. Sechs Wochen Vorüberlegung und drei bis vier Nächte Code geschrieben. Das Tolle war: Das Programm lief sofort wie es sollte.

PuckPoltergeist
28.05.2004, 08:03
Original geschrieben von Ray
Effizienz und ordentlicher Entwurf müssen gleichzeitig daher kommen. Wie heisst es so schön: Optimierung an der Quelle. Es dürfen keine großartigen Optimierungen nachträglich notwendig sein - dazu hat man im wahren Programmiererleben keine Zeit!

Ciao,
Ray

Ein ordentlicher Entwurf bedingt schon Effizienz. Wenn man es von Anfang an richtig macht, hat man auch keine Probleme den Code später schneller zu machen.

Seemann
28.05.2004, 08:07
Original geschrieben von PuckPoltergeist
Ein ordentlicher Entwurf bedingt schon Effizienz. Wenn man es von Anfang an richtig macht, hat man auch keine Probleme den Code später schneller zu machen.
Wer sich ernsthaft mit der Thematik auseinandersetzen möchte, der sollte mal Martin Fowlers Buch "Refactoring" (aber bitte auf Englisch die dt. Übersetzung ist grauenvoll) lesen, da geht er näher auf solche Techniken ein.

i_hasser
28.05.2004, 14:01
Besser ist es doch erst einmal einen ordentlichen Entwurf zu machen, in dem ich mögliche Eventualitäten berücksichtige und dann erst codiere. Dann brauche ich die UML-Diagramme aus der Entwurfsphase quasi nur "abschreiben". Die Folge: Die Codierung geht viel flotter. Ich habe bei meinem letzten Projekt fürs Studium damit unglaublich gute Erfahrungen gemacht. Sechs Wochen Vorüberlegung und drei bis vier Nächte Code geschrieben. Das Tolle war: Das Programm lief sofort wie es sollte.

Ich sags nochmal - Header sind genauere UML Diagramme ;)

Vorteil ist, dass man, wenn man die Header fertiggeplant hat (natürlich ändere ich dann auch was in den Headern um wenn mir neue Ideen kommen, ist ja nur eine sache von Sekunden) schon das komplette Gerüst für den Quellcode da ist.


@Puck

Viele Dinge werden aber leider erst so richtig zur Laufzeit sichtbar.

Seemann
28.05.2004, 14:16
Original geschrieben von intel_hasser
Ich sags nochmal - Header sind genauere UML Diagramme ;)

Vorteil ist, dass man, wenn man die Header fertiggeplant hat (natürlich ändere ich dann auch was in den Headern um wenn mir neue Ideen kommen, ist ja nur eine sache von Sekunden) schon das komplette Gerüst für den Quellcode da ist.
Mag sein, aber wenn du Software planst hast du im Idealfall auch die Anwender mit am Tisch - und die verstehen in der Regel eher eine Zeichnung als abstrakten Code. Zudem sind Header-Files nicht plattformunabhängig. Codegeneratoren in UML-Tools erzeugen mir übrigens auch das komplette Gerüst...



Original geschrieben von intel_hasser
@Puck
Viele Dinge werden aber leider erst so richtig zur Laufzeit sichtbar.
Schlechte Anforderungsnalyse würde ich sagen...

i_hasser
28.05.2004, 14:27
Tja, würdest du sagen - die Erfahrung belehrt einen ab und zu wieder eines besseren ;)

Aber wo sind Header bitte nicht Plattformunabhängig?!?

Und nochwas - die Anwender dürfte ein UML Diagramm den feuchten ****** interessieren - die wollen nur eine hübsche GUI sehen ;)

Ray
28.05.2004, 15:31
Original geschrieben von intel_hasser
Aktuelle PC Spiele die 3GHZ Boliden und mehr vorraussetzen, wo die Hälfte längst genug wäre.

Wann war eigentlich mein letzer Seitenhieb auf Windows? Ist ja auch schon wieder eine Weile her... ;D
Es gibt noch genug andere Plattformen, für die SW entwickelt wird.
Ich entwickle für Embedded Systems und muß mir quasi jedes MHz mehr bei den Hardware-Kollegen mühevoll erkämpfen ;) , es soll schließlich auch Strom gespart werden. Dasselbe gilt für den Speicherausbau, die Hardware soll ja billig in der Herstellung sein.
Effizienz zielt hier auf Codegeschwindigkeit und Speicherverbrauch gleichermaßen ab.

Die verwöhnten PC-Entwickler sollten mal ein paar Embedded Projekte machen ... ;D
Manche PC-Software könnte so schlank sein :]

Ciao,
Ray

mj
28.05.2004, 16:07
Naja, an sich habt ihr ja alle recht. Eine vernünftige Konzeption und Planung sind das A und O... aber was, wenn am Ende mehr rauskommt, als geplant war? Ich hatte das Projekt als ganz kleines Nachmittagsprojekt begonnen, eine Gästeverwaltung für kleine und mittelgroße Hotels sollte es werden, mehr nicht. Eine Aufgabe für einen langen Sonntag Nachmittag im Prinzip.

Dann kam noch das hinzu, jenes hinzu, am Ende kamen mir noch ein paar Ideen, aber für solche Fälle hab ich immer meinen Palm dabei oder einen Zettel. Mittlerweile sind es vier DIN A4 Seiten voller Notizen und am Palm will ich garnicht mehr zählen... solche Dinge kommen bei mir immer wieder, ich fang etwas ganz kleines an und letzten Endes kostet es mich Tage um Tage des Programmierens bis ich die Lust verliere ;D
Mittlerweile ist das Ding relativ umfangreich geworden und ich hab's als Projekt auf Sourceforge angemeldet: http://sourceforge.net/projects/jhotel

Im übrigen saß ich hierbei die letzten zwei Tage am optimieren und verschlimmbessern. Zum Glück hab ich noch während der Entwicklung der reinen Gästeverwaltung bemerkt, dass mir das ganze langsam über den Kopf wächst, die Entwicklung gestoppt und zumindest den Gästeteil vernünftig durchgeplant.
Das Reservierungs-Management ist aber noch ziemlich chaotisch und durcheinander, das ist völlig ohne Planung innerhalb von zwei Nächten entstanden und die dritte Nacht (gestern Nacht) hab ich mit Optimieren verbracht, so dass Ladezeiten jetzt auch auf langsameren Rechnern akzeptabel werden.

Ray
28.05.2004, 18:24
Original geschrieben von intel_hasser
Ich sags nochmal - Header sind genauere UML Diagramme ;)
Vorteil ist, dass man, wenn man die Header fertiggeplant hat (natürlich ändere ich dann auch was in den Headern um wenn mir neue Ideen kommen, ist ja nur eine sache von Sekunden) schon das komplette Gerüst für den Quellcode da ist.

Aber auf UML-Ebene mußt Du Dich nicht zwangsweise schon auf die Implementierungssprache festlegen. Was Du mit den Headern machst, ist eher die VHIT-Methode.
VHIT -> Vom Hirn ins Terminal. ;)

i_hasser
28.05.2004, 18:43
Die Sprache... ja was gibts denn da großes. C++ und Java. Hmmm... die Header kann ich für beides verwenden ;).
Oder soll ich doch lieber mit VB proggen? *kopfkratz*... Header... was zum Teufel sind eigentlich Header?


98% werden doch eh in C++ oder Java geschrieben, und damit hat es sich ;)
Der Vorteil ist, dass man strukturelle Änderungen eben auch sehr schnell an den Headern gemacht hat - ohne sinnlos gecoded zu haben.

Ray
28.05.2004, 18:47
Original geschrieben von D'Espice
Naja, an sich habt ihr ja alle recht. Eine vernünftige Konzeption und Planung sind das A und O... aber was, wenn am Ende mehr rauskommt, als geplant war?

Nun, es geht ja eh schon weit über das Thema "Kommentare" hinaus, hier fehlt es definitiv am (Selbst)Management. Schön für den Kunden, wenn er am Ende mehr bekommt als vereinbart ... *buck*.
Zu Anfang muß klar sein, ob die Aufgabenstellung wirklich richtig verstanden wurde, dazu dient z.B. das klassische Lasten- und Pflichtenheft. Weiterhin muß man über den ganzen Entwicklungszyklus hinweg die Arbeitsschritte tracken. Dabei fallen Ausreißer (jemand braucht zu lang oder implementiert Dinge welche nicht gefordert sind) auf und man kann gegensteuern. Aus eigener Erfahrung weiß ich, daß man manche Entwickler ab einem bestimmten Zeitpunkt regelrecht stoppen muß. Sie würden sonst einfach weiter machen, weil ihnen immer mehr Ideen kommen. Das gilt natürlich für Projektmanagement im professionellen Umfeld, aber auch für Privatprojekte bieten sich durchaus ein paar Management-Maßnahmen an. Das kann helfen, unnötigen Frust und möglicherweise auch Krach mit dem Partner zu vermeiden... ;)

Sind hier eigentlich "nur" Hobby-Coder oder auch Berufs-Programmierer unterwegs?

Ciao,
Ray

Ray
28.05.2004, 19:03
Original geschrieben von intel_hasser
Die Sprache... ja was gibts denn da großes. C++ und Java. Hmmm... die Header kann ich für beides verwenden ;).
Oder soll ich doch lieber mit VB proggen? *kopfkratz*... Header... was zum Teufel sind eigentlich Header?
98% werden doch eh in C++ oder Java geschrieben, und damit hat es sich ;)
Der Vorteil ist, dass man strukturelle Änderungen eben auch sehr schnell an den Headern gemacht hat - ohne sinnlos gecoded zu haben.
Wie auch immer, wenn 100% klar ist, welche Sprache benützt wird und vor allem, wenn ein System schon existiert und man dieses erweitert, kann man Header direkt benützen. Die Header sind die Interface-Spezifikationen. Machen wir zum großen Teil auch so. Wir benützen z.B. Doxygen in den Headerfiles für ein SDK und generieren daraus ein PDF-File mit der API-Dokumentation für den Kunden, welcher selbst Code entwickelt und auf einer Bibliothek von uns aufsetzt.
In diesem Falle alles in Plain C für eine embedded Plattform, welche im gewissen Maß auch auf dem PC als Simulation läuft.

Bei einem (großen) Projekt, bei dem man von Null anfängt, halte ich aber ein vorangehendes Konzept und den ersten Entwurf z.B. mit UML viel geeigneter.
Wenn mit der UML-Umgebung dabei noch vernünftiger Code generiert werden kann, umso besser.
Für Embedded Systems hab ich dazu noch nichts wirklich brauchbares gefunden.

Ciao,
Ray

PuckPoltergeist
28.05.2004, 19:27
Original geschrieben von intel_hasser
Ich sags nochmal - Header sind genauere UML Diagramme ;)

Das sagt mir, dass du die UML nicht verstanden hast, oder sie vielleicht gar nicht wirklich kennst. Header sind die Implementierung der Schnittstelle. Damit lassen sich weder Abhängigkeiten, noch Beziehungen oder Abläufe darstellen.



@Puck

Viele Dinge werden aber leider erst so richtig zur Laufzeit sichtbar.

Ja, und dann werden sie gelöst. Mit einem sauberen Konzept ist das problemlos möglich.


Mal ganz davon abgesehen gehört die UML zwar zur Spezifikation, doch ist sie weder die gesamte Spezifikation, noch steht sie an derem Anfang. Als erstes hat eine Anforderungsanalyse zu stehen, die Aufstellung eines Pflichtenhefts. Danach kann man sich irgendwann Gedanken über die Realisierung machen.

PuckPoltergeist
28.05.2004, 19:29
Original geschrieben von D'Espice
Naja, an sich habt ihr ja alle recht. Eine vernünftige Konzeption und Planung sind das A und O... aber was, wenn am Ende mehr rauskommt, als geplant war? Ich hatte das Projekt als ganz kleines Nachmittagsprojekt begonnen, eine Gästeverwaltung für kleine und mittelgroße Hotels sollte es werden, mehr nicht. Eine Aufgabe für einen langen Sonntag Nachmittag im Prinzip.

Das würde ich schon von Anfang an ordentlich planen, weil hier schon absehbar ist, dass das schnell unübersichtlich wird.

TiKu
28.05.2004, 19:31
Original geschrieben von Ray
Sind hier eigentlich "nur" Hobby-Coder oder auch Berufs-Programmierer unterwegs?Ich habe einen Nebenjob (neben dem Studium) als Programmierer. Und ich habe auch vor, in die Softwareentwicklung zu gehen.
Ansonsten ist die Programmierung seit über 5 Jahren ein äußerst intensives Hobby von mir.

Marnem
28.05.2004, 22:54
Ich bin Informatik Student, der eher selten als manchmal proggt. Hab aber grad ein 5 1/2 Monatiges Praktikum in einer Softwarefirma hinter mir und dort 1000 h Programmiererfahrung gewonnen :D

Seemann
29.05.2004, 00:26
Original geschrieben von Ray
Hobby-Coder oder auch Berufs-Programmierer unterwegs?

Me: Hochleistungs-Wirtschaftsinformatik-Student an einer privaten Fachhochschule, mit Schwerpunkt Software-Engineering. In den Pflichtpraktikumsphasen bin ich als Anwendungsentwickler tätig. Den IHK-Abschluss als Fachinformatiker / Anwendungsentwickler hab ich zudem noch "nebenbei" gemacht.

Softwareentwicklung ist quasi mein Leben...

PuckPoltergeist
29.05.2004, 16:02
Original geschrieben von Ray
Sind hier eigentlich "nur" Hobby-Coder oder auch Berufs-Programmierer unterwegs?

Ciao,
Ray

Was man so Beruf nennt. ;) Also ich muss nicht gerade wenig fürs Studium programmieren.

Ray
04.06.2004, 00:01
Dann sind ja ein paar angehende Software-Entwickler hier, nicht "nur Programmierer". :)
Beruflich entwickle ich zwar Software, zum Programmieren komme ich aber kaum noch. Die Hauptarbeit liegt in der Planung mehrerer paralleler Projekte, Konzeptarbeit, Verteilung und Tracking von Arbeitspaketen für eine 10 köpfige Entwicklertruppe.
Mit Sourcen habe ich noch in Form von Codereviews zu tun, womit wir bei Coding Style und Coding Rules landen und somit wieder bei den Kommentaren.

mj
04.06.2004, 13:35
Ich bin auch an sich so dazwischen, Informatik-Student (ab nächsten Semester IT-Student, das ist weniger Mathe dafür mehr Elektro-Technik und gleichviel Informatik) ergo viel Programmieren fast schon Pflicht.
Wobei man auf der TU verhältnismäßig wenig programmiert, mit etwas Glück kann man das Vordiplom mit weniger als 100 Zeilen Code schaffen.