Comments 29
Все чаще сталкиваюсь с проблемой чёткого разделения полей класса на свойства (то, что непосредственно характеризует объект) и зависимости (то, что нужно для работы объекта и будет инжектится). А ведь есть еще и константы! Но с ними проще, public static final обычно сразу «выделяются из толпы». Короче, хотелось бы сгруппировать поля по назначению. Приходится писать так (пример взят от балды):
public class BadRobot {
public static final int MAX_HEALTH = 60;
public static final int MAX_SPEED = 15;
// ^ Constants ^
private FuelSupplySystem fuelSupply;
private BulletSupplySystem bulletSupply;
// ^ Dependencies ^
private int currentHealth;
private int currentSpeed;
// Constructors and methods…
}
Можно ли каким-либо образом автоматически отслеживать, чтобы такое разделение всегда соблюдалось?
public class BadRobot {
public static final int MAX_HEALTH = 60;
public static final int MAX_SPEED = 15;
// ^ Constants ^
private FuelSupplySystem fuelSupply;
private BulletSupplySystem bulletSupply;
// ^ Dependencies ^
private int currentHealth;
private int currentSpeed;
// Constructors and methods…
}
Можно ли каким-либо образом автоматически отслеживать, чтобы такое разделение всегда соблюдалось?
Если у вас все имена полей начинаются с «current», то вот такое регулярное выражение поможет вам:
Тогда в данном случае порядок будет такой: константы, поля, dependencies.
Либо надо придумать как описать dependencies одним регулярным выражением (например делать опору на имена, типы или аннотации)
Field(public static final) ### Field(private.*current.*) ### Field(private .*)
Тогда в данном случае порядок будет такой: константы, поля, dependencies.
Либо надо придумать как описать dependencies одним регулярным выражением (например делать опору на имена, типы или аннотации)
по-моему, смахивает на фашизм. Чекстайла, PMD, Findbugs я думаю в большинстве случае достаточно.
А вот если бы был плагин, который код форматировал в соответствии с чекстайлом — это было бы хорошо. Конечно, не все ошибки чекстайла можно исправить (остутствие комментария например), но стилевые вещи можно. А так приходится два конфига иметь — чекстайл и code formatting
А вот если бы был плагин, который код форматировал в соответствии с чекстайлом — это было бы хорошо. Конечно, не все ошибки чекстайла можно исправить (остутствие комментария например), но стилевые вещи можно. А так приходится два конфига иметь — чекстайл и code formatting
под фашизмом подразумевается проверка структуры класса на соответствие нормам. В принципе, это не такой уж фашизм, но, например, фэйлить сборку по такой проверке я рассматриваю как перебор
в intellij idea можно задавать порядок размещения элементов класса
А есть способ спрятать пачку однострочных геттеров и сеттеров?
Вообще, Jalopy прекрасно умеет добавлять комментарии к разным блокам кода, сортировать их по смыслу и алфавиту, добавлять модификаторы, если надо…
Оно прекрасно интегрируется в нетбинс, и, вероятно, в eclipse не хуже…
Оно прекрасно интегрируется в нетбинс, и, вероятно, в eclipse не хуже…
jindent пробовали?
jalopy круче, насколько я помню. Рулит автоматическая сортировка блоков кода
jindent тоже сортирует блоки кода, чем круче то?
Видимо был неправ. Исправлюсь
Да какая разница кто тут прав, просто интересно чем он лучше. В свое время сравнивал их и jindent более цивильно код сортировал и оформлял. Проблема только в том, что jindent платный :) Но он стоит своих денег.
Недавно была статья про svn-hook для агрессивной проверки форматирования кода на C# (режект коммита если проверка не прошла). Мне кажется, лишним реализовать поддержку «из коробки» такой проверки для CheckStyle не будет.
Объясните, пожалуйста, куда вставлять строку «Пример правила из реальной жизни...». По настройкам checkstyle потыкался — не нашёл.
После того, как вы установили себе плагин checkstyle и поставили на него патч с нашими дополнительными модулями, в
Window -> Preferences -> Checkstyle вы создаете, редактируете Check Configuration (New, Configure).
В появившемся окне конфигурации вам надо зайти в группу модулей Coding problems и создать из списка новый модуль Custom Declaration Order Check.
К сожалению, разработчики плагина на checkstyle для Eclipse не предусмотрели multi-line поле для текста, приходится все заполнять в одну строку…
Window -> Preferences -> Checkstyle вы создаете, редактируете Check Configuration (New, Configure).
В появившемся окне конфигурации вам надо зайти в группу модулей Coding problems и создать из списка новый модуль Custom Declaration Order Check.
К сожалению, разработчики плагина на checkstyle для Eclipse не предусмотрели multi-line поле для текста, приходится все заполнять в одну строку…
Все эти ваши «конструктор неожиданно появляется в середине класса» и «внутренний класс объявлен где-то в середине внешнего класса» — это все мышиная возня.
Мне вот интересно, что, реально есть люди, которые при открытии класса прокручивают файл, выискивают методы, конструкторы, атрибуты?
А не используют навигаторы струкур классов, которые выдают перед глазами всю логическую структуру, правильно все группируя (гетеры-сетеры с атрибутами; расширения/перепределения в дочерних классах; реализации интерфейсов) и сортируя, если требуется.
А не используют иерархию пакетов, дабы наблюдать (читай — представлять в голове) вложенность пакетов и агрегацию классов.
А не используют иерархию типов, дабы наблюдать зависимости наследований.
Вас реально волнует отсортированы ли методы по названию, рядом ли расположены атрибут и его методы доступа?
Люди, опомнитесь! (с)
Не спускайте время на мышиную возню — пусть всей рутиной занимается компьютер (IDE), а вы — используйте свою жизненную энергию как подобает homo sapiens — реализуйте свой потенциал, добиваясь сдачи интересных проектов в срок, без багов и с изящной архитектурой, которую не прийдется долго и затратно рефакторить.
Мне вот интересно, что, реально есть люди, которые при открытии класса прокручивают файл, выискивают методы, конструкторы, атрибуты?
А не используют навигаторы струкур классов, которые выдают перед глазами всю логическую структуру, правильно все группируя (гетеры-сетеры с атрибутами; расширения/перепределения в дочерних классах; реализации интерфейсов) и сортируя, если требуется.
А не используют иерархию пакетов, дабы наблюдать (читай — представлять в голове) вложенность пакетов и агрегацию классов.
А не используют иерархию типов, дабы наблюдать зависимости наследований.
Вас реально волнует отсортированы ли методы по названию, рядом ли расположены атрибут и его методы доступа?
Люди, опомнитесь! (с)
Не спускайте время на мышиную возню — пусть всей рутиной занимается компьютер (IDE), а вы — используйте свою жизненную энергию как подобает homo sapiens — реализуйте свой потенциал, добиваясь сдачи интересных проектов в срок, без багов и с изящной архитектурой, которую не прийдется долго и затратно рефакторить.
Sign up to leave a comment.
Автоматический контроль структуры класса