C# のコーディング規約 (改行位置) について

Question

質問

最近 C# の勉強を始めたのですが、他の言語 (主に Java や Swift など) との違いに戸惑っております。
特に気になるのが、コードブロック (クラスやメソッド、if や for など) を開始する { の前で Visual Studio が自動的に改行することで、これによって少々間延びした印象を受けます。

Visual Studio の自動フォーマット機能については設定で変更できるようですが、普通はデフォルトの設定で使うものなのでしょうか？ 設定方法の質問ではなく、一般的なコーディング規約はどうなっていて、どこまでそれに従っているのかをお聞きしたいです。

追記

今は個人で勉強中なので好きなスタイルでもいいのですが、今後他の人と共同作業する際のことを考えて一般的なスタイルを確認したくて質問しました。一貫性が重要ということは理解しているつもりで、だからこそ学習の初期段階で一般的なスタイルに慣れておきたいと思っています。

「一般的」と言っても、統計的なことを知りたいというよりは (もちろんそれも重要ですが)、いろんな現場での経験談を聞かせていただけるとありがたいです。

該当のソースコード

比較のために C# と Swift で同等のコードを書いてみましたが、{ get; set; } だけなら 1 行で済むのに、set に条件をつけるだけでこんなに行数が増えるなんて、と驚いています。

class Item
{
    private int _quantity;

    public int Quantity
    {
        get
        {
            return _quantity;
        }

        set
        {
            if (value >= 0)
            {
                _quantity = value;
            }
        }
    }
}

class Item {
    private var _quantity: Int = 0

    var quantity: Int {
        get {
            return _quantity
        }
        set(value) {
            if value >= 0 {
                _quantity = value
            }
        }
    }
}

試したこと

「C# コーディング規約」で検索して、以下のドキュメントを参照しました。サンプルコードを見る限り { の前で改行しているようですが、改行位置のような細かいことは明示的には書いてありませんでした。

• C# のコーディング規則 - C# プログラミング ガイド | Microsoft Docs
• C# CODING GUIDELINES - Qiita

補足情報（FW/ツールのバージョンなど）

Windows 10
Visual Studio 2019

Comments

[javahack]

個人でやってるなら自分の好きなスタイルで良いと思います。
今はIDEで一括変換できますし。
業務の場合、大抵はコーディング規約が用意されていてそれに従うことになります。

[hoshi-takanori]

コメントありがとうございます。質問の意図が曖昧だった部分について追記しました。
実際の業務で使われているコーディング規約がどうだったかの経験談をお聞かせいだだければ幸いです。

[Zuishin]

public int Quantity
{
get => _quantity;
set => _quantity = value >= 0 ? value : 0;
}

[gentaro]

set => _quantity = value >= 0 ? value : 0;
にしてしまうと、1以上の値をセットした後にマイナスの値が渡された時の挙動が変わるんで、書き換えとしては等価ではないですね。（まぁその動きもどうなんだ、というのはあるけど）

[hoshi-takanori]

set => _quantity = value >= 0 ? value : _quantity;
にすれば一応等価ですかね。

プロパティアクセスで => を使う方法は
https://docs.microsoft.com/ja-jp/dotnet/csharp/programming-guide/classes-and-structs/using-properties
にも書いてあるので、積極的に使っていこうと思います。

[Zuishin]

ああ、本当ですね。最小値未満を入れたら最小値になるものと見間違えていました。

Answer 1

一般的なコーディング規約はどうなっていて、どこまでそれに従っているのかをお聞きしたいです。

何を持って一般的とするのか、というのがわかりませんが、多数派がどちらなのかを調査をしたい場合は、公開されているソースやガイドラインを片っ端から自分で調べるか、誰かが調査した結果を探す必要があります。

そのため、きちんとした調査に基づいたものでなく、あくまで基本的には個人的な感想となりますが、OSSのソースを読む限りだと、改行後に{を配置するケースが多い（というか大半）と思います。それがデフォルトである事が最も大きな理由の一つだと思いますし、本家であるMicrosoft自体がそのスタイルをとっているのも影響しているかもしれません。

どちらが「良い・悪い」というのは宗教論争みたいなものなので、どちら採用するのかは、完全に個々の会社やプロジェクトの判断ですし、行末に{を配置せよ、という会社も実際にありますが、これは他言語で利用していたガイドラインを改変して作成されたという経緯がありました。

結局、ここでも議論されているとおり、「大切なのはそのプロジェクト内で一貫していること」という認識だけは共有できるんじゃないでしょうか。

そもそも、デフォルトである挙動を規約によって変更するには、それなりの理由が必要になると思います。その上でデフォルトの設定から変更されていないケースが（私がこれまで見た限り）少ない、という事は、「行数が増える」事自体への抵抗感はそれほど多くの人が感じていないんじゃないかと思います。昔と違ってディスプレイ解像度が年々上がっている事も関係あるかもしれません。

なお

        get
        {
            return _quantity;
        }

はこう書けます。

        get => _quantity;

Comments

[hoshi-takanori]

貴重な経験談をありがとうございます。統計的な面ももちろん大事ですが、どちらかというと個人の経験談をお聞きしたいと思って質問しました。やはり Microsoft に従っておくのが無難なのでしょうね。
ディスプレイの解像度は上がりましたが、物理的にもソフトウェア的にも (ツールバーとかで) 横にばかり伸びて、縦方向はむしろ圧縮されている印象があったりします。
get を短く書く方法はたいへん参考になりました。さっそく採用させていただきます。

[gentaro]

「年々上がっている」というのはちょっと語弊のある書き方でした。

主に利用される解像度で行数が圧縮されたのはHD1080ぐらいだったような気がします。直近で大きく変わったのでそこの印象は大きいかもしれませんが、VGA時代から推移について考えれば、基本的に画面サイズは拡大されてきています。

Javaが誕生したのが1995年、C#が誕生したのが2000年なので、DOSからの移行世代のJavaと、Windowsが完全に普及してから誕生したC#では、その当時の規約を作る立場にあった人の考え方も大きく変わってきていても不思議ではないのかな、というのと、C#誕生以後にプログラミングを始めた人の多くは基本的にSXGA以上の解像度から入ってると思いますし、現在はHD1080から4Kにシフトしていってますので、なおさらそんなに気にならないような気がします。（もう十分広いので、という意味で）

まぁ、どうしても気になる人は画面の広さに関わらず気になるとは思いますけど。

あと、ソースを印刷してレビューしていた時代の人は、印刷枚数を削減するために行数減らす方向への動機づけもあったような気がします。

[pepperleaf]

> ソースを印刷してレビューしていた
72行だった? 当時から、画面の範囲を気にしてました。80x25行。
さすがに今は、100桁(+α) x 40行 くらいかも。
解像度というより、画面上にどれだけの文字が表示できるか。高解像度でも細かすぎると読めないし、広すぎても、全部は見きれない。

[hoshi-takanori]

ソースを裏紙に印刷していたこともありましたね。関数は 1 画面に収まる長さにしよう、とか。

自分が気になったのは、記述したい内容と行数のバランスに違和感を感じたってことなんですが、コードの書き方やツールの使い方を工夫すればいいことがわかったので、とりあえずデフォルトの設定に自分を慣らして、慣れてきたらまた考えるということにします。

Answer 2

個人的にはjavaの様な{の前に改行を入れないスタイルは見づらくてつらいです。

また、C#の案件でいくつかの現場に入った経験がありますが、改行してから{のスタイルというかほぼIDEのデフォルト設定がほとんどですね。せいぜいtabをtabのままにするか空白4文字に置き換えるかぐらいしか無いかなぁ。
ちなみに長くて邪魔になったら閉じればいいだけだし今どき行数で金額が決まるわけでもないので狭くして見間違いを起こしやすくするよりかは見やすさ重視のところが多いのかも？

少なくともMSのサンプルソースでは改行を入れてからのスタイルになっているので先改行を入れないのは主流ではないかと思います。
とはいえURI.csを見ると同一ソース内でも{の前改行があったりなかったりと混在しているのでそれはそれでどうなんだろう？って思いますけど。

Comments

[hoshi-takanori]

貴重な意見をありがとうございます。自分も昔 C を書いていた頃は { の前で改行しないと見づらいと思っていたはずですが、Java も書くようになって改行しないようになりました。結局は慣れですよね。
「長くて邪魔になったら閉じればいい」については、あまり道具に頼りたくないという気持ちがありますが、Android Studio が匿名内部クラスをラムダ風に短縮表示してくれるのに頼ってたりもするので、やはり慣れですね。

[len_souko]

今どきただのテキストエディタでコーディングすることは無いのでIDEの機能は使えるだけ使った方がミスも少なくなりますので避ける必要はないかと思います。
WindowsだけでなくMacでもLinuxでもそれぞれ「Visual Studio」「Visual Studio for Mac」「Visual Studio Code」とVS三兄弟が使えます。
なお僕はVSしか使っていませんのでforMacとCodeでC#をコーディングするときの差異はあまり知りませんが、どうしようもなく違うということは無いかと思います。

[hoshi-takanori]

もちろん便利なものは使うんですが、たとえ使えなくてもちゃんとできるようにしようと思っておりまして。

Answer 3

同じような考え方に至る感じで懐かしいです。

自分も同じ考えの時期があって、VisualStudioでコードを書いていると
自動的に下に改行して中括弧が下りてしまって違和感がありました。

しかし、ここでふと考えました。

あのマイクロソフトが考えあって、そうやっているのだろうと・・・
で、ならば、そのスタイルに合わせようと。

結果、分かったことは、改行をするとブロックが分かりやすい、
バーっと流した時に、塊（ブロック）が縦に戦が入って表示されているのもあり、直感的に判断しやすく、
とてもいいというのを実感しました。

今では、中括弧は下におろすのが基本という考え方になりました。

両方やってみて下した方が作業効率が良かったのが実感して分かったからです。

特に長いコードの場合は、効果を発揮しました。
些細な中括弧の確認漏れなどおきなくていいですね。見直す作業、
および、ちょっと止めて見る作業が無くなりました。

ルールがどうのこうの、というよりは好みですね。

作業しやすい方を選んでみるといいかと思います。

自分の場合、両方やってみて断然下した方がいいと実感しました。

Answer 4

昔からの Cの流儀でやってます。 と言っても沢山あるので、某社で使わているルール準拠。(細々とチェック入れたけど)　その後、C#もそれに準拠してる模様。

Visual Studioのカスタマイズの範囲内ですが、標準設定では無いです。
具体的には、 4-Tab (Tabのまま)　{ は、クラス/メソッドの直後は改行で、それ以外は改行無し。 .... etc. キリが無い。

まあ、一画面に収まるコードを増やす方向。ただ、詰込み過ぎは避ける。
と言ったところでしょうか。見易さとのバランスが難しく、見易さも人によって違うので、ある程度の割切りは必要でしょう。
海外との分業もあるから、コメントは英語でなんてお達しもあったこともあるが、結局、徹底せず、、どころか、中国人は中国語で書くなど、国際色豊かとなったりです。

多分、一般的なものなど無く、別の方も書いているように、宗教戦争のネタ。

Comments

[hoshi-takanori]

回答ありがとうございます。国際色豊かな環境、いいですね。
インデント幅については、今参考にしているソースは 3 tab のものがあったりしますが、自分のスタイルとしてはとりあえずデフォルトで行こうと思ってます。

Answer 5

配布や個別に設定させるのが面倒なので、基本的にはVisualStudioデフォルト設定です。
その他にクラス、プロパティ、メソッド、メンバ変数で名前つけの規約などがあり、MSのサイトのを参考にしてます。が、ガッチガチに従っている訳でもないです
名前付けガイドライン
横にスクロールさせるのは個人的に抵抗あるので、あまり横に長くなりすぎないように意識はしてます。

一貫性が取れていればいいと思うので、特別な理由が無ければ、基本的にはメジャーなIDEの設定に従う事が多いんじゃないですかね。自動整形や補間で、勝手に修正してくれますし。個人開発なら好みでいいと思います。

Comments

[退会済みユーザー]

ぶっちゃけてしまうと、ある程度出来る人のソースは多少書き方のスタイル違ってても見やすいし（無駄な処理が少ない）、うーんって感じの人のソースは、規約従っていても見づらい（よく分からん処理や無駄なネストが多い）です。

[hoshi-takanori]

回答ありがとうございます。名前の付け方はちゃんと覚える必要がありますね。指が勝手に動いちゃうので、名前付けガイドラインは何度も見直していきたいと思います。(実は一番抵抗があるポイントだったりしますが、逆らっても仕方がないので、素直に Microsoft に従うことにします。)

Answer 6

IDEの初期設定のまま使っています。
言語が違うとどこで改行するかとは違ってきますが、言語が違うってことで割り切ってます。
別会社と共同での開発となると特に初期設定でないとマージの際に元を崩すことになったりしますので。

Comments

[pepperleaf]

> 別会社と共同での開発となると特に初期設定でないと
外注に出す場合は、コーディングルールも含めて仕様という事で。
Visual Studioの設定も含めて、指示があるべき。(実際にあった)

[KIYOSHI]

初期設定じゃない場合は、そうなりますよね。
案件ごとに切り替えたりしないといけなくなります。

Answer 7

コーディング規約は個人でやる分にはあまりきにしてはいませんね

プロジェクト内でかきかたは併せていますが、
各プロジェクトのルールに従って書くしかないとしかいえませんが、

気を付けていることと言ったらクラスや関数などの名前とか
誰が見てもわかりやすく処理を整理するとかですかね
docsではないですが、なるべくコメントを書くことも心がけてます。
※行数が増えてしまうので気にしないプロジェクトが前提ですが

文字コードと改行コードだけは、統一するようには気を付けていますが
※バージョン管理ツールとかでこれが異なっていると別物と判断されてしまったりするので

最終的には、後々みてわかるようになってればいいなとおもってコーディングしてます。

Answer 8

Visual Studio(C#)を覚えてからAndroid Studio(Java)を覚えましたが、デフォルト設定で使っています。
IDEが勝手に書き換えますので「言語仕様だけでは無く、開発環境やIDEの挙動も含めて全部方言」の認識であんまり気にしていませんでした。
サンプルコードを見てもデフォルト設定が多いですので、IDEに従うのが一般的かと思います。

Comments

[hoshi-takanori]

回答ありがとうございます。やはり IDE のデフォルトが一番ですね。