Checkstyle 冗长的解决方案?

发布于 2024-09-14 08:04:29 字数 402 浏览 5 评论 0原文

在包含许多 getter 和 setter 的代码示例中,存在以下 CHECKSTYLE 表示法:

/* CHECKSTYLE:OFF */
public void setDisplayName(final String displayName) {
    this.displayName = displayName;
}
/* CHECKSTYLE:ON */

/* CHECKSTYLE:OFF */
public String getDisplayName() {
    return displayName;
}
/* CHECKSTYLE:ON */

我发现这会使代码变得混乱,使其更难以阅读。

是否有更简单的方法来添加这些符号,以便它们不会像本示例中那样出现在每个方法定义的开头和结尾?

In a code sample containing many getters and setters, the following CHECKSTYLE notations exist:

/* CHECKSTYLE:OFF */
public void setDisplayName(final String displayName) {
    this.displayName = displayName;
}
/* CHECKSTYLE:ON */

/* CHECKSTYLE:OFF */
public String getDisplayName() {
    return displayName;
}
/* CHECKSTYLE:ON */

I find that this muddies the code, making it more difficult to read.

Is there a simpler way to add these notations so that they are not at the beginning and end of every method definition as in this example?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

悟红尘 2024-09-21 08:04:29

您是否尝试过更新 Javadoc 方法 Checkstyle 配置,以便在 getter 和 setter 上不需要 javadoc使用allowMissingPropertyJavadoc 属性?

根据您是否只是过滤 getter 和 setter javadoc 还是更复杂的东西,这可能是一个更好、更干净的解决方案。

Have you tried updating your Javadoc method Checkstyle configuration to not require javadoc on getters and setters by using the allowMissingPropertyJavadoc property?

Depending on if you're after just filtering the getter and setter javadoc or something more complicated, this may be a better, cleaner solution.

狂之美人 2024-09-21 08:04:29

您引用的符号称为 SuppressionCommentFilter,它使用成对的注释来抑制审核事件。您可以将它们维护在单独的文件中,而不是在代码中进行这些抑制,如以下链接中所述: SuppressionFilter

但是,根据您的具体情况,有理由在代码中维护它:

当这是代码问题时
问题而不是个人喜好,
推翻政策的最佳地点
位于代码本身中。半结构化
评论可以与
查看。这有时优于
单独的抑制文件,该文件必须
与源文件一样保持最新
已编辑。

The notation you refer to is called a SuppressionCommentFilter which uses pairs of comments to suppress audit events. Instead of having these suppressions in the code you could maintain them in a separate file as is explained in this link: SuppressionFilter

However there are reasons for maintaining it in the code, depending on your circumstance:

When this is a matter of the code in
question and not personal preference,
the best place to override the policy
is in the code itself. Semi-structured
comments can be associated with the
check. This is sometimes superior to a
separate suppressions file, which must
be kept up-to-date as the source file
is edited.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文