Comments 18
Даниил, как я понял, с внутренностями checkstyle`а ваша команда хорошо познакомилась. А насколько сложно портнуть его на другие языки, которые в eclipse используются? К примеру парсер кода более абстрактным сделать. Часть проверок абстрагировать также на большинство языков, а в конкретные уже добавлять свои. Это реально? Или он не может заиспользовать из eclipse ничего?
Как я понял сам парсер «самописный», а уже в IDE`шках просто как GUI-фронтэнд используется. Но можно ли наоброт сделать — у конкретной IDE`шки заюзать парсер и уже далее по более абстрактному плану. Или не совсем?
Как я понял сам парсер «самописный», а уже в IDE`шках просто как GUI-фронтэнд используется. Но можно ли наоброт сделать — у конкретной IDE`шки заюзать парсер и уже далее по более абстрактному плану. Или не совсем?
Чекстайл полностью завянан на Java. Поэтому, на мой взгляд, врядли удастся использовать код его движка для работы с другими языками программирования, отличными от Java. По затраченным усилиям это будет практически равноценно переписыванию всего проекта с нуля, но уже для других языков
Во время студенчества у меня были 2 курсовые работы, посвященные чекстайлу и использованию его для других языков.
Насколько я помню, архитектура чекстайла достаточно гибкая: нет никаких проблем дополнить чекстайл рядом своих собственных классов-«чекеров», это делается декларативно через xml-конфигурацию.
Но: архитектурно checkstyle не рассчитан на использование нескольких языков (язык один, и подразумевается, что это Java). Чекеры не имеют возможности сказать, для какого языка они реализованы.
Итого: использовать checkstyle для других языков можно, но
1. Потребуется собственно грамматика языка (написанная на ANTLR 2)
2. Написать свой аналог класса TreeWalker, так чтобы использовалась корректная грамматика.
3. С большой долей вероятности чекеры переиспользовать не удастся (другой язык — иная структура дерева, другие ID лексем в грамматике и т.п.)
Переиспользовать можно будет все, что не завязано на анализ дерева и всю инфраструктуру (работа с конфигурациями, логирование, регистрация проверок)
Насколько я помню, архитектура чекстайла достаточно гибкая: нет никаких проблем дополнить чекстайл рядом своих собственных классов-«чекеров», это делается декларативно через xml-конфигурацию.
Но: архитектурно checkstyle не рассчитан на использование нескольких языков (язык один, и подразумевается, что это Java). Чекеры не имеют возможности сказать, для какого языка они реализованы.
Итого: использовать checkstyle для других языков можно, но
1. Потребуется собственно грамматика языка (написанная на ANTLR 2)
2. Написать свой аналог класса TreeWalker, так чтобы использовалась корректная грамматика.
3. С большой долей вероятности чекеры переиспользовать не удастся (другой язык — иная структура дерева, другие ID лексем в грамматике и т.п.)
Переиспользовать можно будет все, что не завязано на анализ дерева и всю инфраструктуру (работа с конфигурациями, логирование, регистрация проверок)
А вот неплохо бы его перевезти с ANTLR2 на что-то более универсальное, где парсеры есть для большего числа языков. Напр., тот же эклипс. Хотя я внутренностей его не знаю. Либо не эклипс, а что-то другое,…
Хотя стоп! www.antlr.org/wiki/display/ANTLR3/Code+Generation+Targets
Там же уже много чего есть. МОжно же по идее абстрагироваться от явы или в текущей версии всё черезчур завязано на яву?
ps: Да он ещё щас и третьей версии подлец :)
Хотя стоп! www.antlr.org/wiki/display/ANTLR3/Code+Generation+Targets
Там же уже много чего есть. МОжно же по идее абстрагироваться от явы или в текущей версии всё черезчур завязано на яву?
ps: Да он ещё щас и третьей версии подлец :)
А как связан эклипс с парсерами? Если вы про подсветку синтаксиса, то она синтаксического анализа не требует (как правило, это просто лексический сканнер).
И target для ANTLR — это язык, в который превратится ваша грамматика. ANTLR — это генератор парсеров, таргет — это язык, на котором будет «написан» итоговый парсер. К самой грамматике это не имеет отношения.
Если вы хотите, чтобы checkstyle понимал другие языки, таргеты вам не помогут. Вам потребуется грамматика того языка, который вы хотите анализировать, причем описанная в терминах ANTLR 2.
Если вы хотите, чтобы checkstyle понимал другие языки, таргеты вам не помогут. Вам потребуется грамматика того языка, который вы хотите анализировать, причем описанная в терминах ANTLR 2.
Полностью согласен, так и есть
Полностью согласен с knekrasov, переписыванием лишь кода класса TreeWalker и подменой ANTLR-грамматики изменение кода Checkstyle под новый язык явно не обойдется. Игра не стоит свеч. Возможно, именно поэтому мы до сих пор не увидели разновидностей движка Checkstyle, написанных под языки, отличные от Java.
А как насчёт разрешения подавлять ворнинги в тех случаях с генериками и вараргами, когда ворнинги неизбежны из-за специфики эмуляции генериков и вараргов в Java-компиляторе?
Вы упомянули о патчах в Checkstyle и что ваш проект эту проблему позволяет решить.
Вы вносите патчи в исходный код библиотеки? И нет ли проблем с лицензией в этом случае?
Вы вносите патчи в исходный код библиотеки? И нет ли проблем с лицензией в этом случае?
Все чеки, внесенные в наше дополнение (как, собственно, тут и сказано), объединены в отдельный проект. Этот проект является «плагином к плагину» для eclipse-cs. Собирается проект в jar-файл, содержащий только наши дополнительные чеки с необходимыми конфигурационными файлами. Благодаря сотрудничеству со стороны держателей проекта Eclipse-cs (за что мы им очень благодарны), данный jar подхватывается Eclipse Checkstyle плагином, но только совместно с официальной библиотекой Checkstyle. Таким образом, при добавлении своих чеков, мы всегда обходимся без изменения исходного кода основной библиотеки Checkstyle. Насчет лицензии: Checkstyle распространяется по GNU LGPL, со всеми вытекающими.
Конечно, мы предлагаем многие чеки, написанные нами, в качестве патчей к основному проекту Checkstyle. Их легко можно найти на патч-трекере Checkstyle. Но пока чеки еще не приняты, или если они не приняты вообще — мы легко можем все равно (никому не мешая =) ) использовать их в разработке, добавляя в наше дополнение.
Почитал предыдущие посты, возник вопрос — чем плох @Autowired на private полях?
Проблема с @Autowired в следующем. Представьте, что вы написали код, просетив в нем значения филдов через @Autowired на самих private — филдах. Следующий человек вполне может прийти в тот же код после вас и дописать свои сеттеры для тех же филдов (это может быть, например, необходимо для Unit — тестов, либо такое происходит, если функционал класса изменяется и get/set — методы становятся результатом рефакторинга). И в результате пересетить ваши значения, что иногда может вести к весьма странным ситуациям. Если класс больших размеров, то такую ситуацию несложно не заметить. Плюс существует правило, говорящее, что любой field, участвующий в логике, должен иметь паблик-сеттер/геттер для того, что программист мог видеть, что необходимо для работы с данным классом. Плюс декларирования одинакового стиля инжектирования зависимостей для всего проекта, что может быть полезным с точки зрения стиля кода. Поэтому вполне стоит с помощью Checkstyle запретить @Autowired на private — филдах и разрешить @Autowired только на соответствующих сеттерах. В случае исключений можно отключить чекстайл напрямую для участка кода (методов или филдов) с помощью комментария вида:
// SUPPRESS CHECKSTYLE <Имя чека> <Комментарий>
// SUPPRESS CHECKSTYLE <Имя чека> <Комментарий>
А если @Autowired стоит на сеттере, это разве помешает его вызвать и пересетить?
Это ведь видно из объявления полей? Ну и для тестов, конечно, нужны сеттеры.
любой field, участвующий в логике, должен иметь паблик-сеттер/геттер для того, что программист мог видеть, что необходимо для работы с данным классом
Это ведь видно из объявления полей? Ну и для тестов, конечно, нужны сеттеры.
Sign up to leave a comment.
Checkstyle и Java. Поможет ли автоматическая инспекция кодa?