Как узнать, являются ли орфографические ошибки в исходном коде серьезной проблемой или нет? [закрыто]

15

Я нахожу очень тревожное количество орфографических ошибок, которые я вижу каждый день в нашей базе кода, из которой я приведу очень короткий, но представительный пример:

ArgumnetCount
Timeount
Gor message from queue 

К сожалению, это никоим образом не ограничивается одним человеком. В нашей команде много не говорящих по-английски, которые внесли свой вклад в это, однако я также могу указать на некоторые наихудшие орфографические ошибки для нашего архитектора программного обеспечения, американца, родившегося и выросшего.

Их также можно найти даже в электронных письмах, презентациях, документах, любой части письменной информации, которую мы имеем в компании по разработке программного обеспечения.

Я хотел бы знать, как узнать, является ли это серьезной проблемой или нет?

Я всегда встречал эти орфографические ошибки с беспокойством, но моя собственная, личная, официальная политика заключается в том, что нам не платят за правильное написание слов , нам платят за выполнение заданий, поэтому внутри компании я никогда никого не критиковал за это. Но я поднял эту проблему с некоторыми из моих близких друзей, и никогда не решал ее навсегда.

Андрей Г
источник
4
Проголосовал закрыть как не по теме. Это относится не к разработке, а к любому домену, где люди пишут, начиная с комментариев YouTube и заканчивая содержанием сайтов. Некоторым людям просто наплевать на их написание и проверку орфографии. Они рады создать свой крупномасштабный веб-сайт для электронной коммерции, в названии которого есть три ошибки, написанные большими буквами на главной странице. И, к сожалению, большинство пользователей этого веб-сайта электронной коммерции не заботятся ни об этом.
Арсений Мурзенко
5
@MainMa: написание на языке программирования значительно отличается от написания на человеческом языке. Когда вы пишете для комментариев на YouTube, совершенно очевидно, что вы пишете для читателей-людей, но с исходным кодом распространено мнение, что пока он компилируется и работает, все в порядке.
tdammers
2
@tdammers: когда вы пишете исходный код, или вопрос на Stack Exchange, или книгу, или комментарий на YouTube, или содержание домашней страницы вашего сайта электронной коммерции, в каждом случае вы делаете это для людей, которые будут читать Это. Программирование не отличается, и вашему компилятору все равно, назовете ли вы свою переменную ArgumentCountили ArgumnetCount.
Арсений Мурзенко
16
Голосование возобновить. Комментарии в коде очень отличаются от комментариев в других средах и должны передавать сложную информацию в сжатой форме. Я не согласен, что они все одинаковы
Том Сквайр

Ответы:

19

Орфографические ошибки могут означать одно из двух:

  • Человек, который делает их, не владеет английским языком и не тратит время на компенсацию, используя соответствующие инструменты (словари, средства проверки орфографии и т. Д.)
  • Человек, который делает их, владеет английским языком, но не заботится о правописании вообще.

Либо это довольно плохой знак, потому что это означает, что рассматриваемый человек не имеет удобочитаемости, ремонтопригодности и элегантности в списке приоритетов; если причиной является недостаточное знание английского языка, это также означает, что у человека нет двух основных навыков - письменного общения на английском языке и общего чувства к языкам (если вы не можете четко выразить свои мысли на английском языке, скорее всего, вы сможете » Тоже хорошо выражать их на языке программирования).

Но почему именно ошибки в написании плохие, при прочих равных? В конце концов, код работает, и компилятору совершенно не важно, как вы называете свои идентификаторы, если они не нарушают правила синтаксиса. Причина в том, что мы пишем код не только для компьютеров, но и, прежде всего, для людей. Если бы это было не так, мы все равно использовали бы ассемблер. Исходный код пишется один раз, но читается сотни раз в течение его жизненного цикла. Орфографические ошибки затрудняют чтение и понимание исходного кода - небольшие ошибки приводят к тому, что читатель запинается на долю секунды, многие из них могут вызвать значительные задержки; действительно плохие ошибки могут сделать исходный код полностью нечитаемым. Существует еще одна проблема, заключающаяся в том, что большая часть кода, который вы пишете, будет ссылаться на другой код, и этот код чаще всего пишется кем-то другим. Если вы неправильно написали свои идентификаторы, кто-то другой должен будет запомнить (или поискать) не только то, что имя, но и как именно оно написано с ошибкой. Это требует времени и нарушает процесс программирования; и так как большая часть кода затрагивается более одного раза при обслуживании, каждая орфографическая ошибка вызывает множество прерываний.

