ローカル変数(employeeCount、firstNameなど)の最初の単語に小文字を使用する理由は何ですか


20

すべての変数に適切な大文字小文字を使用しているため、他のプログラマーから多くの批判を受けています。たとえば、典型的なプログラマーはemployeeCount変数名に使用しEmployeeCountますが、私はを使用します。voidメソッド、returnメソッド、変数、プロパティ、定数など、すべてに適切な大文字小文字を使用します。Javascriptでもこの規則に従います。最後の1つは、人々のジミーを本当に擦ります。

この「非標準」の大文字と小文字の規則に従わない理由として挙げられる典型的な理由は、プロパティとvoidメソッドのために完全な適切なケースを予約する必要があるためです。値を返すローカル変数とメソッドには、のような小文字の最初の単語が必要int employeeCount = getEmployeeCount()です。

しかし、その理由はわかりません。

これに疑問を投げかけると、それが標準あるというarbitrary意的な答えを得るだけのようですです。答えが何であれ、それは通常、次のように常に要約されます。それに従うだけです。。任意の答えは決して私にとって十分ではありません。

Excel 97マクロをOffice IDEでプログラミングした初期の頃から、何かがローカル変数またはプロパティであるかどうかを判断するための大文字と小文字の規則は必要ありませんでした。これは、非常に直感的な命名規則を常に使用してきたためです。たとえば、GetNuggetCount()どこかに移動してすべてのナゲットのカウントを取得する方法を明確に提案しています。 SetNuggetCount(x)ナゲットのカウントに新しい値を割り当てることをお勧めします。 NuggetCountすべて単独で、単に値を保持しているプロパティまたはローカル変数を提案します。最後に、「ああ、それが問題だ。財産か変数か、それはどっち?」と言いたくなるかもしれません。それに対して、「本当に重要なのか?」と返信します。

tl; dr ;:変数または戻りメソッドの最初の単語に小文字を使用する客観的、論理的、非任意の理由は何ですか?

編集: MainMaの場合

このコードを回答の最初のコードサンプルに置き換えて、引数がどの程度維持されるかを確認します。

public void ComputeMetrics()
{
    const int MaxSnapshots = 20;

    var Snapshots = this.LiveMeasurements.IsEnabled ?
        this.GrabSnapshots(MaxSnapshots, this.cache) :
        this.LoadFromMemoryStorage();

    if (!Snapshots.Any())
    {
        this.Report(LogMessage.SnapshotsAreEmpty);
        return;
    }

    var MeasurementCount = Measurements.Count();
    this.Chart.Initialize((count + 1) * 2);

    foreach (var s in Snapshots)
    {
        this.Chart.AppendSnapshot(s);
    }
}

7
それらが大文字の場合、他の誰かがなぜ小文字ではないのかを尋ねるでしょう
...-m3th0dman

11
すべての強力なIDEに、このようなスタイル上の問題に対する独自の個人設定をマッピングし、それらを使用できるようにするプラグインがあり、ソースファイルの「実際のバージョン」で、 「プロジェクト」スタイルのセマンティクス。公式のファイルバージョンを監査する必要があるまで、これは完全に視覚的な問題です。ちょうど夢を見て
...-Sassafras_wot

59
残念ながら、実際の正当な理由は「標準だから」です。同じチーム内の人々が同じコードスタイルの標準に従うことは有益です。理由がわからない場合は、別の質問をする必要があります。「なぜ標準が役立つのか?」
アンドレスF.

3
私は常に、開発者はキャメルケースにこだわっていたので、キャメルケースに落ち着いたと思っていました。PascalCaseの上にcamelCase 自体の「客観的な」理由はありません。個人的にPascalCase(例のように)の方がずっと読みやすく、JavaScript以外のほとんどの場所でそれを使用しています。
GrandmasterB

7
標準コーディングスタイルを持つことの利点の研究標準が何であるかは問題ではなく、標準に従うだけです。
-Mr.Mindor

回答:


88

この命名規則は、変数にその型と同じ名前を付けたい場合によく使用されます。例えば:

Employee employee;

一部の言語では、大文字の使用も強制されます。以下のような迷惑な変数名を使用する必要がこれを防ぎMyEmployeeCurrentEmployeeEmployeeVar何かがちょうど総額から、型や変数の場合などは、いつでも伝えることができます。次のような状況で混乱を防ぎます。

