Code optisch gestalten - Wie?

[400kmh]

Du musst das Objekt zuerst createn, bevor du es benutzt.
Guckst du: http://www.delphi-treff.de/tutorials/ob ... ammierung/

Danke, jetzt funktionierts.

Und bitte mach die Formatierung normal, nicht begin auf der gleichen Zeile wie procedure etc.. Das sieht echt übel aus.

So:

Code: Alles auswählen

procedure TObjekt.Berechnung; 
begin
  x:=1; 
end;

Und: Nein, das ist nicht Geschmackssache.

Ich denke schon, dass das Geschmacksache ist.

Ich finde es ablenkend, Zeilen zu sehen in denen lediglich Dinge wie "begin" oder "end" oder ";" stehen. In Zeilen sollten meines Erachtens nicht lediglich Synsemantika stehen, sondern Ausdrücke höherer Bedeutung. Die Struktur kann man viel einfacher durch Einrücken verdeutlichen.

[theo]

Ich denke schon, dass das Geschmacksache ist.

Sobald du mit anderen arbeitest, oder den Code jemandem zeigen möchtest nicht mehr.
Schau dir mal die Quellen von Lazarus an. Dort ist auch nicht jede Datei nach individuellem Geschmack formatiert, sondern einheitlich.
Glaube es einfach.

[Socke]

Und: Nein, das ist nicht Geschmackssache.

Ich denke schon, dass das Geschmacksache ist.[/quote]
Es gibt Personen, die sich damit professionell beschäftigen. Diese nennt man auch Typografen und die Beschäftigung Typografie. Das Ergebnis ist recht einfach: Wenn man wichtige Worte hervorhebt (egal auf welche Weise), können diese schneller optisch erfasst werden (ohne diese Worte gelesen zu haben). Ich denke, hier ist allen klar, warum end; in Pascal-Quelltext üblicherweise hervorgehoben wird.

Ich finde es ablenkend, Zeilen zu sehen in denen lediglich Dinge wie "begin" oder "end" oder ";" stehen. In Zeilen sollten meines Erachtens nicht lediglich Synsemantika stehen, sondern Ausdrücke höherer Bedeutung. Die Struktur kann man viel einfacher durch Einrücken verdeutlichen.

Was ist denn ein Ausdruck höherer Bedeutung? Meinst du damit die Programmlogik? Demnach wären Synsemantika Ausdrücke niederer Bedeutung. Diese Auffassung kann ich leider nicht teilen, da sie sehrwohl ein entscheidende Bedeutung für den Programmfluss -- beispielsweise bei Verarbeitungsblöcken in Schleifen, etc. -- haben. Sie dienen nicht nur dazu, einen Programmquelltext in eine Semantik zu stecken, damit er von einem Compiler geschluckt wird.

Meiner Auffassung deiner Argumentation folgend habe ich den folgenden Quelltext formatiert. Ich finde ihn recht unübersichtlich (auch wenn er inhaltlich Unsinn enthält).

Code: Alles auswählen

function DieseProzedurHatVieleParameter(const x: Integer; var y: String; obj: TMyObject): psqlite3_statement; cdecl; var
  i: Integer;
  z: Integer; const
  a = 'HALLO WELT.'; begin
  i := z; end;

[400kmh]

Es gibt Personen, die sich damit professionell beschäftigen. Diese nennt man auch Typografen und die Beschäftigung Typografie. Das Ergebnis ist recht einfach: Wenn man wichtige Worte hervorhebt (egal auf welche Weise), können diese schneller optisch erfasst werden (ohne diese Worte gelesen zu haben). Ich denke, hier ist allen klar, warum end; in Pascal-Quelltext üblicherweise hervorgehoben wird.

Ich hebe "end" ja auch hervor: Dadurch dass die nächste Zeile ihre Einrückung verliert.

Was ist denn ein Ausdruck höherer Bedeutung? Meinst du damit die Programmlogik? Demnach wären Synsemantika Ausdrücke niederer Bedeutung. Diese Auffassung kann ich leider nicht teilen, da sie sehrwohl ein entscheidende Bedeutung für den Programmfluss -- beispielsweise bei Verarbeitungsblöcken in Schleifen, etc. -- haben. Sie dienen nicht nur dazu, einen Programmquelltext in eine Semantik zu stecken, damit er von einem Compiler geschluckt wird.

