Est-il nécessaire d'écrire une autre partie dans chaque condition if?

Non, vous n'avez certainement pas ont - au moins dans la plupart des langues. (Vous n'avez pas spécifié; il est tout à fait possible qu'il y est une langue qui ne respecter cela.) Voici un exemple où je ne voudrais certainement pas:

public void DoSomething(string text)
{
    if (text == null)
    {
        throw new ArgumentNullException("text");
    }
    //Do stuff
}

Maintenant, vous pourrait mettre le travail principal de la méthode dans un "else" clause d'ici - mais il augmenterait de nidification inutilement. Ajouter un peu plus de conditions et de toute la chose devient illisible mess.

Ce modèle de "début" est raisonnable commune, dans mon expérience - et va pour les valeurs de retour, ainsi que les exceptions. Je sais qu'il ya certains qui sont en faveur d'un seul point de retour à partir d'une méthode, mais dans les langues que je travail avec (Java, C#), qui peut souvent conduire à beaucoup moins de code lisible et plus profonde imbrication.

Maintenant, il y a une situation où il y a plus de place pour le débat, et c'est là que les deux branches sont de terminal, mais aucun d'eux n'est effectivement un raccourci:

public int DoSomething()
{
    //Do some work
    if (conditionBasedOnPreviousWork)
    {
        log.Info("Condition met; returning discount");
        return discount;
    }
    else
    {
        log.Info("Condition not met; returning original price");
        return originalPrice;
    }
}

(Notez que j'ai volontairement donné que les deux branches de plus de travail à faire que de retourner - le contraire d'une instruction conditionnelle serait approprié.)

Cela serait plus lisible sans les "autres"? C'est vraiment une question de choix personnel, et je ne vais pas à demander, je suis toujours cohérentes. Pour avoir eu les deux branches également en retrait leur donne un poids égal en quelque sorte - et encourage peut-être la possibilité de refactoring, plus tard, par l'inversion de l'état... alors que si l'on venait de tomber à travers le "retour prix d'origine", le refactoring de mettre en un bloc si et le déplacement de la remise de cas hors d'un bloc si serait moins évidemment correct à première vue.

Dans des langages comme Java et C, if - else est une déclaration et ne renvoie pas de valeur. De sorte que vous pouvez heureusement écrire que le if partie et aller sur. Et je pense que c'est la meilleure pratique plutôt que d'ajouter du vide elses après chaque if.

Toutefois, dans les langages fonctionnels comme Haskell et Clojure, if est une expression et elle doit retourner une valeur. Donc, il doit être réussi avec un else. Cependant, il existe encore des cas où vous ne pouvez pas besoin d'un else section. Clojure, pour de tels cas, a un when macro qui enveloppe if - else de retour nil dans le else section et d'éviter de l'écrire.

(when (met? somecondition)
  (dosomething))

Parfois, il n'y a pas d'autre partie....et notamment un vide juste rend le code moins lisible à mon humble avis.

C'est purement une question de style et de clarté. Il est facile d'imaginer si les déclarations, en particulier celles qui sont simples, pour lesquelles un d'autre serait tout à fait superflu. Mais quand vous avez un conditionnel plus complexe, peut-être la manipulation d'un certain nombre de différents cas, il peut souvent être la clarification de déclarer explicitement que, sinon, rien ne doit être fait. Dans ces cas-là, j'avais laisser un //do nothing commentaire dans le vide sinon le reste clair que l'espace est intentionnellement laissée en blanc.

Je sais je suis en retard mais j'ai fait beaucoup de réflexion sur le présent et je voulais partager mes résultats.

Dans le code critique, il est impératif que chaque branche est prise en compte. L'écriture d'une autre personne n'est pas nécessaire, mais laisser une marque que d'autre n'est pas nécessaire et pourquoi. Cela aidera à l'examinateur. Observer:

//negatives should be fixed
if(a < 0) {
    a+=m;
}
//else value is positive