Dois-je sacrifier des noms de variable plus courts pour un code «à colonnes» plus long?

Je suis un programmeur amateur dans une classe CS essayant d'apprendre des compétences de programmation appropriées. Voici à quoi ressemble mon code, les bords de celui-ci s'étendent à 103 colonnes.

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;
        }
    }

Avant d'avoir ces noms de variables super longs, j'avais des choses comme i, j, k, mais mon professeur insiste sur le fait que nous ne devons pas utiliser des variables comme ça dans le "monde professionnel" et que même des variables raccourcies comme lenWord sont insuffisantes parce que les gens pourraient supposer il signifie "Lennard's World Literature". Il dit de choisir des noms de variables significatifs, mais ce faisant, j'ai l'impression d'avoir enfreint la règle d'or du codage pour la maintenir sous 80 colonnes. Comment puis-je contourner cela?

Normalement, quand je vois du code affiché ici comme le vôtre, je le modifie, car nous détestons le défilement horizontal. Mais puisque cela fait partie de votre question, je vais vous montrer le montage ici:

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;
        }
    }
}

Cette pause peut surprendre, mais il est plus lisible que la version avec défilement horizontal, et il vaut mieux que raccourcir les noms i, jet k.

Ce n'est pas que vous ne devez jamais utiliser i, jet k. Ce sont de bons noms lors de l'indexation de 3 forboucles imbriquées . Mais ici, les noms sont vraiment mon seul indice sur ce que vous attendiez. D'autant plus que ce code ne fait rien.

La meilleure règle à suivre sur la longueur du nom de variable est la portée. Plus une variable vit longtemps, plus il y a de variables avec lesquelles son nom doit rivaliser. Le nom CandiedOrange est unique sur l'échange de pile. Si nous étions en discussion, tu pourrais juste m'appeler "Candy". Mais en ce moment, vous êtes dans une perspective où ce nom pourrait être confondu avec Candide , Candy Chiu ou Candyfloss . Donc, plus la portée est longue, plus le nom doit être long. Plus la portée est courte, plus le nom peut être court.

La longueur de ligne ne doit jamais dicter la longueur du nom. Si vous en avez envie, trouvez une autre façon de présenter votre code. Nous avons de nombreux outils pour vous y aider.

L'une des premières choses que je recherche, c'est le bruit inutile pour s'en débarrasser. Malheureusement, cet exemple ne fait rien, donc tout ce bruit inutile. J'ai besoin de quelque chose avec lequel travailler alors commençons par faire quelque chose.

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;
}

Là, maintenant ça fait quelque chose.

Maintenant qu'il fait quelque chose, je peux voir de quoi je peux me débarrasser. Ce truc de longueur n'est même pas utilisé. Cela continuene fait rien non plus.

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;
}

Faisons quelques ajustements mineurs dans les espaces blancs, car nous vivons dans un monde de contrôle de source et c'est bien quand la seule raison pour laquelle une ligne est signalée comme modifiée est parce qu'elle fait quelque chose de différent, pas parce qu'une partie de celle-ci devait s'aligner dans une colonne.

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;
}

Oui, je sais que c'est un peu moins lisible, mais sinon, vous rendrez fou les gens qui utilisent les outils vdiff pour détecter les changements.

Maintenant, corrigeons ces sauts de ligne stupides que nous avons parce que nous essayons de rester sous les limites de longueur de ligne.

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;
}

Là, maintenant la logique dans la boucle se concentre sur ce qui change dans la boucle. En fait, tout sauf cipherColumnpourrait être marqué final. Et bon! Regarde ça. Nous avons maintenant de la place pour le faire.

Tout ce que j'ai fait, c'est ajouter 3 variables supplémentaires, renommer une et les réorganiser un peu. Et le résultat est arrivé à rendre les lignes suffisamment courtes pour s'adapter sans un saut de ligne idiot !=.

Bien sûr , les noms keyet keyNextne sont pas que descriptive, mais chacun ne s'utilisé qu'une seule fois, ne pas vivre longtemps, et surtout ne font pas tout ce qui intéressant dans la boucle. Ils n'ont donc pas besoin de l'être. En introduisant des variables supplémentaires, nous avons maintenant de la place pour rendre leurs noms longs si nous en avons besoin. Les choses changent, nous devrons donc éventuellement le faire. Si nous le faisons, c'est bien que nous ayons de la respiration.

J'ai également pris la liberté de vous montrer le style de variante de la forme 6 de Jeff Grigg de présentation des paramètres d'entrée pour respecter les restrictions de longueur de ligne.

D'autres ont déjà fait quelques suggestions utiles, permettez-moi de résumer:

