クラスドキュメント @ wiki

良く使う対義語集

2017-10-31T16:16:53+09:00

良く使う対義語集

良く使う対義語をまとめます。

単語	対義語	備考
attach	detach	-
begin	end	-
connect	disconnect	-
enable	disable	-
import	export	-
inflate	deflate	-
initialize	finalize	-
load	save	-
next	previous	-
open	close	-
pause	resume	-
read	write	-
start	stop	start/endとする場合もある（線分の始終点はStartPoint、EndPointと表しても違和感がない）。

良く使う英単語集

2017-07-20T18:13:30+09:00

良く使う英単語集

良く使う英単語をまとめます。

単語	意味	備考
accumulate	累積する、積算する。	-
add	追加する、加える。	-
align	調整する、整列する。	-
allocate	割り当てる、確保する。	-
append	末尾に追加する。	-
attach	関連付ける、結び付ける。	-
build	構築する。	-
compute	計算する。	似た意味のcalculateは使用せず、こちらで統一する。
create	作成する。	-
delete	削除する。	-
detach	切り離す。	-
disable	無効にする。	-
enable	有効にする。	-
export	書き出す。	形式を変換してファイルに保存する場合など。
extract	抽出する、抜き出す。	-
find	見つける、見つけ出す、探し出す。	見つかることが前提。
ignore	無視する。	-
import	読み込む。	ファイルを対応形式に変換して読み込む場合など。
initialize	初期化する。	-
insert	（任意の位置に）挿入する。	-
load	読み込む。	ファイル全体を読み込む場合など。
make	作る。	buildよりも小さいものを作る。
marge	結合する、合成する。	-
normalize	正規化する、標準化する。	-
remove	取り除く。	-
save	保存する。	ファイル全体を保存する場合など。
search	探す、検索する。	見つからない場合もありうる。
swap	入れ替える。	-
update	更新する。	-
validate	検証する。	決められたフォーマットやルールに従っているか確かめる。

スペース

2017-07-18T15:04:35+09:00

スペース

✓スペースのレイアウトは、下記のオプション設定に従おう。
ツール＞オプション＞テキストエディター＞C#＞書式設定＞スペース

メソッド宣言のスペース

✖メソッド名と始めかっこの間にスペースを挿入しない

✖ パラメーターリストのかっこ内にスペースを挿入しない

✖ 空のパラメーターリストのかっこ内にスペースを挿入しない

int Method()
{
return 3;
}

int Method(int input)
{
return input;
}

int Display()
{
myLabel.Show();
}

メソッドの呼び出しのスペース

✖ メソッド名と始めかっこの間にスペースを挿入しない

✖ 数リストのかっこ内にスペースを挿入しない

✖ 空の引数リストのかっこ内にスペースを挿入しない

int Method()
{
Console.WriteLine("In Method");
return 3;
}

int Display()
{
myLabel.Show();
}

その他のスペース

✓ 制御フローステートメント内のキーワードの後にスペースを挿入する

✖ 式のカッコ内にスペースを挿入しない

✖ 型キャストのかっこ内にスペースを挿入しない

✖ 制御フローステートメントのかっこ内にスペースを挿入しない

✖ キャストの後にスペースを追加しない

✖ 宣言ステートメント内のスペースを無視しない

int Method()
{
    if (a > b)
        return 0;
    return 3;
}

double Function(double a,double b)
{
return a * (b - a);
}

int First(ArrayList list)
{
int number = (int)list[0];
return number;
}

ArrayList names = new ArrayList();
names.Add("John");
string name = (string)names[0];

class MyClass
{
int index = 0;
string text = "Start";

   voidMethod()
    {
       int i = 0;
       string s = "Hello";
    }
}

大かっこのスペース

✖ 始め角かっこの前にスペースを挿入しない

✖ 空の角かっこ内にスぺースを挿入しない

✖ 角かっこ内にスペースを挿入しない

int Main(string[] args)
{
return 0;
}

int First(ArrayList list)
{
return list[0];
}

区切り記号のスペース

✓ 型宣言で、基本またはインターフェイス用のコロンの後にスペースを配置する

✓ コンマの後にスペースを追加する

✖ ピリオドの後にスペースを追加しない

✓ "for"ステートメントでセミコロンの後にスペースを挿入する

