Варианты:
1. Zend Coding Standard
2. PEAR Coding Standard
3. Стандарт используемый в моем любимом Framework/CMF/CMS (кроме Zend)
4. Другой общеизвестный
5. Собственный, не основанный на предыдущих
6. НЛО мне сказал, что лучший стандарт — его отсутствие.
Ну, это очень просто. Если Вы с ними не ознакамливались (но какой-то четко формализированный стиль у Вас есть) — это пункт «Собственный, не основанный на предыдущих». Если Вы с ними не ознакамливались, поскольку и не планировали заводить никакого стиля — это пункт «Нет его у меня».
Основа от Microsoft'a, от гугла немного и довольно много своего.
Пример кода (со времён написания этого кода стиль немного изменился, но в целом такой же)
улыбнуло у вас в коде. А вообще, я лично не нахожу удобным именование вида m_pMyMsg, m_dwCursorPos,… я предпочитаю длинные имена: displayIntervalIsRunning, howMuchValuesNeedToCut, для функций такие имена saveAllElementInDiv() и т.д.
соотв. любой кто читает после меня не испытывает проблем.
Я вот поймал себя на том, что часть моих убеждений в кодировании основано на какой-нибудь аргументации (стандарт, статья, обсуждение, обдумывание) а часть — просто на «так привык» или «так впервые когда-то увидел и решил не изобретать велосипед». Стало интересно как выбирают для себя правила другие люди.
Лет десять-пятнадцать записывают на бумажке удачные решения. Потом сравнивают получившееся с существующими стандартами, находят тот у которого 95-процентное совпадение и на этом успокаиваются :)
С этой точки зрения могу сказать, что вырабатывал его сам, методом проб и ошибок.
Первоисточником стиля был Pascal (в универе его изучал 1м, до этого с 9 го класса знал).
Заменить все «{» на «Begin» и «}» на «End», еще пару специфичных конструкций и получится довольно похоже на него )))
Смотрел, писал, искал как мне удобно оформлять и понимать код. Уже когда увидел, что полугодовалые исходники оформлены в том же стиле, с которым и сейчас работаю, понял что стиль выработался.
Пишу на C#. У нас в команде мы сошлись на том, что для C# самым распространенным является стандарт Microsoft. К тому же, под него, в основном, заточены правила StyleCop.
Немного подпилили под себя правила и успешно пользуемся.
В команде у людей, в общем-то, всегда есть разные предпочтения по форматированию, именованию и пр. Однако с использованием Microsoft Coding Standard у нас проблем не было, всех устраивает.
В С# почти нет вариантов — Microsoft, как разработчик основной IDE и основного компилятора диктуют стиль. А вот на классических плюсах пишут все и по-разному.
Не с одного ли мы проекта )))) Тоже писал до этого сам и в проекте стали писать Microsoft Style. На мой взгляд он наиболее логичный и понятно читаемый.
Ну неудобно мне читать неизвестно где кончающийся if и начинающийся код а ля
if(a== 1 ||
b== 2 ||
c== 3 ||) {
d=4
…
}
или som_variables_is_so_difficult_to_read
Читали исходники драйверов когда-нибудь? Осмелюсь предположить — нет. Так вот там ни одного упоминания про венгерскую нотацию нет, я так же считаю что она излишняя.
Доводилось читать исходники драйверов.
В большинстве своем, правда, на ''чистом'' С, где ''гуру старой закалки'' любят ''особый стиль''.
Приходилось сталкиваться и с вообще ''малочитаемым'' кодом, где автор через 2 месяца не мог быстро разобраться…
Я против чрезмерной формализации, но, по-моему, например, ''система'' в названиях переменных — не помеха при любом раскладе…
Собственно говоря почему так мало стандартов? Загляните в netbeans и там будет довольно большой список вариантов форматирования.
А так пиши в своем стиле похожем на ANSI. Но вообще всё зависит от ОС под которую пишу. Именование переменных и функций, а также возвращаемые значения отличаются когда пишу под Windows или под Linux
В своем продукте выработали свой собственный стиль и стараемся его придерживаться. Для себя пишу в стиле Ultimate++. Он больше похож на то, что принято в C#. Только вместо class пишется struct, чтобы не писать потом сразу public:. При этом при наследовании не надо добавлять public, например: struct Button : Ctrl
{
Button();
...
};
А тут не путают теплое с мягким? Есть совершенно ортогональные аспекты: стандарты форматирования, стандарты именования переменных, практики использования языка (шаблоны, исключения, RTTI).
Например, Mozilla guidelines говорят в основном, каким подмножеством C++ можно пользоваться, а Linux kernel style описывает в основном форматирование кода (так как он вообще не про C++).
Странно, что никто не вспомнил JSF air vehicle C++ coding standards, который рекомендует Страуструп на своей страничке (впрочем, ничего особо хорошего в этом стандарте нет).
Что же касается ответа на вопрос, то я пользуюсь собственной химерой, созданной на основе некоторых из предложенных стандартов.
Если речь идёт о форматировании кода и об именовании переменных и методов, то я использую очень многие правила из WebKit Coding Style Guidelines. В исходниках WebKit'а хорошо видно, как эти правила улучшают удобочитаемость кода. А что касается правил использования языковых фишек, то тут я руководствуюсь только собственным опытом и здравым смыслом.
Я не знаю, возможно слишком давно читал Саттера с Александреску, но там же насколько я помню очень мало собственно стандарта, там просто оговариваются моменты которые должны быть чётко определены в рамках проекта-команды — то есть руководство по созданию собственного стандарта кодирования.
В книгах Макконнелла почти по любому аспекту приводится штук 5 вариантов стиля. Причем смелость сказать «лучший — только вот этот» он на себя не берет. Максимум скажет «вот этот и этот плохой, а из оставшихся выбирайте сами».
А в вашем стандарте каждый случай прям четко-четко прописан? Вплоть до того, сколько пробелов ставить в отступах и сколько должно быть комментариев на каждый N строк кода?
Просто есть мнение, что стандарт нужен не совсем для того, чтобы вот весь код был прям по стандарту, а несколько для иных целей :) Нет ничего страшного, если иногда немного от него отклоняться. Или если стандарт не загоняет программиста в строжайшие рамки. В крайнем случае, код всегда можно прогнать через плагин, форматирующий его нужным образом.
Тут и вправду нужно не путать теплое с мягким. В стандарте да, действительно прописано сколько пробелов ставить в отступах и сколько должно быть комментариев (правда не на N строк кода, а по некоторым другим метрикам). Но Вы правы в том, что стандарт стандартом, а работа работой и в ней иногда случается (или бывает необходимо) от него отклониться. Это мне было понятно с самого начала и в уточнениях не нуждалось, а вот используемые стандарты мне были интересны.
Поддерживаю — как принято в Qt! Хотя иногда склоняюсь к Linux стилю особенно когда pure C.
А так как в последнее время пишу на Python 80% времени, то применяю PEP к C++ насколько это возможно.
т.е. ClassName и new_object.
Если Вы программируете на С\С++, в основе Вашего стиля кодирования лежит