Рассмотрим, как время разработки равняется зарплате, равно затратам. Я думаю, что это должно быть достаточно легко, чтобы доказать это; в конце концов, нарушение потока и возвращение в него может занять до 15 минут. Таким образом, серьезная орфографическая ошибка может легко стоить несколько сотен долларов на дальнейшую разработку и обслуживание (но это косвенные затраты, которые не видны напрямую в оценках и оценках, поэтому они часто игнорируются руководством).

tdammers
источник
5
Я хотел бы добавить , что орфографические ошибки могут привести к трудно проблемы отладки , где thisVaraibleи thisVariableвыглядят почти одинаково и «технически» правильно.
Спенсер Рэтбун
6
+1, но утверждение: «если вы не можете четко выразить свои мысли на английском языке, скорее всего, вы не сможете выразить их и на языке программирования» - это полная чушь!
Мартин Ба
2
@Martin: мне еще предстоит найти программиста мирового класса с ужасным стилем письма. Все лучшие программисты, которых я знаю, также способны писать краткий, четко сформулированный английский; некоторые из них (Кнут, Дейкстра) даже несколько известны своим стилем письма.
tdammers
5
@tdammers: Если бы они были носителями английского языка, я бы согласился. Но если у вас другой родной язык, вы можете довольно плохо понимать английский и все же быть хорошим программистом. Вот что я имел в виду под глупостью. Я согласен с тем, что Хорошие программисты также умеют хорошо писать - на любом естественном языке, на котором они свободно говорят. (Немного английского, очевидно, помогает ориентироваться в сети, но вам ни в коем случае не нужно бегло говорить или хороший писатель или у вас есть понимание грамматики или стиля на английском языке :-)
Мартин Ба
5
Обратите внимание, что Дейкстра не является носителем языка ...
tdammers
9

Я на самом деле сомневаюсь в том, что «Timeount» не является носителем языка. Люди делают тонны опечаток на своем родном языке. Я бы не назвал эти конкретные примеры «английским».

Сказав это, я понимаю, что речь идет не об этих конкретных примерах. Я согласен с вами в принципе. Я сталкивался с реальными проблемами, вызванными этим типом материала («если столбца с именем вложения нет, создавайте вложения»).

Быть программистом - значит быть точным и осторожным с опечатками, запятыми, точками с запятой, точками, которые в большинстве случаев не зависят от языка человека.

Конрад Моравский
источник
9

В первый раз, когда вы тратите время на поиск Timeoutпеременной, просто чтобы узнать, как она была записана Timeount, вы узнаете еще одну причину, по которой орфография важна.

Эрик Кинг
источник
7

Если эта проблема вас беспокоит, большинство IDE теперь разрешают проверку орфографии в комментариях, чтобы дислексики могли хотя бы выглядеть так, как будто они умеют писать. Это, конечно, помогает мне! Поэтому это тривиальное «исправление», чтобы иметь хорошее написание.

Сардатрион - против злоупотребления SE
источник
2
Если вы проголосуете отрицательно, не могли бы вы сказать, почему я могу улучшить свой ответ?
Сардатрион - против злоупотребления SE
6
Я не отрицал, но вы не отвечаете на его вопрос. Вы даете совет о том, как избежать орфографических ошибок. Это совершенно правильный комментарий, но не тот, о котором просил ОП.
Конрад Моравский
6

Ошибки правописания в публичных именах и методах классов просто непрофессиональны. Они стоят времени и денег. Они болезненны в статически типизированных языках, таких как Java, где IDE может создавать меню имен классов и методов. Они недопустимы в динамически типизированных языках.

Еще хуже - орфографические ошибки в именах таблиц базы данных и имен столбцов.

По моему опыту, правильное написание только незначительно связано со знанием английского языка программиста. Я видел, как носители английского языка производят код с практически случайным написанием и разрывом слов, и видел не носителей английского языка, которые стараются составить правильное написание. Но правильное написание тесно связано с общим качеством кода. Способные программисты, независимо от их уровня владения английским языком, заботятся о качестве своей работы и осторожны с именами.

