[linux-l] Sauberes Programmieren (war: Sort parallelisieren)

[Volker Grabsch]

On Sun, Jan 07, 2007 at 11:30:00AM +0100, Oliver Bandel wrote:
> > Die Antwort in C war dann: Kein "new", stattdessen lokale
> 
> Seit wann kennt C "new"?

C kennt malloc/free. Aber wenn man in C++ ständig new/delete verwendet,
*ist* das letztendlich C-Stil. Natürlich sind new/delete viel sauberer
als malloc/free, aber "richtiger" C++-Stil vermeidet das, so gut es
geht.

Und das funktioniert geht immer, solange die Objekte keinen chaotischen
Lebenszyklus haben. Und selbst dann kann man mit Listen (list<..> bzw.
vector<..>) noch einiges retten.

> > Objekt-Variablen, RAII-Prinzip beachten, Referenzen und Objektkopien
> > statt Pointer. Schon verschwindet ne Menge Boilerplate-Code. Das
> > ganze ist bugfreier, und viel, viel weniger potentielle Segfaults.
> > Bis auf eine einzige Ausnahme kein einziges "delete". Das heißt,
> > keine Memory-Leaks, und trotzdem ohne Garbage-Collector. Das ist
> > etwas, das C++ einzigartig macht. Völlig ungewohnt aus Python,
> > Java, C, ...
> 
> Hmhhh, bin kein C++ Spezi. Klingt aber nett/interessant, was Du schreibst.

Neugierig?

Vielleicht solltest du C++ wirklich mal ne Chance aber. Aber wiegesagt,
erstmal den C++-Stil aneignen, das ist ein steiniger Weg. Man sieht viel
C++-Code, der im C-Stil geschrieben wurde (... obwohl C++-Features
verwendet werden). Auch sieht man viel C++-Code, der im Java-Stil
geschrieben wurde.

Im Netz findet man kaum was ordentliches, aber wirklich empfehlenswert
ist das Buch:

    "The C++ Programming Language"
    Bjarne Stroustrup
    http://www.research.att.com/~bs/3rd.html

Es ist vom "C++-Erfinder" geschrieben und deckt nicht nur Formalitäten
aber, sondern auch Herangehensweisen, Methodiken, Stil.

> > > Aber es gibt Leute, die einfachgrundsätzlich zu
> > > faul sind, Fehlerbedingungen abzufragen oder
> > > nicht gewillt sind ihre Programmiertechniken anzupassen.
> > 
> > Nun, das ist eine andere Baustelle. Gibt's natürlich auch, und dieses
> > Phänomen ist unabhängig von der Programmiersprache, da stimme ich zu.
> > :-)
> 
> Ja, und deswegen plädiere ich fürProgrammiersprachen, die einem
> diese Art von Pfuscherei wenigstens schwer machen, bzw. einem
> dabei helfen, eigene Fehler frühzeitig ausfindig zumachen.

ACK. Deshalb mag ich Python so sehr. Das krasse Gegenteil sind
Shell-Scripte und PHP. Das merkt man vorallem an dem Aspekt der
Quoting- bzw. Escaping-Probleme. Während beim Shell-Script die
Quoting-Probleme quasi in die Sprache eingebaut sind, ist bei PHP
nicht die Sprache an sich, sondern das schlechte Design der API
das große Problem. Ruby hat vergleichbare, wenn auch weniger krasse
Probleme. Python hingegen hat eine sehr saubere, durchdachte und
schlanke API.

Ich weiß, es gibt noch dein Lieblingthema, die Laufzeit-Fehler,
die man überwiegend schon beim Compilieren abfangen sollte. Das
ist natürlich auch ein Thema, aber ich wollte mit dem Quoting und
dem API-Design mal einen neuen Aspekt beleuchten. :-)

> > > ...es gibt eben Leute, die arbeiten gerne mit dem Debugger.
> > > ...und es gibt andere, die brauchen keinen Debugger.
> > > 
> > > So einfach ist das.
> > 
> > Es gab ein paar Unsauberkeiten, die wir allein mit Debug-Messages
> > nicht finden konnten. Sie resultierten aus einem teilweise falschen
> > Verständnis von C++, ohne Debugger hätten wir das nicht gefunden.
> 
> Naja gut, manchmal mag man den schon brauchen; wenn man an Code anderer
> Leute arbeitet,die Unsinn verzapft haben ;-)

Man kann solchen Unsinn auch selbst verzapfen. Ich wette, das wird
dir auch passieren, wenn du dein erstes ernsthaftes C++-Projekt hast,
und z.B. Referenzen in Listen packst oder so. Sicher, im nachhinein
war mir völlig klar, warum ich das nicht machen durfte, aber dennoch
hab ich's erstmal mit dem Debugger finden müssen, bevor es mir wie
Schuppen von den Augen fiel.

