Названня конвенцій: camelCase проти underscore_case? які ваші думки з цього приводу? [зачинено]

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

Зараз усі на роботі використовують camelCase, оскільки (так кажуть) код виглядає більш елегантно.

Що ви думаєте про camelCase або підкреслити_випад

ps, вибачте, моя погана англійська

Редагувати

Деякі оновлення спочатку:

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

• Я використовую camelCase так само, як і всі інші в команді (як і більшість з вас рекомендують)

• ми використовуємо Zend Framework, який також рекомендує camelCase

Деякі приклади (пов'язані з PHP):

• Рамка Codeigniter рекомендує underscore_case, і якщо чесно, код легше читати.

• ZF рекомендує camelCase, і я не єдиний, хто вважає, що код ZF - це набагато складніше.

Тож моє запитання буде перефразоване:

Візьмемо випадок, коли у вас є платформа Foo, яка не рекомендує жодних угод про іменування, і вибір лідера команди повинен вибрати її. Ви цей керівник команди, чому б ви вибрали camelCase або чому підкреслити_case?

ps дякую всім за швидкі відповіді поки що

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

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

aRatherLongSymbolName

або це:

a_rather_long_symbol_name

Я вважаю версію підкреслення набагато простішою для читання. Мій мозок може ігнорувати підкреслення набагато легше , ніж він може виявити кордону нижнього / верхнього регістру в ГорбатийРегістр, особливо там , де межі між символами , які виглядають подібно до інших гліфів іншому випадку, або цифрами ( I/l, O/0, t/Iі т.д.). Наприклад, ця булева змінна зберігає значення, яке вказує на те, побудований чи не Igloo з належним дозволом на планування (безсумнівно, загальний для всіх випадків використання):

isIllicitIgloo

Я вважаю цю версію набагато легшою для читання:

is_illicit_igloo

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

Я думаю, вам слід використовувати конвенцію про іменування, прийняту вашою платформою. Підкреслення_case буде дивно виглядати в коді C #, як camelCase в Ruby =)

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

На підставі відповіді відповіді Джона Айзекса:

"чесно, код простіше читати" Думка чи факт?

Я вирішив зробити кілька досліджень і знайшов цю роботу . Що має сказати наука з цього приводу?

1. Кожух верблюда має більшу ймовірність правильності, ніж підкреслення. (шанси на 51,5% вище)
2. В середньому, на верблюдний футляр тривав 0,42 секунди , що на 13,5% довше.
3. Навчання не має статистично значущого впливу на те, як стиль впливає на правильність.
4. Ті, хто пройшли більшу підготовку, виявились швидшими в ідентифікаторах у стилі верблюда.
5. Тренування в одному стилі негативно впливає на пошук часу для інших стилів.

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

Тільки повільність корпусу верблюдів (2) справді актуальна для програмування, відкидаючи інші пункти як нерелевантні через сучасні IDE та більшість користувачів camelCase у дослідженні. Дискусію (разом із опитуванням) можна знайти у дописі блогу.

Мені цікаво, як ця стаття може змінити думку. :)

Скопіюйте найрозумніших хлопців

Що стосується мов програмування, скопіюйте стиль розробника мови.

Наприклад, я кодую C точно так, як це робиться в K&R.

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

Взагалі, я віддаю перевагу camelCase. Однак це тому, що більшу частину своєї кар'єри я працюю в мовах та середовищах, де керівництво стилем зазвичай рекомендує camelCase. (Java, ECMAScript, C ++). Ви, будучи людиною PHP, швидше за все, маєте протилежні переваги.

Це означає, що коли ви виходите за рамки трьохOrFourWords, або якщо ви використовуєте ініціалізми, якXmlForExample, він перестає бути таким читабельним.

Ось чому Emacs надає нам режим окулярів.

camelCase

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

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

Це цікаве питання, я над цим багато разів замислювався. Але однозначної відповіді, я думаю, немає.

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

Іноді цікаво зламати прийняті позначення. Один із моїх невеликих проектів (на Python) я використовував underscored_namesдля утилітних функцій / "захищених" методів та Java-стилів methodNamesдля методів. Моя команда була задоволена цим :)

Залежить від мови програмування.

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

• Python: підкреслюється_запис, відсутність угорських позначень
• C ++: camelCase, угорська нотація

Обидва!

Я дуже багато розвиваю в CakePHP, і використовую або, CamelCaseабо $underscored_vars, таким чином (навіть поза проектами CakePHP):

1. імена файлів - /lowercased_underscored.phpтипові, але варто згадати.
2. класи - class CamelCase extends ParentObject. Зауважте, що при використанні CamelCaseпочатковий символ не є малі. Я вважаю, що camelCaseце виглядає дійсно дивно.
3. змінні -$are_variables_underscored === TRUE;
4. змінні з примірниками -$CamelCase = new CamelCase();
5. клавіші масиву -$collection['underscored_keys'];
6. константи - я думаю, кожен може погодитися, що константи повинні бути ALL_CAPS_AND_UNDERSCORED.
7. методи -$CamelCase->foo_method_underscored();
8. статичні методи -CamelCase::just_like_regular_methods();

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

Однак я маю контрприклад для тих, хто каже: "дотримуйтесь конвенції вашої мови та її бібліотек".

Раніше ми писали код C у Windows за допомогою underscore_caseі називали PascalCaseфункції Win32:

if (one_of_our_conditions_is_true())
{
    call_one_of_our_functions();
    CallSystemFunction();
}

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

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

Мені дуже подобаються просто-звичайні тире-як-як-вони-прості в наборі і прості в читанні Ділана.