✓ 型宣言で、基本またはインターフェイス用のコロンの前にスペースを挿入する

✖ コンマの前にスペースを挿入しない

✖ ピリオドの前にスペースを挿入しない

✖ "for"ステートメントの前にスペースを挿入しない

class MyClass : IDisposable
{
// ...
}

int Sum(int a,int b)
{
return a + b;
}

System.Collections.ArrayList Method()
{
return new System.Collections.ArrayList();
}

int Method()
{
for (int i = 0; i < 10; ++i)
OtherMethod();
}

演算子のスペース

✓ バイナリ演算子の前後にスペースを挿入する

✖ バイナリ演算子の前後のスペースを無視しない

✖ バイナリ演算子の前後のスペースを削除しない

void Method()
{
int result = 1 + 2 * 3;
}

ステートメント

2017-06-25T22:19:44+09:00

ステートメント

このセクションでは、プログラムの個々のステートメントを改良する方法をいくつか説明する。

ステートメントの長さ

1 行の長さを80文字に制限するという、やや時代遅れの一般的な規則がある。
これには次のような理由がある。

あまりに長い行は読みにくい。
1行の文字数を制限することにより、深いネストを阻止する。

ディスプレイの解像度が上がったことにより、ステートメントの長さの制限は以前ほど重要ではなくなっている。
最近の環境では、100文字程度のステートメントであれば問題はないだろう。
しかし、ステートメントがあまりに長くなる場合、コードに問題がある可能性がある。リファクタリングできないか検討してみよう。

継続行のフォーマット

プログラムのレイアウトにおいて最も悩ましい問題の1つは、ステートメントの一部が次の行にはみ出したらどうするかを決めることである。
はみ出した部分に通常のインデントを使用するのか、それともキーワードの下に揃えるのか、代入の場合はどうするのか。
ここでは、実用的で一貫性のある方法を紹介しよう。

ステートメントが完結していないことを明確に示す。
ステートメントを複数の行に分割しなければならないことがある。

その場合は、最初の行にあるステートメントが、ステートメントの一部のみであることを明確に示す。
最も簡単な方法は、最初の行が単体では構文的に成立しないことが明白になるようにステートメントを分割することである。
リスト 31-37 に、レイアウトをいくつか示す。

ステートメントをこのように分割すると、ステートメントが最初の行で完結していないことが読み手にわかるだけでなく、修正ミスを防ぐのにも役立つ。
ステートメントの続きが削除された場合、最初の行は単にかっこ（( )）やセミコロン（;）を忘れただけには見えないだろう。
そうではない何かが足りないことは明らかである。
もう 1 つ効果的な方法がある。リスト 31-38 に示すように、継続行の先頭に継続文字を置く方法である。
このスタイルでは、行頭に&& や + を付けて構文エラーを防いでいると同時に、演算子をでこぼこした右端ではなく整列されている左端に置くことで、演算子が読みやすくなる。
リスト 31-39 に示すように、処理の構造が解明されるという利点もある。

メンバーの名前

2017-06-25T16:51:58+09:00

メンバー（プロパティ、フィールド、メソッド、イベント）の名前

型はメンバーによって作られる。メンバーとは、コンストラクター、ファイナライザー、プロパティ、フィールド、メソッド、およびイベントのことだ。
このうちコンストラクタ―とファイナライザーの名前は型名から一意に決まる。このセクションでは、残りのメンバーの名前付けのガイドラインを説明する。

プロパティの名前

✓ プロパティの名前は名詞にしよう。

✓ プロパティ名には PascalCase を使おう。

✖ 次の例のように「Getー」メソッドの名前に一致するプロパティ名を使用してはならない。

public string TextWriter { get {...} set {...} }
public string GetTextWriter(int value) { ... }

通常このようなケースは、プロパティをメソッドに変更するべき状況であることを示している。

✓ コレクションのプロパティの名前には、コレクション内の項目の複数形の語句を使おう。
項目の単数形の語句に「ーList」または「－Collection」などの接尾辞を付ける名前を使用してはならない。

✓ ブール型のプロパティの名前は肯定的なフレーズにする。CantSeek の代わりに CanSeek としよう。
そうすることが適切である場合、ブール型のプロパティに接頭辞「Isー」、「Canー」、「Hasー」を付けても良い。

✓ プロパティの型と同じ名前を付けることを検討してみよう。