employee.function(); // instance method
Employee.function(); // static method

また、英語では、名詞は一般的に大文字ではないため、大文字が「適切」であると主張することはできません。

それはあなたの状況と何の関係がありますか?明らかに、自分のコードを読むのに問題はありませんが、可能な限り一貫性を保つことにより、コードを読む必要がある他の人の精神的な作業負荷を軽減します。書面のようにコーディングする際には、読者に合わせてスタイルを調整します。


1
プロパティは大文字になっているため、OPで使用される言語にも問題が残っていることに注意してください(もちろん、プロパティの先頭にを付けることができthis.、混乱を避けられます。ローカル変数にはそのようなプレフィックスを付けることはできません)。
アルセニムルゼンコ

1
@oscilatingcretinそれはPascalCaseと呼ばれます。
-Mr.Mindor

21
Employee Employee動作しますが、私はそれが人間の読者にとってより混乱させると主張しますEmployee employee。後者は2つの異なるもののように見えます。最初は不必要な繰り返しのように見えます。
ジェイミーF

14
@oscilatingcretin正確に:「読者が基礎となるフレームワークを理解していると仮定します...」JavaScript、Java、C#、C ++などを読み、頭の中でコードを翻訳するのが好きです。「ああ、この言語のコンパイラはxを扱える」と考え続ける必要はありません。コードの意味を理解しようとしているだけです。
ジェイミーF

1
employee.function()言語がオブジェクトからの静的メソッドの呼び出しを許可している場合は、静的メソッドでもあることに注意してください(Javaのように)。コンパイラーは警告を出しますが、それは許可されています。
うおお

34

ありません。それはほとんどの人が行うことであり、それが標準となっています。多くの文献がこの慣習に従っているので、人々は習慣を取り戻しました。

規則は、コード全体の一貫性ほど重要ではありません。すべてのものが一貫した方法で命名されているので、それらを見ることで何かがわかるようになっていれば、最初の文字が大文字であるかどうかは問題ではありません。

あなたのやり方で書かれたコードに出くわすのは不快で、私はそれが好きではないと言うでしょう。しかし、それはスタイルの問題です。

職場でこれを行っている場合、コードがどこでも一貫性を保つように、チームのスタイルでコーディングする方が良いでしょう。コードを他の人とは異なるものにするのではなく。

http://thecodelesscode.com/case/9​​4


3
ほとんどのプログラマーがあなたのようであったらいいのですが。多くの人は、私が言及したケーシング標準に従うことに情熱的および/または独断的です。
振動クレチン

1
@Schieisあなたがプロジェクトに取り組む次のプログラマであるかどうかは重要です。
N4TKD

3
@oscilatingcretinでいっぱいのコードに取り組んだら、最終的に情熱的で独断的になるかもしれませんvar m_someVariableID = GetVariableValueId()。特に、オートコンプリートをサポートせずに実行する必要がある場合。
タクロイ

7
チームに所属している場合、そのチームの標準に従うことが重要です。ただし、多くのプログラミング言語には、チームが標準を持たない(またはチームがそれらを設定するように延期している)新しいプロジェクトを作成するときに、従うべき事実上の標準があります。使用するコーディング規則がわからない場合は、標準を正当化できない限り、主要言語ベンダーまたは付属のフレームワークで使用されている規則に従うことが、独自の標準よりも望ましいです。
ブライアン

2
@Schleisの良い更新、それは単なるスタイルの問題であることに同意しませんが、慣習と慣習は正当な理由で慣習になり、従わなければなりません。それは宗教ではなく、いつの間にか慣習から非常に離れなければなりませんが、正当な理由があるはずです。
N4TKD

25

1.標準が存在する理由

結局のところ、個人の好みに応じて全員にコードを記述させ、どちらの標準が優れているかについて話すのをやめる方が良いと思いませんか?

実際、あるスタイルに慣れていると、別のスタイルを使用するコードを読むのが難しくなります。あなたの脳は、コードが何をするのかを理解するのではなく、(もしあれば)慣習を理解しようとしてより多くの時間を費やします。

これらの2つのコードの間で読みやすいものは何ですか?

