RequireThis должен зарегистрироваться в Checkstyle быть включенным?
Я думаю, что это работает на SQL 2000:
SELECT
CASE WHEN C.autoval IS NOT NULL THEN
'Identity'
ELSE
'Not Identity'
AND
FROM
sysobjects O
INNER JOIN
syscolumns C
ON
O.id = C.id
WHERE
O.NAME = @TableName
AND
C.NAME = @ColumnName
5 ответов
Правило RequireThis действительно имеет допустимое применение, поскольку оно может предотвратить возможную ошибку в методах и конструкторах, когда оно применяется к полям. Приведенный ниже код почти наверняка является ошибкой:
void setSomething(String something) {
something = something;
}
Такой код компилируется, но ничего не делает, кроме переназначения значения параметра метода самому себе. Более вероятно, что автор намеревался сделать следующее:
void setSomething(String something) {
this.something = something;
}
Это опечатка, которая могла произойти, и ее стоит проверить, так как она может помочь предотвратить сложные отладочные проблемы в случае сбоя кода, потому что this.something не устанавливается намного позже в программе.
Параметры стиля проверки позволяют вам сохранить эту полезную проверку полей, исключив в значительной степени ненужную проверку для методов, настроив правило следующим образом:
<module name="RequireThis">
<property name="checkMethods" value="false"/>
</module>
Когда дело доходит до методов, это правило не имеет реального эффекта, потому что вызывает this. getMeSomething () или просто getMeSomething () не влияет на разрешение метода Java. Вызов this.getSomethingStatic () по-прежнему работает, когда метод статичен, это не ошибка, это только предупреждение в различных IDE и инструментах статического анализа.
Я бы обязательно выключил. Использование this.foo () - это неидиоматическая Java, и поэтому его следует использовать только при необходимости, чтобы сигнализировать о том, что в коде происходит что-то особенное. Например, в установщике:
void setFoo(int foo) {this.foo = foo;}
Когда я читаю код, в котором это неоправданно используется, я обычно помечаю его программисту, не обладающему твердым пониманием объектно-ориентированного программирования. Во многом потому, что я обычно видел этот стиль кода у программистов, которые не понимают, что этот не требуется везде.
Я искренне удивлен, увидев это как правило в библиотеке CheckStyle.
Звонок с "этим". не останавливает вызов от вызова переопределенного метода в подклассе, поскольку это относится к «этому объекту», а не «этому классу». Это должно помешать вам принять статический метод за метод экземпляра.
Если честно, это не похоже на особо распространенную проблему, я лично не думаю, что это стоит компромисса.
Я бы включил эту проверку только для полей, потому что мне нравится дополнительная информация, добавляемая " this. " перед полем.
См. Мой (старый) вопрос: Вы ставите перед переменной экземпляра префикс this в java? .
Но для любого другого проекта, особенно устаревшего, я бы не стал активировать его:
- шансы являются, ключевое слово '
this.' почти никогда не используется, что означает, что эта проверка вызовет массу предупреждений. - переопределения имен (например, поля и метода с аналогичным именем ) очень редки из-за того, что текущая среда IDE по умолчанию отмечает этот код собственным предупреждением.
Лично я бы не стал включать его. В основном потому, что всякий раз, когда я читаю код, я читаю его в IDE (или в чем-то еще, что выполняет интеллектуальное форматирование кода). Это означает, что различные типы вызовов методов и доступа к полям форматируются на основе их фактического семантического значения, а не на основе какого-либо (возможно, неправильного) указания.
this. не требуется для компилятора, и когда IDE выполняет интеллектуальное форматирование, это также не требуется для пользователя. И написание ненужного кода является лишь источником ошибок в этом коде (в этом примере: использование this. в некоторых местах и неиспользование его в других местах).