LINUX.ORG.RU
ФорумTalks

Верблюды для кода

 


0

0

Предположим, вам дали бы выбор из двух вариантов: использовать в коде ТОЛЬКО UpperCamelCase или ТОЛЬКО lowerCamelCase (т.е. это теоретический, а не реальный юзкейс). Что лучше с вашей точки зрения и почему?

Просто был удивлен, недавно, что оказывается есть люди которым «нижний верблюд» не нравится.

Deleted

Последнее исправление: myLogin (всего исправлений: 3)

underscores_are_better

inb4: глаза не вытекают, читатели не жалуются.
inb4: забиндено на <Ctrl>+<Space>.

E ★★★
()

1) Существует множество языков есть где микс из UpperCamelCase и lowerCamelCase.
2) Почти всегда с языком/платформой идет code style, в котором указаны рекомендации именования функций, классов и их членов.

Aber ★★★★★
()

Предположим, вам дали бы выбор из двух вариантов: использовать в коде только UpperCamelCase или только lowerCamelCase.

Написал бы заявление по собственному желанию в тот же день. С придурками лучше дел не иметь.

morse ★★★★★
()
Ответ на: комментарий от Aber

Существует множество языков есть где микс из UpperCamelCase и lowerCamelCase.

Пофиксил стартовый пост, чтобы было понятней:

ТОЛЬКО UpperCamelCase или ТОЛЬКО lowerCamelCase (т.е. это теоретический, а не рельный юзкейс)

Deleted
()

UpperCamelCase - мета сущности - классы\интерфейсы\трейты\модули\шаблоны\миксины\модули\пакеты\етк

lowerCamelCase - имена одиночных функций\переменных\методов

int64
()

выбор из двух вариантов

Пошел бы на принцип и использовал бы идентификаторы из одного слова.

int64
()
Ответ на: комментарий от Deleted

ТОЛЬКО UpperCamelCase или ТОЛЬКО lowerCamelCase (т.е. это теоретический, а не рельный юзкейс)

Тогда согласен с morse.

Aber ★★★★★
()

Хорошая попытка начать срач.

Deleted
()

мне не нравится верхний верблюд.

bvn13 ★★★★★
()
Ответ на: комментарий от E

забиндено на <Ctrl>+<Space>

что забиндено, подчерк? тогда замечу, что для поганого camelCase можно забиндить Shift на пробел и набор вообще почти не будет отличаться от черезпробельного.

t184256 ★★★★★
()
Ответ на: комментарий от Deleted

Да, действительно очень некрасиво, особенно в связке с кучей stl-ного кода, или в легаси-портянках, например.

Мотивирует писать чистый код.

E ★★★
()

Со Spaces vs tabs определились, пришло время найти новую тему для холивара!

По теме. ПО не разрабатываю, если пишу скрипты то функции/переменные называю одиночными словами.

Deleted
()

удивлен

удивлен... удивлен это когда в проекте сотни issues, а в истории изменений сверху висит «Change C++-style variable names» и переменные переименованы с типа btnDontDisturb на типа button_mute. Зато по фэншую теперь, надо полагать.

Deleted
()
Ответ на: комментарий от BceM_IIpuBeT

Ну тут tailgunner очень эмоционально среагировал на lowerCamelCase. Мне стало интересно, почему. Вроде ведь очень удобно. Легко набирается и не создает лишнего визуального шума.

Deleted
()
Ответ на: комментарий от Deleted

То, что имена переменных - дело 100500-ое по важности - понятно

Имена переменных это одна из двух первоочередных проблем программирования. Так что, пожалуйста, поаккуратнее с такими заявлениями.

int64
()

myLogin

По феншую, правда очень древнему. Префикс my в стародавние времена пользовали чтоб в коде отличать поле класса от переменной и аргумента метода, еще бывали префиксы our, такие служили для обозначения статических полей.

Aber ★★★★★
()
Ответ на: комментарий от int64

Тоже вполне допускаю. Просто у меня не хватает компетентности чтобы о таком всерьез рассуждать.

Deleted
()
Ответ на: комментарий от Aber

В каком-то проекте видел, что люди добавляют к переменным первые буквы имени и фамилии. Для John Doe это будет jdFoo. Возможно, это была чья-то шиза.

Еще одна практика, которая полезна для начинающих (и для демонстрационных примеров) - это нарочито странные/идиотские имена. Чтобы не спутать их со встроенными в язык словами.

Deleted
()
Ответ на: комментарий от Deleted

В «чистом коде», вроде, обобщили многие моменты с именованием.

По сабжу: и lowerCamelCase и UpperCamelCase взаимодополняют друг друга. И underscore. И префиксы. Главное - чтоб порядок был во всем этом. Встречал g_globalVarName, e_enumConstName, s_structName и тп. Не раздражало, а оч даже втянулся.

Deleted
()

использовать в коде ТОЛЬКО UpperCamelCase или ТОЛЬКО lowerCamelCase

там наверно еще и vscode пропагандируют?

я бы поджог офис.

Rastafarra ★★★★
()

Нинужно

