Чи відволікаючі та непрофесійні коментарі від першої особи?


63

Щойно я виявив, що я пишу наступний коментар у якомусь (архаїчному Visual Basic 6.0) коді, який я писав:

If WindowState <> 1 Then
    'The form's not minimized, so we can resize it safely
    '...
End if

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

Я можу просто переписати його як it can be resizedі уникнути проблеми, але це викликало мою цікавість: чи часто в коментарях використовувати першу особу, як це, чи вважається це відволікаючим та / або непрофесійним?


1
Коментарі до голосування? Це моє перше запитання Programmers.SE, і я все ще намагаюся з’ясувати, що саме робить хорошим питанням P.SE проти хорошим питанням SO.
dlras2

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

56
Мені подобається «ми». Її доброзичливий і всеосяжний у здоровому, люб'язному вигляді.
Джеремі

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

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

Відповіді:


103

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

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


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

64
// we approve of this answer:)
Jarrod Dixon

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

1
@msw: чи не так, чи "ми відкидаємо конструкції пасивного голосу типу" це може бути змінено розмір "..." тоді?
tdammers

2
@msw, наприклад, у російській мові пасивні голосові конструкції зустрічаються частіше і розуміються легше через деякі культурні відмінності. (І ні, я не написав це речення пасивним голосом спеціально!)
P Швед

22

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

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

'The form is not minimized so it can be resized safely.

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

3
+1 за те, що не беруть на себе відповідальності в командному середовищі. І хоча я погоджуюся намагатися уникати багатослівних коментарів, іноді пасивний час може бути ще важче читати (як вказував jkj) і не менш багатослівний, і я вважаю за краще уникати неясності. =]
dlras2

2
@Jonathan Henson: Багато коментарів хороші, але лише якщо вони містять багато корисної інформації. Якщо однаковий обсяг інформації можна виразити двома рівнозначними способами, тим коротший кращий.
tdammers

Моя порада - уникати використання пасивного голосу. Це складніше для розуміння, особливо для носіїв англійської мови.
Віль Лорікарі

18

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

Пояснюючи такі речі, як вимоги чи обґрунтування, я йду з "ми", як у вас є:

// We can't proceed unless the user has given us this information.

Якщо я пояснюю процес, я схильний використовувати імперативний (командний) голос (виправте мене, якщо це неправильний термін):

// Get the foo from bar and make sure it follows our required format.

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


Це теж мій стиль. Обидва способи, які ви описуєте, мають своє місце.
zourtney

9
Останній теж має "своє". Мені цікаво, що люди, природно, пишуть коментарі у множині від першої особи.
Рейд

@Reid нічого так, це був просто інстинкт, я навіть не помічав. Але це просто могло сказати "то".
Тессерекс

8

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

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

Однак, я часто використовую першу особу в коментарях - щоб пояснити, чому я приймав конкретні рішення, і що я думав.


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

7

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

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

'ensure that the window is not minimized
If WindowState <> 1 Then
    'resize the window
    '...
End if

(І, будь ласка, не використовуйте в коді голі константи типу "1")


3
+1 за те, що я віддаю перевагу імперативу, я про це не думав. Крім того, так, я не повинен був використовувати голий 1. Я, як правило, досить добре про це ... Залиште це, щоб я розмістив один із небагатьох разів, коли це проскочило мою думку в Інтернеті.
dlras2

6

Можливо, ми маємо на увазі маленьких хлопців всередині програми, що робить магію? :)

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

Приклад:

(Ви / ми / один) повинні використовувати делегата, щоб передати події зміни розміру вікна батькові

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

Ще один приклад (зауважте, що ви можете часто опускати форми особи в коментарях):

(Ми) спіймали виняток. (Ми будемо) показувати діалогове вікно помилок.

Винято виняток, і буде показано діалогове вікно про помилку.

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


Я думаю, що лінгвістично це не правильно. Перший - імператив, він не має предмета. "Будь ласка, закрийте двері." Хоча це приблизно означає те саме, що "будь ласка, можете зачинити двері?" це виразна граматична форма, а не абревіатура. У другому прикладі ви можете так само сказати, що "(Це) застало виняток. (Це буде), що показує діалог помилок."
Інка

3

Якщо ви говорите про виконання програми, це не «ми», «ви» чи «я». Антропоморфізм може бути настільки розповсюдженим, що може бути непомітним, але це небезпечна звичка (PDF Warning. Dijkstra Warning.):

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