Подібно до

result-code := write-buffer(file-stream, some-string)

Але я здогадуюсь, оскільки ця мова є досить малозрозумілою, це є поза темою ... :(

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

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

І не заплутайтеся, це не про читабельність (що є суб'єктивною), а про те, щоб бути послідовними та професійними. Будь-хто, хто працював у кодовій базі з численними «стандартами», зрозуміє.

Іноді я використовую мікс: module_FunctionName. Усі (нестатичні) функції моїх модулів починаються з абревіатури модуля.

Наприклад функція для надсилання вмісту буфера на шині I2C:

i2c_BufferSend()

Альтернатива i2c_buffer_sendне показує достатньо великого поділу між префіксом та назвою функції. i2cBufferSendзанадто багато змішується в префіксі (у цьому модулі є досить багато функцій I2C).

i2c_Buffer_send можливо, це була б альтернатива.

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

myGeneralOpinionIsThatNamesAreMuchHarderToReadInCamelCase. I_respect_the_fact_that_some_could_think_otherwise_but_I_do_not_really_understand_why.

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

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

myName   = 7
bobsName = 8   // :(

me.name  = 7
bob.name = 8   // :D

Так само, якщо вам потрібно диференціювати типи, чому б не використовувати мову, яка дозволяє їм?

var intThingy = 7; // :(

int thingy = 7;    // :)

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

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

Наступне, що вам потрібно зробити, - це називати правила, які є популярними для мови, на якій ви пишете. Мій код C ++ для instnace, очевидно, буде виглядати інакше, ніж щось для Python (PEP8 - хороший посібник тут)

Ви також можете використовувати різні умови іменування для позначення різних речей, наскільки ви, ймовірно, використовуєте UPPER_CASE для констант (це стосується, звичайно, певних мов), ви можете використовувати this_style для локальних імен змінних, тоді як ви використовуєте camelCase для приклад / член змінні. Це може не знадобитися, якщо у вас є такі речі, як selfабо, thisоднак.

Оновлення

Давайте візьмемо випадок, коли у вас платформа Foo witch не рекомендує жодних угод про іменування, і вибір лідера команди повинен вибрати. Ви цей керівник команди, чому ви обираєте camelCase або чому підкреслюєте_ccase.

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

Процитуйте Алекса Мартеллі на дуже схожу справу:

Звичайно, мені в Рубі втомлюється вводити дурний "кінець" в кінці кожного блоку (а не просто розмовляти), - але тоді я отримую, щоб уникнути набору однаково нерозумно ":" чого вимагає Python у початок кожного блоку, так що майже мити :-). Інші відмінності в синтаксисі, такі як "@foo" проти "self.foo", або вища значимість випадку у Ruby vs Python, для мене насправді так само не мають значення.

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

Джерело

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

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

Для мов програмування, які я використовував, як-от Java, Python, C ++, я прийняв чіткий формат:

• ClassNamesArePascalCase
• methodNamesAreCamalCase
• змінна_на_міни_на_голошення
• CONSTANT_VARIABLES_ARE_CAPITAL_VARIABLES

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

Я також вважаю корисним бути суворим і називати речі в PascalCase, такі як HTML-аналізатор як HtmlParser замість HTMLParser або HTMLparser. Тому що я вважаю, що простіше запам’ятати суворе правило і чіткіше зберігати межі слова (на жаль, це вимагає неправильного написання таких речей, як HTML або SQL). Аналогічно з camelCase, htmlParserMethod замість HTMLParserMethod або HTMLparserMethod.

ОНОВЛЕННЯ :

З тих пір я знайшов застосування в розширенні цих правил, щоб включити приватні змінні. - _private_variable_names_are_prefixed_with_an_underscore - _PRIVATE_CONSTANT_VARIABLES_ARE_PREFIXED_WITH_AN_UNDERSCORE

У Java це означає, що приватні поля за визначенням знаходяться в іншому просторі імен, ніж локальні змінні, а значить, ви можете пропустити this.на приватні поля. Інші формати я бачив префікс " m", але ці формати також використовують camelCase для імен змінних. Це також дозволяє мені зробити відмінність між полями , які повинні бути доступні тільки усередині класу (і робить його супер ясно , коли це відбувається за межами класу object._field_xвиділяється).

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

Тепер основним аргументом конвенції, я думаю, є те, що ви знаєте заздалегідь, що таке формат назви функції / змінної, і не потрібно її шукати - це LoadXMLFile, loadXMLFile, LoadXmlFile, load_xml_file? Тепер я би протистояв цьому аргументу, кажучи: "Отримайте IDE, який підтримує автоматичне завершення стилю intellisense!" (не завжди це можливо).

Зрештою, все-таки неважливо, який стиль ви використовуєте, оскільки компілятор / інтерпретатор насправді не хвилює. Важливо, щоб ім’я було корисним:

NumberOfPrisonersReleasedByAccident
manufacturer_name
distance_EarthToMoon

Три різні стилі, але ви точно знаєте, що кожен робить.

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

Я, як правило, віддаю перевагу camelCase з нерозумної причини, що більшу частину свого розвитку я роблю в Eclipse (для Java, PHP та JavaScript), і коли я Ctrl+ ←або Ctrl+ →через слова, він фактично зупиняється на межах camelCase.

Тобто: myIntVariableEclipse трактуватиметься як 3 слова, коли Ctrl+ ← →'проходить через нього.

Я знаю, що це дивна химерність, але я вважаю, що волію редагувати середні слова в імені camelCase.