Як я можу розібратися з членом команди, який не любить робити коментарі в коді?

Один із членів моєї команди постійно уникає коментарів у своєму коді.

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

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

Який аргумент я можу представити йому, щоб переконати його правильно документувати свій код?

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

Коментарі самі по собі не покращують код, і лише натискання на "більше коментарів", ймовірно, дасть вам трохи більше, ніж /* increment i by 1 */коментарі стилю.

Тож запитайте себе, чому ви хочете цих коментарів. "Найкраща практика" не вважається аргументом, якщо ви не розумієте чому.

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

Тому не нарікайте на відсутні коментарі: скаржтеся на нечитабельний код. Або ще краще, не нарікайте, просто продовжуйте задавати питання про код. Що-небудь, чого ви не розумієте, запитайте того, хто це написав. Ви все одно повинні робити це; з нечитабельним кодом ви просто задасте більше запитань. І якщо ви пізніше повернетесь до фрагмента коду, і не впевнені, що правильно запам’ятали, що це робить, задайте те саме питання ще раз.

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

На фронті навичок людей уникайте звучання поблажливості чи звинувачення будь-якою ціною; будьте серйозні та чесні щодо своїх питань.

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

Те, що ніколи не працює, - "сказати їм, щоб вони додали більше коментарів". Це не підвищить ні їх самодисципліну, ні досвід. IMHO єдине, що може працювати - це робити часті огляди коду та рефакторинг. Коли розробник виконав завдання, дозвольте йому / їй пояснити будь-які частини коду, які ви не розумієте. Негайно рефактор або задокументуйте код таким чином, що ви обидва зрозумієте через 6 місяців.

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

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

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

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

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

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

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

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

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

1. Він усвідомлює свій вибір коду / дизайну і не хоче викладати їх у прозі. (Огляди коду можуть бути корисними для посилення чиєїсь впевненості в собі, як і для того, щоб знищити їх.)
2. Він працює дуже лінійно і не думає багато вперед. Коментувати болісно, ​​тому що змушує його вивантажити безпосередній код, який він збирався написати зі своєї робочої пам’яті, щоб скласти свій намір по-іншому. (Якщо це правда, коментування стає дуже важливим для його якості коду.)
3. Історично люди не розуміють його коментарів.

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

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

Отримайте програмне забезпечення для перегляду коду та добре його використовуйте.

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

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

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

Використовуючи програмне забезпечення типу Kiln, жоден набір змін не залишається поза увагою. Усі в моїй команді розробників дуже віддають перевагу саме цьому. Програмне забезпечення для перегляду коду мало величезний вплив як на якість нашого коду, так і на якість додатків :-)

Розробникам легко отримати захист із відхиленими відгуками при першому введенні програмного забезпечення, але, на мій досвід, це не займе багато часу, щоб зрозуміти, що краще, таким чином, і прийняти це :-)

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

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

Чому коментарі?

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

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

Читання коду! = Коментарі до коду

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

З іншого боку, програма "Читаема програма = код + документація" може містити кілька законних розділів коментарів, наприклад, для полегшення створення "коментарів до API" документації.

Дотримуйтесь стандартів стилю коду

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

Стати євангелістом з читабельності коду

Якщо ви згодні, код читається частіше, ніж написано. Якщо чітке висловлення ідей і мислення чітко для вас важливо, незалежно від того, якою мовою ви користуєтесь для спілкування (математика, машинний код або староанглійська мова) .. Якщо ваша місія полягає у викоріненні тупого та потворного способу альтернативного мислення .. (вибачте , останній з іншого "маніфесту") .. задайте питання, ініціюйте дискусії, почніть розповсюджувати думки, що провокують книги про очищення коду (напевно, не лише щось подібне до моделей дизайну Бека, але більше схоже на вже згадуване RC Martin ), які стосуються неоднозначності. в програмуванні. Далі йде чіткий уривок ключових ідей (цитується з книги O'Reilly про читабельність)

• Спростіть іменування, коментування та форматування за допомогою порад, які стосуються кожного рядка коду
• Уточнити петлі, логіку та змінні програми, щоб зменшити складність та плутанину
• Проблеми атаки на рівні функцій, такі як реорганізація блоків коду для виконання однієї задачі
• Напишіть ефективний тестовий код, який є ретельним і стислим, а також читабельним

Вирізаючи «коментування», все ще залишається багато (я думаю, написання коду, який не потребує коментарів, - це одна чудова вправа!). Називання семантично значущих ідентифікаторів - хороший початок. Далі - структурування коду шляхом групування логічно пов'язаних операцій у функції та класи. І так далі. Кращий програміст - кращий письменник (звичайно, якщо брати до уваги інші технічні навички).

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

Дещо. Чудовий код не потребує коментарів. Однак, як ви сказали, його код не є самодокументуванням. Тому я б не зосереджувався на коментарях. Ви повинні зосередитись на вдосконаленні майстерності та майстерності своїх розробників.

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

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

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

У більшості випадків я стикаюся з ними, коментарі є злі. Я рекомендую прочитати розділ коментарів до коду "Чистий код" Роберта Мартіна, щоб добре зрозуміти, чому.

Коментарі коментують ваш код кількома способами:

1) Їх важко підтримувати. Вам доведеться вкласти додаткову роботу при рефакторингу; якщо ви змінили логіку, описану в коментарі, вам також потрібно відредагувати коментар.

