Il y a eu quelques remarques sur les espaces blancs déjà en discussion sur les placements d'appareils orthopédiques.

J'ai moi-même tendance à saupoudrer mon code de lignes vides pour tenter de séparer les choses qui vont ensemble dans des groupes "logiques" et, espérons-le, faciliter la prochaine personne à lire le code que je viens de produire.

En fait, je dirais que je structure mon code comme j'écris: je fais des paragraphes, pas plus de quelques lignes (certainement plus courtes que 10), et j'essaye de rendre chaque paragraphe autonome.

Par exemple:

• dans une classe, je regrouperai les méthodes qui vont ensemble, tout en les séparant par une ligne vierge du groupe suivant.
• si j'ai besoin d'écrire un commentaire, je mettrai généralement une ligne vide avant le commentaire
• dans une méthode, je fais un paragraphe par étape du processus

Dans l'ensemble, j'ai rarement plus de 4/5 lignes regroupées, ce qui signifie un code très clairsemé.

Je ne considère pas tout cet espace blanc comme un gaspillage parce que je l'utilise en fait pour structurer le code (car j'utilise l'indentation en fait), et donc je pense qu'il vaut la peine d'écran qu'il faut.

Par exemple:

for (int i = 0; i < 10; ++i)
{
    if (i % 3 == 0) continue;

    array[i] += 2;
}

Je considère que les deux déclarations ont des objectifs clairement distincts et méritent donc d'être séparées pour le rendre évident.

Alors, comment utilisez-vous (ou non) les lignes vides dans le code?

Toujours

L'espace est crucial pour nettoyer le code lisible. Une ligne vierge (ou deux) permet de séparer visuellement les blocs logiques de code.

Par exemple, extrait du chapitre Code Complete, deuxième édition de Steve McConnell sur la mise en page et le style:

Les sujets ont obtenu un score de 20 à 30% plus élevé à un test de compréhension lorsque les programmes avaient un schéma d'indentation de deux à quatre espaces que lorsqu'ils n'avaient aucun programme d'indentation.La même étude a révélé qu'il était important de ne pas trop insister ni trop insister sur la structure logique d'un programme. Les scores de compréhension les plus bas ont été obtenus sur des programmes qui n'étaient pas du tout en retrait. Le deuxième plus bas a été atteint sur les programmes utilisant une indentation de six espaces. L'étude a conclu que l'indentation de deux à quatre espaces était optimale. Fait intéressant, de nombreux sujets de l'expérience ont estimé que l'indentation à six espaces était plus facile à utiliser que les indentations plus petites, même si leurs scores étaient inférieurs. C'est probablement parce que l'indentation de six espaces semble agréable. Mais quelle que soit sa beauté, l'indentation à six espaces s'avère moins lisible. Ceci est un exemple de collision entre l'attrait esthétique et la lisibilité.

Oui pour plus de clarté.

Tout comme je l'ai fait dans cette réponse.

Je le fais mais je m'assure de le documenter en mettant

(This line intentionally left blank.)

sur la ligne

Oui, mais je n'en abuse pas.

J'ai vu du code où chaque ligne de code à l'intérieur d'une méthode est séparée par une ligne vierge, et deux lignes vides sont utilisées là où une séparation logique se produit. Cela le rend encore moins lisible à mon avis. J'ai également vu des espaces blancs utilisés pour faire des alignements fous, comme celui-ci:

//Prot.   Return type                    Name                 Arg1        Arg2
//=====   ============================== ==================== =========== ========

private   int                            AMethodWithALongName(string s,   object o)
{
    ...
}

private   IDictionary<MyLongObject, int> SomethingCrazy      (string s)
{
    ...
}

protected void                           Foo                 (string str, object o)
{
    ...
}

La même utilisation abusive des espaces blancs horizontaux peut être appliquée aux espaces blancs verticaux. Comme tout outil, utilisez-le judicieusement.

On me critique beaucoup pour avoir écrit mon code de cette façon. Je ne comprends pas pourquoi quelqu'un ne le ferait pas de cette façon.

La lisibilité est si importante lorsque vous revenez à un projet après une longue période de temps et j'ai entendu un dicton "Toujours écrire du code si le prochain gars qui le lit est un psychopathe qui connaît votre emplacement".

Je n'écris pas toujours des logiciels, mais quand je le fais, j'utilise des lignes vides pour plus de clarté.

Je suis tout pour rendre le code aussi clair que possible, et les espaces blancs sont souvent un outil utile dans cette entreprise. Mais n'oublions pas le refactoring:

• dans une classe, je regrouperai les méthodes qui vont ensemble, tout en les séparant par une ligne vierge du groupe suivant.

Puisque vous avez plusieurs membres liés, ils sont candidats à une nouvelle classe.

• si j'ai besoin d'écrire un commentaire, je mettrai généralement une ligne vide avant le commentaire

Chaque fois que le code n'est pas assez clair pour vouloir un commentaire, je demande si je peux refactoriser le code suffisamment clairement pour ne pas avoir besoin du commentaire.

• dans une méthode, je fais un paragraphe par étape du processus

Pourquoi ne pas faire une méthode pour chaque "paragraphe"?

Si vous vous retrouvez avec un tas de méthodes dans votre classe, consultez ma note ci-dessus sur l'extraction d'une nouvelle classe.

Oui. Il facilite l'analyse visuelle d'un fichier. Entre autres choses, il est plus clair avec quelle ligne un commentaire va.

Some code here
// Which line does this comment go with?
More code here

// It's pretty clear which line this comment goes with
More code here

Still more code here

J'utilise des lignes vides avec parcimonie et de manière cohérente, et est toujours plus important que avec parcimonie. Toutefois:

• Si chaque ligne de code est séparée de la suivante par une ligne vierge, il y a trop de lignes vides.
• S'il n'y a ni rime ni raison facilement discernable pour l'endroit où les lignes vides sont placées, alors elles sont une distraction et il y en a généralement trop.
• Si une fonction est si grande qu'elle nécessite de nombreuses lignes vides, elle est trop grande.
• Si un bloc de code a besoin de plus d'une ligne vierge avant ou après, il y a quelque chose de vraiment erroné.
• Si vous avez plus de deux lignes vides entre les fonctions, vous avez probablement trop de lignes vides.

La plupart de cela n'est pas terriblement controversé; ce qui suit pourrait être. Je note que la notation K&R avec les accolades ouvertes à la fin de la ligne est souvent déprimante, suivie d'une ligne vierge. Personnellement, je n'aime pas les accolades à la fin de la ligne et le mélanger avec une ligne vierge après l'accolade fait un non-sens de la notation (IMNSHO). Mettez l'accolade ouverte sur la ligne suivante, seule, et vous avez une ligne principalement vide (et, IMNSHO, un code plus lisible). Si vous devez utiliser un croisillon K&R à la fin de la ligne, ne gaspillez pas l'espace vertical avec des lignes vierges superflues.

// I don't like this
if (something == anotherthing) {
    print ...
    update ...
}

// I much prefer this
if (something == anotherthing)
{
    print ...
    update ...
}

// I loathe this - not least for its inconsistent spacing
if (something == anotherthing) {

    print ...
    update ...
}

// I loathe this too, for its absurd waste of vertical space
if (something == anotherthing) {

    print ...
    update ...

}

Écrivez ce qui est le plus lisible et le moins surprenant.

function validEmail($addr) {
    $regex = "/.../";   
    return preg_match($regex, $addr);
}

Cette fonction n'a pas besoin de 12 lignes de commentaires doc.

En fait, il n'a pas besoin de commentaires.

Ou des lignes vides.

Ils porteraient atteinte à son essence.

À l'intérieur de la fonction? Rarement

Si j'ai un bloc clairement différent, c'est une refactorisation vers une nouvelle fonction. Si peu de cas n'en valent pas la peine.

Pour moi, les lignes blanches à l'intérieur de la fonction sont l'une des "meilleures pratiques" les plus erronées.

Souvent

Utilisez-le pour les blocs logiques de code qui sont traités de manière similaire. Une fois que vous avez ajouté un commentaire pour montrer que vous effectuez une étape différente - il est temps d'extraire la méthode.

Bon espace blanc

{
    int x = computeX();
    x += ADJUSTMENT_FACTOR_X;

    int y = computeY();
    y += ADJUSTMENT_FACTORY_Y;

    setPosition(x, y);
}

Bad Whitespace

{
    //Open a connection
    String serverAddress = lookupAddress();
    Connection connection = openConnection(serverAddress);
    connection.login(user, password);


    //Go get stuff from the server
    item1 = connection.get(1);
    item2 = connection.get(2);

    //Close connection
    connection.close();

    //log data
    log(item1);
    log(item2);

    //Update client
    gui.updateView(item1, item2);        
}    

contre

{
    Connection connection = openConnection();
    updateData(connection);
    closeConnection(connection);
    logUpdate();
    updateGui();
}

contre

{
     updateDataFromServer();
     logUpdate();
     updateGui();
}

Non seulement j'utilise des espaces, j'utilise des accolades pour plus de clarté.

Les accolades que j'utilise pour dire qu'elles peuvent potentiellement être des fonctions.

code
{
    code
    code
    code
    code
}
{
    code
    code=code
    code
    code

    code()
    code()
}

À un moment donné, je saupoudrais généreusement de lignes vides tout au long de mon code. De nos jours, j'ai tendance à être plus économe. Je pense que cela fait partie de ce dont parlait Steve Yegge ici :

J'espère que la scène que j'ai peinte jusqu'à présent vous aide à comprendre pourquoi parfois vous regardez du code et vous le détestez immédiatement. Si vous êtes un n00b, vous regarderez du code expérimenté et direz que c'est de la merde impénétrable et indisciplinée écrite par quelqu'un qui n'a jamais appris l'essentiel de l'ingénierie logicielle moderne. Si vous êtes un vétéran, vous regarderez le code n00b et direz qu'il s'agit de peluches ornementales sur-commentées qu'un stagiaire aurait pu écrire en une seule nuit de forte consommation d'alcool.

Le point d'adhérence est la tolérance à la compression. Au fur et à mesure que vous écrivez du code tout au long de votre carrière, en particulier s'il s'agit de code couvrant des langues et des domaines problématiques très différents, votre tolérance à la compression de code augmente. Ce n'est pas différent de la progression de la lecture de livres pour enfants avec du texte géant à des romans de plus en plus complexes avec du texte plus petit et des mots plus gros.

...

Un programmeur avec une tolérance élevée à la compression est en fait gêné par une série de contes. Pourquoi? Parce que pour comprendre une base de code, vous devez être capable d'en emballer autant que possible dans votre tête. Si c'est un algorithme compliqué, un programmeur chevronné veut voir le tout à l'écran, ce qui signifie réduire le nombre de lignes vides et de commentaires en ligne - en particulier les commentaires qui réitèrent simplement ce que fait le code. C'est exactement le contraire de ce que veut un programmeur n00b. Les n00bs veulent se concentrer sur une déclaration ou une expression à la fois, en déplaçant tout le code autour de lui afin qu'ils puissent se concentrer, et crier à haute voix.

Je suis fondamentalement d'accord avec lui. Il est préférable de compresser le code afin d'en obtenir autant que possible sur un seul écran plutôt que de trop l'espacer. Cela ne veut pas dire que vous ne devez jamais utiliser de lignes vides. C'est juste que je pense que si le regroupement que vous essayez de créer n'augmente pas énormément la lisibilité, il fait plus de mal que de bien.

Un professeur émérite a donné deux excellents conseils

1. L'espace est gratuit
2. N'utilisez pas les agrafes qui remontent par le devant du papier, sinon je vous ferai défaut.

Mes règles de base sont les suivantes:

1. Si j'ai du mal à lire le code que j'ai écrit hier, j'ai probablement besoin d'extraire une méthode ou trois.

2. Si ma définition de classe est trop longue pour être lue facilement, j'ai probablement besoin d'extraire un module / interface / objet.

3. Définitions de méthodes: ajouter une ligne

4. Définitions de module / classe: ajoutez deux lignes

J'aime penser aux espaces blancs de la même manière que les paragraphes. Vous regroupez des lignes qui contribuent à une idée.

Si vous commencez une nouvelle idée ou une nouvelle facette de la même idée, vous commencez un nouveau paragraphe - comme celui-ci.

Dans le code impératif, je regroupe les tâches qui effectuent une tâche cohérente; en code déclaratif, je regroupe le code qui décrit une déclaration cohérente d'une idée.

Vous n'avez clairement aucun problème à le faire en anglais (certaines personnes sont horribles avec le paragraphe), donc avec un peu de pratique, appliquer la même compétence au code ne devrait pas être du tout extensible.

Les lignes vides sont un must à mon avis. Je les utilise pour séparer différents blocs logiques de code. Rend le code lisible. Le code lisible est un bon code;)

Mon morceau de code idéal serait que chaque bloc logique soit séparé par une ligne vierge et un commentaire au-dessus de chaque bloc qui a une logique principale.

Bien sûr, si les gens le font en ajoutant plusieurs lignes vides partout, je trouve cela très irritant :(

J'utilise uniquement des espaces dans une fonction / méthode pour séparer les déclarations et le code.

Si vous ressentez le besoin d'avoir des lignes pour séparer les sous-blocs de code implémentant une logique, alors elles devraient l'être mais dans une autre fonction / méthode privée. C'est à votre compilateur de ne pas faire trop de surcharge.

typiquement, en peusdo-code:

def function(arg1, argn, ...)
    INITIALIZERS

    CODE
    BLOCK_START
        INITIALIZERS

        CODE
    BLOCK_END
    CODE
end

Si je vois des espaces inutiles, je grimpe habituellement.

L'espace blanc est extrêmement précieux.

Voici l'affaire ... les nerds qui écrivent du code compliqué comme E = MC ² sont excellents pour montrer leurs compétences en programmation.

Maintenant, allons de l'avant six mois, et il est 2 h du matin et le système qui n'a pas été examiné depuis six mois est tombé en panne sur la ligne E = MC ² . C'est presque impossible à déboguer ... tout le monde panique.

Supposons que le code ressemble plus à ceci ...

See Dick
See Jane
See Dick and Jan

S'il est 2h00 et que le code est cassé. Un rapide coup d'œil vous montrera que la ligne 3 aurait dû être

See Dick and Jane

Problème résolu.

Conclusion ... utilisez des espaces.

Comme beaucoup d'autres l'ont indiqué, les lignes vides facilitent la lecture du code. Cependant, certaines langues appliquent cette norme. Un que je peux penser du haut de ma tête (pas tellement sur les lignes vides mais l'indentation appropriée) est Python.

Je suis d'accord, j'utilise les espaces blancs de la même manière. Cependant, si je me retrouve à utiliser des espaces pour diviser une méthode en trop de parties, c'est un signe que je pourrais avoir besoin de refactoriser ce code en plusieurs méthodes. Trop de sections logiques dans une méthode peuvent signaler que la méthode sera plus difficile à tester.

Je les utilise pour séparer le code en unités logiques. J'ai vu très peu d'exemples de code qui n'utilisaient pas de lignes vierges, bien sûr l'obfuscation est exceptée.

La réponse du psychopathe est la meilleure, mais je remplacerais cela en supposant que la prochaine personne est un idiot, et qu'elle supposera que vous l'êtes, et vous voudrez lui prouver le contraire.

L'utilisation de commentaires est tout aussi importante pour la lisibilité. J'ouvre chaque fonction ou sous-programme avec un bloc de commentaires, expliquant en texte clair, ce qu'il est, ce qu'il fait, quels sont les arguments et quels sont les résultats attendus (y compris une liste de conditions d'erreur). Ensuite, il n'est pas question de ce qu'il est prévu et / ou conçu pour faire. Ce qu'elle peut faire peut varier, mais c'est plus loin sur la voie.

Je pense que beaucoup trop de codeurs supposent que ce seront eux, eux-mêmes, qui feront des "réparations" sur le code, ou ne s'en soucient tout simplement pas.

Les lignes vides sont importantes. Cependant, le fait de gaspiller une ligne vierge entière sur l'accolade ouvrante réduit la quantité de code que vous pouvez voir dans un écran. Devrait être:

for (int i; i < 10; ++i)
{  if (i % 3 == 0) continue;

   array[i] += 2;
}

(Ne me faites pas commencer à mettre l'accolade '{' sur la même ligne que le 'pour' ... c'est meshuggah).

Oui. Pour plus de lisibilité. Parfois, je mets même des lignes vides dans du code que je n'ai pas écrit. Je trouve plus facile de comprendre le code lorsqu'ils ont un regroupement logique via des lignes vides - comme vous pouvez le "lire rapidement" à travers.

Nous devons utiliser des lignes vides entre les blocs de code comme nous le faisons lorsque nous écrivons une lettre.

Par exemple, entre les fonctions, ou à l'intérieur d'une fonction lorsque nous terminons une boucle ...

Les gens vous remercieront d'un code propre s'ils doivent en faire la maintenance;)

Nous utilisons l'espace blanc recommandé par Microsoft StyleCop. En plus de la lisibilité et de la cohérence, j'ai trouvé que (avec des classes de petite taille) un code correctement disposé facilite beaucoup la gestion des fusions lorsque différentes personnes dans une équipe travaillent sur les mêmes domaines.

Je ne sais pas si c'est juste mon imagination, mais les différents outils semblent faire un meilleur travail pour reconnaître où le code équivalent commence et se termine lors de la fusion quand il est bien organisé. Un code bien présenté est une joie de fusionner. D'accord, c'était un mensonge - mais au moins la douleur est maintenue à des niveaux gérables.

Jamais une ligne vierge, pas dans tout le fichier. Cela ne veut pas dire qu'il n'y a pas de rupture dans le code:

 code;
 //
 morecode;

Les lignes vides servent à ouvrir des sections du code, vous avez quelques raccourcis clavier dans votre éditeur pour vous amener à la ligne vide précédente / suivante.