Taille de tabulation optimale pour la lisibilité du code [fermé]

J'aime 8 espaces (je sais, Non?). Cela rend le début/ fin des blocs vraiment évident.

En ce qui concerne votre question, une étude formelle de la facilité d'utilisation serait nécessaire. Regardons les limites cependant:

0 espaces

function test(){
var x = 1;
for (i=0; i<=5; i++){
doSomething();
}
}

Aucune indentation n'est évidemment mauvaise. Vous ne pouvez pas dire où quelque chose commence ou se termine.

19 Espaces

function test(){
                   var x = 1;
                   for (i=0; i<=5; i++){
                                      doSomething();
                   }
}

Les charges d'indentation sont évidemment mauvaises aussi, car vous ne pouvez pas lier visuellement le code à sa fonction ou boucle parent (ou ce qui a vous) comme votre vision périphérique ne s'étend pas si loin. Vos yeux doivent feuilleter trop loin d'avant en arrière pour faciliter la lecture.

8 espaces

function test(){
        var x = 1;
        for (i=0; i<=5; i++){
                doSomething();
        }
}

Je pense que j'ai décidé de 8 espaces parce que le mot 'fonction' fait 8 caractères. Mais cela semble si utile pour la lisibilité. Tout le code est dans ma vision périphérique, et il n'y a aucun moyen que je puisse manquer le début d'un nouveau bloc de code si je scanne rapidement.

2 space 4 busy coder
3 space for heavy if statement using script kiddies 
4 space for those who make real money pressing space 4 times
8 space for the man in ties and suit who doesn't need to code

Cette discussion implique souvent des malentendus, parce que ( comme JWZ décrit ) elle implique généralement trois questions distinctes :

• Que se passe-t-il lorsque j'appuie sur la touche Tab dans mon éditeur de texte?

• Que se passe-t-il lorsque je demande à mon éditeur de mettre en retrait une ou plusieurs lignes?

• Que se passe-t-il lorsque je visualise un fichier contenant des caractères de tabulation horizontaux U+0009?

Mes réponses:

• Appuyer sur le bouton Tab la touche doit indenter la ligne courante (ou les lignes sélectionnées) d'un niveau supplémentaire.

  Comme alternative secondaire, je peux également tolérer un éditeur qui, comme Emacs, utilise cette clé pour une commande fix-my-indentation contextuelle.

• Indenter une ou plusieurs lignes devrait suivre la convention régnante, si le consensus est suffisamment fort; sinon, je préfère grandement 4-indentation d'espace à chaque niveau.

• U+0009 caractères devrait déplacer les caractères suivants vers l'onglet suivant stop . Les tabulations commencent à la colonne 1 et sont espacées de 8 colonnes, sans exception.

Je ne connais aucune étude qui répondrait à votre question. Je ne pense pas qu'il y ait un moyen pour que cela soit non subjectif, mais ma préférence personnelle est 4 espaces.

Personne n'a mentionné cela jusqu'à présent, donc je me sens obligé d'en poster un. Le choix de la taille de retrait (que je pense ce que signifiait OP), affecte non seulement la façon dont les codes sont en retrait, mais affecte également la quantité de code que vous pouvez tenir dans une ligne et comment ils s'alignent.

Une équipe de développement doit, finalement, à une sorte d'accord sur la longueur d'une ligne. J'ai commencé avec 80 colonnes et à ce jour je m'en tiens toujours à 80 colonnes. AFAIK, stackoverflow utilise 80 colonnes dans le code source markdown comme Bien.

Lorsque vous utilisez un niveau de retrait de 8, avec une fonction typique imbriquée à 3 niveaux de profondeur, votre code commencera à la colonne 24. Cela me laisse avec seulement 56 caractères pour écrire une ligne de code.

Voici à quoi ressemble un code dans VLC avec indent = 4:

            msg_Dbg( p_libvlc, "Adds %s to the running media player", mrl );
            free( mrl );

            /* send message and get a handle for a reply */
            DBusMessage *reply = dbus_connection_send_with_reply_and_block( conn, msg, -1,
                                                                            &err );
            dbus_message_unref( msg );

Voici à quoi cela ressemble avec indent = 8

                        msg_Dbg( p_libvlc, "Adds %s to the running media player", mrl );
                        free( mrl );


                        /* send message and get a handle for a reply */
                        DBusMessage *reply = dbus_connection_send_with_reply_and_block( conn, msg, -1,
                                                                                        &err );
                        dbus_message_unref( msg );

Bien que les grands retraits facilitent la lecture du code, ils vous donnent également moins de place pour écrire du code imbriqué avant qu'il ne s'enroule.

C'est vraiment important de garder la taille de l'onglet à 8. onglet != tiret. Bien qu'il soit tentant de faire de l'onglet dur en retrait, il a également de très mauvaises conséquences. Beaucoup de gens aiment aussi aligner leur code. Donc, le code comme ci-dessus ressemblera à ceci avec tab = 4:

            msg_Dbg( p_libvlc, "Adds %s to the running media player", mrl );
            free( mrl );


            /* send message and get a handle for a reply */
            DBusMessage *reply = dbus_connection_send_with_reply_and_block( conn, msg, -1,
                                        &err );
            dbus_message_unref( msg );                                                  

Vous verrez que la ligne &err ne s'aligne plus avec conn ci-dessus. La situation s'aggrave encore lorsque plusieurs commentaires sont ajoutés à la fin de chaque ligne.

J'ai toujours utilisé un onglet comme deux espaces.

Dans le passé, j'ai utilisé 3 espaces. Et c'est toujours ma préférence. Mais 4 espaces semble être la norme dans le monde VB. Donc, je suis passé à 4 pour être en ligne avec la plupart des exemples de code que je vois, et avec le reste de mon équipe.

Mort aux infidèles de l'espace!

Puisque vous utilisez Python, vous pouvez, comme dit précédemment, prendre le guide de style de python ( PEP 8 ) Conseil:

Indentation

Use 4 spaces per indentation level.

, Mais le noyau Linux CodingStyle dit diferent:

Les onglets sont de 8 caractères, et donc les indentations sont également 8 caractères. Il y a des mouvements hérétiques qui essaient pour faire des indentations 4 (ou même 2!) des personnages profonds, et qui s'apparente à essayer de définir la valeur de PI à être 3. Justification: l'ensemble de La l'idée derrière l'indentation est de définir clairement où un bloc de contrôle commence et se termine. Surtout quand vous avez regardé votre écran pendant 20 heures consécutives, vous trouverez beaucoup plus facile de voir comment l'indentation fonctionne si vous avez les grandes impressions.

Ce document a aussi quelques exemples de la façon dont le code devrait ressembler, et comment l'identation change cela (c'est en C, Cependant)

L'argument de tabulation sur les espaces est qu'il permet à chaque personne de personnaliser son éditeur pour voir le niveau d'indentation qu'elle veut. L'argument contre les onglets est qu'il est difficile de repérer (pour l'auteur) quand ils ont mélangé des onglets et des espaces. Parfois, vous voudrez des lignes qui ne sont pas en retrait d'un arrêt de tabulation, ce qui provoque des onglets/espaces mixtes.

L'utilisation de 2 espaces présente les avantages suivants: il est possible d'avoir plus de blocs imbriqués (ceci est important si vous avez également une limite de ligne), et que l'utilisation d'un double tiret (soit 4 places) est bien lisible de l'habillage de longues lignes. Un inconvénient est qu'il est parfois difficile de juger si deux lignes sont au même retrait.

L'utilisation de 8 espaces présente les avantages et les inconvénients opposés à 2 espaces. Il est facile de juger le niveau de retrait, mais l'imbrication profonde devient difficile à gérer. Beaucoup de gens jugeraient ce dernier inconvénient comme un avantage (car il rend la nidification profonde moins souhaitable).

4 espaces est quelque part entre ces deux extrêmes.

Mais ma croyance personnelle est que cela ne fait aucune différence quel niveau d'indentation vous utilisez. La chose la plus importante est de choisir une norme et de s'y tenir. Comme d'autres l'ont dit, Suivez PEP8 si vous écrivez python, suivez le guide de style java de Sun si vous écrivez java, et si vous faites du piratage du noyau linux, suivez leur guide de style. Même s'il y avait un petit avantage dans l'utilisation de l'un sur l'autre, c'est un gaspillage d'énergie à débattre de laquelle choisir. Faire un décision, et passer à la partie intéressante de l'ingénierie logicielle.

J'ai lu que 2 espaces est réellement optimal, basé sur une étude où les programmeurs ont été invités à estimer le niveau d'imbrication basé sur l'indentation, mais que lorsqu'on leur a demandé, les programmeurs pensaient que 4 serait optimal. Citation nécessaire, mais ne peut pas le trouver.

Je pense que je me souviens qu'il y a une section sur l'indentation dans Code Complete , citant quelques études sur le niveau d'identation qui rend le code le plus lisible, mais je n'en ai pas une copie avec moi en ce moment, donc je ne peux pas le vérifier.

Je suppose que l'espace de 4 onglets rend le code beaucoup plus lisible... au moins dans la mesure où j'ai travaillé sur mes projets, l'onglet espace de 4 a été l'option la plus confortable....