Чи варто дотримуватися рекомендацій щодо іменування конвенцій?


13

Я називаю свої змінні за допомогою конвенцій .Net:

  • camelCase для змінних та полів (я, як правило, використовую _camelCase для приватних полів у класі)
  • PascalCase для методів, властивостей та класів

Єдине місце, на яке я відхиляюся, - це константи та енуми, де я фактично віддаю перевагу стилю Java SCREAMING_CAPS.

Кодова база моєї компанії всіяна стилем позначення псевдо-угорської мови VB6 та VBScript, якщо не повномасштабною угорською, тобто

  • s або str для рядків
  • i або int для Ints
  • d для десяткової (або іноді подвійної)
  • o або obj для будь-якого виду об'єктів

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

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


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

Відповіді:


7

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

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

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


+1 Ці дні Rename перейменування настільки ефективні, що навряд чи можна помітити вплив змін.
Гері Роу

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

3

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

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


4
Мене навіть не цікавить префікс "Я", і використовую його лише тому, що він уникає загадок Java, скажімо, пов'язаного імені CustomerRepositoryта класу, який є CustomerRepositoryImplчи подібним.
Уейн Моліна

3
+1 - Здається, має бути кращий спосіб. Я час від часу використовую "Угорське світло", але префікси завжди пов'язані з бізнесом, а не типовими. Наприклад, все в Бухгалтерському обліку має AP та AR, і вони часто мають те саме ім'я, як Рахунок-фактура. Мені ARInvoice та APInvoice здається мені цілком розумним. Угорська - це ВСЕ погано ВСЕ.
Морган Херлокер

@Wayne M Ви можете подивитися на programmers.stackexchange.com/questions/75956/…
Гері Роу,

Я б не вважав це "угорським позначенням", тому що, як ви сказали, це ділове значення з чітко визначеною абревіатурою, яку люди знають, по тим же принципам, що код, який використовує XML з префіксом Xmlзамість ExtensibleMarkupLanguage. У модулі обліку я б очікувати , щоб побачити об'єкти рахунків - фактур , як arInvoiceі apInvoiceщо передає бізнес - контекст, але бачачи , objArInvoiceабо oApInvoiceпросто нерозумно ІМО. Я думаю, це може бути гірше, це може бути clsApInvoiceсправжнє ім'я класу
Wayne Molina

1
@ironcode: Насправді, це називається Угорська нотація додатків, порівняно із Системою Угорської Нотації, і набагато краще. Більшість людей, на жаль, використовують Системи. en.wikipedia.org/wiki/…
Мікі Ваттс

2

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

  • Заохочуйте більше distintcion (b) ool (f) loat (c) har (l) ong (s) hort (конфлікти зі String? No: (S) tring), (v) oid.
  • Заохочуйте кодування видимості. Я з Javaland, і сподіваюся, що він підходить і для .net: (pri) vate, (pub) blic, (pro) tected (def) ault слід використовувати.
  • .net має final / const? Зробіть це префіксом! Я чую "мінливий"?
  • Чому для int і long потрібен префікс, але різні об'єкти цього не роблять? Це не логічно. Створіть абзац.tab. де кожен новий Об'єкт отримує чітку абревіатуру.
  • Змінні, які можуть бути нульовими і такими, які ніколи не повинні бути нульовими, також можуть бути префіксальними. Розумні люди ставлять цілий DbC у префікс змінної.

Серйозно: під час рефакторингу ви можете змінити змінну з int на long, з String на char. Вам також не потрібно змінювати ім’я.

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

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

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

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


На жаль, я також бачив, що eSomeEnumвикористовується також місцями; на щастя, не часто.
Уейн Моліна

2

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


1

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

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

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


1

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

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


0

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


0

Мої відхилення:

  • _PublicPropertyBacker
  • _private_property_backer
  • _privateMember
  • CONSTANT_MEMBER
  • приватніфункції
  • парам_
  • приватна кнопка okBU; // тощо. обмежити 3 символи
  • struct SOMESTRUCT // for pinvoke structs

Регіони загального коду та макет файлу:

  • Члени
    • (приватний | внутрішній | захищений | публічний) X [статичний] X [const / readonly]
  • Властивості
    • (приватний | внутрішній | захищений | публічний) X [статичний] X [лише для читання]
  • Конструктори
    • (приватний | внутрішній | захищений | публічний) X [статичний]
  • Команди // що завгодно з недійсним поверненням або поверненням статусу
    • (загальнодоступний | захищений | внутрішній | приватний) X [статичний]
  • Обробники подій / приватні /
    • (Контроль | Віддалений | Сервіс | Інші) Події
  • Функції // запит на стан, не повинен мати побічних ефектів
    • (загальнодоступний | захищений | внутрішній | приватний) X [статичний]
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.