16+
Пятница
19 июля
Вход |Карта сайта |Upload |codebook | PARTS

 О смысле всего сущего 0xFF

 Средства и методы разработки

 Мобильная и беспроводная связь

 Блошиный рынок Объявления

caxapa

Микроконтроллеры ARM 

AVR PIC MSP PLD,FPGA,DSP 

Кибернетика Технологии 

Схемы, платы, компоненты 

Средства и методы разработки

 
Новая темаПравила РегистрацияСтатистика Архив
Вернуться в конференциюТопик полностью
fk0  (14.03.2019 00:47 - 14.03.2019 01:04) , в ответ на Верно. Но почему-то самым популярным является какой-то особый С++ вид, с кучей больших букв в идентификаторах, к которому надо привыкать отдельно :( автор: Evgeny_CD
Это вопрос кодстайла. Очень удобна, например, венская конвенция венгерская нотация. LpZStrЁклмн ведь куда понятнее, чем просто "string"... 
Твои безумные идеи со спецредактором для программистов иногда начинают обретать смысл: дело в том, что в C и в C++ несколько ортогональных пространств имён: 1) типы/классы -- сущности момента компиляции; 2) их инкарнации момента времени исполнения -- объекты, функции, переменные; 3) макропроцессор. Причём по пункту 1 между C и C++ есть важное различие: пространство типов у C плоское и одно, на уровне единицы компиляции. У C++ возможны вложенные типы определённые внутри типа (класса, структуры). Ну и namespaces ещё (действующие и для типов, и для объектов). Объекты в C могут быть на уровне единицы компиляции или блока кода (которые могут быть вложенные, включая nested functions в gcc), в C++ добавляются вложенные в выражение лямбды, namespaces, в методах класса -- scope самого класса. А при выборе функций ещё argument dependent lookup, просматривающий в определённом порядке все namespaces связанные с аргументами (в которых определён тип аргумента или friend-функции классов аргументов). Не знаю даже, забыл ли что, нагромождено много... И практически чёрно-белый текст программисту читать не разделяя на перечисленные три "типа" имён -- тяжело. Компилятор понимает из контекста (да и то не всегда так как программист, есть фокусы вроде таких: en.wikipedia.org/wiki/Most_vexing_parse, и таких: eli.thegreenplace.net/2012/06/28/the-type-variable-name-ambiguity-in-c). Но современные редакторы, когда раскрашивают, они не понимают C++ или даже C. Они просто по наборы шаблонов/регэкспов находят текст и раскрашивают. Поэтому обычно принимают какой-либо кодстайл, где стремятся как-то выделить разные типы имён. Часто принимается следующее: 1) типы записываются в CamelCase с заглавной буквы; 2) объекты записываются в lowerCamelCase со строчной буквы, или в snake_case; 3) макросы обычно записывают в SCREAMING_SNAKE_CASE. В негативную сторону выделяется микрософт, использующий варианты с заглавной буквы так же и для функций (нижний регистр для переменных). Не знаю есть ли смысл отличать чистые функции и объекты (функторы с operator(), делегаты), по-моему скорей нет. По-моему больший смысл в том, чтоб отличать типы (классы момента компиляции) от объектов (функций, переменных, данных момента исполнения). Вот и весь смысл кучи больших букв. Когда всё записано в snake_case оно точно так же нечитаемо, как когда микрософт записывает всё в CamelCase. Но у каждого тут конечно своё мнение и можно долго спорить. Ещё члены класса, если их много и возникает name clashing с функциями (находящимися в одном пространстве имён с переменными) или аргументами, часто выделяют как-то. Варианты: дописать к каждому префикс "m_" (google), дописать к каждому суффикс "_", дописать к каждому префикс "_" (возникает риск name clashing'а с библиотечными функциями, переменными и макросами, которые начинают с подчёркивания). Можно ещё доллар использовать... В принципе достаточно "this->" или "ClassName::" спереди, но можно забыть и огрести. Компиляторы так же умеют предупреждать о name clashing'е. Так что я бы не дописывал всегда, а только уж если путаницы много. И было бы очень неплохо раскрашивать разные имена в редакторе в зависимости от типа (тип/класс, объект/функция/переменная, макрос, можно ещё выделить отдельно переменные класса, переменные функции и аргументы, глобальные переменные...) Но увы, я такого пока не видел. Или не замечал. И для этого существуют соглашения с вырвиглазным стилем наименования заглавными буквами. Вдогонку. Ещё есть вопрос именования файлов. Наверное имеет смысл придерживаться того как сделано в Java и если в файле ровно один класс, то именовать файл именем класса. Если несколько -- то именем модуля, пространства имён, чем-то, что уже как-то названо, а не изобретать отдельное имя. Отдельный вопрос по раскладыванию файлов в каталоги. Люди пришедшие из мира windows не в состоянии воспринимать файловую систему иначе как "папку" в которую они будут постоянно смотреть глазами. Поэтому плодят огромное количество каталогов когда совершенно не нужно, и неудобно в такой системе работать (постоянно то в один, то в другой руками заходить, как минимум). При нормальном восприятии файловой системы, когда НЕ пользуются Far, Total Commander, Midnight Commander, Norton и т.п. и понимают, что команда "dir" или "ls" это практически то же самое, что "SELECT * FROM DIRECTORY", и что Explorer в Windows не так уж плох и в отличии от многих "коммандеров" способен отобразить именно результат запроса, а не тупо список, при таком восприятии количество каталогов в принципе может стремиться к одному. Потому, что по сути система каталогов -- это та же "венгерская нотация" применённая ни к месту. Понятно, что отдельную библиотеку можно положить в отдельный каталог, и результирующие файлы в отдельный. Но у некоторых возникают 7-уровневые вложенные каталоги в которых потом сами путаются. Ещё есть вопрос именования Enum'ов. Поскольку они сущность момента компиляции, то скорей следовало бы использовать CamelCase. Но не SCREAMING_CASE, чтоб не путать с макросами. Почему названия обычно вырвиглазные -- система описанная выше не всеми программистами понимается, некоторые просто лепят код в CamelCase (многие...) не думая вообще. Просто потому, что у других так сделано. Это действительно тот случай, когда за нажатие на shift стоило бы брать отдельную плату...
[ZX]
Главная | Карта сайта | О проекте | Проекты | Файлообменник | Регистрация | Вебмастер | RSS
Лето 7527 от сотворения мира. При использовании материалов сайта ссылка на caxapу обязательна.
MMI © MMXIX