Що є причиною використання малих літер для першого слова в локальній змінній (наприклад, EmployCount, firstName)


20

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

Типова причина, чому я не повинен дотримуватися цієї «нестандартної» конвенції обсадної труби, полягає в тому, що повністю належний випадок повинен бути зарезервований для властивостей та недійсних методів. Локальна змінна та методи, які повертають значення, повинні мати перше слово в малій букві int employeeCount = getEmployeeCount().

Однак я не розумію, чому.

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

Починаючи з моїх ранніх днів програмування макросів Excel 97 за допомогою Office IDE, мені ніколи не потрібна конвенція обкладинки, щоб сказати мені, чи є щось локальною змінною чи властивістю. Це тому, що я завжди використовував дуже інтуїтивну конвенцію про іменування. Наприклад, GetNuggetCount()чітко підказує метод, який десь іде, отримує підрахунок усіх самородків. SetNuggetCount(x)говорить про те, що ви присвоюєте нове значення для кількості самородків. NuggetCountвсе саме по собі говорить про властивість або локальну змінну, яка просто містить значення. На останнього можна спробувати сказати: "А-а-а! Це питання. Власність чи змінна? ЯКІ ЦЕ?" На це я відповів би: "Це дійсно важливо?"

Отже, ось tl; dr ;: Які об’єктивні, логічні, не довільні причини використовувати малі літери для першого слова у вашій змінній або методі повернення?

Редагувати: Для MainMa

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

public void ComputeMetrics()
{
    const int MaxSnapshots = 20;

    var Snapshots = this.LiveMeasurements.IsEnabled ?
        this.GrabSnapshots(MaxSnapshots, this.cache) :
        this.LoadFromMemoryStorage();

    if (!Snapshots.Any())
    {
        this.Report(LogMessage.SnapshotsAreEmpty);
        return;
    }

    var MeasurementCount = Measurements.Count();
    this.Chart.Initialize((count + 1) * 2);

    foreach (var s in Snapshots)
    {
        this.Chart.AppendSnapshot(s);
    }
}

7
Якби вони були у
великому регістрі,

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

59
На жаль для вас, фактична і поважна причина - "тому що це стандарт". Люди з однієї команди платять за той самий стандарт стилю коду. Якщо ви не розумієте чому, то, можливо, вам слід задати ще одне питання: "чому корисні стандарти?"
Андрес Ф.

3
Я завжди вважав, що розробники влаштувалися на camelCase, тому що це виглядало збитково. Там немає «об'єктивних» причин для верблюжого самого вище PascalCase. Я особисто вважаю PascalCase (як ваш приклад) набагато простішим для читання, і використовую його в більшості інших місць, крім JavaScript, де я підтримую camelCase, тому я не пропускаю запрошення на вечірку.
GrandmasterB

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

Відповіді:


88

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

Employee employee;

Деякі мови навіть застосовують цю букву. Це запобігає використанню дратівливих імен змінних , як MyEmployee, CurrentEmployee, EmployeeVarі т.д. Ви завжди можете сказати , якщо що - то тип або змінний, тільки від капіталізації. Це запобігає плутанині в таких ситуаціях, як:

employee.function(); // instance method
Employee.function(); // static method

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

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


1
Зауважте, що проблема все ще існує в мові, якою використовується ОП, оскільки властивості використовуються з великої літери (звичайно, властивості можуть бути встановлені префіксом this., що дозволяє уникнути плутанини; місцеві змінні не можуть мати такий префікс).
Арсеній Муренко

1
@oscilatingcretin це називається PascalCase.
МістерМіндор

21
Employee Employeeпрацює, але я заперечу, що це для людини читача більше заплутано, ніж Employee employee. Остання схожа на дві різні речі. Перший виглядає як непотрібне повторення.
Джеймі Ф

14
@oscilatingcretin Саме так: "припускає, що читач розуміє основні рамки ..." Мені подобається читати JavaScript, Java, C #, C ++ та інші та перекладати код у голові. Мені не подобається постійно думати "О, компілятор цієї мови може мати справу з x ". в той час як я просто намагаюся отримати значення коду.
Джеймі Ф

1
Зауважте, що це employee.function()може бути і статичним методом, якщо мова дозволяє викликати статичні методи з об'єкта (як це робить Java). Компілятор подає попередження, але це дозволяється.
Uooo

34

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

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

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

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

http://thecodelesscode.com/case/94


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

1
@Schieis це важливо, якщо ви наступний програміст, який працює над проектом.
N4TKD

3
@oscilatingcretin Ви можете, мабуть, бути пристрасними та / або догматичними, коли працюєте над кодом, який повно var m_someVariableID = GetVariableValueId(). Особливо, якщо вам доведеться це робити без підтримки автодоповнення.
Tacroy

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

2
@Schleis гарне оновлення, я не згоден, це лише питання стилю, але конвенція і конвенція стають конвенцією з поважних причин і її слід дотримуватися. Це не релігія, і ви повинні дуже довго домовитися з умовами, але у вас є вагомі причини.
N4TKD

