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

>«пахнет указателем на unsigned int»

«Я люблю запах NULL dereferece поутру»

>>Если могут, по почему все пишут код с этими префиксами?

кто все?

Не прикапывайся. Я постоянно на практике встречаю такое. Получается они все используют неправильные IDE?

Кстати, кто знает как такую технику прикрутить к vim?

>Не прикапывайся.

Уж какие тут шутки

Я постоянно на практике встречаю такое.

Под венду програмишь шоле?

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

Надо Гвидо предложить Ыфкуиль :)

>CamelCase немногим младше Си

CamelCase (конкретно - UpperCamelCase) намного старше Си. Ибо он пришёл из докопьютерной поры :)

>> Лисповый стиль самый приятный, факт. Но мало где доступен.

О чём речь, где почитать?

Дык, что там читать, в емаксовый конфиг загляните. Например: auto-save-list-file-name - и читается легко, и набирается. Но в большинстве языков дефис зарезервирован, потому облом.

> Я недавно размышлял на тему имён переменных и пришёл к выводу, что всякие 'g_' и т.п. префиксы идеологически неправильны, т.к. получается в одну сущность (название переменной/функции/т.п.) помещаются избыточные данные (характеристики). И правильно было бы отображать эти характеристики каким-то специфическим способом (не знаю, может цветом или значком или как ещё)

Есть такой дядька-хакир Ларри Уолл, так он как раз придумал информацию о типе в виде смешных значков хардкодить. Это конечно смотрится забавно, но сильно подрывает идею полиморфизма. Хорошо ещё в те времена не было юникода...

зачемвообщепользоватьсяненужнымисимволами.lowercaseбезпробеловотличночитается.

> И правильно было бы отображать эти характеристики каким-то специфическим способом (не знаю, может цветом или значком или как ещё). Кто-ть встречал реализации таких идей?

Не вполне понятно, что вам нужно, но может colorForth (http://en.wikipedia.org/wiki/ColorForth) подойдет?

Ну, хотя бы, Practical Common Lisp.

Специально для вас [C,C++] Партизанская нотация (комментарий)

Гораздо проще сделать это на elisp, нежели на скриптовом виме.

Сам долго был фаном последнего, но убедился в перспективности емакса.

Вим(ви) использую только для правки конфигов в консоле, не более.

Мне лично верхний, не поверишь :)

> CamelCase (конкретно - UpperCamelCase) намного старше Си. Ибо он пришёл из докопьютерной поры :)

Snake case тоже.

Кстати, вот что нашел:

Please use underscores to separate words in a name, so that the Emacs word commands can be useful within them. Stick to lower case; reserve upper case for macros and enum constants, and for name-prefixes that follow a uniform convention. For example, you should use names like ignore_space_change_flag; don’t use names like iCantReadThis.

Richard Stallman, GNU Coding Standards.

Но он все же на это со своей колокольни смотрит.

Но он все же на это со своей колокольни смотрит.

Для Emacs есть режим c-subword-mode для перемещения по идентификаторам в CamelCase.

Я использую разные нотации в зависимости от языка и принятого кодингстайла. Например, для одних и тех же плюсов юзались camelCase на работе и snake_case дома

>Для Emacs есть режим c-subword-mode для перемещения по идентификаторам в CamelCase.

Но это не от хорошей жизни, имхо.

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

Но это не от хорошей жизни, имхо.

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

У каждого языка или фреймворка есть свой коде стайл, на каком пишу, тот коде стайл и использую

А если в проекте используются библиотеки с разным стилем?

> Linux style, если честно, немного бесит, например эта часть:

Эта часть - самая лучшая часть во всём LKCS, а сам LKCS очень и очень не плох.

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

У лисповцев наверное какая-то особая, элитарная раскладка, где скобки набираются без шифта.

С гипером+супером+метой. (у труЪ - space-kadet keyboard)

>Есть такой дядька-хакир Ларри Уолл, так он как раз придумал информацию о типе в виде смешных значков хардкодить.

Вот какраз когда я писал на перле, у меня эта идея и возникла. Там это решено лишь частично.

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

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

? :)

* (defvar |Определённо, лучше всего именование сделано в Common Lisp| t)

|Определённо, лучше всего именование сделано в Common Lisp|
* |Определённо, лучше всего именование сделано в Common Lisp|

T

Мог бы и на уровне парсера ограничить стиль именования

это не дело парсера ни разу, чувствуешь баттхёрт на эту тему - юзай pylint

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

видел в толстом коммерческом пакете, такие штуки HC_Do_Some_Stuff(), так имхо лучше

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

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

hindustan residents only

http://www.python.org/dev/peps/pep-0008/