Чи погані короткі ідентифікатори? [зачинено]

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

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

Редагувати

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

Зірвана ланка

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

• http://evergreen.loyola.edu/chm/www/Papers/SCP2009.pdf

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

Кожна змінна повинна мати значення, а її назва є частиною цього значення. І дуже важлива частина, оскільки вона допомагає читачеві зрозуміти, що це таке, не заглиблюючись у алгоритм. i, jочевидно, використовуються як індекси, вони короткі, але дуже інформативні. bntнекрасиво, closeабо closeButtonмають сенс. Оскільки короткий чи довгий не є найважливішим критерієм назви змінної, це має бути значимим. Змістовність сильно залежить від контексту. Наприклад, ви можете надати дуже коротке ім'я, як nмісцева змінна рядок, яка використовується в невеликому блоці коду, наприклад, 10 рядків і посилається на ім'я властивості ( vдля значення - інший приклад).

Тож назви змінних мають бути інформативними, і не важливо, чи вони короткі чи довгі .

Я буду використовувати ідентифікатор, який описує змінну, незалежно від довжини.

Випадки i, j і k самі по собі є настільки всюдисущими, що вони самоописуються, ви автоматично знаєте, що вони - це циклічні індекси. Ви можете сказати те саме для:

foreach loop (Strings s : myString)

Однак IDE тепер надає інструменти для заповнення коду, тому єдиний негативний побічний ефект дуже довгих та описових ідентифікаторів був видалений afaik.

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

Вони не такі погані, як оманливі ідентифікатори. Я не проти налагоджувального коду, в якому ідентифікатори - це лише одна літера, але в момент, коли різні картинки іменувань увійдуть у малюнок, це стає дратує. Наприклад, якщо ви десь бачите strPersonID, а потім ще десь бачите s_EmployeeID, то заплутано сказати, чи це обидва рядки і чи є різниця. Також, якщо змінні будуть вставлені копією ( pmapIntString = new std::map<int,int>) і абсолютно помиляються, я буду хвилюватися.

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

Я борюся ...

Я завжди використовую описові імена як ідентифікатори, але пізно я використовував дуже короткі ідентифікатори.

Я думаю, це залежить від контексту коду:

• Якщо ви пишете складні функції (алгоритми), то ЗАВЖДИ використовуйте короткі ідентифікатори (найкращі окремі символи)
• При написанні значень параметрів для функцій використовуйте описові імена.

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

Іноді без імен це абсолютно загадковим!

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

Отже змінні циклу, такі як i, j і k , настільки стандартні, що немає підстав не використовувати їх, якщо ви створюєте індексований цикл.

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

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

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

Ім'я змінної - це завжди вправа збалансувати унікальність та зрозумілість. Довжина назви по-різному пов’язана з обома. Більш довгі імена легше зробити унікальними; Імена середньої довжини, як правило, більш зрозумілі, ніж імена, які є занадто короткими або занадто довгими.

Дуже коротку назву змінного тільки корисно , якщо у нього є історія , що робить його доступним (наприклад, i, j, і kдля індексів, dxна відстань уздовж осі) або обсяг , який досить мало , щоб всі посилання , щоб бути видимими одночасно (наприклад , , temp). Найгірші імена змінних у світі - такі речі t47. ("Що це означає і чому вона відрізняється від t46?") Слава богу, що стиль іменування здебільшого вийшов із FORTRAN, але саме тут походить бажання довших імен змінних.

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

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

Змінна локальна для функції може мати невелику описову назву, як deltaXбез проблем. Статична змінна delta X у модулі повинна мати ім'я, яке відрізняє цей deltaX від інших deltaX у тому ж модулі, що робить його довшим. І глобальна змінна delta X повинна бути унікальною для всіх модулів і всіх можливих інших модулів, які можуть бути створені, ймовірно, приєднавши ім'я модуля до іншого описового імені. Це одна з багатьох проблем глобальних; щоб бути корисними унікальними, імена повинні бути досить довгими, щоб ускладнити їх читання.

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

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

Спостереження, яке я мав протягом багатьох років, і це сьогодні так менше, ніж це було 10 або 15 років тому. Програмісти, які не можуть набрати, - це той, хто буде боротися з вами зубами та нігтями над змінними назвами. Це ті, у кого всі назви змінних букв 1-3.

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

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

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

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

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

Неважко сказати, що «будь-хто повинен бути в змозі зрозуміти, що i, j і k є змінними циклу». І більшість випадків це справді очевидно. Але я все ще намагаюся залишатись покірним та професійним щодо цього і припускаю, що легко помилитися при програмуванні. Отже, якщо я перебираю масив Grobbles, я назву змінну циклу grobbleIndex. Я також міг би прийняти i як абревіатуру індексу. Коли ви використовуєте ij і k, складніше помітити помилку, як-от використання неправильного індексу з неправильним масивом тощо. І стає ще гірше, коли у вас внутрішня петля.

PS. У той час, коли я писав цю відповідь, я кодував javascript на 10-дюймовому міні-ноутбуці з вертикально розділеним екраном у vim, і я все ще знадобився час, щоб назвати свої змінні петлі rowIndex та columnIndex.

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

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

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

Особисто я часто використовую короткі імена для невеликої кількості неодноразово посилаються осіб. Наприклад, часто називаються додаткові підпрограми, наприклад.

Я ніколи б не використовував імена ідентифікаторів, що містять менше 4-5 символів, наприклад, змінною циклу може бути Index, jIndex або kIndex, залежно від того, скільки внутрішніх циклів мені потрібно щось виконати, але для інших імен, скажімо, "ключ" я б використовував "Рядок LKey" або "int LKey", "L" для локальних, якщо це змінна методу або "F" для змінної приватного класу, всі інші ідентифікатори, як і інші згадані раніше мною, повинні пояснити причину її існування в його імені, інакше Область "ідентифікатор" марна, чи не так ?!