Чи слід зазначити помилки, пов'язані з написанням / граматикою в чиємусь коді? [зачинено]

Переглядаючи код співробітника, я зіткнувся з деякими орфографічними помилками у назвах функцій, а також граматичними помилками на зразок 'didUserHasPermission ()' замість 'doesUserHavePermission ()' у функціях та назвах змінних.

Чи варто вказати на нього або я занадто педантичний, помічаючи їх?

Код з орфографічними та граматичними помилками неможливий .

• Люди не пам’ятатимуть погану граматику, тому спробують викликати функцію так, як вона повинна була бути написана, і ось так трапляються помилки.

• Ви не можете похвастатися за щось у коді, якщо не знаєте, як це написано.

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

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

Так, звичайно. Простіше запам'ятати ім'я, якщо воно граматично правильне. Спроба запам'ятати ім'я та помилки граматики - це зовсім інша справа.

Не зазначайте їх як дефекти в офіційному огляді коду. Замість цього позначте список і поговоріть з ним / ПРИВАТНО про них. Будьте настільки дипломатичними, наскільки це можливо, просто "Гей, щось я помітив, і я наткнувся на людей, які дійсно дивляться на подібні речі, вони думають, що це робить програміста недбалим і неохайним".

Якщо це код, який клієнт збирається бачити, його ОБОВ'ЯЗКОВО слід виправити. Вам подобається чи ні, це відображається на репутації вашої компанії.

На прикладі, який ви подали, я підозрюю, що він почався як UserHasPermission, і хтось інший сказав йому, що місцева практика - це «UserBlahBlah» (), а не «UserBlahBlah» (), і він просто не помітив зміни граматики.

Змініть самі.

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

Я розробник, чия рідна мова - це не англійська, це насправді голландська, і зовсім не заперечував би, якщо хтось вкаже мені на граматичну чи орфографічну помилку. Таким чином я можу постійно вдосконалювати свою англійську. І точно не важко виправити всі помилки у всьому вихідному коді. Простий скрипт Perl може бути легко записаний для перегляду всіх файлів у папці. Можливо, навіть це можна зробити за допомогою sed? Не знаю.

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

Я думаю, тут варто згадати, що заголовок HTTP-реферала в протоколі HTTP був написаний неправильно як "референт" (і ми повинні з ним жити / ми навчилися жити з ним.) :)

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

Я також хочу додати кілька речей:

• Код часто пишуть люди, які не дуже добре володіють англійською мовою та / або англійська мова не є їх рідною мовою. Якщо в коді, який ви переглядаєте, є граматична помилка, це не означає, що ваш колега допустив цю помилку. Можливо, це була просто копія-вставка з веб-сайту.
• Якщо англійська мова не є рідною мовою вашого колеги, можливо, це буде гарна або дуже погана ідея сказати їй / йому про цю помилку. Будучи з Франції, я завжди вітаю зауваження щодо помилок, які я роблю англійською мовою, тому що це єдиний спосіб, коли я можу їх уникнути в майбутньому; з іншого боку, я знаю кількох людей, які відчувають себе дуже боляче, якщо ви розповісте їм про граматичні помилки, які вони роблять.
• Як сказав Джон Р. Стром, ніколи цього не робіть публічно. Більшість людей буде справді роздратовано цим.

Я б рекомендував використовувати IDE із вбудованим інструментом перевірки орфографії. IntelliJ Idea робить чудову роботу для програм Java. Існує безліч невтішних помилок, які вона ловить не тільки у назвах функцій, але, наприклад, у повідомленнях про винятки, які користувач бачить. Програма, яка видає повідомлення, сповнені помилок, не викликає великої впевненості.

Я роблю це лише в тому випадку, якщо

• це впливає на використання програми
• це впливає на точність програми
• Я чітко знаю, що автор хоче виправитись.

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

if userHasPermission() ...

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

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

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

Застосовується Золоте правило

Робіть іншим так, як ви хотіли б їх робити вам.

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

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

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

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

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

userPermission () можливо? -

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

Звичайно, зауважте, але не витрачайте час на перевірку орфографічних помилок. Використовуйте інструмент для автоматизації цього на вашому ІС. У .net fxCop може це зробити ...

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

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

/ rant :)