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

Это вопрос кодстайла. Очень удобна, например, венская конвенция венгерская нотация. 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-функции классов аргументов). Не знаю даже, забыл ли что, нагромождено много... И практически чёрно-белый текст программисту читать не разделяя на перечисленные три "типа" имён -- тяжело. Компилятор понимает из контекста (да и то не всегда так как программист, есть фокусы вроде таких: https://en.wikiped …iki/Most_vexing_parse, и таких: https://eli.thegre …le-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 стоило бы брать отдельную плату...