読み取り可能なコードを記述するアート(4)

第四章審美
良いソースコードは目を養うように見えるはずです.多くの会社は符号化規範の上で一致しなければならない.ソースコード全体をきれいに見せることができ、筋道が通っているため、このようなコードは、読むのがもっと便利だ.
コードを審美的に改造する際には、以下の原則に従うことができます.
a、一貫したレイアウトを使用する
b、似たようなコードを似たように見せる
c、関連するコード行をグループ化し、コードブロックを形成する.
1、改行を再配置して一貫性とコンパクトさを保つ
まず、次の例を見てみましょう.クラスの構造関数には、ネットワーク接続速度(Kbps)、平均遅延(ms)、遅延のジッタ(ms)、パケット損失率(%)の4つのパラメータがあります.この例では、3つの異なる例が必要です.

public class Tester{
	public Tcpconnect wifi = new Tcpconnect(
		500, /*Kbps*/
		80, /*ms latency*/
		200, /*jitter*/
		1 /*packet loss %*/);
	
	public Tcpconnect t3_fiber = 
		new Tcpconnect(
			450000, /*Kbps*/
			10, /*ms latency*/
			0, /*jitter*/
			0 /*packet loss %*/);
			
	public Tcpconnect cell = new Tcpconnect(
		500, /*Kbps*/
		80, /*ms latency*/
		200, /*jitter*/
		1 /*packet loss %*/);
}

このコードはきれいに見えますが、t 3_だけです.fiberの定義は他の2つと形式的に異なり、これはそれを際立たせている.次のように書くと、一致を保つことができます.

public class Tester{
	public Tcpconnect wifi = 
		new Tcpconnect(
			500, /*Kbps*/
			80, /*ms latency*/
			200, /*jitter*/
			1 /*packet loss %*/);
	
	public Tcpconnect t3_fiber = 
		new Tcpconnect(
			450000, /*Kbps*/
			10, /*ms latency*/
			0, /*jitter*/
			0 /*packet loss %*/);
			
	public Tcpconnect cell = 
		new Tcpconnect(
			500, /*Kbps*/
			80, /*ms latency*/
			200, /*jitter*/
			1 /*packet loss %*/);
}

これでいいですか?
このコードを見直します.このコードは縦方向の空間が多すぎて、注釈の部分が重複しているところがたくさんあります.少し修正すると、よりきれいになります.

public class Tester{
	// Tcpconnect(throughput,  latency, jitter, packet_loss);
	//	       /*Kbps*/	    /*ms*/  /*ms*/   /*percent*/
	public Tcpconnect wifi = 
		new Tcpconnect(500, 80, 200, 1);
	
	public Tcpconnect t3_fiber = 
		new Tcpconnect(450000, 10, 0, 0);
			
	public Tcpconnect cell = 
		new Tcpconnect(500, 80, 200, 1);
}

このコードはさらに一目瞭然に見えます.
2、不規則なものを整理する方法
コードを見つめる過程で,重複するコードが精錬されているかどうか,関数を抽出することで不規則なコードをよりきれいに整理できるかどうかに注意する必要がある.
たとえば、「Doug Adams」が「Mr.Douglas Adams」に拡張されたように、人名をより正式に拡張できるAPIインタフェースがあり、マッチング関係は所与のデータベースから検索され、拡張できないと、パラメータ形式でエラーコードが返されます.このインタフェースは次のとおりです.

string ExpandFullName(Database dc, string partial_name, string *error)

このAPIのテストはいくつかあります.

Database dc;
string error;
assert(ExpandFullName(dc, "Doug Adams", &error) 
	== "Mr. Douglas Adams");
assert(error == "");
assert(ExpandFullName(dc, "Jake Brown", &error) 
	== "Mr. Jacob Brown III");
assert(error == "");
assert(ExpandFullName(dc, "No Such Guy", &error) == "");
assert(error == "no match found");
assert(ExpandFullName(dc, "John", &error) == "");
assert(error == "more then one result");

このテストコードでは改行が不規則で、形式も一致せず、第一印象が乱れます.改行を再配置してもより良い効果は得られないため,これらのコードの実現に注目する必要がある.これらのコードは同じ機能を実装していることがわかります.これらの具体的な実装の詳細を抽出することができます.以下のようにします.

CheckFullName("Doug Adams",  "Mr. Douglas Adams",   "");
CheckFullName("Jake Brown",  "Mr. Jacob Brown III", "");
CheckFullName("No Such Guy", "",                    "");
CheckFullName("John", 	     "", 		    "more then one result");

void CheckFullName(string partial_name,
				   string expected_full_name,
				   string expect_error)
{
	Database dc;
	string error;
	string full_name = ExpandFullName(dc, partial_name, &error); 
	assert(error == expect_error);
	assert(full_name == expected_full_name);
}

修正されたコードは、上記のように3つの追加効果をもたらします.
a、大量の重複コードを排除
b、各テストで注目すべき部分をより明確にし、expected_error,expected_full_name, partial_name.
c、新しいテスト項目を追加するのは簡単です.
ここから、「美しく見える」コードは、表面的なレベルの改善をもたらすだけでなく、コード構造をよりよくすることができます.
3、必要に応じて列を配置する
整然としたエッジと列は、読者がテキストを簡単に読むことができます.上の例ではこのテクニックを使用しています.
たとえば次の例です.

details  = request.POST.get("datails");
location = request.POST.get("location");
phone	 = equest.POST.get("phone");
email 	 = request.POST.get("email");
url	 = request.POST.get("url");

列整列を使用すると、不規則な項目が一目でわかり、エラーが見つかり、requestはアルファベット「r」を失いました.
また、コードで意味のある順序を選択した場合は、できるだけ一貫して使用することに注意してください.上記の例のように、details、location、phone、email、urlに従って人の情報を記述し、後続のコードの中で、突然別の順序で人を記述すると、思考上の突然の不防備をもたらすことが多い.
4、声明と実現をブロックによって組織する
私たちが子供の頃作文を書いたように、手順や意味によって、コードをブロックの形式で組織します.コードの行数が多くなったように見えますが、各階層の段落をすばやく見つけ、各セグメントのコードの意図をより直感的に理解するのに役立ちます.
このほうが分かりやすいので、詳しく説明しません.
5、個人的なスタイルの一致性
コードの審美的な選択の一部は個人的なスタイルにまとめることができます.例えば、次の2つのスタイルです.

class C{
	...
};
class C
{
	...
};

かっこの開始位置.これはコードの可読性に影響しませんが、2つの方法が混ざっていると、読者に友好的ではないように見えます.
一致したスタイルは往々にして「正しい」スタイルよりも重要である.