Frage zur "Abwärtskompatibilität"
-
Mich würde folgendes interessieren: Wie kommt es: Wenn man für irgendein Programm nach Windows 98-Unterstützung fragt, wird man komisch angeguckt, weil dieses Betriebssystem ja schon uralt ist etc. und nicht mehr unterstützt wird.
Aber andererseits: Wenn ich mir Programmiersprachen-Styleguides durchlese, dann steht da oft, daß die Zeilen nicht länger als 80 Zeichen sein sollen, falls sich jemand den Quellcode zum Beispiel auf einer Unix-Konsole anguckt.
Ich meine, ist das nicht der absolute Doppelstandard? Einerseits darüber lachen, wenn sich jemand aufregt, daß stinknormale Piß-Standard-Konsolenanwendungen, die unter Visual C++ 2008 kompiliert werden, nicht mehr auf Windows 98 laufen (Was soll der Scheiß eigentlich? Macht es nicht viel mehr Arbeit, die Unterstützung bewußt rauszunehmen, statt den alten Code weiter zu verwenden? Ich spreche ja nichtmal von WinAPI-Zeug, sondern von cout), aber andererseits muß man auf jeden Hinz und Kunz Rücksicht nehmen, der es in den letzten 20 Jahren nicht geschafft hat, sich mal ein ordentliches grafisches Betriebssystem zuzulegen, bei dem die Bildschirmauflösung größer als 320x240 ist, und der immer noch vor einem 80x25-Zeichen-Bildschirm sitzt?
Bitte erklärt mir diesen Diskrepanz. Es interessiert keinen, ob etwas noch auf einem alten Betriebssystem läuft, aber Quellcode muß auch für Geräte aus den 80ern gut lesbar sein.
-
Die Betriebssysteme der 80er hatten aber wenigstens schon einen funktionierenden Speicherschutz.
-
Auf meinem linux hab ich auch noch ne 80er konsole. ist einfach praktisch
und in meiner ide hab ich damit mehr Platz für mehr fenster. ist schon ein Unterschied ob man 1,2 oder 4 Quellcodedateien gleichzeitig anschauen kann
-
NES-Spieler schrieb:
Aber andererseits: Wenn ich mir Programmiersprachen-Styleguides durchlese, dann steht da oft, daß die Zeilen nicht länger als 80 Zeichen sein sollen, falls sich jemand den Quellcode zum Beispiel auf einer Unix-Konsole anguckt.
...oder auf einem 17"-Monitor. Soll es noch geben. Bei Notebooks sollen sogar noch 15" vorkommen.
Möglicherweise hängt das Überleben dieser Stilrichtlinie auch damit zusammen, daß Code, der gerne horizontal sehr anschwillt, tendentiell an Übersichtlichkeit einbüßt und von geringerer Qualität ist
NES-Spieler schrieb:
Ich meine, ist das nicht der absolute Doppelstandard?
Das Leben ist voller Doppelmoral. Ist es nicht gleichermaßen fragwürdig, daß du einerseits logische und argumentative Inkonsistenzen bemängelst, zugleich aber insbesondere in der Betriebssystemfrage unter Angabe tendentiell irrationaler Gründe auf technisch überholten Systemen wie Windows 98 beharrst?
NES-Spieler schrieb:
(Was soll der Scheiß eigentlich? Macht es nicht viel mehr Arbeit, die Unterstützung bewußt rauszunehmen, statt den alten Code weiter zu verwenden? Ich spreche ja nichtmal von WinAPI-Zeug, sondern von cout)
Was meinst du denn, wie die iostreams unter Windows implementiert sind?
NES-Spieler schrieb:
aber andererseits muß man auf jeden Hinz und Kunz Rücksicht nehmen, der es in den letzten 20 Jahren nicht geschafft hat, sich mal ein ordentliches grafisches Betriebssystem zuzulegen, bei dem die Bildschirmauflösung größer als 320x240 ist, und der immer noch vor einem 80x25-Zeichen-Bildschirm sitzt?
Sollte das immer noch auf die 80 Zeilen bezogen sein? Dann denke mal drüber nach, wieviel es ausmacht, wenn mehrere Generationen von Programmierern, die unter diesen Bedingungen ihr Handwerk erlernten, auch nur einen Bruchteil der konservativistischen Bequemlichkeit ausleben, die dir eigen ist, und lieber Programme in einer Breite schreiben, wie sie es seit jeher gewohnt sind.
-
Das ist wie bei Typographie: Bei Büchern könnte man die Zeichen heute auch problemlos viel enger setzen als zu Gutenbergs Zeiten, aber aus Gründen der Lesbarkeit wäre das einfach nur sinnlos. Wenn Quellcode sehr lange Zeilen hat, wird der auch viel schwieriger zu lesen (zumindest geht es mir so).
-
wenn ich debugge, bin über diese inoffzielle 80 zeichen konvention sehr froh. mit den ganzen stacks und was nicht alles für tools überall, bleibt recht wenig platz für den code.
-
Die Zeilenbreite meines Quellcodes wächst mit der Breite des Quellcodeeditors auf meinem Bildschirm. Im Moment sind das 150 Zeichen.
Ansonsten steht es Dir auch frei, mit VS 2005 weiter für Windows 98 zu programmieren. Ich werde nie verstehen, warum man ein 10 Jahre altes Betriebssystem einsetzt (das schon mehrere Nachfolgenerationen hat), mit dem Anspruch, jede topaktuelle Software darauf laufen lassen zu wollen. Irgendwann hat jede Software mal ihren Lebensabend erreicht, und bei Windows 9x ist das auch gut so.
-
80 Zeichen/Zeile sind einfach toll, weil man so ohne Probleme zwei Editorfenster nebeneinander packen kann. Außerdem gewöhnt man sich so schwer leserlichen Code ab. Zu viele Zeichen pro Zeile sind oft ein schlechtes Zeichen.
Aber wenn es dich stört: Es steht dir ja frei so viele Zeichen pro Zeile zu nehmen, wie du willst.
-
80 Zeichen sind in modernen Sprachen viel zuwenig, wenn man ordentlich einrückt. Hätte ich nie gedacht, dass durch die Einrückung soviel Platz verloren geht, bis ich gerade mal im VS die vertikale Linie gezogen habe.
:schland:
-
Rückt man in "modernen" Sprachen denn mehr ein als in "nicht-modernen"? Was sind denn überhaupt "moderne" Sprachen?
-
Tim schrieb:
Was sind denn überhaupt "moderne" Sprachen?
alle sprachen, die jünger als 15 jahre sind.
-
ausprobiereur schrieb:
80 Zeichen sind in modernen Sprachen viel zuwenig, wenn man ordentlich einrückt.
Rückst Du vielleicht zu oft ein?
Beim Linux-Kernel schreibt man mit 80 Spalten und einer Einrückungstiefe von 8 Spalten. Würde ich persönlich nicht gerade so machen, funktioniert aber auch.
-
Hi,
spätestens wenn Du das ganze mal in Maulwurfsfreundlicher Schriftgröße ausdruckst wirst Du den Sinn von 80 Zeichen verstehen.
Gruß Mümmel
-
LordJaxom schrieb:
ausprobiereur schrieb:
80 Zeichen sind in modernen Sprachen viel zuwenig, wenn man ordentlich einrückt.
Rückst Du vielleicht zu oft ein?
Beim Linux-Kernel schreibt man mit 80 Spalten und einer Einrückungstiefe von 8 Spalten. Würde ich persönlich nicht gerade so machen, funktioniert aber auch.
Zugegeben, ich habe nicht an C oder C++ gedacht, sondern einfach mal ein C# Projekt geöffnet.
Mit Einrückung von 4 Zeichen ist man bei Konstruktionen wie
namespace->class->method->using->while->if
allein schon bei 24 Zeichen Einrückung bei 56 Zeichen Code. Und das ohne nennenswerte Verschachtelung. Dazu kommt, dass Bezeichner der BCL tendenziell eher länglich daherkommen, und Best-Practices dazu anhalten, Namen auszuschreiben und Abkürzung zu vermeiden.Then again, wer betrachtet schon C# Code auf seiner Unix Konsole ...
-
rüdiger schrieb:
80 Zeichen/Zeile sind einfach toll, weil man so ohne Probleme zwei Editorfenster nebeneinander packen kann. Außerdem gewöhnt man sich so schwer leserlichen Code ab. Zu viele Zeichen pro Zeile sind oft ein schlechtes Zeichen.
Mir reicht ein Fenster, was dann etwas breiter ist.
Solange der Quelltext in das Fenster passt, lassen sich längere Zeilen imho viel besser lesen als nur 80 Zeichen/Zeile. Der Überblick ist besser und man erspart dem Kopf unnötige Mehrarbeit (für die interne Auflösung der Zeilenumbrüche).
Letztlich muss jeder seinen eigenen Stil finden. Schwerer wird es bei der Teamarbeit, da braucht man schon gewisse Richtlinien.
-
Wenn Du Programme schreiben willst, für die Du zusagst, dass sie unter bestimmten Betriebssystemen laufen, dann musst Du diese Betriebssysteme auch verfügbar haben. Das ist bei Windows 98 gar nicht mehr so einfach.
Ich versuche meine Programme so zu schreiben, dass sie auch z. B. auf Windows lauffähig wären, aber da ich dieses Betriebssystem nicht habe, kann ich lediglich vermuten, dass die Programme auch dort funktionieren würden. Wenn ich die Lauffähigkeit nicht zusage, heisst das ja nicht, dass das nicht doch funktioniert.
Über die Grenze auf 80 Spalten kann man Diskutieren. Ich halte es so, dass ich versuche, 80 Spalten nicht wesentlich zu überschreiten. In der Regel verbessert das die Lesbarkeit der Programme. Bei tief verschachtelten Konstrukten sollte man einfach mal darüber nachdenken, Teile in Unterfunktionen auszulagern.
-
(doppelpost)
-
muemmel schrieb:
Hi,
spätestens wenn Du das ganze mal in Maulwurfsfreundlicher Schriftgröße ausdruckst wirst Du den Sinn von 80 Zeichen verstehen.
Gruß Mümmel
Hm.
Wenn ich mich danach richten würde dass Programme in ausgedruckter Form lesbar sein sollen müsste ich einiges an meinem Programmierstil ändern. z.B. die Monster-Zeilen.
Zeilen wo in den ersten 20 oder 30 Zeichen klar wird *was* gemacht wird, die aber insgesamt 200 Zeichen lang sind breche ich z.B. oft nicht um.BTW: bei Java und C# kommt man mit Einrückung für namespace + class schonmal auf 8 Zeichen mehr bei C++ (bei 4er Einrückung). Zumindest wenn man die "üblichen" Einrückungs-Regeln der Sprachen verwendet. Nur weil "moderne Sprachen" erwähnt wurden...
-
Hi,
hast ja (leider) recht. Gerade bei if-Bedingungen... kommen leicht abartige Längen zusammen. vor allem wenn man bei Borland-Datenbankanwendungen Feldnamen benutzt, die auch noch in anderen Formularen und somit anderen Klassen stehen.
Aber zumindest versuche ich, den überwiegenden Teil des Quelltextes links vom Strich unterzubringen. Da ich gerne aussagekräftige Namen verwende, kommt da schon mal was zusammen. Aber die Möglichkeit, daß sich Quelltext wie ein Kommentar dassekbeb liest ist mir wichtiger als die sklavische Einhaltung der 80 Zeichen. Zum Glück sind A3-Drucker in Reichweite. Manchmal guckt mann doch durech ein stück Papier auf dem man rummalen kann doch besser durch als durch ne Bildschirmanzeige.
4-Zeichen-Einrückungen hab ich noch nie verwendet, ich bleib bei 2 Zeichen, auch wenn ich da eventuell erst gucken muß wo ich stehe.Gruß Mümmel
-
Windows 98 ist ein Schrottbetriebssystem. Leute, die es immer noch einsetzen, werden so wenigstens gezwungen auf NT Kernel zu migrieren, wenn sie Programme benutzen wollen. Das kann nur gut sein. Es gibt keinen Grund, weshalb man so ein wahnsinniges OS wie Windows 95 bzw. 98 einsetzen sollte.