Das ist mir schon klar, doch auch in dem Fall kann man das durch Einrücken betonen.

Meiner Auffassung deiner Argumentation folgend habe ich den folgenden Quelltext formatiert. Ich finde ihn recht unübersichtlich (auch wenn er inhaltlich Unsinn enthält).

Code: Alles auswählen

function DieseProzedurHatVieleParameter(const x: Integer; var y: String; obj: TMyObject): psqlite3_statement; cdecl; var
  i: Integer;
  z: Integer; const
  a = 'HALLO WELT.'; begin
  i := z; end;

Ich würde es wohl so formatieren:

Code: Alles auswählen

function DieseProzedurHatVieleParameter(const x: Integer; var y: String; obj: TMyObject): psqlite3_statement; cdecl; 
var  
  i, z: Integer;
const  
  a = 'HALLO WELT.'; 
begin
  i := z; end;

"Begin" bekäme eine eigene Zeile, da es sich nicht auf die Konstante a bezieht.

Nehmen wir ein anderes Beispiel:

Deklaration:

Code: Alles auswählen

type
 
  TypX = record
    x1, x2: Array [1..10] of integer; end;
 
  TypZ = record
    z1: Array [1..10] of integer;
    z2: integer; end;
 
var
  a, b: integer;
  x: Array [1..10] of TypX;
  y: Array [1..10] of integer;
  z: Array [1..10] of TypZ;  

So und im folgenden wird der Vorteil deutlich:

Meine Formatierung:

Code: Alles auswählen

 
Procedure Prozedur1; begin
  for a:=1 to 10 do begin
    for b:=1 to 10 do if b mod 2=0 then with x[a] do begin
      x1[b]:=1;
      x2[b]:=1; end;
    y[a]:=1;
    with z[a] do begin
      for b:=1 to 10 do 
        z1[b]:=1;
      z2:=1; end; end; end;
 

Anstatt:

Code: Alles auswählen

 
Procedure Prozedur1;
begin
  for a:=1 to 10 do
    begin
      for b:=1 to 10 do
        if b mod 2=0 then
          with x[a] do
            begin
              x1[b]:=1;
              x2[b]:=1;
            end;
      y[a]:=1;
      with z[a] do
        begin
          for b:=1 to 10 do
            z1[b]:=1;
          z2:=1;
        end;
    end; 
end;
 

Was ist übersichtlicher, kürzer, prägnanter?

In letzterem finde ich mich schwieriger zurecht, werde ich abgelenkt und kostet mich die Anpassung mehr Zeit.

Bei meiner Formatierung ist durch den Grad der Einrückung auf den ersten Blick eindeutig klar, was zu welcher Ordnung gehört.

"Begin" und "end" sind Grammatik. "If"- und "with"-Aussagen etc. sind Nebensätze. Das alles sollte nicht von den Hauptsätzen ablenken.

[m.fuchs]

Ich werfe mal eine dritte Variante in den Raum:

Code: Alles auswählen

procedure Prozedur1;
begin
  for a:=1 to 10 do begin
    for b:=1 to 10 do begin
      if b mod 2=0 then begin
        with x[a] do begin
          x1[b]:=1;
          x2[b]:=1;
        end;
      end;
    end;
    y[a]:=1;
    with z[a] do begin
      for b:=1 to 10 do
        z1[b]:=1;
      z2:=1;
    end;
  end;
end;

Dies entspricht den ursprünglichen Codingstyle von Borland mit nur einem Unterschied. Bei Blöcken die sich an if, case, for, while, etc. anschließen, rückt das begin eine Zeile nach oben. Das hat mehrere Vorteile:

1. Man sieht dass ein end beispielsweise zu einem if gehört. Folgendes Beispiel würde also nicht auf den ersten Blick verwirren.

   Code: Alles auswählen

   if True then DoSomething;
   begin
     DoSomethingOther;
     DoSomethingOther;
   end;

   
   
