Zitat von
mleyen:
Ich persönlich finde begin und end; viel übersichtlicher als diese kleinen Klammern.
Zusätzlich regen diese 'Mehrzeichen' dazu an, seinen Code weiter aufzusplitten, heißt in neue Methoden auszulagern.
Was ist so schlecht daran, Programmteile in Methoden auszulagern? Ich ging davon aus, das sei etwas Gutes.
Zitat von
mleyen:
Man kann auch nicht an jeder x-Beliebigen stelle einfach wahrlos Variablen deklarieren.
In Delphi hat man alle Variablen übersichtlich vor dem ersten begin.
Warum willst du denn vor dem ersten begin schon wissen, dass es in der Methode eine Laufvariable gibt, die in dritter Verschachtelungstiefe (oder doch woanders? das weißt du ja nicht) an nur einer Stelle benutzt wird? So lange du sowieso noch nicht weißt wann und wofür sie verwendet werden, ist das Wissen von deren Existenz doch auch nur unnötige Information für dich.
Außerdem gelten in Delphi Variablen immer für eine ganze Methode. In C# gelten sie nur für den begin-end-Block, in dem sie deklariert worden sind.
Zitat von
mleyen:
Records können Operatoren überladen und dazu wurde hier (ich glaub Himitsu war´s) mal vorgestellt wie man Records genau wie Objekte handhaben kann.
Hast du nen Link dazu?
Zitat von
mleyen:
Ich persönlich brauche soetwas bei großen Objekten eigentlich nie. Gerade, da ich meißt später nichtmal mehr wusste, was die Op.-Überladung überhaupt macht. Da schreib ich mir lieber eine kleine Methode ala 'add()'.
Und wieso weißt du bei der Methode "add()" eher, was sie macht, als bei dem Operator "+"?
Zitat von
mleyen:
Zitat von
Cöster:
- Case-Sensitivität: Indem man Parameter und Variablen mit einem Kleinbuchstaben beginnen lässt und Typen und Methodenbezeichner mit einem Großbuchstaben, sind Präfixe wie "T" für Typen oder "F" für Felder nicht mehr nötig
Das ist denke ich mal Geschmackssache. Ich kann gleichnamigen Variablen / Methoden etc nichts abgewinnen, da ich es für unsauberen Code halte.
Sie sind ja nicht gleichnamig, da sie sich eindeutig durch Groß- und Kleinschreibung unterscheiden. Das zwingt auch dazu, sauber zu programmieren, also die Variable nicht an einer Stelle groß und woanders aus Faulheit klein zu schreiben.
Zitat von
mleyen:
Zitat von
Cöster:
- Zeichen statt Wörtern sind einfacher zu lesen, z. B. += statt Inc(), ! statt not, & statt and etc. Ganze Wörter hierfür zu benutzen wie in Delphi, ist ja fast so schlimm als würde man in Mathe "plus" schreiben statt das Zeichen + zu benutzen. Durch die Verwendung von Zeichen für Operatoren und Wörtern für Operanden heben sich diese besser voneinander ab
Und da ist sie wieder: Die Geschmackssache.
Die einen finden cryptischen Code übersichtlich, die anderen nutzen lieber genau definierbare Bezeichner...
Fändest du auch "Zwei
plus vier
gleich sechs" besser lesbar als "2 + 4 = 6"? Wenn du an die erste der beiden Schreibweisen gewöhnt wärest, würdest du das vermutlich als übersichtlicher bezeichnen. Wir werden hier aber vermutlich alle für die cryptische Schreibweise stimmen (oder nicht?), wieso dann also nicht auch bei Operatoren im Code? Die Gewöhnung an das imo Unlesbarere mal außen vorgelassen, kann ich nicht nachvollziehen, wie man das bevorzugen kann.
Zitat von
Luckie:
Dadurch, dass alles im Interfaceteil deklariert ist hat man einen sehr schönen überblick über die Klasse.
Nagut, das möchte ich dann meinetwegen als ein gutes Argument anerkennen
Zitat von
Luckie:
Also das Zeilen sparen ist wohl eine ziemlich doofe Begündung.
Warum? Jede zusätzliche Zeile, die nicht zum Verständnis der Programmlogik nötig ist, macht den Code doch nur unübersichtlicher.
Zitat von
Luckie:
Aber findest du das gut:
Code:
for(;P("\n"),R--;P("|"))for(e=C;e--;P("_"+(*u++/8)%2))P("| "+(*u/4)%2);
Ok, das ist jetzt C, aber mit C# wahrscheinlich auch möglich.
Hehe, nein, das finde ich nicht gut. Ich versteh aber auch nicht wirklich, was es bedeuten soll. Was wäre denn die Delhpi-Übersetzung davon? Das Problem daran ist meiner Meinung nach aber nicht, die Verwendung von Zeichen, sondern die Anzahl der Vorgänge, die in einer Zeile zusammengefasst sind.
Zitat von
Medium:
Die Klammern sind recht spidderig, und ich übersehe gerne mal eine. Ein Wort sticht da einfach besser hervor.
Genau das halte ich für ein Problem von Delphi: Ausgeschriebene Wörter stechen zu stark hervor und je mehr diese hervorstechen, desto weniger sticht der Rest des Codes hervor.
Zitat von
himitsu:
Und ich hab lieber selbst die Kontrolle über den Speicher, denn so weiß ich was wo für Speicher exisiert oder eben nicht.
Diese Kontrolle kann man auch trotz Garbage Collector haben, denn Instanzen lassen sich trotzdem noch manuell freibeben, wenn es denn erwünscht ist.
Zitat von
himitsu:
Operatoren sind doch Zeichen?
Einige, wie +, -, *, / sind es. Andere, wie not, and, xor, or, div, mod sind in Delphi allerdings Wörter.