Comments 72
Запостите тоже самое только про PHP, пожалуйста. Думаю, будет интересная картина. Я честно пытался сделать сам, но кармы не хватает.
0
Не силен в стандартах, принятых в PHP, не смогу предложить варианты.
0
Так скооперируйтесь, коллеги, для того ведь Хабр и нужен!
vooD — предложи варианты, а tangro — забабахай опрос.
vooD — предложи варианты, а tangro — забабахай опрос.
+2
Варианты:
1. Zend Coding Standard
2. PEAR Coding Standard
3. Стандарт используемый в моем любимом Framework/CMF/CMS (кроме Zend)
4. Другой общеизвестный
5. Собственный, не основанный на предыдущих
6. НЛО мне сказал, что лучший стандарт — его отсутствие.
1. Zend Coding Standard
2. PEAR Coding Standard
3. Стандарт используемый в моем любимом Framework/CMF/CMS (кроме Zend)
4. Другой общеизвестный
5. Собственный, не основанный на предыдущих
6. НЛО мне сказал, что лучший стандарт — его отсутствие.
+1
Отличные варианты, тогда уж можно сразу:
1. Zend
2. PEAR
3. Что-то другое
1. Zend
2. PEAR
3. Что-то другое
0
Ок, публикую. Сошлюсь на Вас, как на автора вариантов. Еще вставлю ссылочки.
Zend Framework Coding Standard for PHP
PEAR Coding Standards
Horde Coding Standards
Zend Framework Coding Standard for PHP
PEAR Coding Standards
Horde Coding Standards
+1
Когда-то занимался разработкой на php, использовал довольно известный стандарт
0
Жаль нет нигде сводной таблицы по стилям :-(
0
Вот я с ними не ознакамливался достаточно и затрудняюсь какой вариант ответить…
Странный опрос…
Странный опрос…
+4
Ну, это очень просто. Если Вы с ними не ознакамливались (но какой-то четко формализированный стиль у Вас есть) — это пункт «Собственный, не основанный на предыдущих». Если Вы с ними не ознакамливались, поскольку и не планировали заводить никакого стиля — это пункт «Нет его у меня».
+2
— Вы умеете играть на пианино?
— Не знаю, не пробовал.
+14
У меня собственный, основанный на «Google C++ Style Guide» и «Microsoft Coding Standards»
+1
Их получается совместить? А дайте почитать.
+2
Основа от Microsoft'a, от гугла немного и довольно много своего.
Пример кода (со времён написания этого кода стиль немного изменился, но в целом такой же)
Пример кода (со времён написания этого кода стиль немного изменился, но в целом такой же)
+1
Комментариев бы в ваш стильный код)
+1
жуть :-)
+3
m_bEnterMessage = !m_bEnterMessage;
if(m_bEnterMessage)
{
…
}
else
{
…
}
улыбнуло у вас в коде. А вообще, я лично не нахожу удобным именование вида m_pMyMsg, m_dwCursorPos,… я предпочитаю длинные имена: displayIntervalIsRunning, howMuchValuesNeedToCut, для функций такие имена saveAllElementInDiv() и т.д.
соотв. любой кто читает после меня не испытывает проблем.
if(m_bEnterMessage)
{
…
}
else
{
…
}
улыбнуло у вас в коде. А вообще, я лично не нахожу удобным именование вида m_pMyMsg, m_dwCursorPos,… я предпочитаю длинные имена: displayIntervalIsRunning, howMuchValuesNeedToCut, для функций такие имена saveAllElementInDiv() и т.д.
соотв. любой кто читает после меня не испытывает проблем.
0
Не особо понял, зачем у вас модификаторы const при передаче параметров метода по значению. Параноя какая-то )
0
Qtшный стиль, он отчасти BSDшный
+14
Собственный, основанный на общеизвестных.
+2
Ни когда не задумывался, чей же стиль у меня (есть и есть, что с него взять?).
Но ближе всего к Microsoft Coding Standards, выбрал его.
Но ближе всего к Microsoft Coding Standards, выбрал его.
+1
Я вот поймал себя на том, что часть моих убеждений в кодировании основано на какой-нибудь аргументации (стандарт, статья, обсуждение, обдумывание) а часть — просто на «так привык» или «так впервые когда-то увидел и решил не изобретать велосипед». Стало интересно как выбирают для себя правила другие люди.
+1
Лет десять-пятнадцать записывают на бумажке удачные решения. Потом сравнивают получившееся с существующими стандартами, находят тот у которого 95-процентное совпадение и на этом успокаиваются :)
+2
С этой точки зрения могу сказать, что вырабатывал его сам, методом проб и ошибок.
Первоисточником стиля был Pascal (в универе его изучал 1м, до этого с 9 го класса знал).
Заменить все «{» на «Begin» и «}» на «End», еще пару специфичных конструкций и получится довольно похоже на него )))
Смотрел, писал, искал как мне удобно оформлять и понимать код. Уже когда увидел, что полугодовалые исходники оформлены в том же стиле, с которым и сейчас работаю, понял что стиль выработался.
Первоисточником стиля был Pascal (в универе его изучал 1м, до этого с 9 го класса знал).
Заменить все «{» на «Begin» и «}» на «End», еще пару специфичных конструкций и получится довольно похоже на него )))
Смотрел, писал, искал как мне удобно оформлять и понимать код. Уже когда увидел, что полугодовалые исходники оформлены в том же стиле, с которым и сейчас работаю, понял что стиль выработался.
+2
Интересно было бы выделить отдельно такие стандарты как MISRA. Есть ли на Хабре люди пишущие с соблюдением этих стандартов.
0
Пишу на C#. У нас в команде мы сошлись на том, что для C# самым распространенным является стандарт Microsoft. К тому же, под него, в основном, заточены правила StyleCop.
Немного подпилили под себя правила и успешно пользуемся.
В команде у людей, в общем-то, всегда есть разные предпочтения по форматированию, именованию и пр. Однако с использованием Microsoft Coding Standard у нас проблем не было, всех устраивает.
Немного подпилили под себя правила и успешно пользуемся.
В команде у людей, в общем-то, всегда есть разные предпочтения по форматированию, именованию и пр. Однако с использованием Microsoft Coding Standard у нас проблем не было, всех устраивает.
+1
В С# почти нет вариантов — Microsoft, как разработчик основной IDE и основного компилятора диктуют стиль. А вот на классических плюсах пишут все и по-разному.
+3
Не с одного ли мы проекта )))) Тоже писал до этого сам и в проекте стали писать Microsoft Style. На мой взгляд он наиболее логичный и понятно читаемый.
Ну неудобно мне читать неизвестно где кончающийся if и начинающийся код а ля
if(a== 1 ||
b== 2 ||
c== 3 ||) {
d=4
…
}
или som_variables_is_so_difficult_to_read
Ну неудобно мне читать неизвестно где кончающийся if и начинающийся код а ля
if(a== 1 ||
b== 2 ||
c== 3 ||) {
d=4
…
}
или som_variables_is_so_difficult_to_read
0
Ближе всего мой стиль к BSD.
0
Microsoft Coding Standard за исключением венгерской нотации.
0
А что в венгерской нотации не подходит?
Пожелания работодателя?
P.S. У нас она рекомендована, но не ''мордуют''…
Пожелания работодателя?
P.S. У нас она рекомендована, но не ''мордуют''…
0
Читали исходники драйверов когда-нибудь? Осмелюсь предположить — нет. Так вот там ни одного упоминания про венгерскую нотацию нет, я так же считаю что она излишняя.
0
Доводилось читать исходники драйверов.
В большинстве своем, правда, на ''чистом'' С, где ''гуру старой закалки'' любят ''особый стиль''.
Приходилось сталкиваться и с вообще ''малочитаемым'' кодом, где автор через 2 месяца не мог быстро разобраться…
Я против чрезмерной формализации, но, по-моему, например, ''система'' в названиях переменных — не помеха при любом раскладе…
В большинстве своем, правда, на ''чистом'' С, где ''гуру старой закалки'' любят ''особый стиль''.
Приходилось сталкиваться и с вообще ''малочитаемым'' кодом, где автор через 2 месяца не мог быстро разобраться…
Я против чрезмерной формализации, но, по-моему, например, ''система'' в названиях переменных — не помеха при любом раскладе…
0
Boost Guidelines + GNU coding style
+2
Sun Coding Conventions с адаптацией к c++
0
K&R
+10
Повторюсь, но все таки qt.gitorious.org/qt/pages/QtCodingStyle
+5
проголосовал за Microsoft Coding Standards, т.к. стараюсь придерживаться его.
0
Зачем вы стили C и C++ смешали?
+5
Kernel style
В основном пишу для ядра на Си, когда переключаюсь на плюсы — пишу в таком же стиле
Очень компактно и читаемо
В основном пишу для ядра на Си, когда переключаюсь на плюсы — пишу в таком же стиле
Очень компактно и читаемо
0
Собственно говоря почему так мало стандартов? Загляните в netbeans и там будет довольно большой список вариантов форматирования.
А так пиши в своем стиле похожем на ANSI. Но вообще всё зависит от ОС под которую пишу. Именование переменных и функций, а также возвращаемые значения отличаются когда пишу под Windows или под Linux
А так пиши в своем стиле похожем на ANSI. Но вообще всё зависит от ОС под которую пишу. Именование переменных и функций, а также возвращаемые значения отличаются когда пишу под Windows или под Linux
0
В своем продукте выработали свой собственный стиль и стараемся его придерживаться. Для себя пишу в стиле Ultimate++. Он больше похож на то, что принято в C#. Только вместо class пишется struct, чтобы не писать потом сразу public:. При этом при наследовании не надо добавлять public, например:
Очень удобно и практично.
struct Button : Ctrl
{
Button();
...
};
Очень удобно и практично.
-1
А тут не путают теплое с мягким? Есть совершенно ортогональные аспекты: стандарты форматирования, стандарты именования переменных, практики использования языка (шаблоны, исключения, RTTI).
Например, Mozilla guidelines говорят в основном, каким подмножеством C++ можно пользоваться, а Linux kernel style описывает в основном форматирование кода (так как он вообще не про C++).
Например, Mozilla guidelines говорят в основном, каким подмножеством C++ можно пользоваться, а Linux kernel style описывает в основном форматирование кода (так как он вообще не про C++).
+3
Странно, что никто не вспомнил JSF air vehicle C++ coding standards, который рекомендует Страуструп на своей страничке (впрочем, ничего особо хорошего в этом стандарте нет).
Что же касается ответа на вопрос, то я пользуюсь собственной химерой, созданной на основе некоторых из предложенных стандартов.
Что же касается ответа на вопрос, то я пользуюсь собственной химерой, созданной на основе некоторых из предложенных стандартов.
+1
Если речь идёт о форматировании кода и об именовании переменных и методов, то я использую очень многие правила из WebKit Coding Style Guidelines. В исходниках WebKit'а хорошо видно, как эти правила улучшают удобочитаемость кода. А что касается правил использования языковых фишек, то тут я руководствуюсь только собственным опытом и здравым смыслом.
0
Смесь K&R и Linux.
+2
Пользуюсь NetBeans стилем форматирования, именование идентификаторов в стиле Qt…
0
По ссылке MS-style — наглая ложь! Краем глаза видел всем известные исходники. :-)
0
Я не знаю, возможно слишком давно читал Саттера с Александреску, но там же насколько я помню очень мало собственно стандарта, там просто оговариваются моменты которые должны быть чётко определены в рамках проекта-команды — то есть руководство по созданию собственного стандарта кодирования.
0
Почему нет варианта, «по рекомендациям Макконнелла»?
0
В книгах Макконнелла почти по любому аспекту приводится штук 5 вариантов стиля. Причем смелость сказать «лучший — только вот этот» он на себя не берет. Максимум скажет «вот этот и этот плохой, а из оставшихся выбирайте сами».
0
Приводит он действительно много вариантов, но рекомендует один, максимум два. Я соответствующую главу недавно совсем перечитывал.
0
Ну вот из-за случаев «максимум два варианта» я его сюда и не включал. Ну не стандарт это, если рекумендуется 2 варианта.
0
А в вашем стандарте каждый случай прям четко-четко прописан? Вплоть до того, сколько пробелов ставить в отступах и сколько должно быть комментариев на каждый N строк кода?
Просто есть мнение, что стандарт нужен не совсем для того, чтобы вот весь код был прям по стандарту, а несколько для иных целей :) Нет ничего страшного, если иногда немного от него отклоняться. Или если стандарт не загоняет программиста в строжайшие рамки. В крайнем случае, код всегда можно прогнать через плагин, форматирующий его нужным образом.
Просто есть мнение, что стандарт нужен не совсем для того, чтобы вот весь код был прям по стандарту, а несколько для иных целей :) Нет ничего страшного, если иногда немного от него отклоняться. Или если стандарт не загоняет программиста в строжайшие рамки. В крайнем случае, код всегда можно прогнать через плагин, форматирующий его нужным образом.
0
Тут и вправду нужно не путать теплое с мягким. В стандарте да, действительно прописано сколько пробелов ставить в отступах и сколько должно быть комментариев (правда не на N строк кода, а по некоторым другим метрикам). Но Вы правы в том, что стандарт стандартом, а работа работой и в ней иногда случается (или бывает необходимо) от него отклониться. Это мне было понятно с самого начала и в уточнениях не нуждалось, а вот используемые стандарты мне были интересны.
0
Qt
0
Поддерживаю — как принято в Qt! Хотя иногда склоняюсь к Linux стилю особенно когда pure C.
А так как в последнее время пишу на Python 80% времени, то применяю PEP к C++ насколько это возможно.
т.е. ClassName и new_object.
А так как в последнее время пишу на Python 80% времени, то применяю PEP к C++ насколько это возможно.
т.е. ClassName и new_object.
0
Sign up to leave a comment.
Если Вы программируете на С\С++, в основе Вашего стиля кодирования лежит