C# 命名規則についての質問

Question

C#の命名規約に関して、ざっくりいうと
privateなフィールド等はCamel方式、
publicなフィールド等はPascal方式
だと認識しています。

現在「圧力」を扱うクラスを作成していまして、
圧力単位はいろいろありますが例えば

• ヘクトパスカル：hPa
• バール：bar
• 水銀ミリメートル：mmHg
• 重量ポンド毎平方インチ:psi

などがあります。

これらをプロパティにしたい場合に、
命名規約に従って書くと下記のようになりますが、なんか気持ちが悪い。。。

public class Pressure
{
    private double hPa = 0.0;
    public double HPa
    {
        get { return hPa; }
        set { hPa = value; }
    }

    private double bar = 0.0;
    public double Bar
    {
        get { return bar; }
        set { bar = value; }
    }

    以下略

}

こういったケースは圧力の単位に限らず、長さや重さでも出てくると思うのですが、
皆さんはどういった風に書かれているのでしょうか？

###追記
C#勉強始めた頃に読んだ命名規則では、privateはCamel、publicはPascalとあったので、
今までそれに従っていたのですが、リンク切れで見れなくなっています。(pdfでは持ってますが)

改めて公式の方を見てみたのですが、
privateに関しては特に何も書いてない感じですね(まだ軽くしか見れてませんが)

チームのルールが無い(もしくは自分でルールを作る立場)場合に、
みなさんなら今回のような時どのようなルールを設けるかを知りたいです。

Answer 1

命名規約に従って書くと下記のようになりますが、なんか気持ちが悪い。。。

組織・チームで開発している場合は組織・チームで命名ルールを決めておいて、個人が気持ち悪かろうと何だろうとそれに従う。質問者さん個人で開発していて他の人が保守なども行うことがなければ、質問者さんが気持ち悪くない命名にすればいいと思いますが。

ただ、日本語を使うのは、思わぬ副作用があるかもしれないので、よく考えた方がいいと思います。

Comments

[lain]

日本語を使用するのは、私も嫌なので使うことは無いです。
もちろんチーム開発のルールがある場合はそれに従います。

今回は個人作成になります。
今までなら質問のところに書いたような
コードを(気持ち悪いと思いながらも)使用しているのですが、
ふと「他の人はどういった書き方をするのだろう？」と思い質問させていただきました。

参考までにSurferOnWww様が今回のような場合、どういった名前を使用されますか？

[退会済みユーザー]

そうするともう完全に個人の好みの問題ということだと思うのですが。私の個人的な好みを聞いても、それを質問者さんが気持ち悪いと思えば意味がないのでは？　それをあえて聞かせろということですと、フィールド名の最初の文字は小文字、プロパティ名の最初の文字は大文字、即ち、質問者さんが質問にアップされていたような書き方を、いつもの通りあまり深く考えずにするかなぁ・・・という感じです。

[lain]

今回のようなことは宗教論争的なことであるとは思っています。。。

このケースで質問で書いた方式か、
ozwk様が書かれているようなフルネームで書くかぐらいしか思いつかなかったので、
（長さのメートルや重さのグラムを考えた時に「m」「g」のような一文字の場合は
「metre」「gram」の方が分かりやすいかな？と思ってみたり）
私が思いつかなかったアイデアがあるのかな？と思い投稿させてもらいました。

Answer 2

Pressure.HectoPascal(DateTimeに倣った感じ)とか
Pressure.AsHectoPascal(なんかかっこいい)とか
Pressure.hPa(単位ぐらいは大目に見る)とか。

いっそF#に乗り換えてfloat<hPa>とか

Comments

[lain]

「HectoPascal」のように省略せずにフルネームで書くのも考えたのですが、
「bar」が何の略なのか？(調べきれてません)

「hPa」にした場合はprivateのhPaをどうするか？という事になってしまいます。

F#はいじった事ないです。。。汗

[ozwk]

barはそのまんまbarです(inchと同じノリ)
単位の名称がbarで記号がbarです。

[lain]

調べてみたのですが、どうもbarはbarみたいですね。
「kgf/cm2」(キログラム・フォース・パー・平方センチメートル)というのもありまして
そのままではパーや平方メートルが表記できませんので、
この場合はフルネームで「kilogramForceParSquareCentimeter」ですかね？

深く考えずに適材適所で名前付してコメントで分かるようするのが、良いのかもしれませんね。

Answer 3

C# はやっていませんが。

違和感があるのであれば、

set/get をつけてみては?

たとえば、

int hPa を操作するのは、

int gethPa();
void gethPa( int hPa );

のように。

趣味で自分だけで作るならコーディング規則 ( 命名規則の方 ) は守らなくてもいいです。
ただ、仕事でやる場合は守らないといけませんが。

私が指定する立場なら、

フィールドは 基本的に 小文字から ( Camel方式 )、
フィールド操作 ( get/set にあたる ) は、get + フィールド名 / set + フィールド名

のようにしますね。

的外れだったらすみません。

Answer 4

僕の場合は、各重さ毎に別々のクラスにするか、enumで区切ってしまいます。
色々妥協案を考えた結果、他の規約を破りたくないので、enumだけ小文字から始めるのオッケー、みたいに考えてます。
enumだと他の機能を持てないというところがなんか良いんですよね。
それはプロパティなのか、変数なのか、publicなのか、privateなのか、そんな悩みとは外にあるので。

enum PressureUnit
{
    hPa,
    bar,
    mmHg,
    psi
}

