Правило Checkstyle для предотвращения вызова некоторых методов и конструкторов

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

Первый вариант — использовать Разное->Регулярное выражение. Это, очевидно, возможно только в том случае, если вы можете найти нарушения с помощью регулярного выражения. Вам нужно будет установить absolutePattern = true. Я думаю, это было бы хорошим местом для начала.

Второй вариант — создать свой собственный чек. См. Написание чеков.

Существуют ограничения на написание чекеров. Первое и самое важное заключается в том, что вы не можете видеть другие файлы. Нет никакой перекрестной проверки. С сайта:

1. Вы не можете определить тип выражения.
2. Вы не можете видеть содержимое других файлов. (хотя вы можете сохранить обработанные файлы для последующего использования)

Это означает, что вы не можете реализовать некоторые функции проверки кода, которые доступны в продвинутых IDE, таких как IntelliJ IDEA. Например, вы не сможете реализовать проверку, которая находит избыточные приведения типов или неиспользуемые общедоступные методы.

Таким образом, вы не могли проверить, например, что java вызывает один метод, у которого есть альтернатива с Locale. Вы можете использовать черный список методов, которые вам не разрешено вызывать. Так, например, вызовы new FileWriter() будут проверять количество переданных параметров или что-то в этом роде.

Я думаю, что обработчик аннотаций будет более подходящим для этой задачи. Из ответа Мэтью Фарвелла "Вы не можете определить тип выражения".

Предположим, вы используете стороннюю банку, которая содержит класс FancyWriter, расширяющий FileWriter. Вы незаконно поставили x = new FancyWriter ( ) ; в свой код. CheckStyle не найдет его, потому что он использует регулярные выражения и недостаточно умен, чтобы знать, что FancyWriter — это FileWriter. Я думаю, вы могли бы написать обработчик аннотаций, который определяет, что FancyWriter на самом деле является FileWriter и является незаконным.

OTH, кто-то - в теории - может написать расширение нелегального класса, которое сгладит системную зависимость. Например, предположим, что у FileWriter есть метод, в котором он получает системную кодировку. Если LegalWriter расширяет FileWriter и переопределяет метод, то мы не должны отвергать LegalWriter только потому, что он расширяет недопустимый класс.

Если вы используете сторонние банки, как их классы будут законными. То, что они не расширяют незаконный класс, не означает, что они его не используют. Затем, если вы используете один из их классов, ваш код зависит от системы.

Как Мэтью и эмори заявил, что не существует идеального решения со стилем проверки. Вот мое предложение:

• Не запрещайте только некоторые конструкторы, а запретите все конструкторы затронутых классов. Затем создайте свой собственный подкласс, который скрывает запрещенные конструкторы. Например, создайте шаблон контрольного стиля "FileWriter\(" и подкласс SystemIndependentFileWriter только с некоторыми конструкторами суперкласса.
• Создайте паттерн "toLowerCase()" и надейтесь, что никто не создал метод с таким именем. Или используйте FindBugs, чтобы отловить это.
• Создайте узор в виде клетки "Calendar.getInstance()". Я не вижу проблемы с этим.

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