> > Aber ansonsten: Ja, ich stimme zu, wenn man ordentlich entwickelt,
> > braucht man den Debugger kaum. Man debuggt gleich beim Schreiben,
> > und zahlt dort einen viel niedrigeren Preis als später in der
> > Fehlersuche. Dieses Prinzip namens "Inkrementelle Programmierung"
> > ist aber uralt, und wird *eigentlich* jedem Neuling mit als erstes
> > beigebracht.
> 
> Ich dachte das ist erst, seit man den alten Wein (alter Wein, schöner,
> alter Jahrgang,lecker) in neue Schläuche füllte (und Zucker und/oder Glykolalc
> dazu gab) und es XTreme-programming nannte, erst bekannt geworden?!

Ich finde das auch in uralten Python-Tutorials, die schon lange vor dem
XP-Hype geschrieben wurden. Ich wette, in irgendwelchen *richtig*
steinalten LISP-Büchern findet man das auch noch. Eigentlich wird einem
in jeder Interpreter-Sprache dazu geraten.

Ich vermute, das hängt damit zusammen, dass es sich um interpretierte
Sprachen handelt. Bei den Compiler-Sprachen ist diese Methodik etwas
abhanden gekommen, was vielleicht mit dem Mythos zusammenhängt, der
Compiler fände alle Fehler, und dass bisschen an Logikfehlern, was übrig
bleibt, würde man auch im Nachhinein schnell rauskriegen.

Ist aber nur ne Vermutung. Ich war damals nicht dabei, als die vielen
tollen Ideen und Prinzipien aufgestellt und später wieder vergessen
wurden.

Was mir an XP aber immer noch sympathisch ist: XP behauptet nicht, neu
zu sein. Es steht dazu, viele altbekannte Methoden zu kombinieren. Und
es behauptet nicht, das Allheilmittel für jedes Projekt zu sein, sondern
gibt eine Abgrenzung an: Projekte mit hohem Risiko und unscharfen
Anforderungen.

Unsympathisch an XP, wie auch an vielen anderen Paradigmen, ist dieser
religiöse Charakter: Wende XP ganz an oder gar nicht. Keine Varianten.
Keine verschiedenen Lösungen für einzelne Aspekte, denen Vor- und
Nachteile gegenüber gestellt werden. Sondern einfach nur:
Du sollst das und das machen, und hier ein paar Gründe dafür: ...

Viel professioneller ist aber: Unter diesen Umständen mache (1), sind
die Umstände soundso, mache lieber (2), ansonsten besser was ganz anders.

Für lezteres braucht man nämlich wirklich umfassende Erfahrung, und
nicht nur eine handvoll Tricks, die bei ein paar eigenen Projekten
zufällig gut gelaufen sind.

Das stört mich übrigens auch an den Artikeln von Paul Graham und Joel
Spolsky: Die sind sehr interessant zu lesen, aber sie verallgemeinern
ihre Erfahrungen aus einzelnen Projekten viel zu schnell. (Obwohl sie
gleichzeitig behaupten, genau das nicht zu tun ;-))

> > > Mehr als diese allgemeine Aussage kann man hier nicht treffen,
> > > denn sonst können wir gleich ein Buch schreiben.
> > > (Keine schlechte Idee, eigentlich, was? :))
> > 
> > Ein Buch über KISS, und warum verfrühte Optimierung böse ist,
> > mit zahlreichen Beispielen "richtig" <-> "falsch". Das wäre
> > lustig, ja.
> 
> Daslustigste sind Codebeispiele.
> Manche sehen fast aus wie uuencodet files ;-)

Von welchen Codebeispielen genau redest du?

> Sowas wie versehentlich obfuscated.

Jeder Anfänger kann unverständliches Zeug schreiben. "de-obfuscation"
des eigenen Codes ist das, was den professionellen Programmierer
ausmacht, oder?

> Aber manch einer programmiert jaobfuscated,damit sein Job sicher ist.

Davon habe ich gehört, aber noch nie jemanden kennengelernt, der das
tatsächlich macht. Die meisten schreiben unverständlich, wenn sie es
einfach noch nicht besser wissen. Das gilt für mich selbst auch, z.B.
als ich mein erstes configure.ac - Script geschrieben habe. Oder am
ersten größeren C++-Projekt mitprogrammierte. ;-)

> Kann sich damit aber ins Knie schiessen.

Nenn mir einen, der das nicht tut. ;-)


Viele Grüße,

    Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR