[C,C++] Партизанская нотация

>gPtrArrayNewWithFreeFunc

g_ptr_array_new_with_free_func

ИМХО второе гораздо читаемее.

оба нечитабельные - зачем полное название типа в имя переменной тулить

NameWithABBREVTailOfName

Это имя функции, а не переменной.

shit

ИМХО, верблюжийРегистр читабельнее, его и придерживаюсь.

Не, ну это откровенная симуляция нечитабельного уродского имени переменной.

В продолжение дискуссии: почему в том же расово верном С в рекомендациях к стилю прописано использовать «_» вместо верблюжатника, а в нелюбимом мною С# - все, как я описал выше про интерпрайз. Неужели домохозяйкам так читабельнее?

>Не, ну это откровенная симуляция нечитабельного уродского имени переменной.

Это не переменная, блин. Нормальное имя, сокращать не куда.

Раз уже начали, а что она делает, то есть, что означает ее имя?

g_ptr_array_ - префикс, означает что функция относится к классу GPtrArray.

new_with_free_func - значит создать новый GPtrArray с функцией освобождения элементов.

>префикс Специально для вас, Козлов, придумали классы и пространства имен.

с функцией освобождения элементов

на это должен указывать тип

Специально для таких, как ты, придумали С++, а это С.

Какие классы и пространства имен в C? Деструкторов в C тоже нет.

>У меня сложилось впечатление, что стиль программирования «а-ля Linux» - н-р, some_fucking_function

Вообще-то, это snake_style (snake_case).

Я одинок с этой мыслью?

Есть две непримеримых школы. Каждая аргументированно доказывает свою правоту. Я принадлежу к школе snake :) Она лучше учитывает особенности восприятия homo sapiens европейского разлива.

Какая мне разница? Код - говно. То что он на C это отягощающее обстоятельство.

>оба нечитабельные - зачем полное название типа в имя переменной тулить

Венгерская нотация. Наследие языков с плохой типизацией :)

У гугла в style guidelines переменные назваются через подчеркивание, а все остальное в camel case

>У гугла

Гугл для меня не авторитет :) Кроме него есть ещё много разных корпораций, которые нередко даже в процессе своего существования меняют стилистику :D

http://local.joelonsoftware.com/wiki/%D0%9A%D0%B0%D0%BA_%D0%B7%D0%B0%D1%81%D1...

На C я всегда пишу snake_case, на C++ CamelCase(как в Java). Так уж привык, и проблем не возникает.

Это просто пример сочетания обоих стилей.

cum_on_her_tits() выглядит таки лучше, нет гребаных капиталов, уродлящих строку.

Коды linux написаны в стиле snake, все сисвызовы тоже, а вот у майкрософта, еяпп, все наоборот, т.е. они используют camel.

>Это просто пример сочетания обоих стилей.

Ну, с ним ещё постоянно в Питоне том же сталкиваешься. Например, в Django.

Да даже в PHP часто оба стиля смешиваются. Даже в рамках базового синтаксиса языка. array_push(), скажем, но getImageSize() :)

Самое неприятное, это когда кодовую базу, исполненную в одном стиле, «партизаны» дописывают в другом, обосновывая выбор религиозными мотивами. Вот тогда полный атас получается. Да и для новых проектов (по крайней мере для публичного API) лучше выбирать стиль, принятый в стандартной библиотеке языка.

Мне кстати, не кажется что snake_case сильно лучше читается. Хотя к camelCase есть серьёзная претензия: аббревиатуры и двухбуквенные слова уродуются. Так что при прочих равных выберу всё же snake_case.

> Да даже в PHP часто оба стиля смешиваются. Даже в рамках базового синтаксиса языка. array_push(), скажем, но getImageSize()

Во-во, это и есть самое большое уродство. Python так вообще помойка в этом смысле, что удивительно, учитывая bondage&discipline наклонности Гвидо. Мог бы и на уровне парсера ограничить стиль именования, фанбои бы наверно радовались очередному откровению :)

>Мне кстати, не кажется что snake_case сильно лучше читается

