nicht angemeldet
Hi,
Du bist ja auch aus dem consulting Bereich.
Auch wenn Du Dich darauf zu versteifen scheinst: ich bin es immer noch nicht.
ich hatte Dich so verstanden. Dass Du nur noch gelegentlich "den Blaumann anziehst" und so.
Ist ja auch meistens nicht nötig, da die Infrastruktur schon besteht und nicht mehr durhc Kabelkänale gekrochen werden muß. Nur bei manchen Tastaturen möchte man sich gerne zwei Lagen Gummihandschuhe übereinander anziehen.
Ich mach das, was bezahlt wird. Nur Fenster putze ich nicht.
Du bist also nicht kaeuflich und hast Rueckgrat, sehr gut.
Ich bin durchaus käuflich, Preisliste auf Anfrage.
Ist aber hilfreich, wenn man ein Modell hat, das beschreibt, was software und Software-Entwickler so machen.
Software ist reine Mathematik in anderer Sprache und der Softwareentwickler ist der Übersetzer. Wofür da noch ein Modell?
Und warum wehrst Du Dich dann so vehement gegen ein Mittelchen, das nützlich zur Vorbeugung ist?
Weil ich nicht dran glaube,
Ich hoffe nicht, das das eine theologische Diskussion wird?
Obwohl, werden die über Codeformatierung eh immer.
if (bedingung) {;
tuWas();
}
hat mich einfach nicht ueberzeugt.
Warum nicht? (was soll die schließende Klammer eigentlich an derart exponierter Stelle? Egal? Gut, da hast Du natürlich auch wieder Recht)
if(bed);
{
func();
}
Es erfolgt keine Abzweigung, keine Fehlermeldung und keine Warnung und mit ein wenig Pech taucht der Fehler erst beim Kunden auf.
if(bed){;
func();
}
Erstes Semikolon ist ohne Wirkung und damit ohne Schaden.
if(bed){;
func();
}
Ist zudem nach meinem Geschmack ganz gut lesbar, aber eben: Geschmacksache.
Hauptaussaage meiner Antwort auf Toms Frage war:"Werdet euch einig, worauf ist egal." und dabei bleibe ich immer noch.
Du hast noch nicht gesehen, worauf sich Menschen einigen koennen.
Ja, da gibt es ganz furchtbare Sachen, aber im Bereich Codeformatierung ist es wirklich völlig egal, hauptsache man ist sich überhaupt einig. Durcheinander ist dagegen meistens tödlich.
BTW: wie hälst Du's eigentlich bei Python, Scheme, Lisp, Assembler, Ook ... ?
Ich habe bisher nur in groesserem Masse Turbo Pascal, "GW/Q BASIC", LaTex (ist das eine Programmiersprache? ;-)
Ist glaube ich nicht ganz Turing-Complete.
COBOL, VB, Perl, PHP, XSL, JavaScript und T-SQL (bzw. ANSI92 SQL) kodiert. Taete mich interessieren, ob in den von Dir erwaehnten Sprachen Specials zu beachten sind, die mein konsistentes und kohaerentes "Whitespace-Modell" in Frage stellen. ;-)
Alle o.a., deshalb habe ich sie ja gelistet. In Python ist die Formatierung sogar in der Syntax selber. Falsche Formatierung->Parse-Error. Die Klammerzäune bei Lisp sollten Dir aber auch ein Begriff sein, oder? Und Ook hat nur drei Befehle. Bei Assembler ist auch alles recht linear und dabei bunt gemischt.
Es gibt also Sprachen, die keine logischen Blöcke kennen, viel zu viel Klammern haben, fixierte Formatierung oder auch total obskur sind. Da ich auch eine Mathematik entwerfen kann, die nicht auf Logik basiert kann ich auch Sprachen entwerfen, die noch nicht einmal virtuelle logische Blöcke haben. Oder gar nicht einmal derartig abgehobene, sondern ganz einfach probabilistisch arbeitende Sprachen, die nötig werden, wenn man Quantencomputer tatsächlich nutzen möchte. (im Augenblick wird da normale Logik aufgepropft, die alle Möglichkeiten brachliegen läßt). Dafür wären dann z.B. Farben, Muster, ja ganze Bilder zur Code Formatierung ideal.
Der größte Nachteil eines Modells ist der veränderte Maßstab. Was im Kleinen paßt muß nicht auch im Großen passen und umgekehrt.
so short
Christoph Zurnieden