L'écriture de code mort est-elle utile?

Trouvez-vous utile d'écrire du code mort?

Certains disent: "Si vous avez 2 logiques pour effectuer une opération, au lieu de commenter un autre code logique ou de supprimer du code, faites-en un code mort car cela n'affectera pas l'opération."

Exemple:-

if(true){
    // logic - 1
} else {
    // logic - 2  // dead code
}

Est-ce vrai?

Je n'écris généralement pas de codes morts à la place, je supprime simplement la deuxième logique.

OMI, c'est pire qu'inutile.

En plus d'être une perte de temps, cela vous donne (ou le gars suivant) l'illusion que vous avez du code qui fonctionnera si vous passez trueà false. Ce n'est qu'une illusion ... à moins que vous ne la testiez.

Et bien sûr, c'est l'encombrement qui rend le code plus difficile à lire.

Si vous utilisez n'importe quel type de code mort SCM, il est rarement utile. Vous devez le supprimer à la place et si vous avez besoin de voir le code de la logique 2, vous le récupérez du référentiel SCM.

Éditer:

Si vous avez du code mort et que vous maintenez d'autres parties du code, vous pouvez essayer d'obtenir des utilisations de certains codes qui pourraient générer le code mort. Si quelqu'un d'autre fait la maintenance, il se peut qu'il ne connaisse pas son code mort et même s'il le fait, il ne saura certainement pas pourquoi il est toujours là.

Si vous pensez alors qu'une méthode pourrait être supprimée car elle n'est pas utilisée par du code "en direct" mais uniquement par du code mort, vous devrez soit changer (et probablement casser) votre code mort, soit rendre l'autre méthode morte elle-même.

En fin de compte, vous vous retrouveriez très certainement dans une sorte d'enfer de maintenance.

Ainsi, le meilleur code est le code supprimé, car il ne peut pas produire de mauvais résultats ou distraire les responsables. :)

Non, c'est mauvais, car cela encombre votre code et réduit la maintenabilité.

