L'auteur recommande d'utiliser d'abord les métriques les plus simples :

• nombre de lignes de code (LOC)
• la forme du code (indentation)
• le couplage structurel (couplage de contenu - le module A modifie le contenu du module B - et couplage commun - les modules modifient des variables globales)
• le couplage logique

Les autres métriques (dont la complexité cyclomatique) peuvent être utiles si elles sont beaucoup trop grandes.

Dans cet article, l'auteur explique la relation entre cohésion et couplage. Pour paraphraser son résumé final :

• De par les limitations de notre cerveau pour appréhender des systèmes complexes, nous cherchons à modulariser notre base de code en parties indépendantes.
• Un module est un ensemble d'éléments qui devraient être autant liés entre eux (cohésion) que possible, avec une frontière nette entre "l'intérieur" et "l'extérieur".
• Les connexions entre les différentes frontières des modules devraient être réalisées via leurs interfaces, une manière contrôlée de communiquer à travers les frontières.
• La force du couplage de ces connexions dépend du nombre et de la complexité des interfaces des modules, la quantité et la nature des données échangées, et si les composants des modules changent souvent en même temps.
• Il y a plusieurs types de couplage, et de nouveaux sont toujours "découverts".
• Créer des modules cohérents est la meilleure manière d'éviter un couplage fort. Autrement dit, des modules faiblement couplés ont souvent une grande cohésion.
• Une cohésion imprécise ou de haut niveau devrait être évitée - il s'agit d'une cohésion artificielle (des bouts de code rassemblés en un même endroit bien qu'ils n'aient rien à voir). À la place, nous devrions tendre vers des modules dédiés à la résolution de problèmes métiers bien définis.
• Il est plus facile d'arriver à une grande cohésion fonctionnelle avec des modules mécaniques, tels que des modules dédiés à la résolution de problèmes mathématiques (ceux ci ont peu de chance de changer)

L'auteur part du constat d'un problème courant à beaucoup de bibliothèques de validation de formulaire : du code fortement couplé. Dans un premier article, il a présenté les bénéfices d'une séparation orthogonale des préoccupations, en développant un système de validation non restreint aux formulaires, et qui peut même fonctionner en dehors du DOM. Dans cet article, il parle des validateurs composés, comment récupérer les données d'un formulaire, et comment afficher les erreurs.

Le titre est un peu trompeur, l'auteur s'attache à démontrer les bienfaits d'un couplage faible. Il choisit comme cas particulier de s'attaquer à la validation des formulaires.