- PR -

わかりやすいソースコードってどんなもの?

投稿者投稿内容
Beatle
ぬし
会議室デビュー日: 2003/06/09
投稿数: 394
投稿日時: 2004-04-28 15:27
引用:

はにまるさんの書き込み (2004-04-28 14:37) より:

 一般に「このプログラムは分かり難い」と思う理由は、構成の問題では?
 と考えました。




構成の問題が最も分かりにくくする要因だと思いますね。論理テーブル設計と同じで
あまりにも正規化しすぎると、ソース量は減っても、かえって分かりにくくなったし
ますから...

あと、コメントに関しては微妙ですね...
上級者が初心者を意識して、「教育」という要素があれば、動きそのもののコメント
があったほうが良いのですが、「教育」要素ではないプログラムの場合、プログラムの
動きは、きっちり出来ていればコメントは不要だと思います。(見れば解る)
が、「何をしているか」ではなくて「なぜそうするか」というようなコメント、
つまり仕様のようなコメントが欲しいと思うのですけどね。
極端な話、設計書が無い状態のとき、ソースから設計書が起こしやすいようなコメント
があればと思うのです。(ソースから業務フローかシステムフローまで起こせれば言う
事無いのですけど...無理ですね(^^ゞ)
との
会議室デビュー日: 2004/04/28
投稿数: 1
投稿日時: 2004-04-28 17:28
デバッグしやすいソースってのは
たいてい綺麗にみえるもんですがいかがでしょ。

構成がまとまっていなかったり、
適切なコメントがついていなかったり、
適切なクラス名、メソッド名がついていなかったりすると、
ソースを追い難い原因だと小生考えております。
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2004-04-29 10:36
引用:

るぱんさんの書き込み (2004-04-28 13:06) より:



 前の会社には、javaでいうところのjavadocですか?C#でいうところのXMLコメントファイルですか?コメントから仕様書を生成するツールを作っていたので、仕様書として恥ずかしくないコメントをつける、かつメンテすることが会社のルールだったのです。。。でも、ひと目、つまり20行程度いないで、メソッド名や変数名から何をしているかわかる場合は、処理内容のコメントをつけなかったりします。



[quote]
tak3さんの書き込み(2004-04-28 12:57)より:

ここまでやってる方って実際多いと思うのですよ。
でも、このあとの実装になると・・・
[/qoute]
 それは「設計をどの程度まで行うか」にもよると思います。これは「慣れ」もあるのかと思います。慣れれば、「この処理にはn個の手順が必要」というのが「経験的に」わかっています。その為、
コード:
データベースの接続文字列取得
データベースのコネクション取得
オートコミットをオフに設定


は、「データベース接続という処理の為の一連の手順」となるのではないでしょうか。もちろん、これは随所でやるでしょうから、1つのメソッドにまとめて、メソッド内にこのコメントを書きたいところですが…



 そういえば、ふと疑問。皆さんはif文のコメントをどう書きますか?って、スレッド起こすか。。。
unibon
ぬし
会議室デビュー日: 2002/08/22
投稿数: 1532
お住まい・勤務地: 美人谷        良回答(20pt)
投稿日時: 2004-04-29 13:59
unibon です。こんにちわ。

引用:

るぱんさんの書き込み (2004-04-27 16:02) より:
1.「自分がメンテナンスするとしたら、こういうのが読みやすい! 」


メンテナンスと言っても、
(1)バグを見つけて取り除くためだけのもの
(2) 機能拡張や改造という複雑なもの
に分けられると思います。(ただ、ここでのメンテナンスは暗に(1)でしょうか?)

上記(1)ならば、ぱっと見の見易さ・分かりやすさがあったほうが良いかもしれません。これを優先する場合は、できるだけフラットな構造にして、たとえばRDBなら非正規化してあったり、コードならネストは浅く、グローバル変数を多用するというのも手だと思います。こういうコードを見るときは過度であってもコメントがたくさんあったほうが良いのかもしれません。
一方で上記(2)ならば、ぱっと見の見易さよりもむしろアーキテクチャーの奇麗さや統一感(デザインパターンの使用等)が求められるかもしれません。こういうコードだと過剰なコメントがあってもあまり意味はなく、逆に見づらいだけかもしれません。
はにまる
ぬし
会議室デビュー日: 2003/12/19
投稿数: 969
お住まい・勤務地: 誤字脱字の国
投稿日時: 2004-05-06 13:08
はにまるです。

前投稿で
引用:

takuさんの書き込み (2004-04-27 15:25) より:
コメントが無くても何をしているのか解る。


という発言があり、その後NAL-6295さんから、その具体的方法が提示されました。
個人的には、「ふ〜ん、そんな考えもあるな〜」と流していたのですが、
NAL-6295さんのHPで、その背景にある考えを読み、「おお!なるほど!」と感動してしまいました。

既に御存知の方もいらっしゃるとは思いますが、
「技術習得は、その背景を知る事で更なる知識を得る事が出来る」考えから、
図々しくもNAL-6295さんへ引用許可をPMで依頼し、ご好意によりOKを頂きましたので
ここに、その文書を引用致します。

引用:

コメントレスコーディングのススメ
---------------------------------------------------------
コメントを書かないでコーディングしましょう。
コメントを書かないでコーディングしましょうと言うことは、プログラムの解読をコメントに頼らない。読みやすさをコメントに頼らない。という事で、読みやすいコーディングを心がけましょうと言うことです。
個人的な経験上から言うと、コメントが多いプログラム程、読みにくい構成になっています。
変数名、関数名、クラス名がむやみに短縮されていたりして、何も連想できなかったりします。
あと、保守されていないコメントは、ミスリードを誘います。叙述トリックです。(違う)
というわけで、コメントレスコーディングを奨めるわけです。
もれなく、以下の特典が付いてきます。

自分に・・・
・構成力がつく。
・文章力がつく。
・その他(考えてください)

プログラムが・・・
・読みやすくなる。
・保守性が高くなる。
・その他(考えてください)
です。

ちなみに、コメントレスコーディングをするに当たって気をつけなくてはいけないのは以下の点。

・変数名、関数名、クラス名を省略しない。
・それぞれが持っている役割を書く。
・名前は長くなっても良い。
・名前が長すぎると思ったら、役割を持ちすぎているので分解する。
・マジックナンバーを使わない。
・文章を書くようにプログラムする。

これらが守られなかった場合、悪夢をみます。
って、別にコメントレスじゃなくても、当然気をつけるべき点ですね。

まぁ、モノは試し、とりあえず、コメントレスでコーディングしてみて、読みにくいと思ったら、要所要所コメントを付ければいいのではないでしょうか。

と、ちょっと端折り気味。



# NAL-6295さんへ、この場を借りてお礼申し上げます。

【注意】
1.@ITさんの引用タグを使い原文を直接引用しているので読み難いかもしれません。
  その場合はリンク先へGO!

2.リンク先は個人のHPですので、時間の経過によりリンクが外れる場合が御座います。

jmasu
会議室デビュー日: 2004/03/01
投稿数: 19
投稿日時: 2004-05-06 13:24
こんにちは。jmasuと言います。

引用:

まゆりんさんの書き込み (2004-04-27 17:13) より:
(略)
そう言えば、入社した時に教育係(?)だった先輩は
私が付けた変数名や関数名を全部ローマ字に変えていました。
(例:strTel → Dennwa みたいな・・・)
確かに読みやすいけど・・・・どうなんでしょ?

[ メッセージ編集済み 編集者: まゆりん 編集日時 2004-04-28 00:22 ]


母国語を使うとバグが劇的に減るという調査結果もあるので、一概に良い悪いはいえない感じですね。個人的には「ダサいから嫌い。」ですけど。

スキルアップ/キャリアアップ(JOB@IT)