web-dev-qa-db-fra.com

Ergonomie du code informatique

Plus tôt, j'ai posé une question similaire à StackOverflow et j'ai été impitoyablement rétrogradé. Pourtant, je pense qu'il est absolument viable et utile. Du moins pour moi en tant que développeur de logiciels.

Il y a beaucoup de discussions sur la guerre sainte concernant le style de code, la lisibilité, etc.
Pourtant, le seul livre qui fait référence à une véritable recherche ergonomique que j'ai lu jusqu'à présent est Human Factors (6 volumes en traduction russe) de Salvendy. C'est trop peu. Je doute que la persuasion doive être basée sur une perception subjective de la lisibilité.

Considérez ces morceaux de code:

if (bla-bla) return;

if (very-long-bla-bla-bla) return;

if (bla-bla) 
    return;

if (bla-bla)
{
    return;
}

if (bla-bla){
    return;
}

Sémantiquement équivalent mais du point de vue de la lisibilité est assez différent.
. Et cela arrive vraiment de temps en temps lorsque je lis le code d'autres développeurs.
Eh bien, la recherche indique que le balayage vertical est plus performant que horizontal lorsque la largeur n'est pas trop petite. Mais comment comparer le retrait retour et retour entouré d'accolades?

Une autre préoccupation est la mémoire à court terme et une partie visible de la routine. Si le code introduit beaucoup de "choses" (rappelez-vous ces 7 + -2), je préfère les voir toutes en même temps sans faire défiler d'avant en arrière afin de me rappeler à quoi sert quelque chose.
Par conséquent, il est raisonnable de se demander si l'orientation de l'affichage portrait est meilleure que paysage?

Chaque langage de programmation a ses idiomes et ses conventions de formatage de code mais je n'ai jamais vu la justification pour adopter et préférer l'un à l'autre.
J'apprécie que quelqu'un partage ses connaissances et fournisse des liens utiles vers les résultats de la recherche scientifique sur ce sujet. Merci.

p.s. Je suis sûr qu'il est légal de traiter les développeurs lisant mon code comme des utilisateurs et le résultat de ce processus comme leur expérience. ;)

Mise à jour:

Je ne suis pas d'accord avec les commentaires indiquant que cette question concerne uniquement la lisibilité. Absolument pas.
Je peux continuer avec des exemples de conception de langage:
Les fameux opérateurs '==' et '=' C/C++ et le style spécial if (value == variable) pour vérifier l'eualité par rapport aux valeurs constantes. Laissant toujours place aux erreurs lors de la comparaison des variables.
Il s'agit de la facilité avec laquelle une faute de frappe peut provoquer des erreurs difficiles à repérer.

Un autre exemple est la conception d'API en général.
En C # List<T> Ne pouvait contenir qu'une seule méthode Add surchargée acceptant T ou IEnumerable<T>, Alors le code suivant serait possible:

foreach (var item in items)
{
    list.Add(items); // may be item?!
}

mais List<T> a Add() et AddRange().

Nous utilisons beaucoup l'aide de la saisie semi-automatique - parfois cela nous induit en erreur et parfois l'erreur est également ignorée par le développeur et le compilateur.

Langages dynamiques.
Chaque fois que vous utilisez dynamic en C #, vous devez oublier IntelliSense, cela ne fonctionne tout simplement pas. Cela pourrait probablement être utile avec une analyse puissante, mais ce n'est pas le cas.
Le langage dynamique demande-t-il donc une charge de mémoire plus élevée?

Une autre question est de savoir si le langage de programmation et la langue/culture naturelle native interfèrent les uns avec les autres. En commençant par la direction d'écriture de lecture et en terminant par la perception sémantique.
Dans les livres russes, "Stream" et "Thread" sont souvent traduits par le même mot: " поток". Dans certaines publications, 'I/O' ( ввода/вывода) a été ajouté au 'Stream' pour distinguer de 'Thread'. Je ne sais pas si cela influence la compréhension mais je soupçonne que c'est au moins au stade de l'apprentissage.

Mise à jour 2

Ces vidéos répondent partiellement à ma question:

http://vimeo.com/97329157

http://vimeo.com/97471514

ergonomicscode
5
Pavel Voronin

La convention (quel que soit le contexte dans lequel vous travaillez) l'emporte sur tout. Tout ce que votre groupe de travail a décidé doit être observé. Si vous êtes en train de déterminer les conventions de codage, il existe de nombreux conseils anecdotiques et spécifiques à la langue disponibles sur Internet.

Je ne connais aucune étude suggérant qu'un style de codage spécifique soit plus facile à lire que d'autres, mais comme mentionné, il existe de nombreuses preuves/opinions anecdotiques sur le sujet, et il est généralement spécifique au langage.

Par exemple, Javascript ressemble un peu à C/Java mais a une sémantique que les programmeurs C/Java ne s'attendraient pas:

return {
    x : "x"
};
// in not semantically the same as
return
{
    x : "x"
};
// search for "semicolon insertion gotchas" for explanation

Je soupçonne que dans ce domaine de détermination de la meilleure convention de codage, l'expérience des experts tendrait à fournir des informations plus utiles que les études empiriques. Exactement pourquoi je ressens cela, je ne peux pas dire - c'est vraiment juste une supposition. Il y a peut-être trop de variables à contrôler pour une étude.

J'ai donné à cette question un +1 parce que (même si la question est vague) la syntaxe du langage de programmation (et la sémantique bien sûr) est un problème UX, et souvent ignoré. Trop de langages informatiques utilisent une syntaxe vieille de 40 ans. L'UX de la programmation est trop refoulée. Pas toujours réprimé (par exemple Python), mais l'inertie (en particulier les langages Web) semble aller dans le mauvais sens.

