- PR -

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

«前のページへ 1|2|3|4 次のページへ»
投稿者投稿内容
tak3
ベテラン
会議室デビュー日: 2004/04/15
投稿数: 80
お住まい・勤務地: 菜の花・銀杏
投稿日時: 2004-04-28 00:54
性別で処理を振り分けたい場合、どの書き方が見やすいと思いますか？
どのように書いていますか？
男女で処理が共通する部分があります。

コード:

１．
if（性別 == 男 ）｛
    // 男女共通処理
    // 男性用処理
｝else ｛
    // 男女共通処理
    // 女性用処理
｝

２．
//男女共通処理
if（性別 == 男 ）｛
    // 男性用処理
｝else ｛
    // 女性用処理
｝

３．
if（性別 == 男 ）｛
    // 男女共通関数呼び出し
    // 男性用処理
｝else ｛
    // 男女共通関数呼び出し
    // 女性用処理
｝
男女共通関数｛
    // 男女共通処理
｝

４．
if（性別 == 男 ）｛
    // 男性用処理をする関数呼び出し
｝else ｛
    // 女性用処理をする関数呼び出し
｝

男性用関数｛
    // 男女共通処理をする関数呼び出し
    // 男性用処理
｝
女性用関数｛
    // 男女共通処理をする関数呼び出し
    // 女性用処理
｝
男女共通関数｛
    // 男女共通処理
｝


１〜４の順に、自分の書き方の推移だったりします。
１．素直にif文の内部で男女の処理を「そのまま」書く
２．重複コードを減らすため、共通部分をif文の前に出す
３．２が非常にわかりづらいと感じ、共通部分を関数化しif文の中に戻す
４．自分の中での理想。実際のとこ３の場合が多々というのが現状。

単純な２分岐のケースなので、実際ここまで凝った書き方しないと思いますが。
要は、フロー制御の中に処理を直接書かずに、関数呼び出しだけにしておくと見やすい
（１〜３のケースは、処理に追加があるとif文の中身がどんどん膨れていくのでメンテが辛い）
と自分は思うのですが、皆さんはどうしていますか？
m.ku
大ベテラン
会議室デビュー日: 2002/09/15
投稿数: 184
投稿日時: 2004-04-28 01:29
> 性別で処理を振り分けたい場合、どの書き方が見やすいと思いますか？
> どのように書いていますか？

まあ例示されている様に物量と経緯次第な面はありますね。
概ねケースバイケースです。
ただ、仕様変更がやたら多いような状況だとわざとベタ書きして
仕様変更が落ち着くまでコンパクト化を避ける様にすることも
あります。下手に早い時点で最適化すると変更が大事になるので。
なちゃ
ぬし
会議室デビュー日: 2003/06/11
投稿数: 872
投稿日時: 2004-04-28 02:45
開発言語とその後どのようになる可能性があるかによりますが、
思わずクラスにしてしまいそうです。

ある程度の規模になる事が予想される、場合わけが際限なく増える
可能性があるといった場合に特にですが。
るぱん
ぬし
会議室デビュー日: 2003/08/01
投稿数: 1370
投稿日時: 2004-04-28 09:42
るぱんです。

個人的な希望は４番。
そう言う風に作ってます。

あと、細かい突っ込みですが、
コード:
３−１．
// 男女共通関数呼び出し

if（性別 == 男 ）｛
    // 男性用処理
｝else ｛
    // 女性用処理
｝
男女共通関数｛
    // 男女共通処理
｝


こんなんじゃダメですかね？
設計の観点からはこっちの方がお勧めのような気がします。
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2004-04-28 11:37
引用:

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

そこで、逆説的に、自分がメンテナンスするとしたら、こういうのが読みやすい！
と言うような物有りますでしょうか？

　もう一つのスレッドより、「仕様書がない」という前提で、いいですね？


　そうですね。私も「機能仕様書」は作っても「関数仕様書」は作らないことが多いですから

　箇条書きで「すること」がコメントしてあるもの、かな？私の場合、最初にコメントで「何をするか」を書くことが多いです。
コード:
// データベースと接続する
// SQL文の前半を作成
// 入力から条件を作成
// データベースへ問い合わせ
// 結果を表示

一度列挙してから、メソッドを分けたり、より細かいものを書きます。なので、後からコメントだけ抜き出して追いかければ、何をしているかわかります（もちろん、仕様変更が入るとコメントもメンテする）。
tak3
ベテラン
会議室デビュー日: 2004/04/15
投稿数: 80
お住まい・勤務地: 菜の花・銀杏
投稿日時: 2004-04-28 12:57
引用:

箇条書きで「すること」がコメントしてあるもの、かな？私の場合、最初にコメントで「何をするか」を書くことが多いです。

// データベースと接続する
// SQL文の前半を作成
// 入力から条件を作成
// データベースへ問い合わせ
// 結果を表示


ここまでやってる方って実際多いと思うのですよ。
でも、このあとの実装になると・・・

コード:
 
connectDB()　　　　　// データベースと接続する
createSQL()　　　　　// SQL文の前半を作成
createCondition()　　// 入力から条件を作成
execQuery()　　　　　// データベースへ問い合わせ
showResult()　　　　// 結果を表示

みたいに書くとコメントと処理が追いやすいのですが、実際は・・・

コード:
 
// データベースと接続する
データベースの接続文字列取得
データベースのコネクション取得
オートコミットをオフに設定
うんぬんかんぬん
// SQL文の前半を作成
SELECT句作成
// 入力から条件を作成
WHERE句作成
if（ カラム１ ！＝ NULL)｛
   WHERE区に追加
｝
if （カラム２ ！＝ NULL）｛

// データベースへ問い合わせ
処理がいっぱい
処理がいっぱい
// 結果を表示
処理がいっぱい
処理がいっぱい


というコードを多く見かけて、コメント追うのが一苦労するっていうケースが多々ありまして、
最初の箇条書きがコードに埋もれちゃって意味無いじゃん！と思うわけなのですよ。
皆さんは、よく見かけませんか？
るぱん
ぬし
会議室デビュー日: 2003/08/01
投稿数: 1370
投稿日時: 2004-04-28 13:06
引用:

Jittaさんの書き込み (2004-04-28 11:37) より:
引用:

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

そこで、逆説的に、自分がメンテナンスするとしたら、こういうのが読みやすい！
と言うような物有りますでしょうか？

　もう一つのスレッドより、「仕様書がない」という前提で、いいですね？


　そうですね。私も「機能仕様書」は作っても「関数仕様書」は作らないことが多いですから

　箇条書きで「すること」がコメントしてあるもの、かな？私の場合、最初にコメントで「何をするか」を書くことが多いです。
コード:
// データベースと接続する
// SQL文の前半を作成
// 入力から条件を作成
// データベースへ問い合わせ
// 結果を表示

一度列挙してから、メソッドを分けたり、より細かいものを書きます。なので、後からコメントだけ抜き出して追いかければ、何をしているかわかります（もちろん、仕様変更が入るとコメントもメンテする）。

るぱんです。

＞Ｊｉｔｔａ様
おこし頂きまして、ありがとうございます。
仕様書ナシとして・・・です。

僕の場合は、
コメントの頭にＡ．とかＢ．とか振ってます。
順番にＡから進んでいけば流れを追えるようにコメントつけてます。
問題ありですけど、丸付１とかも使います。

仰るようにコメントのメンテナンスが実は重要なんですよね。
担当する人が変われば影響範囲の想定が狭くなると言う問題も有ると思います。

忙しくなればなるほどコメントからメンテナンスしなくなるもんですし。。。汗

貴重なお話をありがとう御座います。（＾＾
はにまる
ぬし
会議室デビュー日: 2003/12/19
投稿数: 969
お住まい・勤務地: 誤字脱字の国
投稿日時: 2004-04-28 14:37
はにまるです。

　なぜ「グローバル変数」を使っては、いけないのですか？
　なぜ「ＧＯＴＯ文」を使っては、いけないのですか？
　を議論して思った事。

　構造（関数／メソッドの切り方、アーキテクチャ）が確りしており、
　それをテンプレート利用（継承）していれば、多少ボケた構成文も、
　関数／メソッド内で収まり見難い問題が緩和される。

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

　既出の例題を引用させて頂くと、

コード:
　obj接続情報   = obj共通.ＤＢ.接続処理()
　strＳＱＬ文   = objプログラム.機能群.ＳＱＬ生成()
　objＳＱＬ結果 = 接続情報.ＳＱＬ実行(strＳＱＬ文)
　int実行結果   = objプログラム.機能群.一覧セット(objＳＱＬ結果)

とすれば、実装者は「objプログラム.機能群.ＳＱＬ生成()」の中身を触るだけで、
このパターンを知っていれば、ＳＱＬ生成()の内容を見る行為だけで済むと思います。

# ちなみに、自分でも何の言語か解らずに記述しています。
«前のページへ 1|2|3|4 次のページへ»

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