public void comp_metrics ()
{
  int Count;
  List<snapshot> measurements=fromMemoryStorage();
  if (_liveMeasurements.enabled)
    measurements = GrabSnapshots(20, _cache);
    if( !measurements.Any() ) {
        this.Report(LogMessage.Measurements_Are_Empty); return;
    }

    Count = measurements.Count ();

    this.Chart.initialize(( Count + 1 )*2);

    foreach(snapshot S in measurements) {
      this.Chart.append_Snapshot ( S );
    }
}

または:

public void ComputeMetrics()
{
    const int MaxSnapshots = 20;

    var snapshots = this.liveMeasurements.isEnabled ?
        this.GrabSnapshots(MaxSnapshots, this.cache) :
        this.LoadFromMemoryStorage();

    if (!snapshots.Any())
    {
        this.Report(LogMessage.SnapshotsAreEmpty);
        return;
    }

    var count = measurements.Count();
    this.Chart.Initialize((count + 1) * 2);

    foreach (var s in snapshots)
    {
        this.Chart.AppendSnapshot(s);
    }
}

両方のコードは同様に実行されます。唯一の違いは、最初のケースでは、プロジェクトに取り組んだ各開発者が独自のスタイルを使用したことです。これにより、コードは一貫性がなくなり、判読できず、危険になりました。チームのメンバーがインデントのサイズについて同意できなかったという事実とif、コードのエラーが発生しやすくなった後、中の1人が中括弧の使用を拒否したという事実と相まって、それを見て、2つ目ifは最初の場合にのみ実行されifますが、そうではありません。

2番目のケースでは、すべての開発者が同じ標準に従いました。それらのいくつかは、2つのスペースのインデントを好むか、小さな文字で始まるメソッドに慣れているため、不幸かもしれません。実際のところ、コードはこの方法ではるかに読みやすく、異なる標準を使用している場合でもコードは読みやすくなります。

厳格で統一された標準を持つことにより、コードが読みやすくなります。

2.なぜ彼らの標準はが今発明したものよりも優れているのですか?

世界中の何十万人もの開発者が標準を使用している場合は、そのままにしてください。自分で発明しないでください。たとえそれがより良いとしても、数十万人の開発者があなたのものを使い始めるよりも、グローバル標準に移行する方が簡単です。

例:私の会社では、データベースの主キーと外部キーおよびインデックスに名前を付けるための特定の規則があります。それらの名前は次のようになります。

  • [FK for Application: CreatedByApplicationId]
  • [IX for SessionIPAddress: SessionId] または
  • [PK for RoleOfPassword: RoleId, PasswordId]

個人的には、この規則は非常に優れており、非常に明確だと思います。私のために。しかし、それは完全に最悪です。それは私のものだし、何千人ものデータベース管理者の誰もそれを使ったことがないからだ。この意味は:

  • DBAを雇うと、彼はすぐに仕事を始めるのではなく、新しい慣習を学ぶことを余儀なくされます。

  • インターネット上でコードの一部をそのまま共有することはできません。これらの奇妙に見える名前は、私のコードを読む人を混乱させ、

  • 自分で使用するために外部からコードを取得した場合、統一するために名前を変更する必要があり、

  • ある日、よく知られた標準を使用することに決めた場合、数百の名前すべてを変更する必要があります。

3.では、大文字化はどうですか?

プロパティは、フィールドまたはローカル変数よりも大きなスコープまたは可視性を持ちます。プロパティの作成は大文字で始まり、フィールドと変数-小さなものはこの方向に進みます。

C#を検討する場合、このロジックは十分に一貫しています。

Javaを検討する場合、メソッドは小さな文字で始まりますが、これはロジックに従っていません。

だから、この規則があなたのものより良いという決定的な証拠はありません。それはグローバルに使用されるものであり、あなたのものではありません。どれも優れていません。

JavaScriptでは、new前に必要な場合を除き、関数は小文字で始まります。他の方が良いと思いませんか?多分。実際、JavaScript開発者は長年にわたってこの標準を使用しており、その反対ではありませんでした。すべての本を書き直し、すべての開発者にスタイルの変更を強制することは、少し複雑になります。