Кевин Клайн
источник
5

В исходном коде, внутренних презентациях, документах и ​​т. Д. Мелкие опечатки, которые не меняют смысла или затрудняют понимание, не являются проблемой. Просто исправьте их в источнике, если вы находите их раздражающими.

Также, особенно в комментариях, содержание более важно, чем форма. Нет английского здесь:

Строка s = "Википедия"; / * Назначает значение "Wikipedia" переменной s. * /

Дело в том, что некоторые люди, естественно, являются более осторожными писателями, чем другие (будь то из-за образования, или из-за отношения, или из-за интеллекта или чего-то еще, не имеет значения). Сколько нужно потратить усилий, чтобы исправить это вопрос деловой ценности: получаете ли вы больше пользы от исправления опечаток, чем затрачиваете усилия на их исправление? В случае внутренних вещей ответ обычно - нет. Ваши клиенты не будут жаловаться на опечатки в комментариях к исходному коду (если вы не делаете открытый код).

Преднамеренная неправильная типизация и неуместные комментарии непрофессиональны, и их следует избегать, но основное внимание следует уделять вещам, которые имеют значение (например, генерировать ценность для бизнеса, если вы работаете для бизнеса).

Публично видимые вещи, конечно, должны быть тщательно вычитаны.

Joonas Pulakka
источник
2
Пожалуйста, скажите мне, что вы ввели "porblem" сознательно. :)
pdr
2
По общему признанию я сделал. Если вас это раздражает, вы можете это исправить;)
Joonas Pulakka
2
О нет. Я нашел это невероятно забавным.
фунтовые
6
«Некоторые люди - более осторожные писатели ...» Да, и те же самые люди - более осторожные программисты. Я еще не встретил хорошего программиста, который также не был осторожен в письменном общении.
Кевин Клайн
4

Проблема здесь не в самой лексике, а в отсутствии ясности комментариев. Идеальный английский не нужен, чистый английский есть. Это тривиально, чтобы запустить что-то через Google, чтобы подобрать очевидные ошибки.

Например, неясно с первого взгляда, что Gor message from queueозначает «получил сообщение из очереди» или «сообщение GOR из очереди». Вам нужно будет прочитать код, чтобы понять смысл комментария (таким образом победив объект комментария).

Вам следует попросить внедрить обзоры кода в вашей компании. Затем вы можете «критиковать» людей конструктивно, в то время как они поступают так же с вами.

Том Сквайрс
источник
2

Должно быть очевидно, что компилятор не заботится о неправильном написании, если вы используете одно и то же написание, например, при обращении к переменной. Тогда возникает вопрос, оказывают ли орфографические ошибки негативное влияние на способность членов команды поддерживать код.

Единственный способ сделать это - поговорить с людьми, выполняющими техническое обслуживание, и вы могли бы начать с вопроса, не труднее ли кому-нибудь следовать коду, содержащему орфографические ошибки.

Я не думаю, что есть какой-либо способ полностью исключить субъективность из этой проблемы, но чтобы уменьшить ее, вы можете (вручную или с помощью скрипта) отсканировать исходный код, чтобы получить приблизительное количество орфографических ошибок для конкретного модуля кода, и посмотреть, есть ли поддержка на модулях с большим количеством орфографических ошибок в среднем требуется больше времени, чем на модулях с меньшим количеством орфографических ошибок.

Конечно, не все модули сделаны равными, поэтому вы можете подумать о взвешивании ваших результатов с различными показателями, такими как цикломатическая сложность модуля.

Майк Партридж
источник
Майк, несоответствие ответов и вопроса - это недавние массовые изменения, внесенные в него. До версии 3 заголовок вопроса звучал так: «Что вы думаете об английском языке с исходным кодом»? и текст был очень в соответствии с ним
комнат
Это имеет смысл @gnat; Я удалил лишний абзац из своего ответа.
Майк Партридж
2

По моему опыту, такие основные орфографические ошибки вызывают беспокойство и могут быть симптомом более глубоких проблем. Каждый проект, над которым я работал с такими «тривиальными» ошибками, имел реальные проблемы в дизайне, которые каким-то образом проходили через процесс обзора только для того, чтобы появиться в процессе разработки, а не тогда, когда вы хотите узнать, что критически важная функциональность вам действительно нужна. не там