2. Man spart eine Zeile. Diese Begründung ist allerdings absolut vernachlässigbar.
   
   
3. Es findet sich trotzdem noch jeder zurecht. Diese eine Änderung erschwert für Nutzer des Borland-Styles so gut wie gar nicht die Lesbarkeit. Okay, ich habe das nicht an tausenden von Menschen geprüft, aber bishr wurde es mir bestätigt. Gegenmeinungen sind natürlich willkommen.

Aber mit deiner seltsamen Nutzung von end, kann man sich nun wirklich nicht zurecht finden. Kein Mensch kann erkennen, wozu ein end gehört. Nimm es mir nicht böse, aber kommst du ursprünglich von einer C-artigen Sprache?

PS: Wie ihr sicher bemerkt habt, nutze ich in meinem Beispiel einige begin..end-Blöcke. Auch da wo eigentlich keine notwendig sind. Hilft aber auch an dieser Stelle sehr die Übersichtlichkeit zu behalten.

[mse]

PS: Wie ihr sicher bemerkt habt, nutze ich in meinem Beispiel einige begin..end-Blöcke. Auch da wo eigentlich keine notwendig sind. Hilft aber auch an dieser Stelle sehr die Übersichtlichkeit zu behalten.

Ich verwende sogar grundsätzlich immer begin..end, dadurch sieht die Struktur immer gleich aus, unabhängig von der Anzahl Statements im Block. Auch das begin am Ende der Zeile mache ich wie du. Als Einrückung verwende lediglich ein einzelnes Leerzeichen pro Stufe, damit ergibt sich am Ende meist eine 45° end Kaskade wo Unstimmigkeiten sofort ersichtlich sind. Der Highlighter hier im Forum kommt damit nicht zurecht, daher kann ich kein Beispiel zeigen.
Übrigens habe ich meinen Pascal Stil seit ich programmiere 3 oder 4 mal geändert, vor über 10 Jahren das letzte mal, für mich scheint das Optimum erreicht.
Ich habe immer gedacht der in FPC RTL und FCL verwendete sei für mich der schlimmst-mögliche Programmierstil, nun sehe ich , dass es tatsächlich noch schlimmere Versionen gibt.

Martin

[theo]

Ich habe immer gedacht der in FPC RTL und FCL verwendete sei für mich der schlimmst-mögliche Programmierstil, nun sehe ich , dass es tatsächlich noch schlimmere Versionen gibt.

Du kannst dich gerne lustig machen, aber dein Coding-Stil mit konsequenter Kleinschreibung ist das Schlimmste was ich je gesehen habe.
Damit schreckst du einige Leute von deinem Projekt ab.
Man muss das nicht Pro- und Kontra diskutieren, es ist der visuelle Eindruck, und der ist schlecht.

wahllos herausgepickt:

setstatfilevar(istatfile(self),avalue,fstatfile);

[mse]

Interessant, Graeme Geldenhuis, der in der Regel kein Blatt vor den Mund nimmt, hat mir letzthin geschrieben, dass er sich an den MSEgui Stil mittlerweile gewöhnt hat und die Sache nun auch für ihn Sinn macht.
Um einen Bug in Michaels FCL Code zu finden, muss ich immer zuerst den Stil umschreiben. Graeme schreibt, dass gehe ihm genauso, er habe zu diesem Zweck den Jedi-Formatter in Betrieb.

[theo]

Interessant, Graeme Geldenhuis, der in der Regel kein Blatt vor den Mund nimmt, hat mir letzthin geschrieben, dass er sich an den MSEgui Stil mittlerweile gewöhnt hat und die Sache nun auch für ihn Sinn macht.
Um einen Bug in Michaels FCL Code zu finden, muss ich immer zuerst den Stil umschreiben. Graeme schreibt, dass gehe ihm genauso, er habe zu diesem Zweck den Jedi-Formatter in Betrieb.

"mittlerweile gewöhnt" sagt ja alles. Das heißt auf deutsch, das er auch große Mühe damit hatte.

[MitjaStachowiak]

Ich versuche immer jede Einrückung zu vermeiden:

Code: Alles auswählen

procedure Prozedur1;
begin
 for a := 1 to 10 do begin
  for b := 1 to 10 do if (b mod 2 = 0 ) then with (x[a]) do begin
   x1[b] := 1;
   x2[b] := 1;
  end;
  y[a] := 1;
  with (z[a]) do begin
   for b := 1 to 10 do z1[b] := 1;
   z2 := 1;
  end;
 end;
