Verschlüsselung bzw. Entschlüsselung will nicht gelingen

[Faffy]

Zitat von sx2008:

Zitat von Insider2004:

Schau mal auf Deinen Code. Deiner grünen Kommentare sind länger als der Programmcode. Guter Code braucht keine Kommentare. Benenne Deine Variablen erst mal gescheit.

Das kann ich nur unterstützen!!
Variablen- und Funktionsnamen dürfen wirklich mehr als ein oder zwei Buchstaben lang sein.
Die Zeiten von Sharp Taschenrechner mit ihrem Basic-Dialekt sind lange vorbei.

Ich mag lange Variablen nicht, sondern arbeite lieber mit Abkürzungen und weit rechts am Rand mit vielen Kommentaren. Aber dennoch danke für dein Meinungsbild, ich werde jedoch fortfahren, sodass ich es selbst am Besten finde.

[Faffy]

Zitat von Faffy:

Perfekt, vielen Dank. Jetzt funktioniert es echt wunderbar, ihr habt mir sehr geholfen.

Eine Frage hätte ich jedoch noch, da mir das nicht ganz klar ist.
Warum muss bei Procedure A
Procedure TCaesar.A (T : String; Var T2 : String; Z : Integer); Das "Var T2 : String" hinter "T : String;" stehen und bei Procedure B

Procedure TCaesar.B (Var T2 : String; T : String; Z : Integer); das "Var T2 : String;" eben am Anfang?

Dies hier steht bitte immer noch als zentrale Frage offen, verzeiht mir den Doppelpost, aber ich hatte Angst, dass es so sonst übergangen wird .

[Medium]

Zitat:

Ich mag lange Variablen nicht, sondern arbeite lieber mit Abkürzungen und weit rechts am Rand mit vielen Kommentaren. Aber dennoch danke für dein Meinungsbild, ich werde jedoch fortfahren, sodass ich es selbst am Besten finde.

Dann wünsche ich viel Freude bei deinen weiteren Forumsfragen, oder sobald du mal mit jemandem anderes zusammen arbeiten musst.

[cookie22]

Zitat von Insider2004:

Guter Code braucht keine Kommentare.

Halte ich für ein Gerücht und einen schlechten Tipp für einen Anfänger.

Guter Code kann hoch kompliziert sein, du hättest schreiben sollen: "Einfacher Code braucht keine Kommentare.". Und auch das ist kein guter Stil.

[Klaus01]

Zitat von Faffy:

Perfekt, vielen Dank. Jetzt funktioniert es echt wunderbar, ihr habt mir sehr geholfen.

Eine Frage hätte ich jedoch noch, da mir das nicht ganz klar ist.
Warum muss bei Procedure A
Procedure TCaesar.A (T : String; Var T2 : String; Z : Integer); Das "Var T2 : String" hinter "T : String;" stehen und bei Procedure B

Procedure TCaesar.B (Var T2 : String; T : String; Z : Integer); das "Var T2 : String;" eben am Anfang?

Wie sieht denn die Parameterlist in der Type/Klassen-Deklaration aus?
Grüße
Klaus

[Sir Rufo]

Zitat von Faffy:

Zitat von sx2008:

Zitat von Insider2004:

Schau mal auf Deinen Code. Deiner grünen Kommentare sind länger als der Programmcode. Guter Code braucht keine Kommentare. Benenne Deine Variablen erst mal gescheit.

Das kann ich nur unterstützen!!
Variablen- und Funktionsnamen dürfen wirklich mehr als ein oder zwei Buchstaben lang sein.
Die Zeiten von Sharp Taschenrechner mit ihrem Basic-Dialekt sind lange vorbei.

Ich mag lange Variablen nicht, sondern arbeite lieber mit Abkürzungen und weit rechts am Rand mit vielen Kommentaren. Aber dennoch danke für dein Meinungsbild, ich werde jedoch fortfahren, sodass ich es selbst am Besten finde.

Da du aber mit den Abkürzungen augenscheinlich selber nicht klar kommst

Zitat von Uwe Raabe:

Innerhalb deine Entschlüsselungsmethode hast du die Bedeutung von T und T2 vertauscht.

und du auch noch sachlich falsche Kommentare dort stehen hast

Delphi-Quellcode:

Procedure TCaesar.A (T : String; Var T2 : String; Z : Integer); 
// T = Zu verschlüsselndes Wort
// T2 = Verschlüsseltes Wort
// Z = Irrelevant (Zahl, um die verschoben wird, ist aber nicht angegeben)
Var
 P, Code : Integer; // P = Länge des Wortes, Code = Verschlüsselungscode
 B : String; // B = Buchstabe des Wortes
 B2 : Char; // B2 = Verschobener Buchstabe
Begin
For P := 1 to Length(T) Do
                                Begin
                                  B := Copy(T,P,1);
                                    Code := ORD(B[1]);
                                    Code := Code - Z;

• P ist also die Länge des Wortes, hmmm, im Code sieht das aber nach einem Index aus
• Z ist nicht irrelevant, wenn nicht angegeben, dann dürfte da keine Veränderung passieren (wenn es ein Caesar-Cipher sein soll)

wirst du hoffentlich verstehen, dass ich deinen Standpunkt nur müde belächeln kann.

Ein guter Code ist niemals kompliziert (KISS) und erklärt sich quasi durch den Code selber. Kommentare werden da nur sehr selten benötigt (meistens Quellenangaben für Formeln oder Erläuterungen zu Konstanten).

[Uwe Raabe]

Zitat von Sir Rufo:

Ein guter Code ist niemals kompliziert (KISS) und erklärt sich quasi durch den Code selber. Kommentare werden da nur sehr selten benötigt (meistens Quellenangaben für Formeln oder Erläuterungen zu Konstanten).

Ich möchte dieses Statement noch um den Fall erweitern, bei dem der Kommentar erklärt, warum man etwas macht. Das ist nämlich nicht immer aus den selbsterklärenden Variablen- und Methodennamen ersichtlich.

[cookie22]

Zitat von Uwe Raabe:

Ich möchte dieses Statement noch um den Fall erweitern, bei dem der Kommentar erklärt, warum man etwas macht. Das ist nämlich nicht immer aus den selbsterklärenden Variablen- und Methodennamen ersichtlich.

Gerade wenn man mit Code zu tun hat, den man nicht selbst geschrieben hat sind Komentare sehr wichtig. "Ein guter Code ist niemals kompliziert." Das halte ich wie schon gesagt für ein Gerücht.

[Sir Rufo]

Zitat von cookie22:

Zitat von Uwe Raabe:

Ich möchte dieses Statement noch um den Fall erweitern, bei dem der Kommentar erklärt, warum man etwas macht. Das ist nämlich nicht immer aus den selbsterklärenden Variablen- und Methodennamen ersichtlich.

Gerade wenn man mit Code zu tun hat, den man nicht selbst geschrieben hat sind Komentare sehr wichtig. "Ein guter Code ist niemals kompliziert." Das halte ich wie schon gesagt für ein Gerücht.

Welches du uns gerne mit einem konkreten Beispiel zeigen darfst, welches wir dann seinerseits mit den von uns genannten Vorgaben widerlegen werden

Ist der Code einer Routine/Methode zu kompliziert, dann macht dieser Codeteil einfach zu viel -> zerlegen in kleinere Routinen/Methoden

[cookie22]

Zitat von Sir Rufo:

Welches du uns gerne mit einem konkreten Beispiel zeigen darfst, welches wir dann seinerseits mit den von uns genannten Vorgaben widerlegen werden

Ist der Code einer Routine/Methode zu kompliziert, dann macht dieser Codeteil einfach zu viel -> zerlegen in kleinere Routinen/Methoden

Du gehst hier aber vom Idealfall aus, nicht von der Realität. Wenn man in Teams mit vielen Leuten an einer Code-Base arbeitet, dann hat man viele Leute, die in einem Topf rühren. Wenn da nicht kommentiert wird, findet sich da niemand mehr zurecht. Dann hat man viele Programmierer mit unterschiedlichem Skill-Level. Das, was einer leicht versteht, sind für andere böhmische Dörfer. Es geht auch sicher nicht darum, jede einzelne Zeile zu kommentieren, aber den Sinn einer Sache oder bestimmte Zusammenhänge sollte man schon kommentieren. Das kann viel Zeit sparen.

Aber ich glaub das ist schon wieder OT.