Devrions-nous chercher du code mensonger?

9

Cela fait référence à une discussion dans une réponse et aux commentaires de cette question: Quelle est l'aversion pour la documentation dans l'industrie? . La réponse affirmait que «le code ne peut pas mentir» et devrait donc être l'emplacement de référence au lieu de la documentation. Plusieurs commentaires ont souligné que "le code peut mentir". Il y a de la vérité des deux côtés, au moins en partie à cause de la mauvaise et inappropriée gestion de la documentation.

Devrions-nous être à l'affût de codes mensongers, en les comparant à toute documentation existante? Ou est-ce généralement la meilleure source pour ce qu'elle doit faire? S'il s'agit d'un code agile, est-il moins susceptible de mentir, ou ce code ne peut-il pas mentir du tout?

documentation

— thursdaysgeek
source

1

Pourriez-vous clarifier ce que vous entendez par «mensonge»? Nous ne devrions pas avoir à nous référer aux commentaires dans une autre question pour obtenir votre contexte.

— user16764

@ user16764 Sans regarder l'autre fil, la première chose à

— retenir

Si la documentation indique que le code doit faire foo, et que le code barre, cela signifie-t-il que la barre est ce que le code devrait faire? Ou supposons-nous que la barre est la bonne action parce que nous n'avons jamais lu la documentation, parce que le code est toujours correct?

— jeudijeudi

Si le code a été accepté comme barre, la documentation est incorrecte et obsolète. Mais si foo et bar sont étroitement liés et que les utilisateurs n'ont pas remarqué que cela ne résout pas tout à fait leurs problèmes comme ils s'y attendaient, alors peut-être que la documentation sur foo n'est pas fausse? En d'autres termes, le code est-il vraiment la clé de voûte de ce que le code devrait faire?

— thursdaysgeek

9

Dans les mots du profane:

Oui , vous devez rechercher le code de mensonge et lui faire dire la vérité. Mais pas en le comparant à la documentation. Ce serait une méthode pour détecter la documentation qui ment.

Il y a plusieurs façons dont le code peut mentir, dont je ne mentionnerai que quelques-unes:

Des blocs de code qui ne sont jamais exécutés car des conditions ne sont jamais remplies. Le code vous ment sur ce qu'il fait.
Le code qui ajoute une complexité inutile réside dans la complexité du problème.
Le code sans convention de dénomination ment parce qu'il vous induit en erreur en pensant qu'il fait quelque chose de différent de ce qu'il fait réellement.

Plus il est court, moins il se trouve. C'est évident.

Moins le code est compliqué, plus il est transparent. Donc ça ment moins.

Les astuces de syntaxe arcanique mentent beaucoup. Préférez des algorithmes clairs et pas à pas. Ils mentent moins.

Un bon outil d'analyse de code statique peut vous aider à trouver le code qui se trouve.

Une bonne batterie de tests automatisés oblige également le code à dire la vérité.

— Tulains Córdova
source

4

The shorter and terser the code is, the less it lies. It's self evident. Je dirais à peine cela. D'après mon expérience, plus le code est court et concis, plus il a de possibilités de balayer sous le tapis, généralement en les cachant dans des appels de fonction trompeurs.

— Mason Wheeler

@MasonWheeler Vous avez raison. J'ai édité la partie "laconique".

— Tulains Córdova

Je ne suis pas convaincu par "Code sans convention de dénomination". C'est certainement mauvais, mais comment peut-il mentir s'il ne vous dit rien? "Je ne te dis pas!" est obstinément obstructive et non informative mais pas trompeuse. Le «mensonge» est sûrement lorsqu'une convention de dénomination existe, mais est utilisée d'une manière qui ne correspond pas à ce que le code fait réellement - par exemple si vous utilisez le hongrois (beurk!) Mais que vous avez parfois le préfixe pd'une variable qui n'est pas un pointeur.

— Steve314

2

En fait, ce que vous proposez pourrait être mieux décrit comme une «sophistique» que simplement comme un «mensonge». La sophistique a tendance à être verbeuse et compliquée précisément de sorte qu'il est difficile de voir les défauts logiques, et est superficiellement intelligente et confiante afin que les gens aient peur de la remettre en question au cas où ils auraient l'air stupides.

— Steve314

Autre exemple: code qui modifie le langage sous-jacent ou les propriétés d'exécution, par exemple en redéfinissant ou en masquant le comportement primitif.

— JustinC

6

Le code ne peut pas mentir.

Le contenu du code correspond à ce que fait actuellement votre programme, quelle que soit la documentation, le contrôle qualité ou le client. Surtout si votre code a été publié et est sur le terrain depuis un certain temps, ce comportement attendu ne doit pas être ignoré.

Le code peut certainement être incorrect . Il peut certainement être trompeur dans sa dénomination ou son organisation. Cela peut certainement être illisible.

Mais si vous voulez que la source de vérité pour ce que votre code est en train de faire , pas ce qu'il est censé faire, pas ce qu'il a été conçu pour faire, pas ce que vous pensiez qu'il était en train de faire ... si vous avez besoin de savoir ce qu'il fait réellement, allez au code.

— Telastyn
source