1
コードが少し異なる標準に準拠しているため、コードが読みにくくなる部分については、私はその問題に遭遇したことがありません。誰かの変数にのような名前が付けられていない限りhookyDookyDoo、命名規則や大文字小文字の区別は読みやすさを損ないません。また、devテーブルに本当に特別なものをもたらすわけではないので、私の慣習は「より良い」と言っているわけではないことに注意してください。最後に、[プロパティのスコープが広い...この方向に進む]のあなたのポイントがわかりません。スコープは、大文字と小文字の区別と何の関係がありますか?どの方向に行きますか?
振動クレチン

23
@oscilatingcretin、問題はあなたがその問題を抱えたことがあるかどうかではなく、同僚が持っているかどうかです。明らかに彼らは持っている、または彼らは文句を言っていないだろう。
カールビーレフェルト

1
再:あなたの編集:あなたの最初のコード例は、単純に構築が不十分で、災害を起こしやすいコードを示しています。私のOPは、構築が不十分で災害が発生しやすいコードに関するものではありません。2番目の例とまったく同じコードですが、大文字と小文字の表記規則が異なります。2番目のコード例を編集し、大文字と小文字の規則に従ってOPに投稿しました。それを最初のコード例に置き換えてください。
振動クレチン

5
@oscilatingcretin:最初のコード例は、不完全に構築されたコードではなく、すべての開発者が独自のスタイルに従ったチームによって記述されたコードを示しています。これは、十分な時間(5年など)が与えられたコードベースが多すぎる場合に発生します。注:「実際には、コードはこの方法ではるかに読みやすく、異なる標準を使用している場合でもそうです。」
アルセニムルゼンコ

6
@oscilatingcretin一貫性があなたが読んでいる何かを理解するのに必要な認知的努力を著しく減少させることを示す多くの研究があります。定期的な散文、綴りの悪さ、句読点の不備、お粗末な文法などはすべて、誰かがそれを意識的に気づいているかどうかにかかわらず、読むのを難しくしています。コードは難しくせずに読むのに十分なほど困難です-「選択した技術スタックの」「共通の標準」を順守することで全体の一貫性が高まり、ニューロンが解放されてコードの動作の重要なビジネスに集中できますそれは書かれている。
ベヴァン

10

技術的には、問題ではありません(少なくとも、ほとんどの言語では問題ありません)。

ただし、ほとんどのプログラミングコミュニティ(特定の言語を中心に形成された世界規模のコミュニティ、そのようなコミュニティのサブグループ、人気のあるライブラリやツールキットを中心に形成されたグループ、または個々のチーム)は、確立されたコーディング標準を開発しています。正確な詳細は、(多くの場合、良い引数は彼らのために行うことができるが)比較的重要でない、何重要なことは、あなたがそれらに固執するということです。

彼らが最高だからではなく、彼らが誰もが使用しているからです。標準に固執する場合、最終的に使用する他のほとんどのコード(ライブラリ、チームメイトのコード、組み込み言語)とコードの一貫性が保たれます。一貫性のある命名は、生産性の強力な武器の1つです。これは、何かの名前を推測すると、通常は正しく推測できることを意味するためです。それはfile.SaveTo()File.saveTo()file.save_to()FILE.save_to()?命名規則からわかります。

第一に、すべての言語には独自の文化があり、命名規則はしばしば互換性がないため、遭遇するすべての言語に個人的な好みを持ち込むことは特に危険です。第二に、命名に関する限り、言語間に多くの微妙な違いがあります。

ほんの一例です。C#では、型と変数は別々の名前空間に存在します。コンパイラーは、違いを知るのに十分なほど賢いです。ただし、Cでは、両方の種類の名前が名前空間を共有するため、同じスコープ内に同じ名前の型と変数を含めることはできません。このため、Cでは型と変数を区別する命名規則が必要ですが、C#では必要ありません。


