Справа з нецензурною лексикою вихідного коду [закрито]

Як люди поводиться з нецензурною лексикою у вихідному коді та коментарях VCS. Зберегти чи видалити?

А що з тими мекси-експлікативами, як WTF чи Arrgggh?

Чи непрофесійно, образливо чи щось слід знищувати?

Це повинно бути обережно відсторонено

.. ви, можливо, не можете знати, хто отримає перегляд вихідного коду протягом його життя.

Хоча це все є частиною роботи, щоб засмутитися особливо складним або старим фрагментом коду і хочете озвучити це, додавання в вихідний код експлікатів / рейтингів / мистецтва ASCII / погані жарти / образливі зауваження є непрофесійними і погана ідея в моєму досвіді. Іноді інженер, який пише коментарі, не звертає уваги на можливі наслідки, які його коментарі могли мати - ось лише деякі проблеми, які я бачу:

• Велика кількість прихильників коду, що публікується як публічний / зразок коду.
• Анекдоти з поганим смаком, що спричиняє глибокі образи для деяких членів команди, що призводить до промислового трибуналу.
• Викидання зауважень, які насправді були расистськими / сексистськими / гендерними, викликали звільнення людей.

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

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

Не захист сказати, що коментарі складаються або - що з JavaScript або будь-яким іншим динамічним кодом клієнта?

Ось деякі зі справжнього досвіду, які я мав, що сформували мою думку:

• Працюючи в Microsoft, я помітив, що один інженер-програміст не знав правильного написання "не міг" - він пропустив o, l і d - і багато чого з його коду пронизав довгими поясненнями того, як він не міг змусити X працювати, тому що людина Y викликала проблеми Z. Його код був чудовим; його написання було не таким хорошим. Досить сказати, будь-який наступний рецензент цього коду (наприклад, я) був насторожений, побачивши велику кількість випадкових присяг у коді. Частину цього коду надалі показували партнерам (драйверам). Уявіть їх жах, коли побачите лаянку. Титульні ідеї в ідеалі повинні бути у керівника проекту у словесному вигляді (в такому випадку людина Y може бути залучена до обговорення) або, можливо, передавати повідомлення, але не в джерелі.

• В одній компанії іноземна мова, яка розмовляє іноземною мовою, приєдналася до переважно англійськомовної команди. Він писав коментарі своєю мовою, думаючи, що ніхто більше не може їх прочитати. Це було чудово, поки Babelfish / Google Translate не випустив варіант "на англійську мову" для своєї мови, і тоді решта команди переклала кілька коментарів і була вражена брудними та часто принизливими коментарями, які хлопець робив про компанію , його команда та жінка-колега. Незграбний .

• В іншій компанії одного хлопця справді взяли з мистецтвом ASCII і поклали всі види мистецтва у свій вихідний код, не зафіксований (або, можливо, благословлений) рецензентами коду. Через деякий час він зупинився на драконах, чомусь, як правило, з якоюсь міткою. Пізніше до команди приєдналася валлійська особа. Національна емблема Уельсу - це червоний дракон, тому новий хлопець спочатку пильнував фотографії, але потім образився, коли деякі дурні теги-рядки могли бути розтлумачені як образливі. Так, потрібно було посередництво лідера команди, але цього не повинно було статися.

Імена / специфіки вилучено для захисту невинних.

Якщо ви продаєте свій вихідний код (тобто ви пишете компонент), він, ймовірно, не повинен бути там.

Якщо мова йде про розсудливість, то все, що завгодно, вирішувати вам.

Якщо ви бачите, що хтось пише багато WTF, то, можливо, це знак того, що вам слід поговорити з ними про проблеми, які вони виникають.

Якщо хтось спрямовує свою агресію до коду інших осіб, то він може переслідувати цю людину, і ви маєте вирішити зовсім іншу ситуацію. Можливо, у них є законна скарга і не знають, як правильно озвучити це. Можливо, вони просто придурки.

Не було б розумно мати лише якийсь фільтр контенту, як би не писав розробник, це важливо, і це багато що розповідає про те, як ідуть справи.

Я працюю в компанії Fortune 500, яка розробляє, виготовляє та продає споживчі товари з розробленим власним кодом µControllers. Судові справи - це завжди можливість або споживачів, які сподіваються швидко розбагатіти, або конкурентів, які заявляють про порушення. Через це ми пишемо наш код та ВСІ коментарі з усвідомленням того, що він (можливо, може) потрапити під огляд ворожих присяжних у певний час. Це означає, що назви змінних та функцій не повинні включати підбурювальні терміни, наприклад 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 In Internet" ?

<rant_mode_off>

З урахуванням сказаного, для особистих проектів ви можете робити те, що вам подобається у вашому коді.

Якщо вас це турбує, і ви головний хончо, я не бачу, чому ви не могли б застосувати правило щодо цього. Ви перебуваєте все - таки лідер в цій гіпотетичній ситуації.

Однак якщо це вас тільки турбує, і ніхто інший, здається, не заперечує, можливо, вам слід просто посмоктати.

Я, можливо, не є потрібною людиною, щоб питати, оскільки я часто вживаю легкої лексики.

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

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