Il y a une école de pensée selon laquelle si vous êtes délibérément trompeur mais correct sur le plan pédant, alors vous ne mentez pas. Ce n'est pas la seule école de pensée. Par exemple, j'ai une ancienne édition de Detecting Lies and Deceit par Aldert Vrij . L'une des premières choses que cela fait est de considérer diverses définitions du mensonge et de la tromperie, en choisissant d'inclure des déclarations pédantiquement correctes mais délibérément trompeuses, en partie parce que c'est une compréhension commune de toute façon.

— Steve314

Désolé, mais dire "mais c'était pédantiquement correct" ne signifie pas que vous ne pouvez pas être traité de menteur - même si les gens ne se disputent pas, ils le savent toujours.

— Steve314

@ steve314 - pssh. La question initiale portait sur les commentaires. Construire un homme de paille pour ces rares scénarios où le code est nommé de manière trompeuse afin d'argumenter en faveur des commentaires (et ignorer le scénario très courant de commentaires obsolètes) est absurde.

— Telastyn

1

Je suis d'accord avec cela - je ne conteste pas l'argument que vous faites, seulement la définition apparente du "mensonge" que vous utilisez en le faisant. Le code peut mentir - non pas au compilateur, mais certainement aux lecteurs humains. C'est même un objectif intentionnel dans certains cas - des choses comme le concours C obscurci serait un exemple relativement bénin. Sophistication, comme je le suggère dans mon commentaire à user61852. Ce n'est pas parce qu'un compilateur voit à travers le mensonge que ce n'est pas un mensonge.

— Steve314

@Telastyn Je suppose que vous n'avez jamais eu de filtre pour effectuer une redirection provoquant une étape sur l'espace blanc, puis entrer dans du code non appelé à partir de cette méthode, pour ne jamais revenir, n'est-ce pas? Dieu, je déteste le! @ # $ Les développeurs Java font avec Java.

— Erik Reppen

0

Vous posez plusieurs questions.

Faut-il être à l'affût du code mensonger?

Bien sûr!

Devrions-nous comparer le [code] à toute documentation existante?

Cela ne pourrait jamais faire de mal, mais comme mentionné dans d'autres réponses, le plus souvent, cela vous amènera à trouver des problèmes dans la documentation , pas dans le code .

Ou est-ce que [code] est généralement la meilleure source pour ce qu'il doit faire?

Il est toujours la meilleure source pour ce qu'elle est en train de faire. La meilleure source pour ce que le code devrait faire peut être (une combinaison de) différentes choses, les principales étant:

Le code lui-même;
Le code appelant;
Commentaires dans ce code;
Documentation;
Tests unitaires;
Tests d'intégration et de régression;
Le programmeur;
L'utilisateur final;

La «meilleure» source (ou une combinaison de ces sources) dépend de votre situation.

S'il s'agit d'un code agile, est-il moins susceptible de mentir, ou ce code ne peut-il pas mentir du tout?

Je ne sais pas ce que vous entendez par "code agile", AFAIK "agile" se réfère généralement au processus de codage. Supposons que vous vouliez dire «code créé dans un processus de programmation agile», alors je pense qu'il est sûr de dire qu'il peut toujours mentir. La probabilité de mentir par rapport au code créé par exemple dans des projets de style cascade est une question subjective (personnellement, je ne pense pas qu'il y ait une grande connexion).

Note de bas de page
Tout ce qui précède repose sur l'hypothèse que le code peut mentir, et qu'il s'agit d'un exemple basique (quoique peu élaboré):

public int DivideByTwo(int input) 
{
    return input / 3;
}

Ceci est juste un exemple où je dirais que "code ment", @ user61852 en a quelques autres (code inaccessible, complexité du code ne correspondant pas à la complexité du problème, mauvaise dénomination), et je pense qu'il y en a beaucoup plus. Wikipedia a un résumé quelque peu décent des mensonges , beaucoup d'entre eux peuvent être trouvés en code.

Notez que si vous vous disputez avec quelqu'un, assurez - vous que celui-ci ne veut pas dire par "le code ne peut mentir" que "le code fait ce qu'il fait". En substance, l'autre personne ici définit en utilisant une définition de "mensonge" qui est si étroite qu'elle peut déclarer l'énoncé "le code ne peut pas mentir" comme un axiome / vérité fondamentale. Dans ce cas, il est probablement préférable d'être d'accord avec son axiome.

— Jeroen
source

0

if (x > 5) {
  doSomething();
} else {
  doADifferentThing();
}

Vous pouvez vous demander si le mot «mensonge» est techniquement approprié, mais ce code implique très clairement que x sera parfois supérieur à 5 et parfois non. Si vous regardez le programme complet et découvrez que cette fonction n'est jamais appelée qu'à un seul endroit et que x est toujours défini sur une constante 6, alors c'est un mensonge.

De plus, le compilateur a peut-être remarqué cela et a remplacé ce bloc de code par simplement

doSomething()

Si doADifferentThing n'est appelé nulle part ailleurs dans votre programme, il peut être supprimé complètement du programme.

Si votre langue prend en charge un asserttype quelconque, qui est désactivé dans les versions de production, chaque assertdéclaration est potentiellement un mensonge. Un transtypage est une autre affirmation qui pourrait être un mensonge.

— MatrixFrog
source