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

Question

Можно ли использовать Checkstyle, чтобы запретить использование некоторых конструкторов или методов, которые используют системные значения по умолчанию (локаль, кодировка и т. Д.).Я предпочитаю применять политику, в которой программист должен четко указывать системные значения.Поэтому я считаю опасными следующие элементы:

• все конструкторы java.io.FielWriter
  • с использованием системно-зависимого кодирования
• OutputStreamWriter(OutputStream os) конструктор java.io.OutputStreamWriter
  • с использованием системно-зависимого кодирования
• метод java.lang.String.toLowerCase()
  • с использованием системного языкового стандарта по умолчанию
• Метод java.util.Calendar.getInstance()
  • с использованием системного языка по умолчанию и часового пояса по умолчанию

(список можно продолжить, вы получитеизображение).

Возможно ли применить это с помощью Checkstyle 5.5?

Answer 1

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

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

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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