• 80 caractères par ligne auraient pu être une règle d'or dans les années 80. De nos jours, la plupart des gens conviennent que 100 à 130 caractères conviennent.
• Utilisez des sauts de ligne dans vos expressions.
• Séparez les expressions longues en introduisant des résultats intermédiaires.

J'aime ajouter une autre recommandation: ne soyez pas dogmatique à propos des noms longs! Plus la portée d'une variable est grande, plus il faut mettre d'informations dans son nom. Et généralement, c'est une bonne idée de garder la portée des variables petite.

Par exemple, si vous avez une variable pour la colonne de votre table de chiffrement de mots clés et qu'il est clair qu'il n'y a qu'une seule table utilisée dans la portée de votre variable, il est correct de l'appeler columnou même col. Si la portée est plus grande et que plusieurs tables sont impliquées, il est judicieux de l'appeler keyWordEncryptionTableColumn.

Un autre exemple: si vous avez une boucle avec un corps couvrant deux ou trois lignes et devez utiliser un index pour accéder aux éléments d'un tableau, il n'y a rien de mal à appeler l'index i. Dans ce contexte, il est beaucoup plus lisible (pour la plupart des gens au moins) que, disons arrayIndexOfMyVerySpecialDataSet.

Je suis généralement d'accord avec vous, professeur. Cependant, si vous avez une variable que vous allez utiliser beaucoup dans un gros morceau de code défaillant, il peut être préférable d'utiliser une forme abrégée pour elle après avoir été explicite sur sa signification. Comme lorsque vous avez beaucoup d'expressions et d'affectations arithmétiques complexes, celles-ci ne se lisent pas aussi bien avec des noms de variable longs.

À propos des grandes lignes:

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

Cela ne sert à rien, le fait de limiter la longueur de la ligne ne la rend pas plus lisible. Si vous voulez que cela soit lisible, procédez comme suit:

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

Et puis, vous pouvez même vouloir aligner les identificateurs de type (ajoutez un espace après int). Cependant, soyez prudent / restrictif en décrivant les initalisations ou les listes d'arguments comme ceci:

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

Le problème est que lorsque vous modifiez un nom ou ajoutez une variable, vous devrez peut-être reformater tout le bloc pour conserver son aspect esthétique. Ce n'est pas pour le travail autant que pour les changements insignifiants que vous introduiriez, cela aurait l'air horrible dans un système de contrôle de version. Votre collègue verrait que vous avez modifié le fichier et fera une différence avec la version précédente pour voir ce que vous avez fait. Ensuite, chaque ligne s'allumait comme modifiée, masquant le vrai changement. Cela dépendrait un peu de la qualité de l'outil de comparaison utilisé, à quel point cela serait mauvais, mais en général, ce n'est pas une bonne idée de rendre le code trop personnel et / ou de faire dépendre le formatage d'une ligne de l'autre.

Parfois, le contour peut servir à quelque chose, si vous avez des dizaines de lignes consécutives qui sont presque les mêmes, il sera facile de repérer où elles sont différentes si vous les décrivez.

Notez qu'un lieu de travail peut avoir un formatage automatisé en cours qui supprimera simplement tout formatage de fantaisie que vous faites à votre code avant de le soumettre au système de contrôle de version.

Avertissement: j'exagère un peu ici pour clarifier mon propos. Prenez donc tout superlatif avec un grain de sel.

Votre professeur a raison à 100%: il n'y a plus de "règle d'or" concernant environ 80 caractères (sauf si vous écrivez du code linux, c'est-à-dire). Cette règle a été établie en raison de la taille des terminaux à l'époque, mais de nos jours, vous pouvez facilement entasser plus de 150 caractères dans votre fenêtre enditor. Et même si vous dépassez cette limite, votre éditeur devrait, espérons-le, boucler la ligne en douceur afin que vous n'ayez pas à faire défiler. Et la seule raison de ne pas dépasser 80 caractères était la nécessité de faire défiler .

Cela dit, il est en effet nécessaire de ne pas laisser vos lignes croître indéfiniment. Plus la ligne est longue, plus il devient difficile pour un humain d'analyser. Mais les noms de variables courts ne sont pas le remède au problème des longues lignes .

Le remède consiste à diviser vos expressions logiquement en introduisant des variables encore plus correctement nommées . N'essayez pas d'être intelligent avec les espaces blancs. Identifiez simplement toute sous-expression qui peut être correctement nommée et créez une variable pour elle. Cela simplifie à la fois le code calculant la variable et le code utilisant cette variable .

Cela ne fait pas partie de votre question, mais j'aimerais quand même commenter: c'est une très mauvaise idée d'aligner verticalement vos =opérateurs.

Il y a trois raisons à cela:

1. La modification d'un bloc contenant des opérateurs alignés verticalement est un PITA. Chaque fois que la longueur de la plus grande variable change (renommer, ajouter, supprimer), vous devez retoucher toutes les lignes du bloc pour retrouver votre "belle" disposition.

   Bien sûr, ce problème peut être réduit un peu en utilisant un éditeur compétent, c'est donc la raison mineure. La vraie raison est la seconde:

2. Ces faux espaces blancs introduits par le réalignement ne fonctionnent pas bien avec les systèmes de contrôle de version modernes comme git. Ils ont tendance à créer des quantités importantes de conflits de fusion là où aucun conflit réel ne s'est produit et où aucun conflit ne serait signalé si l'alignement n'était pas utilisé. Chacun de ces faux conflits vous coûtera un temps précieux pour rien .

3. L'alignement n'a aucune signification sémantique . C'est inutile. Il n'y a rien que vous puissiez mieux comprendre avec l'alignement. Chaque ligne de votre bloc doit être lue seule pour comprendre ce qu'elle fait, la connexion aux lignes ci-dessus et ci-dessous est de nature purement syntaxique.

Étant donné que l'alignement n'a aucune signification sémantique, mais génère des coûts importants, vous devez désapprendre l'habitude avant qu'elle ne vous coûte plus de temps.

Si vous aimez tant la limite de 80 caractères, essayez une programmation fortran. Certes, les nouvelles normes ont augmenté la limite de ligne fortran à 132 caractères, mais elle reste en vigueur, comme toujours, paralysant la compilation de tout programme qui dépasse la limite. Si vous êtes bon en programmation, vous allez bientôt détester le fortran, y compris sa limite de longueur de ligne. Après cela, vous serez guéri pour le reste de votre vie.

J'ai moi-même dû faire de la programmation fortran professionnellement, et je vous le dis, cela m'a appris à détester cette limite de longueur de ligne très cher. Il n'y a absolument rien de plus frustrant que de devoir diviser une ligne autrement simple et lisible en parties simplement parce que le compilateur ne la compilera plus correctement. Et il y a certainement des lignes de code qui sont plus simples lorsqu'elles sont exprimées en une seule ligne.

De nombreuses conventions stylistiques (pas des règles!) Sont apparues au fil des ans en raison des limitations des environnements de programmation. Retour en jours-cartes perforées, vous aviez une dure limite du nombre de caractères qui pourraient apparaître sur une ligne de source physique (qui était la raison pour laquelle la colonne réservée Fortran 6 pour les caractères de continuation). Il n'y a pas si longtemps, je travaillais sur un terminal VT220 ambre sur noir 80x24; alors que les éditeurs que j'ai utilisés ne limitaient pas les lignes à 80 caractères, la vie était beaucoup plus facile si vous faisiez de votre mieux pour éviter le défilement horizontal.

Sous les anciennes versions de Fortran (jusqu'à 77, IINM), vous ne pouviez même pas avoir d' identifiants de plus de 6 à 8 caractères. Même aussi tard que dans les années 80, C ne garantissait que les 8 premiers caractères des noms externes étaient significatifs (c'est pourquoi certaines fonctions de bibliothèque ont des noms merveilleusement descriptifs comme strpbrk).

Bien sûr, deux décennies après le début du 21e siècle, nous n'avons plus ces limites. Il n'y a aucune raison de ne pas utiliser plus d'identifiants descriptifs.

La chose est, dans les contextes à droite, iet jet ksont parfaitement raisonnables, des noms significatifs . Si j'itère à travers un tableau ou un vecteur dans une boucle et que j'ai juste besoin de quelque chose pour identifier l'élément actuel, cela ifonctionne parfaitement bien. Je n'utiliserais pas un nom comme currentElement- il n'a plus de sens dans ce contexte , et cela ajoute simplement du désordre visuel.

Cela dit, votre professeur n'a pas tort de vous forcer à penser en termes de noms plus longs et plus descriptifs pour tout - la vie sera plus facile pour vous si vous prenez d'abord cette habitude, puis apprenez où économiser si nécessaire. En tant que personne qui a été obligée à tout moment de tout faire en 8 caractères ou moins, il est certainement préférable d'errer du côté de plus d'informations que de moins. Au fur et à mesure que vous gagnez en expérience, vous apprendrez où vous pouvez économiser sur la longueur de l'identifiant et où vous devez être un peu plus descriptif.

Je ne sais pas si cela fonctionne pour c ou non, mais existe-t-il un moyen de fractionner les formules sur plusieurs lignes? Je sais que quelque chose comme ça existe pour python.

Voyez si vous pouvez commencer + (rowSize * nextWord) + nextWord]) {sur une nouvelle ligne. (Comme appuyez sur Entrée dans votre IDE et voyez s'il l'indente afin que C sache que l'expression précédente est en train de se terminer sur la ligne actuelle)