큰 소리로 코드를 읽는 표준?

누구든지 어떤 언어에 대해서도 큰 소리로 코드를 읽는 표준을 정의 했습니까? 나는 이것이 시각 장애를 가진 스크린 리더와 같은 소프트웨어에 중요하다고 생각합니다. 이런 종류의 일은 누군가와 코드를 토론하거나 그룹에서 코드를 검토하거나 수업을 가르 칠 때도 나타납니다.

C 언어 군에는 "명백한"발음이있는 단어가 많이 있습니다. 일부는 단순히 영어 단어 : for, break, case, default, 등 일부 약어, 같은 int모호하다. 그리고는 char입니다.

나는 항상 "차콜"의 첫 음절처럼 말하고 머리에서 듣는 경향이 있습니다. "car"와 같이 발음 한 사람과 코드에 대해 이야기 할 때 처음으로 저를 괴롭 혔습니다. 실제로 char"character"라는 단어의 약어 이기 때문에 실제로 더 의미 가 있으므로 명확하게 동일하게 발음해야합니다. 그러나 그것을 알고, 석탄으로 숯불이 더 나에게 느낌이 듭니다.

그리고 다음과 같은 진술이 foo = bar ? *(++baz) : zardoz있습니다.

누구든지 코드를 소리내어 읽는 방법을 올바른 방식으로 설명하는 문서를 작성한 사람이 있습니까? 특정 언어 또는 일반적인 코드가 있습니까?

빠른 작업복 : 코딩 공포에서이 위대한 기사를 읽으십시오

전화로 코드를 논의 할 때마다 문자 그대로 읽지 않습니다. 당신은 그것을 인간에게 "컴파일"해야하며, 줄의 다른 쪽 끝에 여전히 혼란이 있다면, 당신은 좀 더 문자 적으로 읽을 수 있습니다. 예를 들어, 나는 당신의 예를 다음과 같이 읽었습니다.

"bar가 true이면 baz 포인터를 증가시키고 해당 주소의 값을 foo에 할당하십시오. 그렇지 않으면 foo를 zardoz로 설정하십시오."

나는 90 년대 중반부터 전일 재택 근무를 했으므로 실제로 동료와의 모든 상호 작용은 전화 나 다른 간접적 인 수단을 통해 이루어졌습니다. 우리는 종종 스크린 (터미널) 또는 VNC (X) 세션을 공유합니다. 일반적인 동지애 외에 우리는 하루 종일 코드, 디자인, 계획 등에 대해 이야기합니다.

코드에 대해 이야기 할 때 우리는 작업중인 프로젝트의 유형과 밀접한 관련이있는 전문 용어를 사용합니다. 새로운 그룹 구성원이 완전히 기능하는 데 오랜 시간이 걸리는 이유 중 하나는 새로운 부서 / 회사에 가입 할 때마다 본질적으로 새로운 언어를 배우기 때문입니다.

위에서 말했듯이 다른 사람들이 말했듯이 우리는 모든 토론에 적절한 수준으로 말하려고 노력합니다. 그러나 때때로 누군가에게 다음과 같이 말해야합니다.

어떻게 말합니까? 글쎄, 우리는 다음과 같은 열거를 줄 수 있습니다 ...

~  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)
...

이것은 우리가이 문자들을 말하는 방식입니다. "#"의 전체 범위에 대한 아이디어를 얻으려면 Wiki 페이지에서 #을 살펴보십시오 .

가변성이 너무 많습니다. 코딩하려는 언어에만 적용되어야합니다 (인간 커뮤니케이션을 위해 영어로 입력하는 것처럼).

언어의 맥락이 없다면 문자 철자법을 사용하여 끊임없이 문자로 되돌려 야합니다. 그래서 내가 아는 대부분의 사람들은 언어 표준이 무엇을 호출 하든지 무엇이든 되돌아갑니다.

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)

