Contrats le côté pratique de la sémantique

Nous reconnaissons tous que nous devrions écrire du code sémantique. Peut-être que vous utilisez même

ou correctement et se sentir bien dans sa peau. Mais considérez-vous également le contrat implicite qui existe lorsque vous codez?

Imaginons qu'un client demande un lien de texte, "Voir plus,”Qui devrait révéler du texte supplémentaire sur la page. voir plus avec un gestionnaire de clics devrait fonctionner parfaitement, non? Hé, il ressemble et fonctionne comme demandé!

Non, cela ne fonctionnera pas toujours correctement car cela violerait le contrat entre vous et le navigateur. En particulier, je me réfère à celui qui dit le href attribut doit avoir une valeur qui est une URL valide.

Il y a des problèmes pratiques qui peuvent survenir lors de la violation de contrats, et ce sont de bien meilleures raisons pour écrire du code sémantique que des choses auxquelles vous pensez habituellement lorsque vous entendez le terme «sémantique».


Arguments populaires pour le code sémantique

Il y a cependant beaucoup plus de raisons pratiques de s’occuper de la sémantique: les contrats.

Si vous demandez à un développeur moyen quelle est la valeur du code sémantique, vous entendrez probablement quelque chose comme:

  • Il assiste les handicapés
  • Décrire correctement le code facilite l’interprétation des machines

Malheureusement, les deux sont très faciles à négliger. «Les aveugles et les robots ne sont pas le public cible» est une réponse trop simple, peu importe la façon dont elle est mal dirigée ou ignorante.

Dans d'autres cas, vous pouvez même entendre un raisonnement cyclique, tel que "le code non sémantique est mauvais, car il n'a pas de sens."!

Il y a cependant beaucoup plus de raisons pratiques de s’occuper de la sémantique: les contrats.


Contrats d'utilisation

Chaque fois que vous utilisez des fonctionnalités fournies par des éditeurs de navigateurs, votre langage de programmation ou une API, vous faites appel à un contrat..

Un fournisseur de fonctionnalités figure sur un côté du contrat. Par exemple, lorsque vous utilisez un tag, les développeurs de navigateur vous promettent qu’ils fourniront un moyen simple pour l’utilisateur de votre application d’accéder à l’URL spécifiée..

Comme toujours, cependant, il y a l'autre côté de ce contrat. L'implémenteur de la fonctionnalité promet d'utiliser la fonctionnalité telle que spécifiée. Dès qu’il utilise cette fonctionnalité à mauvais escient, tous les paris sont ouverts, ce qui risque d’échouer.

Contrats de fonctionnalité du navigateur

Revenons à la "Voir plus”Exemple de plus tôt. Dans les premiers jours de JavaScript, les développeurs écrivaient leur code JavaScript à l'aide d'un pseudo protocole., javascript:

 Voir plus

Assez rapidement, ils ont commencé à se rendre compte que cette approche présentait au moins un défaut pratique: le code JavaScript est affiché dans la barre d'état du navigateur, ce qui n'a pas l'air professionnel. La réponse à ce dilemme était de déplacer le code vers un sur clic gestionnaire, et remplacer le href attribut avec un identifiant de hachage vide, comme suit:

 Voir plus

Bien sûr, cela n'a pas tout résolu. Si Montre plus a une erreur, retourne faux n'est jamais appelé et la page défile jusqu'en haut - comportement certainement pas souhaité.

Aujourd'hui, les développeurs séparent leurs codes HTML et JavaScript et utilisent les techniques appropriées de prévention des événements:

 Voir plus
 $ ('a.show-more'). on ('click', function (event) event.preventDefault (); ShowMore (););

Mais devinez quoi? Cette approche pose encore de nombreux problèmes: l'ouverture dans un nouvel onglet, la mise en signet ou la copie du lien ne fonctionne pas comme l'utilisateur pourrait s'y attendre (surtout s'il y a une balise sur la page), ce qui entraîne une confusion et éventuellement un client perdu.

Remarquez comment tous les problèmes décrits jusqu'ici sont nés d'un seul fait. Les développeurs ont violé leur part du contrat avec les fabricants de navigateurs: href L'attribut doit contenir une URL correcte, mais les développeurs inséraient toutes sortes d'ordures..

Si nous essayons de nous conformer à notre contrat, nous devons nous demander: "Pourquoi le contrat ne nous permet-il pas de faire ce dont nous avons besoin?" La réponse est simple: nous abusons du étiquette. Nous ne l'utilisons que parce que nous voulons le texte “Voir plus”Pour apparaître et se comporter comme un lien. Cependant, lorsque nous utilisons des mots tels que "look" et "apparaitre", n'est-ce pas le domaine du CSS? Est-ce pas "Voir plus"lien, en réalité, juste un bouton? C'est facile à mettre en œuvre:

 
 $ ('button.show-more'). sur ('cliquez', ShowMore);
 a, .link-style color: @ your-shade-of-blue; texte-décoration: souligné;  .link-style font: inherit; fond: aucun; bordure: aucune; curseur: pointeur; 

Indépendamment du nombre de nouvelles façons d’interagir avec les liens qui sont ajoutées aux itérations futures des navigateurs, cette approche continuera de fonctionner, car nous ne violons aucun contrat avec le navigateur. Nous utilisons des éléments pour communiquer leur signification et, au lieu de travailler constamment autour de nouveaux problèmes, nous savons que le navigateur les traitera correctement. comprend ce que nous voulons.

