J'ai ce qui suit et je me demandais si le test initial est surchargé:
static void Main(string[] args) {
if (args.Length == 0 || args == null) {
//do X
}
else {
//do Y
}
}
5 Réponses :
Ce n'est jamais une mauvaise idée de contrôler un contrôle supplémentaire, si cela ne se trouve pas dans les fonctions usagées très fréquentes. Donc, je dirais, pas, ce n'est pas trop exclu.
et une autre chose: première vérification de null , après pour longueur
Oui, il est absolument une mauvaise idée d'ajouter du code qui ne sert à rien. Il cloque le code, rend la lecture plus difficile à lire et à comprendre et, tout simplement, vous donne plus de code à maintenir. principal n'est pas appelé avec un paramètre null, alors n'ajoutez pas de complexité à votre code qui tente de tester Et si cela le fait
Eh bien, votre méthode principale ne doit normalement pas être utilisée plus d'une fois par exécution de programme ;-)
@jalf: Je n'ai jamais utilisé que le programme est utilisé sur la méthode principale d'utilisation une fois, je ne sais pas si vous l'avez fait. La pensée est que si suppose qu'un jour, après un service de service (mise à jour), il peut devenir null votre programme ne manquera pas. Il suffit d'ajouter un contrôle supplémentaire et de vivre heureux. Simple.
@Tigran: Service Packs Ne modifiez pas la spécification de la langue pour casser les programmes existants. Et si ils le font, il faut alors plus qu'un contrôle NULL pour corriger votre programme. Si un tel service de service a été délivré, cela tomberait beaucoup plus que cela. Mais imaginez que vous n'aviez pas écrire ce code, mais lisez it. Imaginez que vous ayez dû le maintenir. Ma réaction en lisant ce serait "Qu'est-ce que ce diable? Pourquoi ce chèque null est-il nécessaire? L'auteur original sait-il quelque chose que je ne le fais pas?"
Et puis je passerais le reste de la journée à essayer de découvrir tout un bug qu'il protégeait évidemment et des cas de recherche où args pourrait être null. Temps gaspillé parce que quelqu'un a introduit une complexité inutile dans son code. Si le .NET Framework ne suit pas sa propre spécification, nous sommes vêles, peu importe ce que nous faisons. Écrire votre code sur l'hypothèse que .NET réside à vous est futile
@Tigran: Un jour, après un service de service, console.writeline Peut amener des licornes à apparaître et à formater votre disque dur. Vous ne pouvez pas et ne devriez pas vous défendre contre tous les cas que «pourrait» arriver à l'avenir - considérez que si de tels changements de rupture ont été apportés, vous auriez beaucoup plus à vous inquiéter que args être nul.
@chao: Pourriez-vous être plus précis? Ce n'est pas vraiment clair si c'est le Service Pack ou les Licornes qui formataient votre disque dur. Je veux juste être sûr. ;)
@jalf: Pas sûr. Je vois une corrélation entre les licornes apparaissant et des disques durs mystérieusement formatés. Je ne peux pas dire avec certitude que ce sont les licornes qui le font, cependant.
@JAlf: Comprenez votre point, mais vous ne pouvez pas me convaincre que la présence d'une seule vérification de référence NULL dans le code le rendra moins lisible, créez une confusion à vous et de la force pour perdre un temps sur étudier ( ???) le code que vous regardez.
Peut-être que je ne peux pas. Mais sinon, alors vous n'avez pas eu à maintenir beaucoup de code. La simplicité est importante. Comprendre pourquoi Le code a l'air de la manière dont il est extrêmement important. Si vous ne pouvez pas donner une bonne raison pour que votre code a l'air de la façon dont il veut, je ne veux pas le maintenir.
@jalf: D'accord sur ce point +1. Malheureusement, le maintien du code ancien (Legacy) fait partie de mon travail, partagez-la donc de vos pensées.
Désolé gars, mais tous ceux qui croient que vous ne devriez pas protéger contre tous les cas sont simplement des mauvais développeurs. J'ai rencontré Soooo de nombreux cas où un développeur a répondu à un crash de programme avec: "Eh bien, le paramètre ne doit jamais avoir cette valeur" qu'elle mendie la croyance. S'appuyant sur la Parole des autres que les valeurs de paramètres aux fonctions publiques ne contiennent que certaines valeurs sont une erreur fatale.
@Adelphus: D'accord. N'aime pas ça "Je sais ce que je fais ce que je fais" et après avoir reçu des appels à minuit de certains clients pour le problème que le programme est écrasé et il a perdu toutes ses données.base exactement ce scénario malheureusement arrive beaucoup de temps dans ma vie. Préférez avoir une vérification, un journal et une notification utilisateur sur l'échec de l'opération. De cette manière, le client ne lâche rien (même si cela n'est pas capable de finir son travail, mais c'est mieux).
@Adelphus: Il y a une différence entre "ne devrait pas avoir" et "n'aura pas", ni même "ne peut pas avoir". Dans ce cas, args ne sera jamais nul (avec une exception près ... si une personne l'appelle spécifiquement dans l'application et transmet null ). Ce n'est pas une fonction de bibliothèque; Cela fait partie de la spécification pour le CLR lui-même. Ce n'est pas seulement que cela "ne devrait pas" arriver; IT ne se produira pas Sauf si vous appelez principal (incorrectement!) de votre application ... ou quelque chose a tellement mal tourné que vous ne pouvez pas faire confiance au runtime. Et si vous ne pouvez pas faire confiance à l'heure d'exécution pour même commencer votre application correctement, comment pouvez-vous faire confiance à quelque chose à partir de ce moment-là?
J'adore ça quand les gens disent "
@Adelphus: Il y a précisément un cas où cette principal (null) est cassé . Période. Lorsque les règles du jeu sont définies et que vous refusez de jouer par eux, tous les paris sont éteints. Dans ce cas, les règles sont définies par le CLR lui-même. Quand ils sont cassés, le code devrait casser. joyeusement. et qui ajoute si (args == null) {/ * oh noes * /} à leur code, plutôt que de fixer l'appelant (qui est dans le même panique app), doit être enfilé pour leur incompétence.
@Adelphus: Vous manquez le point. Ce n'est pas que "
J'adore tellement que je suis souvent embrassant le développeur lorsque
@Tigran: Quel scénario arrive souvent dans votre vie? Que le CLR se brise de manière à ce que les pratiques de codage défensives puissent sauver la journée et éviter les appels de minuit du client? Je trouve cela improbable
@jalf: Non :) Espérons que non CLR. Arrive souvent que le développeur suppose : "Cela ne va jamais arriver", et dans 90%, il sera . Je parle de pas Ce cas concret que la question a été demandée. Notre discussion a été éloignée du sujet réel de la question.
@jalf i vraiment J'espère que lorsqu'un client payant vous contacte, votre réponse est: Mon logiciel se bloque délibérément parce que c'est ce que je veux que cela ne soit pas juste.
@Tigran: Eh bien, Certains d'entre nous essayons de répondre à la question de l'OP. L'OP n'a pas posé de questions sur la programmation défensive en général. Il n'a pas posé de questions sur cette affaire la semaine dernière où votre client a été énervé à vous de ne pas vérifier si un paramètre était null. Il a demandé si c'était une bonne idée de vérifier l'argument de la méthode de la méthode principale de C #
@jalf: Il y a différents mondes de logiciels là-bas. Tous n'ont pas de bonnes unités de test (si elles ont), de bons développeurs ou de bons gestionnaires. Sameone travaille directement avec les clients (qui a ses avantages et problèmes pour le développeur de logiciels). Cette méthode de programmation "diffencive" est habituelle utilisée par celles qui travaillent de près avec le (s) client (s). D'autres, qui travaillent dans le bureau, au calme et séparés du monde extérieur avec un service client organisé, peuvent et vont choisir d'autres moyens. Je pense que c'est juste une entreprise.
@Tigran absolument. Je dirais que cela ressemble plus à 95%. C'est encore mieux lorsque le développeur dit: "Je suis 100% / 110% / 1000% de sorte que cela n'arrivera jamais". Et puis bien sûr, ça fait. Il semble que l'expérience compte dans ce cas.
@Adelphus: Je vraiment J'espère que vous ne facturez pas de l'argent pour des logiciels qui essaie de camoufler des erreurs et de continuer dans un état peu fiable où il pourrait faire beaucoup plus de dégâts que si cela vient de s'écraser. Voir, je peux le faire aussi. Peut-être pourrions-nous coller au sujet pendant cinq minutes?
@Adelphus: Et pourtant, je viens de me demander si Le problème dont nous parlons de garde contre n'est jamais arrivé, et il a dit non. Et toi? Est-ce arrivé pour vous? Et si c'est le cas, pouvez-vous sérieusement, honnêtement, disons que ce chèque null aurait sauvé la journée? Laissez-moi réessayer. Je ne dis pas "Je suis certain que ce paramètre ne sera jamais nul". Je dis "Je suis certain que si Ce paramètre est toujours nul, alors mon environnement est si vêtu que rien que je puisse faire aura de l'importance."
Personnellement, je vote pour fermer cette question avec la raison pour laquelle cela pourrait causer un stress émotionnel inutile :-)
Si le principal est appelé avec un argument nul, je n'ai aucune raison de croire que mon code sera même exécuté correctement. Et ainsi, même si je l'ai inséré ce chèque nul, je ne peux même pas être sûr que cela serait exécuté, ou que cela ne ferait que quelque chose d'autre, comme, formatage des clients HardDrive ". Vous pourriez aussi bien écrire Code pour vérifier que votre compilateur a émis le code correct ou que la CPU n'est pas défectueuse. Ce sont des erreurs claires que nous aimerions attraper, mais nous ne pouvons pas, parce que s'ils se produisent, aucun de notre code ne peut être invoqué. Comme nous ne pouvons pas compter sur notre code si le CLR se brise soudainement
Le problème est @jalf, les développeurs prennent vos raisons et les appliquent dans d'autres endroits. Tout ce que j'essaie de faire est d'indiquer que de bonnes pratiques de programmation impliquent une bonne vérification des paramètres - qui inclut la vérification de NULL. Un développeur pourrait facilement afficher vos commentaires et dire "bien dans mon API, ce paramètre entier ne sera jamais plus de 3 parce que cela n'a aucun sens dans ma fonction. Par conséquent, je ne me dérangerai pas de vérifier ce cas". C'est une mauvaise pratique et cela cause vraiment des problèmes. Dernier commentaire sur le sujet (je promets).
@Adelphus: Un "développeur" qui lit "le CLR n'appellera jamais principal (null) " et voit "Je n'ai pas à vérifier si quelqu'un m'a passé un 4" ... hein. Peut-être devrait-il vérifier pour NULL, dans le seul but de rendre plus claire au reste du monde qu'il ne sait pas ce qu'il fait. Ce sont deux cas différents. Personne n'a dit que vous ne devriez pas vérifier les choses que l'autre code de l'utilisateur vous passe. Mais vous pouvez faire confiance au système pour faire son travail - ou plutôt, si vous ne pouvez pas, vous ne pouvez pas vraiment faire confiance à ce que ce soit dans le système (même votre propre code!).
J'ai compris que cela pourrait faire une question sur le sujet et obtenir de nombreux points dessus :) vraiment incroyable comment la simple question mène à liée Long Battle où ne sont pas des gagnants ...
Incroyablement triste, peut-être. Cela n'aurait vraiment pas dû se transformer en ce qu'il a fait.
@CHAO: Pourquoi triste ?? Cet identifiant Q & A et un forum de discussion. C'est bien d'avoir quelqu'un qui peut offrir différentes solutions. Les solutions peuvent être, je ne suis pas convaincue dans ou je n'ai même pas pensé.
@Tigran: triste parce que c'était une question directe oui / aucune question. Il n'y a pas beaucoup de place pour "différentes solutions". Cela, et les réponses que je discutais avec sont si clairement faux . : P Il est la paranoïa aveugle et le cultisme de la cargaison.
if (args == null)
{
Console.WriteLine("args is null"); // Check for null array
}
else
{
if (args.Length == 0)
{
//do X
}
else
{
//do Y
}
}
Vous pouvez simplifier cela en utilisant si (args == null) {...} else si (arg.length == 0) {...} else {...} et enregistrez un calque d'accolades frisées. FWIW, dans la plupart des cas, les branches pour null et la matrice vide sont probablement les mêmes de toute façon.
@Joey sur les crochets Je pense que cela est plus lisible pour les autres et sur le deuxième commentaire dont vous vous trompez, car cité de ARG est NULL, la vérification de la longueur de la longueur de la nullreference!
C'est pourquoi vous vérifiez premier pour null et alors pour longueur : si (args == null | | arg.length == 0) ...
Selon Ce , vous Il suffit de vérifier: si vérifiant null ne fait aucun mal, il n'y a pas de besoin réel.
+1 pour le rasoir d'Occam et fournir un lien. Les autres réponses sont correctes, bien sûr, pour les cas généraux, mais cette question était très spécifique.
@InteNediatehacker - Nice; Je pensais que je me suis souvenu d'une entrée de MSDN, je ne pouvais tout simplement pas le trouver!
Eh bien, D'autre part, si vous DO Vérifiez que NULL, les lecteurs et les responsables du code devront comprendre pourquoi . Pourquoi le programmateur d'origine a-t-il été mis dans un tel chèque inutile? Savait-il quelque chose que nous ne faisons pas? Nous ne pouvons pas simplement le supprimer, car il aurait pu découvrir un bogue de cas d'angle étrange!
En d'autres termes, vous ajoutez de la complexité à votre programme et vous trompez les futurs lecteurs du code. Ne fais pas ça. Cet utilisateur futur pourrait être vous . Faites votre futur auto-heureux et écrire du code que a du sens .
Cependant, dans des situations où un tel chèque de NULL fait le sens, il doit s'agir de la condition la plus à gauche.
Dans un test comme celui-ci: Main est défini pour jamais jamais être appelé avec un paramètre null . Si ce est reçoive un paramètre null, alors votre environnement est tellement brisé que tous les paris sont désactivés, peu importe ce que vous faites, il n'y a donc vraiment rien à gagner en vérifiant pour null .
arg.length == 0 || args == null , arg.length est évalué premier , et si cela échoue, args est comparé à null . En d'autres termes, si args est NULL, votre code lancera une exception. Il devrait être args == null || arg.length == 0
C'est une réponse vraiment terrible. Tous les bons développeurs savent ne pas compter sur le comportement du code externe lorsqu'il appelle leurs fonctions publiques. La programmation défensive atout toujours la programmation espoir (c'est-à-dire que le paramètre n'est pas null). C'est vraiment une mauvaise pratique d'avoir l'habitude d'assumer des valeurs de paramètre. Vérifiez pour NULL - Il n'y a aucun préjudice, vous ne pouvez pas vraiment prétendre que c'est une performance touchée dans ce cas et cela montre que vous pensez à toutes les possibilités.
Je n'ai jamais rien dit sur la performance. Mais s'il vous plaît dites-moi comment il est mauvais de compter sur votre langage de programmation et sa bibliothèque de classe pour faire ce qu'il dit ? Si vous ne pouvez pas compter sur cela, comment pouvez-vous écrire n'importe quel type de code ? Si vous ne pouvez pas faire confiance à cela, alors chaque ligne que vous écrivez, y compris votre chèque NULL est suspect et peu fiable. Si vous voulez parler de pratiques terribles, ce type d'obfuscation inutile est-ce. Dire "Et si tout dans le monde entier est corrompu et peu fiable? Que ferons-nous alors? Je sais, vérifiant" code> arg == null va le corriger ". Non, ce ne sera pas.
Si votre monde est cassé, vous ne pouvez pas le réparer, et vous pourriez aussi bien que vous n'ayez pas la peine d'essayer. Vous pouvez appeler cela «espoir» de programmation si cela vous fait sentir mieux, mais c'est la seule chose que nous puissions faire. Nous devons espoir que le compilateur génère le code demandé. Nous devons espérer que la classe principal sera appelé le démarrage . Nous devons espoir qui accédant à un null jette un NullReferenceException . La programmation défensive ne peut pas vous protéger contre une mise en œuvre de la langue brisée.
Qui a dit que le seul appelant est le .NET Framework? Cela n'a rien à voir avec la mise en œuvre de la langue - il s'agit de bonnes pratiques de programmation. Cette question pourrait facilement être interrogée sur toute autre langue. La programmation défensive consiste à assurer que le comportement du programme est connu et bien compris dans le cas d'erreurs. Si vous ne le faites pas et si vous supposez que tout ira bien, vous attendez un monde de douleur quand tout est tombé en panne.
Si je faisais une bicyle, pourquoi devrais-je porter un casque de vélo de moteur - au cas où un jour à l'avenir Le vélo germe un moteur. Sûrement il suffit de s'en tenir à porter avec un chapeau de vélo, comme Jalf dit que si quelqu'un tire le vélo à l'avenir avec un casque de moto vélo, ils se demanderont ce qui se demandera! (Peut-être pas la meilleure analogie que j'ai pensée)
De simple question née une discussion intéressante ... :)
@WhyTheq, je dirais que tu ne portes pas un casque du tout :-) Tout le monde vous a dit qu'aucune voiture ne va jamais sortir devant vous, donc vous pensez que ça va bien. Le problème est que j'ai vu des charges de voitures glisser des charges de vélos (métaphoriquement parlant). Personnellement, je ne veux pas mourir et je ne veux pas que quiconque utilise mon vélo pour mourir non plus.
@Adelphus: Ensuite, vous voudrez peut-être imposer que tout coureur porte une combinaison de protection et un parachute de 10 pieds d'épaisseur et portent un missile nucléaire en cas de chute d'astéroïdes. Visez-le, vous ne pouvez pas - et ne devrait pas! - Protéger contre chaque chose étrange qui pourrait jamais arriver. Considérez (à revenir sur le sujet :)) que si quelque chose appelle principal (null) , quelque chose est fondamentalement brisé. Que quelque chose serait l'appelant , et c'est là que le correctif devrait aller. si (args == null) est une aide-bande sur une jambe cassée.
Tout est parti un peu trop surréaliste - il s'agit d'un site sérieux pour une analyse sérieuse ... Mieux gardez mes analogies bon marché pour moi la prochaine fois
+1, pour le commentaire long discussion-argument-débat chose.
@adelphus: "Cette question pourrait facilement être posée sur toute autre langue." Sérieusement? Une programmation si défensive consiste à protéger contre l'affaire où votre code s'avère soudainement une langue différente ? Je peux juste l'imaginer. "Oh merde, le code C ++ que j'ai écrit depuis 8 mois vient de devenir prolog! DAMN, si seulement je suis protégé contre principal appelé avec des paramètres non valides". Cette question concerne la méthode principale dans une langue spécifique . Dans cette langue, la principale est appelée une fois, par l'exécution, au lancement de la demande, à moins que le programmeur soit fou
Et si le programmeur est fou, un chèque nul ne va pas nous aider.
@Whytheq: "Si je faisais un vélo, je devais-je porter un casque de moto à vélo - au cas où une journée à l'avenir, le vélo germe un moteur" - c'est une analogie superbe . M'a fait rire. +1 :)
Je concède que j'ai perdu cette bataille contre les Nay. @jalf Vous ne comprenez clairement pas ce que la programmation défensive est ou pourquoi elle est utilisée. J'admets que dans cet exemple particulier Il existe une probabilité élevée que le paramètre ne soit pas nul. Cependant, j'imagine ainsi comme un forum d'apprentissage ainsi qu'un QA et j'espère que j'ai au moins donné d'autres lecteurs de la nourriture à la pensée.
@Adelphus: Je sais quelle est la programmation défensive. Mais l'OP a demandé à une question spécifique sur la vérification de NULL dans un scénario très spécifique . Je suis absolument d'accord avec vous, dans de nombreux cas Autres , il est logique de vérifier NULL. Mais nous ne parlons pas de ces cas. Nous parlons d'un programme C # dans lequel la méthode principale vérifie si son argument est null. Ainsi, un forum d'apprentissage et l'une des leçons importantes que chaque programmeur devrait apprendre est que "cela dépend". Vérifier aveuglément Tout contre NULL est aussi stupide que de vérifier rien .
Si (argument == Discussion) {abandonne ();}
une des meilleures réponses sur SO
@jalf Juste pour clarifier, aucune de args s ' valeurs pourrait être null non plus? (En supposant que le temps d'exécution appelle bien sûr, pas un programmeur fou)
S'il n'y a pas de données d'entrée, alors arg.length est égal à 0, mais pas null. S'il y a des données d'entrée, la longueur d'AGR est égale au nombre d'arguments d'entrée. En conclusion, args ne peuvent pas être nuls, mais la longueur peut être nulle.
PS chèque pour null d'abord toujours
Votre logique est le mauvais sens. Que se passe-t-il si
args estnull ? Vérificationarg.length lancera unNullReferenceExcetpionOverkill? pas vraiment. Sauf si vous avez absolument besoin de fournir une réponse lorsque des arguments sont tenus d'exécuter le programme, alors faites-le. Greg B a raison, vérifiez si NULL puis vérifiez la longueur.
En règle générale, vous devriez vérifier que NULL avant toute autre chose, car si
args est vraiment null, votre première condition jettera unNullReferenceException .