Работа с ненормативной лексикой в ​​исходном коде [закрыто]

Как люди справляются с ненормативной лексикой в ​​исходном коде и комментариях VCS. Сохранить или удалить?

А как насчет мягких ругательств, таких как WTF или Arrgggh?

Это непрофессионально, оскорбительно или что-то, на что можно не обращать внимания?

Это должно быть мягко обескуражен

..Вы не можете знать, кто увидит исходный код в течение его жизни.

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

• Большое количество ругательств в коде, опубликованном в виде кода с открытым исходным кодом.
• Шутки с плохим вкусом, вызывающие глубокое оскорбление у некоторых членов команды и приводящие к возникновению промышленного трибунала.
• Отброшенные замечания, которые на самом деле были расистскими / сексистскими / гендерными, заставляли людей быть уволенными.

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

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

Нет никаких оснований утверждать, что комментарии компилируются - как насчет JavaScript или любого другого динамического кода на стороне клиента?

Вот некоторые из моих реальных опытов, которые сформировали мое мнение:

• Работая в Microsoft, я обнаружил, что один инженер-программист не знал правильное написание слова «не может» - он пропустил o, l и d - и усыпил большую часть своего кода длинными объяснениями того, как он не мог заставить X работать, потому что Y человек вызывал проблему Z. Его код был великолепен; его написание было не так хорошо. Достаточно сказать, что любой последующий рецензент этого кода (например, я) был встревожен, увидев большое количество случайных ругательств в коде. Часть этого кода была показана партнерам (авторам драйверов). Вообразите их ужас при виде ругательств. В идеале рант должен был быть перед менеджером проекта в устной форме (в этом случае лицо Y может быть привлечено к обсуждению) или, возможно, зафиксировать сообщения, но не в источнике.

• В одной компании человек, говорящий на иностранном языке, присоединился к преимущественно англоязычной команде. Он писал комментарии на своем языке, думая, что никто другой не сможет их прочитать. Это было хорошо, пока Babelfish / Google Translate не выпустили опцию «на английский» для своего языка, после чего остальная часть команды перевела несколько комментариев и была потрясена грязными и часто уничижительными комментариями, которые парень делал о компании. , его команда и сотрудница. Неудобно .

• В другой компании один парень действительно увлекся искусством ASCII и поместил все виды искусства в свой исходный код, незапятнанный (или, возможно, благословленный) рецензентами кода. Через некоторое время он почему-то остановился на драконах, обычно с какой-то меткой. Позже к команде присоединился валлиец. Государственный герб Уэльса - красный дракон, поэтому новичок сначала был очень рад фотографиям, но затем обиделся, когда некоторые глупые метки можно было бы назвать оскорбительными. Да, требуется некоторое посредничество руководителя группы, но этого не должно было случиться.

Имена / особенности удалены, чтобы защитить невинных.

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

Если это вопрос ханжества, тогда как угодно, решать только вам.

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

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

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

Я работаю в компании из списка Fortune 500, которая разрабатывает, производит и продает потребительские продукты, в которых микроконтроллеры работают с кодом, разработанным собственными силами. Судебные разбирательства всегда возможны, либо со стороны потребителей, надеющихся быстро разбогатеть, либо со стороны конкурентов, заявляющих о нарушении. Из-за этого мы пишем наш код и ВСЕ комментарии со знанием того, что он может (вероятно, будет) подвергнуться проверке враждебных присяжных заседателей в какой-то момент. Это означает, что имена переменных и функций не должны содержать подстрекательских терминов, например KILL_CHILD(int process_id). Хотя цель этой примерной функции вполне могла бы заключаться в прекращении дочерних процессов, как враждебное жюри может просмотреть это имя функции, если ребенок истца был убит во время использования продукта?

Комментарии в коде могут быть еще хуже. Хотя достойная команда защиты могла бы, вероятно, справиться с объяснением того, что такое дочерний процесс (из предыдущего примера) и почему его, возможно, нужно прекратить, было бы почти невозможно защититься от такого комментария:

// The following section of code is REALLY BAD!!!  I hope
//  it doesn't burn anybody's house down.

Подобные комментарии были решающими факторами в реальных судебных делах.

Что касается смежной темы, названия для проектов также могут быть проклятыми под микроскопом интенсивного судебного разбирательства. Помните ли вы, что в середине 90-х годов шумные группы консерваторов сообщили о том, что «SATAN Unleashed On The Internet» опубликован ?

<rant_mode_off>

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

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

Однако, если это только беспокоит вас, и, кажется, никто не возражает, возможно, вам следует просто смириться с этим.

Возможно, я не тот человек, которого нужно спрашивать, поскольку я часто использую ненормативную лексику

Я думаю, что это в основном зависит от того, насколько ПК (политкорректно) ваша среда.

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

Мне кажется, что в США и некоторых других странах люди гораздо больше (или застряли) в ПК, чем в Нидерландах, где я живу и работаю.

В качестве дополнительного бонуса приведем некоторые статистические данные о ненормативной лексике в коде: http://andrewvos.com/2011/02/21/amount-of-profanity-in-git-commit-messages-per-programming-language/

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

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

Это непрофессионально, оскорбительно или что-то, на что можно не обращать внимания?

Возможно, все три ... в зависимости от вашей точки зрения.

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

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

Однако, если исходный код / ​​комментарии VCS публикуются за пределами вашей организации, ваше руководство может захотеть занять более жесткую позицию, исходя из того, что бизнесу плохо оскорблять ваших клиентов.

Одна из проблем с ненормативной лексикой заключается в том, что она отличается от культуры к культуре. В США невинные вещи, как правило, «выдыхаются», в то время как в других странах часто можно услышать один и тот же язык, которым обмениваются в парламентских дискуссиях.

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

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

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

Быстрое решение этой проблемы - установить фильтр ненормативной лексики в вашей системе контроля версий (в виде сценария предварительной отправки или регулярной проверки).

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

/ * * игорь: я сделаю себя публичным массером? * Франкенштейн: а, игорь, я унаследую твои лучшие черты ... * /

Так продолжалось долго. Он создал два названных объекта, как вы уже догадались: Франкенштейн и Игорь как часть проверки здравомыслия. Это было на самом деле очень креативно, но это пустая трата времени. Я бы скорее увидел несколько WTF или ругательств, чем сценарий между двумя объектами C # ...

Зависит от культуры компании / клиента. Например, если вы разрабатываете библейское программное обеспечение, ругательства в любой форме, безусловно, нежелательны. С другой стороны, разработчик игры может не заботиться так сильно (или перейти к другой крайности).

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

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

Ну, я не совсем уверен, что еще вы должны сказать о коде так:

tocommit = (n + (COMMITSIZE/PAGESIZE) - 1) & ~(COMMITSIZE/PAGESIZE - 1);

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

Как уже говорили другие, это зависит от рабочего места и того, кто увидит исходный код.

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

В настоящее время мой сервер сборки сообщает о комментариях OMG, WTF, kludge, mess и TODO как показатель оставшейся очистки, чтобы сделать это прямо сейчас, они являются частью процесса.

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

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

Они тебя беспокоят ? Исходя из того, что вы задаете этот вопрос, я предполагаю, что они это делают. В этом случае удалите их или очистите их в более подходящие комментарии о том, что не так.