НуТакСамПроверьКакойТестПрочестьПроще

такой_как_выше_или_такой_как_тут

? :)

>Python так вообще помойка в этом смысле, что удивительно, учитывая bondage&discipline наклонности Гвидо.

Дык, просто Гвидо делает ставку на snake_style. А вот разработчики сторонних библиотек - на camelCase. Вот и возникает мешанина...

По мне так одинаково, честное слово. Может потому, что я последние пару лет работаю только с кодом в camelCase. Проще всего всё же с пробелами и знаками препинания :)

Для функций записываю так: someFuckingFunction(), для переменных - some_fucking_variable. Для шаблонных классов так же, как функции.

> Дык, просто Гвидо делает ставку на snake_style. А вот разработчики сторонних библиотек - на camelCase.

Да у них даже внутри одной библиотеки порой разброд и шатания. Не очень много кода на PHP видел, но по-моему даже там лучше в этом плане.

>Для шаблонных классов так же, как функции.
А для не шаблонных?

>А для не шаблонных?

пардон, это для обьектов шаблонных классов. все типы классов начинаю как SomeFsckingClass. Иногда вставляю префикс имени программы, как в Qt. Например QMCVideoCodecLavc.

У CamelCase есть одно маленькое преимущество: с моноширным шрифтом переменные выглядят компактнее, а в остальном оба стиля вполне читаемы. В таких случаях понимаешь, что иногда лучше пожертвовать свободой и форсировать определённый indent и case чтобы не было «разброда и шатания».

Мне больше нравится the_function_with_a_lot_of_chars(), чем theFunctionOfALotOfChars - прочитать проще, все-таки, имена файлов именно так и пишутся - с разделением подчеркиванием..

Мне нравится подчёркивание, оно визуально похоже на пробел, и читать идентификаторы несколько проще. Но большинство кода использует camel :(

есть компромисс: some_Fucking_Function()

>some_fucking_function(), присущ только «партизанам» - программистам OpenSource
в Qt и KDE например camelCase

нечто в стиле Java, в стиле из книги Макконнелла

почему то именно жабокодеры чаще всего думают, что все значимые вещи придуманы жабокодерами. Я одинок с этой мыслью?

скорее маразм, сочетающий недостатки обоих стилей

Уважаемый в топиксратере вы видите пример кодера кой считает что snake_case придуман «партизанами», так что не важно на каком языке кодит члест - ограниченной мировоззрение всегда его выдаст.

А ну брысь в дупло, белка!

>Дык, просто Гвидо делает ставку на snake_style. А вот разработчики сторонних библиотек - на camelCase. Вот и возникает мешанина...

Блин! Крон я тебя конечно уважаю, но осиль уже pep8. Там черным по белому написано, что для имен классов рекомендуется CamelCase, а для функций и методов snake_case.

имен классов рекомендуется CamelCase, а для функций и методов snake_case.

А переменные писать на хинди?

Белкам разрешено только на Санскрите!

CamelCase настолько читаем, что в Emacs даже есть специальный режим: glasses minor mode makes ‘unreadableIdentifiersLikeThis’ readable by altering the way they display.

>Мог бы и на уровне парсера ограничить стиль именования, фанбои бы наверно радовались очередному откровению

+1, было бы логичным продолжением отступов

> осиль уже pep8. Там черным по белому написано, что для имен классов рекомендуется CamelCase, а для функций и методов snake_case.

Потому что Гвидо мудр.

Поклоняетесь авторитетам, уважаемый, а как вы объясните столь неадекватный стиль кодирования предложенный гвидо?

Почему не было ни одного поста о гениальности принятого стиля в Lispe?

Так я начну. Там все решено вообще просто: не в коем разе не юзать кнопку шифт вообще, а пользоваться "-". Этот стиль самый грамотный имхо, поэтому, перенося его на С, получаем использование «_»

??????????

PROFIT!!!!!

>не в коем разе не юзать кнопку шифт вообще

получаем использование «_»

не юзать кнопку шифт

fail

Уважаемый - набирается в одно нажатие, а _ требует комбианции клавиш, думайте.