2) Вони часто брешуть. Ви не можете довіряти коментарям і повинні замість цього прочитати код. Звідки виникає питання: навіщо вам взагалі потрібні коментарі?

// this method returns the sum of 'a' and 'b'
public int GetHash(int a, int b)
{
    //the calculation of the hash
    int result = a*b;
}

(Хеш - це не сума, а продукт.)

3) коментарі захаращують код і дуже рідко додають значення.

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

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

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

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

Переважно, заохочуючи членів команди запитувати один у одного пояснень, ви створюєте систему самоврівноваження; де різні члени команди "автоматично налаштовуються" один на одного.

Це значною мірою розширення відповіді тадмерів, але регулярно проводити огляд коду.

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

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

Чи перегляд коду є хорошою практикою?

Враховуючи часто екстремальні погляди на коментарі, я не вагаюся зважитися. Це, як кажуть ...

Які аргументи я можу навести, якщо ви збираєтесь написати (нечитабельний) код, що він повинен бути належним чином задокументований?

Розуміння того, як писати корисний та читабельний код, вимагає часу, практики та досвіду. Недосвідчені програмісти (і, на жаль, багато досвідчених) часто страждають від ефекту Ikea ( PDF ). Це тому, що вони побудували його і тісно знайомі з ним, і вони впевнені, що код не тільки чудовий, але і читабельний.

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

Чи означає це "документування" їх коду? Не обов'язково. У конкретному випадку, у мене був подібний програміст із цим питанням і раніше. Я змусив його документувати. На жаль, його документація була такою ж нерозбірливою, як і його код, і нічого не додала. В ретроспективі коди відгуки були б кориснішими.

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

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

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

Деякі проекти вимагають, щоб така документація була поміщена в коментарі до коду та витягнута за допомогою таких інструментів, як Doxygen або Sphinx або Javadoc, щоб код та документація залишалися більш послідовними.

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

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

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

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

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

   var str1:String="" //not uderstandable
   var strSearchPattern:String="" //uderstandable

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

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

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

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

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

Серйозно подумайте про те, щоб просунути це як частину свого «Командного контракту» (і, безумовно, створіть контракт, якщо у вас його немає) - таким чином всі погодились на це, і ви маєте його на стіні десь, щоб не було » t будь-яке питання про те, що ви погодилися зробити.

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

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

Немає кращого вчителя, ніж суворий досвід!

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

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

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

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

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

В одному з моїх минулих проектів не вистачало десятків коментарів (алгоритм, результати або якийсь базовий JavaDoc), тому я просто вирішив зробити 130 випусків для нього, повідомляти електронною поштою про кожен випуск кожні 4 дні. Через 3 тижні у нього було 280 випусків, потім він вирішив написати коментарі.

Коментарі мають одну мету і лише одну ціль:

Чому цей код робить це?

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

У мене є звичка робити свої коментарі найбільш очевидною справою в моєму IDE. Вони виділені білим текстом на зеленому тлі. Справді зверніть вашу увагу.

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

Хороший приклад коментаря:

/* Must instantiate clsUser before trying to encrypt a password because the code to 
   encrypt passwords only uses strong encryption if that module is loaded. */

Поганий приклад:

/* instantiate clsUser */

Якщо ви використовуєте коментарі як "секції" коду: Розбийте свій метод мамонта на менші, корисні іменовані функції, і видаліть коментарі.

Якщо ви говорите, що ви робите, у наступному рядку: Зробіть код роз'яснювальним та видаліть коментар.

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

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

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

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

Просто: якщо працівник не коментує, скажіть йому натиснути shift+alt+jдля автоматичного коментування кожного методу одночасно з введенням коду. будь ласка, перегляньте код, щоб уникнути цих проблем.