Bien sûr, il faudra peut-être quelques lignes supplémentaires de CSS pour réinitialiser le style des boutons par défaut. Ça en vaut la peine! Ne soyez pas paresseux.

Spécifications sous forme de contrats

… Ceux qui connaissaient la sémantique et les ignoraient sciemment.

En 2005, une grande partie de la communauté du développement Web a appris à ses dépens qu’ignorer les exigences HTTP était une mauvaise chose. Google Accélérateur Web nouvellement publié effectue une pré-extraction des URL sur une page afin de minimiser le temps d'attente de l'utilisateur lors d'un clic..

Cela a causé des ravages dans les applications, qui ignoraient HTTP et plaçaient des opérations destructrices derrière des liens simples. Et il y avait beaucoup de telles applications.

Le problème n'était pas entre les mains des développeurs qui ne comprenaient pas la sémantique des méthodes HTTP. Non, le problème venait de ceux qui connaissaient la sémantique, les ignoraient sciemment et ne partageaient pas les connaissances..


Contrats de maintenance

Le code déroutant est mauvais!

Des contrats existent également entre développeurs. Chaque fois que vous écrivez une ligne de code, vous promettez aux futurs développeurs de faire exactement ce que cela semble être. En d'autres termes, le code source de confusion est mauvais!

Par exemple, en utilisant une fonction de filtrage (telle que filtre en Python), boucler sur les éléments est incorrect, car il existe un contrat implicite selon lequel les fonctions de filtrage ne modifient que la liste, sans aucun effet secondaire:

 def show (item): print (item) fruits = ['orange', 'apple', 'citron'] filtre (show, fruits) # Utilisation incorrecte du filtre

À la place, utilisez une boucle explicite sur une liste:

 def show (item): print (item) fruits = ['orange', 'pomme', 'citron'] pour les fruits dans les fruits: show (fruit)

Par contre, si vous pouvez vous fier à un contrat, cela vous permet de clarifier votre code. Par exemple, en utilisant tableau_filtre au lieu d'une pour boucle en PHP pour filtrer les éléments permet aux autres développeurs de comprendre ce qui se passe après un seul coup d'œil:

 $ revenus = [20, 15, -7, 19]; $ profits = array_filter ($ revenus, fonction ($ i) retour $ i> 0;);

Comparez l'extrait ci-dessus pour utiliser un pour boucle:

 $ revenus = [20, 15, -7, 19]; $ profits = []; foreach ($ revenus en $ i) si ($ i> 0) $ profits [] = $ i; 

La deuxième version est pire, non seulement parce qu’elle est plus longue, mais aussi parce que tableau_filtre fournit une attente. Il est clair que $ profits est un sous-ensemble de $ revenus. Il n'y a pas une telle convention avec un générique pour boucle, ce qui explique pourquoi nous ne pouvons faire aucune hypothèse sans déchiffrer d’abord les éléments internes de la boucle.


Écrire correctement le code sémantique

Comment faites-vous la distinction entre le code qui est et non sémantique? Comment remarquez-vous ces contrats? Pour la plupart, se poser simplement des questions devrait suffire.

Balises HTML

«J'utilise un tag et je dois mettre quelque chose dans un href attribut. href stocke la destination cible du lien. Alors, d'où vient mon tag link to? ”Nulle part? Eh bien, je peux alors en conclure que j’utilise probablement cette balise.

Fonctions nommées

“Je dois imprimer le contenu de ma liste dans un format filtre une fonction. L'impression d'éléments fait-elle partie du processus de filtrage? ”Pas vraiment. Cela signifie que j'utilise mal filtre.

Des fonctions qui font trop

«J'écris un getFoo méthode, et besoin d'ajouter un code de modification en son sein. Est-ce que la modification d'état a un sens dans le fait de devenir foo? Est-ce que quelqu'un qui veut simplement être foo s'attend à ce que quelque chose d'autre se passe?!

Séparation des préoccupations

“Je veux ajouter du JavaScript dans un fichier HTML sur clic attribut. Est-ce correct? "Le fichier que vous modifiez est .html, droite? Au lieu de cela, placez votre JavaScript et CSS dans .js et .css fichiers, respectivement. Toujours.

Bien sûr, dans de nombreux cas, des connaissances supplémentaires peuvent être nécessaires pour évaluer correctement la situation. Le plus important est de commencer à réfléchir à ces choses et d’éviter le principe "il (un peu) fonctionne, donc c'est assez bien."Au lieu de cela, demandez-vous toujours:" Que signifie réellement le code que j'écris? "


Conclusion

La violation d'un contrat garantit la rupture de la coopération.

La coopération dépend toujours des efforts des deux parties. La majeure partie du développement de logiciels se réduit à une coopération: coopération entre les fabricants de matériel, les programmeurs système, les développeurs de navigateurs, les auteurs de bibliothèques, les développeurs de sites Web et bien d’autres. La violation d'un contrat garantit la rupture de la coopération.

La sémantique des codes est l'un de ces contrats. Prenez soin de vous pour votre bien!


Notes de bas de page

Sémantique: Le terme «sémantique» est souvent mal compris. Dans le contexte de cet article, j’utilise le terme pour distinguer le signification du code du résultats produits par le code. Par exemple, la signification sémantique d’un la balise est représentation d'un lien, tandis que le sens simple et pratique est texte cliquable et souligné.

Strictement parlant, un identifiant de fragment vide # pourrait être considéré comme valable dans ce contexte. Cette technicité, cependant, manque le point que je fais dans l'article.