25

1. Чому стандарт існує?

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

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

Що можна зрозуміти між цими двома фрагментами коду?

public void comp_metrics ()
{
  int Count;
  List<snapshot> measurements=fromMemoryStorage();
  if (_liveMeasurements.enabled)
    measurements = GrabSnapshots(20, _cache);
    if( !measurements.Any() ) {
        this.Report(LogMessage.Measurements_Are_Empty); return;
    }

    Count = measurements.Count ();

    this.Chart.initialize(( Count + 1 )*2);

    foreach(snapshot S in measurements) {
      this.Chart.append_Snapshot ( S );
    }
}

або:

public void ComputeMetrics()
{
    const int MaxSnapshots = 20;

    var snapshots = this.liveMeasurements.isEnabled ?
        this.GrabSnapshots(MaxSnapshots, this.cache) :
        this.LoadFromMemoryStorage();

    if (!snapshots.Any())
    {
        this.Report(LogMessage.SnapshotsAreEmpty);
        return;
    }

    var count = measurements.Count();
    this.Chart.Initialize((count + 1) * 2);

    foreach (var s in snapshots)
    {
        this.Chart.AppendSnapshot(s);
    }
}

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

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

Маючи суворий, єдиний стандарт, це полегшує читання коду.

2. Чому їх стандарт кращий за той, який я винайшов зараз?

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

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

  • [FK for Application: CreatedByApplicationId],
  • [IX for SessionIPAddress: SessionId] або
  • [PK for RoleOfPassword: RoleId, PasswordId].

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

  • Коли я найму DBA, він буде змушений вивчити нову конвенцію, а не розпочати свою роботу зараз,

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

  • Якщо я беру код ззовні, щоб використовувати його самостійно, я змушений був би змінити назви, щоб зробити його однорідним,

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

3. Отже, що з капіталізацією?

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

Якщо розглядати C #, ця логіка є досить послідовною.

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

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

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


1
Що стосується менш читабельної частини про код, тому що вона відповідає трохи іншому стандарту, я ніколи не мав такої проблеми. Якщо чиїсь змінні не названі як hookyDookyDoo, ніякі умови іменування або обстановки не зачіпають читабельності. Крім того, майте на увазі, що я не кажу, що моя конвенція є "кращою", оскільки вона справді не приносить нічого особливого до таблиці розробників. Нарешті, я не розумію, що ваш пункт [Властивості мають більший обсяг ... йде в цьому напрямку] . Що стосується сфери дії конвенції про корпус? Йти в якому напрямку?
oscilatingcretin

23
@oscilatingcretin, питання не в тому, чи були у вас коли- небудь такі проблеми, а чи є у ваших колег . Очевидно, що вони є, або вони б не скаржилися.
Карл Білефельдт

1
Re: редагування: Ваш перший приклад коду демонструє просто погано побудований, схильний до катастроф код. Мій ОП не про погано побудований, схильний до катастроф код. Це приблизно той самий код, що і ваш другий приклад, але відрізняється умовою корпусу. Я відредагував ваш другий приклад коду і розмістив його в моєму ОП із моїм корпусом. Замініть це своїм першим прикладом коду, будь ласка.
коливальнийкретин

5
@oscilatingcretin: Перший приклад коду демонструє не погано побудований код, а код, написаний командою, де кожен розробник дотримувався власного стилю. Це трапляється із занадто великою кількістю баз коду з урахуванням достатнього часу (наприклад, п’ять років). Примітка: чи ви пропустили: "Справа в тому, що код все ще набагато читає таким чином, і все одно було б, якби вони використовували будь-який інший стандарт". ?
Арсеній Муренко

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

10

Технічно це не має значення (або, принаймні, у більшості мов це не має значення).

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

Не тому, що вони найкращі, а тому, що вони є тим, чим користуються всі інші; якщо ви дотримуєтесь стандарту, ваш код буде відповідати більшості інших кодів, які ви зрештою будете використовувати - бібліотеки, код командних команд, вбудовані мови. Послідовне називання - це одна потужна зброя продуктивності, адже це означає, що коли ви вгадаєте назву чогось, ви зазвичай здогадуєтесь правильно. Це file.SaveTo(), File.saveTo(), file.save_to(), FILE.save_to()? Конвенція про іменування вам скаже.

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

Лише один приклад: у C # типи та змінні живуть в окремих просторах імен; компілятор досить розумний, щоб знати різницю. Однак у C обидва типи імен мають спільний простір імен, тому ти не можеш мати тип і змінну з тим самим іменем у межах однієї області. Через це C потребує конвенції про іменування, яка відрізняє типи від змінних, тоді як C # ні.


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

4
@oscilatingcretin Коли кожен використовує одну і ту ж конвенцію, це не додає постійних складностей, конвенція стає частиною вашої ментальної моделі щодо відповідної мови І полегшує використання цієї мови. Це наочно і вимірно.
Містер Міндор

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

