28 votes

Cocoa Bad Habits

Quelles sont ces mauvaises habitudes que vous avez développées depuis que vous avez commencé à coder en Cocoa?

Je pense que faire une liste de mauvaises habitudes et y ajouter activement et, plus important encore, briser ces habitudes est une bonne technique pour produire la qualité de votre code. Alors commencez maintenant, débarrassez-vous de vos mauvaises habitudes. Peut-être que d'autres personnes partagent vos mauvaises habitudes.

21voto

lfalin Points 1181

Passer nil aux arguments qui appellent NSError **, pure paresseux.

14voto

Dave Dribin Points 3175

Pas assez de tests unitaires. Il est vraiment difficile de nettoyer et de refactoriser le code si vous n'avez pas de tests unitaires. Et sans refactorisation et nettoyage constants, la pourriture du code commence à s'installer et à se propager.

Utiliser le modèle singleton pour partager des objets, comme + [MyObject defaultObject]. Il s'agit essentiellement d'une variable globale qui crée de belles dépendances et couplages cachés. Ceci, à son tour, rend le code plus difficile à tester.

11voto

mmalc Points 7663

L'utilisation d'exceptions pour le contrôle de flux

(Et d'autres non-circonstances exceptionnelles.)

Depuis l'utilisation des exceptions est porté dans une autre réponse ici et la documentation mentionnée dans les commentaires de ne pas insister sur ce point en particulier, il est intéressant de souligner que les exceptions ne devraient pas être utilisées pour le contrôle de flux (comme cela est courant dans certains autres environnements). Exceptions dans le Cacao sont relativement très cher. Si vous souhaitez communiquer une erreur, utilisez un NSError de l'objet et de la gestion des erreurs de l'architecture fournies par le Cacao. Ne jetez pas les exceptions.

7voto

schwa Points 9102

Voici quelques-unes des miennes:

De lever des exceptions sans tenter de catch 'em. J'ai commencé à compter sur NSError de plus en plus à prévenir NSExceptions de voler comme des balles dans un John Woo film, mais j'ai encore beaucoup de exceptionnel de code là-bas.

La rédaction d'un rapide de classe pour faire X, Y et Z puis d'oublier de les nettoyer dans le dealloc. Les fuites ahoy!

À l'aide de cordes directement dans différents endroits (KVO) au lieu de définir une constante et l'utilisation (voir Dave Musée de l'excellent billet de blog sur le KVO pour en savoir plus)

7voto

Jablair Points 2495

Je deviens paresseux sur l'utilisation des accesseurs à l'intérieur des classes. Généralement, le plus gros problème est que je ne peux pas dire facilement la portée de la variable lors d'un rapide coup d'œil. Ensuite, j'ai passé quelques heures la semaine dernière le débogage d'une corruption de la mémoire des questions qui était due à l'utilisation de

self.displayName = name

dans certains endroits, et

displayName = name

dans les autres. J'ai été heureux quand je l'ai trouvé et mon application cessé de s'écraser. Je n'étais pas si heureux que j'ai perdu plusieurs heures à la recherche d'un tel évitables erreur.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X