Récemment, dans plusieurs équipes différentes, j'ai constaté que leurs conventions de codage varient considérablement dans l'utilisation des espaces. Cela a piqué ma curiosité, car j'avais toujours pensé qu'il devrait y avoir une meilleure pratique universellement reconnue pour l'utilisation des espaces dans le formatage du code. Mais dans le développement réel, une telle uniformité ne semble pas avoir émergé.

État actuel

Tout d'abord, examinons les conventions de style pour le code Java dans la plupart des IDE Java.

Voici un exemple :

public class Example {

public static void main(String[] args) {
    int answer = 2 + 4 * 6;
    for (int i = 0; i < 5; i++) {
        doSomething();
    }
    System.out.println("The answer is " + answer);
}

    private static void doSomething() {
        // something
    }
}

Notez qu'il s'agit du style le plus courant parmi les programmeurs Java et dans d'autres langages de type C.

Il n'y a pas d'espaces de chaque côté à l'intérieur des parenthèses. Ce n'est que lorsque la parenthèse est précédée d'un mot-clé tel que « for » ou « while » qu'un espace apparaît entre eux, mais il n'y a pas d'espace entre un nom de méthode et la parenthèse suivante. Toutefois, il y a toujours un espace avant l'accolade ouvrante (qui apparaît généralement à la fin d'une ligne). Les opérateurs mathématiques sont toujours entourés d'espaces. Et il n'y a pas d'espace avant un point-virgule.

Si vous lisez souvent du code, vous pouvez penser qu'il s'agit d'une disposition très naturelle, mais si vous n'êtes pas programmeur, vous pourriez trouver ces règles trop arbitraires, avec de nombreuses incohérences, des cas particuliers et des points sujets à débat.

Veuillez laisser plus d'espace pour votre code

Dans mon projet de développement actuel, il y a deux équipes de développement principales dans l'entreprise : l'une est l'équipe Load Test Products (LTP), et l'autre est l'équipe Functional Test Products (FTP). Les deux équipes suivent certaines conventions de style de codage, et toutes deux sont particulièrement généreuses dans leur utilisation des espaces, comme dans l'exemple d'extrait de code suivant :

public class Example
{

    public static void main( String[] args )
    {
        int answer = 2 + 4 * 6;
        for( int i = 0; i < 5; i++ )
        {
            doSomething();
        }
        System.out.println( "The answer is " + answer );
    }

    private static void doSomething()
    {
        // something
    }

}

Ce style rend le code moins dense et plus uniforme (par exemple, il n'y a pas d'espace avant les parenthèses ouvrantes, et il y a des espaces à l'intérieur à gauche et à droite de toutes les parenthèses, accolades et crochets) ! Je ne dis pas que c'est mieux ou moins bien que le style précédent... cela permet simplement de distinguer plus facilement les mots. Le coût, c'est qu'un seul écran peut afficher moins de code.

Bien que chaque style de codage ait ses propres avantages et inconvénients, ce qui m'a surpris, c'est que l'équipe de développement FTP ait finalement décidé de passer au style de codage le plus courant mentionné précédemment. Ils estimaient que ce changement en valait la peine, et ils en ont même discuté, donc je pense qu'ils considéraient ce changement comme important. Leur décision ne reposait pas sur la question de savoir si ce style est meilleur que cet autre... Je pense qu'elle portait principalement sur qui est habitué à ce style, puisque la plupart de nos produits sont open source, ce qui est une raison importante : cela facilite la contribution de code par les programmeurs de la communauté.

Dans mon équipe, l'équipe LTP, nous restons fidèles à notre style et n'avons pas l'intention d'apporter le moindre changement. Au moins pour moi, il s'agit d'une décision fondée sur des considérations techniques : si un autre style de codage ne présente aucun avantage (notre projet a peu besoin de contributions open source), pourquoi passer à un autre style ?

Les règles doivent être unifiées

J'ai contribué du code à des projets open source, comme le langage de programmation Ceylon, et j'ai été très surpris qu'ils ne suivent aucun style de codage. Vous pouvez écrire du code dans le style que vous voulez.

Certains programmeurs qui ont été intimidés par le volume considérable de normes de codage dans certaines entreprises pourraient aimer cela, mais je crois que sans un ensemble de normes de codage, le code de votre projet risque de sombrer dans le chaos du formatage. Chaque contributeur de code apporte son propre style de code unique lorsqu'il soumet du code, ce qui n'est pas surprenant ; le résultat est que tout le code est varié, et vous pouvez voir plusieurs styles différents dans les quelques lignes de code ci-dessous :

while (exists cell = iter) {
        if (exists elem = cell.element,
        elem==element) {
            last = cell;
        }
        iter = cell.rest;
    }
}

if (exists cell=last){
    cell.element=replacement;
    return true;
}
assert (0<=index<length);

La question principale que je veux soulever est la suivante : le style de codage est-il vraiment une pratique de développement importante ? Quel impact a-t-il sur l'efficacité des programmeurs à développer des logiciels ?