たとえば、次の例のプロパティは Color という名前の列挙型で Control の Color の取得および設定をおこなう。
このような場合、Colorというプロパティ名は適切だ。

public enum Color {...}
public class Control
{
public Color Color { get {...} set {...} }
}

フィールドの名前

フィールドの名前付けのマイクロソフト公式ガイドラインは、public または protected の静的フィールドに適用される。
public または protected のインスタンスフィールドは使用を禁止されている。
internal または private のインスタンスフィールドには、マイクロソフト公式ガイドラインは対応していない。

✓ フィールドは「プロパティバッキングストア」と「依存関係プロパティ」のみに使用を制限しよう。
また、この目的でフィールドを使用する場合、private の静的・インスタンスフィールドにしよう。

✓ プロパティバッキングストアとして使用するフィールドの名前はプロパティ名に接尾語「_（アンダースコア）」を追加する。

✓ 依存関係プロパティとして使用するフィールドの名前はプロパティ名に接尾語「ーProperty」を追加する。

メソッドの名前

✓ メソッドは型のアクションを意味するので、メソッドの名前は動詞にしよう。

✓ メソッド名には PascalCase を使おう。

public class String
{
public int CompareTo(...);
public string[] Split(...);
public string Trim();
}

イベントの名前

イベントは、常に何らかのアクションを参照している。そのアクションには、①現在進行形で発生している最中のものと、②現在完了形で既に終了したものがある。
そのためメソッドと同様にイベントの名前は動詞にして、英語の時制表現を利用して①②のいずれなのかを明確にしよう。

✓イベントの名前は動詞にしよう。
たとえば、Clicked、Painting、DroppedDown、という具合にしよう。

✓ 現在進行形と現在完了形でイベントが参照するアクションの時制を明確にしよう。
たとえば、ウィンドウが閉じられる前に発生するイベントは、Closing とする。ウィンドウが閉じられた後に発生するイベントは、Closed とする。

✖ 上記の目的のために「Before」または「After」といった接頭辞または接尾辞を使うのはやめよう。

✓ デリゲートをイベントの型として使う場合、次の例で示すように接尾辞「ーEventHandler」をイベントハンドラの名前に追加しよう。

public delegate void ClickedEventHandler(object sender, ClickedEventArgs e);

✓イベントハンドラの2つのパラメータは、sender と e という名前にしよう。
sender パラメータは、イベントを発生させたオブジェクトを表現する。sender パラメーターの型は、具体的な型が決まっていても object とする。

✓イベント引数のクラス名には接尾辞「ーEventArgs」を追加しよう。

メニュー

2017-06-25T16:13:44+09:00

