Opfere ich kürzere Variablennamen für längeren Code mit Spalten?

Ich bin ein Amateur-Programmierer in einer CS-Klasse, der versucht, die richtigen Programmierfähigkeiten zu erlernen. So sieht mein Code aus, seine Kanten erstrecken sich auf 103 Spalten.

int extractMessage(char keyWord[25], char cipherText[17424],
                   int rowSize, char message[388]) 
{
    int keyColumn    = 0;
    int cipherColumn = 0;
    int offset       = 1;
    int nextWord     = 1;

    int lengthOfWord   = 0;
    int lengthOfCipher = 0;

    lengthOfWord = length(keyWord);
    lengthOfCipher = length(cipherText);


    while (keyWord[keyColumn] != cipherText[cipherColumn]) {
        cipherColumn++;
        if (keyWord[keyColumn + offset] != cipherText[cipherColumn + (rowSize*nextWord) + nextWord]) {
            cipherColumn++;
            continue;
        }
    }

Bevor ich diese superlangen Variablennamen hatte, hatte ich etwas wie i, j, k, aber mein Professor besteht darauf, dass wir solche Variablen in der "Berufswelt" nicht verwenden sollen und dass sogar verkürzte Variablen wie lenWord unzureichend sind, weil die Leute annehmen könnten es steht für "Lennards Weltliteratur". Er sagt, er solle aussagekräftige Variablennamen wählen, aber dabei habe ich das Gefühl, dass ich die goldene Kodierungsregel gebrochen habe, um sie unter 80 Spalten zu halten. Wie komme ich darum herum?

Normalerweise bearbeite ich den Code, wenn ich ihn wie Ihren hier sehe, weil wir horizontales Scrollen hassen. Da dies jedoch Teil Ihrer Frage ist, zeige ich Ihnen die Bearbeitung hier:

int extractMessage(char keyWord[25], char cipherText[17424],
                   int rowSize, char message[388]) 
{
    int keyColumn    = 0;
    int cipherColumn = 0;
    int offset       = 1;
    int nextWord     = 1;

    int lengthOfWord   = 0;
    int lengthOfCipher = 0;

    lengthOfWord = length(keyWord);
    lengthOfCipher = length(cipherText);


    while (keyWord[keyColumn] != cipherText[cipherColumn]) {
        cipherColumn++;
        if (keyWord[keyColumn + offset] 
        != cipherText[cipherColumn + (rowSize*nextWord) + nextWord]) {
            cipherColumn++;
            continue;
        }
    }
}

Das Pause mag überraschend sein, aber es ist besser lesbar als die Version mit horizontalem Bildlauf, und es ist besser als die Namen der Verkürzung i, jund k.

Es ist nicht , dass Sie nie benutzen sollten i, jund k. Dies sind gute Namen für die Indizierung von 3 verschachtelten forSchleifen. Aber hier sind die Namen wirklich mein einziger Hinweis darauf, was Sie erwartet haben. Zumal dieser Code eigentlich gar nichts macht.

Die beste Regel für die Länge von Variablennamen ist der Gültigkeitsbereich. Je länger eine Variable lebt, desto mehr andere Variablen müssen mit ihrem Namen konkurrieren. Der Name CandiedOrange ist beim Stapelaustausch eindeutig. Wenn wir in einem Chat wären, könntest du mich einfach "Candy" nennen. Aber im Moment befinden Sie sich in einem Bereich, in dem dieser Name mit Candide , Candy Chiu oder Candyfloss verwechselt werden könnte . Je länger der Gültigkeitsbereich, desto länger sollte der Name sein. Je kürzer der Gültigkeitsbereich, desto kürzer kann der Name sein.

Die Zeilenlänge sollte niemals die Länge des Namens bestimmen. Wenn Sie das Gefühl haben, finden Sie einen anderen Weg, um Ihren Code zu gestalten. Wir haben viele Tools, die Ihnen dabei helfen.

Eines der ersten Dinge, die ich suche, ist unnötiger Lärm, den ich loswerden muss. Leider macht dieses Beispiel nichts, daher ist alles unnötiges Rauschen. Ich brauche etwas zum Arbeiten, also lassen wir es zuerst etwas tun.

int calcCipherColumn(char keyWord[25], char cipherText[17424],
                     int rowSize, char message[388]) 
{
    int keyColumn    = 0;
    int cipherColumn = 0;
    int offset       = 1;
    int nextWord     = 1;

    int lengthOfWord   = 0;
    int lengthOfCipher = 0;

    lengthOfWord = length(keyWord);
    lengthOfCipher = length(cipherText);

    while (keyWord[keyColumn] != cipherText[cipherColumn]) {
        cipherColumn++;
        if (keyWord[keyColumn + offset] 
        != cipherText[cipherColumn + (rowSize*nextWord) + nextWord]) {
            cipherColumn++;
            continue;
        }
    }
    return cipherColumn;
}

Dort macht es jetzt etwas.

Jetzt, wo es etwas tut, kann ich sehen, was ich loswerden kann. Diese Länge Zeug wird nicht einmal verwendet. Das continuemacht auch nichts.

int calcCipherColumn(char keyWord[25], char cipherText[17424],
                     int rowSize, char message[388]) 
{
    int keyColumn    = 0;
    int cipherColumn = 0;
    int offset       = 1;
    int nextWord     = 1;

    while (keyWord[keyColumn] != cipherText[cipherColumn]) {
        cipherColumn++;
        if (keyWord[keyColumn + offset] 
        != cipherText[cipherColumn + (rowSize*nextWord) + nextWord]) {
            cipherColumn++;
        }
    }
    return cipherColumn;
}

Lassen Sie uns ein paar kleinere Änderungen an Leerzeichen vornehmen, da wir in einer Welt der Quellcodeverwaltung leben und es schön ist, wenn eine Zeile nur deshalb als geändert gemeldet wird, weil sie etwas anderes tut, und nicht, weil ein Teil davon in einer Spalte ausgerichtet werden musste.

int calcCipherColumn(char keyWord[25], char cipherText[17424],
                     int rowSize, char message[388]) 
{
    int keyColumn = 0;
    int cipherColumn = 0;
    int offset = 1;
    int nextWord = 1;

    while (keyWord[keyColumn] != cipherText[cipherColumn]) {
        cipherColumn++;
        if (keyWord[keyColumn + offset] 
        != cipherText[cipherColumn + (rowSize*nextWord) + nextWord]) {
            cipherColumn++;
        }
    }
    return cipherColumn;
}

Ja, ich weiß, dass es etwas weniger lesbar ist, aber sonst werden Sie Leute verrückt machen, die vdiff-Tools verwenden, um Änderungen zu erkennen.

Beheben wir nun diese dummen Zeilenumbrüche, die wir haben, weil wir versuchen, unter den Grenzen der Zeilenlänge zu bleiben.

int calcCipherColumn(
        char keyWord[25], 
        char cipherText[17424],
        int rowSize, 
        char message[388]
) {
    int keyColumn = 0;
    int keyOffset = 1;

    int nextWord = 1;
    int cipherColumn = 0;
    int cipherOffset = (rowSize * nextWord) + nextWord;

    char key = keyWord[keyColumn];
    char keyNext = keyWord[keyColumn + keyOffset];

    while (key != cipherText[cipherColumn]) {
        cipherColumn++;
        if (keyNext != cipherText[cipherColumn + cipherOffset]) {
            cipherColumn++;
        }
    }
    return cipherColumn;
}

Dort konzentriert sich nun die Logik in der Schleife darauf, was sich in der Schleife ändert. Tatsächlich konnte alles außer cipherColumnmarkiert werden final. Und hey! Sieh dir das an. Wir haben jetzt Raum dafür.

Alles, was ich getan habe, war, 3 weitere Variablen hinzuzufügen, eine umzubenennen und sie ein wenig neu anzuordnen. Und das Ergebnis war, dass die Linien kurz genug waren, um ohne dummen Zeilenumbruch zu passen !=.

Sicher , die Namen keyund keyNextist nicht so beschreibend, aber sie jeweils nur einmal gewöhnen, nicht so lange leben, und vor allem nicht etwas zu tun , dass in der Schleife interessant. Sie müssen es also nicht sein. Durch die Einführung zusätzlicher Variablen haben wir jetzt Platz, um ihre Namen zu verlängern, wenn dies erforderlich ist. Die Dinge ändern sich, also müssen wir es eventuell tun. Wenn wir das tun, ist es schön, dass wir Raum zum Atmen haben.

Ich habe mir auch die Freiheit genommen, Ihnen Jeff Griggs Form-6-Variante zu zeigen, bei der Eingabeparameter so angeordnet werden, dass sie die Beschränkungen der Zeilenlänge einhalten.

Andere haben bereits einige nützliche Vorschläge gemacht, lassen Sie mich zusammenfassen:

• In den 80er Jahren waren möglicherweise 80 Zeichen pro Zeile eine goldene Regel. Heutzutage stimmen die meisten Menschen darin überein, dass 100 bis 130 Zeichen in Ordnung sind.
• Verwenden Sie in Ihren Ausdrücken Zeilenumbrüche.
• Teilen Sie lange Ausdrücke, indem Sie Zwischenergebnisse einfügen.

Ich möchte noch eine Empfehlung hinzufügen: Sei nicht dogmatisch über lange Namen! Je größer der Gültigkeitsbereich einer Variablen ist, desto mehr Informationen müssen in ihren Namen eingefügt werden. Im Allgemeinen ist es eine gute Idee, den Umfang der Variablen klein zu halten.

Wenn Sie beispielsweise eine Variable für die Spalte Ihrer Schlüsselwortverschlüsselungstabelle haben und klar ist, dass nur diese eine Tabelle im Bereich Ihrer Variablen verwendet wird, ist es in Ordnung, sie columnoder sogar aufzurufen col. Wenn der Bereich größer ist und mehrere Tabellen betroffen sind, ist es sinnvoll, ihn aufzurufen keyWordEncryptionTableColumn.

Ein weiteres Beispiel: Wenn Sie eine Schleife mit einem zwei- oder dreizeiligen Text haben und einen Index für den Zugriff auf Elemente eines Arrays verwenden müssen, ist der Aufruf des Index nichts Falsches i. In diesem Zusammenhang ist es viel lesbarer (zumindest für die meisten Menschen) als etwa arrayIndexOfMyVerySpecialDataSet.

Ich stimme im Allgemeinen mit Ihrem Lehrer überein. Wenn Sie jedoch eine Variable haben, die Sie häufig in einem fehlerhaften großen Teil des Codes verwenden werden, ist es möglicherweise besser, eine Kurzform zu verwenden, nachdem Sie deren Bedeutung explizit angegeben haben. Wie wenn Sie viele komplexe arithmetische Ausdrücke und Zuweisungen haben, lesen sich diese mit langen Variablennamen nicht so gut.

Über Gliederung:

ExtractMessage(char keyWord[25], char cipherText[17424],
               int rowSize, char message[388]) 

Dies hat keinen Zweck, nur die Beschränkung der Zeilenlänge macht es nicht lesbarer. Wenn Sie möchten, dass dies lesbar ist, gehen Sie wie folgt vor:

ExtractMessage(
  char keyWord[25],
  char cipherText[17424],
  int rowSize,
  char message[388]
  )
{

Und dann möchten Sie möglicherweise sogar Typbezeichner ausrichten (ein Leerzeichen nach int einfügen). Seien Sie jedoch vorsichtig / restriktiv, wenn Sie Initalisierungen oder Argumentlisten wie die folgenden skizzieren:

int keyColumn    = 0;
int cipherColumn = 0;
int offset       = 1;
int nextWord     = 1;

Das Problem ist, wenn Sie einen Namen ändern oder eine Variable hinzufügen, müssen Sie möglicherweise den gesamten Block neu formatieren, um das ansprechende Erscheinungsbild beizubehalten. Es ist weniger für die Arbeit als für die bedeutungslosen Änderungen, die Sie einführen würden, es würde in einem Versionskontrollsystem schrecklich aussehen. Ihr Kollege würde sehen, dass Sie die Datei geändert haben und einen Vergleich mit der vorherigen Version durchführen, um zu sehen, was Sie getan haben. Dann würde jede Zeile als geändert aufleuchten und die tatsächliche Änderung verdecken. Es würde ein wenig von der Qualität des verwendeten Vergleichstools abhängen, wie schlecht dies tatsächlich wäre, aber im Allgemeinen ist es keine gute Idee, den Code zu persönlich zu gestalten und / oder die Formatierung einer Zeile von der anderen abhängig zu machen.

Manchmal kann die Gliederung einen Zweck erfüllen. Wenn Sie zig aufeinanderfolgende Linien haben, die fast gleich sind, können Sie leicht erkennen, wo sie sich unterscheiden, wenn Sie sie umreißen.

Beachten Sie, dass an einem Arbeitsplatz möglicherweise eine automatische Formatierung ausgeführt wird, durch die lediglich alle ungewöhnlichen Formatierungen, die Sie an Ihrem Code vornehmen, gelöscht werden, bevor Sie ihn an das Versionskontrollsystem senden.

Haftungsausschluss: Ich übertreibe hier ein bisschen, um meinen Standpunkt klarer zu machen. Nehmen Sie also einen Superlativ mit einem Körnchen Salz.

Ihr Lehrer hat zu 100% Recht: Es gibt keine "goldene Regel" mehr für 80 Zeichen (es sei denn, Sie schreiben Linux-Code). Diese Regel wurde aufgrund der Größe der Terminals festgelegt, aber heutzutage können Sie problemlos über 150 Zeichen in Ihrem Enditor-Fenster speichern. Und selbst wenn Sie dieses Limit überschreiten, wird Ihr Editor die Zeile hoffentlich in Zeilenumbrüche umbrechen, damit Sie nicht scrollen müssen. Der einzige Grund, 80 Zeichen nicht zu überschreiten, war das Scrollen .

Das heißt, es besteht in der Tat die Notwendigkeit, Ihre Linien nicht auf unbestimmte Zeit wachsen zu lassen. Je länger die Linie ist, desto schwieriger wird es für einen Menschen, sie zu analysieren. Aber kurze Variablennamen sind nicht die Mittel für die Ausgabe langen Linien .

Das Mittel ist, Ihre Ausdrücke logisch zu teilen, indem Sie noch besser benannte Variablen einführen . Versuchen Sie nicht, mit Leerzeichen klug umzugehen. Identifizieren Sie einfach einen Teilausdruck, der passend benannt werden kann, und erstellen Sie eine Variable dafür. Dies vereinfacht sowohl die Code-Berechnung der Variablen als auch den Code, der diese Variable verwendet .

Kein Teil Ihrer Frage, aber ich möchte sie trotzdem kommentieren: Es ist eine sehr schlechte Idee, Ihre =Operatoren vertikal auszurichten .

Dafür gibt es drei Gründe:

1. Das Bearbeiten eines Blocks mit vertikal zugewiesenen Operatoren ist eine PITA. Immer wenn sich die Länge der größten Variablen ändert (Umbenennen, Hinzufügen, Löschen), müssen Sie alle Zeilen im Block retuschieren, um Ihr "schönes" Layout wieder herzustellen.

   Natürlich kann dieses Problem durch die Verwendung eines kompetenten Editors etwas verringert werden, daher ist dies der kleinere Grund. Der wahre Grund ist der zweite:

2. Diese unechten Whitespace-Änderungen, die durch die Neuausrichtung eingeführt wurden, passen nicht gut zu modernen Versionskontrollsystemen wie git. Sie neigen dazu, erhebliche Mengen von Zusammenführungskonflikten zu erzeugen, wenn kein wirklicher Konflikt aufgetreten ist und wenn kein Konflikt signalisiert würde, wenn die Ausrichtung nicht verwendet würde. Jeder dieser unechten Konflikte kostet Sie wertvolle Zeit für nichts .

3. Das Alignment hat keine semantische Bedeutung . Es hat keinen Sinn. Es gibt nichts, was Sie mit der Ausrichtung besser verstehen können. Jede Zeile in Ihrem Block muss für sich gelesen werden, um zu verstehen, was sie tut. Die Verbindung zu den Zeilen darüber und darunter ist rein syntaktischer Natur.

Da die Ausrichtung keine semantische Bedeutung hat, aber erhebliche Kosten verursacht, sollten Sie die Gewohnheit verlernen, bevor sie Sie mehr Zeit kostet.

Wenn Ihnen die Beschränkung auf 80 Zeichen so gut gefällt, probieren Sie eine Fortran-Programmierung aus. Zwar haben die neueren Standards die Obergrenze für fortran-Zeilen auf 132 Zeichen angehoben, aber es bleibt so, wie es immer die Kompilierung eines Programms lähmt, das die Obergrenze überschreitet. Wenn Sie sich gut mit Programmieren auskennen, werden Sie bald Fortran hassen, einschließlich der Begrenzung der Zeilenlänge. Danach wirst du für den Rest deines Lebens geheilt.

Ich musste mich professionell mit Fortran-Programmierung befassen, und ich sage Ihnen, es hat mich gelehrt, diese Zeilenlängenbeschränkung am meisten zu hassen. Es gibt absolut nichts Frustrierenderes, als eine ansonsten einfache und lesbare Zeile in Teile aufteilen zu müssen, nur weil der Compiler sie nicht mehr richtig kompiliert. Und es gibt definitiv Codezeilen, die am einfachsten sind, wenn sie als einzelne Zeile ausgedrückt werden.

Viele stilistische Konventionen (keine Regeln!) Sind im Laufe der Jahre aufgrund von Einschränkungen in Programmierumgebungen entstanden. Zurück in Lochkarten Tagen hatten Sie eine harte Begrenzung für die Anzahl der Zeichen , die auf einer physischen Quellenleitung erscheinen könnte (weshalb Fortran Spalte reserviert 6 für Zeilenfortsetzungszeichen). Es war noch nicht so viele Jahrzehnte her, dass ich an einem 80x24 Amber-on-Black-VT220-Terminal arbeitete. Während die von mir verwendeten Editoren die Zeilen nicht auf 80 Zeichen beschränkten, war das Leben viel einfacher, wenn Sie Ihr Bestes gaben, um horizontales Scrollen zu vermeiden.

Unter älteren Versionen von Fortran (bis '77, IINM), könnten Sie nicht einmal haben identifers , die mehr als 6 bis 8 Zeichen lang waren. Noch in den 80er Jahren garantierte C nur, dass die ersten 8 Zeichen in externen Namen aussagekräftig waren (weshalb manche Bibliotheksfunktionen wunderbar beschreibende Namen haben wie strpbrk).

Natürlich haben wir nach zwei Jahrzehnten des 21. Jahrhunderts diese Grenzen nicht mehr. Es gibt keinen Grund, keine aussagekräftigeren Bezeichner zu verwenden.

Die Sache ist, in den richtigen Kontexten iund jund ksind durchaus vernünftige, aussagekräftige Namen . Wenn ich durch ein Array oder einen Vektor in einer Schleife iteriere und nur etwas brauche, um das aktuelle Element zu identifizieren, ifunktioniert das perfekt. Ich würde keinen Namen wie verwenden currentElement- er ist in diesem Zusammenhang nicht aussagekräftiger und fügt nur visuelle Unordnung hinzu.

Allerdings ist Ihr Lehrer nicht verkehrt, Sie zu zwingen, in längeren, aussagekräftigeren Namen für alles zu denken - das Leben wird für Sie einfacher, wenn Sie sich zuerst an diese Gewohnheit gewöhnen und dann lernen, wo Sie bei Bedarf sparen können. Als jemand, der war auf einmal fit alles in 8 Zeichen oder weniger gezwungen, es ist auf jeden Fall besser, err auf der Seite der mehr Informationen als weniger. Wenn Sie mehr Erfahrung sammeln, erfahren Sie, wo Sie die Länge des Bezeichners einsparen können und wo Sie etwas aussagekräftiger sein müssen.

Ich bin nicht sicher, ob dies für c funktioniert oder nicht, aber gibt es eine Möglichkeit, Formeln auf mehrere Zeilen aufzuteilen? Ich weiß, dass es so etwas für Python gibt.

Prüfen Sie, ob Sie + (rowSize * nextWord) + nextWord]) {in einer neuen Zeile beginnen können. (Drücken Sie beispielsweise die Eingabetaste in Ihrer IDE und prüfen Sie, ob sie eingerückt ist, damit C weiß, dass der vorherige Ausdruck in der aktuellen Zeile vervollständigt wird.)