ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Вторник
16 апреля
963645 Топик полностью
Связанные сообщения
Style Guide
Программисту должна быть оставлена свобода форматировании кода. Навязывание посимвольного соответствия автоформаттеру (часто даю...2019-05-14
Комментирую часть MISRA rules, сами они лежат на сахаре совершенно бесплатно...2015-11-08
Через-чур. По пунктам с чем не согласен:2013-05-24
fk0, легенда (09.12.2019 23:01 - 23:07, просмотров: 469) ответил Evgeny_CD на Barr Group's [Embedded C Coding Standard]
Приаттачил. Но начиналось оно с обучения правильно пробелы расставлять -- далее читать не стал. Я считаю, что форматирование кода -- прерогатива автора этого кода. В разумных пределах конечно, но тем не менее. И да, я считаю, что peak C++ ещё не наступил и наступит в середине 20-х годов. Современный C++ сделал большой рывок вперёд в последние 10 лет и только ускоряется. Таки стал читать. Правила не серьёзные. Мол "не используйте goto". Считаю, все средства имеющиеся в языке появились там не просто так и имеют право на жизнь и использование. И "не по назначению" можно не только goto использовать. Заставь дурака богу молиться -- лоб себе расшибёт. Это о многих "code style". Начинают рассказывать как _им_ нравится форматировать текст, как _им_ нравится именовать переменные и т.п. Забывают, что их мнение не обязательно правильное. Про мотивацию обычно не пишут, что характерно. Два более менее адекватных это "style guide" на мой взгляд это: 1) C++ core guidelines: https://isocpp.git …ines/CppCoreGuidelines 2) SEI Cert C coding standard: https://wiki.sei.c …CERT+C+Coding+Standard 2.1) SEI C++ coding standard: https://wiki.sei.c …action?pageId=88046682 Да, вдогонку, в C++ FAQ по этой теме уже давно сказано: https://isocpp.org …i/faq/coding-standards
A word of warning: Nearly every software engineer has, at some point, been exploited by someone who used coding standards as a “power play.” Dogmatism over minutiae is the purview of the intellectually weak. Don’t be like them. These are those who can’t contribute in any meaningful way, who can’t actually improve the value of the software product, so instead of exposing their incompetence through silence, they blather with zeal about nits. They can’t add value in the substance of the software, so they argue over form. Just because “they” do that doesn’t mean coding standards are bad, however. Another emotional reaction against coding standards is caused by coding standards set by individuals with obsolete skills. For example, someone might set today’s standards based on what programming was like N decades ago when the standards setter was writing code. Such impositions generate an attitude of mistrust for coding standards. As above, if you have been forced to endure an unfortunate experience like this, don’t let it sour you to the whole point and value of coding standards. It doesn’t take a very large organization to find there is value in having consistency, since different programmers can edit the same code without constantly reorganizing each others’ code in a tug-of-war over the “best” coding standard.
Могу сказать, что первый абзац -- часто встречается на практике. И второй. Второй часто можно видеть в существующих "стандартах кодирования", где многие пункты не актуальны для современных компиляторов (вроде советов писать "if (5 == a)..." и средств отладки (вроде советов не использовать malloc -- но альтернативы увы, ещё хуже).
[ZX]