Локальная терка "о стилях"

Во многих ЯП допускается разное многообразие оформления идентификаторов. В настоящий момент превалирующими способами можно отметить три:

1) идентификатор_со_знаками_подчеркивания
2) ИдентификаторРазныхНаборовСимволов
3) "Малобуквенный" идентификатор + коментарии

Понимаю, субъективно просто адово ... тем не менее, ваш выбор?

Подстраиваюсь под язык. Сам предпочитаю CamelCase, но в сях могу вполне и на under_score перейти.

Скрытый текст

Цитата Da$aD @ 27.11.15, 18:30

Подстраиваюсь под язык. Сам предпочитаю CamelCase, но в сях могу вполне и на under_score перейти.

пасип

Как принято в проекте - так и пишу. Сам предпочитаю стиль Qt.

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

snake_case
Хотелось бы kebab-case

Google Code Style for C++ вообще сочетает в себе оба варианта
переменные и поля с_подчёркиваниями, а имена методов (кроме геттеров_и_сеттеров) - ВПаскальКейсе.

но я не уверен, что мне это нравится

хотя по факту мне не принципиально как писать

если бы я выбирал - писал бы всё как в Java/Qt.

1С голосует за СтрочныеИПрописныеБуквы.

Для классов РазнаяВысота
Для переменных_подчеркивание

Но опять же, да зависит от языка
На пыхе как описано выше
На Qt первый вариант

Цитата Алексей_Л @ 28.11.15, 20:03

Google Code Style for C++

Крайне сомнительный документик.

Только второй вариант. Недолюбливаю подчеркивания (и их приверженцев)

Кстати да. Давно хотел сесть и решить для себя, что мне нравится.
А то использую всё подряд вперемешку.
Хотя нет, в последнее время чаще был CamelCase.

Только что-то аргументов в теме пока нет...
Вот глянул википедию:

Цитата

По результатам по крайней мере одного исследования, читатели гораздо быстрее воспринимают информацию, написанную в snake_case, чем написанную в CamelCase.

По моим наблюдениям, проблема проявляется в случае когда первое слово заканчивается на "высокие" символы.
Например ScrollItems. Всё-таки Scroll_Items читабельней.

Но с другой стороны, ИМХО, есть что-то отталкивающее в подчёркиваниях.
Только не могу уловить что. Разумных доводов нет...

Цитата B.V. @ 29.11.15, 21:06

Недолюбливаю подчеркивания

А за что?

Цитата SV() @ 30.11.15, 09:20

Цитата B.V. @ 29.11.15, 21:06

Недолюбливаю подчеркивания

А за что?

Скорее всего, из-за тяжёлого вендового детства.

Цитата B.V. @ 29.11.15, 21:06

Недолюбливаю подчеркивания (и их приверженцев)

Можно подробнее?

константы так: CONST_VALUE
все остальное преимущественно CamelCase

Цитата SV() @ 30.11.15, 09:20

А за что?

За неэстетический вид кода. Всплывают ассоциации автомобиля, сваренного из арматуры, где из каждого прибора на панели торчит болт или шестеренка.

Цитата D_KEY @ 30.11.15, 13:44

Можно подробнее?

Моя практика показывает, любители подчеркиваний оказываются любителями линукса и командной строки. У них свое, особое видение эстетики кода.

Цитата B.V. @ 30.11.15, 16:51

Моя практика показывает, любители подчеркиваний оказываются любителями линукса и командной строки. У них свое, особое видение эстетики кода.

Скорее всего дело не в подчеркивании. Исторически все исполняемые файлы *nix'ов (а раньше вообще все) принято было писать, используя только нижний регистр. Хотя никто не мешал использовать и смешанный. Поэтому файлы часто именовались по варианту №1. Возможно именно это явилось причиной выбора и при кодировании варианта №1.

Лично я стараюсь использовать по возможности №3 вариант, либо №2. Личная практика показала, что локальные переменные выгодно объявить по возможности 1-м символом, максимум - 2 и обязательно дать расшифровку комментарием. Потом быстрее и короче код в выражениях и понятность выше. Естественно, если количество переменных в функции/методе зашкаливает (для меня порог 16-20) - значит код требует переработки. Во всех остальных случаях (исключая константы и макросы) - использую №2. Это глобальные переменные, структуры, классы, методы ...

ЗЫ: Не люблю мелкомягкий подход привнесения информации о типах в имя переменной в виде префикса.

ЯПишуВсеСлитноОченьЭстетичноВыглядитАга)

Цитата Kray74 @ 01.12.15, 02:27

ЯПишуВсеСлитноОченьЭстетичноВыглядитАга)

Осталось добавить:
return WBR::__Zurab__Tsereteli__ << 2;

Кстати, а кто как файлы именует? Лично я если сам код ПишуТак, то называния файлам даю_такие.

Цитата B.V. @ 30.11.15, 16:51

Моя практика показывает, любители подчеркиваний оказываются любителями линукса и командной строки.

Так это же хорошо

Цитата

У них свое, особое видение эстетики кода.

Поясни, пожалуйста.

вспомнилось: http://habrahabr.ru/company/yandex/blog/210638/

Неужто бот сподобился на пост со смыслом? Глазам не верю. Делает успехи, скоро тест Тьюринга наполовину сумеет пройти.

Цитата Qraizer @ 01.12.15, 13:38

Неужто бот сподобился на пост со смыслом? Глазам не верю.

Да, несмотря на общность его утверждения, сюда оно весьма кстати попало.

Цитата Qraizer @ 01.12.15, 13:38

Неужто бот сподобился на пост со смыслом? Глазам не верю. Делает успехи, скоро тест Тьюринга наполовину сумеет пройти.

Цитата Славян @ 01.12.15, 14:08

Да, несмотря на общность его утверждения, сюда оно весьма кстати попало.

Игра случая

Скрытый текст

Обычно при именовании методов/функций/классов использую Верблю́жийРеги́стр, но иногда могу в начале сделать подчеркивание, дабы подчеркнуть - что это именно метод класса, а не какая то там локальная или глобальная переменная.
Пробовал писать с нижними подчеркиваниями - код получается вырвиглазный.

Цитата KILLER @ 03.12.15, 14:28

иногда могу в начале сделать подчеркивание

Кто-то где-то вечно советует не делать свои подчёркивания первыми - a'la резерв за языком или что-то вроде того.

Цитата KILLER @ 03.12.15, 14:28

Верблю́жийРеги́стр

но иногда могу в начале сделать подчеркивание

Не надо так

Цитата

17.6.4.3.2 Global names [global.names]

Certain sets of names and function signatures are always reserved to the implementation:
Each name that contains a double underscore __ or begins with an underscore followed by an uppercase letter (2.12) is reserved to the implementation for any use.
Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace

Цитата

Any other predefined macro names shall begin with a leading underscore followed by an uppercase letter or a second underscore

Ну после подчеркивания я обычно маленькую букву пишу. Просто я целый год на явошарпах писал, а там как раз, по крайней мере у нас было принято члены класа начинать с подчеркивания. А так обычно в плюсах всегда члены класа начинал с m_членКласса. Это уже в последнее время что то поперло у меня по привычке после шарпа писать просто подчеркивание. Но да, надо отучаться.

Сообщение отредактировано: KILLER - 03.12.15, 17:12

Цитата Славян @ 03.12.15, 15:06

Кто-то где-то вечно советует не делать свои подчёркивания первыми - a'la резерв за языком или что-то вроде того.

А у нас есть один разработчик, который всё время в переменных первое подчеркивание ставит (а главное в названиях своих объектов, в результате чего они всё время в списке в начале стоят).
Я раньше думал что он тупо выпендривается, а теперь понял, что это он язык резервирует...

Добавлено 03.12.15, 17:49

Цитата OpenGL @ 01.12.15, 06:42

то называния файлам даю_такие.

Кстати, забавно, я тоже. Хотя переменные во время разработки называю только CamelCase. Хотя в хранимых процедурах и скриптах Питона - через подчеркивание.

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

Цитата Dark_Sup @ 03.12.15, 17:45

а главное в названиях своих объектов, в результате чего они всё время в списке в начале стоят

А что за список?

Цитата D_KEY @ 03.12.15, 15:07

Each name that contains a double underscore __ or begins with an underscore followed by an uppercase letter (2.12) is reserved to the implementation for any use.

А можно пример более-менее реального случая, когда это помешает? Не то, что я собираюсь писать, начиная с подчёркивания - предпочитаю mЧтоТоТам - просто интересно

_Bool, появившийся в C99.

Ну мне вряд-ли придёт в голову так назвать переменную.
И это же reserved to the implementation, а значит там будут скорей какие-то компиляторозависимые фичи, а-ля __int64. И как мне кажется, вероятность пересечения пользовательских идентификаторов с такими достаточно низка.

Если её можно свести к нулю, зачем пренебрегать-то?

Цитата MyNameIsIgor @ 28.11.15, 01:44

Хотелось бы kebab-case

переходи-на-лисп =)
И наш мини-холивар по поводу скобочек разрешится сам собой. =)

В php принят PSR де-факто, так что lowerCamelCase для полей, переменных и методов, CamelCase для классов, under_score для глобальных функций и CAMEL_CASE для констант. Да и в JS\ES5\ES6 ситуация примерно аналогичная, только там ещё _lowerCamelCase для приватных полей\свойств\методов принят.

Добавлено 20.12.15, 01:55

Цитата OpenGL @ 01.12.15, 06:42

Кстати, а кто как файлы именует? Лично я если сам код ПишуТак, то называния файлам даю_такие.

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

Добавлено 20.12.15, 01:56
В случае JS именую так же, как именуется дефолтный экспортный класс внутри.

Добавлено 20.12.15, 02:01

Цитата B.V. @ 29.11.15, 21:06

Только второй вариант. Недолюбливаю подчеркивания (и их приверженцев)

С помощью подчёркиваний проще реализовывать метапрограммирование (например реализация мутаторов и акссесоров, особенно у каких-нибудь ActiveRecord моделей намного проще через some_field => get_some_field, нежели через some_field => getSomeField), плюс не стоит забывать про БД, у некоторых из которых имена целлов регистронезависимы. Хотя я согласен, мне тоже больше нравится lowerCamelCase

Сообщение отредактировано: Serafim - 22.12.15, 18:53

Цитата Serafim @ 20.12.15, 01:52

snakeCase

Вот snake_case. А это lowerCamelCase.

MyNameIsIgor, спасибо, поправил