したがって、一部の古い言語は、将来の言語のコーディング標準(C / C#の例など)への道を開いたようです。変数とオブジェクトメンバーの大文字小文字の区別を追跡する必要があるため、不必要なレベルの複雑さが追加されるため、それは最も残念なことです。
振動クレチン

4
@oscilatingcretin全員が同じ規則を使用する場合、継続的な複雑さは追加されず、規則は問題の言語のメンタルモデルの一部となり、その言語の使用を容易にします。これは実証可能であり、測定可能です。
-Mr.Mindor

賛成票を投じるつもりでしたが、最初はそれは重要ではないと言ってから、なぜそれが重要なのかを説明するいくつかの段落を書きます。最初に「問題ではない」を削除すると、私はあなたに投票します。
Tulainsコルドバ

10

私は誰もこれを言っていないことに驚いていますが、大文字の違いは1つの理由で驚くほど役立つと思います:変数がローカルスコープのみであるかどうかを知ることができて便利です。変数がローカルである場合、名前のリファクタリングなど、変数を変更する副作用についてはあまり心配しません。したがって、クラスメンバーとプライベートクラス変数とローカル変数を区別する規則が好きです。

最新のIntelliSenseでは、これは重要性を失いますが、コードを読んで定義を見つけるためにどこを探すべきかを知る際のランドマークを与えてくれます。

そして、メソッドが1つの画面に収まらない可能性があった数年前の私の悪いスタイルから、これのかなりの部分が残っているかもしれません。


私が取り組んだ多くのプロジェクトでは、スタイルガイドでこのようなものを指定しています。
アナキシマンダー

7

これは、特定の規約というよりも規約の問題のようです。

あなたが破るすべての慣習に対して、あなたは他の皆のためにより多くの仕事を追加しているだけです。おそらく完璧な世界では、会社全体が生涯にわたって単一の製品で作業していますが、実際には、これは真実ではありません。人々はプロジェクト間をジャンプし、時には企業間で、あるいは楽しみのためにジャンプします。コードがランダムであるほど、作業が難しくなり、費用がかかります。事業主または利害関係者として、プロジェクトの利益のためではなく、利己的に考える開発者を雇いたくありません。

これはプロフェッショナリズムに帰着します。時々、私たちの個人的なスタイルを脇に置いて、大量採用のためにより効率的なものを選ぶ必要があります。これにより、コラボレーションが促進され、そもそも存在しないはずの無関係な障壁が取り除かれます。

実際の慣習として、CapitalCamelCaseは通常クラス名(またはJavascriptではコンストラクター)のために予約されています。大文字の変数が表示された場合、経験に基づいた推測により、使用するためにインスタンス化する必要があります。それが間違っている場合、コードがコミュニティの標準に従っていないことに腹を立てます。他のほとんどの言語でさえ、初めてそれを見る他の誰もが即座に誤解されています。コードは誤解を招くものではなく、明らかにする必要があります。


「大文字の変数が表示される場合、経験に基づいた推測により、使用するためにインスタンス化する必要があります。」わかりません。大文字の変数を見ると、使用する前にインスタンス化する必要があると思いますか?クラス名に見えるから?だから、違いを知らないMyClass MyClass = nullclass MyClass { }
振動クレチン

3
はい、違いがわかります。あいまいさを防ぐための規則が存在します。var car = new Car();私の最後の行ごとに-なぜそれを明らかにしないのですか?
エイドリアンシュナイダー

3
@oscilatingcretinもちろん違いがあります。しかし、人間の脳は、コンピューターパーサーが必要としない視覚的な合図から恩恵を受けます。慣習/標準の必要性を疑問視しているように見えます...これは、最初に求めたものと異なる質問であれば、有効です。
アンドレスF.

2

「プロパティとvoidメソッドには完全な大文字と小文字を予約する必要があります。ローカル変数と値を返すメソッドには、最初の単語を小文字にする必要があります」と標準の規則です。

他のプログラマーはあなたのコードを今すぐ引き出しており、これはプロパティであり、実際にはローカル変数であると考えており、仕事を難しくしています。


1
私の質問を全部読みましたか?私が言った最後に目を向けてくださいNuggetCount all by itself suggests a property or local variable that is simply holding a value. To that last one, one may be tempted to say, "Ah ha! That is the question. Property or variable? WHICH IS IT?" To that, I'd reply with, "Does it really matter?"
。–振動クレチン

8
はい、はい、それは重要です。次のプログラマはNuggetCountを考える必要はないはずです。名前を見て伝えることができるはずです。読むのに適した本は、ストーリーのようにコードを読み、何が起こっているのかを知ることができる「クリーンコード」です。
N4TKD

2
@oscilatingcretinあなたが質問しているのとは少し異なる質問に答えている人々に見られる不満は、受け入れられた慣習を破ったときに生成される混乱の証拠だと思います。
-Mr.Mindor

7
規則には意味があります。慣例に従ってNuggetCountがプロパティを意味する場合、それはローカル変数が持つ範囲を超えるスコープを持つことを意味します。つまり、その範囲を判断するには、さらに調査する必要があります。決定する必要があります:変更するための副作用はありますか?使用中に別のスレッドによってその値が変更されないことを信頼できますか?nuggetCountはローカルスコープを意味し、その全体がローカルであると想定できるはずです。
-Mr.Mindor

5
@oscilatingcretinはい!まさに!私は、彼らが書いたものが慣習に従っており、それに付随するすべてのものを運ぶと信じていました。彼らがチームの一員として働いていると信じていたので、その慣習を使用するメリットを享受することができました(nuggetCountが一目でわかる)。 、そして次回は信頼しないことでフォローする必要があります。規約に従わないことにより、彼らは読みにくく保守しにくいコードを生成しました。コンベンションに背負いたい理由はありますか?
-Mr.Mindor

0

他の人が本当の理由を言っていないように、名前付け規則を軽くすることを除いて。チーム全体を同じページにまとめることができれば、おそらく時間を節約できます。例えば、個人的にはコーディング標準を始めました。これはすべてのプライベート変数とValで渡されたものにcamelCaseを使用しましたが、公開されたものとRefで渡されたものにはPascalCaseを使用しました。

保護されている、Out、または何かのようなものを扱うとき、線は少しぼやけます。


-2

言語(その正式な側面と従来の)は、あなたの思考を整理するために重要であり、あなたの考え方を支配する力を持っています。そのため、あるスタイルから別のスタイルに移行するのは苦痛です。

小文字のシンボルと大文字のシンボルは、Haskellで大きな意味の違いがあり、Scalaでもわずかに異なります。私は両方とも使用しました。私が使用する他の言語では、この2種類の識別子に違いはありませんが、Haskellが識別子を認識する方法を考えておくと、異なる言語で頭を断片化するよりもはるかに簡単になります。


-2

私にとっては期待にかかっています。

ほとんどのコードを読むと、 lowerCaseローカル変数または関数(C#では変数になります)になることを期待しています。にローカル変数ProperCaseが表示された場合、クラス名またはプロパティまたは他の何かであると考えて、つまずき、しばらく混乱する可能性があります。それは私にコードを再読させ、私を悩ますでしょう。

それはおそらくあなたのケースで起こっていることです。

さらに、最初の文字を見るだけで変数がどのような役割を果たしているかを知ることができ、インスタンス名とクラス名の衝突を回避できます。


-3

入力しやすいように、ローカル変数には小文字を使用する必要があります(速度/シフトキーなし)。大文字は、名前内の単語を区切って読みやすくするために使用されます。シングルワードのローカル変数名(これは一般的であるはずです)を含むコードは、高速で簡単に入力できます。名前の新しい単語ごとに大文字を使用することは、別の文字を追加するアンダースコアを使用するよりも高速です(スペースが少なくなります)。これはキャメルケースとも呼ばれます。


これは非常に良い答えだと思いますが、私はダウン票を理解していません。これは論理的な答えです-OPから要求された事実に基づいています。反対票を投じる場合は、自分自身を説明してください。シフトキーはあちこちで押すのが大変です。考えてみてください。コードに入力するほとんどすべての単語がPascalCaseを開始し、それぞれに対して別のShiftキーを押す必要があります。ミニマリストで効果的になりたい場合は、不要なシフトキーを押す必要はありません。そして論理的に言えば、あなたはより生産的になりたいと思うでしょう。それは、私が立っている場所から、より少ないキーを押すことを意味します。なぜもっと押す?
AIon

-3

ここのOPに同意します。camelCaseは間違っているように見えます。また、それが標準であり、同じ標準に固執しなければならないという事実、または標準を持つことのポイントに同意します。また、PascalCapsをメソッドなどに使用し、キャメルケースを独自の変数などに使用して、メソッドを色付けするIDEを使用しない場合に差別化することもできます。

それを回避するために、私は常にオブジェクトの名前の前にオブジェクトのタイプを付けます。したがって、文字列変数の場合、strMyVariableを呼び出します。何らかのオブジェクトである場合、objMyObjectなどと呼びます。そのように、標準に従って小さな大文字で始まり、正しく見えます。


3
これは作られたポイントを超える大幅な提供の何にも思えるし、前に11件の答えで説明していません
ブヨ
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.