La dactylographie pour les programmeurs : symboles, chiffres et la vitesse qui compte

Pourquoi le WPM en prose reflète mal la frappe de code

Le code diffère du texte de trois façons, et un test de frappe composé de mots anglais courants ne mesure aucune d'entre elles.

La première est le mélange de caractères. Nous avons compté. Sur les dix premiers articles de ce blog, environ 93 caractères sur 100 (hors espaces) sont des lettres, 5 sont de la ponctuation et 2 des chiffres. Dans le code source JavaScript de l'outil en ligne de commande de npm, les lettres tombent à environ 80 et les symboles montent à 19. Les modules json et email de Python donnent 80 à 85 lettres, et un de nos scripts de build très dense en donne 64, avec un tiers de symboles. Le code contient donc environ trois à sept fois plus de symboles que notre prose. La plupart se trouvent sur la rangée du haut ou demandent Maj, ce qui sollicite l'auriculaire droit et les déplacements les plus difficiles. Nos tests de mots en anglais sont construits à partir des 1 000 mots les plus courants d'un corpus de sous-titres ; « { » n'en fait pas partie.

La deuxième est le rythme. La prose se tape en longues séquences. Le code se tape en courtes rafales entrecoupées de pauses pour réfléchir, faire défiler et lire. Les volontaires de l'étude de Dhakal et al. de 2018 portant sur 136 millions de frappes, qui recopiaient des phrases, mettaient en moyenne environ 239 ms entre deux touches. La journée d'un programmeur est pleine de pauses de plusieurs secondes, et la vitesse de rafale dans les courtes séquences compte plus que n'importe quelle moyenne.

La troisième est l'éditeur. Avec l'autocomplétion, les snippets et les raccourcis clavier, un programmeur au travail ne tape qu'une fraction des caractères affichés à l'écran. Aucun test de frappe ne peut mesurer cela, et le nôtre ne prétend pas le faire.

La vitesse de frappe est-elle importante pour programmer ?

Moins qu'on ne le pense, et pas là où on l'attend. Quand quelqu'un demande si 60 WPM suffisent pour être programmeur, la réponse est oui, avec une réserve : si vous baissez les yeux pour trouver les symboles et les chiffres, ce n'est pas à 60 WPM que vous tapez du code. Pouvoir taper une ligne sans perdre le fil de sa pensée compte plus que la vitesse brute, et c'est le fait de regarder le clavier qui fait perdre ce fil.

Comment taper les symboles plus vite, et pourquoi personne ne l'enseigne

Une question revient sans cesse sur les forums de dactylo : quelqu'un sait taper les lettres à l'aveugle à une vitesse correcte, mais dès qu'il se met à coder, il recommence à chercher les symboles, les chiffres et même les majuscules, et il voudrait une méthode progressive pour les apprendre, comme il a appris les lettres, quelques touches à la fois.

Une partie de la difficulté des symboles vient de Maj. Dans le code source de npm que nous avons analysé, environ 45 % des frappes de symboles étaient des caractères obtenus avec Maj, comme ( ) { } : et $, soit près de 9 caractères sur 100 (hors espaces) avant même de compter une seule majuscule. Corrigez donc d'abord votre habitude avec Maj : appuyez sur Maj avec la main qui ne tape pas le caractère. ( et ) se trouvent sur le 9 et le 0, côté main droite, donc ils prennent la touche Maj gauche ; ! @ # $ sont côté main gauche, donc ils prennent la touche Maj droite. La plupart des autodidactes utilisent la touche Maj gauche pour tout, et pour ! cela oblige l'auriculaire gauche à appuyer sur deux touches à la fois. Vérifiez votre propre habitude en tapant une ligne contenant @ et $, et regardez quel auriculaire bouge.

Les symboles sont difficiles à travailler isolément, et ennuyeux à travailler tout court : les lettres viennent avec les mots, les crochets avec le code, et du code aléatoire n'a aucun intérêt. Notre réponse consiste à travailler les symboles sur de vraies lignes de code, une famille à la fois.

Une famille à la fois

