- PR -

「ソフトの質はコード量に関係するか？」の感想

参照元記事 | 同じ記事を参照しているスレッド一覧
1|2 次のページへ»
投稿者投稿内容
H2
ぬし
会議室デビュー日: 2001/09/06
投稿数: 586
お住まい・勤務地: 港
投稿日時: 2001-11-18 23:25
1.
引用:

「クラスを作成するときには再利用を考えて、汎用的な設計にせよ」という教科書的な正しさに真っ向から逆らうものだ。XPでは、「明日できることは今日やるな」という原則があり、次のプロジェクトで使うかもしれないという理由で、現在のプロジェクトでは不必要なメソッドを追加することを禁じているのである。

これは賛成できます。私もよく思うのですが、再利用を考えても使わなかったり、使えなかったりする方が多いですね。それであれば最初からわざわざ汎用的にする必要もないかと。

2.
引用:

XPではプログラマが2人で1台のパソコンを使ってコーディングするペアプログラミングを勧めている

これは難しいと思います。何度か大学の宿題でグループプロジェクトでペアプログラミングをしたのですが、だいたいパートナーと私のプログラミングスタイルと思考回路がまったく違い非常に効率が悪くなりました。相手が何をやっているかをその場で理解するのは難しいですね。また、あるパートナーは非常に怠け者で後ろでぶらぶら座って何もしないということも。

ただし、自分が書いたコードを他人にチェックしてもらうのは良いと思います。デバッグとコードチェックは他人にやってもらった方がはるかに効率的です。チェックするほうはコードの意味がわからなければ作成者にどんどん質問していくので、ミスや怪しい部分があればすぐに判明しますね。　（ただうちの大学では、個人のプロジェクト・宿題でコードの見せ合いを禁じてるため、残念ながらいつも使えるとは限らないのですが・・・）

3.
ちょっと気になるので質問です。「プログラムの読みやすさ」というのはコメントを含まないのですか？コメントを書けばわざわざソースを長くする必要はないのでは？私の場合、できるだけ短いコードで書き、理解のしにくそうなコードにはコメントを多く書くようにしています。これって「プログラムの読みやすさ」だと思っています。
biac
大ベテラン
会議室デビュー日: 2001/10/22
投稿数: 106
投稿日時: 2001-11-19 11:55
引用:

ちょっと気になるので質問です。「プログラムの読みやすさ」というのはコメントを含まないのですか？コメントを書けばわざわざソースを長くする必要はないのでは？私の場合、できるだけ短いコードで書き、理解のしにくそうなコードにはコメントを多く書くようにしています。これって「プログラムの読みやすさ」だと思っています。

コメントも含むと思います。
ただし、XP 的には、「コメントは減らすべし」でしょう。

一般的な開発プロセスですと、設計ドキュメントとソースコードを作成します。 言い換えれば、ドキュメントとコードの二重管理をしているわけです。 さらに、ソースコードを読むときにコメントも読まないと理解できないとしたら、ドキュメントとコメントとコードの三重管理になります。 (コードを修正するときに、コメントとドキュメントも忘れずに修正しないといけない。)

XP の文化は「無駄なことはするな」ですから、管理の手間が増えるコメントを書くより、同じことをコードで表現するほうが好まれるのでしょう。