**メニュー -[[トップページ]] -[[プラグイン紹介>プラグイン]] -[[wiki編集練習用]] -[[簡潔な文書作成の要点]] -[[コーディング規則]] --[[コーディング規則の目的]] --[[命名規則]] ---[[大文字と小文字の表記]] ---[[一般的な名前付け規則]] ---[[アセンブリとDLLの名前]] ---[[名前空間の名前]] ---[[型の名前]] ---[[メンバーの名前]] ---[[パラメーターの名前]] ---[[リソースの名前]] ---[[良く使う英単語集]] ---[[良く使う対義語集]] --[[レイアウト規則]] ---[[空白]] ---[[インデント]] ---[[スペース]] ---[[改行]] ---[[かっこ]] ---[[ステートメント]] --[[コメント規則]] -[[ツール]] --[[GIT]] ---- **リンク -[[@wiki>>http://atwiki.jp]] -[[@wikiご利用ガイド>>http://atwiki.jp/guide/]] // リンクを張るには "[" 2つで文字列を括ります。 // ">" の左側に文字、右側にURLを記述するとリンクになります //**更新履歴 //#recent(20) &link_editmenu(text=ここを編集)

改行

2017-06-25T16:10:20+09:00

改行

✓ 改行のレイアウトは、下記のオプション設定に従おう。
ツール＞オプション＞テキストエディター＞C#＞書式設定＞改行

インデント

2017-06-24T22:23:41+09:00

インデント

インデントを使って、プログラムの論理構造を明らかにしよう。論理的に従属関係にあるステートメントにはインデントを付ける。
インデントの字下げ量、タブ文字の使用の可否などは特にプログラマの宗教論争の発火点になりやすい。
プロのプログラマであるならば、自らのアイデアやこだわりを適切に抑制し、コンセプトデザインの完全性に貢献しよう。
インデントについては、次のガイドライン（コードエディターの既定の設定）に従おう。

✓ インデントのサイズは、半角スペース4つを使おう。

✖ タブ文字を使用してはならない。

✓ Visual Studio のコードエディターで、スペースを表示しよう（編集＞詳細＞スペースの表示）。
スペースを非表示にしているプログラマのコードは、不要なスペースが残っていたり、タブ文字と半角スペースと全角スペースが混在したりしている。
このようなコードは、スペースを表示しているプログラマには見苦しい状態で表示される。スペースを表示し、自分のコードの品質を確認する習慣をつけよう。

空白

2017-06-24T22:15:21+09:00

空白

Usewhitespacetoenhancereadability（Use white space to enhance readability：空白を使って読みやすくしよう）
スペース、タブ、改行、空行といった空白は、プログラムの構造を明らかにする基本的なツールである。

✓ 空行を利用して、関連するステートメントを1つのグループにまとめよう。

文章を書くときは、考えを段落にまとめる。優れた段落には、特定の考えに関連する文しか含まれていない。無関係な文は含まれていない。
同様に、優れたコードのグループには、1つのタスクを遂行する互いに互いに関連するステートメントだけが含まれている。

コーディング規則の目的

2017-06-23T08:09:14+09:00

コーディング規則の目的

ほとんどのヨーロッパの大聖堂は、いろいろな時代にわたってさまざまな建築家が建てた部分との間に、構想や建築様式の相違がみられる。
後代の建築家は、様式の変更や好みの違いを反映させるため、それ以前の設計を「改良」したいと思うものだ。
だから、穏やかなノルマン建築の外廊が、高くそびえ立つゴシック様式の本堂と隣接し、互いに主張しあっている。
その結果、神への賛美と同じくらいに建築家の奢りを物語ることになる。

これに反し、ランス大聖堂の統合された建築様式は見事な対照を見せている。見るものは、個々の美しさ同様にそのデザインの見事な調和に心を動かされる。
ガイドブックにあるように、この完全さは八世紀にわたる建築家の自己犠牲によって得られたものであり、全体が統一されたデザインになるよう、彼らはそれぞれ自分のアイデアを犠牲にした。
その結果、そこには神への賛美のみならず、堕落した人間を奢りから救出する神の力が示されることになった。

コンセプトデザインの完全性こそ、システムデザインのもっとも重要な考慮点だと言いたい。

ー Frederick Phillips Brooks, Jr. 人月の神話

ザ・ブックからそのまま出てきたような

ーポール・エルデシュ

コーディング規則には、次の目的がある。

✓ コンセプトデザインを統一し、コードを読みやすく美しく仕上げる。
趣味で一人書くコードにコーディング規則は不要だ。自分が正しいと思う方法でコードを書けばいいだろう。
しかし、プロがチームでおこなう開発にはコーディング規則が必要だ。
世の中には正しく美しいスタイルやコンセプトがいくつも存在する。しかし、それらが混在してしまっては、もはや正しくもなければ美しくもない。
コンセプトデザインの完全性こそ、システムデザインのもっとも重要な考慮点だと言いたい。

✓ コーディング規則によりコードの共有化の基盤をつくる。
Steve McConnell の「CODE COMPLETE」によれば、プログラムを作成するのに必要な時間には人によって10対1の差がでるそうだ。
もちろん、McConnell の主張は「だから優れたプログラマになろう」ということなのだろう。
しかし物事を裏側から眺めれば、たとえ最高のプログラマであっても最低のプログラマの10倍程度の生産性しか出せないことになる。
個の力を高めるのは言うまでもなく重要だ。しかし、一人でできることには限界がある。時間は有限のリソースだ。
コードの共有化による集合知の構築を目指そう。

✓ コードを読むとき、内容・本質に重点を置くことができる。
コーディング規則は、コードの内容・本質については何も語らない。
コードの内容・本質ではなく、コードを書く上で検討が必要になる識別子の命名規則やレイアウト規則、コメントの書き方などディテールを説明する。
こうしたディテールの一つ一つを規則化・パターン化しておくことで、プログラマはコードの内容・本質に集中できるようになる。