Le nommage d’une méthode doit toujours être explicite sur ses intentions, sur les actions qu’elle s’apprête à réaliser.
Un nom trop court aura du mal à faire transparaître les intentions, tandis qu’un nom trop long risque de nuire à la lisibilité et à la compréhension du code.
La longueur idéale d’un nom de méthode varie en fonction de son niveau dans la chaîne d'appels, autrement dit, du degré de contexte dont elle dispose et de son niveau de spécialisation dans le flot d’exécution.
En amont de la chaîne, les méthodes situées au début du traitement orchestrent des actions plus larges : elles manipulent des concepts globaux et déclenchent d'autres méthodes en cascade. Leur nom est souvent plus général et synthétique car elles condensent plusieurs intentions en une seule.
Il est très difficile de nommer précisément ce genre de méthode sans prendre le risque de devenir trop long et d'enchaîner les "and" et "or" sous peine de devenir illisible. De plus, le nom de ces méthodes doit exprimer le service rendu et non énumérer toutes les actions sous-jacentes qui n’apportent rien à la compréhension de son intention.
Au fur et à mesure que l’on progresse dans la chaîne, les méthodes deviennent plus spécifiques. Chacune opère dans un cadre plus restreint, réalise une tâche plus ciblée et dispose de plus de contexte. Cela permet, et souvent exige, un nom plus descriptif car l’intention peut être exprimée avec davantage de précision.
Ce raisonnement s’applique tout au long de la chaîne d’exécution : plus une méthode est en bout de chaîne, plus son nom est susceptible d’être long, détaillé et représentatif de sa fonction exacte. À l’inverse, les méthodes plus en surface peuvent sacrifier un peu de précision au profit d’une meilleure lisibilité d’ensemble.