きれいなコードを書いてもらうようにするにはどうしたらよいでしょうか？

会社でプログラマをしています。開発言語は主にC#です。
会社のほかの人たちがあまりきれいなコードを書いてくれません。
例を挙げれば、以下のようなコード警告すら無視してしまいます。
というより、どんな警告があるのか調べようとか勉強しようという意思すらありません。

【警告の例】
https://docs.microsoft.com/ja-jp/dotnet/fundamen …
https://docs.microsoft.com/ja-jp/dotnet/fundamen …
https://docs.microsoft.com/ja-jp/dotnet/fundamen …

こういった警告を無視してしまうのは、最悪しょうがないとしても、
せめてこういう警告が悪いものであるということ・・・というか、最悪でもどんな警告があるか調べるぐらいの意識を持ってほしいと思うのですが、
そのためにはどうしたらよいでしょうか？

No.7 ベストアンサー 回答者： naktak 回答日時： 2022/02/15 12:02

> チームごとの都合もあるだろうと思い、細かいルールはチームで決めてく

> ださいとお願いしました。
うーん、そうなんですか？
チームではなく会社として策定されればいいと思うんですが。
ソリューションの『種類』で標準化されたルールがあればいいと思います。
その上で、必要ならソリューションごとにルール追加を行えばいいと思います。
ルールを気にしていない場合、ルール追加するなんて思考が出てこないでしょうからeditorconfigをいじる機会もないでしょう。
特定の理由がないルール決めをチームやソリューションに依存して委ねてはいけませんよ。

ルールの策定とは、意識を持つことが目的ではありません。
最終的な効果としては、品質の担保、コストの削減が主な目的として挙げられるはずです。

他人に意識を持たせることは不可能であり、それでもやもやするのは不毛です。
意識させることではなく、強制させること／意識する必要がない状態（普通という感覚）にすることが重要かと思います。

そういったルールの適用を日々推進および監視していくしかありません。
editorconfigで制御できる部分を文書ファイルで用意する必要もありませんし、文書ファイルで書いても見ない人は見ませんし。
そういう意味でも、推進さえすれば、editorconfigは有効かと思います。

No.6 回答者： naktak 回答日時： 2022/02/12 18:24

editorconfigは個人個人で編集するものではなく、用意したものをソリューション、プロジェクトファイルとともに配布するのですよ。

趣味で個人でやってるのではないのですから。
gitやsvnでソース管理してないのですか？

この回答へのお礼

すいません、説明の仕方が悪かったかもしれません。
もちろん、editorconfigの編集は各製品のチームでやっています。
個人個人で編集していません。
最初は私が作り、それを各チームに配布しました。
で、配布する際、チームごとの都合もあるだろうと思い、細かいルールはチームで決めてくださいとお願いしました。

私が言った面倒というのは、チームリーダーがeditorconfigの編集を面倒だと思っているということです。
言い換えれば、ルールの策定が面倒だと思われているということです。
とはいえ、チームによっては私が配布したeditorconfigを使っているところもあるようです。

お礼日時：2022/02/12 23:03

No.5 回答者： tknakamuri 回答日時： 2022/02/11 22:18

具体的なコードが無いので何とも言えないけど、

再スロ―は確かに不味いけど、他のは
どれもかなり厳し過ぎる警告で、後はスタックトレース出して
落ちるしかない時は普通はわざわざそこまでしない。

後でスタックトレースをフルに読める運用なら
警告OFFを書き込むだけというパターンが多いと思う。


例外の扱いはプロジェクトの方針に従って
柔軟に考えるべき。無闇に例外の種類を量産しても
怒られると思うよ。どこ迄許すのかはプロジェクト
で良く話あおう。

余談だけど、JavaではcheckStyleでコードの品質チェックを
行なうけど、有名なSunのSun_checkは、理想的だけど
厳しすぎで生産性が落ちるので、皆適度に緩めて使ってます(^_^;)

この回答へのお礼

再スロ―は確かに不味いけど、他のは
どれもかなり厳し過ぎる警告で、後はスタックトレース出して
落ちるしかない時は普通はわざわざそこまでしない。

感覚的な話なので、人によって考えが変わるところかもしれませんが、ほかも厳しすぎますか？

https://docs.microsoft.com/ja-jp/dotnet/fundamen …
↑のサイトには
「どのようなときに警告を抑制するか
この規則による警告は抑制しないでください。」
とはっきり書かれていますし、例外キャッチぐらいのことを厳しいと感じたことはないのですが・・・

もう少し詳しく『なぜ厳しいと感じるのか』を説明していただけますか？
もちろん、すでに説明いただいているのは分かるのですが、より詳しくという意味です。

> 例外の扱いはプロジェクトの方針に従って
> 柔軟に考えるべき。無闇に例外の種類を量産しても怒られると思うよ。
私はむやみに例外の種類を量産するとは言っておりません。

お礼日時：2022/02/12 16:52

No.4 回答者： naktak 回答日時： 2022/02/11 19:41

利用しているVisual Studioのバージョンはいくつでしょう？

バージョンによってはeditorconfigを用意することで、ルールを配布することができ、警告から禁止に設定すれば、コンパイルできない状況を作ることができます。

この回答へのお礼

editorconfigは数カ月前に一度提案しましたが、浸透しませんでした。
editorconfig自体の編集が面倒と思われているようです。

お礼日時：2022/02/12 16:55

No.3 回答者： 初心者ですが何か。 回答日時： 2022/02/11 18:13

個人的に見ていて嫌なのか会社として改善を考えているのかでも違うかもね。

会社としてなら『作業の標準化』を定めて指導・教育を徹底する。
質問者さんが先頭に立って良いのかも。

ただ会社の経営陣的に『動いていれば問題ない』的な考えなら、黙っているか転職を検討するかでないとストレス溜めそう。

この回答へのお礼

確かに、転職もいい案ですね

お礼日時：2022/02/12 16:55

No.2 回答者： おーニック 回答日時： 2022/02/11 17:45

コードの書き方をルール化するしかないでしょうね。

それに加えて、警告が出ている状態ではレビューを通過させないことも大事です。

この回答へのお礼

ほかの方も言っておられますが、.editorconfigを使ったルールを推奨したことがあります。
と言っても、それを無視されたのですが・・・

あと、この警告はVisual Studioのデフォルトでは出ないんですよ。
なので、警告が出ている状態でレビューを通過させないといってもあまり意味がありません。
さらにすでに数千の警告が出ているプロジェクトもあるので、現実的に警告が出ている状態でレビュー通過できないとしてしまうと、やばいことになりそうです。

お礼日時：2022/02/12 16:55

No.1 回答者： lv4u 回答日時： 2022/02/11 17:25

１．C#の書き方などを教えてくれるセミナーなどに会社の経費で出席させる。

２．しっかり勉強して、良いコードを書いたら、給料２倍、３倍になるよ！というような制度を会社に作ってもらう。

この回答へのお礼

確かに、プログラムを書く人たちのモチベーションを上げないとやってくれませんよね・・・

お礼日時：2022/02/12 16:53