-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
slim-lintの4ルールが適用できるか調査し反映する #7395
Conversation
@yocchan-git |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
確認しました!OKです🎉
- 信頼できるサイトのリンクを貼ってある
- ログを書いている
- なぜその判断かの経緯もしっかり書いてある
など、丁寧に書いてあったので負担なくレビューできました。🙇♂️
対応ありがとうございました🙏
@yocchan-git |
@komagata |
config/slim_lint.yml
Outdated
@@ -26,11 +25,11 @@ linters: | |||
- Layout/MultilineOperationIndentation | |||
- Layout/ParameterAlignment | |||
- Layout/TrailingEmptyLines | |||
- Lint/Void | |||
- Metrics/BlockLength | |||
- Lint/Void #除外検討したが見送り |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
このタイプのコメントがこの設定ファイル中で本当に機能するのかが気になりました。
また、コメントはだいたい#
から1スペース開いてることが多いのでそれに合わせた方がいいかなと思いました。
- Lint/Void #除外検討したが見送り | |
- Lint/Void # 除外検討したが見送り |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@komagata
.yml
の形式のファイルのコメントの仕様について調べてみました。
いくつかサイトを見たところ、コメントの前に#
を付ける形でよいということでした。
#のあとからその行の末までがコメント扱いになります。
ということで、コメントのタイプはそのままで据え置き、#
の後に1スペース追加のみしております。
確認よろしくお願いいたしますm(__)m偽t
以下確認したサイト例です
https://www.redhat.com/ja/topics/automation/what-is-yaml
https://apidog.com/jp/blog/how-to-write-a-yaml-file/
config/slim_lint.yml
Outdated
@@ -25,11 +25,11 @@ linters: | |||
- Layout/MultilineOperationIndentation | |||
- Layout/ParameterAlignment | |||
- Layout/TrailingEmptyLines | |||
- Lint/Void #除外検討したが見送り | |||
- Metrics/BlockLength #除外検討したが見送り | |||
- Lint/Void # 除外検討したが見送り |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Lint/Void # 除外検討したが見送り | |
- Lint/Void # 除外検討したが見送り |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@komagata
確認が甘く、修正の爪が甘くて申し訳ございません。
3つとも#の前の不要なスペース1つを削除しました。
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
確認させて頂きました。OKです〜🙆♂️
Issue
slim-lintの5つのルールを適用させるissueのうちの4つのルールについての調査結果を反映させています。
残り1ルール↓
slim-lintのルール「Layout/LineLength」を適用する #7345
補足情報のあるissue
概要
slim-lintが指摘するルールで無視する設定になっているもののうち、以下4つのルールについて調査を行いその結果を
config/slim_lint.yml
に反映させています。指摘の付くビューファイルがなかったため設定ファイルから該当ルールの記述のみ削除したもの1つ
Layout/IndentationConsistency
一貫性のないインデントをチェックする、コード内のインデントが一貫しているかどうかを確認するルール
Layout/IndentationConsistency
調査の結果、ルールの適用が困難、あるいは適切でないと判断したため据え置きコメント追加したもの3つ
Lint/Void
メソッド内やブロック内で値を返さない式を検出するルール
Lint/Void
変数などの出力を行う際に
=
を使うslimのルールと相性が悪かったため据え置きとしましたMetrics/BlockLength
コード内のブロックの長さを測定し、長大なブロックがないかどうかを評価するルール
25行以上になると指摘がはいります
Metrics/BlockLength
調べた結果、slimに対しての対処例は見つからなかったのですが、
形式的にブロックが長くなりやすいRSpec(Railsのテストフレームワーク)では無視する設定にしてることが多いということがわかりました
指摘が付いているファイル数から判断するに、slimはブロックが長くなりやすい傾向があるのではと考え、RSpecと同様無視する設定が妥当なのではと考えています
以下指摘が付いたファイルです
また、ブロックの途中に空行をいれたりして結果が変わるか確認してみましたが、slimはインデントでブロックを判断しているため空行では効果がなく、効果のある対処法はリファクタリングだろうという結論になりました。
しかし、指摘が付いてるファイルの数を考えると現実的ではないため、今回は据え置きとしました
Style/FrozenStringLiteralComment
Rubyスクリプト内で
# frozen_string_literal: true
コメントを使用することを推奨するルール# frozen_string_literal: true
コメントを付けることで文字列リテラルがフリーズされてパフォーマンスが上がる場合があるStyle/FrozenStringLiteralComment
このルールを適用するとapp/views以下に置かれているおらくすべてのファイルに対して指摘が付きます。
↓その一部です
# frozen_string_literal: true
コメントをつけることの影響を調査したところ、該当ファイルのRubyのコードの中に文字列リテラルに破壊的な操作を行う箇所があった場合、その操作が許されなくなるためうまく動かなくなる可能性があることがわかりました。したがって、機械的にすべてのファイルにこのコメントを追加するのは不具合を発生させる原因になりかねません。
しかし、すべてのコードを確認し破壊的操作の有無を確認してからコメント追加をするのも対象のファイル数的に現実的ではありません。
また、slim-lintのデフォルト設定だとそもそもこのルール除外する設定にしているみたいです。
https://github.com/sds/slim-lint/blob/main/config/default.yml#L79
slimでの例は見つからなかったのですが、erbでは無効化している例が1つですが見つかりました。
https://zenn.dev/junara/articles/efa04ce1ab02c9
以上のことからこのルールについても今回は据え置きとしました
変更確認方法
1.
feature/apply-4-slim-lint-rules-survey_result
をローカルに取り込む2.bundle exec slim-lint app/views -c config/slim_lint.ymlを実行する
3. 指摘がないことを確認する
Screenshot
機能の変更はないので見た目の変化はありません