적절한 문맥 내에서 "Set X to ..."라고 말하면 각각이 암시됩니다. 하지 마십시오 심지어 날과 같이 어떤 코드를 시작하는 "문자열 X 문자열 Y 같다".

"hash bang bin bash"또는 "shebang bash"라고 말하면 거의 모든 사람들이 "#! / bin / bash"를 의미합니다. 그들이 "Huh?"라고 말하지 않으면 "파일의 맨 위에는 파운드 기호, 느낌표, 슬래시, 빈, 슬래시, bash, 줄 바꿈"이 표시됩니다. 그래도 문제가 해결되지 않으면 다시 내려가십시오. "앞의 키보드를 참조하십시오."3 "키를 참조하십시오. Shift 키를 누를 때 맨 위에 표시되는 기호는 파운드 기호입니다."

결론 :

• 너무 걱정 하지마, 틀릴거야, 모두 극복 할거야
• 그것은 당신이하는 일에 너무 구체적입니다.
• 항상 수건을 들고
• 코딩 공포에서 기사를 읽으 십시오

언어 구문을 말하기위한 표준을 크게 뛰어 넘어 본 적이 없습니다. 예를 들어 "#! / bin / sh"를 "Hound-bang 슬래시 빈 슬래시 SH"라고 말하고 "파운드 느낌표 슬래시 BIN 슬래시 SH"와는 달리 자신의 개인적 선호도를 표현한 작은 스 니펫을 발견했습니다. 나중에 리스너가 구문에 익숙하지 않다고 가정 할 수 있습니다.

또한 다른 언어를 큰 소리로 읽을 수있는 정도에는 큰 차이가 있습니다. 예를 들어 큰 소리를 내기 쉬운 경향이있는 Python과 Perl의 차이점을 생각해보십시오. Perl은 많은 구두점을 말하거나 "$ var [20]"에서 "배열 var의 20 번째 요소"로 변환해야합니다.

내 자신의 경험은 코드를 크게 읽어야하는 이유, 청취자의 지식 수준 및 해당 언어를 기반으로 매우 문맥 적이라는 것입니다.

코드 검토의 경우 리스너에게 원시 코드를 읽는 것보다 의미 또는 사고 과정을 얻는 것이 일반적으로 더 중요하므로 문장을 크게 읽으려고 시도하는 것보다 문장을 설명 할 가능성이 높습니다.

누군가가 정확한 C 코드 줄을 편집기에 입력하려고 할 때 (예를 들어, 주니어 프로그래머의 어깨 너머로보고 코드 줄을 수정하는 방법을 볼 때) 종종 코드를 말하게됩니다. "공백이 비어있는 null이 이중 인 경우 p-paren ..."과 같은 키워드 및 기호에서 상급 개발자와의 동일한 상호 작용은 "여기서 p가 null인지 확인해야합니다 ... "

코드에 대해 이야기하는 것은 의사 코드가 매우 편리 해지는 시간 중 하나입니다 .

누군가 문자로 나에게 코드를 제공하기 시작하면, 나는 그들에게 나에게 이메일을 보내라고 말하고 내가 생각하는 것을 알려줄 것이다.

짧은 답변

표준 발음 가이드에 가장 가까운 것은 해커 사전 ( " The Jargon File ")에서 "ASCII"에 대한 항목 인 것으로 보입니다 . 더 이상 온라인에서 쉽게 찾을 수없는 "Usenet ASCII 발음 가이드 개정 2.3"에서 파생 된 표가 포함되어 있습니다. 1991 년 5 월에서 6 월 사이에 관련 토론 스레드 인 " 이름 그 캐릭터! "가 comp.misc있으며, 이는 Maarten Litmath가 원본 문서를 유지하는 것으로 간주합니다. 스레드는 "&"에 대한 "Donald Duck"과 같은 "영리한"이름이 최신 문서에서 생략되었다고 지적합니다.