end;

Ich denke, die bevorzugte Schreibweise hängt auch davon ab, was man sonst so programmiert / schreibt. Von der Typografie her ist eine Programmiersprache auch ähnlich zu HTML/XML:

Code: Alles auswählen

 
<HTML>
 <HEAD>
  <TITLE> Eine Seite </TITLE>
 </HEAD>
 <BODY>
  <DIV class="Element" style="margin-top : 5px; ">
   Text<BR/>
   Text
   <U><B>
    Wichtiger Text
   </B></U>
  </DIV>
 </BODY>
</HTML>
 

Auch wenn es nicht standardkonform ist, schreibe ich gerne die HTML-Elemente GROSS. Ich konnte mich noch nicht an einen HTML-Editor gewöhnen, der die Syntax hervorhebt...
Außderdem sieht man so, dass eine Seite noch handgeschrieben ist, in der heutigen Zeit der WYSIWYG-Editoren.

Fakt ist: Wenn man zu weit einrückt, dann sieht man in großen Dokumenten in der mitte den Code gar nicht mehr


_________________

Weil mir gerade langweilig ist, schreibe ich mal weiter...

Ich habe auch eine lange Historie an möglichen Formatierungen hinter mir. Ich erinnere mich noch an sowas:

Code: Alles auswählen

 
 function VieleParameter (     Param1 : integer;
                               Param2,Param3 : byte;
                           var Param4 : Boolean;
                               Param5 : Array of integer;
                           var Param6 : cardinal)
                           : Word;
 

Habe ich natürlich nicht konsequent durchgelalten...

Dann gibt es solche etwas old-fashioned Programmierer aus der Java Welt mit:

Code: Alles auswählen

 
public int DieFunktion (bool Param1; uint Param2)
{
    if Param2 < 2
    {
        if Param1
        {
            my int x = 5;
            x++;
        }
        else
        {
            my int x = 5;
            x--;
        }
    }
    return x;
}
 

Naja, wer's mag. Die Sourcecodes von Lazarus lesen sich da noch verhälltnismäßig einfach, auch, wenn sie keine individuellen Verfeinerungen haben.

[Patito]

setstatfilevar(istatfile(self),avalue,fstatfile);

Hm. Code von Leuten mit kaputter Shift-Taste ist schon auch so ein guter Kandidat für TheDailyWTF...

Dieser Python-Sytil mit dem Einrücken ist zwar auch eine lustige Idee, hat aber auch viele Probleme:

1) begin und end sind wichtig. Ist ihre Position irgendwo verstreut, ist es wesentlich schwerer Fehler
an ihrer Position zu erkennen. Es geht ja nicht nur darum dem Leser die Idee des Codes darzubringen,
sondern der Leser muss auch in der Lage sein "Code = Absicht" einfach zu prüfen. Wenn man es
trotzdem durchziehen will, wäre es zumindest Pflicht die Positionen der begin und ends vollautomatisch
mit den Einrückungen abzugleichen.

Was aber nicht so einfach geht wegen:
2) Wenn die Zeilen länger werden und man Zeilenumbrüche im Code hat, die nicht zur Syntax gehören,
funktioniert dieses "Syntax = Einrückung" einfach nicht mehr.
Das kommt u.a. vor bei
- Funkitionsaufrufen mit vielen Parametern
- längeren Verkettungen von Strings
- längeren boolschen Bedingungen
- ...

Der "Richtige" Stil ist folgender:

Code: Alles auswählen

 
if (........) then
begin
 
end;
 

"begin" und "end" immer auf selber Einrücktiefe. Das erzeugt im Code ein Rechteck-Muster, das sehr einfach zu erkennen ist.

Schlechter, aber recht üblich ist auch:

Code: Alles auswählen

 
if (....) then begin
 
end;
 

Hier hat man ein Dreieck, mit recht variabeler Breite. Das begin kann dabei auch schon mal aus dem Bildschirm wandern
So ein Dreieck ist von der Mustererkennung her prinzipiell schlechter zu erkennen. In uralten Styleguides war es aber Standard um
Zeilen zu sparen. Seit der Urzeit hat sich die Anzahl der Zeilen, die auf den Bildschirm passen aber drastisch erhöht, und das Argument mit dem
Zeile-Sparen zieht einfach nicht mehr.