それから、XP とは関係無く、私の考えとして、「ソースコードは人間のためのものだ」というのがあります。 C++ や Java などの高級言語で書かれたコードは、人間のためのものであり、それを機械に読めるようにするためにコンパイルするわけですよね。 したがって、ソースコードを読んで理解できないとすれば、それは、書き手の能力・読み手の能力・言語の表現能力のどれか (あるいは複数) が不足しているのだと考えます。 そこで、言語の限界によりコメントをつけざるをえない、という場合以外はコメントは不要だと思うわけです。 (管理からの要請によるものは、まぁ、別と考えるしかありませんが。 f(^^; )

例えば、私は英語が苦手です。 はっきりいって出来ません。 どうしても英語の文書を書かざるを得ないときは、日本語の注釈を付けて、英語の分かる人に添削してもらいたくなります。 やたらとコメントの多いソースは、この自信の無い英文と同じに見えてしまいます。
H2
ぬし
会議室デビュー日: 2001/09/06
投稿数: 586
お住まい・勤務地: 港
投稿日時: 2001-11-19 13:10
引用:

biacさんの書き込み (2001-11-19 11:55) より:
一般的な開発プロセスですと、設計ドキュメントとソースコードを作成します。 言い換えれば、ドキュメントとコードの二重管理をしているわけです。 さらに、ソースコードを読むときにコメントも読まないと理解できないとしたら、ドキュメントとコメントとコードの三重管理になります。 (コードを修正するときに、コメントとドキュメントも忘れずに修正しないといけない。)

うーん。そうでしょうか？私個人の意見ではコメントはソースコードの一部だと思います。ドキュメントとソースコードは大抵別のものですので二重管理というのはうなずけますが、コメントはソースコード内に書かれますので三重管理になるとは思いません。コードを長くしてわかりやすくすると、コード内で何箇所も直さないといけない可能性もあるのでやっぱり複数箇所修正しないといけない気がします。

コードとコメントは「どう」実装したのかを表現するものであり、両方を含めて「ソースコード」というのではないでしょうか？（設計ドキュメントはプログラムが「何」をするかを表現したものですよね）

揚げ足取り・・・ (コードを修正するときに、コメントとドキュメントも忘れずに修正しないといけない。)というのは仕様を変えてませんか？・・・

引用:

biacさんの書き込み (2001-11-19 11:55) より:
したがって、ソースコードを読んで理解できないとすれば、それは、書き手の能力・読み手の能力・言語の表現能力のどれか (あるいは複数) が不足しているのだと考えます。 そこで、言語の限界によりコメントをつけざるをえない、という場合以外はコメントは不要だと思うわけです。 (管理からの要請によるものは、まぁ、別と考えるしかありませんが。 f(^^; )

確かに、読み手と書き手の能力・言語の表現力は必要ですね。単純な普通のプログラマから見て一般的なことをしているのではあればコメントはいらないでしょう。しかし、高級言語とは言え、やはり日常会話で使う言語に比べればプログラム言語は表現力に劣ります。そういった所はコメントで補わないといけないと思います。

まぁ無駄なコメントは確かにいらないですが、（例　i++ //iに1足す　とか　笑）無理やり減らすのもいけないかなと思います。コメントってどのくらいが丁度いいのでしょうね。

私は、プログラムを大雑把な流れにして区切りの良いところで一行だけ何をしてるかのコメントを入れるようにしてます。複雑な処理をしている所は複数行にわたって説明を書きますが、1行というのは読みにくくなく十分だと思っています。
autumn
大ベテラン
会議室デビュー日: 2001/07/27
投稿数: 215
投稿日時: 2001-11-19 14:09
引用:

これは難しいと思います。何度か大学の宿題でグループプロジェクトでペアプログラミングをしたのですが、だいたいパートナーと私のプログラミングスタイルと思考回路がまったく違い非常に効率が悪くなりました。相手が何をやっているかをその場で理解するのは難しいですね。また、あるパートナーは非常に怠け者で後ろでぶらぶら座って何もしないということも。

　XPでは、個々の手段の弱点を別の方法で補っています。プログラミングスタイルが違うというのは、別個にプログラミングスタイルを統一するというルールを持ち込むことで弱点を補強しています。思考回路は難しいですが、XPが想定する開発期間は長いので、そのうちにお互いの思考回路が分かってくると思います。

引用:

ちょっと気になるので質問です。「プログラムの読みやすさ」というのはコメントを含まないのですか？コメントを書けばわざわざソースを長くする必要はないのでは？私の場合、できるだけ短いコードで書き、理解のしにくそうなコードにはコメントを多く書くようにしています。これって「プログラムの読みやすさ」だと思っています。

　コメントの質というのも問題になると思います。書きすぎたコメントというのも始末に負えないもので、ソースを見れば一目瞭然のことまで全部説明して、しかもソースを直したのにコメントを直し忘れて、ソースを理解するのに役立たなかったりします。そういう意味で、コメントはあればあるだけ良いと言うわけではなく、書くべき場所と内容を選ぶと思います。まったくコメントを書かないのは論外ですが、書き過ぎも良くないと思います。ですので、分かりにくいポイントに絞ってコメントを付けるというのは、良い選択だと思います。
　理想的には、コメントなど付けなくても意味が分かるようにソースを書くべき、という意見もありますが、それは理想論で、現実的にはコメントが必要になってしまいますね。

　余談ですが、C#で///を使って埋め込んだクラスやメソッドの説明は、VS.NETで編集中にポップアップする情報に表示されて便利です。こういう情報は従来型のコメントとは別個に評価すべきものでしょうね。

_________________
biac
大ベテラン
会議室デビュー日: 2001/10/22
投稿数: 106
投稿日時: 2001-11-20 22:19
引用:

コメントはソースコード内に書かれますので三重管理になるとは思いません。

ものすごくくだらない例で申し訳ないんですが、
コード:
    amount = totalPrice * 1.05;  // 消費税率 3%
というようなコードとコメントに出くわしたことはありませんか? 寿命の長いプログラムには、えてしてこういうことが起こります。

これぐらいなら、「ああ、消費税率の変更があったときに、コメントを直すの忘れたな」と分かりますが。


引用:

しかし、高級言語とは言え、やはり日常会話で使う言語に比べればプログラム言語は表現力に劣ります。そういった所はコメントで補わないといけないと思います。

同感です。
私が「言語の限界によりコメントをつけざるをえない」と書いたのと、同じような意味合いだと思います。 「コメントをつけざるをえない」というのは、そういう場面では、「付けるべきだ」ということです。

引用:

揚げ足取り・・・ (コードを修正するときに、コメントとドキュメントも忘れずに修正しないといけない。)というのは仕様を変えてませんか？・・・ :)

もちろん、ドキュメントの修正をともなう状況、多くは「仕様変更」の場合を想定して、書きました。

引用:

私は、プログラムを大雑把な流れにして区切りの良いところで一行だけ何をしてるかのコメントを入れるようにしてます。複雑な処理をしている所は複数行にわたって説明を書きますが、1行というのは読みにくくなく十分だと思っています。

私も、通常そういうコメントの入れ方をしています。 (あと、英単語がわかりにくい変数名の後ろに、日本語訳を書いておくことが多い。)

長くなりますが、例を出します。

コード:
public int sampleMethod(...){
    // foo を取得
    //...コード...

    // bar を取得
    //...コード...

    // foo と bar から、結果を計算
    int result = 0;
    //...コード...

    return result;
}


というようなメソッドがあったとします。
「...コード...」の部分がそれぞれ数行くらいずつなら、なにも言うことはないと思います。 メソッド全体を通して、明確に処理の流れがわかります。

ところで、「...コード...」の部分がそれぞれ 100行にもなる場合はどうでしょう? それでもメソッド全体の流れが分かるでしょうか? (「//...コード...」の行をコピー&ペーストして長くしたサンプルも書けますが、長くなるだけで無意味ですんで、書きません。 想像してください。)
私には、おそらく理解できなくなります。 こういうときに、メソッドを抽出するリファクタリングが有効だというのです。

コード:
public int sampleMethod(){
    // foo を取得
    OBJ foo = getFoo();

    // bar を取得
    OBJ bar = getBar();

    // foo と bar から、結果を計算
    return calcResult(foo, bar);
}

private OBJ getFoo(){
    //...長いコード...
    return foo;
}

private OBJ getBar(){
    //...長いコード...
    return bar;
}

private int calcResult(OBJ foo, OBJ bar){
    int result = 0;
    //...長いコード...
    return result;
}


で、sampleMethod() の中では、コメントと次の行が同じ意味になりましたから、コメントを削除できる、というわけです。

コード:
public int sampleMethod(){
    OBJ foo = getFoo();
    OBJ bar = getBar();
    return calcResult(foo, bar);
}


ところで、こうすると、他のメソッドからアクセスできるメソッドが増えてしまう、という、autumn さんが指摘した欠点があります。 いつリファクタリングすべきかというさじ加減が難しい、という問題を抱えます。

この例に関しては、言語の限界から来てる問題だと、私は思います。
「メソッドローカルなメソッド」が宣言できればいいのに、と思ったりするわけです。 そうすれば、文章で言う章・節のような論理構造が表現できるのに。 つまり、こんな具合に書ければなぁ、と。 f(^^;

コード:
public int sampleMethod(){
    return calcResult(getFoo(), getBar());

    local OBJ getFoo(){
        //...コード...
        return foo;
    }

    local OBJ getBar(){
        //...コード...
        return bar;
    }

    local int calcResult(OBJ foo, OBJ bar){
        int result = 0;
        //...コード...
        return result;
    }
}


繰り返しになりますが、言語がそういう方向へ進化していけばコメントは無くて済むようになるんだ、理想はコメント無しのソースコードである、と思っています。

# もっとも、私の場合、変数名の日本語訳はやめられそうにありません。 :-p
　あ、これも、日本語変数名で解決? f(^^;
autumn
大ベテラン
会議室デビュー日: 2001/07/27
投稿数: 215
投稿日時: 2001-11-22 13:30
引用:

「メソッドローカルなメソッド」が宣言できればいいのに、と思ったりするわけです。

　リファクタリングの本を読んで、「なるほど!」と思ったのは、長いメソッドはクラスにしてしまえというアイデアです。というか、過去にそれらしいこともやってるんですけどね。典拠があれば強く自信を持って書けます。
　クラスならローカルなメソッドをいくつでも書けます。

_________________
autumn
大ベテラン
会議室デビュー日: 2001/07/27
投稿数: 215
投稿日時: 2001-11-22 15:12
引用:

# もっとも、私の場合、変数名の日本語訳はやめられそうにありません。
　あ、これも、日本語変数名で解決? f(^^;


　こんなの書けましたけど〜〜〜!?

コード:
using System;

namespace ConsoleApplication17
{
	class Class1
	{
		private const decimal 消費税率 = 0.05M;
		private static decimal 消費税加算( decimal 金額 ) 
		{
			return 金額*(1+消費税率);
		}

		static void Main(string[] args)
		{
			decimal 価格 = 100;
			decimal 税込価格 = 消費税加算(価格);
			Console.WriteLine( 税込価格 );
		}
	}
}


_________________
autumn
大ベテラン
会議室デビュー日: 2001/07/27
投稿数: 215
投稿日時: 2001-11-23 16:18
　自分で書いていて気に入らないので、書き直してしまった^^;
　ああ、なんか、自分でポリモーフィズム多用は気に入らないとか、短いプログラムは正しいとか書いてたはずなのに、それに逆行するようなソースになってるなぁ (絶賛自滅中)
　ちなみに、ふるまいは何も変わらない税抜価格と税込価格を分けたのは、2重に課税するコードを書こうとすると自動的にコンパイルエラーになるようにするためです。また、is演算子で、扱っている価格が税込みか税抜きかを動的に判定できるようにもなります。

コード:
using System;

namespace ConsoleApplication18
{
	class 消費税
	{
		public const decimal 税率 = 0.05M;
		public static 税込価格 課税する( 税抜価格 対象価格 ) 
		{
			return new 税込価格( 対象価格.金額*(1+税率) );
		}
	}
	class 価格
	{
		private decimal _金額;
		public decimal 金額 
		{
			get { return _金額; } set { _金額 = value; } 
		}
	}
	class 税抜価格 : 価格
	{
		public 税抜価格( decimal 初期値 ) 
		{
			金額 = 初期値;
		}
	}
	class 税込価格 : 価格
	{
		public 税込価格( decimal 初期値 ) 
		{
			金額 = 初期値;
		}
	}
	class Class1
	{
		static void 価格表示( 価格 対象 ) 
		{
			if( 対象 is 税抜価格 ) 
			{
				Console.WriteLine( "税抜き価格 {0}円", 対象.金額 );
			} 
			else if( 対象 is 税込価格 ) 
			{
				Console.WriteLine( "税込み価格 {0}円", 対象.金額 );
			} 
			else 
			{
				Console.WriteLine( "価格 {0}円", 対象.金額 );
			}
		}
		static void Main(string[] args)
		{
			税抜価格 缶コーヒー価格 = new 税抜価格(115);
			税込価格 税込缶コーヒー価格 = 消費税.課税する(缶コーヒー価格);
			価格表示( 缶コーヒー価格 );
			価格表示( 税込缶コーヒー価格 );
		}
	}
}

_________________
1|2 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）