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

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

ArgumnetCount
Timeount
Gor message from queue 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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