@Caiiiycuk7 мар 2013 в 01:33

Улучшаем качество кода с помощью автоматических утилит

3 мин

13K

Я пиарюсь

+45

Комментарии 19

@ImperfectCadenca 7 мар 2013 в 03:20

поддержку Ruby/Rails бы…

для Rails существует Code Climate — интересный, удобный и няшный инструмент, помогающий рефакторить. Увы, приватные репы лишь за денежку.

@Source 7 мар 2013 в 10:25

Code Climate — это же по большей части удобная обертка для тех же гемов, что входят в состав metric_fu

@Caiiiycuk 7 мар 2013 в 11:53

Пытался найти линтер для Ruby, но что бы вот так просто взять и прикрутить не нашел.

@Captcha 7 мар 2013 в 06:06

AndroidLint не хватает

@Caiiiycuk 7 мар 2013 в 11:54

Спасибо за наводку, надо будет изучить после праздников. Сильно лучше чем java checkstyle?

@Captcha 7 мар 2013 в 12:00

Разные вещи. AndroidLint предназначен чисто для анализа кода Android приложений.

@k0sh 7 мар 2013 в 09:02

Можно ли проверить не pull, а исходный репозиторий?

@Caiiiycuk 7 мар 2013 в 11:47

На данный момент нельзя.

@mefrill 7 мар 2013 в 09:33

cpplint.py создан для проверки стиля кодирования компании Google. Этот стиль интересный, но какие-то вещи выглядят явными архаизмами. Например, запрет на использование шаблонов и исключений. Ну, а проверку копирайта в первой строке файла вообще приходится менять для каждой компании. Обычно этот скрипт качают и подгоняют на месте. Было бы интересно добавить в скрипт возможности подгонки стиля по какому-то множеству параметров. Иначе, по крайней мере, для C++, это малорименимо.

@c0d3r 7 мар 2013 в 17:53

В нашем проекте много шаблонов. cpplint не на один из них не выдавал предупреждения. Исключения тоже не были замечены в warning'ах. Кроме того, в рамках данного проекта cpplint запускается с некоторыми отключенными проверками (в том числе и проверка копирайта; полный список отключенных проверок может подсказать автор).
Резюме: данный скрипт помог нам выявить достаточно много «вольностей», которые позволяют себе программисты при написании кода.

@mefrill 8 мар 2013 в 06:51

Да, конечно, некоторые проверки можно отключить опциями. Но, для полноценного использования я скрипт обычно подстраиваю. Какие типичные проблем сразу вспоминаются:
* Проблема с проверкой порядка включения заголовочных файлов. Проверяемый порядок включения таков: файлы стандартной библиотеки C, файлы STL, файлы третьих библиотек (в угловых скобках), файлы проекта (в двойных кавычках). Т.к. в Google не используют Boost, там ничего про него не сказано и программка ругается на такие заголовки. Скрипт приходится менять.
* Т.к. исключения в Google не разрешены, скрипт не знает ключевого слова catch и потому ругается на конструкцию вида catch (...). Скрипт думает, что это вызов функции, а в стиле Google между именами функций и скобками нельзя ставить пробелы. Надо добавить catch в список ключевых слов.
* Проверку копирайта конечно можно отключить, но хотелось бы ее как-то использовать. Я обычно в своих программах использую Doxygen комментарии и для описания файла задаю такой шаблон:
/** Copyright © 2011-2013, CompanyName.
* \file File name
* \brief File description.
* \author Author name.
* \date Date
*/

Не так трудно поменять скрипт, чтобы он проверял наличие таких комментариев в начале файла. С методами/классами я не заморачивался, но можно было бы, при желании.

В общем, было бы здорово иметь такие вещи в качестве параметров.