Комментарии 91
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Вы будете удивлены тем, что можно сделать на VB, в Visual Studio. Впрочем, то же самое, что и на встроенных C#, Java, Python и остальных языках.
0
А у нас единственная проблема — тестами покрыто малая часть приложения. Фичи успевают внедрять быстрее, чем их покрывают тестами. А внедряют их быстрее тестов, поскольку так требует руководство :)
0
Комментарии — рекомендуемый диапазон 20% — 40% от общего количества строк.
40% от общего количества — довольно спорный вопрос. Изобилие комментариев внутри метода (а не в «шапке») зачастую мешает восприятию кода, который в принципе должен писаться так, чтобы быть понятным. Конечно, это субъективное мнение. А тулза вроде интересная:)
+5
Да, как правило приходится сталкиваться с комментариями типа:
# Frobnicate throbber
throbber.frobincate()
или
# Increase reference count
references += 1
При этом назначение метода в шапке часто никак не описывается. Бороться с этим тяжело, почему-то мало кто понимает, для чего нужны комментарии.
# Frobnicate throbber
throbber.frobincate()
или
# Increase reference count
references += 1
При этом назначение метода в шапке часто никак не описывается. Бороться с этим тяжело, почему-то мало кто понимает, для чего нужны комментарии.
+4
Путаете немножко.
В шапке или докстринге (если таковые есть в языке) пишется про назначение метода или функции. В теле — пояснения к реализации. Если реализацию еще можно не прояснять, то назначение следует описывать всегда.
И, черт возьми, реально время на комментарии не любят тратить только те, что так и не соизволили освоить адекватно слепую печать!
В шапке или докстринге (если таковые есть в языке) пишется про назначение метода или функции. В теле — пояснения к реализации. Если реализацию еще можно не прояснять, то назначение следует описывать всегда.
И, черт возьми, реально время на комментарии не любят тратить только те, что так и не соизволили освоить адекватно слепую печать!
-2
Это никак не связано, или почти никак
0
Это вы только что признались, что сами не очень с набором текста или что?
Просто не знаю уже, как объяснить нежелание отдельных кодеров комментировать собственные творения. Это так трудно? Это так не нужно? Сложно? И ведь не лохи какие-нибудь, а люди с десятилетним опытом. Сначал понять не мог.
А потом увидел, с какой скоростью они русский текст из себя выдавливают и прозрел. Это просто-напросто тяжело для них!
Просто не знаю уже, как объяснить нежелание отдельных кодеров комментировать собственные творения. Это так трудно? Это так не нужно? Сложно? И ведь не лохи какие-нибудь, а люди с десятилетним опытом. Сначал понять не мог.
А потом увидел, с какой скоростью они русский текст из себя выдавливают и прозрел. Это просто-напросто тяжело для них!
-2
Глупости, во-первых, можно быстро набирать русский, английский, какой-угодно текст без слепого набора, во-вторых, это не решает.
Если человек считает, что комментарии это неважно, то он и не будет их писать. Не нужно говорить им, что нужно комментировать код. Нужно сделать так, чтобы они поняли, что это реально полезно.
К слову, если ты не понимаешь зачем что-то делать, ты не сможешь ни сделать это толком, ни понять когда этого делать не нужно.
Если человек считает, что комментарии это неважно, то он и не будет их писать. Не нужно говорить им, что нужно комментировать код. Нужно сделать так, чтобы они поняли, что это реально полезно.
К слову, если ты не понимаешь зачем что-то делать, ты не сможешь ни сделать это толком, ни понять когда этого делать не нужно.
0
Надо, понятное дело, объяснять, когда и зачем это надо.
Только комменты в докстрингах или чуть выше тела функции нужны всегда. И лучше бы у программиста были бессознательной привычкой пояснения к своим функциям. Это такой же хороший тон, как и качественное тестирование кода.
В идеальном случае автоматический сборщик комментариев вроде того же sphinx для Питона или какие-нибудь Doxygen, scaladoc, javadoc в результате должен выдавать полноценное описание API. В качественном open source проекте это более чем хороший тон.
А вот так называемые «корпоративные» продукты очень часто представляют собой недокументированную кашу кода.
Только комменты в докстрингах или чуть выше тела функции нужны всегда. И лучше бы у программиста были бессознательной привычкой пояснения к своим функциям. Это такой же хороший тон, как и качественное тестирование кода.
В идеальном случае автоматический сборщик комментариев вроде того же sphinx для Питона или какие-нибудь Doxygen, scaladoc, javadoc в результате должен выдавать полноценное описание API. В качественном open source проекте это более чем хороший тон.
А вот так называемые «корпоративные» продукты очень часто представляют собой недокументированную кашу кода.
0
Если вы пишете блок, который надо прокомментировать — вынесите его в отдельный метод и опишите в шапке (алгоритмы, ссылки на документацию и обсуждения и т.п.)
Чаще всего поясняющие комментарии в коде методов действительно не имеют смысла. Плюс ко всему, качество комментариев по моему опыту всегда коррелирует с качеством кода. Поэтому обычно хорошему программисту комментировать код не нужно, а плохой программист комментирует код так, что лучше бы не комментировал.
Живой пример (PHP):
И код никудышный, и комментарии соответствующие.
Чаще всего поясняющие комментарии в коде методов действительно не имеют смысла. Плюс ко всему, качество комментариев по моему опыту всегда коррелирует с качеством кода. Поэтому обычно хорошему программисту комментировать код не нужно, а плохой программист комментирует код так, что лучше бы не комментировал.
Живой пример (PHP):
// Render
$layoutPath = $this->getLayoutPath('Base');
if (file_exists($layoutPath)) {
// Render Layout
ob_start();
include $layoutPath;
$content = ob_get_clean();
}
// Render
echo $content;
И код никудышный, и комментарии соответствующие.
0
А у нас нет проблем, мы в отпуске :)
+9
А для C++/Qt сообщество что то аналогичное может посоветовать?
+2
ооооо, метрики кода :)
самая нелепая вещь что была придумана быдломенеджерами :)
мне всё время интересно как можно померять качество кода, например, html парсера, глядя только на исходники и 100% покрывающие их юниттесты? :)
P.S. подсказка html парсер это в первую очередь нечто опирающееся на стандарт, описанный человеческим языком…
самая нелепая вещь что была придумана быдломенеджерами :)
мне всё время интересно как можно померять качество кода, например, html парсера, глядя только на исходники и 100% покрывающие их юниттесты? :)
P.S. подсказка html парсер это в первую очередь нечто опирающееся на стандарт, описанный человеческим языком…
+7
Я согласен, что померять качество когда метриками задача не из простых. Но вот пример ваш не очень. В данном случае, вы говорите о качестве продукта, а не о качестве кода. Можно красиво запрограммировать, но не то. А это уже другая проблема.
+1
о да
int main()
{
};
идеальный код, наверное, по метрикам :)
int main()
{
};
идеальный код, наверное, по метрикам :)
-2
а где комменты?
+2
gcc -Wall скажет, что этот код не совсем чистый ;)
0
Метрики кода — довольно полезная вещь. Например, по ним я оцениваю состояние текущего проекта и сравниваю его с ранее выполненными. На основе полученных данных можно оценить сложность, объем работ и необходимые для выполнения ресурсы. Зачастую эти цифры показывают более точный результат, чем субъективный взгляд со стороны.
+2
в точку
0
хахаха, примитивный пример, как по метрикам оценить сложность:
class Outputer{
public:
virtual void put( const string & ) = 0;
virtual void put_char( char ) = 0;
virtual ~Outputer(){};
}
typedef shared_ptr OutputerPtr;
class HelloWord{
static const string hello_word_string;
OuputerPtr out;
public:
HelloWord( OuputerPtr o ): out( o ){};
void operator()(){
for( string::size_type i=0;iput_char( hello_word_string[ i ] );
};
}
и что про этот код скажет программист делающий ревью…
class Outputer{
public:
virtual void put( const string & ) = 0;
virtual void put_char( char ) = 0;
virtual ~Outputer(){};
}
typedef shared_ptr OutputerPtr;
class HelloWord{
static const string hello_word_string;
OuputerPtr out;
public:
HelloWord( OuputerPtr o ): out( o ){};
void operator()(){
for( string::size_type i=0;iput_char( hello_word_string[ i ] );
};
}
и что про этот код скажет программист делающий ревью…
0
Ваши метрики кода дают илюзию контроля, но не сам контроль. Что толку с вашего идеального кода по метрикам, если код не обрабатывает ошибок и имеет дедлок на 2-ом часу работы, ой а здесь ваши юнитэсты скорее всего тоже не помогут, потому что дедлок случается согласно теории вероятности и если его не искать целенаправлено то ваши тэсты все успешно буду пройдены, но софтина завалится. Ваши метрики ничерта не покажут что обработчик прерываний запорол стэк изза неправильно выбраной модели памяти и контролер начинает валится в самых непредвиденных местах. Зато у нас шапка в каждом файле и описание над каждой функицей.
К чёрту менеджера который думает что одними метриками он что-то будет контролировать, просто в один момент звёзды сложатся плохо и всё накрыется медным тазом и виноват будет он, а не програмисты.
Хотите контролировать качество кода извольте найти квалифицированных програмистов не задействованных в разработке даного фрагмента и заставьте проделать качественны разбор кода хотя бы раз в неделю. От проблем вас это не убережёт, но зато вы о них будете знать не за день до релиза. А метрики, метрики можете оставить, но это только для 1-го уровня контроля, что-то вроде базовых правил гигиены, чистить зубы по утрам, документировать внешние интерфейсы и неочевидные вещи.
А оценивать сложность работ и объём работ по таким примитивным метрикам можно разве для типовых проэктов.
К чёрту менеджера который думает что одними метриками он что-то будет контролировать, просто в один момент звёзды сложатся плохо и всё накрыется медным тазом и виноват будет он, а не програмисты.
Хотите контролировать качество кода извольте найти квалифицированных програмистов не задействованных в разработке даного фрагмента и заставьте проделать качественны разбор кода хотя бы раз в неделю. От проблем вас это не убережёт, но зато вы о них будете знать не за день до релиза. А метрики, метрики можете оставить, но это только для 1-го уровня контроля, что-то вроде базовых правил гигиены, чистить зубы по утрам, документировать внешние интерфейсы и неочевидные вещи.
А оценивать сложность работ и объём работ по таким примитивным метрикам можно разве для типовых проэктов.
0
Я думаю качество кода — это плохо формализируемая область, тем более для автоматических программ. Качественный код — это код, который понятен человеку и с которым удобно работать. Раз психика человека неформализируема, а автоматическая программа попытаться понять код не может, то и все метрики Sonar не более, чем цифры, хотя как-то и связанные с реальным качеством кода.
Это примерно тоже самое, что брать на работу только тех, кто набирает много баллов в IQ и других тестах.
Это примерно тоже самое, что брать на работу только тех, кто набирает много баллов в IQ и других тестах.
+5
А в случае с Sonar внедрение его может быть наоборот отрицательным. Разработчики зная его критерии будут писать код под них, а не понятный и удобный код.
+7
По-моему, лучшие способ поднять качество кода, это:
— выкладывать код в open source;
— парное программирование;
— проверка любого кода, другим разработчиком, как в Google.
— выкладывать код в open source;
— парное программирование;
— проверка любого кода, другим разработчиком, как в Google.
+8
НЛО прилетело и опубликовало эту надпись здесь
Ручной тест не позволяет создать регрессию. Через месяц что то сломается и не узнаете. Юнит или не юнит, но тесты должны быть автоматическими
0
Лично я считаю, что оценка качества кода по количеству комментариев и проценту покрытия кода тестами в принципе не может дать никакого результата, потому что эти показатели не имеют ничего общего с качеством кода.
Например у меня на работе код оценивается следующим образом. Мы работаем над проектом командой из 4 человек, и если кто-то увидел ковнокод в репозитарии, то он громко на весь офис кричит: «Говнокод!», и имя автора кода, после чего над автором глумятся весь день… По-моему, самый лучший мотиватор.
Ну а если серьезно, то просто нужно, чтобы программисту доставляло эстетическое удовольствие писать качественный код, и тогда все будет хорошо, иначе это ошибка в выборе программиста.
Например у меня на работе код оценивается следующим образом. Мы работаем над проектом командой из 4 человек, и если кто-то увидел ковнокод в репозитарии, то он громко на весь офис кричит: «Говнокод!», и имя автора кода, после чего над автором глумятся весь день… По-моему, самый лучший мотиватор.
Ну а если серьезно, то просто нужно, чтобы программисту доставляло эстетическое удовольствие писать качественный код, и тогда все будет хорошо, иначе это ошибка в выборе программиста.
-3
Это зависит от психики и организации человека. Если бы я допустил ляп, и мне бы день кричали говнокод, я бы в этот же день уволился нахуй. Потому что извините, в гробу видал работать в таком коллективе.
Ты забываешь золотое правило. Критикуй ошибки, код, дизайн, но не критикуй людей.
Ты забываешь золотое правило. Критикуй ошибки, код, дизайн, но не критикуй людей.
+1
И уж тем более, еще более важное правило — хвали на людях, ругай наедине.
0
Зачем же увольнятся. Надо тихо терпеть, накапливая злобу, а потом в один прекрасный день всех порезать на маленькие кусочки, воткнуть напильник в глаз техдиректору и т.п. По-моему, самый лучший мотиватор для подобных работодателей.
0
Понятие «Говнокод» иногда очень субъективное. У нас раз в неделю проводили коллективный Code Review. Каждый мог выставить на обсуждение чужой участок кода, который он считал проблемным. Далее шло обсуждение, где приводились доводы как против, так и в защиту кода. В результате вырабатывалась практика, обязательная для всей команды. На самом деле выработка практики происходила далеко не всегда с первого раза. Но в целом, по моим ощущениям, это помогло подтянуть качество кода у более слабых членов команды.
+1
Если говорить про стиль кода, то зачастую главное не какой стиль вы выбрали, а то, как строго вы ему следуете.
Хотя согласитесь, есть и вполне объективные метрики показывающие качество кода, например степень вложенности или абсолютно неговорящие имена методов.
Хотя согласитесь, есть и вполне объективные метрики показывающие качество кода, например степень вложенности или абсолютно неговорящие имена методов.
0
Какая увлекательная история в эпиграфе, причём заметьте с хэппиэндом: «приходит представитель Всемирно Известной Организации по Измерению Качества… попала в Топ 10… проект на самом деле 10й с конца.» Т.е. десятый с конца в десятке, они всё-таки выиграли? Ай, молодцы какие
-1
Джоэл Спольский наоборот пишет, что у программиста ничего не надо мерить. Все эти измерения не объективны, а если проект 10 с конца, то это вина руководителя, проектом и людьми надо руководить, а не метрики мерить. На мой взгляд плохое качество кода лечится введением небольшого стандарта кодирования. Хотя если так задуматься, что это такое вообще качество кода? может начнем с определения, что бы все мы говорили об одном и том же.
+1
как руководить проектом, о котором ты ничего не знаешь?
-1
я должен отвечать на этот вопрос? по моему это более чем странно — руководить проектом о котором ничего не знаешь. Вопрос тут только — а руководите ли вы проектом?
0
все верно. ты ничего не знаешь о проекте, в котором ничего не измеряешь.
а значит и не можешь им управлять
а значит и не можешь им управлять
0
Согласен на счет стандартов кодирования. Есть те, кто пишет великолепно (то есть доступоно, прозрачно, оптимально). Но во всем должен быть баланс. По сути стандарты это и фиксируют.
Вопрос измерения метрик он пожалуй все-таки важный. Я почитал про Sonar. По сути это просто автомат по проверке соблюдения таких стандартов. Когда команда сыграна здесь никаких проблем, а вот когда куча народу с участием подрядных организаций, то стандарты пожалуй не помешают.
Вот книга Дж. Ханка Рейнвотера «Как пасти котов». Я сейчас не предлагаю ее обсуждать, не буду говорить хорошая она или плохая. Это не важно. Но в этой книге автор пытается поделить все братсво кодеров на категории. Он там выделяет разгельдяев и еще кого-то там. Ну во общем доля правды в этом есть. Есть люди, которые, не умеют кодировать. Они порождают просто ужастный код. От них нужно либо избавляться в своей команде (но это если человек просто не адекватен), либо приучать к стилю (если человек отличный программист, но так случилось, что он не умеет работать в команде).
Вот как раз для обучения подобные решения и нужны. Лично мне кажется, что приведенный здесь продукт вполне неплохое решения для подобных задач.
Вопрос измерения метрик он пожалуй все-таки важный. Я почитал про Sonar. По сути это просто автомат по проверке соблюдения таких стандартов. Когда команда сыграна здесь никаких проблем, а вот когда куча народу с участием подрядных организаций, то стандарты пожалуй не помешают.
Вот книга Дж. Ханка Рейнвотера «Как пасти котов». Я сейчас не предлагаю ее обсуждать, не буду говорить хорошая она или плохая. Это не важно. Но в этой книге автор пытается поделить все братсво кодеров на категории. Он там выделяет разгельдяев и еще кого-то там. Ну во общем доля правды в этом есть. Есть люди, которые, не умеют кодировать. Они порождают просто ужастный код. От них нужно либо избавляться в своей команде (но это если человек просто не адекватен), либо приучать к стилю (если человек отличный программист, но так случилось, что он не умеет работать в команде).
Вот как раз для обучения подобные решения и нужны. Лично мне кажется, что приведенный здесь продукт вполне неплохое решения для подобных задач.
0
Вы говорите кодировать, простите, но чтобы кодировать много ума ненадо. Есть кодер есть девелопер, или разработчик, как Вам будет угодно. Да не все люди гении. Кто-то пишет код дольше, укого-то процесс разработки занимает больше времени (я имею ввиду именно процесс проектирования системы), но Вы этого никак не замеряете, потому как еще вмешивается психология. Да и вообще я же и предлагаю, давайте определимся что значит качество кода, а то мы будем мереть не то.
0
Я согласен з Джелом, но вот делать с него большого авторитета в области разработки софта не стал бы. После его ухода из Майкрософта он был больше известен благодаря блогу чем реальным достижениям в области софтостроения. Его багтрекинг уныл и судя по всему никогда не был заметным игроком в сегменте. Что у него действительно получилось хорошо так это stackoverflow.
0
Кто нибудь знает подобные проекты для питоновских проектов?
0
Я пользуюсь pyLint'ом в связке с емаксом (можно сразу перейти на строчку с ворнингом).
Отчет выглядит так: pastebin.com/kaHf2yNj
Отчет выглядит так: pastebin.com/kaHf2yNj
+1
Тока у него некоторые проблемы с русским языком — строки с русским он считает слишком длинными. Да и вообще слишком многословен, но в целом кое что может показать полезное.
0
А для проверки покрытия кода тестами есть утилита PyCoverage. Конечно покрытие тестами на 100% — это хорошо, но даже разработчик пишет, что это не панацея
А PyLint хорошая утилита, но когда работаешь с библиотеками или фреймворками, а она начинает ругаться на них, то это отвлекает.
А PyLint хорошая утилита, но когда работаешь с библиотеками или фреймворками, а она начинает ругаться на них, то это отвлекает.
+1
Почему не в «Я пиарюсь»?
-1
Единственное чего сильно не хватает это описания того как его установить и как использовать.
+1
Вроде на сайте есть у них: docs.codehaus.org/display/SONAR/Install+Sonar
0
Спасибо. Это я видел и даже пытался поставить (под win), но вот как его использовать — непонятно.
P.S. Хотел PHP проект прогнать, но как выяснилось уже после установки, похоже, нужен проект под maven. Просто так — без maven (только ради sonar-a не хочется его использовать), его нельзя запустить?
P.S. Хотел PHP проект прогнать, но как выяснилось уже после установки, похоже, нужен проект под maven. Просто так — без maven (только ради sonar-a не хочется его использовать), его нельзя запустить?
0
Было бы еще круче, если бы вместо краткого описания проблемы в конкретном месте кода было бы еще можно поглядеть детальное описание этой проблемы, почему это нехорошо и т.д. (на сайте где водится этот puppycrawl, оно конечно есть, но гуглить туда неудобно). Ну и там же — возможность отфильтровать/отключить эти сообщения в текущем проекте. А так проект очень понравился :).
0
Этот функционал есть, попробуйте. Каждое замечание можно отследить прямо в коде.
0
Вы меня неправильно поняли.
Например:
private void btAddScheduleActionPerformed(java.awt.event.ActionEvent evt) {//GEN-FIRST:event_btAddScheduleActionPerformed
^ Unused formal parameter: Avoid unused method parameters such as 'evt'.
На это можно нажать, вы попадаете на страницу, где написано:
Unused formal parameter
Plugin: pmd Key: UnusedFormalParameter
Avoid passing parameters to methods or constructors and then not using those parameters.
Это в общем-то и все. Но если этого мало, приходится гуглить по сообщению и попадать на проект PMD: pmd.sourceforge.net/rules/unusedcode.html
Хотя, может быть, это их проблема, а не Sonar :)
Другое заключается в том что я пока не понял, как ему объяснить, что такие вещи можно иногда опускать (например, когда наличие параметра обязательно, чтобы не нарушать сигнатуру метода, но параметр не используется).
Например:
private void btAddScheduleActionPerformed(java.awt.event.ActionEvent evt) {//GEN-FIRST:event_btAddScheduleActionPerformed
^ Unused formal parameter: Avoid unused method parameters such as 'evt'.
На это можно нажать, вы попадаете на страницу, где написано:
Unused formal parameter
Plugin: pmd Key: UnusedFormalParameter
Avoid passing parameters to methods or constructors and then not using those parameters.
Это в общем-то и все. Но если этого мало, приходится гуглить по сообщению и попадать на проект PMD: pmd.sourceforge.net/rules/unusedcode.html
Хотя, может быть, это их проблема, а не Sonar :)
Другое заключается в том что я пока не понял, как ему объяснить, что такие вещи можно иногда опускать (например, когда наличие параметра обязательно, чтобы не нарушать сигнатуру метода, но параметр не используется).
0
А иконки Violations слизаны с Atlassian Jira…
0
В версии 2.2 это было исправлено — jira.codehaus.org/browse/SONAR-1636
0
В одной компании мы использовали Bamboo. Это платный билд-сервер, который заодно и генерирует похожие отчёты.
А в другой компании мы при билде запускали ряд плагинов для Maven (FindBugs, PMD, CheckStyle), которые тоже генерировали похожие отчёты. Кстати, Sonar их тоже использует, кажется.
А в другой компании мы при билде запускали ряд плагинов для Maven (FindBugs, PMD, CheckStyle), которые тоже генерировали похожие отчёты. Кстати, Sonar их тоже использует, кажется.
0
Меня заинтересовала первая рекомендация: «Комментарии — рекомендуемый диапазон 20% — 40% от общего количества строк. ». Почему именно столько? У нас вот считается, что комментариев должно быть как можно меньше.
0
Интересно, а откуда взяты «рекомендуемые значения»? :)
0
В основном из двух источников:
1. Определения метрик. Пример — LCOM4.
2. Stack overflow. Пример — покрытие тестами.
1. Определения метрик. Пример — LCOM4.
2. Stack overflow. Пример — покрытие тестами.
0
Интересно а для C++ есть что-либо подобное?
0
выше ответили: habrahabr.ru/blogs/pm/100013/#comment_3089261
0
Средняя сложность методов — не больше 5
100 простых геттеров, 100 простых сеттеров и 10 методов со сложностью 100. Средняя по больнице — 4.2.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Управление качеством кода