Des normes pour lire du code à haute voix?

Quelqu'un a-t-il défini une norme pour lire le code à haute voix, pour n'importe quelle langue? J'imagine que c'est important pour les logiciels comme les lecteurs d'écran pour les malvoyants. Ce genre de chose se produit également lorsque vous discutez du code avec quelqu'un, le révisez en groupe ou enseignez une classe.

Dans la famille des langues C, il y a beaucoup de mots avec des prononciations "évidentes". Certains sont simplement des mots anglais: for, break, case, default, etc. Certaines abréviations, comme int, sont sans ambiguïté. Et puis il y a char.

J'ai toujours tendance à le dire (et à l'entendre dans ma tête) comme la première syllabe de "charbon de bois". C'était choquant pour moi la première fois que je parlais de code avec quelqu'un qui le prononçait comme "voiture", ce qui est en fait plus logique car charc'est vraiment une abréviation du mot "caractère", donc clairement il devrait être prononcé de la même manière. Mais même en sachant cela, le charbon de bois me semble plus juste.

Et puis il y a des déclarations comme foo = bar ? *(++baz) : zardoz.

Quelqu'un a-t-il produit un document dictant la manière correcte (à leur avis) de lire le code à haute voix? Soit pour une langue spécifique, soit pour du code en général?

Combinaison rapide: lisez cet excellent article sur Coding Horror

Chaque fois que je parle de code par téléphone, je ne le lis jamais littéralement. Vous devez le "compiler" à l'homme, et s'il y a encore de la confusion à l'autre bout de la ligne, vous pouvez vous diriger vers une lecture plus littérale. Par exemple, je lirais votre exemple comme

"Si la barre est vraie, incrémentez le pointeur baz et affectez la valeur à cette adresse à foo. Sinon, définissez foo sur zardoz."

Je suis un télétravailleur à temps plein depuis le milieu des années 90, donc pratiquement toutes mes interactions avec mes collègues se sont faites par téléphone ou par d'autres moyens indirects. Très souvent, nous partageons une session écran (terminal) ou VNC (X). Outre la camaraderie régulière, nous passons toute la journée à parler de code, de conception, de planification, etc.

Lorsque nous parlons de code, nous utilisons un jargon profondément lié au type de projet en cours de réalisation. L'une des (nombreuses) raisons pour lesquelles un nouveau membre du groupe met tellement de temps à devenir pleinement fonctionnel est qu'il apprend essentiellement une nouvelle langue à chaque fois qu'il rejoint un nouveau département / entreprise.

Comme je l'ai dit plus haut, et comme d'autres l'ont dit, nous essayons de parler au niveau le plus élevé possible pour toute discussion. Mais parfois, il faut vraiment dire à quelqu'un: "Tapez ceci"

Comment le dis tu? Eh bien, nous pourrions simplement donner une énumération comme ...

~  tilde
`  backtick
'  single quote
"  quote (or double quote)
/  slash, \ is backslash
#  pound or hash
!  bang (or exclamation mark)
@  at
$  dollar
%  percent or mod
^  caret or xor
&  and or bitwise and
&& and or logical and
|  pipe or 'or' or bitwise or
|| 'or'
*  value of, times, glob, multiplied by
() parens, open paren, close paren
{} braces, curlies, open stash, close stash
[] brackets, square brackets, at & sub (for subscript) (for C-ish arrays)
...

C'est ainsi que «nous» disons ces personnages. Pour avoir une idée de la gamme complète des mots "#", jetez un œil à la page wiki de #

Il y a donc trop de variabilité. Il doit être spécifique à la langue dans laquelle vous codez (tout comme je le tape en anglais pour notre communication humaine).

Sans le contexte de la langue, vous devrez constamment revenir à l'orthographe caractère par caractère. Donc, la plupart des gens que je connais se replient sur ce que la norme linguistique appelle.

SELECT COUNT(*) INTO x FROM ...   (SQL)
X IS Y + 1                        (Prolog)
(setq x 40)                       (Emacs lisp)
/def x 40                         (PostScript)
x = 40                            (C)
$x = 40                           (Perl)

Chacun de ceux-ci serait implicite en disant simplement "Set X to ..." dans le contexte approprié. Ne me lancez même pas sur le code lu comme "la chaîne X est-elle égale à la chaîne Y".

Si vous dites "hash bang bin bash" ou "shebang bash", presque tout le monde saura que cela signifie "#! / Bin / bash". S'ils ne le font pas, ils diront "Huh?", Et vous descendez d'un cran "En haut du fichier: signe dièse, point d'exclamation, barre oblique, corbeille, barre oblique, bash, nouvelle ligne". S'ils ne l'obtiennent toujours pas, vous le redescendez encore une fois: "Voir ce clavier devant vous? Voir la touche" 3 "? Cette marque en haut lorsque vous appuyez sur Maj est un signe dièse, ça."

Conclusion:

• ne vous en faites pas trop, vous vous tromperez, tout le monde s'en remettra
• c'est trop spécifique pour exactement ce que vous faites
• portez toujours une serviette
• lire l'article sur Coding Horror

Je n'ai jamais rencontré de normes pour parler la syntaxe du langage à haute voix. J'ai rencontré de petits extraits où quelqu'un a exprimé sa préférence personnelle, par exemple en faisant référence à "#! / Bin / sh" comme "Hash-bang slash bin slash SH" par opposition à "pound exclamation forward-slash BIN forward-slash SH "le dernier pourrait supposer que l'auditeur a moins de familiarité avec la construction.

Il existe également une grande disparité dans la mesure dans laquelle les différentes langues sont lisibles à haute voix. Prenez par exemple les différences entre Python qui a tendance à être plus facile à dire à haute voix que Perl, ce qui vous oblige à dire beaucoup de ponctuation ou à traduire de "$ var [20]" en "vingtième élément du tableau var".

Ma propre expérience est que c'est très contextuel basé sur la raison pour laquelle j'ai besoin de lire le code à haute voix, le niveau de connaissance de l'auditeur et la langue en question.

Dans le cas des révisions de code, je suis plus susceptible d'expliquer une déclaration que d'essayer de la lire à haute voix, car il est généralement plus important de faire comprendre le sens ou le processus de réflexion que de simplement lire le code brut aux auditeurs.

Lorsque j'essaie de demander à quelqu'un de taper une ligne exacte de code C dans un éditeur (par exemple, je regarde par-dessus l'épaule d'un programmeur junior et je vois comment corriger une ligne de son code), je finis souvent par prononcer du code dans les mots-clés et les symboles tels que "si l'espace open-paren null double est égal à p close-paren ..." Ce même échange avec un développeur plus avancé pourrait commencer plus comme "vous devez vérifier si p est nul ici ... "

Parler de code est l'un de ces moments où le pseudo-code devient extrêmement pratique.

Si quelqu'un commence à me donner du code par le personnage, alors je vais juste lui dire de m'envoyer un email et je lui ferai savoir ce que je pense.

Réponse courte

La chose la plus proche d'un guide de prononciation standard semble être l'entrée pour "ASCII" dans The Hacker's Dictionary (aka The Jargon File ). Il contient un tableau dérivé de la "révision 2.3 du guide de prononciation Usenet ASCII" qui n'est plus facilement détectable en ligne. Il y a un fil de discussion pertinent, " Nommez ce personnage! " comp.miscEn mai-juin 1991, qui attribue à Maarten Litmath le maintien du document original. Le fil note que les noms «plus intelligents» tels que «Donald Duck» pour «&» ont été omis du document plus récent.