Avant d'entrer dans ce post, je voudrais faire quelques choses absolument clair. Je ne veux pas que mes intentions incompris.
Mon partenaire d'écriture illustres, Dave Mark tweeté aujourd'hui sur les Guide Google style Objective-C argument contre l'aide de notation pointée en Objective-C, Qui se lit comme suit:
La deuxième moitié de la première phrase est une tentative de remise d'un des avantages de la notation pointée par un simple rejet désinvolte sans preuve qu'il ou du soutien.
La deuxième phrase est tout simplement une tentative pour renforcer les arguments qui suivent en banalisant notation pointée comme "juste" quelque chose que nous pouvons déjà faire. C'est un peu comme dire que les réacteurs ne pas ajouter de valeur au cours des hélices parce qu'ils sont «juste» une autre façon de créer de poussée. Chaque construire dans tout langage de programmation qui est de niveau supérieur que l'assemblage est «juste» une autre façon de faire quelque chose que nous pouvons déjà faire. Cette phrase n'a aucune valeur sémantique ou logique, c'est tout simplement ici pour définir une tonalité négative envers l'utilisation de la notation pointée sans réellement offrir tous les faits ou les raisons de ne pas l'utiliser. Ce premier «argument» est la rhétorique, rien de plus.
En réalité, vous ne voyez pas la notation hongroise beaucoup ces jours-ci. Les variables avec une signification sémantique - ceux qui utilisent des mots qui sont reconnaissables par et ont un sens pour le cerveau - fonctionnent beaucoup mieux. Nous ne connaissons pas le type spécifique de la variable, mais nous savons à quoi elle sert, ce qui est vraiment plus important.
Notation pointée ne «obscures» du type que vous êtes le déréférencement moins qu'il y ait une raison pour laquelle vous voulez savoir le type de regarder juste à cette ligne de code. Cet argument fait l'hypothèse que nous savons déjà et que nous devrions savoir ce que le type de foo est. Bien sûr, avec la notation crochets, nous savons que nous sommes face à un objet, mais nous ne savons pas quel type d'objet, il est de regarder à ce une ligne de code dans le vide.
Mais, quand pensez-vous jamais regardé une ligne de code dans le vide? Vous n'avez pas. Code n'a pas de sens hors contexte. Si il était vital que nous savons tout sur une variable de regarder hors de son contexte, alors nous serions tous en utilisant la notation hongroise. Pourtant, nous ne sommes pas.
Quelque part, probablement pas plus de quelques lignes ci-dessus
Vous ne pouvez pas occulter quelque chose que vous n'avez pas de raison de connaître. La quantité d'informations que la notation crochets nous donne sur la notation à points est trivial et pas assez pour prendre une décision éclairée sur ce que fait le code, donc vous have à considérer son contexte. Si ce n'est pas votre code, vous devez regarder le code précédent pour le comprendre de toute façon.
Tout langage de programmation, pour être utile, doit permettre à certains types de mauvais code. Je doute qu'il soit possible de créer un langage de programmation qui n'a pas «permettre» un programmeur inexpérimenté pour faire toutes sortes de choses complètement horrible. Je ne pouvais arriver à des dizaines d'exemples de façons que l'Objective-C 1.0 "permet" de faire des choses mauvaises. Ce n'est pas un argument, c'est un exemple d'une ligne de code qui est mauvais d'être passer pour un argument. C'est malhonnête parce qu'il n'ya rien pour vous empêcher de créer des méthodes qui ressemblent à des getters, mais ne sont pas sans notation pointée. Il n'y a aucune contrainte de la langue au niveau de ce en Objective-C, et aucune vérification de la compilation pour cela indépendamment du fait que la notation à points est utilisé. Dot notation changements cela en aucune façon.
En fait, je trouve difficile de croire qu'un expérimentés en Objective-C programmeur même essayer cet argument parce que, franchement, ça sonne comme un argument que vous obtiendriez par un programmeur C + +. Objective-C est un langage permissif. C'est dans l'ADN Objective-C pour vous permettre de faire les choses. C'est faiblement typé et les poignées à l'exécution de nombreuses choses qui sont manipulés au moment de la compilation en C + + (et toutes les autres langues OO basé sur le modèle objet Simula). Ce sont des décisions de conception intentionnelle. Ce langage est conçu pour vous donner beaucoup de flexibilité et met la confiance dans le développeur que vous allez utiliser ses fonctionnalités de manière appropriée. Notation Objective-C de point n'est pas contraire à celui de la moindre. En fait, c'est un prolongement logique de cette philosophie sous-jacente. Ils failles notation pointée pour quelque chose qui est inhérent à l'Objective-C
Ces arguments contre la notation pointée dans le Guide de style de Google Objective-C sont des arguments illusoires. Le premier, n'est pas un argument du tout. La seconde repose sur des hypothèses qui sont fausses prouvable (que vous savez ce type d'une variable en regardant simplement sa ligne de code). Les deux autres sont fondées sur un programmeur quelque chose de mal et peut être démontré à la fois tout aussi facilement sans utiliser la notation à points.
Google souligne le fait que la notation à points est mauvaise parce qu'elle peut entraîner dans le code source de confusion quand un développeur ne prête aucune attention aux conventions de nommage établies ou fait des choix de conception vraiment pauvres. Mais ces problèmes n'ont rien à voir avec la notation point. Code mal écrit est mal écrit le code. Le simple fait de la question est, si vous essayez de lire du code comme ça, rien ne va aider. Avec ou sans notation par point, le code sera difficile à lire parce que c'est mauvais. La bonne solution dans cette situation est d'incendie ou de former le développeur qui a écrit le code incriminé.
Mais, il ya des façons dont la notation à points peut être utilisé pour rendre le code plus lisible. La façon dont je l'utilise (ramassés à partir du code de l'échantillon d'Apple) est d'utiliser les propriétés et la notation de points pour représenter l'état d'objet, et la notation crochets lors de l'appel des méthodes qui représentent le comportement ou déclencher des actions. En fait, on pourrait faire valoir que l'utilisation de la notation crochets à la fois pour l'état et le comportement a au moins autant de possibilités de confusion que d'utiliser la notation point fait. Prenez cette ligne de code, par exemple
Arguant contre laisser les gens utiliser la notation de points parce que certaines personnes vont prendre de mauvaises décisions est ignorant. C'est fondamentalement dire «je n'aime pas ça, alors vous ne devriez pas l'utiliser", et quand vous affirmez comme ça, ça sonne un peu idiote, n'est-ce pas?
- Lors du codage pour vous-même, faire ce que sent le droit de vous. Si vous n'aimez pas notation par point, ne l'utilisez pas, et ne se sentent pas comme vous devraient s'excuser de ne pas l'utiliser.
- Lors du codage d'un client ou un employeur qui a un guide de style de codage ou d'autres conventions de codage publié, utilisez ceux, même s'ils sont en désaccord avec votre opinion personnelle de la «bonne» façon de coder. Dans un environnement de programmation du groupe, la cohérence est extrêmement précieux.
Mon partenaire d'écriture illustres, Dave Mark tweeté aujourd'hui sur les Guide Google style Objective-C argument contre l'aide de notation pointée en Objective-C, Qui se lit comme suit:
Lorsque vous lirez ces derniers, ils sonnent plutôt logique, et peut-être même convaincant. Mais en réalité, ils ne sont pas logiques du tout. En fait, toute l'argumentation est essentiellement une série de sophismes logiques. Regardons les arguments spécifiques dans l'ordre et ensuite recoller les morceaux à la fin.
- Notation pointée est le sucre purement syntaxique pour les appels méthode standard, dont la lisibilité des gains sont discutables. Il vous donne juste une autre façon de faire des appels de méthode.
- Elle obscurcit le type que vous êtes le déréférencement. Quand on voit:
[foo setBar:1]il est immédiatement évident que vous travaillez avec un objet Objective-C. Quand on voitfoo.bar = 1il n'est pas clair si foo est un objet, ou un struct / union / classe C + +.- Il vous permet de faire des appels de méthodes qui ressemblent à des getters.
NSString *upperCase = @"foo".uppercaseString;qui n'est pas seulement déroutant, mais difficile à repérer dans une revue de code.- Il cache les appels de méthode.
bar.value += 10;est en fait deux appels de méthodes séparées (une pour régler et un pour obtenir) et si vos propriétés ne sont pas simples que vous pouvez trouver beaucoup de travail qui se fait de manière cachée.
Le premier argument: l'argument non
Notation pointée est le sucre purement syntaxique pour les appels méthode standard, dont la lisibilité des gains sont discutables. Il vous donne juste une autre façon de faire des appels de méthode.Ce premier "argument" ne contient aucun argument réel contre l'utilisation de la notation à points. La première partie de la première phrase est repris presque textuellement à partir Le langage de programmation Objective-C 2.0 sur le site d'Apple et est juste une reformulation (hors contexte) de la façon dont la notation à points est mis en œuvre.
La deuxième moitié de la première phrase est une tentative de remise d'un des avantages de la notation pointée par un simple rejet désinvolte sans preuve qu'il ou du soutien.
La deuxième phrase est tout simplement une tentative pour renforcer les arguments qui suivent en banalisant notation pointée comme "juste" quelque chose que nous pouvons déjà faire. C'est un peu comme dire que les réacteurs ne pas ajouter de valeur au cours des hélices parce qu'ils sont «juste» une autre façon de créer de poussée. Chaque construire dans tout langage de programmation qui est de niveau supérieur que l'assemblage est «juste» une autre façon de faire quelque chose que nous pouvons déjà faire. Cette phrase n'a aucune valeur sémantique ou logique, c'est tout simplement ici pour définir une tonalité négative envers l'utilisation de la notation pointée sans réellement offrir tous les faits ou les raisons de ne pas l'utiliser. Ce premier «argument» est la rhétorique, rien de plus.
Le second argument: l'Assomption invalide
Elle obscurcit le type que vous êtes le déréférencement.Cet argument rappelle les arguments pour Notation hongroise. L'argument de la notation hongroise est que lorsque vous regardez une variable, vous savez tout de suite ce qu'il est. En préfixant chaque variable avec un fouillis de lettres individuelles, chacune avec sa propre signification, vous savez (en théorie) tout ce qu'il ya à savoir sur cette variable juste en jetant un regard sur elle.
En réalité, vous ne voyez pas la notation hongroise beaucoup ces jours-ci. Les variables avec une signification sémantique - ceux qui utilisent des mots qui sont reconnaissables par et ont un sens pour le cerveau - fonctionnent beaucoup mieux. Nous ne connaissons pas le type spécifique de la variable, mais nous savons à quoi elle sert, ce qui est vraiment plus important.
Notation pointée ne «obscures» du type que vous êtes le déréférencement moins qu'il y ait une raison pour laquelle vous voulez savoir le type de regarder juste à cette ligne de code. Cet argument fait l'hypothèse que nous savons déjà et que nous devrions savoir ce que le type de foo est. Bien sûr, avec la notation crochets, nous savons que nous sommes face à un objet, mais nous ne savons pas quel type d'objet, il est de regarder à ce une ligne de code dans le vide.
Mais, quand pensez-vous jamais regardé une ligne de code dans le vide? Vous n'avez pas. Code n'a pas de sens hors contexte. Si il était vital que nous savons tout sur une variable de regarder hors de son contexte, alors nous serions tous en utilisant la notation hongroise. Pourtant, nous ne sommes pas.
Quelque part, probablement pas plus de quelques lignes ci-dessus
foo.bar = 1est soit une déclaration de foo ou le début de la méthode. Si vous êtes confus au sujet du type, généralement défilement vers le haut de quelques lignes peut résoudre cette confusion. Si cela ne fonctionne pas (parce que c'est une instance ou une variable globale, par exemple), commande double-cliquant dessus vous amènera à sa déclaration et alors vous saurez que son type.
Vous ne pouvez pas occulter quelque chose que vous n'avez pas de raison de connaître. La quantité d'informations que la notation crochets nous donne sur la notation à points est trivial et pas assez pour prendre une décision éclairée sur ce que fait le code, donc vous have à considérer son contexte. Si ce n'est pas votre code, vous devez regarder le code précédent pour le comprendre de toute façon.
Le troisième argument: le Red Herring
Il vous permet de faire des appels de méthodes qui ressemblent à des getters.Permet? Cet argument est qu'il est mauvais parce qu'il «permet» à faire quelque chose? Et ce qu'il vous permet de faire est de créer des appels de méthodes qui ressemblent à des getters? Quels sont les getters? Ils sont une sorte de méthode, non? Suis-je manqué quelque chose?
Tout langage de programmation, pour être utile, doit permettre à certains types de mauvais code. Je doute qu'il soit possible de créer un langage de programmation qui n'a pas «permettre» un programmeur inexpérimenté pour faire toutes sortes de choses complètement horrible. Je ne pouvais arriver à des dizaines d'exemples de façons que l'Objective-C 1.0 "permet" de faire des choses mauvaises. Ce n'est pas un argument, c'est un exemple d'une ligne de code qui est mauvais d'être passer pour un argument. C'est malhonnête parce qu'il n'ya rien pour vous empêcher de créer des méthodes qui ressemblent à des getters, mais ne sont pas sans notation pointée. Il n'y a aucune contrainte de la langue au niveau de ce en Objective-C, et aucune vérification de la compilation pour cela indépendamment du fait que la notation à points est utilisé. Dot notation changements cela en aucune façon.
En fait, je trouve difficile de croire qu'un expérimentés en Objective-C programmeur même essayer cet argument parce que, franchement, ça sonne comme un argument que vous obtiendriez par un programmeur C + +. Objective-C est un langage permissif. C'est dans l'ADN Objective-C pour vous permettre de faire les choses. C'est faiblement typé et les poignées à l'exécution de nombreuses choses qui sont manipulés au moment de la compilation en C + + (et toutes les autres langues OO basé sur le modèle objet Simula). Ce sont des décisions de conception intentionnelle. Ce langage est conçu pour vous donner beaucoup de flexibilité et met la confiance dans le développeur que vous allez utiliser ses fonctionnalités de manière appropriée. Notation Objective-C de point n'est pas contraire à celui de la moindre. En fait, c'est un prolongement logique de cette philosophie sous-jacente. Ils failles notation pointée pour quelque chose qui est inhérent à l'Objective-C
Le quatrième argument: manquant le point
Il cache les appels de méthode.Mais oui, oui il le fait. L'exemple de ligne de code soutenir cette "argument"
bar.value += 10;se traduira par exactement le comportement attendu si vous utilisez la notation de points pour représenter l'état d'objet. Si la valeur et setValue: méthodes sont autre chose que d'une paire accesseur / mutateur, alors ce qu'il est vrai que cette ligne de code pourraient entraîner des résultats inattendus, mais la faute en incombe non pas avec notation pointée, mais plutôt avec un programmeur qui a fait méthode extrêmement pauvres nommant choix, essentiellement couché sur le monde au sujet de leurs méthodes en ne respectant pas la convention de nommage pour les accesseurs et manipulateurs. Selon ce scénario, vous avez exactement le même problème avec cette ligne de code qui n'utilise pas de notation pointée:
[bar setValue:[bar value] + 10];En d'autres termes, cet argument est seulement un problème quand quelqu'un fait des choses mauvaises avec leur code, et il est tout autant d'un problème lorsque vous n'utilisez pas notation pointée.
Whoops! Il a été souligné dans les commentaires que je sorta manqué le point sur celui-ci, et que le "problème" est qu'il ya deux appels de méthodes quand quelqu'un qui ne comprenaient pas la notation à points pourrait raisonnablement penser n'y avait qu'un seul. Ma réponse à cette question est: et alors? Comment est-il un problème si le résultat est correct? Le code utilisé pour illustrer le problème sera d'atteindre les résultats que vous devriez raisonnablement s'attendre. Après la ligne de code, la valeur sera correcte. Le fait qu'il ya deux messages envoyés et pas un seul ne sera pas question dans la très grande majorité des situations. Ce qui compte, c'est que le résultat est correct, et dans l'exemple, il serait en supposant l'accesseur et mutateur sont correctement appliquées. Si vous rencontrez des problèmes de performance et de déterminer, par profilage que c'est causé par le message supplémentaire, alors vous optimisez en mettant en œuvre une méthode qui incrémente la valeur en un seul appel. C'est encore un non-problème.
Arguments Illusoire
La loi a un concept intéressant appelé une promesse illusoire (Ou état), qui est une promesse qui n'est pas vraiment une promesse à tous. C'est quelque chose qui ressemble à une promesse, et est rédigé dans la langue d'une promesse, mais qui n'est tout simplement pas une promesse.Ces arguments contre la notation pointée dans le Guide de style de Google Objective-C sont des arguments illusoires. Le premier, n'est pas un argument du tout. La seconde repose sur des hypothèses qui sont fausses prouvable (que vous savez ce type d'une variable en regardant simplement sa ligne de code). Les deux autres sont fondées sur un programmeur quelque chose de mal et peut être démontré à la fois tout aussi facilement sans utiliser la notation à points.
Google souligne le fait que la notation à points est mauvaise parce qu'elle peut entraîner dans le code source de confusion quand un développeur ne prête aucune attention aux conventions de nommage établies ou fait des choix de conception vraiment pauvres. Mais ces problèmes n'ont rien à voir avec la notation point. Code mal écrit est mal écrit le code. Le simple fait de la question est, si vous essayez de lire du code comme ça, rien ne va aider. Avec ou sans notation par point, le code sera difficile à lire parce que c'est mauvais. La bonne solution dans cette situation est d'incendie ou de former le développeur qui a écrit le code incriminé.
Comment je utiliser la notation Dot
Mais, il ya des façons dont la notation à points peut être utilisé pour rendre le code plus lisible. La façon dont je l'utilise (ramassés à partir du code de l'échantillon d'Apple) est d'utiliser les propriétés et la notation de points pour représenter l'état d'objet, et la notation crochets lors de l'appel des méthodes qui représentent le comportement ou déclencher des actions. En fait, on pourrait faire valoir que l'utilisation de la notation crochets à la fois pour l'état et le comportement a au moins autant de possibilités de confusion que d'utiliser la notation point fait. Prenez cette ligne de code, par exemple
[foo setIsOn:YES]Suis-je mise en état ou le déclenchement de comportement? Il pourrait être soit. Il pourrait être à la fois. Pour en être sûr, je dois vérifier la documentation de la méthode appelée. Si, d'autre part, j'ai utilisé la notation à points et les propriétés de séparer l'Etat des comportements, il est instantanément entendu que
foo.isOn = YES;est mise en état, mais
[foo turnOn];déclenche le comportement (qui peut, bien sûr, une incidence sur l'état). Oui, cela nécessite des choix de conception uniforme, mais tout le codage bon ne. Si vous jetez que comme une exigence, vous pouvez prétendre que tout est mauvais.
Arguant contre laisser les gens utiliser la notation de points parce que certaines personnes vont prendre de mauvaises décisions est ignorant. C'est fondamentalement dire «je n'aime pas ça, alors vous ne devriez pas l'utiliser", et quand vous affirmez comme ça, ça sonne un peu idiote, n'est-ce pas?
Aucun commentaire:
Enregistrer un commentaire