Weil Compiler (mit Präprozessor, Assembler usw.) wie der von IAR für die Entwicklung nicht ausreichen braucht man ja dazu noch unbedingt nötige Sachen wie einen guten Editor (z. B. XEmacs), Prettyprinter (z. B. indent) und Semantik-Prüfer (z. B. splint), aber was ist denn noch empfehlenswert?
Auf der seite von Borland kannst du dir eine Kostenlosse version von Borland++ Downloaden diese software enthählt einen Editor einen Compiler und einen Debuuger.
also wenn du einen guten editor suchst dann schau dir mal source insight an. Der gefällt mir sehr gut.Bei interesse könnt ich dir den mal zumailen.
Editor: UltraEdit, unbedingt mit dem Zusatz CTag ausprobieren CTag hilft beim Navigieren in grösseren Projekten. Versionsverwaltung: CVS Prettyprinter (z. B. indent) ist auch schön, aber meines wissens nicht für C++ freigegeben. Es verschiebt auch sehr viel im Quellcode, was nicht immer gewünscht ist. kann dein Semantik-Prüfer C++, dann schick doch bitte mal einen Link. Oryx
splint kann bisher nur C, aber C++ gibt's ja kaum auf MCs. Und was können denn source insight und Ultraedit, was andere nicht können und macht das wirklich etwas aus? Können die zum Code auch Struktogramme o. ä. anzeigen?
Hi UltraEdit beherscht den sog. Spaltenmodus. Kann man schlecht erklären was das ist aber es arbeitet sich genial damit. Ansonsten beherscht er natürlich SyntaxHighlighting, Projektverwaltung, Programmaufrufe, mehrere Zwischenablagen und ne Menge mehr. Wirklich empfehlenswert wenn auch nicht ganz billig. Matthias
"unbedingt nötige Sachen" sind wirklich nur der Compiler und ein
Plain-Text-Editor.
Der Rest ist Schnickschnack und wer will kann ihn benutzen.
Die Effektivität der Programmierarbeit hängt nämlich nicht von der
Anzahl der benutzten Tools ab. Im Gegenteil, sie sinkt bei jedem neuen
Tool erstmal drastisch ab, nämlich solange, wie man braucht, um das neue
Tool gründlich kennen zu lernen.
Und danach stellt sich erst heraus, ob das neue Tool wirklich was bringt
oder nicht.
Ich habe bisher noch nie einen "Prettyprinter" oder "Semantik-Prüfer"
verwendet und auch nicht vermißt.
Ich vermute mal, ein "Semantik-Prüfer" zeigt mir an, ob die Klammern
ausbalanciert sind. Aber dazu brauch ich doch kein extra Tool, das sagt
mir auch der Compiler mit seiner Fehlermeldung.
Wozu aber ein "Prettyprinter" gut ist, davon habe ich nicht die
geringste Vorstellung.
Wichtig ist auf alle Fälle, daß man mit seinem Editor gut klarkommt und
der auch schön schnell ist. Ich benutze z.B. Borland-C in der DOS-Box,
da ich von Wordstar noch die ganzen Tastenkürzel kenne.
Tastenkürzel sind eminent wichtig, da ja das Suchen und Aufklappen von
Menüs mit der Maus für Auge und Handgelenk wesentlich anstrengender ist,
als ne Taste zu drücken. Wer den ganzen Tag am PC sitzt, wird das
bestätigen können.
Weiterhin wichtig ist auch, daß der Compiler voll auf der Kommandozeile
als Batch lauffähig ist. Der Compilevorgang ist ja eine ständig
wiederkehrende Aktion, die man mehrere 100 bis 1000 Male ausführen muß,
ehe ein Programm fertig ist. Da zählt jede mögliche Automatisierung,
z.B. das eine Batch nach erfolgreicher Compilierung automatisch linkt,
das Hex-File erzeugt und gleich in den MC runterlädt und vielleicht noch
die COM aufmacht, um die Debugmeldungen zu sehen.
Was ich vermisse und was wirklich die Effektivität erhöhen könnte, ist
10-Finger-Blindschreiben. Aber das kann kein Tool für mich tun, sondern
ich muß es selber lernen.
Eine Versionskontrolle ist im Prinzip eine wichtige Sache, aber
erfordert eine Menge Selbstdisziplin und ist meistens sehr umständlich
zu bedienen.
Die einzige praktikable Methode, die ich für mich gefunden habe ist, ein
Unterverzeichnis mit dem aktuellen Datum zu benennen, da alles
reinzukopieren und vielleicht noch ein "Readme.txt" reinzuschreiben.
Peter
P.S.:
Ich hab wohl doch schon mal was von "Prettyprinter" gehört, formatiert
wohl den Quelltext komplett um.
Da ich aber nicht gerade mit großer Sehschärfe gesegnet bin, benutze ich
eine abweichende Schreibweise. Um Variablen und Operationen besser zu
erkennen, füge ich Leerzeichen ein. Statt:
if (Variable==Testwert) {
schreibe ich:
if( Variable == Testwert ){
ist halt für mich wesentlich besser lesbar.
@Peter: Klammer-Gleichgewichte gehören zur Syntax, nicht zur Semantik. Deshalb kümmert sich der Compiler darum. Prettyprinter rücken den Code nach dessen Schachtelungs-Tiefe ein; man sieht viel besser was in einer Klammer ist und defaultmäßig ist die schließende geschweifte Klammer ganz übersichtlich genau so tief eingerückt wie die öffnende. Und indent fügt ebenso Leerzeichen ein wie Du. Natürlich kann da viel umkofigurieren. In Rubi ist es umgekehrt: Da bestimmt die Einrückung die Schachtelungs-Tiefe. Mit einem Skript ist das Prettyprinting in einer Sekunde erledigt. Semantik-Checker sind sinnvoll, weil die wahrscheinliche Fehler wie if ( a = 4 ) oder sizeof(array) (mit dem Feld array) ebenso wie ungenutzte Variablen melden. Im Linux-Magazin 5/2003 ist ein Artikel darüber.
@Peter Mit dem Zehnfingertippen gebe ich Dir recht. Ein moderner Editor zeigt Dir z.B. alle Funtionen in einer Datei an. Er kann auch zur Implementierung in eine andere Datei springen. Was macht denn dein Editor bei langen Dateinamen. Deine Unterverzeichnistechnik ist auch gut, aber was ist, wenn mehrere Leute an dem gleichen Quellcode arbeiten. Welche Änderungen sind von der letzen Version zum aktuellen Stand vorgenommen worden. Ein Prettyprinter macht auch Sinn, wenn sich einige Leute nicht an die Einrückabsprachen halten oder man den Quellcode von irgendwo her bekommen hat. Mit einem bisschen Einrücken wird er gleich viel lesbarer. Die Batchdateitechnik ist durch makefiles etwas aus der Mode gekommen. Aber wenns läuft. @nobody Solche Kleinigkeiten sollte der Compiler schon warnen können. Aber auch der GNU versagt da je nach Version schon mal. Und je mahr Warnprogramme über den Quellcode laufen, desto sicherer wird es. Wenn man alle Warnungen denn beachtet und versteht. Der UltraEdit unterscheidet sich von anderer Editoren durch die Navigation im Quellcode. Das ist bei grösseren Projekten schon ein wichtiges Kriterium. Ein drei-Seiten Programm bekommt man nach einiger Zeit auch mit goto's und anderen tollen Befehlen zum laufen. Struktur braucht man da noch nicht. Nachtrag: Im Endeffekt hat Peter recht, auch mit allen erdenklichen Tools muß man seine Programme noch selbst tippen und der Rest ist "Schnickschnack". Nur durch Tools werden die Programme nicht besser. Einige Dinge werden halt konfortabler. Wenn man nur eine if-Anweisung wie von nobody beschrieben oder einen vergessenen switch-Zweig mit den Tools findet, lohnt sich der Aufwand schon. Oryx
Ich finde eine Versionsverwaltung sehr sinnvoll. Wenn man z.B. CVS mal ausprobiert hat merkt man was das ganze in-ordnern-rumkopiere eigentlich für ein Murks ist. Der Lernaufwand ist sehr gering, für den Einstieg reicht es wenn man mal schnell eines der vielen kurzen Tutorials durchliest. Die paar wichtigsten Befehle kann man sich schnell merken, den Rest findet man in ein paar Sekunden in der manpage.
Daß das mit den Ordnern nicht Multiuser fähig ist, da stimme ich voll zu. Aber das CVS ist einfach zu umständlich. Das Aus- und Einchecken ist einfach zu nervig. Da gehört schon ne Menge Selbstdisziplin dazu, nicht ständig ausgecheckt zu bleiben. Außerdem ist das wiederfinden einer bestimmten Version eine Syssiphusarbeit. Wenn ich unseren CVS-Guruy sage, Ich will alle Files der letzten Version vor dem 1.1.1998, dann sagen die, daß ist nicht möglich. Alle Files haben nämlich völlig unterschiedliche Versionsnummern, je nachdem, wie oft man dran gearbeitet hat. Und nach Datum suchen geht schonmal garnicht. Mit meiner Datums-Verzeichnismethode ist das dagegen ein Klacks. Peter
Was meinst du mit "immer ausgecheckt bleiben"? Die Sache ist ganz einfach: man checkt die Dateien aus, arbeitet dran rum, und immer wenn man mal eine funktionierende Änderung gemacht hat gibt man "cvs update" und optional eine Zeile fürs Changelog ein, fertig. Wer hat dir denn den Unsinn mit dem Datum erzählt? Das ist einfach nur falsch. Mit "cvs co -D 1998-01-01 deinprojekt" bekommst du die gewünschte Version. Dass die Dateien unterschiedliche Versionsnummern haben spielt keine Rolle, das ist einfach eine CVS-interne Numerierung. Für die "externen" Versionsnummern (Release 1.0, 2.0, ...), also das was für den Anwender interessant ist, gibt es Tags. Was machts du mit deiner Ordnerstruktur, wenn du z.B. wissen willst was sich seit gestern an einer Datei geändert hat? Mit CVS kein Problem: "cvs diff -u -D yesterday deinedatei.c".
@Andreas, da haben mich wohl die Unix-Gurus total verscheißert. Nochmal zum Mitschreiben: Ich habe z.B. die "kbd.c" am 1.11.97, 1.12.97, 2.1.98 eingescheckt und die "timer.c" am 2.11.97, 31.12.97, 7.1.98. Dan kriege ich also mit Deinem Kommando genau die gewünschte "kbd.c" vom 1.12.97 und die "timer.c" vom 31.12.97 Richtig ? Peter
Ja, du bekommst genau die Dateien die zum angegebenen Zeitpunkt aktuell waren.
@Peter: Ich will dich ja jetzt nicht verunsichern, aber das ganze gibts sogar auch mit Mausbedienung und für Windows... explorerlike - und das nicht erst seit gestern. Schmittchen "früher Verzeichniskopierer, heute VSS-User"
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.