Voici l'ordre que nous suivrions, et l'ordre du parcours de symboles que nous préparons pour la page d'entraînement. En attendant sa sortie, vous pouvez faire la même chose en collant du vrai code dans le mode personnalisé, une famille de symboles à la fois, sans passer à la suivante tant que la famille en cours n'atteint pas 95 % de précision :

• Les chiffres. La rangée des chiffres, avec les doigts de la rangée de repos qui montent l'atteindre. Elle vient en premier parce que c'est la famille non alphabétique la plus utilisée, et parce que presque tout le monde a une mauvaise habitude ici, comme l'index qui tape 4, 5, 6 et 7. Le test des chiffres permet une vérification rapide.
• Les parenthèses, crochets et accolades par paires. ( ) d'abord, puis [ ], puis { }. Par paires, parce qu'on ne tape presque jamais l'un sans l'autre : dans ce code source de npm, ( apparaît 6 195 fois et ) 6 194 fois. C'est en entraînant le geste d'ouverture et de fermeture comme une seule unité qu'il devient rapide. Le symbole fermant est l'endroit où le rythme de la plupart des gens se casse.
• Les opérateurs. = + - * / et les chevrons, plus les formes composées (==, =>, +=, !=). Ils sont répartis entre la rangée des chiffres et les touches de ponctuation de la main droite, et plusieurs demandent Maj sur la même main, ce qui est la partie délicate.
• Les guillemets et la ponctuation. ' " ; : , . avec l'auriculaire droit qui fait l'essentiel du travail. C'est sur les points-virgules et les deux-points que les programmeurs de la famille C et ceux de Python diffèrent le plus : entraînez-vous donc sur des lignes du langage que vous utilisez.
• Le shell et les cas à part. La barre verticale, la barre oblique inverse, le tilde, l'accent grave, l'accent circonflexe, l'esperluette, le dièse, le dollar, l'arobase et la touche _. Le _ et l'accent grave surprennent la plupart des gens ; le code en snake_case utilise _ en permanence, et la plupart des dactylos le frappent avec le mauvais doigt.

Chaque famille demande à la plupart des gens une semaine ou deux de séances de dix minutes, donc le parcours complet prend deux à trois mois. C'est plus lent que l'apprentissage des lettres, parce que les touches de symboles sont plus éloignées et que les habitudes à remplacer sont plus anciennes.

Ce qui tourne mal, d'après ce que montrent les statistiques par touche : les gens apprennent le symbole avec le bon doigt, puis reviennent à l'ancien geste sous la pression, parce qu'il reste plus rapide pendant quelques semaines. Les statistiques le montrent sous la forme d'une touche dont l'intervalle varie énormément, rapide quand vous l'atteignez correctement et lente quand ce n'est pas le cas. La solution est de rester une semaine de plus sur cette famille.

Les paires de crochets et la fermeture automatique

Les éditeurs ferment automatiquement les parenthèses et crochets, ce qui soulève une question légitime : pourquoi apprendre à taper le symbole fermant ?

Pour deux raisons. La fermeture automatique n'est pas constante : elle se déclenche à certains endroits et pas à d'autres, comme un terminal ou une fenêtre de discussion. Un dactylo qui compte sur elle hésite à chaque fois pour vérifier si elle s'est déclenchée, et cette hésitation coûte plus cher que la frappe. Et taper par-dessus un symbole fermé automatiquement (appuyer sur « ) » alors que l'éditeur en a déjà inséré une) est en soi une frappe : vous tapez donc le symbole fermant de toute façon.

Quand vous collez du code dans le mode personnalisé ici, le texte est découpé selon les espaces : l'indentation disparaît et chaque élément devient un mot. C'est à la fois une limite et une commodité : vous ne tapez pas quatre espaces au début de chaque ligne de Python, mais vous ne les travaillez pas non plus. Un vrai mode code qui gère l'indentation et les paires fermées automatiquement comme le fait un éditeur est dans notre liste, et c'est plus difficile qu'il n'y paraît.

Vitesse sur du code et vitesse sur de la prose

Nous n'avons pas assez de résultats en mode code pour publier des centiles, et nous préférons attendre plutôt que de les inventer. Dans nos propres essais, la vitesse sur un extrait de code réaliste se situait entre la moitié et les deux tiers environ de la vitesse en prose de la même personne, et ce rapport s'améliore davantage avec un entraînement aux symboles qu'avec un entraînement général.