Я бы дважды проверил спецификации системы (если они существуют) и проверил бы общий дизайн; Я не удивлюсь, если вы нашли дыры.

Джон Боде
источник
1

На самом деле это две разные, но связанные проблемы. Это зависит от того, где орфографические ошибки:

1) В исходном коде. Если у вас есть такой идентификатор ArgumnetCount, это может создать реальные проблемы, когда кто-то приходит и использует правильное написание. Таким образом, вы должны исправить эти ошибки, когда это возможно. Если вам нужно сохранить обратную совместимость API, вы можете сделать что-то вроде:

/**
 * @deprecated - use setArgumentCount()
 */
public void setArgumnetCount(int c) {
    setArgumentCount(c);
}

2) В удобочитаемом тексте (электронные письма, документация, комментарии к коду). Правильное их написание важно, но я бы сказал, что это более низкий приоритет, поскольку программное обеспечение для анализа в вашей голове гораздо более щадящее. Если вы видите текст с несколькими ошибками, который по-прежнему читается, не беспокойтесь об этом - это не ваша проблема. Но если кто-то посылает вам какую-то бессмысленную бессмыслицу и ожидает, что вы будете использовать эту ерунду в качестве образца для многопользовательского веб-приложения, то вам следует отправить автору вежливую заметку с просьбой дать разъяснения (что-то вроде: «Вы, неграмотный придурок, как же Вы ожидаете, что я пойму это дерьмо? ")

Майк Баранчак
источник
-1

Правильно написанный английский является обязательным в коде. У меня также есть большая кодовая база, полная бессмыслицы, и поддерживать это кошмар.

Не позволяйте этому выйти из-под контроля. Постарайтесь рассказать всем, что разработчики кода не являются читателями ума.

linkerro
источник
1
«Постарайся обучить всех», - сделал я, и теперь они пишут с ошибками / опечатками, просто чтобы насолить. Должен любить это ...
MetalMikester
5
@MetalMikester: может быть, пришло время искать более профессиональный магазин.
Кевин Клайн
-1

Ну, это многогранная культурная проблема.

Говоря с немецкой точки зрения: мы замечаем, как наш язык все больше и больше подвержен влиянию английских терминов. Это доходит до национальных компаний с английскими лозунгами или рекламой. Некоторые люди, особенно на руководящих должностях, тем временем, по-видимому, не могут произнести одно предложение на простом немецком языке. Их речь полна модных слов и непонятного управленческого сленга. Мы говорим, что такие люди говорят по-английски.

Принимая во внимание такое положение дел и то, что английский язык является «лингва франкой», особенно в бизнесе программного обеспечения, неизбежно, что на сам английский влияет огромное количество не носителей языка. Но для носителей английского языка это все же лучше, чем, скажем, уроки китайского языка для участия в индустрии ПО.

Инго
источник
-1

Это цвет или цвет? Какую версию английского вы считаете верной? Правильное написание одного человека - это другое оправдание другого человека, чтобы начать выигранную войну.

Если вы хотите начать войну, тщательно выбирайте сражения и выигрывайте их. В вашем случае не беспокойтесь о комментариях, меньше заботьтесь о внутренних деталях и сосредоточьтесь (почти) исключительно на API

mattnz
источник
-3

У меня есть принцип: код Tidy не обязательно означает аккуратный ум, но аверс, безусловно, верен: неопрятный код, неопрятный ум.

Программист, который не тратит время на правильное именование переменных и правильное написание комментариев, почти наверняка не тратит время на то, чтобы сделать что-то еще правильно. Вопрос о том, является ли программист носителем английского языка, не является реальной проблемой, поскольку проблемы с его английским языком можно (и нужно) решать в ходе экспертной оценки.

Да, это серьезная проблема для продукта, для команды и для отдельных лиц.

  • Для продукта: исправление может привести к дефектам, которые обнаруживаются только клиентами
  • Для команды: команда тратит время на исправление неаккуратного кодирования, а не на создание ценности
  • Для людей: плохое правописание заставляет вас выглядеть глупо и снижает ваше профессиональное положение среди ваших сверстников.
Кристофер Уильямс
источник
4
Похоже, это не дает ничего существенного по поводу высказанных и объясненных в предыдущих 14 ответах. Вряд ли стоит натолкнуться на 3-летний вопрос с таким содержанием
gnat