Was am besten ist, ist meiner Meinung nach keine Geschmacksfrage, sondern man könnte den Unterschied bestimmt auch objektiv ausmessen.
Z.B. wenn man mal die typischen Augenbewegungen beim Lesen von Codes ausmisst.
Ich bin mir da zu 100% sicher, dass das begin und end auf derselben Einrücktiefe gewinnt.

Nimmt jemand eine Wette an?

[MitjaStachowiak]

Um was wetten wir?^^

Also lesen kann man das mit den gleichen Einrückungen natürlich schon schneller, aber wenn man sich in einen Quelltext hineindenken möchte und ein verschachteltes Bug sucht (Also nicht ein Fehler im Ablauf, sondern ein logischer Fehler in einem Algorithmus, oder so) dann würde ich dennoch das begin am ende der bedingenden Anweisung (for, if, etc.) bevorzugen. So muss man sich nämlich merken, dass der Block, den man bis zum end erkennen kann, zu dieser Anweisung gehört.

Und Zeilen einzusparen ist schon sinnvoll. In sehr langen Units sucht man oft ewig nach einer bestimmten Stelle. Jedes mal einen Suchdialog öffnen... Ich weiß nicht.

[theo]

Nimmt jemand eine Wette an?

Ich wette nicht dagegen, denn ich bin voll und ganz mit deinem Beitrag einverstanden.

[m.fuchs]

Schlechter, aber recht üblich ist auch:

Code: Alles auswählen

 
if (....) then begin
 
end;
 

Hier hat man ein Dreieck, mit recht variabeler Breite. Das begin kann dabei auch schon mal aus dem Bildschirm wandern

Da halte ich wiederum dagegen, dass nicht nur das begin aus dem Bildschirm wandert:

Code: Alles auswählen

if Bedingung1 and Bedingung2 and Bedingung3 and Bedingung4 and Bedingung5 and Bedingung6 and Bedingung7 and Bedingung8 and Bedingung9 and Bedingung10 and Bedingung11 and Bedingung12 and Bedingung13 and Bedingung14 and Bedingung15 then DoSomething;
begin
  DoSomeOtherThing;
end;

Wäre hier nicht der Zeilenumbruch vom Forum-Highlighter, dann sähe niemand dass das begin der folgenden Zeile nicht zum if-Statement gehört. Das ist der Grund warum ich vom Borland-Style abweiche. Einfach Faustregel: Endet die letzte Zeile mit einem ; kommt das begin auf die nächste Zeile, sonst nicht.

Abgesehen davon, dass man obige Prüfung in eine separate Funktion auslagern sollte.

[MAC]

Ich versuche immer jede Einrückung zu vermeiden:

Komisch, ich versuche gerde große, aber auch nicht zu viele Einrückungen zu machen
Nachteil ist natürlich, das das ganze schonmal stark nach rechts verschoben werden kann und in die länge gezogen...
Besonders, wenn man, wie ich, einen if/ while / for befehl, entweder in eine Zeile presst, oder ihn komplett entfalltet mit Begin und End, Wie beim "if (b mod 2 = 0) then" ... wo das Begin End eigentlich nicht notwendig ist.
Vorteil ist, das alle Begin und End auf der gleichen Höhe Anfangen und Enden wie auch der zugehörige Code. Sieht man so ein "y[a] := 1;" kann man einfach mit dem Auge solange "hochscrollen" bis man das passende Begin sieht...
Soweit meine Meinung

Code: Alles auswählen

procedure Prozedur1;
begin
for a := 1 to 10 do 
     begin
     for b := 1 to 10 do 
          begin 
          if (b mod 2 = 0 ) then 
              begin
              with (x[a]) do 
                      begin
                      x1[b] := 1;
                      x2[b] := 1;
                      end;
              end;
          y[a] := 1;
          with (z[a]) do 
                 begin
                 for b := 1 to 10 do z1[b] := 1;
                 z2 := 1;
                 end;
          end;
     end;
end;