Последнее время по большей части следую Google C++ Style Guide с некоторыми модификациями в именовании файлов, в ряде случаев использую статические объекты нетривиальных типов (если уверен, что ничего не сломается — кодовая база детских размеров). Единственные префиксы, которые использую, применяются к параметрам функции:
i_ — входные параметры;
o_ — выходные параметры;
io_ — параметры с двухсторонним потоком информации, если можно так сказать.
В большинстве случаев параметры входные, остальные два типа используются довольно редко, чаще всего для мнимой оптимизации либо при перегрузке функций-членов в классах, унаследованных от классов из сторонних библиотек.
Мне кажется, что на самом деле лёгкого ничего нет. Фактически, Вы предлагаете потратить огромное количество времени на разработку никому не нужных инструментов, которые не позволяют получать большую прибыль с меньшим вложением средств, но требуют вложения средств в поддержку этих самых инструментов. При этом проблемы возникнут не только у разработчиков данных инструментов, но и у всех разработчиков прикладных библиотек: если раньше можно было написать документацию один раз и, максимум, перевести тексты описаний на другие языки, то теперь требуется ещё и код переводить. Да, часть кода будет переведена автоматически, но дальше перевода ключевых слов вы этого сделать не можете. Следовательно, требуются специалисты, говорящие на целевом языке, чтобы перевод идентификаторов и наименований функций был осмысленным. И это очень много работы, причём непрерывной и подверженной ошибкам.
Не забывайте, что использование «англоязычных» языков программирования, а также использование английского языка для именования переменных и комментариев позволяют в случае необходимости аутсорсить разработку в другие страны, если это экономически оправданно. Никто не любит так называемый «индусский код», аутсорсить в другие страны не патриотично, т.к. не создаёт рабочих мест в «родной» стране компании, но зачастую это экономически выгодно. При этом, насколько я понимаю, может происходить и с продуктами, которые не выходят за пределы использующей их компании.
Странно слышать какие-то утверждения про инженерную школу от человека, который, очевидно, сам инженером не является, даже на уровне самоучки. Отказ от использования готовых, проверенных временем инструментов, от использования в разработке общепринятых подходов программной, на минутку, инженерии, попахивает чем-то очень далёким от инженерного подхода к решению задачи.
«Дешёво»?
При просмотре кода становится очевидно, что это что-то не дешёвое. И главная причина — низкое качество самого кода. Например, функция com_compile. Это кошмар на 500+ строк с множеством вложенных ветвлений. Написать такую функцию один раз может быть и «просто и дёшево», в чём я сомневаюсь. Но поддержка подобного кода обойдётся во много раз дороже, чем поддержка любого из предложенных в комментариях «плохого и сложного» решения.
«Надёжно и работает»?
Работает — может быть. Но работает, очевидно, как-то. Явно не надёжно. И причина этого в низком качестве кода, которое было Вам продемонстрировано на примере скриншота, где большая часть кода подсвечена, как содержащая потенциальные ошибки. Профессиональные разработчики стремятся к минимизации количества предупреждений от инструментов анализа, в идеале — к полному отсутствию таких предупреждений.
Ох, насколько же движки больная тема. Смотришь на Unreal и не знаешь, что с ним делать. С одной стороны, куча инструментов, сообщество, готовое решение 80% всех возможных задач. С другой стороны, тесная интеграция с Physx, трудности с использованием сторонних библиотек и невозможность встраивания в ПО без переписывания самого движка.
Разве необходимо что-то делать с std::auto_ptr? Насколько я могу судить, std::auto_ptr используется только в случае, если не доступен std::unique_ptr, т.е. при сборке в режиме C++98/03. Или я что-то упускаю?
P.S. Можно не открывать Visual Studio для сборки:
cmake --build . --config Release
(вместо Release можно использовать Debug, RelWithDegInfo, MinSizeRel или другой конфигурации сборки. Мелочь, конечно, но из терминала использовать удобнее получается.
Примерами плагинов, так или иначе использующих различные варианты IPC, являются:
ycmd, предоставляющий сервис автодополнения, и интегрируемый в текстовые редакторы через плагины, общающиеся с ycmd-сервером через http;
языковые серверы, предоставляющие сервисы работы с проектами на различных языках программирования, ингенрируемые в редакторы через плагины, общаяющиеся с сервером через LSP;
NeoVim, в котором даже интерфейс работает через IPC;
Можно, конечно, поспорить, что ycmd и LSP-серверы не являются плагинами и т.п., но, на мой взгляд, они отражают идею по-настоящему универсальных плагинов, которые можно интегрировать буквально куда угодно. Подобные возможности интеграции обеспечиваются в первую очередь тем, что взаимодействие построено на основе IPC.
А зачем российским спецслужбам информация о переписке пользователей, которые находятся вне юрисдикции России?
С одной стороны — и правда, ни за чем. С другой стороны, террористические атаки вполне могут планироваться за границей. Информация о подобных приготовлениях вполне может передаваться по каналам содействия спецслужб государств. Соответственно, спецслужбы некоторой страны, где происходит подготовка, могут предоставить информацию российским спецслужбам, которые смогли бы запросить информацию у Telegram.
Я не буду вспоминать про то, что спецслужбам США, например, везде и до всех есть дело. Я не считаю это и поведение США в подобных вопросах правильным, и уж тем более не хочу, чтобы страна, в которой я живу, подобным образом позорилась, просто констатирую факт.
Ведут себя, как дети малые: «Мы будем сливать информацию о пользователях хорошим дядям из спецслужб „правильных“ государств, а этим букам, законно требующим информацию о переписке пользователей и законно блокирующим наш сервис за неподчинение решению суда — нет!»
«Ковровые бомбардировки» РКН — это плохо, но сокрытие информации о лицах, подозреваемых в терроризме, по причине какой-то глупой обиды и столь же глупых убеждений — верх инфантильности и слабоумия.
Интересная идея. Напоминает мне разговоры на тему проблем чёрных в США: Правозащитники настаивают, что чернокожие должны получать бесплатное образование и т.п., потому что их предки находились в рабстве, что негативно сказалось на социальных возможностях данной части населения. В целом — справедливо. Однако, когда современные негры (не все, разумеется) становятся преступниками, бросают женщин с детьми, говорится, что это всё виноваты белые («white privilege»). А когда людям, утверждающим это, задаётся вопрос, мол, а что мешает современных чернокожим получать образование, не вставать на пусть преступности и т.п. — ведь преград нигде нет — начинается повторение мантры про привелегии белых и несправедливость общества.
Так и у Вас: виновато государство, потому что люди сами не могут принимать правильные решения. По-моему, если человек не понимает, что убивать нельзя, воровать нельзя, нарушать закон — нельзя, то это вина в первую очередь самого человека и среды, в которой он был воспитан.
Я извиняюсь, но я не понимаю, что не так в цитате — так оно и есть. И для ОАЭ и других стран ближнего востока, получающих огромные доходы за счёт продажи углеводородов это точно также справедливо.
Мой код на plpgsql придерживается сходной нотации. Разве что io_ префикс не используется, а локальные переменные имеют префикс _.
Последнее время по большей части следую Google C++ Style Guide с некоторыми модификациями в именовании файлов, в ряде случаев использую статические объекты нетривиальных типов (если уверен, что ничего не сломается — кодовая база детских размеров). Единственные префиксы, которые использую, применяются к параметрам функции:
В большинстве случаев параметры входные, остальные два типа используются довольно редко, чаще всего для
мнимойоптимизации либо при перегрузке функций-членов в классах, унаследованных от классов из сторонних библиотек.Не забывайте, что использование «англоязычных» языков программирования, а также использование английского языка для именования переменных и комментариев позволяют в случае необходимости аутсорсить разработку в другие страны, если это экономически оправданно. Никто не любит так называемый «индусский код», аутсорсить в другие страны не патриотично, т.к. не создаёт рабочих мест в «родной» стране компании, но зачастую это экономически выгодно. При этом, насколько я понимаю, может происходить и с продуктами, которые не выходят за пределы использующей их компании.
Странно слышать какие-то утверждения про инженерную школу от человека, который, очевидно, сам инженером не является, даже на уровне самоучки. Отказ от использования готовых, проверенных временем инструментов, от использования в разработке общепринятых подходов программной, на минутку, инженерии, попахивает чем-то очень далёким от инженерного подхода к решению задачи.
«Дешёво»?
При просмотре кода становится очевидно, что это что-то не дешёвое. И главная причина — низкое качество самого кода. Например, функция com_compile. Это кошмар на 500+ строк с множеством вложенных ветвлений. Написать такую функцию один раз может быть и «просто и дёшево», в чём я сомневаюсь. Но поддержка подобного кода обойдётся во много раз дороже, чем поддержка любого из предложенных в комментариях «плохого и сложного» решения.
«Надёжно и работает»?
Работает — может быть. Но работает, очевидно, как-то. Явно не надёжно. И причина этого в низком качестве кода, которое было Вам продемонстрировано на примере скриншота, где большая часть кода подсвечена, как содержащая потенциальные ошибки. Профессиональные разработчики стремятся к минимизации количества предупреждений от инструментов анализа, в идеале — к полному отсутствию таких предупреждений.
Разве необходимо что-то делать с std::auto_ptr? Насколько я могу судить, std::auto_ptr используется только в случае, если не доступен std::unique_ptr, т.е. при сборке в режиме C++98/03. Или я что-то упускаю?
P.S. Можно не открывать Visual Studio для сборки:
(вместо Release можно использовать Debug, RelWithDegInfo, MinSizeRel или другой конфигурации сборки. Мелочь, конечно, но из терминала использовать удобнее получается.
Можно, конечно, поспорить, что ycmd и LSP-серверы не являются плагинами и т.п., но, на мой взгляд, они отражают идею по-настоящему универсальных плагинов, которые можно интегрировать буквально куда угодно. Подобные возможности интеграции обеспечиваются в первую очередь тем, что взаимодействие построено на основе IPC.
С одной стороны — и правда, ни за чем. С другой стороны, террористические атаки вполне могут планироваться за границей. Информация о подобных приготовлениях вполне может передаваться по каналам содействия спецслужб государств. Соответственно, спецслужбы некоторой страны, где происходит подготовка, могут предоставить информацию российским спецслужбам, которые смогли бы запросить информацию у Telegram.
Я не буду вспоминать про то, что спецслужбам США, например, везде и до всех есть дело. Я не считаю это и поведение США в подобных вопросах правильным, и уж тем более не хочу, чтобы страна, в которой я живу, подобным образом позорилась, просто констатирую факт.
«Ковровые бомбардировки» РКН — это плохо, но сокрытие информации о лицах, подозреваемых в терроризме, по причине какой-то глупой обиды и столь же глупых убеждений — верх инфантильности и слабоумия.
Так и у Вас: виновато государство, потому что люди сами не могут принимать правильные решения. По-моему, если человек не понимает, что убивать нельзя, воровать нельзя, нарушать закон — нельзя, то это вина в первую очередь самого человека и среды, в которой он был воспитан.
Во-вторых, внешних врагов никто не изобретает, они сами родятся — как за пределами, так и внутри страны.
Я применяю sqitch в связке с pgTap, поэтому в сознании у меня два инструмента смешались — не мыслю одного без другого.