Змінні умови іменування? [зачинено]

Я нещодавно почав використовувати ReSharper (для C #), і мені подобається, що його код шукає запахи коду, він показує мені деякі речі про моє написання, які я мав намір виправити давно (в основному змінні умови іменування).

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

Друге, що спонукало мене до повторної оцінки - це мої умови домену імен для обробників подій GUI. Зазвичай я використовую стандарт VS ControlName_Action, і в моїх елементах управління зазвичай використовується угорська позначення (як суфікс, щоб допомогти уточнити в коді те, що видно користувачеві, а що ні, при роботі з аналогічно названою змінною), тому я закінчую OK_btn_Click ( ), яка ваша думка з цього приводу? Чи варто піддаватися конвенції ReSharper або існують інші не менш дійсні варіанти?

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

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

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

З повагою до

але чи потрібне підкреслення? вам це зручно?

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

Поміркуйте:

public void Invoke(int size) {
    _size = size;
}

без підкреслення, вам доведеться написати:

public void Invoke(int size) {
    this.size = size;
}

яка потенційно вводить тонку помилку:

public void Invoke(int size) {
    size = size;    // urgh ... no this! 
}

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

З повагою до

зазвичай використовують угорські позначення

Рамкові рекомендації щодо дизайну: Конвенції, ідентичності та зразки для багаторазових бібліотек .NET:

НЕ використовуйте угорські позначення

Не залишаючи місця для двозначності:)

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

У C # початок захищеного або загальнодоступного імені з підкресленням суперечить Загальній специфікації мови. Це правильно лише у випадку приватних членів.

Від MSDN:

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

Дивіться: http://msdn.microsoft.com/en-us/library/12a7a7h3.aspx

Тут ви можете прочитати попередження про підкреслення:

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

Дивіться: http://msdn.microsoft.com/en-us/library/81ed9a62.aspx

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

Але, можливо, це не проблема у вашому випадку, якщо вам не потрібен код компілятора CLS.

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

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

Ви можете використовувати ключове слово "це", але _ коротше для кращого горизонтального масштабування. Описові назви зазвичай бажані, але коли щось є усталеною умовою, краще мати 1 символ. наприклад, використовуючи букву i як індекс під час циклу проходження масиву. Оскільки це встановлена ​​умова про те, що я є індексом, ви отримуєте користь від масштабованості без недоліків питання про те, що означає «я».

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

• Простіше встановити (просто перейдіть за замовчуванням, навіть я можу натиснути Enter 20 разів і продовжувати його)
• Зазвичай помилки розробляються за замовчуванням, часто це езотерична конфігурація, яку я встановив, яка виявляє дефект вперше
• Постачальник ланцюгів інструментів, напевно, знає про це більше, ніж я, тому вони зробили це таким чином не просто так. Хто я, щоб вирішити, що експерти помиляються (я вважаю їх експертами, бо купив їхній інструмент)
• Вам ніколи не доведеться захищати вибір постачальників менеджером - "Це те, що вони рекомендують"
• Новий хлопець не буде переслідувати вас "чому" та "Краще так" - Коли кожна відповідь - "тому що вони вирішили ..."

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

Майте на увазі, що кожна зміна потребує постійних витрат (реальних та прихованих). Чим менше їх, тим менша вартість. Наприклад - той новий хлопець, якого я згадав - без змін означає, що він може прочитати їх посібник. Переконфігуруйте - ви повинні написати додаток, зберігати його разом із речами otehr, звільнити його та змусити його прочитати його, прочитавши їх посібник. Можливо, це не проблема для магазину на 2 людини, але що робити з магазином на 100 чоловік?

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

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

У моєму випадку використання верблюжої та підкреслення допомагає з описовими (читання: довгими) назвами змінних та заповненням коду. Я не зовсім впевнений, як працює автозавершення Visual Studio, але в QtCreator і, в меншій мірі, Eclipse, можна набрати, наприклад

sDI

і чи поширився він до

someDescriptiveIdentifier

Економить трохи набравши, якщо у вас є такі назви

someDescriptiveName, someOtherDescriptiveName, someOtherButNotTheSameDescriptiveName

які я схильний виробляти в режимі "описового іменування".

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

someDescriptiveIdentifier

або

_someDescriptiveClassMember

Сподіваюся, моє пояснення досить зрозуміле :)