Habituellement, il y a une raison claire de préférer l'une des «logiques» alternatives. Cette raison (et l'existence d'une alternative rejetée) doit être documentée dans un commentaire de code. Dans le cas relativement improbable où la raison devient invalide, le code alternatif peut être récupéré de l'historique du référentiel (s'il s'agissait de la solution mise en œuvre précédemment préférée), ou étoffé et mis en œuvre en utilisant toutes les connaissances et les exigences actuelles (s'il ne s'agit que d'un vague idée).

Cela n'affecte pas le fonctionnement mais cela affecte la maintenance. Vous voulez garder le code aussi ordonné que possible pour en faciliter la maintenance.

Je suis honnêtement confus par ce que vous faites.

Par ordre de priorité décroissante:

1. Vous devez conserver un enregistrement des modifications de code quelque part, donc si le nouveau code ne fonctionne pas, vous pouvez les comparer. Cela devrait toujours être sous contrôle de source. Je suppose que vous le faites déjà. Sinon, faites tout ce que vous pouvez pour obtenir QUELQUE forme de contrôle de code source. Si vous devez absolument vous en passer (et je n'ai jamais entendu parler d'une occasion où c'est une bonne idée), rendez au moins facilement accessibles des sauvegardes régulières de l'état de la source.

2. En supposant que vous faites # 1, vous pouvez donc récupérer le code mort si vous en avez besoin, ne le gardez pas dans le code en direct à long terme. Cela sera juste déroutant, ajoutera une complexité supplémentaire sans valeur, nécessitera de la maintenance, se désynchronisera avec le code en direct et induira en erreur les gens à l'avenir, etc., etc.

3. Cela dit, il existe des situations spécifiques où un basculement au moment de la compilation entre deux chemins de code est raisonnable. Pendant que vous développez le nouveau code, et immédiatement après, il peut être pratique d'avoir les deux, afin que vous puissiez facilement basculer entre. Si vous devez probablement revenir en arrière ou ajouter une option de configuration externe, un if basé sur une constante leur donne un chemin de mise à niveau raisonnable. Donc, comme beaucoup de choses - si cela résout un problème particulier, faites-le. Sinon, évitez-le.

La raison pour laquelle je suppose que les gens le font trop est: d'avoir des doutes (souvent correctement) que les gens liront réellement l'historique du contrôle de la source s'ils ont un problème; d'avoir peur du nouveau code ne fonctionnera pas et de vouloir une option de réversion facile. Un compromis pour essayer de vous satisfaire tous les deux pourrait être de mettre un commentaire "Modifié pour calculer ... le (Date). En cas de problème, voir l'ancienne version dans le contrôle de code source" ou similaire.

Non, ce n'est pas utile. Ce elsebloc ne remplit aucun objectif. Si vous n'êtes pas sûr de l'implémentation à utiliser, mettez-la en commentaire, créez des classes séparées ou enregistrez-la ailleurs. De plus, la plupart du temps, vous avez - ou du moins devriez avoir - un historique local ou distant de vos fichiers source.

Le code mort devrait être supprimé par le compilateur si la condition dépend d'une constante de temps de compilation, donc techniquement cela ne ferait pas de mal de le conserver. Cependant, je préfère le commenter car cela améliore la lisibilité du code.

Si vous souhaitez pouvoir basculer rapidement entre deux alternatives de code, vous pouvez utiliser la construction de commentaire pratique suivante:

//*
alternative 1 is active
/*/
alternative 2 is commented out
//*/

si vous supprimez uniquement le premier /de la première ligne de commentaire, cela devient:

/*
alternative 1 is commented out
/*/
alternative 2 is active
//*/

Avec cela, vous pouvez basculer entre les alternatives en ajoutant ou en supprimant simplement un seul /dans le code.

Cela peut sembler un peu étrange au début, mais une fois que vous vous y serez habitué, vous le reconnaîtrez facilement comme une sorte de motif.

Vous pouvez même l'enchaîner et ainsi basculer plusieurs blocs à la fois avec un seul caractère:

//*
first block of code for alternative 1
/*/
first block of code for alternative 2
/*/
second block of code for alternative 1
/*/
second block of code for alternative 2
//*/

Je ne l'utiliserais pas de cette façon mais cela fonctionne.

Il y a de très rares occasions où l'ancien code, et le fait qu'il a été remplacé, devrait vraiment rester dans le code source afin que les futurs programmeurs soient avertis de quelque chose de contre-intuitif. Dans ce cas, il faut également une sorte de commentaire expliquant pourquoi il est toujours là et ce qui s'est passé.

Comme toujours, écrire des programmes faciles à entretenir consiste à clarifier les choses, pas seulement à suivre des règles strictes et rapides. Si le fait de laisser le code mort facilite la compréhension de ce qui se passe, laissez-le. Sinon, retirez-le.

Il sera ignoré par le compilateur. Cependant, je suis d'accord avec vous et je supprimerais simplement la déclaration else. En supposant que vous utilisez le contrôle de version, vous pourrez toujours voir l'ancien code en affichant l'historique du fichier.

C'est probablement une opinion personnelle, mais je trouve que le code mort distrait lors de la maintenance d'un morceau de code. Pour une tâche donnée, vous avez toujours plus d'une façon de l'accomplir, vous devez donc en choisir une. Faites vos recherches, évaluez les algorithmes et choisissez-en un. Après cela, le code n'a plus besoin de contenir de méthodes alternatives.

S'il y a deux prétendants très forts, rédigez une petite note sur l'alternative et collez-la dans un wiki de projet ou ailleurs contenant la documentation du projet. Si vous le souhaitez, vous pouvez mettre un commentaire d'une ligne qui se réfère à ce document et explique pourquoi vous pouvez aller le lire.

Je ne peux pas immédiatement penser à une situation où j'ai trouvé utile d'écrire du code mort. S'il existe des algorithmes alternatifs, alors:

• soit vous gardez le plus utile et vous éliminez l'autre,
• ou les algorithmes sont applicables à différentes circonstances, puis vous conservez les deux et le conditionnel identifie les circonstances lorsque vous utilisez le premier algorithme.

Dans les deux cas, vous vous retrouvez sans code mort.

Si vous ne supprimez pas ou ne commentez pas votre code mort, vous devrez le maintenir pour éviter les erreurs du compilateur. C'est du temps perdu. Supprimez-le simplement si vous avez un SCM.

NON

Certains programmeurs utilisent ce style comme alternative aux commentaires et le trouvent élégant.

if (1 == 0) 
{
    std::cout <<"I am a dead code capable of resurrection, once a programmer changes the condition!";
}

La réponse simple est un simple non. Le code mort attire la confusion et les opportunités de bugs se produisent. Dès que vous saisissez un caractère dans le code, il y a un risque. N'ajoutez donc pas plus que nécessaire.

La seule fois où j'ai dû écrire quelque chose de similaire était comme solution de contournement pour un bogue du compilateur, il a même été recommandé par le vendeur du compilateur d'utiliser cette solution.

Testez-vous le code mort que vous écrivez? Faire quelque chose pour confirmer que c'est probablement bon? Sinon, débarrassez-vous-en.

Pour les changements de code futurs, allez-vous vérifier que le code mort fonctionne toujours? Sinon, débarrassez-vous-en.

Vous ne voulez pas de mauvais code dans vos programmes, même s'il n'est pas utilisé. L'y avoir suggère qu'il peut être utilisé. Vous ne voulez généralement pas conserver deux versions de code si vous n'utilisez pas les deux, car c'est un travail supplémentaire, et comme cela semble inutile, la plupart des gens ne feront pas du bon travail avec le code mort.

Il peut y avoir des raisons de conserver le code commenté (ou, en C ou C ++, #ifdefle code édité), mais cela devrait être accompagné de commentaires expliquant pourquoi il est toujours là et à quoi il sert.

Notez qu'en Java, les éléments suivants ne seront même pas compilés, en raison du code inaccessible:

int someFunc() {
    return 10;
    int x = 12;
    return x;
}

Idéalement, s'il y a quelque chose qui ne va pas avec votre code, vous voulez le trouver le plus tôt possible, plutôt que de le laisser aller en production et être trouvé par vos utilisateurs.

Si une classe d'erreur peut être trouvée par votre compilateur, laissez le compilateur la trouver. À mon humble avis, ce que quelqu'un fait en écrivant du code mort de la manière que vous décrivez, tente de contourner cette erreur du compilateur, permettant à tous les problèmes qu'elle peut provoquer d'être détectés lors de l'exécution.

Vous pouvez faire valoir que le code mort ne peut pas être atteint, donc ne peut pas causer de problèmes, mais quelque chose peut mal tourner dans les commentaires, le renforcement et l'indentation qui pourrait y arriver.

La raison pour laquelle les gens commentent une vieille logique est parce qu'ils ont peur d'apporter de grands changements au code. Et en effet, réalisant une semaine plus tard que l'ancien code était en fait correct et maintenant vous devez l'écrire à partir de zéro est une chienne. Mais c'est à cela que sert le contrôle des sources. Si vous décidez de changer une logique, n'ayez pas peur de perdre le code actuel quelque peu fonctionnel. Supprimez-le et laissez votre SVN / Git / TFS s'occuper du versioning pour vous.

Si ce n'est pas le cas et que vous venez de produire deux éléments de logique différents pour faire quelque chose parce que vous ne vous souciez pas de YAGNI ou de DRY, assurez-vous simplement de le placer à un endroit où les gens peuvent l'utiliser. Peut-être y jeter un modèle de stratégie si vous en avez envie. Ne faites pas ces choses "si .. sinon", c'est une mauvaise conception et une douleur à maintenir. Si vous pensez vraiment qu'un code a le droit d'exister, assurez-vous de pouvoir l'utiliser.

Un autre regard est que la plupart des programmeurs professionnels conviennent que la taille du code est l'ennemi. Jetez un œil à ces articles de blog: Le meilleur code n'est pas du tout de Jeff Atwood, le pire ennemi de Code par Steve Yegge, vous pouvez en trouver beaucoup plus.

Les gens font beaucoup de choses pour garder leur code concis et empêcher que la base de code ne devienne trop grande, souvent même en sacrifiant les performances (là où cela n'a pas beaucoup d'importance). Alors, pensez-vous vraiment que 100 lignes de code mort peuvent être une bonne chose?

Le seul endroit où j'ai vu que cela était utile est dans les cas où vous voulez désactiver rapidement quelque chose et tester / remblayer (Dites que le programme fait les étapes A, B, C - tout cela prend beaucoup de temps. Pendant le remblayage, vous pouvez choisir de désactiver B et C pour le moment d'accélérer si vous savez qu'ils ne sont pas nécessaires).
Mais la vérité est que dans tous les cas, c'est très hacky. Et si vous voyez une utilisation à long terme pour votre code de renvoi, vous devez écrire votre code de telle manière qu'il utilise config pour choisir un choix au lieu d'utiliser de tels hacks.
Ma règle générale rapide est de ne jamais archiver ce type de code. Si vous avez besoin d'un enregistrement / contrôle de version, cela signifie que vous pourrez y revenir très bientôt, et c'est toujours une mauvaise chose à la lumière des exigences changeantes.

En fait, il y a un moyen d'avoir un code "mort": quand vous voulez que votre programme lève une énorme exception car il a atteint quelque chose qui n'aurait jamais dû arriver. Ce serait soit une erreur du compilateur, soit si quelqu'un en haut de la ligne modifiait la logique du test que vous utilisez et la gâchait. Quoi qu'il en soit, votre "else" envoie des feux d'artifice. Dans ce cas, vous voudriez le retirer pour publication.

Il est extrêmement important que le message d'erreur indique quelque chose comme "Panique: nous ne sommes jamais censés être ici à la ligne% d dans le fichier% s" ...