Le chiffre qui, lui, se transpose, c'est la précision. Un programmeur qui tape de la prose à 97 % de précision et du code à 90 % a un problème avec les symboles, et la carte de chaleur des touches montre exactement lesquels. Un programmeur à 97 % sur les deux a simplement besoin de taper plus de code. Notre méthode de calcul des scores explique comment la précision compte les erreurs corrigées.

Comme référence standard, le test de ponctuation avec les chiffres activés est, parmi nos modes habituels, le plus proche du code. Il n'aura pas d'accolades, mais il fait intervenir la touche Maj et la rangée des chiffres, et pour la plupart des gens, c'est là que se trouve l'écart.

Les choix de clavier qui aident

Les conseils de clavier donnés aux programmeurs portent surtout sur les switchs, et passent surtout à côté de l'essentiel.

La disposition compte plus que le switch. Dvorak fait monter les crochets sur la rangée des chiffres et déplace la plupart de la ponctuation. Colemak et Workman gardent les crochets là où les place le QWERTY, mais tous deux déplacent le point-virgule à l'emplacement du P en QWERTY, ce que les programmeurs de la famille C sentiront passer. L'article sur les dispositions de clavier en donne la version longue.

Une couche de symboles vaut mieux qu'un clavier plus grand. Beaucoup de claviers séparés et compacts permettent de placer les crochets et les opérateurs sous les doigts de la rangée de repos, sur une couche activée en maintenant une touche du pouce. De tous les changements matériels que décrivent les programmeurs, c'est celui que nous essaierions en premier, parce qu'il signifie que vous ne baisserez plus jamais les yeux pour trouver un symbole.

ISO ou ANSI. Sur les claviers ISO (Royaume-Uni et la majeure partie de l'Europe), la touche supplémentaire à côté de Maj gauche et la haute touche Entrée changent l'emplacement de la barre oblique inverse et de la barre verticale. Si vous vous entraînez sur l'un et travaillez sur l'autre, votre auriculaire ratera sa cible. C'est pour cette raison que notre émulation propose les deux variantes de Colemak-DH.

Les switchs n'ont presque aucun effet sur la vitesse. Les switchs linéaires, tactiles et clicky diffèrent par la sensation et le son, et le journal des frappes ne sait pas sur lequel vous avez appuyé. Notre article sur les claviers mécaniques passe les chiffres en revue.

Le son aide certaines personnes en leur donnant un retour : le son d'erreur vous signale qu'un symbole était faux sans que vous baissiez les yeux. Activez-le pendant que vous apprenez les symboles.

Une séance de dix minutes pour programmeur

Ce que nous ferions chaque jour pendant les deux ou trois mois que prend le parcours des symboles :

• Deux minutes : un test de mots de 30 secondes pour s'échauffer, avec une précision de 97 %.
• Six minutes : la famille de symboles en cours, sur un texte personnalisé collé depuis votre propre code. Arrêtez-vous au premier signe de retour à l'ancien doigt.
• Deux minutes : un extrait de code dans le langage que vous utilisez le plus. Regardez ensuite la carte de chaleur des touches, pas le WPM.

Les jours où vous n'avez pas dix minutes, tapez vous-même le symbole fermant. C'est la plus petite habitude de cet article, et généralement la première à porter ses fruits.

Questions fréquentes

Quelle est une bonne vitesse de frappe pour un programmeur ?

Tout ce qui dépasse environ 40 WPM est suffisant si vous tapez les symboles et les chiffres à l'aveugle. Au-delà, le goulet d'étranglement, c'est la réflexion, la lecture et la maîtrise de l'éditeur, pas la vitesse des doigts.

Comment apprendre à taper les chiffres à l'aveugle ?

Entraînez-vous sur la rangée des chiffres seule jusqu'à ce que la précision se maintienne à 95 %, en utilisant pour chaque chiffre le doigt qui se trouve juste en dessous sur la rangée de repos, puis mêlez des chiffres à du texte normal.