Мені здається, що в США та деяких інших країнах люди набагато більше ПК (або стикаються), ніж у Нідерландах, де я живу і працюю.

Як додатковий бонус, ось декілька статистичних даних щодо нецензурної лексики в коді: http://andrewvos.com/2011/02/21/amount-of-profanity-in-git-commit-messages-per-programming-language/

Я схильний погодитись, що це може бути досить непрофесійно, але кожен час від часу обманює, тому я намагаюся не перешкоджати цьому проти інших. Зважаючи на це, база даних коду, як правило, відображає загальний професіоналізм групи, тому експлікативна база даних коду може відображати непрофесійну групу, і, можливо, потрібно буде зустріч, щоб "застосувати трохи польської мови" до групи. Так само, якщо в коді з’являються певні тенденції, це може бути показником загальних проблем у групі, які потрібно вирішити (тобто API, з яким ви працюєте, має проблеми, які засмучують розробників).

Щодо кодової бази, я зазвичай просто редагую відповідний коментар, щоб бути безпечним для роботи, і залиште його при цьому. Залежно від мови, з якою ви працюєте, це завжди гарна ідея, оскільки ви ніколи не знаєте, що може з’явитися перед клієнтом чи замовником.

Це непрофесійно, образливо чи щось слід знищувати?

Можливо, всі три ... залежно від вашої точки зору.

Людина полягає в тому, щоб люди виражали себе, використовуючи «барвисту мову» в певних ситуаціях. Більше в деяких культурах, ніж в інших, а в деяких людей більше, ніж в інших. Але тенденція універсальна.

Якби я був ти, я би відмахнувся від цього, якщо ти не готовий зробити себе непопулярним зі своїми однокласниками.

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

Одна з проблем із нецензурною лексікою полягає в тому, що вона відрізняється від культури до культури. У США невинні речі, як правило, "вихлюпуються", тоді як в інших країнах часто можна почути ту саму мову, яку обмінюють під час обговорень парламенту.

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

Я особисто вважаю, що особи, які не стикаються із замовниками (наприклад, матеріали з внутрішніх зобов’язань), не є такою великою проблемою.

Однак більшість великих міжнародних організацій керують юридичними відділами та "безпечним робочим місцем", і все таке, що означає, що що-небудь, що могло б образити хоча б одну людину, є проблемою та потенційною причиною звільнення. Я ненавиджу це визнавати, але я схиляюся до поклону регламентам тих, хто платить мою зарплату.

Швидке рішення цієї проблеми - встановити фільтр нецензурної лексики у вашій системі управління джерелом (як сценарій попереднього подання або звичайна перевірка).

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

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

Так тривало довгий час. Він створив два об'єкти, які називаються, ви здогадалися: Франкенштейн та Ігор як частина перевірки здорового стану. Насправді це було дуже креативно, але загальна трата часу. Я б швидше бачив кілька WTF або експлікацій, ніж сценарій між двома об'єктами C # ...

Залежить від культури компанії / клієнта. Наприклад, якщо ви розробляєте біблійне програмне забезпечення, експлікати в будь-якій формі, безумовно, не бажані. З іншого боку, розробник ігор може не так сильно піклуватися (або йти в іншу крайність).

Я завжди маю на увазі, що будь-які коментарі (у коді чи комітетах) повинні бути корисними . Деякі слова привертають нашу увагу більше, ніж інші - безумовно, помітні експліканти, навіть м'яка різноманітність. Це може бути корисно привернути увагу до чогось, що просто неправильно, але у вас поки немає способу обійти це.

Однак, я не використовую експлікатів, але інколи буду використовувати такі речі, як "До!" або "А?" що не надто відрізняється духом. Якщо це вас турбує, поговоріть про це з правопорушником - він / він може не думати про це. Якщо вони скажуть вам здійснити похід, і ви сильно відчуваєте це, підніміться до менеджера. Якщо ви не отримаєте підтримки від менеджера, тоді вам доведеться навчитися жити з ним або їхати в інше місце.

Ну, я не точно впевнений, що ще потрібно сказати про такий код:

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

Цей код було виведено з реальної, надзвичайно жорсткої бази даних, яку я намагаюся оптимізувати останнім часом. (Код є відкритим кодом, тому я не розкриваю жодних секретів роботодавця тут чи чогось іншого.)

Як говорили інші, це залежить від робочого місця та того, хто побачить вихідний код.

Якби я продавав вихідний код, я мав би друге сховище лише випущених версій і не дозволяв би будь-який коментар із реєстрацією там, окрім опису того, що надає кожна нова версія. Що я роблю щодня і всі мої помилки - між мною та моєю командою, а не моїми клієнтами.

В даний час мої звіти сервера побудови щодо коментарів OMG, WTF, kludge, mess та TODO є показником залишкової очистки, щоб зробити це прямо зараз, вони є частиною процесу.

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

Я думаю, що це питання особистих уподобань. Цей матеріал насправді не турбує мене, тому я, мабуть, залишу його. Можна навіть дати нам підказку, де в коді є проблемні області.

Вони вас турбують ? З того, що ви задаєте це питання, я здогадуюсь, що вони так роблять. У такому випадку видаліть їх чи очистіть до більш відповідних коментарів про те, що не так.