4
obelia

Ma réponse ne sera pas complète - des morceaux vraiment, je veux juste faire allusion à deux aspects qui, selon moi, valent la peine d'être négligés.

(Comme je l'ai noté dans les commentaires, j'ai déjà partagé quelques réflexions sur le sujet - ici ).

Lorsque je numérise du code, je regarde généralement le côté gauche de l'écran et je m'attends à ce que des instructions de flux de contrôle y apparaissent, il est donc possible de manquer "retour" dans les deux premiers exemples. Et cela arrive vraiment de temps en temps lorsque je lis le code d'autres développeurs. Eh bien, la recherche indique que le balayage vertical est plus performant que horizontal lorsque la largeur n'est pas trop petite. Mais comment comparer le retour en retrait et le retour entouré d'accolades?

L'entourer d'accolades est une habitude qui aide à vous protéger contre l'introduction d'un bug.

Disons que vous devez appeler stream.Close(); avant de quitter la méthode. Voici notre code:

if (bla-bla) 
    return;

D'accord, insérons stream.Close:

if (bla-bla) 
    stream.Close();
    return;

Et oups, je l'ai juste cassé. Appeler uniquement stream.Close dépend maintenant de la véracité du bla-bla. return n'est plus conditionnel, nous allons donc sortir de la méthode dans tous les cas et le code ci-dessous ne s'exécutera jamais.

Si notre code ressemblait à ceci:

if (bla-bla)
{
    return;
}

Ça ne pouvait pas arriver.

Je pense que cela attire l'attention sur un point important. Dans le cas du code, qui a tendance à être beaucoup édité, il ne s'agit pas seulement de lisibilité "statique".

Il s'agit également de s'assurer que cette lisibilité est persistante et moins susceptible d'être affectée par de futurs changements, de refactoriser etc.

Une autre préoccupation est la mémoire à court terme et une partie visible de la routine. Si le code introduit beaucoup de "choses" (rappelez-vous ces 7 + -2), je préfère les voir toutes en même temps sans faire défiler d'avant en arrière afin de me rappeler à quoi sert quelque chose. Par conséquent, est-il raisonnable de demander si l'orientation de l'affichage portrait est meilleure que paysage?

Cela me fait penser à un autre aspect important: le contrôle de source.

Les programmeurs ne lisent pas seulement le code dans les éditeurs de code/IDE. Travailler avec le contrôle de source est essentiel. Plus les lignes de code sont longues, plus il est difficile de suivre les modifications, de comparer le code, de fusionner automatiquement les modifications.

Si votre code ressemble à ceci:

if (header instanceof TextView) ((TextView) header).setText(data.getTitle());

Ce n'est qu'une seule ligne, d'accord. Vous avez économisé de l'espace vertical. Mais maintenant, la probabilité que deux programmeurs changent la même ligne (l'un renommé header en mainHeader, un autre a dû changer getTitle en getDescription) a augmenté, et le contrôle des sources ne pourra pas dire comment combiner ces modifications automatiquement, et le développeur - qui peut être une tierce personne - doit résoudre le conflit manuellement.

Si le même code était disposé sur plusieurs lignes comme suit:

if (header instanceof TextView) {
    String title = data.getTitle();
    ((TextView) header).setText(title);
}

Cela n'aurait pas été un problème. Un développeur a modifié les lignes 1 et 3, l'autre - uniquement la ligne 2.

C'est donc un autre aspect important: lisibilité dans le VCS/diff. Il est beaucoup plus difficile de lutter avec du code désordonné lors de la résolution de conflits: il peut y avoir des dizaines de de tels cas à la fois (et vous ne pouvez pas continuer jusqu'à ce que vous les résolviez tous), chacun dans un fichier différent afin que vous ne connaissiez pas le contexte, etc.

Ensuite, il y a aussi la lisibilité lors du débogage - par exemple. si quatre appels de méthode sont écrasés sur une seule ligne, il est moins pratique pour moi de le déboguer étape par étape ...

Donc, pour résumer, il existe différents contextes dans lesquels on aborde le code, et c'est quelque chose dont il faut être conscient lorsqu'on essaie d'évaluer sa lisibilité.

2
Konrad Morawski

Je ne peux pas répondre à toute utilité dans le sens du code, mais il peut sûrement y avoir des méthodes pour améliorer le code pour la perception. Vous devez simplement considérer le code comme un produit écrit, lu par un utilisateur humain (c'est-à-dire un autre programmeur ou quelqu'un d'autre), alors, entre autres, répondez-vous à ces questions:

  1. Qui est le lecteur de code? Est-ce toi, l'auteur? Programmeur amateur ou expert?
  2. Comment pouvez-vous aider le lecteur à mieux comprendre le code, ses objectifs, les tâches qu'il résout et les astuces qu'il utilise?
  3. Y a-t-il une sorte de mention dans la réponse ci-dessus des conventions, qui sont probablement bien connues des autres utilisateurs et prennent en charge certaines normes - dans les noms de variables, le formatage du code, etc.?
  4. Intégrez-vous dans votre code une descente en douceur de la description commune, à vol d'oiseau, de la structure et de l'organisation du code aux explications de points locaux concrets (par exemple, dans des commentaires ou dans des descriptions générales)?

Répondre à ces questions est bon de ressentir et de comprendre le code comme produit utilisé, donc vous trouverez certainement de meilleures solutions dans les commentaires, l'organisation, la lisibilité et ainsi de suite pour le rendre plus utilisable.

1
Alex Ovtcharenko