Je pense que cette question est liée à une autre question similaire : le formatage du code affecte-t-il la lisibilité du code ?

Le formatage du code affecte la lisibilité du code

Je pense que cette question est très facile à répondre ! Bien sûr que oui. Parcourez visuellement les deux extraits de code suivants ligne par ligne (tirés du projet Ceylon), et vous sentirez facilement lequel est le plus facile à lire. – CeylonCreate)?

function validModuleNameChar(Character c)=>c.letter||c.digit||c in ['_','.' ];
if (!trimmedName.empty,
    validModuleNameFirstChar(trimmedName.first else 'X'),
    trimmedName.every(validModuleNameChar),
    !(trimmedName.split('.'.equals,true,false)).containsAny(ceylonKeywords.chain {""})) {
    return trimmedName;
}
function validModuleNameChar( Character c ) => c.letter || c.digit || c in ['_', '.' ];
if ( ! trimmedName.empty,
    validModuleNameFirstChar ( trimmedName.first else 'X' ),
    trimmedName.every ( validModuleNameChar ),
    ! ( trimmedName.split ( '.'.equals, true, false ) ).containsAny ( ceylonKeywords.chain { "" } ) )
{
    return trimmedName;
}

La différence peut être faible, mais si vous passez beaucoup de temps à lire beaucoup de code toute la journée, la différence devient énorme.

Leçons tirées de l'écriture de textes ordinaires

Quand on parle de lisibilité du code, nous devrions peut-être nous intéresser à la capacité plus ordinaire des gens à lire du texte. Cette capacité s'est développée sur des milliers d'années, alors une meilleure solution aurait dû être trouvée !?

En anglais « ordinaire », vous pouvez voir l'utilisation conventionnelle des espaces, mais vous ne voyez pas d'auteurs discuter de la question de savoir s'ils doivent utiliser des espaces autour des parenthèses ! Alors, à quoi cela ressemblerait-il si le code était écrit comme de l'anglais « ordinaire » ?

Revenons à l'exemple simple ci-dessus :

function validModuleNameChar( Character c ) => c.letter || c.digit || c in ['_', '.' ];
if ( ! trimmedName.empty,
    validModuleNameFirstChar ( trimmedName.first else 'X' ),
    trimmedName.every ( validModuleNameChar ),
    ! ( trimmedName.split ( '.'.equals, true, false ) ).containsAny ( ceylonKeywords.chain { "" } ) )
{
    return trimmedName;
}

La plupart des choses dans le code sont identiques à celles des phrases en anglais ordinaire. Vous utilisez des parenthèses pour « regrouper » certains mots. Vous utilisez des espaces entre les mots et les symboles — ici, nous trouvons un point différent des habitudes de codage courantes : lorsque nous appelons une méthode, il n'y a pas d'espace entre le nom de la méthode et les parenthèses qui suivent, et aucun espace n'est laissé après l'opérateur point.

Je peux comprendre pourquoi il n'y a pas d'espaces à ces endroits, parce que ces parenthèses ou ces points dans le code représentent une sorte de relation de « propriété » ou une association. Mais est-il vraiment nécessaire de supprimer ce petit espace pour représenter cette relation ? Ne trouvons-nous pas cela très clair lorsque nous regardons l'exemple de code ci-dessus ?

Une autre chose qui n'existe pas en anglais ordinaire, ce sont les expressions imbriquées... Nous avons donc des situations qui n'apparaissent pas dans l'écriture anglaise ordinaire. Mais ce n'est pas un gros problème ; il suffit de se rappeler une règle générale : ajouter des espaces des deux côtés des symboles.

Trouvez-vous que le code ci-dessus semble un peu étrange ? Je dois admettre qu'il paraît un peu inconfortable, mais je crois que c'est simplement parce que je n'y suis pas encore habitué.

Bien que je n'y sois pas encore habitué, je suis sûr que ce code est plus facile à lire et à comprendre.

Je peux dire clairement que si tout le code suivait de telles conventions, nous, programmeurs, trouverions la lecture du code beaucoup plus facile.

Conclusion

J'espère qu'aucun programmeur ne pensera que suivre une norme de codage prédéfinie rend la programmation plus difficile !

Tout d'abord, tous les IDE peuvent être configurés pour ajuster automatiquement le formatage du code. Vous pouvez écrire du code en désordre, mais au final n'oubliez pas d'utiliser les raccourcis clavier de l'IDE pour mettre le code en ordre avant de le valider. De même, je doute qu'un écrivain pense que les règles de formatage pour l'écriture de texte soient trop strictes et restreignent sa créativité.

Heureusement, je constate qu'il n'y a pas de problèmes majeurs avec l'utilisation des espaces dans tous les styles et normes de codage actuels. Mais utiliser un peu plus d'espace rendra certainement le code plus clair et plus facile à lire.

Texte original :Donnez un peu d'espace à votre code !

Source :Revue informatique étrangère