10

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

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

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


Ряд проектів, над якими я працював, вказав щось подібне у своєму посібнику зі стилів.
anaximander

7

Це здається швидше питанням про конвенції, а не про вашу конкретну конвенцію.

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

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

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


"Якщо я побачу великочасну величину, освічена здогадка продиктує мені, що мені потрібно використати її для використання". Я не розумію. Як би бачення змінної з великої літери змусило вас вважати, що вам потрібно інстанціювати її перед її використанням? Тому що це схоже на назву класу? Тож ви не знаєте різниці між MyClass MyClass = nullі class MyClass { }?
коливальнийкретин

3
Так, я бачу різницю. Конвенція існує для запобігання неоднозначності. var car = new Car();Згідно з моїм останнім рядком - чому б не зробити це очевидним?
Адріан Шнайдер

3
@oscilatingcretin Звичайно, є різниця. Але людський мозок отримує користь від візуальних підказок, яких не потребує комп'ютерний аналізатор. Схоже, ви ставите під сумнів необхідність конвенцій / стандартів ... що є дійсним, якщо питання інше, ніж те, що ви спочатку задавали.
Андрес Ф.

2

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

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


1
Ви читали моє запитання повністю? Погляньте до кінця, де я сказав:NuggetCount all by itself suggests a property or local variable that is simply holding a value. To that last one, one may be tempted to say, "Ah ha! That is the question. Property or variable? WHICH IS IT?" To that, I'd reply with, "Does it really matter?"
коливальнийкретин

8
Так і так, це важливо, наступному програмісту ніколи не потрібно думати NuggetCount, ви повинні мати можливість подивитися на ім'я та сказати. Гарна книга для читання - «Чистий код», ви повинні мати можливість читати код як історію та знати, що відбувається.
N4TKD

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

7
Конвенції несуть значення. Якщо згідно з умовою NuggetCount має на увазі властивість, це означає, що вона має сферу, що перевищує локальну змінну. Що означає, що мені доведеться більше досліджувати, щоб визначити цю сферу. Мені потрібно визначити: чи є побічні ефекти для його зміни? Чи можу я довіряти, що його значення не буде змінено іншим потоком під час його використання? nuggetCount передбачає локальну сферу, і я повинен мати можливість припустити, що вся його історія є локальною.
МістерМіндор

5
@oscilatingcretin ТАК! Саме так! Я довірився, що те, що вони написали, дотримується конвенції і здійснює все, що йде з ним. Я довірився, що вони працюють як частина команди, і я міг скористатися перевагами використання цієї конвенції (знаючи, що саме з niggetCount на перший погляд) Якщо цього не зробив, я, мабуть, роблю те, що зробили ваші колеги: Я намагаюся навчити відповідального , і я витрачаю більше часу наступного разу, коли мені доведеться дотримуватися їх, не довіряючи. Не дотримуючись конвенції, вони створили менш читабельний, менш доступний код. Чи є у вас підстави хотіти дотримуватися конвенції?
МістерМіндор

0

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

Рядки трохи розмиваються при роботі з такими речами, як захищені або зовнішні чи щось.


-2

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

Символи малого та великого регістру мають великі смислові відмінності в Haskell, також вони незначно відрізняються у Scala, і я використовував їх обидва. Інші мови, якими я користуюся, не мають різниці між цими двома видами ідентифікаторів, але зберігати думки в тому, як Haskell сприймає ідентифікатори просто набагато простіше для мене, ніж розбивати розум на різні мови.


-2

Для мене це зводиться до очікування.

Коли я читаю більшість кодів, я очікую, що все, що починається з а, lowerCaseє локальною змінною або функцією (в C # це буде просто змінною). Якщо я бачу локальну змінну в ProperCase, я, швидше за все, спотикаюся і плутаюся деякий час, думаючи, що це або назва класу, або властивість, або щось інше. Це змусить мене перечитати код і роздратуватиме мене.

Це, мабуть, те, що відбувається у вашому випадку.

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


-3

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


Я думаю, що це дуже гарна відповідь, і я не розумію голосів. Це логічна відповідь - ґрунтуючись на фактах, як цього вимагав ОП. Якщо ви голосуєте проти, будь ласка, поясніть себе. Натискання клавіші перемикання в усьому місці є масовим. Подумайте, майже кожне слово, яке ви введете у свій код, запустить PascalCase, і для кожного з них вам знадобиться ще одна клавіша shift. Якщо ви хочете бути мінімалістичними та ефективними, має сенс зняти непотрібні натискання клавіш. І, логічно кажучи, ти хотів би бути більш продуктивним, а те, звідки я стою, означає менше натискати клавіші. Навіщо натискати більше?
AIon

-3

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

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


3
це, здається, не пропонує нічого суттєвого щодо пунктів, викладених та пояснених у попередніх 11 відповідях
груб
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.