Кто-нибудь определил стандарт для чтения кода вслух, для любого языка? Я полагаю, что это важно для таких программ, как программы чтения с экрана для людей с нарушениями зрения. Подобные вещи также возникают, когда вы обсуждаете код с кем-то, просматриваете его в группе или преподаете в классе.
В семействе языков C много слов с «очевидным» произношением. Некоторые из них просто английские слова: for
, break
, case
, default
и т.д. Некоторые аббревиатуры, как int
, однозначны. И тогда есть char
.
Я всегда говорю это (и слышу это в своей голове), как первый слог «уголь». Мне было неприятно, когда я впервые говорил о коде с кем-то, кто произносил его как «автомобиль», что на самом деле имеет больше смысла, потому что char
на самом деле это аббревиатура слова «характер», поэтому ясно, что его следует произносить одинаково. Но даже зная об этом, уголь как уголь кажется мне более правильным.
И тогда есть заявления, как foo = bar ? *(++baz) : zardoz
.
Кто-нибудь выпускал документ, диктующий правильный (по их мнению) способ прочитать код вслух? Либо для конкретного языка или, может быть, код в целом?
источник
:=
?Ответы:
Быстрый комбинезон: прочитайте эту замечательную статью в Coding Horror
Всякий раз, когда я обсуждаю код по телефону, я никогда не читаю его буквально. Вы должны «скомпилировать» его для человека, и если на другом конце строки все еще есть путаница, вы можете перейти к более буквальному чтению. Например, я бы прочитал ваш пример как
Я работаю на полную ставку с середины 90-х годов, поэтому практически все мои взаимодействия с коллегами осуществлялись по телефону или другими косвенными способами. Очень часто мы разделяем сеанс экрана (терминала) или VNC (X). Помимо регулярного товарищества, мы проводим весь день, обсуждая код, дизайн, планирование и т. Д.
Когда мы говорим о коде, мы используем жаргон, который тесно связан с типом работающего проекта. Одна из (многих) причин, по которой новому члену группы требуется столько времени, чтобы стать полностью функциональной, заключается в том, что они, по сути, изучают новый язык каждый раз, когда присоединяются к новому отделу / компании.
Как я уже говорил выше и, как уже говорили другие, мы стараемся говорить на таком высоком уровне, который подходит для любой дискуссии. Но иногда вам действительно нужно просто сказать кому-то: «Напечатайте это»
Как ты это говоришь? Ну, мы могли бы просто дать перечисление как ...
Вот как «мы» говорим этим персонажам. Чтобы получить представление о всей поговорке "#", взгляните на вики-страницу для #
Так что слишком много вариабельности. Он должен быть конкретным для языка, на котором вы кодируете (так же, как я набираю это на английском для нашего человеческого общения).
Без языкового контекста вам бы постоянно приходилось возвращаться к буквам. Поэтому большинство людей, которых я знаю, прибегают к тому, что языковой стандарт называет вещами.
Каждый из них будет подразумеваться, просто сказав «Установите X в ...» в соответствующем контексте. Даже не начинайте меня с того, что код читается как "строка X равна строке Y".
Если вы скажете «hash bang bin bash» или «shebang bash», почти каждый будет знать, что означает «#! / Bin / bash». Если они этого не сделают, они скажут: «А?», И вы уйдете на ступеньку внизу «В верхней части файла: знак фунта, восклицательный знак, косая черта, корзина, косая черта, удар, новая строка». Если они по-прежнему не получают его, вы еще раз понижаете его: «Видите эту клавиатуру перед собой? Видите клавишу« 3 »? Эта метка вверху, когда вы нажимаете клавишу shift, является знаком фунта».
Нижняя линия:
источник
#
или «а»!
. Вы даже не говорите, почему обсуждаете код по телефону. Поскольку у вас есть наибольшее количество голосов, не могли бы вы конкретизировать свой ответ еще?Я никогда не сталкивался с какими-либо стандартами вслух говорящего на языке синтаксиса. Я натолкнулся на небольшие фрагменты, где кто-то выразил свое личное предпочтение, например, ссылаясь на «#! / Bin / sh» как «Слэш-слэш бина хеш-бэнг», а не как «Восклицательный знак слеш-бин БИХ слеш-слэш» «последний может предположить, что слушатель менее знаком с конструкцией.
Существует также большое несоответствие между количеством языков, доступных для чтения вслух. Возьмем, к примеру, различия между Python, который легче говорить вслух, чем, скажем, Perl, который требует, чтобы вы либо произвели много знаков препинания, либо перевели с «$ var [20]» на «двадцатый элемент массива var».
Мой собственный опыт заключается в том, что он очень контекстуален, потому что мне нужно читать код вслух, уровень знаний слушателя и язык, на котором идет речь.
В случае обзоров кода я с большей вероятностью объясню утверждение, чем попытаюсь прочитать его вслух, поскольку обычно важнее понять смысл или мыслительный процесс, чем просто прочитать необработанный код для слушателей.
Когда я пытаюсь заставить кого-то набрать точную строку кода C в редакторе (например, я смотрю через плечо младшего программиста и вижу, как исправить строку их кода), я часто заканчиваю тем, что говорю код в ключевых словах и символах, таких как «if space open-paren null double-equals p close-paren ...» Тот же самый обмен с более старшим разработчиком может начаться больше как «вам нужно проверить, что p здесь null ... "
источник
Разговор о коде - один из тех случаев, когда псевдокод становится чрезвычайно удобным.
Если кто-то начнет давать мне код от персонажа, то я просто скажу, чтобы он отправил мне его по электронной почте, и я сообщу им, что я думаю.
источник
Короткий ответ
Ближе всего к стандартному руководству по произношению представляется запись "ASCII" в словаре хакера (он же The Jargon File ). Он содержит таблицу, основанную на «редакции 2.3 Руководства по произношению USCET ASCII», которую больше нельзя легко найти в Интернете. В мае-июне 1991 года существует соответствующая дискуссионная ветка « Назовите этого персонажа! »
comp.misc
, В которой Маартен Литмат считает автором оригинального документа. В ветке отмечается, что «более умные» имена, такие как «Дональд Дак» для «&», были опущены в новом документе.источник