public class Pressure
{
    public Pressure(decimal value, PressureUnit unit);
    public decimal To(PressureUnit unit);
}

あと、変数の内部は常に1種類の単位で持っておく方が僕は好みです。
一つの文脈に複数の状態が混在するのを忌避するからですが。
このため、質問の回答とはちょっとズレます。
なんていうか、プロパティとして直接hPaとかが実装される、ようなことは避ける、というのが回答でしょうか。

他の回答を見るに、mmHgをデフォルトにしたい…のかなと思いますので、それをベースに回答します。
mmHg用のクラスを1個作成して、各値からコンバートできるパブリックコンストラクタと、変換用の関数を作ります。
全部の値を生の値で保持したい場合でも変数をいくつも一つのクラスで持つのはオススメしがたいです。

public struct MmHg
{
    private readonly decimal value;
    public MmHg(decimal value, PressureUnit unit)
    {
         // それぞれのケースでmmHg化する
         switch(unit)
         {
             case PressureUnit.hPa:
                // ...
             case PressureUnit.bar:
                // so on...
         }
    }

    public decimal To(PressureUnit unit)
    {
        // mmHgから変換する方法だけをそれぞれ実装する
    }

    // 直接プロパティ, 又はメソッド呼び出す形式にしたければ内部的にToメソッドを呼び出す
    // ただし、UIのあるアプリケーションで、各単位に変更可能、なんてのを作りたければToメソッドのが便利。
    // HectoPascalが省略形じゃなくて、Psiが省略形なのは、Psiが省略形で一般的だと思えるから
    public decimal AsHectoPascal { get { return To(PressureUnit.hPa; } }
    public decimal AsBar { get { return To(PressureUnit.bar; } }
    public decimal AsPsi { get { return To(PressureUnit.psi; } }
}

面倒じゃなければ残りの３つもクラスにします。
その場合はパブリックコンストラクタもAsメソッド群もつくらず、お互いにキャスト可能にします。
変換関数のパターンがクラス数分増えてしまいますが、それを簡易化する場合は一度全部統一単位に変換するようにすると簡単です。
※変換関数に誤差が含まれる場合は繰り返すほど誤差が大きくなるので注意が必要です。

public struct HectoPascal;
public struct Bar;
public struct Psi;

// 圧力という文脈にしてしまいたい場合は以下のような感じで改めてぼかす。。。
// Box化が微妙なんだけど仕方ない。。。
public struct Pressure
{
    private readonly object value;
    public Pressure(HectoPascal value) { this.value = value; }
    public Pressure(MmHg value)  { this.value = value; }
    public Pressure(Bar value)  { this.value = value; }
    public Pressure(Psi value)  { this.value = value; }

    public HectoPascal AsHectoPascal { get { return (HectoPascal)value; } }
    public MmHg AsMmHg { get { return (MmHg)value; } }
    public Bar AsBar { get { return (Bar)value; } }
    public Psi AsPsi { get { return (Psi)value; } }
}

mmHgだけは悩みます…単位をそのままクラスにするなら問答無用でMmHgです。（規約を破りたくないので。）
もしくは、元の名前を使います。Millimeter of mercuryなんで、MillimeterOfMercuryですかね。

Answer 5

「圧力」そのものをクラスにしたことがないですね。
なので単位をプロパティ名にするのではなく、
「圧力」や「重さ」などの名前をプロパティ名にしたことがあります。
例えば SurfacePressure とか TotalWeight などになります。

「圧力」や「重さ」など対象が変わると単位名も変わってしまうので、
その値を示すためのプロパティ名は Value とでもしておいたほうがいいと思います。
そうすれば使う側もいちいち単位名を考える必要がなくなります。

Comments

[lain]

質問のコードでは省略してるのですが、
このクラスの機能を一つとして、単位の相互換算を考えています。
なので、それぞれの単位のプロパティは持っておきたいのです。

[twyujiro15]

そういう状況なら、自分なら単位名をそのままプロパティ名にするかなぁ。
ちなみに Value_mmHg というようにアンダースコアを入れる手もあります。
こうするとコーディングするときに ".Value" と入力すると
その他の単位の Value_xxx というプロパティが Intellisense で全部表示されるようになります。
結局 SurferOnWww さんが書かれている通り、
個人開発であれば自分が納得できればそれでいいと思います。

[lain]

Pressureクラスを使う側からみると一番自然なのが「mmHg」ですよね。

Pressureクラスを作る側からした時に
publicをｍｍHgにした時にprivateのｍｍHgの名前をどうするか？
ということと
「先頭文字が小文字だしprivateだよね」と条件反射的に考えてしまわないですかね？
(そういった事が起こるくらい大きなクラスにする事自体が設計ミスだとは思うのですが)

[twyujiro15]

自動変数の名前と一緒になる場合に対応できないので、
私は private 変数の名前をアンダースコアから始めるようにしています。

private int _value;

public int Value { get; set; }

private void Hoge(int value)
{
}

後、何度も言いますが、自分が納得できればそれでいいと思います。
そのソースは自分しか見ないんだし。
自分が条件反射的に private 変数と見間違えてしまうのであれば
名付け方を変えたほうがいいと思います。

[lain]

確かに今回の場合は自分で決めた規則で書けばいいのですが、
チーム開発になった時(コーディング ルール作りも含む)の後学のために質問させてもらいました。

確かにアンダースコアを使うのは視認性がよくなりますね。
参考にさせていただきます。