немного о code metrics
Есть в программировании такое понятие, как "метрики кода" (code metrics). В самом простейшем случае- это количество строк кода, пустых строк и комментариев в процентном соотношении. Обычно используются для фаллометрии оценки производительности разработчика- делим наработанную метрику на затраченное время и получаем искомое. Обычно считается количество измененных/произведенных строк кода, т.е. исходник в 100 строк может принести своему разработчику и тысячу и более строк метрики за все время разработки. Для примера, хорошей метрикой для С++ программиста обычно считается 30тыс строк кода за 6 месяцев- чем больше период измерения, тем результат будет точнее (интегрирование).
Разумеется, такой простой подход к оценке часто используется для накручивания- расовый индусский метод copy&paste, писанина в стиле "код ради кода" и т.п. Тогда в дело вступают (а может и нет- как повезет) более серъезные методы- анализ повторяющихся кусков кода, ревью кода перед добавлением в репозиторий (для обоснования что и зачем делается).
Почему вспомнил об этой теме. Привязал к своим проектам систему мониторинга на сайте www.ohloh.net (на самом деле, это их краулер нашел мои проекты, мне осталось только зарегистрироваться и обозначить себя менеджером проекта). Эта система мониторинга сообщила мне, что в моем коде очень мало комментариев (too few) - около 10%. Добавил во все файлы шапку с разными полезными данными (что за файл, версия по репозиторию и т.п.), набил doxygen-овские комментарии на все публичные заголовки. Говорит, что все равно мало (few) - около 13%. Как сказано в аннотации к метрике, планка "нормально комментариев" берется в среднем по всем зарегистрированным проектам.
Решил ради интереса посмотреть на "топовые" продукты, про которые написано, что их код "well-documented". И что же я вижу? Невнятные интерфейсы с половиной страницы комментариев нахрена данный метод нужен (я далеко не гуру в составлении интерфейсов, я только учусь, но отделить хороший интерфейс от плохого иногда могу). Огромные закомментированные куски кода (не примеры, просто старый код не был выкинут, а остался под комментом- как будто разработчик не доверяет системе контроля версий). Огромные шапки файлов, где описано кто и что и когда менял (лог системы контроля версий уже отменили чтоли?).
Недавно сподобился начать читать Фаулера (Fowler) про рефакторинг (а до этого осилил Мартина (Robert K. Martin). Все они крайне рекомендуют дробить код на маленькие части, каждая из которых самодокументируется названием функции и небольшим телом, очевидно описывающим функциональность. Разумеется, данная рекомендация приводит к увеличению общей массы кода и к уменьшению числа комментариев (нафига комментировать очевидное?).
К сожалению, никаких данных по "норме метрик" в новых реалиях не нашел...
Разумеется, такой простой подход к оценке часто используется для накручивания- расовый индусский метод copy&paste, писанина в стиле "код ради кода" и т.п. Тогда в дело вступают (а может и нет- как повезет) более серъезные методы- анализ повторяющихся кусков кода, ревью кода перед добавлением в репозиторий (для обоснования что и зачем делается).
Почему вспомнил об этой теме. Привязал к своим проектам систему мониторинга на сайте www.ohloh.net (на самом деле, это их краулер нашел мои проекты, мне осталось только зарегистрироваться и обозначить себя менеджером проекта). Эта система мониторинга сообщила мне, что в моем коде очень мало комментариев (too few) - около 10%. Добавил во все файлы шапку с разными полезными данными (что за файл, версия по репозиторию и т.п.), набил doxygen-овские комментарии на все публичные заголовки. Говорит, что все равно мало (few) - около 13%. Как сказано в аннотации к метрике, планка "нормально комментариев" берется в среднем по всем зарегистрированным проектам.
Решил ради интереса посмотреть на "топовые" продукты, про которые написано, что их код "well-documented". И что же я вижу? Невнятные интерфейсы с половиной страницы комментариев нахрена данный метод нужен (я далеко не гуру в составлении интерфейсов, я только учусь, но отделить хороший интерфейс от плохого иногда могу). Огромные закомментированные куски кода (не примеры, просто старый код не был выкинут, а остался под комментом- как будто разработчик не доверяет системе контроля версий). Огромные шапки файлов, где описано кто и что и когда менял (лог системы контроля версий уже отменили чтоли?).
Недавно сподобился начать читать Фаулера (Fowler) про рефакторинг (а до этого осилил Мартина (Robert K. Martin). Все они крайне рекомендуют дробить код на маленькие части, каждая из которых самодокументируется названием функции и небольшим телом, очевидно описывающим функциональность. Разумеется, данная рекомендация приводит к увеличению общей массы кода и к уменьшению числа комментариев (нафига комментировать очевидное?).
К сожалению, никаких данных по "норме метрик" в новых реалиях не нашел...