2
Попередження Dijkstra! Якби більше речей було одне :(
Том Андерсон

Я не думаю, що написання коментарів у множині від першої особи не є антропоморфізмом. Я думаю, що це означає: "Тепер ми доручаємо комп'ютеру ...", ніби програміст, який пише коментар, веде читача через його код.
blujay

2

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

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

// X is 10
// X is the user data of the newly-authenticated user
// X is a BigInt

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

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


Цікаве поняття; як би висловити поняття "X має бути принаймні 5" або "Y має бути не більше 23"?
supercat

@supercat - "Значення X повинно мати величину 5 або більше". "Значення Y не повинно перевищувати 23". Рівність, логічна чи арифметична, також не повинна використовувати дієслово "бути". "X має містити 5", або "X має значення 5" або "X має значення 5" або деяке значення. Якщо ви натрапили на особливо незрозумілий коментар, шукайте дієслова "бути". Б'юсь об заклад, що незрозумілий коментар використовує дієслова noting, але "бути". Також зверніть увагу, що відповідь я написав вище в E-Prime.
Брюс Едігер

Друге - добре; перше не так вже й багато, оскільки -6 має величину 5 і більше.
supercat

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

2

Правильний стиль коментування - безособовість третьої особи; " Форма не зведена до мінімуму, тому її можна безпечно змінити ".

  • Я наївний.
  • Ви - лукаві.
  • Ми занадто формальні (і королівські).

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


11
-1 тому що: немає правильного способу, я знаходжу ваше резюме I / You / Ми трохи недоторкані, і я не розумію останньої частини. Убік: Коли я кажу в коментарях "ми", я не намагаюся розмовляти як король - я розмовляю з вами, хлопець, який читає мій код, і проводжу вас по своїх думках пліч-о-пліч.
doppelgreener

2

Це залежить від коментаря.

Як правило, я пишу коментарі таким чином, як пропонував The Mouth of Cow . Я також завжди пишу коментарі, що створюють документацію (Doxygen, JavaDoc) таким чином.

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


+1 для Doxygen та JavaDoc. Я погоджуюся, що документація відрізняється від коментарів (хоча деякі коментарі генерують документацію), і я роблю все можливе, щоб така документація була на крок більш формальною, ніж моє коментування.
dlras2

1

Мій старий добрий батько (мхріп) запитав би: "Хіба у вас немає важливіших речей, які потрібно турбувати?"

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

Однак я сам і я згоден, що таким чином ми відчуваємо себе менш самотніми :)


1

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


0

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

//You can get a session_id from SYSSession.getSessionID() if you need one

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


Англійська пасивна рідко звучить добре: "session_id можна отримати від SYSSession.getSessionID (), якщо потрібен"
jkj

0

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

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

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

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

1
Вибачте, але я зовсім не шанувальник цього стилю. Тим більше, що цей код використовується один раз, в одному місці, і це вже єдине в методі зміни розміру. Я вважаю за краще короткий, чітко викладений коментар до додаткової складності через рефакторинг, особливо при роботі з налагоджувачем VB6. Як осторонь, CanThisFormBeResizedмабуть , це має бути, ThisFormCanBeResizedякщо це буде використовуватись як би If ThisFormCanBeResized Then.
dlras2

1
Такий перевага. Я приймаю приватний булевий метод, як function() { return this.windowState != 1 }будь-який коментар. +1 від мене
keppla

1
@Dan, що робити, якщо хтось інший піде пізніше: навіщо змушувати їх шукати навколо себе та переосмислювати логіку, щоб визначити, чи можна вікно мінімізувати? Вони можуть навіть не помітити ваш невеликий рядок коду з коментарем і додати свій власний. Тепер у вас є 2 місця, які потрібно змінити, якщо логіка зміниться, і 2 місця, де коментарі можуть не синхронізуватися з кодом. Чому добре названий метод 1 рядка (який не змінює стан) додає складності? Це найпростіший і один із найчистіших реконструкцій.
Стів Данн

0

Як правило, я б запропонував використовувати першу особу, тобто I.

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


0

Особисто я написав би (на C #):

if (WindowState != WindowState.Minimised)
{
     ResizeWindowSafely();
}

Або щось у цьому напрямку, тому коментарі не потребують.


ResizeWindowSafelyозначає, що його можна назвати, якщо ви не знаєте, чи слід змінити розмір чи ні, і, таким чином, потрібно було б включити if (WindowState != WindowState.Minimised)себе.
dlras2
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.