AW: A vor Variablen
Schaden tun aber 1 Zeichen Präfixe aber auch nicht
|
AW: A vor Variablen
nun gewöhne ich mir - die mühsam angewöhnte - ungarische Notation ab ... und dann das! :stupid:
|
AW: A vor Variablen
Zitat:
Ich lese gerne Code wie ein Buch: 1. 'if lCustomer.HasOpenInvoices' vs. 2. 'if theCustomer.HasOpenInvoices' vs. 3. 'if Customer.HasOpenInvoices' Was liest sich flüssiger? 1000x 'l' im Geiste zu lesen ist 1000x ein geistiger Schluckauf. Muss nicht sein. Ob man nun 'the' hinzupackt, um es noch lesbarer zu machen, sei mal jedem selbst überlassen: Clean-Code-Jünger machen das (ein paar), ich nicht. Ich lasse auch 'Self' weg, andere bestehen darauf. Übrigens wäre 'Self.Field' ein Ersatz für 'fField' :kotz: |
AW: A vor Variablen
Das "l" für lokale Variablen spare ich mir auch, aber pscht :) (Das "a" in Argumenten nehme ich aber ganz gerne, besonders wegen der Englisch-Artikel-Lesbarkeit.)
|
AW: A vor Variablen
Ich habe mich mit Präfixen als letzte Rettung dafür, dass die Delphi-IDE so gut wie nichts formatieren kann auch nie anfreunden können.
Unter Eclipse habe ich immer ein LSD-Feuerwerk an Farben abgebrannt- Abstrakte Methode? Parameter? Lokale Variable? Feld? Klassenvariable? Ist der Typ ein Interface? Eine Implementierung? Alles konnte man anhand der Farben (und anderem) schneller sehen als man zwei Buchstaben lesen kann. Mit der RAD Studio IDE bin ich größtenteils ganz zufrieden, aber Code Highlighting ist ja schon fast schlechter als Notepad++. |
AW: A vor Variablen
aField, aClass, aGlobalVar ... da braucht man ja nur noch das A und es passt überall davor. :stupid:
Und das mit den Farben geht im Delphi auch ... man braucht nur das passende Addon. :roll: |
AW: A vor Variablen
Und welches ist das? Nichts gegen cnPack (es hilft schon sehr), aber im Endeffekt tut es auch nicht mehr, als ein paar Block-Schlüsselwörter wie
Delphi-Quellcode:
oder
begin..end
Delphi-Quellcode:
bunt anzumalen.
try..finally
(Und die Farben nur drüberzulegen. Dank ClearType sieht man den blauen Originaltext oft drunter durchschimmern) |
AW: A vor Variablen
Auch bei Farben gilt: Weniger ist mehr.
Wozu sollte ich mir bei
Delphi-Quellcode:
Die Klasse und das Interface unterschiedlich einfärben lassen. was soll das denn sonst sein? Das Interface wird zudem in jeder Sprache mit 'I' gepräfixt... Aber wer's gerne bunt mag. Soll ja wieder 'in' sein (retro).
Type
TMyClass = Class (TFoobar, ISomeInterface) // oder ganz untypisch MyClass = Class (Foobar, ISomeInterface) Ich habe eine bessere Idee: Schreibt einfach übersichtlichen und leicht zu lesenden Code mit kleinen Methoden und verzichtet ganz auf globale Variablen der Konstanten. |
AW: A vor Variablen
Oder Implementationen waren fett, Interfaces dünn. Oder es gab überhaupt keinen Unterschied. Zu lange her.
Solange ich nicht die Farben auf meinem persönlichen Bildschirm als Grund nehme um andere Dinge wie vernünftige Namensgebung schleifen lasse ist doch alles in Butter. |
AW: A vor Variablen
Zitat:
Dass andere das nicht machen, sieht man an Fragen wie nach der parallelen Ansicht von Code und Quelltext... So muss ich nur schreiben pnl, wenn ich ein Panel suche, und dann schauen welche es gibt. Wenn die dann ordentlich benannt sind, findet man das richtige Panel dann sofort. Wenn ich aber nicht weiß wie der Begriff anfängt, weil das nicht am Typ der Komponente festgemacht ist, muss ich viel länger suchen (oder eben zum Formular schalten). |
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:22 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz