Préférez-vous la concision ou la lisibilité de votre code? [fermé]

Les raccourcis linguistiques peuvent souvent être utilisés pour rendre le code plus concis.

Par exemple, les opérateurs de coalescence ternaire et nulle peuvent réduire la quantité de code, mais sans doute au détriment de la lisibilité:

En C #:

Person newGuy = new Person();
if (boss == null) {
    newGuy.Boss = GetDefaultBoss();
} else {
    newGuy.Boss = boss;
}

est fonctionnellement équivalent à:

Person newGuy = new Person();
newGuy.Boss = boss ?? GetDefaultBoss();

mais évidemment beaucoup plus verbeux.

Où tracez-vous la ligne quand il s'agit de concision vs lisibilité?

Tous les deux.

Votre premier exemple est certainement plus verbeux et sans doute plus explicite ... mais il m'oblige également à scanner cinq lignes au lieu d'une. Pire encore, il sous-estime son objectif - attribuer une valeur à newGuy.Boss.

Votre deuxième exemple peut me coûter une seconde si je ne suis pas familier avec l'opérateur de coalescence nulle, mais il ne fait aucun doute quant à son objectif, et si je scanne une routine plus large à la recherche de la source d'une valeur, il être beaucoup plus facile pour moi de choisir celui-ci.

Maintenant, contrastez ceci:

if (boss == null) {
    newGuy.Boss = GetDefaultBoss();
    newGuy.IsTemp = true;
    newGuy.AddTask("orientation");
} else {
    newGuy.Boss = boss;
    newGuy.IsTemp = false;
}

...avec:

newGuy.Boss = boss ?? GetDefaultBoss();
newGuy.IsTemp = boss == null;
if ( boss == null ) newGuy.AddTask("orientation");

Le dernier exemple est encore beaucoup plus court, mais maintenant il obscurcit son objectif en faisant apparaître les tâches déclenchées par le même test comme distinctes. Ici, je pense que la verbosité de l'ancien est justifiée.

Bien que les deux soient de bons objectifs, je serai toujours du côté de la lisibilité lorsque je serai obligé d'en choisir un.

Je dirais que votre exemple améliore à la fois la lisibilité et la brièveté. Considérez cependant:

if( a > b )
{
    foo = bar
}
else
{
    if( c.isThing() ){
        foo = somethingElse;
    }
    else{
        foo = someFurtherThing.GetFoo();
    }
}

par opposition à

foo = a > b ? bar ?? whatever.something : c.isThing() ? somethingElse : someFurtherThing.GetFoo();

Ce dernier est concis, mais difficile à lire. Le premier est verbeux, mais le flux de la logique est clair.

En fin de compte, la brièveté ne sert pas à grand chose, à part la possibilité d'afficher plus sur l'écran. La lisibilité facilite le débogage et devrait donc être généralement préférée.

Je dirais qu'en règle générale, ne sacrifiez jamais la lisibilité à cause de la concision, mais ne jugez jamais la lisibilité en fonction du manque de connaissances d'un autre programmeur à ce sujet.

La concision et la lisibilité ne sont pas opposées. Comme cette réponse, parfois plus courte est plus lisible.

Je dirais que je préfère la lisibilité, même si cela signifie parfois utiliser un code concis. (C'est-à-dire ternaire pour les conditions relativement simples à l'intérieur d'un bloc conditionnel plus grand.)

Fondamentalement, s'il est inutilement difficile à comprendre, ne le faites pas.

La lisibilité vient en premier où elle entre en conflit avec la concision, car le code est modifié plus souvent qu'il n'est initialement écrit. D'autre part:

1. Le bruit syntaxique et le code passe-partout obscurcissent souvent les intentions et nuisent ainsi à la lisibilité. Parfois, le code plus concis est également plus lisible. Par exemple, pensez aux fonctions lambda ou aux fonctions délégués / de première classe par rapport aux classes à méthode unique qui implémentent une interface à méthode unique.

2. La lisibilité doit être évaluée en fonction de la facilité de lecture du code pour un programmeur raisonnablement expérimenté qui connaît assez bien le langage et ses caractéristiques uniques / avancées, pas un singe de code à peine compétent qui ne connaît que le plus petit dénominateur commun.

Un aspect qui, je pense, n'a pas encore été mentionné: quels sont vos objectifs?

Si vous ne vous souciez que de la sécurité de l'emploi, optez pour la concision et la compacité par rapport à tout le reste. Évitez également de commenter votre code.

Si vous voulez pouvoir facilement transmettre votre code à quelqu'un d'autre pendant que vous travaillez sur un nouveau projet sympa, optez pour la lisibilité, la clarté et de nombreux commentaires solides.

_{^{Remarque: ce qui précède ne vous concerne pas personnellement, @Damovisa; c'est pour quiconque choisit entre les deux positions.}}

Il y a une chose que la version détaillée a comme avantage.

Il a plus de lignes et la plupart des débogueurs sont orientés ligne ! Il est très difficile de définir un point d'arrêt au milieu d'une expression, mais il est généralement très simple de le placer dans une instruction de bloc.

En d'autres termes, lequel voudriez-vous voir dans votre éditeur si vous voulez que votre débogueur démarre quand boss == null?

(Cela dit, j'aime l'opérateur ?? -)

La lisibilité doit venir en premier, à long terme, la plupart des gens passent le plus de temps à modifier ou étendre le code existant - la lisibilité est une grande partie de la maintenabilité.

Cela dit, la concision est quelque chose qui peut contribuer à la lisibilité. Par exemple, dans votre question, le deuxième extrait est à la fois plus lisible et plus concis.