Вопрос теоретический до полной бесполезности. Использовать надо и camelCase, и CamelCase, и CAPITALS_WITH_UNDERSCORE, и under_score. Каждый стиль для какой-то цели.

Camel ★★★★★
()
Ответ на: комментарий от Deleted

Не шутка

Это совсем не шутка. Придумывать понятные не только автору имена действительно сложно.

Camel ★★★★★
()

Надо сделать какой-нибудь бинарный формат для исходников, чтобы форматирование (стиль) у каждого пользователя было, как настроишь

TheAnonymous ★★★★★
()

По возможности использую lowerCamelCase для всего, кроме статиков. А для статиков использую UpperCamelCase.

andreyu ★★★★★
()

Что лучше и почему?
И как на это ответить? Кому как удобно так и пишут. К тому же есть рекомендации по языку, где эти правила описаны.
И желательно придерживатЬся их.

tyamur ★★
()
Последнее исправление: tyamur (всего исправлений: 1)

Первое. Потому что я хочу тебе насолить.

Deleted
()
Ответ на: комментарий от tailgunner

underscores_are_better

Читабельность не лучше, чем у lowerCamelCase

ничегоПодобногоЧитабельностьГораздоЛучше.

Ничего не понял, читабельность какого варианта для вас лучше?

andreyu ★★★★★
()
Ответ на: комментарий от andreyu

Ничего не понял

Считаем доказанным факт, что понимание текста, написанного нижнимВерблюжьимКейсом, затруднено.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Считаем доказанным факт, что понимание текста, написанного нижнимВерблюжьимКейсом, затруднено.

То бишь для вас кемел кейс затрудняет чтение?

andreyu ★★★★★
()
Ответ на: комментарий от andreyu

То бишь для вас кемел кейс затрудняет чтение?

Для меня, по сравнению со snake case - да, конечно. И для тебя^Wвас - тоже.

tailgunner ★★★★★
()

мне вообще никакие верблюды не нравятся. подчёркивание и строчные буквы - более чем достаточно. но есть такие языки, в которых типизация через жопу и флоат может стать интом или даже строкой без явного намерения. и вот там приписывание всяких префиксов о типах к переменным - вопрос выживания. наверное, там верблюды имеют свой логический смысл.

Iron_Bug ★★★★★
()
Ответ на: комментарий от andreyu

а не надо а) создавать километровые имена переменных б) писать дико вложенные циклы и кодолапшу. даже с табами по 8 ширины экрана в 80 символов хватает на всё. за глаза. это при правильном разбиении кода на функции. код без излишеств повышает читабельность и не требует комментирования, в большинстве случаев.

Iron_Bug ★★★★★
()
Ответ на: комментарий от andreyu

Читабельность не лучше, чем у lowerCamelCase

На самом деле лучше, слова чётко отделены друг от друга. Сложнее пропустить опечатку в аббревиатуре внутри длинных идентификаторов. Особенно вроде GetSomethingLocalShiftXForExample/GetSomethingLocalShiftYForExample

E ★★★
()
Ответ на: комментарий от tailgunner

И для тебя^Wвас - тоже.

Для меня равнозначно. Ваш вывод основан на ...на чем он основан?

andreyu ★★★★★
()
Ответ на: комментарий от Iron_Bug

а не надо а) создавать километровые имена переменных

Ну да, i, j, k хватит всем.

б) писать дико вложенные циклы и кодолапшу.

Как это связано с именем переменной?

даже с табами по 8 ширины экрана в 80 символов хватает на всё.

Как это связано с именем переменной?

это при правильном разбиении кода на функции. код без излишеств повышает читабельность и не требует комментирования, в большинстве случаев.

Как это связано с именем переменной?

andreyu ★★★★★
()
Ответ на: комментарий от E

На самом деле лучше, слова чётко отделены друг от друга.

Вместо spirteWidth вы используете redSpriteWidthFromGlobalListCalculatedEachFrameIndependentFromTimeDeltaAsFloatValue?

Особенно вроде GetSomethingLocalShiftXForExample/GetSomethingLocalShiftYForExample

Крайности в обоих случаях отвратительны.

andreyu ★★★★★
()
Ответ на: комментарий от andreyu

Как это связано с именем переменной?

а в чём ещё могут быть проблемы с длиной? я вот сколько лет программирую, никогда не было тяги к написанию километровых названий переменных. и да, внутри функций отличные названия переменных i, j, k. при этом функция должна влезать в один экран, в идеале.

Iron_Bug ★★★★★
()
Ответ на: комментарий от E

Составные идентификаторы более чем из 2-3 слов указывают на прогрессирующую деградацию личности и должны быть запрещены межгалактическим стайлгайдом независимо от кейса. В оставшихся случаях читабельность эквивалентна, плюс минус, вплоть до принципиальной неотличимости в случае идентификаторов из одного слова. С этой т.з. кстати lCC лучше UCC так как обратно совместим с s_c.

d_a ★★★★★
()
Ответ на: комментарий от Deleted

Ну тут tailgunner очень эмоционально среагировал на lowerCamelCase.

А кто это?

d_a ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.