Часто flex-разработчики работают в небольших командах, либо (о, ужас) в одиночку. А это может привести к тому, что утрачивается критическое отношение к своему коду. Но мы же не хотим деградации! =)

Некоторое время назад Adode выпустили инструмент, который покритикует, укажет на недоработки, ошибки и bad practices в коде – это FlexPMD.
Расшифровка PMD точно неизвестна, но мне нравится – Programming Mistake Detector. Эту технологию уже давно используют Java-разработчики.

Даже если вы пишете идеальный код (чего, конечно, не бывает), то будет полезно узнать про пару-тройку неиспользуемых методов или наличие пустых используемых методов. Или может в каком-то методе затесался неиспользуемый аргумент? =)

На пути к идеальному коду у вас три этапа:

1. определение правил, на соответствие которым будет проверен код (используем FlexPMD Ruleset Creator)
2. запуск FlexPMD и получение в результате файла с расширением pmd.xml
3. просмотр pmd-файла, например, с помощью PMD Violations Viewer

Набор правил

Прежде всего необходимо определиться с набором правил, по которым будет проверяться код. Адобе предоставил FlexPMD Ruleset Creator, который по умолчанию предлагает набор из 84 правил разного приоритета: Error, Warning, Info. Этот набор можно редактировать и сгенерить файл pmd.xml, который будет в дальнейшем использоваться при проверке кода.

Расскажу кратко про некоторые правила.

Error priority

Ошибками считается:

• использование BindingUtils и ChangeWatcher. Да и как тут не согласиться? Ведь на этапе компиляции вы не узнаете о том, что все плохо.
• использование callLater. А кто бы сомневался?
• использование dynamic классов, Dictionary, Object и *.
• создание или удаление чайлдов внутри updateDisplayList и вообще не внутри createChildren
• dispatch события внутри конструктора (а кому нужны такие события? =))
• некорректные метаданные [Event]. Вот это удобно.
• использование не статических констант. Константы обязаны быть статическими.
• наличие неиспользуемых, методов, параметров и тд. Это полезно. Часто в больших проектах повисают неиспользуемые методы, классы и даже пакеты. =)

Warning priority

• Предупреждают, что не надо инстанциировать переменную в цикле.
• Не рекомендуют использовать статические переменные. И правильно.
• Также не рекомендуют делать весь класс [Bindable]. Тоже правильно. Что тут скажешь?
• Находит слишком сложные методы и указывает на это. Если программе метод кажется слишком сложным, то что же делать вашим коллегам?
• Ну и конечно вложенные if else никуда не годятся.
• Много импортов наводят программку на размышления о том, что этот объект связан слишком со многими. А это не есть гуд.
• Слишком длинные методы, конструкторы и тп не нравятся никому.
• Кстати, на нравятся заглавные буквы в названии пакетов. Что ж. Может в этом что-то есть.
• Очень приятно, что даются рекомендации понижать уровень видимости методов. Ура-ура! =)
• Слишком много параметров у метода? Да я сама это терпеть не могу.
• Наблюдая переменные со странными именами (наличие цифр, tmp и тд), программа тоже дает об этом знать.

Info priority

• Слишком короткое имя переменной.
• Слишком длинная строка кода.
• Конструктор какого-то фига имеет возвращаемое значение.
• Отсутствует copyright header.

В общем, лично я считаю эту программу крайне полезной. Если вы практикуете в команде ревью кода, то это может помочь на начальном этапе. Если команды нет, то полезно для самоорганизации.

Шаги к идеальному коду с помощью Ant

Приведу шаги, в результате которых, вы сможете узнать всю правду про свой код. =)
Это вариант с использованием Ant.

1. Скачиваем нужную версию http://opensource.adobe.com/wiki/display/flexpmd/Downloads из колонки “Ant Task”
2. Распаковываем архив в любое удобное место, например в C:\Program Files\flex-pmd
3. С помощью FlexPMD Ruleset Creator создаем файл pmd.xml и кладем в любое удобное место, например тоже в C:\Program Files\flex-pmd. Для начала можно правила не редактировать, а просто кликнуть “Export” и сохранить файл.
4. В файл свойств для build.xml добавляем переменные
   FLEXPMD=c:/Program Files/flex-pmd
   FLEXPMD_VERSION=1.0.RC4
   Пример файла local.properties:
   FLEXPMD=c:/Program Files/flex-pmd
   FLEXPMD_VERSION=1.0.RC4
   SRC_DIR =${basedir}/src
   DEPLOY_DIR = ${basedir}/DEPLOY

5. Пример build.xml:

   XML:

   	<project name="" default="pmd">
   	<!−− load previously defined configuration properties file −−>
   	<property file="local.properties" />
   	<!−− delete and create the DEPLOY dir again −−>
   	<target name="init">
   	<delete dir="${DEPLOY_DIR}" />
   	<mkdir dir="${DEPLOY_DIR}" />
   	</target>
   	<taskdef name="flexPmd"
   	classname="com.adobe.ac.pmd.ant.FlexPmdAntTask"
   	classpath="${FLEXPMD}/flex-pmd-ant-task-${FLEXPMD_VERSION}.jar">
   	<classpath>
   	<pathelement location="${FLEXPMD}/flex-pmd-ruleset-api-${FLEXPMD_VERSION}.jar"/>
   	<pathelement location="${FLEXPMD}/flex-pmd-ruleset-${FLEXPMD_VERSION}.jar"/>
   	<pathelement location="${FLEXPMD}/flex-pmd-core-${FLEXPMD_VERSION}.jar"/>
   	<pathelement location="${FLEXPMD}/as3-plugin-utils-${FLEXPMD_VERSION}.jar"/>
   	<pathelement location="${FLEXPMD}/as3-parser-${FLEXPMD_VERSION}.jar"/>
   	<pathelement location="${FLEXPMD}/pmd-4.2.2.jar"/>
   	<pathelement location="${FLEXPMD}/commons-lang-2.4.jar"/>
   	<pathelement location="${FLEXPMD}/flex-pmd-files-${FLEXPMD_VERSION}.jar"/>
   	<pathelement location="${FLEXPMD}/as3-parser-api-${FLEXPMD_VERSION}.jar"/>
   	<pathelement location="${FLEXPMD}/plexus-utils-1.0.2.jar"/>
   	</classpath>
   	</taskdef>
   	<target name="pmd" depends="init">
   	<flexPmd
   	sourceDirectory="${SRC_DIR}"
   	outputDirectory="${DEPLOY_DIR}"
   	ruleSet="${FLEXPMD}/pmd.xml"/>
   	</target>
   	</project>

6. Полученный pmd.xml анализируем с помощью PMD Violations Viewer