Méthode d'archivage explicite retournant si l'objet est nul?

Question

Si j'ai une méthode comme ci-dessous:

-(BOOL)shouldResize { 
    return _view != nil; 
} 

où _view est un pointeur vers un objet, est explicite nul contrôle nécessaire/recommandé, ou est-il suffisant pour simplement faire:

-(BOOL)shouldResize { 
    return _view; 
} 

Je me demande si un comportement étrange peut apparaître dans la coulée du pointeur vers une BOOL, comme dans l'exemple ici: (je suppose que vous pouvez aussi faire return !!_view, à droite) https://developer.apple.com/documentation/objectivec/bool?language=objc

Answer 1

Selon la plate-forme ou l'architecture, BOOL peut être équivalent à signed char. Par conséquent, return _view n'est pas sûr. La valeur réelle du pointeur _view sera tronquée en un seul octet. Cet octet est susceptible d'être 0 même si _view n'est pas nil. Dans ce cas, le code retournera false quand il devrait être vrai.

return _view != nil est sûr et raisonnable. L'utilisation de return !!_view est correcte et peut ne pas convenir selon les normes de codage de votre équipe. Dans certains endroits, c'est la façon idiomatique de «normaliser» une expression booléenne. D'autres peuvent le trouver trop malin par moitié et «laid» (comme exprimé dans d'autres réponses ici).

Answer 2

Il suffit de retourner la vue pour gérer automatiquement si la vue est nulle ou non. Si elle est nulle, elle retournera "NON" et "OUI" sinon. La seconde version de la méthode "shouldResize" suffit.

Selon moi, la meilleure pratique est d'avoir un contrôle nul explicite afin d'avoir une compréhension claire, une meilleure maintenabilité et éviter la surprise.

Answer 3

Je préfère "return _view! = Nil" pour la lisibilité. La méthode retourne un booléen et donc je préfère que cela soit évident à partir du code dans la méthode.

Dans votre cas, la deuxième option (return _view) fonctionnera également.

"retour! _view" Je trouve moche.

Answer 4

Le type BOOL est défini différemment dans les modes 32 bits et 64 bits, donc le comportement est différent. Par conséquent retourner _view au lieu de _view! = Nil est un bug. Prenez un indice de Swift (que vous aurez à faire de toute façon bientôt). Dans Swift, self.view! = Nil serait le seul moyen légal. Dieu merci. A titre d'exemple, à quel point être intelligent peut être dangereux, "return! _view" n'est pas seulement laid, c'est faux. Il fait le contraire de ce qui a été demandé.