Meilleure pratique: valeur de retour de fonction ou paramètres de sortie byref?

StackOverflow https://stackoverflow.com/questions/246814

  •  05-07-2019
  •  | 
  •  

Question

J'ai une fonction appelée FindSpecificRowValue qui prend un objet datable et renvoie le numéro de ligne qui contient une valeur particulière. Si cette valeur n'est pas trouvée, je souhaite l'indiquer à la fonction appelante.

Est la meilleure approche pour:

  1. Ecrivez une fonction qui retourne false si non trouvé, true si trouvé, et le numéro de ligne trouvé en tant que paramètre byref / output, ou
  2. Ecrivez une fonction qui retourne un int et repasse -999 si la valeur de la ligne n'est pas trouvée, le numéro de la ligne s'il s'agit?
Était-ce utile?

La solution

Personnellement, je ne ferais pas non plus avec ce nom de méthode.

Je ferais plutôt deux méthodes: 

TryFindSpecificRow
FindSpecificRow

Cela suivrait le modèle Int32.Parse / TryParse, et en C #, ils pourraient ressembler à ceci: 

public static Boolean TryFindSpecificRow(DataTable table, out Int32 rowNumber)
{
    if (row-can-be-found)
    {
        rowNumber = index-of-row-that-was-found;
        return true;
    }
    else
    {
        rowNumber = 0; // this value will not be used anyway
        return false;
    }
}

public static Int32 FindSpecificRow(DataTable table)
{
    Int32 rowNumber;


    if (TryFindSpecificRow(table, out rowNumber))
        return rowNumber;
    else
        throw new RowNotFoundException(String.Format("Row {0} was not found", rowNumber));
}

Modifier: Modifié pour être plus approprié à la question.

Autres conseils

Les

fonctions qui échouent devraient générer des exceptions.

Si l'échec fait partie du flux attendu, le renvoi d'une valeur hors bande est correct, sauf dans les cas où vous ne pouvez pas déterminer à l'avance ce que serait une valeur hors bande, auquel cas vous devez générer une exception. / p>

Si je devais choisir entre vos options, je choisirais l'option 2, mais utiliserais une constante plutôt que -999 ...

Vous pouvez également définir la valeur de retour comme Nullable et ne renvoie rien. si rien n'a été trouvé.

Je choisirais l'option 2. Bien que je pense que je n'utiliserais que -1 et non pas -999.

Richard Harrison a raison de dire qu’une constante nommée vaut mieux qu’une simple -1 ou -999.

Je choisirais 2 ou une autre variante dans laquelle la valeur renvoyée indique si la valeur a été trouvée.

Il semble que la valeur de la ligne renvoyée par la fonction (ou fournissant une référence à) indique déjà si la valeur a été trouvée. Si une valeur n'a pas été trouvée, il semble alors inutile de fournir un numéro de ligne qui ne contient pas la valeur. La valeur renvoyée doit donc être -1, ou Null, ou toute autre valeur adaptée à la langue en question. Sinon, le fait qu'un numéro de ligne ait été renvoyé indique que la valeur a été trouvée.

Ainsi, il ne semble pas nécessaire de disposer d’une valeur de retour distincte pour indiquer si la valeur a été trouvée. Cependant, le type 1 pourrait être approprié s'il correspond aux idiomes du langage particulier et à la façon dont les appels de fonction y sont effectués.

Allez avec 2) mais retournez -1 (ou une référence null si vous retournez une référence à la ligne), cet idiome est très utilisé (y compris par les fonctions .Onets indexOf (item)), c'est probablement ce que je ferais .

BTW -1 est plus acceptable et plus largement utilisé "nombre magique" que -999, c’est la seule raison pour laquelle il est "correct" (citations utilisées pour une raison).

Cependant, cela est en grande partie lié à vos attentes. L'article devrait-il toujours y être, mais vous ne savez pas où? Dans ce cas, renvoyez l'index normalement et émettez une erreur / exception s'il n'y en a pas.

Dans ce cas, l'élément peut ne pas être là et c'est une condition acceptable. C'est un piège d'erreur pour les valeurs non sélectionnées dans un GridView qui se lie à un datatable.

Encore quelques possibilités non encore mentionnées: 

// Method 1: Supports covariance; can return default<T> on failure.
T TryGetThing(ref bool success); 

// Method 2: Does not support covariance, but may allow cleaner code in some cases
// where calling code would use some particular value in in case of failure.
T TryGetThing(T DefaultValue);

// Method 3: Does not support covariance, but may allow cleaner code in some cases
// where calling code would use some particular value in case of failure, but should
// not take the time to compute that value except when necessary.
T TryGetThing(Func<T> AlternateGetMethod);

// Method 4: Does support covariance; ErrorMethod can throw if that's what should
// happen, or it can set some flag which is visible to the caller in some other way.
T TryGetThing(Action ErrorMethod);

La première approche est l’inverse de la méthode mise au point par Microsoft à l’époque antérieure à la prise en charge des interfaces covariantes. La dernière solution est à certains égards la plus polyvalente, mais elle nécessitera probablement la création de deux nouvelles instances d’objet GC (par exemple, une fermeture et un délégué) chaque fois qu’elle est utilisée.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top