【解り易い】上手なプログラムを書くには【美しい】

『他の人が見て用意にソースが追える。』
『あとでメンテナンスや、機能追加しやすいしやすい。』
プログラムを作成する上で、
上手で美しいプログラムを書く為に、
どのようなことを、気をつけていますか？
心がけていますか？

関数や変数・定数には、解り易い名前を付ける。
ネストを深くしない。
１つの関数は１００行以内にする。
コメント文をきちんと書く。
GOTO文は使わない。
データの授受は引数を使い、グローバル変数やStatic変数は極力止める。
(ローカルスコープする。）
このあたりが、基本的なことでしょうか？

他にどのようなことを心がけていますか？

2

いるな、読む気も失せるプログラム書く奴
そんな奴のプログラムに限って
うまく動かなくて（あたりまえ）
上司から「お前、ちょっと見てやってくれ」って言われる
すごい、苦痛

そういう時は、もう情け容赦なく
そのプログラムは捨て、一から作り直す

ということで、２ゲット

最低限、インデント汁！
頼むから面をそろえて書くのはやめて〜！

こんな過疎板で2ゲットやるやつがまだいたとは（ｗ

>>1
まず、誤字を無くす所から始めような。

・変数の数を少なくする(特に、フラグ変数はなるべく使わない)。
・正常処理と、異常処理を混在させない。
・モジュール(クラス)に無駄なインターフェースを作らない。
・引数の順序・戻り値の内容を統一する。

1.ネストが深くなるなら関数に切り出す。
2.ダブルディスパッチが発生するなら、ジャンプテーブルとか、
OOP言語のポリモーフィケーションとか使いましょう。

これだけでも結構スッキリするような。

1. 用意にソースが追える
2. 追加しやすいしやすい
3. データの授受は引数を使う

ま、こんなとこかな。

>>1
単刀直入に言うと、XP, RUPを導入しろ。

if文を使わない方法を考える

おじいちゃんソース見づらーい

そんあときー

「インデントー」

これでｽｷﾘｰだねおじいちゃん




ムカッ

●コメントを書くだけでなく丁寧に書く。変数全てにももれなく書く。それこそ仕様書のように。
かなりめんどくさいけれど個人的には書きすぎて書きすぎる事はないと思ってる。

●コーディング規約にも通じるけれどグローバル、ローカル，引数
それぞれの変数の前に識別する文字をつける。g_とかw_とかa_とか

●フラグ変数は極力使わない。意味のないフラグの立ちまくるソースはいっぺんで萎え

●変更履歴は逐一つける。

●その都度きちんと動作確認し、いらないソースは潔くソースから消す。コメントにしたままにしない。

●これいるのかな？いらないのかな？的なソースは絶対にあってはならないようにする。

●引数の場所は揃える。コーディングに入る前に引数戻り値は頭か後ろかは決めておく

●変数名は事業部ならばJigyobuとするようにする。ヘタに事業部を英語に変換したり
Jgbなどと略さないようにする。結局解りづらい。

コメント文はとりあえず重要だと思う。

変数もそうだけど関数やクラスもやたらに作らない。
ただ単に切り分ける目的なら、切り分けずにコメント文で整理した方が変更しやすい場合もある。
よっぽど汎用性があったり、一括管理が必要な要件だけ関数化する。

クラスは、よっぽど汎用性のある場合だけに絞り、
できるだけ、できあいのクラスと似たような操作感にし、
メソッドの名前や引数の名前を工夫して使用方法を思い出しやすいようにする。
汎用性を意識した関数・メソッドでは、やたら複雑な動作をさせず、
あえて単純なもので抑え、外側で複数の関数を組み合わせて使用する形を取り、
その使用例から関数の動作を想像しやすいようにする。

グローバル関数は、できるだけその仕事の業務要件専用で、かつ一括管理するもののみにする。
汎用性の高いものはクラス化し、グローバル関数にしない。
大量の汎用グローバル関数があると名前を覚えるのが面倒だし、重複を防ぐため名前がやたら長くなる。
ＡＰＩはクラス内でローカル宣言し、クラスのメソッドとして名前を短くする。

>>13-14ってスゲーずれてるって思うの、俺だけか？

おれはエディタにいくらネストが深くなっても{と}に自動的に識別記号をつける機能をつけているね。
ネストの深い他人のソースを開くと、{と}に自動的に識別記号がつくから、どの{がどの}に対応しているかが一目でわかる。

誰が見ても>>13-14はズレてるから安心しなさい。
でも
・奇怪な業界用語はローマ字で。
・変数名を略すな。
には同意。
長い変数名をタイプするのが面倒ならコピペしろ。
単語選択＋コピーが面倒に思えるクソエディタなんぞ使うな。

>>13
> ●コメントを書くだけでなく丁寧に書く。変数全てにももれなく書く。それこそ仕様書のように。
> かなりめんどくさいけれど個人的には書きすぎて書きすぎる事はないと思ってる。
ある程度はドキュメント自動生成ツールにあわせれ。

> ●コーディング規約にも通じるけれどグローバル、ローカル，引数
> それぞれの変数の前に識別する文字をつける。g_とかw_とかa_とか
そもそも、グローバル変数を使用禁止にすればそんなことする必要はない。

> ●変更履歴は逐一つける。
CVSで差分ファイルを自動管理すればそんなもんいらん。
コミットすればソースコードにバージョン番号が勝手につく。CSVではないぞ！
変更履歴は別のファイルにログとして自動的に保存される。

> ●その都度きちんと動作確認し、いらないソースは潔くソースから消す。コメントにしたままにしない。
テストケースを作れ。XPの流儀に従い、テストファーストだ。
>
> ●これいるのかな？いらないのかな？的なソースは絶対にあってはならないようにする。
それもXPの常識。使う可能性がないまたは使うかどうかはっきりしないメソッドは作らないでおく。

> ●引数の場所は揃える。コーディングに入る前に引数戻り値は頭か後ろかは決めておく
意味不明。喪前はどんな言語を想定しているのか？

> ●変数名は事業部ならばJigyobuとするようにする。ヘタに事業部を英語に変換したり
> Jgbなどと略さないようにする。結局解りづらい。
いや、英語に変換できるなら変換したほうがいい。うまくクラスを使って実現しろ。

基本的に、メソッド(関数)名は動詞に、小文字を使い単語切りで2つめの単語からは間にアンダースコアを
使わずに、次の単語の頭文字を大文字にする。例、 compareTo(Object object) .

クラス名、オブジェクト名は名詞、クラス名の頭文字は大文字に。オブジェクトは小文字に。
オブジェクト名の単語区切りはメソッドと同様。

>>4
コードフォーマッタツールでインデントができる。
使え。SoureForgeに転がっている。
EclipseなどのIDEでも自分でフォーマットスタイルを指定できる。
ctrl + shift + F で自動的に、インデントされていないソースコードを自動的にインデントしてくれる。

このスレでレスしている香具師はXPも知らずなんとレベルの低いものが多いのだろうか。

>>14
お前のいっている関数やクラスもやたらに作らないは
反則。

作れ。
分割統治せよ！
リファクタリングせよ！

フラグの多用がダメっていうけど、
具体的にどういう風にフラグを使うのが、ダメなんですか？

int iFlg; // フラグ
int iLC;　　// ループカウンタ


iFlg = 0
for(iLC = 0; iLC < 500; iLC++){
・
・
・
if (条件) {

　　　iFlg = 1;
　　　break;
}
・
・
・
}

if (iFlg == 1) {

　　何か処理;

}

こんなのがダメなのかな？
俺、よく使うけど・・・

とりあえず、まずは翌日の自分が見て判るコードかな？ｗ

もしかしてブーリアンをビットフラグにマップしろって言いたいのか？

int i; // int型変数iを宣言と定義
++i; // i をインクリメント

>>21 突込みどころ満載だけど、
フラグに話題を絞ってレスすると以下
int iLC;　　// ループカウンタ

for(iLC = 0; iLC < 500; iLC++){
・
・
・
if (条件) {
　　　 some_processing(/*仮引数群*/);
　　　 break;
}
・
・
・
}

・
・
・
void some_processing(/*実引数群*/){
　　何か処理;
}

仮引数と実引数が反対ですか？

>>26 ご指摘の通りです。失礼しました。

>>21の将来のために
もっと突っ込んであげましょう。
あなたの、愛のムチで

if (0 == hogehoge){
}
って書かれているのを見ると、ムカツクよな。

if (hogehoge　== 0 ){
}
って書けよ。

またこいつか！！

http://pc.2ch.net/test/read.cgi/prog/1066100142/
http://pc.2ch.net/test/read.cgi/prog/1067396520/
http://pc.2ch.net/test/read.cgi/prog/1066221124/
http://pc.2ch.net/test/read.cgi/prog/1063009025/
http://pc.2ch.net/test/read.cgi/prog/1065497296/
http://pc.2ch.net/test/read.cgi/prog/1064884554/

>>29 恐ろしいことに、「定数==変数と書け」との規約が実在するんだよ。
(変数==定数)を(変数=定数)と書いてしまうという書き間違いをコンパイラに発見させる
ってつもりなんだろうけど。
馬鹿につける薬は無い。っていう類例だね。

0か1かのフラグならBOOL/boolで宣言して
代入はTRUE or FALSE/true or false
比較は if ( flg ) / if ( !flg ) の方向で

具体的に>1はどんなコードを書いてるの？見てみたいな

>>29、>>31

そんなに怒ることか？ポカヨケとしては有効だと思うけど。

>>34
この話題は、お前のような馬鹿をあぶりだす役に立つな（ｗ

>>35
バカはお前だ。
この手のことは、危険を回避するためにやるんだよ。
テメーができるできないとは別問題。

>>36
恥の上塗りはその辺にしとけよ(ﾌﾟ

ハンガリアン記法についてフレームするスレはここですか？

羹に懲りて膾を吹く

　これは、初心者の(あるいは熟練者でも油断した)プログラマーは代入の = と比較の == を間違う、
という伝説が根拠になっています。変数には代入することができますが、定数には他の値は代入す
ることはできません。比較の左辺に定数を書くようにすれば、間違って=と書いてしまった時に、コン
パイラがエラーにしてくれるので、変なバグが入ったプログラムを実行して致命的な結果になること
を避けられます。
　しかし、このような癖を身に付けても、比較の両辺が変数である場合には何の役にもたちません。
また、多くの人が、プログラムを左から右に読んでいきます。ある変数の値が何であるか調べる、と
いう発想があるのなら、左に変数を書いて、「もし fp が NULL なら」と考える方が自然です。「もし
NULL が fp なら」と考える人は滅多にいないでしょう。日常の言語（日本語や英語）では、主語が先
に現れますから、普段、そのような発想をしているはずです。変な順序で物事を考えると、かえって
ミスを招きかねません。個人的には、このような理由により、

if (fp == NULL)

　と書く方が望ましい、と考えます。

つーか、警告レベル上げとけよ。

またこの話かよ（ｗ

他でもあったの？

>>41
禿堂

こんなことも検知してくれないような、糞コンパイラを使う方が悪い。

何でもかんでも外部変数に押し込む奴はたいていＶＢ厨だな。


そんでもって、宣言したはいいが結局使わない変数をそのままにして
平気なのもたいていＶＢ厨だな。

>45
VBはそういう類のワーニング設定がないからなー。

ところで、>1は普段はどんな言語を使ってんだ？

>>36
チェックの手間を惜しんでたら、バグ出すよ。

>>45
自分のことですね。

言語は基本はVB
あとはCを使うこともある

>>33
仕事のソースをここで披露するのは、
いろいろと問題があるので、
また、自分個人で何か作ったら、お見せします。

やっぱ、他の人が、自分のプログラムを読んで、
読みやすい、解りやすい、って言って貰えるとうれしいよね。

ドキュメント作りはおざなりでも
プログラムがあれば、大体何をやっているかが、
把握できるような、プログラムが組めたらいいんだけど

>>21
コードの検証が面倒になるから。
5本のフラグ使った場合には単純計算で最大32通りのパターンを流す必要あるし。

一人で組んでる分には、フラグによる処理の流れの変更を把握するのは簡単
だろうけど、他人のコードに手を入れるときにはたまったもんじゃない。
それまでのフラグの状態によって影響を受けないかどうかを検証するする必要
があるし、フラグの状態を変えたい場合にはどこにどんな影響を及ぼすかをひ
たすら追っていかないといけないので。
(特に、フラグをセットする場所と参照する場所が離れてると大変)

>>51

自分もよく、フラグを使っちゃうんだけど、
フラグを使うのが良くないことは、読んでて十分分かりました。

ただ、フラグを使わないとなると、
どうやって、書けばいいのか（どういう風に書けばよいのか）、
その改善案が、思い浮かばない。

こういう書き方にすれば、フラグを使わなくても済むよ
みたいな、例ありましたら、
よろしくお願いします

> 5本のフラグ使った場合には単純計算で最大32通りのパターンを流す必要あるし。
フラグやめて他のに変えても結局パターン数は変わらないわけだが。

表現がまずかった。

＞ただ、フラグを使わないとなると、
＞どうやって、書けばいいのか（どういう風に書けばよいのか）、
＞その改善案が、思い浮かばない。

ただ、フラグを使わないとなると、
どうやって、書けばいいのか（どういう風に書けばよいのか）、
それに変わる上手い書き方が、思い浮かばない。

>>54
状況によるけど、フィルター式処理にする。
って発想をすると結構大丈夫。
なにがなんでもフラグを使わないってのはマズイぞ。
フラグのほうが見やすく解りやすいならフラグでもいい。
でも最大限努力してフラグのセットから判定、開放までの距離は短くすること。

flagをやめて固定の組み合わせを持つテーブルにする
proc_table[type]();

または
switch (type) {
case ...:
.......
}

２次元テーブル
proc_table[type_l][type_r]();
など。
状態遷移表みたいなのと対応つけやすい。

>>1
ネストのレベルは最大３。百歩譲っても４。

関数のネストも考えてくれ

再帰を使ってはだめなのか？

再帰はいいが、
A関数の中でB関数よんでB関数の中でC関数よんでC関数のなかで・・・
ってやられると頭がパンクする

そんな凄まじい相互再帰があり得るのか？

>>61
コボラーの作ったソースはそんなんです。
引数で処理されているものでないので、IOだけを知っていればという代物ではないのです。
（；´д｀）

１関数＝１機能
ってのは常識だと思うんだがコボラーさんは、
引数の値で動きを操作するように関数内のロジックがくまれているのでげす。
(;´д｀)ﾄﾎﾎ

>A関数の中でB関数よんでB関数の中でC関数よんでC関数のなかで・・・

ハェァ？普通ジャン？

関数のネストか。
これはｃの規格策定の一部にその動きがある「関数内関数」の事じゃないだろ。
決まってもいない規格について論じても仕方ないしね。
参照／被参照の関係を示す、俗に言う「プログラム構造図」／「モジュール構造図」の事だね。
まあ今のスレの空気はコード表記が話題の中心だ。
いまプログラム構造設計の方法論に話題を移すのは早過ぎると思う。
ボトムアップ的にプログラム構造設計の方法論に話題が移行したらレスするよ。

>>64
普通じゃねーな。
A（）
｛
　戻り値＝B（引数）
　戻り値＝C（戻り値を引数にしたり、なんかしたり）
　戻り値＝D（戻り値を引数にしたり、なんかしたり）
｝
だろ。

>>65
if 文のネストのことじゃないか？

普通、関数は自分の呼び出し元や自分が呼び出す関数を意識せずにすむように作るだろ。
それが出来ていないということは、関数のネストが悪いのはなく、
全体の設計がゆがんでいるのが原因では？

>>68
汎用関数ならな

処理の抽象化としての関数ならもっと特殊な前提条件があり得る

>>66
ﾊｪｧｪｧ？普通ｼﾞｬｬｬｬﾝ？

＞＞６６
おれもそうやる。
関数内関数の乱用はパーツ化ができていない証拠だな。
中に抱き込むと関数内の修正がでたときひどい目にあう。

すまん
関数内関数ってPascalくらいしか思いつかないのだが…

>>72
関数内関数はC++でもCでもできるよ。
でもここでは関数の中で関数をコールするのを深く深くやるのはやめてくれーっていってんでしょ？

ヲレも関数内での自作関数のコールネストは３を限界にしてる。
関数の中での関数コールは、関数内において小さい修正が入ると悲しいことになるし。

ソースの規模を確認しておこうか

メイン関数からメインループ関数に入って、その中で自作関数読んだらそこで終わり？

自作関数の中で自作関数を呼ぶってのを深くやってるようなやつは、関数と呼ぶよりオブジェクトと呼ぶほうがいいよ。
うちのCOBOLERも似たようなことやってる。
結果、同じようなサイズのでかいオブジェクトプログラムが大量にある。
びっくりすることに引数によっては、その中の５％くらいしがコードが有効にならないものまで（ｗ

>>71 >>73

関数内関数ってのは普通
関数内で副関数を定義することなんだが…

Googleで調べてもその意味が一般的っぽい

>>76
ちゃう。区切り目ってもんがあるやろ。区切り目ごとをサブメインととらえてそっから３つ。

　　　　　　引　数　は　３　つ　ま　で





それ以上はいろんな意味で無駄

>>80
それきっつい・・・。

>>81
そんなもんだろ

strncpy(dest, src, size);

>>77
それは、そういう設計レスなプログラムが根本原因。

英語ネイティブの感覚だと４つ以上は「たくさん」なのです。

引数三つまでとか、関数コール三つまでとか、なんつーかアホだね

なんもプログラムクメネーヨ

>>85
引数３つまでってのは Effective Java の著者も言ってるけどな
オブジェクト指向言語の場合はインスタンス名と合わせて実質４引数だが

>>73
>関数内関数はC++でもCでもできるよ。
嘘だろ。多分、お互いの「関数内関数」の認識が違うんだ。

「関数の中で関数をコールするのを深く深くやるのはやめてくれー」か。
それがそんなに嫌なのだろうか。
個々の関数が結合度が低く、強度が高ければそっちの方が読みやすいと思うのだが。
cobolのような言語の経験が長ければ「読みにくいと感じる」のは理解出来るが、慣れの問題だよ。
#今まで目撃した中で一番「深い」プログラムは、c言語で、わずか3.5ｋ行だが、mainから15レベル下までもぐっていた。

自作関数コール3っつまでってネタでしょ？

ネスト3つになったらそれからはコピペインライン展開でもしてんの？

>>87
それは >>87 の視点で読みやすかったか？
可読性のための抽象化なら許容できる

>>88
さあ？
平面展開がお得意の COBOLer が訳の分からないこと言ってるんでしょ

でっけープログラムの１０年２０年選手ものだと自作コールの３つってのも気持ちわかるなぁ。
細かい修正に修正が重なるとひどいことになる。

ネタじゃないよ。
仕様書ない、設計書ない、コメントのないのソース直すときには展開して読まざる終えない。
そうなってくると関数コール３ネスト以内ってのはありがたい。
そういうソースはちゃんと息継ぎする場所が、把握しやすいから何万ステップってやつでも
解読できる。

一回作っておしまい。って感じの仕事しかしてないならわからないと思うし、その場合はネスト３なんか考慮の必要ない。

const使えないやつは美しいプログラムなど書けない

>>92
そういうソースを書かないためのスレじゃなかったのか？

>>95
そだな・・・・。

どうもcobolerが混じっている様だな。仕様の違う言語の感覚で話をするから、噛み合わないんだよ。
>>1が「vbとc」だって言っているんで、その言語を知らないで発言しても意味が無いぞ。

どちらにせよ・・・・・・・俺も＞＞６６の書き方だな。
Aをオブジェクトとして、A関数がB、C、Dをコールするように作る。

>>92
ネストしたループをくくり出して別関数にするとお前には怒られる訳か？

オブジェクトって、どういう意味で「オブジェクト」なんだ？

>自作関数の中で自作関数を呼ぶってのを深くやってるようなやつは、関数と呼ぶよりオブジェクトと呼ぶほうがいいよ。

スゲー意味ワカンネーんですけど？

■■■　お勧めレンタルサーバー　■■■

★あなたのHPのアドレス長くて憶えられません！

【独自ドメインでホームページを作るならここ！】

Ａ：無難なサーバー。 お勧め!!　　
　http://www.webspeed.ne.jp/　　
　http://www.wadax.ne.jp/
　http://www.ktplan.ne.jp/
　http://www.wakwak.net/
　http://www.cpi.ad.jp/ 　
　http://solid.ad.jp/ 　

Ｂ：ある程度の障害は大目に。 　
　http://www.binboserver.com/
　http://s55.net/
　http://www.j-navi.com/
　http://domainya.net/
　http://www.j-speed.net/main/
　http://www.cyberjellyfish.com/

昔からある巨大プログラムを扱っている人と最近のプログラマーとの戦いだな。（ｗ

>>99
cobolerのいう関数って言うのは、ｃでいう実行型マクロに近いものだよ。おそらく。
少なくとも単体でコンパイルできるソース単位ではないと思う。
だから「展開」とかいう単語が出て来るんだよ。

自作関数ネスト3までと言ってる方の使用している言語を教えて欲しいなぁ

A->B->C->D->...........ってやつがあって
プログラム（以下P)
PA、PB、PC、PDとあってAを呼んでいる。
それぞれのプログラム毎に細かくBとかCとかの動きが変わる変更が何度も入るようになってきた。
って状態になってくると、たしかに汚れてわけわかんなくなる。

が！

そんな仕事は、もうないぞ。
パソコン化してるからライフサイクルが早いし。

>>18
>基本的に、メソッド(関数)名は動詞に、小文字を使い単語切りで2つめの単語からは間にアンダースコアを
>使わずに、次の単語の頭文字を大文字にする。例、 compareTo(Object object) .
>クラス名、オブジェクト名は名詞、クラス名の頭文字は大文字に。オブジェクトは小文字に。
>オブジェクト名の単語区切りはメソッドと同様。

この辺は単にコーディング規約にも通じてくるから押しつけがましさ全開だと思うけど？
自分のやった規約以外は受け入れられないという頭の固さは嫌だな。

>意味不明。喪前はどんな言語を想定しているのか？
Javaしか頭にないようですね。
世の中に出回ってる言語はJavaが全てじゃないっすよ。

自動ドキュメント作成ツールは魅力だし今後は仕様書＝コーディングになっていくことも解る。
Javaは色んなフレームワークがあって個人的にはとっつきにくいが.NETフレームワークにも
同じような機能もありそうだし主流になってくだろう。

しかしその裏には地道なバッチ等も走るわけで
テキストエディタでシコってるPGも山ほどいるって事で。

それから関数クラスは山ほど作りたい派かな。
小分け小分けにしたほうがメンテしやすいと思うけど。

ソース内部に加除書きのように関数でわけ隔てると
テスト等しやすいように思う

きれいなプログラムを書くために心がけるべきことは…
「いきなりコーディングしない。ちゃんと設計してから作る」
だろ。

>>109
正論

>>89 うん。
抽象化は無かったが、可読性は高かった。
資源の解放忘れを極力嫌っていて、
mallocしたら下位関数呼んでから同一関数でfree、
fopenしたら下位関数呼んでから同一関数でfclose
なんて書きかたしていた。
まあそう書けば「資源の解放忘れ」はなくなるけどね。
ネストが深くなるのも理解出来るかな。

>>109
基本はね。
ただ、設計段階踏まずに捨てプログラムを作らせても、
きれいなコードになってる奴と行き当たりばったりの
コードになってる奴がいるんだよな。

Cに関して，
どちらも中級者以上には基礎的過ぎるだろうが…

・ファイルスコープ使え
　ファイル外に公開しない関数やグローバル変数には static を付ける
・参照先を変更しないポインタを引数に取るときは const を付ける

func(const char *src, ...) ってしてないせいで，
func( (char *)"..." ); ってやってるのには呆れたよ

こんなのが職業プログラマでいることが信じられない

func(char *src, ...)
func( "..." );
これは通るけどね

>>113
>参照先を変更しないポインタを引数に取るときは const を付ける
これってANSI以降の事だよね。
俺は少なくとも初級者ではないと思うんだけど、K&Rでcを覚えた人間だから、良く忘れてしまうんだ。

>>114
gcc は通るな
警告レベルが低いのかな

SunOS の cc とかどうよ？

>>116
"string"は互換性のために、型はchar*になる。

>>117
なるほど

>>115
K&R の 2版を見たが，確かに const は付けていないな
標準ライブラリ関数を man で見れば大抵は const 付きだが

>>117
g++ でも通ってしまうのな…

constがC++から逆輸入されるまえに既に沢山のCのプログラムの中で
char *str="...";
という記述があった。これを全て変更するなんてのは無理だということで、しょうがなく"..."は非constのままとなり現在に至る。

VB使いな>1はこのレベルについていけず逃げたようだな。

>>1ではありませんが、全然ついていけません

>>123　言語仕様知らなきゃ、ついてこれるはずがない。

変な技巧に凝らずに、素直にプログラミングするのが、
一番分かりやすく、美しいプログラム。

凝らなくても十分作れるのに、
見るのが面倒で、深く読まなけば何やっているのか分からないテクニックを、わざわざ使い、
「俺はこんなテクニックを知っているんだぞ」とひけらかしているプログラマは、
DQNプログラマ

しかし、雑誌かＨＰか何か知らんけど、
どこかで見つけたテクニックを、
あえて使いたがる（必要もないのに）、DQNプログラマの多いこと。
（ウチの部署の先輩なんだけど・・・）

>>125
かといって必要以上に愚直なプログラムもDQNだよな

何事もほどほどが肝心

>>125-126
少しレベルが高い話をしているね。
どっかにも書いたけどぴったりの格言があるんだ。
「不即不離」

関数内関数だけど
前提条件がない関数なら、いくらネストしてもＯＫ。
そうでないなら１レベルでも絶対駄目ってのは当たり前？

>>113 こんなのが職業プログラマでいることが信じられない
状況はよくわからんが、他人のプログラムの単一の欠点だけ発見して、
へぼと決め付けるのｲｸﾅｲ場合多いと思う。
（特に小ネタ覚えたてのﾌﾟﾙﾌﾞﾗﾏにこの傾向が強いとおもふ）

ほんでこういつﾔｼが、
>>29 の if( 定数 == 変数 ) みたいなちょと聞きかじったｸｿﾃｸを実践してみんなをこまらせるw

関数呼び出しのコストは現在のコンパイラ、CPU
にとっって負荷がかかる処理の一つである。
それはこの部分は最適化がほとんど効かないからだ。
ループ内での5回や10回の呼び出しでは差はないかも知れないが
100〜1000の単位になると数十秒の差が出てくる。
可読性だけが全てではない。

つづき

ﾏｼﾞﾚｽすると、他のﾌﾟﾙｸﾞﾗﾏ達とは仲良くしてお互い精進するのが良いと思われ。

>>29 のやつは今では「警告レベルあげれ」で済ませられる明らかなｸｿﾃｸであることが判明しているが、
実際のﾌﾟﾙｸﾞﾗﾑはもっともっと複雑だ。
関数のデザイン方針、ファイルなど排他の必要なリソースの取り扱い方針、例外処理、並行処理 ･･･
などなど難しい問題を考えていくと、いつの間にか自分でもｸｿﾃｸつかってることが多いと思う。
しかも誰からも指摘されずに･･･。

てわけで、 >>125 もその先輩と仲良くすれ。
聞きかじった新テクは一緒に検証すればよいではないか。
たとえｸｿﾃｸでも新しいことに挑戦する意欲のあるﾔｼは長い目で見たら上達すると思われ。

129=131 ね

一応書いておこう
ttp://www.catnet.ne.jp/kouno/c_faq/c17.html
17.3より
>よい書き方は価値ある目標であるし、たいていは見ればよいか悪いかわかるが、
>文章にすることはできない。

人にｸｿﾃｸ/ｳﾙ技を濫用されても別に構わんというか気にならない
そいつに合わせればいいだけだし

それより俺は相手の趣味趣向を素早くつかむ方法が知りたいよ

>>130
ちょっとまて。嘘つくな。
わずか千回の「関数呼び出し」で「数十秒の差」？
一回の「関数呼び出し」に数十ミリ秒もかかっている計算になるぞ。
いったいどんなCPU使えばそんなに時間がかかるんだ。

↑漏れもそう思う。。
千回数十秒のオーバーヘッドのかかる関数呼び出しコストって･･･。
こんなCPU使ってたらC++やJavaみたいな高級言語はぴくりとも動かんな。

ほんでｺﾝﾊﾟｲﾗのこたよく知らないけどそんなに呼び出しコストがかかるんなら、
短い関数はｲﾝﾗｲﾝ展開されるようなｵﾌﾟｼｮﾝとか使うとえんちゃう？

130たんガンガレ（・∀・）

Z80とかZ80とかZ80とか?

>>130

確かに組み込みとJ2EEを同列に語るのは無理があるが、事情があるならコメントに明記しないとな。
パフォーマンスを考慮した結果コードの可読性が下がったら、コメントでカバーしる。これ最強。
このスレの流れも最近の言語も可読性重視の傾向が強いし。

ほんで意味不明コード書いてパフォーマンスがどうたら言うﾔｼは
パフォーマンス的にもたいしたことはしてない罠。（無意味か、逆に遅い）

最適化厨はRISCプロセッサが主流になってますます威厳がなくなったわけだが

1000回というのは少なすぎだが
1000×1000回すると10秒の差は出る。

>>141
関数呼び出しのオーバーヘッドが関数の処理のどのくらいの割合なんだ？
もし割合が高ければインライン展開を指定すればいい
もし高級車を買ったときのCDカーナビとDVDカーナビの差額…くらいの割合なら
考えるだけ無駄

100万回実行で10秒程度なら可読性を上げたほうがいいと思うよ。
ゲームや組み込みならまた話は別だが。

まぁお前さんのチーム内でパフォーマンスと可読性のバランスについて検討するといいと思うよ。
あるいはもっとマシンを強化するとか。

べつに喧嘩するつもりはないから、 >>130 のつくった神業マクロとかがあればまた教えてくれよ。
そいうのが案外Javaでも役立ったりするからな。

>>20
若いな。若いうちはやたら関数化する。身に覚えがある。ｗ
意味もなく関数だらけにして崩壊し、
２０００万の赤字で解散したとある部署のソースを見た。
まして、ただ単に分割する目的で作った関数など
ソースを見難くするゴミでしかない。
「関数」と呼ぶにふさわしい意味のある関数だけにしよう。

>>144
>>20ではないが。
文面から判断すると「ソースが見難く」なって赤字解散したみたいに判断できるんだけど、
今だかつてそんなことが原因で解散するプロジェクトなど聞いたことがない。
ので「赤字解散」っていう部署の使っていた言語名を教えてくれない？

もう一つ。「関数と呼ぶにふさわしい意味のある関数」という表現では、
「適切な粒度」が全く理解できない。
あなたが考える「適切な粒度」を別の表現で書いてみてくれないかな。

10MhzのCPUの場合。

一秒間に10,000,000クロック。
> 1000×1000回すると10秒の差は出る。
1,000,000回で10秒の差がでるとなると
関数呼び出しのオーバーヘッドは一回当たり100クロック。

// 醜悪なコードの例
if(this.foo > this.FOO && this.bar < this.BAR) {
　hoge();
}

//優雅なコードの例
if(isHait()) {
　hoge();
}

private boolean isHait() {
　return (this.foo > this.FOO && this.bar < this.BAR);
}

ミスった。宇宙ヤバイ。
- if(isHait()) {
+ if(isHate()) {

インデントを自動で付けてくれるソフトを作ってみたけどいる？
gcc、VCでコンパイル可です。
対応言語はC/C++とJava
まあ、単純に中カッコの数でインデントつけるだけなんだけどさ。

>>149
いらない。

>>147
「isHate」って単語しか可読性の向上に寄与していない。
//優雅なコードの例
if ( isHate() ) {
　hoge();
}

private boolean isHate() {
　boolean FooOver = this.foo > this.FOO;
　boolean BarOver = this.bar < this.BAR;
　return FooOver && BarOver;
}

>>151
この醜悪な言語は何？

>>150
(´･ω･`)ｼｮﾎﾞｰﾝ
生徒の提出課題を読みやすくするために10分で作ったソフトなんだけどね。
大学の非常勤講師やってます。

宗教戦争が勃発しそうなスレはここですか？

>>153
Winの方は知らないけど、
gccが動くunix環境ならcbとかindent（こっちはすごい）
っていうコマンドがすでにあると思うぞ。

>>154いいえ。
cobolerがcobolの感覚でレスして、「ずれてる」とか言われるスレです。

>>155
そんな便利そうなコマンドが。。今度調べてみます
Win一辺倒だったので、UNIXは詳しくないんです。

>>151
関数の中が糞かと。

>>158 うん。おれも書いてて「クソだな」って思った。

はてさて

ふむー

>>160,161
『できるかな』の歌をこんなところで書くな！！

>>160
>>161
「はてはてふむー」じゃなかったのか！

はてはてはほー

かと思った

ルールなんてどうでもいいよ。何か規則を決めてそれを
守って書いていれば自動的にきれいになると思うのがそも
そもの間違い。プログラムは何度も読み返し改良してこそ
美しくなる。いくら入念に設計したって、一回書いて終わ
りでは絶対に美しいプログラムは書けない。

たとえるならダイヤモンドのようなものだな。指輪に乗っ
ててるダイヤは非常に美しいが、ダイヤモンド鉱山からい
きなりそれを削り出すわけではない。まず原石を切ってき
て、それを少しずつ磨いて光沢を出す。プログラムもその
ように書かなければいかん。

最初のデザインに失敗すれば全て台無し

>>145
依存関係が多過ぎるとかえって困るぞ。
例外が出る度に依存関係の全てに対応すべくパラメータがどんどん増えて、不用に複雑になる。
挙句の果ては変なマイナーバージョンみたいな「なんとか2」みたいな名前の関数が羅列されたりぐちゃぐちゃ。
例の部署は、ＶＢＳｃｒｉｐｔ（ＡＳＰ）。１２０画面ぐらい。
関数のせいで解散したわけじゃないけど、客が怒ってて赤字状態で、
設計書不備は基本的にはあるまじきことだが、なくても作った本人ならデバッグぐらいはできるでしょう。
だがそれもできんというゲームオーバーな状態だった。
まあ彼らは低次元かもしれんが、それを見て思ったこと。
「なるべく関数化」という文言がセンスのない人にブレーキもなしに届くとエライことになる。
１．たとえ数年後に、あるいは他人が見ても動作を把握するのに困らないこと。
２．関数のカスタマイズ時に、それに依存してる全ての部分で絶対に矛盾が生じない自信があること。
　　また、カスタマイズするとすれば関連する全ての部分が全く同じく変更されるべきものであること。
４．「長いから切り出す」というだけの目的で一ヶ所でしか使わない関数を作らないこと。
　　あとで気持ち悪いパラメータを増やさざるを得ない場合があり、意味不明度が高くなる。
５．できるだけ一般的な概念でネーミングできるものにし、専用動作し過ぎる関数は作らないこと。
６．関数化したいがためにいちいち回りくどくなりそうならやめること。
う〜ん・・他にもあるかもしれないけど、要は経験とセンスだろうけどね。
例えば、有効桁数で丸める関数なんかは汎用としてカプセル化してしまった方がいい。
しかしＪＩＳ重量を計算するような関数は、今回の業務専用ということで、
今回の業務専用だけを集めた場所に保管する。
もっと今回限りの専用なものは、繰り返し別の場所で使う場合に限りなるべくひっそり関数化する。

2ch見てるとデキの悪い奴って結構いるんだなぁ〜って思う

あーたのむ　誰か暇な奴、上のレスを箇条書きかなんかでまとめてくれ
そんで、出版しよう　みんなで小金もちになろう(　￣ー￣)

【解り易い】上手なプログラムを書くには【美しい】 by マ板の皆さん
出版社　2ch出版

>>147>>151
あー！これ！
こんなことでいちいち関数化するな。
少なくとも受託開発では>>147の最初の例が正しい。
設計書の書き方によるけど。
なるべく業務要件の定義をそのまま反映した形で書くべき。

優雅なコメントの書き方をご教授願いたい。

>>172
/* 20031105 これからマキシムでお食事なので今日はここまで */

関数型言語一回使ってみろよ

>>167
あなたの説明するプログラム設計は制御結合（control coupling)と呼ばれる悪い結合度を持つ設計だ。
確かにこのような設計は「>依存関係が多過ぎるとかえって困るぞ」という弊害が発生する。
>「なるべく関数化」という文言がセンスのない人にブレーキもなしに届くとエライことになる。
支持。まともにプログラム設計できない奴にプログラム設計させておいて、その技術レビューもしていなかった。
という技術管理上の失敗だね。全く関数分割しない方がもっとましな結果になったかもしれない。
しかしこれはあくまで「技術管理上の失敗」であって、「関数分割が悪」ということにはならない。
「全く関数分割しない」と書いたが、そうしたら成功したと思うか？重要なのは「正しく設計すること」なんだ。

>>171　うん。そうだね。
最後の2行は全面的には同意できないけど。
「設計書」ってどのような内容の設計書を意味しているのかな？

>>172
コメントか。コメントを重視する人と軽視する人がいるね。俺は後者だけど。
優雅かどうかわからないけど、
「コードに表現されている情報ではなく、人間寄りの情報をコメントしろ」
というのはどうかな。

>>175
そりゃそうだよ。全く分割しないとは言ってない。
>>14で「やたらに作らない」と言ってるのは、「やたらに」が重要。
問題なくエレガントに分けられる人がいたらそれに越したことはない。
逆に、要件定義的にも一括管理されるべきなのに分散してるのも有罪。

>>176
例えば製造業で、その会社で言う「製品の完成条件」なるものがあって、
その条件が結構複雑で、あらゆる個所で登場する場合、
そんな時は設計書に「製品の完成条件」について説明があり、
他の紙面ではそのキーワードを使って説明されることだろう。
そんな時は、「IsComplete(OrderID)」等の関数で一括管理される。
（この場合はＤＢサーバ上のストアドで作られるだろうけど）

>>179
了解しました。確かにそのような場合、（アプリ側でその判断を行うときは）
c言語ならライブラリ化、javaならstatic修飾子(だったかな)をつけて、
「一箇所で行う」という方法を選択すべきですね。

Cで関数の引数に、
/* (IN) */
とかいちいち書くんじゃなく、 const 付けろ。

値渡しの変数に const 付けるのはアホらしいしな

>>171
いいや。それは違うね。一瞥しただけで理解できない条件文は、
すべからく関数にしたほうがいいね。
そもそも、「もしホゲホゲしたとき」って仕様書書いてあるわけだろう？
そしたらソースにも、isHogeHogeって書くべきだと思うね。
もしそうしないとしたら、「仕様書に反している」とさえ思うよ。

>>179
if(isComplete()) {
　hoge();
}

というソースを

if(ManufactureProgress.isComplete()) {
　hoge();
}
に直すのは簡単だ。それが「完成を判定する」部分だということが一目瞭然だから、
一箇所で判定を行うようにするための変更はとてもとても簡単だ。

でももし下みたいな条件文を修正する羽目になったら？

if((((s+(u++/8)).length%2>1))&&((u/4)%2>0)) {

背筋が凍るね。

>>183
それは何カ所からも呼ばれるからだな

値渡しの変数はそもそも
/* (IN) */
なんて書く必要すらない

>>185
そうだな

>>183
結局、呼ばれた関数で条件文を書き下すわけだが。

built in typeにconstをつけると馬鹿呼ばわりされるぞ。

引数で値を戻すときはretとか書かなければならない仕様だったら良かったのに。

>>168
同意。なんで制御結合みたいな設計するのかなと思ってググッて見たら、なんと情報処理２種（今もそう呼ぶのかな）レベルの知識じゃないか。
呆れたよ。
#情報処理試験も様変わりしたもんだ。

だから情報処理技術者試験を受けろと。

スレタイトルの「わかりやすい」と「上手」と「美しい」って
必ずしも等価とはいえないと思うが、そこらへんどうよ？
（すべてを満たすプログラムがないとはいわないが）

たしかにジョーズは美味いとは思わない。

誰もオブジェクト指向には触れないのか？

>>194
スレの方向とは微妙に違うからね。

>>192
「わかりやすい」
これが再優先

「上手」
これは良くわからないんだ。
「わかりやすさを損なわない」でかつ「簡潔」かなあ。

「美しい」
形態は機能に従う（Form follows function）。だね
日本刀や名高い拳銃みたいに高度に機能的なものは美しい。
問題は「プログラムが機能的であるとは何を意味するか」なんだ。
おそらく品質のことなんだろうが、品質ってのは、それを判断する人間によって何を重きに置くかが違うわけ。
例をあげると、おれは「わかりやすい」ってのが一番重要だけど、
ユーザにとって見れば「わかりやすい」なんて特性は全く意味がない。
「自分が読んで美しい」と思ったら美しいことにしよう。という辺りで思考停止しているんだ。

「わかりやすい」 「美しい」
読み手のレベルによって異なる罠

そうでもないよ。

書き手に、読み手としての経験がないと、なにがわかりやすいかを正しく判断できないというのはあると思う。
変数全部にコメントつけろとか……。

>>197
日本語でビジネス文書を書くことを考えてみろ。
読み手の思考に多少は左右されるが、
・理路整然としている。
・無駄がない。
・要点がはっきりしている。
という要件を満たしている文章は、
一般に「わかりやすい」「美しい」とされる。

段落、見出し、図表、箇条書きなどの手法は使えるが、
書き手によって読みやすさは大きく変わるだろ？

例)
・書き物に慣れていない香具師が見出しを多用しても読みづらい。
・新聞記事は、文章だけでも十分にわかりやすい。


プログラム言語も基本的には同じ。
理路整然と書かれたプログラムはわかりやすい。

オブジェクト指向も、構造化、関数化などの手法も、
プログラムを理路整然と記述するための手助けでしかない。

その言語がサポートしている方法を使い、
理路整然としたプログラムの記述を行うことが肝要。

記述レベルでとやかく言うのはその後だろ？

上で早さがどうのこうのって話しあるけど、そういう事ってデータベースアクセスとかの
あたりでは考えた方がいいけど
通常のコーディングでは全く考えない方がいいよね。
見てわかりやすいソースだったらいいと思う。
今のCPUだとその辺の差なんかほとんど出ないだろうしね。

関数化の話だけどIF文の中まで関数化はあんまりしないなぁ。
ただ呼ばれる初期処理の関数の中では
初期処理ではどんな事をするのかを箇条書きついでに関数化。

初期処理では主にこんな事やってまーす。というのが解るようにする。
単に２、３行のソースだったとしても関数化する。
データアクセス、ｲﾆファイル読み込み、コントロール設定、初期表示
等
汎用的でなかったとしても大まかに細分化する事でコードは読みやすくなるし、テストがしやすくなる。

「わかりやすい」ってのが曲者だな。
英語が日本人にとってわかりやすいかというと、習得できない者が多いことから、わかりにくいものなんだろう。
だがアメリカ人にとってはわかりやすいし、英語はアメリカ人にとってわかりやすければいいのだ。
プログラムも「わかりやすい」ってのがいいからといって初心者にまでわかりやすいコードを書く必要はない。
ある程度修練を積んでプロのレベルに達した者に、わかりやすければそれでいいのだ。

gotoを使うべきところでは使う。

bool ishoge(const int & num) { return ( 0 >= hoge && hoge >= 9); }

値綿しな引数をなんとなくconstな参照とかにしてみたり。

あとclass定義の ; の付け忘れを防ぐためにも関数の終わりとか
ifとかの{}の後にも ; をつけてみたり。

VBむずい、読めない意味わからない
助けてください

うつくしさだけなら、コピペで作ったスイッチ文とかいいよね。
スクロールすると波打つように流れる。ｗ

かといって、「見た目の綺麗さ」にこだわるあまり、わざわざ無駄な変数を宣言して
そこに代入しなおしたり、変数名を英語のしかも省略形に押し込んで、知らない
者にはちんぷんかんぷんな状態にしたり、そんなのに終始しだしたら本末転倒だよね。

>>205
Java/C/C++/C#/Perl/Ruby/PHP/DOSバッチファイル/JScriptなら助けられますが、
混沌の申し子たるVBを助けるのは無理無駄無謀というものです。

素直に勉強不足で知りませんと言えよ。

混沌の申し子といえばPerlでしょう。

VBは融通が利くようで利かないところが多すぎるからな〜
ユーザー定義型の変数を引数としてForm内のプロシージャに渡すことが
出来ないってのは結構ショックだった。
それでグローバル変数に逃げてしまうのも嫌なんだけどねぇ。

Friendプロシージャ、もしくはレジストリに登録された
(参照設定して使えるようになる)ユーザ定義型なら無問題。
それに構造体が無いJavaのようにクラスを使えばいい。
グローバル変数に逃げるのはただの馬鹿。
やっぱり勉強不足なだけか。

　∧||∧　　精進します……

>>191そうではない。「勉強しろ」と言いたいだけ。
二種なんかの試験に出てくる知識ってのは、
技術者として知っていて当然だと思うから。
#知識が血肉になっていればもっといい。

>>211、>>212
その辺りの話はVB5、VB6、VB.netで全部仕様が違うから。

VBは本気で難しいと思う
互換性って意味を真っ黒ソフトさんが知ってるなら
若干話は違ってくるが

>>201
早すぎる最適化は諸悪の根元だと Knuth 先生が仰いました
あと Jackson 先生は
素人は最適化するな，専門家は明らかに最適化されていないと分かるまで最適化するな
と仰いました

小手先の最適化よりも設計段階で効率の悪いアルゴリズムを除くべし

・改行は絶対入れない
・コメントは行頭に書く　例：for /* forです。 */　(int i = 0 /* 初期化です。*/; ; )
・細分化しない、全部コンストラクタだけに書く
・必ずユーティリティー関数としてじゃんけんを入れる
・変数名はエクセルを見習い、A1・A2・A3〜で統一する。
・型を差別しない、平等に扱う。定数だけは配列にする。

こんぐらいかな？

>>217
アルゴリズムうんぬんよりも、まずは最適化するべきかどうかの見極めからだな。

２０代の若者には分からないかもな。脳が若いから。
３０近くになって、記憶力や同時に把握できる量や体力や目が弱くなってくると、
それでも把握できるソースが欲しくなる。

>>217 作る前の話だよね
>>219 作ってから、アプリ側にレスポンスのボトルネックが発生したときのはなし？

>>220
で、まだ書いているの？だったらわかりやすいコードだろうね。
それとも、書いていなくて、部下のコードに文句をつけているだけ？
だったら部下が設計する前に「指針」を渡さなきゃ駄目駄目だよ。

最適化だってよ
おい
笑わせるな〜

>>49
> 言語は基本はVB
アフォか。VB厨はこれだから。
しかもこのスレを立てた>>1はオブジェクト指向もeXtreme Programming
もrational unified Processすらも知らない時代遅れのクズだということが発覚した。
出直して来い。

>>61
> そんな凄まじい相互再帰があり得るのか？
相互再帰はCompositeパターンの常識

>>222
書いてるよ。
２０代前半の時のソース見ると宇宙人が書いたのかと思う。
超パズルになってて自分で理解できない。
当時は５００行ぐらいのファイルを３０個ほど頭に入れた状態でできたらしい。
今は１個のプロシージャさえ頭に入りきらない。ｗ
だからちょこまかコメント書いたり、関連するものが離れたところに行かないようにしたりする。
空白行の入れ方にも必死になったりする。

>>224
粘着は恥ずかしいよ。下らん思い込みもほどほどにな。

VB厨が粘るな

>>207
＞わざわざ無駄な変数を宣言して

おまいに無駄に見えるからといって、そいつにとっても無駄かどうかはわからないよ。
日本人にとって母音が１１個もある英語は無駄に見えるよ。日本語は母音が５個だから、残る６個はまったく必要ないものだ。
だがアメリカ人にとっては母音は１１個必要なのだ。
何が無駄で何が無駄でないかは、そいつの生活習慣や発想のパターンによって違うよ。

>>74
> ヲレも関数内での自作関数のコールネストは３を限界にしてる。
> 関数の中での関数コールは、関数内において小さい修正が入ると悲しいことになるし。
お前にその程度の考え方しか持っていないことが、お前がオブジェクト指向をいかに
学んでいないかということを示す証拠だ。

オブジェクト指向を学べ。少なくともパターンを学べ。
少なくともデザインパターンを学べ。少なくともGOFデザインパターンを学べ。
少なくともDecoratorパターンを学べ。その程度のネストは常識であることがすぐにわかるであろう。

以下に例を示す。


BufferedReader reader =
　new BufferedReader(
　　new InputStreamReader(
　　　new ZipInputStream(
　　　　new FileInputStream(
　　　　　new File("string.txt")
　　　　), new Charset("UTF8")
　　　)
　　)
　)
);

>>81
> >>80
> それきっつい・・・。
複数の変数をひとつのオブジェクトに集約(Aggregation)すればその程度のこと朝飯前。
オブジェクト指向を学べ。
こういう技もある。
たとえば、
execute(BigInteger x, double realNumber, double imaginaryNumber)
こんな関数があったとして、なんとかまとめたいとき

ArrayList arrayList = new ArrayList();
arrayList.add(new BigInteger.valueOf(100));
arrayList.add(new Double(100));
arrayList.add(new Double(-50.1d));

また、double realNumber, double imaginaryNumberのぶぶんが複素数である場合、
複素数をクラスとして自作するのが手っ取り早い。

public class Complex extends Number implements Comparable {
　private double real;
　private double imaginary
　pulic Complex(double real, double imaginary){
　　this.real = real;
　　this.imaginary = imaginary;
　}

　//以下略
}

こいつ使ってexecute関数を再定義するのだ。
execute(BigInteger x, Complex complex);
どうだ？　引数の数が減っただろう？

オブジェクト指向の常識だ。


それより、このスレにレスしている奴はなんとオブジェクト指向を知らずに
効率の悪いことをやっている奴が多いことか。

>>107
> >基本的に、メソッド(関数)名は動詞に、小文字を使い単語切りで2つめの単語からは間にアンダースコアを
> >使わずに、次の単語の頭文字を大文字にする。例、 compareTo(Object object) .
> >クラス名、オブジェクト名は名詞、クラス名の頭文字は大文字に。オブジェクトは小文字に。
> >オブジェクト名の単語区切りはメソッドと同様。
>
> この辺は単にコーディング規約にも通じてくるから押しつけがましさ全開だと思うけど？
> 自分のやった規約以外は受け入れられないという頭の固さは嫌だな。
>>13も十分に頭が固く押し付けがましいが。
自分のやった規約とかではなくこれは一般常識。
自分しか読まないようなコードなら好き勝手にやってもいいが。
できる限り規約に従ったほうが可読性は高まる。

> >意味不明。喪前はどんな言語を想定しているのか？
> Javaしか頭にないようですね。
> 世の中に出回ってる言語はJavaが全てじゃないっすよ。
だからどうした。
それより「引数戻り値は頭か後ろかは」とはどういう意味か

> 自動ドキュメント作成ツールは魅力だし今後は仕様書＝コーディングになっていくことも解る。
> Javaは色んなフレームワークがあって個人的にはとっつきにくいが.NETフレームワークにも
あれでとっつきにくいならプログラマは向いていない。

> しかしその裏には地道なバッチ等も走るわけで
> テキストエディタでシコってるPGも山ほどいるって事で。
きみは何がいいたいのかよくわからないのだが。
テキストエディタを使うのは常識だろ。

>>109
> きれいなプログラムを書くために心がけるべきことは…
> 「いきなりコーディングしない。ちゃんと設計してから作る」
> だろ。
だが最近のソフトウェア開発ではコーディング後に設計、
コーディングしながら設計することも常識になってきているぞ。

ウォーターフォールモデルを捨て去れ。
スパイラル開発を学べ。
反復型開発を学べ。
アージャイルな開発を学べ。
Rational Unified Processを学べ。
eXtreme Programmingを学べ。

>>144
> >>20
> 若いな。若いうちはやたら関数化する。身に覚えがある。ｗ
> 意味もなく関数だらけにして崩壊し、
その問題を解決するためにオブジェクト指向というものが生まれたわけだがw

>233
「一般常識」ではなくて、それはsunのjavaのコーディング規約だろ。
世の中に数多あるコーディング規約は大方これに準拠していることは認めるけど
準拠していないコーディング規約の不在が確認できない以上、
それを「一般常識」と断言するのは言いすぎではないか。

>>236
> >233
> 「一般常識」ではなくて、それはsunのjavaのコーディング規約だろ。
Smaltalkの規約もJavaとほとんど一致しているぞ。

>>236
>世の中に数多あるコーディング規約は大方これに準拠していることは認めるけど
おいおい、それを一般常識といわずして何と言う?

>>233
なんだ、唯のプログラム厨か。

>>234
学んでどうするのかな？

>>235
オブジェクト指向と、そうでないプログラムの違いをもっと勉強しよう。

>>231
技を使う必然性と、メリット･デメリットも考えよう。

>>231
>execute(BigInteger x, double realNumber, double imaginaryNumber)

>ArrayList arrayList = new ArrayList();
>arrayList.add(new BigInteger.valueOf(100));
>arrayList.add(new Double(100));
>arrayList.add(new Double(-50.1d));


どっちが解り易いプログラム？前者だよね。

>>235
その前の>>14にはクラスについて触れてるよ。
関数にしろクラスにしろ同じことで、
安易に作るとボロボロになるというのは当然だと思うが。
クラスにすべきような複雑なものを無理に関数で作ると、
WinAPIやPHPのDB関連関数のように使い辛いものになるのは当たり前のことで、
ある機能をクラスにするか関数にするかの選定は特に問題ないと思う。
問題はクラス、関数ひっくるめて何を共通機能として分離するかという次元の話だと思う。
引数を構造体にしても、その要素の選定や名前はやっぱり整理しなければならないし。

…
honya.excute(this);
…
public void excute(Hoge hoge)
{
this.x=hoge.getX();
this.complex=hoge.getComplex();
…
}
きっちりとgetterを使うのが正しい

>>234
＃ひょっとしたらだいぶ前にもアナタとワタシは同じような問答をしたかもしれない

もうロートルなんで付いていけてないのかなあ。
「いきなりコーディング」っていう感覚がつかめない。

XPの実施例を読んでもペアプロしながら「これをこういう風に」って
計画を立ててレビューしながらコーディングしているように見えたよ。
その前に「計画ゲーム」だってちゃんとやるのだろう。

反復っていえば>>165も大事だね。

>WinAPIやPHPのDB関連関数のように使い辛いものになるのは当たり前のことで、

こやつはカーネルハックなんて言葉も知らないだろうな。

コメント行に顔文字をふんだんに散りばめる香具師がいるんだけど
おかげで誰がコーディングしたのか一発でわかる。
ワーク領域(￣ー￣)ﾆﾔﾘ、　処理成功（*゜ー゜*）ｂ　など・・

でも、そいつの技術、開発速度共に凄いから誰も文句は言わない。

>>231
それはバグの温床になるのでは？
(スーパープログラマーだけで作ってるのならかまわないだろうけど)

凡人が考えると、変数が３つで済むような場合、変数が５つ必要と考えるのが、一流のＰＧ。

つまり5/3の法則よ。
凡人が考えると、処理に必要なステップ数が４の場合、天才が考える必要なステップ数は７。
凡人が考えると、必要な関数の数が８の場合、天才が考える必要な関数の数は１３。
凡人が考えると、コーディングに必要な行数が１１の場合、天才が考えるコーディングに必要な行数は１８。
天才は頭の構造そのものが複雑だから、そうなるんだよ。わかるかな？

すいません、>>231-232 が非常に香ばしいんですが。
OOP を単なるテクニックだと思っているんだろうか…?

>>231
OOPは現実に則しているからうまくいくのであって
小手先のプログラミング技術を駆使することでうまくいくわけではない

つうかXP厨うざい。
こういうのって、入社３〜５年目で新規の案件しかやったこと無いからだろうね。

世の中理想を持つのは大事だけど、理想の環境が必ずしも実現できるとは思うな。
そのときこそ、その人の本当の力が試される。

なに言ってんだか。

新しいことを覚えたくないｵｯｻﾝ必死の遠吠え

>>254
全くだ。俺はOOP厨もうざい
自分の知識を披露したいがために、「ずれた発言」を拾ってきてレスつけてるやつが何人かいる。

>>254
いやぁ、231あたりは複素数を例題としてたりするので、業務経験ないのではないかと。

>>258
学生だとしても研究の経験もなさそうだしね

なんだよ おまいら
学生にまけてんじゃん
ぷっ

勝ち負けって・・・、XP厨、OOP厨の彼が、それを受け入れないプロジェクトに参入したときに
どのように振舞えるかが知りたいけど。

まあ、止めるんだろうね。青臭い。

>>260
研究経験もない学生が吠えてるだけ
説得力の欠片もないよ

「いきなりコーディング」
賛成。でもそれが出来る奴だけに許可してくれ。

>>262
どこに研究経験もない学生が？
ノイローゼですか？

>>264
まぁ熱くなるなよ

>>265
そういうセリフは>>262にいいなよ。

学と業 両方持ち合わせたやしはいないっつーことですかね。

所詮は理系じゃなくて工学系なんだからさ。
業に適わなければ学もへったくれもない。

というより、ここのXP,OOP厨は学としても厨房レベルなのが問題では。

>>269　そだね
特に、学のXP厨なんてその存在すら認められない。
実践抜きで、書籍からの知識のみでほざいてるってことだからな。

このスレの流れ

COBOL厨の台頭 -> COBOL厨あえなく撃退 -> OOP,XP厨の出現 -> COBOL厨の反撃

COBOLとOOP,XPしか習ったこと無いというのはかわいそうだ。

COBOLのことは知らんが、基幹業務用データベースシステムの
テーブル設計におけるOOP,XPってどんな感じになるの？
「オブジェクト」ないし「モジュール」と呼ばれるものごとに
ばらばらに独自のデータベース持つの？
昔、SE不在で営業が打合せ→PGがそこまで作っては見せる→フィードバック
という無茶な方法でやってたことがあったけど、そういうんじゃないよね。
テーブル設計なんて、客のたった一言で根本的な構造が変わる場合があるから、
徐々に部分的に作るなんて無理だと思うけど。
溜めた膨大なデータは高速に検索・集計される必要があるので、動けばいいというものでもないし。

１０進数（小数）の２進数への基数変換はなぜ２をかけて１越したのを拾ってるんですか？
理屈は分かるんですが、聞いた人がなるほどと思うような面白い例えを使って説明してください。

>>274
気に入らないなら２分の１で割ってもいいよ。

>>273
まずはオブジェクト指向から理解しろ

素直にここみたら？

ttp://www.pro.or.jp/~fuji/mybooks/cdiag/index.html

>>274
2進数（小数）の2進数への基数変換は2をかけて1越した(?)のを拾えばよいから。

XP厨はXPをやるように上司や教官を説得する能力もなければ
遊びでペアプログラミングする友達もいない

>>279
ＸＰはコンサルティング・設計のできないニセＳＥ等の上司と言われる人が楽するためや、
納品等の責任のない教官がカッコ付けるためにあるものでそ。
ＰＧは何度も来る無計画な変更で大変になるはずだ。

>>233
うわー粘着。こわ。

>> Javaしか頭にないようですね。
>> 世の中に出回ってる言語はJavaが全てじゃないっすよ。
>だからどうした。

Javaが初めて学んだプログラムなんだね。これで大体歴が３年程度ということが発覚したなぁ。
先走りｺﾞｸﾛｳだよ。ほんと。

>それより「引数戻り値は頭か後ろかは」とはどういう意味か

あのね、Javaみたいな言語とは別にpl/sqlとかバッチ系のpgもあるわけ。
上からだだ、っと流れるようなね。
処理がうまくいったかいかなかったかを戻り値で戻すような関数の場合は
その戻り値を第一引数にするのか、それとも最後の引数にするのかという事。場所をきめておくってこと。
できれば変数名も。
例外で頭飛ばしするのはメンテがしにくくコードが見にくいという事で戻り値での判断が個人的には好きなので。

まぁJavaやってっとビジネスロジック部分でさえ部品部品でsqlの一本も書けなくなるからねぇ。
ＭＱだのどこぞの誰さんが作った怪しいデータアクセスクラスだの。
個人的にはJavaもVB.NETも金が安くデジドカになってく気がして嫌い。
DB回りが一番楽だね。

>>233
君はもっと色んな言語をやったほうがいい。あ、一応Javaも.NETもやったからね。俺は。

けっこう面白そうなスレだと思って見ていたが
やべ、ねみぃ。

新人のころにはみんな通る道だ
熱く語れ！！
それにしてもレベルが低いぞ
がんばれよ！
みんな！！

>>280
嘘つくな。俺はXP厨のつもりはないが、お前の言っていることは滅茶苦茶だぞ。
WaterFallマンセーか？

プログラムのスレで、プロセス方法論のXPの事を持ち出す理由を述べよ。

>>285
それをいうなら、OOPも同様だ。
OOP言語を使ってない奴もいるんだからOOP言語用の別スレ立ててそこでやって欲しいよな

>>281
>例外で頭飛ばしするのはメンテがしにくくコードが見にくいという事で
>>281例外処理も理解できない無能だってことはよくわかった。
だからpl/sqlの古臭い風習をJavaに持ち込むのだけは勘弁してくれ。
try {
　connect();
　insertHogeTable();
　insertFooTable();
　updateBarTable();
　commit();
} catch (SQLException ex) {
　rollback();
} finally {
　deconnect();
}
例外を使わずに、これ以上解り易いコードが書けるか？ ん？

>>286
OOP知らないなら、OOPの話題が出てるうちは黙ってるか、
自分が知ってる非OOP言語の話題を振ればいいでしょ。

自分が理解できないことだからって別スレに追いやる必要は無い。
そんなことにも気づかないあなたは、典型的COBOLerですね。

>>287
>>286
いつからここはjavaのスレになったんだ。

>>288
＞OOP知らないなら
「知らない」と書いたか？
＞自分が理解できないことだからって
「理解できない」と書いたか？
＞典型的COBOLerですね
COBOLなんかしらねーよ。

俺はSTPがOOPの基礎だと思っているから、
STPもまともに理解せずに、一足飛びにOOPに飛びついた香具師らの
書くクソなOOPコードを見たくないだけだ。
そんなクソな香具師ほど沢山コードをさらしやがる。

>>287
質問
connect()メソッド参照時のｄｂコネクションクラスの明示的な取得
各種insertメソッドやupdateメソッド参照時のデータ
などは隠蔽されている様だが、なぜか。

>>281
>>>233
>うわー粘着。こわ。

お前も十分粘着じゃん。

>>290
理由１．普通はスーパークラスに変数やメソッドが
　　　　定義されているだろうという常識的前提。
理由２．例外処理の素晴らしさを伝道するためには、
　　　　レスの行数が多くなるのは不都合だった。

>>287
closeはdeconnect()に隠蔽されているのか？

disconnectだろーが、ハゲ

>>293
もちろん。
しかしコネクションの取得、開放には何通りもやりかたがあるから
明示は避けた。
例えば、closeせずに、コネクションプールに戻すだけかもしれない。

protected deconnect() {
　ConnectionPool.getConnectionPool().release(connection);
　connection = null;
}

あるいは、単に別のクラスからsetConnectionされていて、
deconnectでは何もする必要がないという可能性も有り得る。

protected deconnect() {
　// このクラスにコネクションを設定したクラスで、
　// 責任を持って開放しなければならない。
　connection = null;
}

>>294
間違いを指摘していただきありがとうございます。
おっしゃるとおり、正しくはdisconnectでした。すぐにメソッド名を右クリックして
リファクタリングしますから少々お待ちください。

終わりました。
5分と手間のかからない変更作業ですが、何ら問題ありません。

30分以上かかってるぞ。

抽象的だけど、俺が気をつけていること。

・わかりやすい、うつくしいを自分で決めない

・自分が書いたコードに関して他人が質問に来たら、
そこに"わかりにくさ"があったと考え、どうすればよかったのかを考え今後の参考にする。

・たとえ後輩でも、わかりやすくうつくしい記述があれば
それを賞賛し自分も利用する。

　　∠二ミ:::::://　 ...::::::ヽヽ、
　　r'r'´..::::::::ヽr‐､'､..::::::::::::::/ rl].　　　　　　　>>297
　　||　...::::::::::/ | l::ヽ､`ー‐'´ノ:ヽ
　 r' ヽ､___／ ∧::ヽ;::::::i「:l「::ヽ::::',　　　　　　　　　　　　　　　　_＿
　 |iTｰ--r‐'´ ヽ:､ヽヽ:::l|::|ヽ:::ヽ:::!　三|三　　∧　　└┼┘　　／
　 |::}:::/|:|:|　　　 ヽ 　 ヽ!| ! ヾ;:::|::| イ `＜　/　 ＼　|＿|＿|　 ´⌒)
　 |.:.!/:|::|l:!　　　　　　 -彡-;､ﾘヽ:|　￣　　　　　　　　　　　　　　-'
　 |.:.||:::l::|ﾘ''テ=ﾐ　　　　ﾍ:;;;ﾉ　|:::|:! 　
　 |!.:|:::::l::|ハ::;;:ﾉ　　　　　 ::::::: |:::|:!
　 .!|.||;:::l::|､:::￣　　　,　　　　 /川| 　 __ , -''´i￣￣｀ﾞヽ､
　　 |!ヾ!:l:Lヽ　　　　 _...,　 ／ﾘ:/!|　/／へ|ﾚ^ﾚ彡　　　　｀ヽ,--､
　　 !　 lﾊ::!　｀''ｰ- ､.`´ イ　　_ 　 ////　　　　　 | |　ヽ　　 ヾﾐ ヽ
　　　　　 , ---､ __ﾉ　　 l⌒Y|　 V/ //　　　　 　 ヽ! 　 |　!　 ﾊ| ||
　　　　 /　　　　 ､　 　 / 　 |＼ || ! /　　　　　　　 ヽ　 l| |彡/ | ||
　 　 　 | ＿＿、　 ￣ /　　/ヽ(.)! | | ＞=､　　　　-＜!　| |/ //| ||
　　　　/: : : : : ヽ　　 / 　 / 　 /|| | | ! |::::'!　 　 　 /::Lミ||ﾚ// l| ||
　　 　 {: : :r'´--ヽ=:/　　/ 　 /７|| |.|ﾞ! L::ﾉ　　　　 L;;ノ ||ﾘｸヽ.l| ||　 .l⌒!
　 　 　 |: : :／: :__／　 ､ '　 /-r'┴､!||:::: 　　,　　　::::::::　| |!).ノ|| ||　 /　/
　 　 　 ト|: : : /:ノ　　 　ヽ､ ﾚ'′ /ハ|'､　　　　　　　　 //'´　 ||Ll／　/
　 　 　 |: :Y: : /　　＼　　　!　　/l/: :||　｀ﾞ - ﾟ..＿_,.ィ´//＿,--'´　 ､,/
　 　 　 L; :|: : }　　　　＼　 l 　 | !: : ∧　 ,. --|　／/〃:r'´　､　 ＼ ヽ
　　　　　 ト|: :.|　　 ＼　 レ'　 /: :: : {〃⌒l Lr'￣｀ヽ |:::|　､　 ヽ　　〉ﾉ
　　　　　 |:ヽ: |　　 　 |　/　,ｨし!: : : ||...::::/r､| ....:::::/ ﾊ::| ｀Lヽ　ﾚ‐<
　　　　　 ヽ ヽ|ヽ、　 .し'r<ハ!: : : : :|トニノ　ヽニニ人ヾヽ､ ￣　 >'′
　　　　　　∧ ヽ::::`ー‐': : 人: : : : : :|　|/::::::::::::::::::::::::::｀ﾞ´:::::r`ｰ'´

・俺の書くコードは常に美しい。
　「先に言っておくが、俺ぁパーフェクトだぜ？」
・自分が書いたコードに関して他人が質問に来たら、挑発する。
　「センスが違うんだなぁ・・・センスが」
・後輩が美しいコードを書いたら、敬意を払う。
　「アンタなかなか・・・グレイトだぜ・・・」

>>284
WaterFallはＳＥの負担が増え、ＰＧの負担が減る。
つまりWaterFallをやめたいのはＰＧでなくＳＥ。
やめたいというかできないんだろうけど。ただの営業だから。ｗ

>>300
ゲームはほどほどにな。

OOPはわかるんだけどXPってなに？

まるまるピーはまる二つ
ばつピーはばつ一つ

>>303
顔文字だよ。
横から見てみな？　モロに昭和中期の漫画キャラの顔だから。

>>286
メイン部の処理そら例外使うさ。何言ってんの？（笑）
下層の関数からのシステムエラーも上位に飛んでくるのはそれはいいとして。
個人で切り分けしたい処理の場合は戻り値で判定したりするのはよく有ることで
その場合の戻り値の場所を頭か後ろかというのは最初に良く決める話だよ。
戻り値によりユーザ定義例外に飛ばすか否かはまた別の話。

君のその書いてるような処理を実務で使うことはまずあり得ないな。
バッチ処理になるとジョブ管理が通常だからね。

だからもうすべてをJavaに置き換えてる時点でもっと他の言語もみとけって事だよ。
世の中には色んな言語があるんだから。
インターフェイス部分だけがプログラムじゃないんだよ。
君の知らないところで月次処理や物理削除が行われてるんだ。
pl/sql古いっていうのはいいけどならもうＤＢオラクル使うのはやめろよな（ｗ
DB2とかSQLサーバで開発しれ。

粘着ﾊｧﾊｧ

>281
>処理がうまくいったかいかなかったかを戻り値で戻すような関数の場合
ワザワザ引数戻り値でなく、素直に関数戻り値で返した方がいい、とは
誰もツッコまないの？？

>>308
きみってOOやったことないでしょ？

>>308
日本語が理解できていないようだな

君はもっと色んな言語をやったほうがいい。あ、一応Javaも.NETもやったからね。俺は。

>>309==>>310
ﾌﾟﾌﾟｯ
顔真っ赤にして目に涙タップリ溜めて頑張ってまつね(w

>>308
ファンクションの戻り値は基本引数のない関数の場合のみ
という指定が多いからな。
引数のある関数の場合の戻り値は引数で、ってのがよくあるパターンだな

>>312
どっちが赤いんだかなぁ。
Javaしかやった事ない事を認めてるなら
とりあえず他の言語やプロジェクトを経験してから書き込め。
ｵﾏｴみたいなちっちゃいちっちゃい場所しか解ってないPGの書くプログラムが
一番見づらいんだよ。

プロジェクトの大小に関わらずアルゴリズムを考える部分は重要だからな
アルゴリズムの関係ない部分しか担当できない人間なら関係ないが

Java厨が暴れているようですね。
若いな。

>>315
アルゴリズムを考えてもいいプロジェクトは減ってるけどな。

>>317
それは単に君のレヴェルを物語っているだけ。
出来合のライブラリ使うだけでは、そりゃ無いよ。

>>317
ライブラリの組み合わせで出来る仕事は流通業と一緒
いつかネット時代の流通業と同じ運命を辿る

>>318
要するに、(自分でやってたら)人件費が高くなってしまうということ。
昔はコスト意識低いところも多かったけどね。

>>320
ほら
もうコスト削らないと採算が合わない時代になってる

>>321
そうやって、競争力落としていくんだ。

独自性がなくコストダウンでしか勝負できないのは
既に競争力がない証拠なんだがな

>>313
要はファンクションには引数つけちゃわかりにくいからダメって事だろ。
コーディングﾙｰﾙではお馴染みだからよく解るけどね。
個人的にはファンクションに引数つけてもいいじゃん。とか良く思うのだけど。

>>313 や >>324 はそもそも言ってることの意味が分からない
と思っているのは俺だけだろうか？

>>323
独自性なんて求めてないんだよ。

つまり誰でも出来るということだ

>>325
大丈夫、漏れも分かってないから(w

関数には引数付けないのがお約束って、どういう言語なんだろう．．．COBOL？

>>313 に突っ込むなら

「ファンクション」と「関数」はあなたにとっては違う概念なの？
「基本引数」って何？

ってことかな

なんかよくわからんが関数はvoidが基本だということか？

>>313
>>324

「引数」っていうのは数学で言う
y = f( x1, x2, ... )
の x1, x2, ... のことだという認識で相違ないよな？

そのとき引数（＝入力）のない関数は
・常に同じ値を出力する
・「状態」をもとに値を出力する
・「状態」を遷移させる
のどれか（あるいはその組み合わせ）しかできないのだが

>>316
COBOL厨が暴れているようですね。
老いてるな。

またCOBOLerか。
COBOL知ってる香具師同士にしか通じない話をここでするな。
COBOL知らない人間が混乱するだろ。
#数多あるスレの中で今一番重要な名前を持ってるスレなんだから。

ファンクションは戻り値のある関数で
プロシージャは戻り値のない関数って事では？
VBとかPL/SQLなんかはそんな感じだったような気がする。

プロシージャという単語が出てきたレスは

>>211
>>212
>>226
>>334

です。本件には関係していない気がします。

ていうかストアドプロシージャの話してんじゃないの？
＞戻り値が前か後ろか

そんな気がする。pl/sqlのバッチ担当者でしょう。

>>328
基本ストアドプロシージャで物を作れって事では？
処理が正常に終了した場合０を
異常終了下場合は９を返すOUT引数というのをつけるのだが
その戻り値を戻り値付きのファンクションで作成するのは通常せず、
プロシージャのOUT引数に設定する。
ジョブ管理の基本。
その戻り値の場所を決めるって事じゃないの？

いやちがう、俺なにいってんだ。
通常パッケージで物作るよな。
ファンクションに引数はつけるな、って標準規約は良く見る。
結構無視することはあるけど。

わからねー。
関数には戻り値と引数があるよな。
それで、引数にはINとOUT（ValとRef）があるよな。
そのOUT引数は使うなってことか？

【逮捕祭り】
ファミコンのエミュレータを売るサイト
　　　　　　　↓
http://www.geocities.co.jp/Playtown-Spade/7898/

プロシージャ、関数、メソッド、いずれも本質的には同様のもの
http://yougo.ascii24.com/gh/78/007837.html

ストアドプロシージャ=RDBMSを構成するプロセスの「内部」で実行
されるため、通信コスト0＋最良の最適化が期待できるという特性を
もつ「関数」ですな。呼ぶ側から見れば、単なる関数の一種です。

多値を使えば解決。
あるいはCPS。

仕様書がきちんと書かれていれば
ソースが綺麗である必要はない

∴終了

ソースが汚いと仕様書通りに動かない可能性も高くなるがな。

>>344
君はもっと広い視点を持ったほうがいい。

視野だけ広くて役に立たない奴もいるがなw

>>344
ソースが綺麗ならば、機能仕様書以降の仕様書は不要である。

>>344
一回限りの開発で逃亡できるのならね。

>>349
いいや。基本的に「機能仕様書以降の仕様書」は書かないよ。
プログラム設計書は書かない。試験仕様書群は書くけどね。
顧客が「欲しい」って言えば、リリース後に別工数を貰って書くけど。
何回もバージョンアップするような仕事の場合は、殆ど書かないなあ。

顧客がプログラム設計書を欲しがるのは、
「プログラム設計書が無いと保守不能だ」っていう
根拠の無い恐怖心からのものだろ。

>>337 >>338
PL/SQL とやらが分からないので，出来るだけ用語を一般的で一貫した表現にしてみた

> 基本ストアドプロシージャで物を作れって事では？
「基本ストアドプロシージャ」ってのは
・戻り値のない関数（＝プロシージャ）で
・引数の並びの中に出力を返せる引数がある
・出力を返せる引数に終了の正否を返す
という認識でいいのか？

> ファンクションに引数はつけるな、って標準規約は良く見る。
で，こっちはまだ意味が分からないのだが…
「ファンクション」は戻り値のある関数のことだよな？
関数が戻り値を返すとき
「入力」（＝引数）や「状態」（＝大域変数，静的変数など）がなければ
常に同じ値の戻り値を返すことしかできないと思うのだが？

rand()

rand()は状態を持ってるよ。srand()で状態設定できるし。

「引数があって戻り値がない（Void）なのは’ファンクション’ではなく
’サブルーチン’である」って言われることは未だに多いな。

で、ファンクションは何らかの結果を戻り値で返すだけだから
引数は最大でも一つにすべきだ、っての。
うちの上司の口癖なんだけどね。
（FORTLANとCとアセンブラしか知らない、古き良き時代のＰＧって感じの人）

y = f(x)というスタイルこそが「関数」である、って言いたいのかなあ。

>>354
サブルーチンの方はいいとして
> ファンクションは何らかの結果を戻り値で返すだけだから
> 引数は最大でも一つにすべきだ
ってのはすごいな。その上司書いたプログラムを見てみたいもんだ・・・ちょっと怖いけど。

あと「FORTRAN」な。

y = f(x, z)
は普通に関数だと思うが。

>>356
数学ならそうだね。FORTRANだとどうなんだろ？

FORTRANの「関数」（関数副プログラム, 文関数）でも２つ以上の引数は使える。
標準の組み込み関数の中にも複数の引数を持つものがある。

でなきゃMAX()とかATAN2()が使えないだろ…。

漏れが個人的にツールとか作るときは、返り値を必ずbooleanかvoidにしてる。
同じことしてる香具師いる？

いないだろうな。

>>359
その二つに絞るメリットはないと思うが。
オブジェクトを返してもらいたい場面はないのか？

>>361
くそＡＰＩの真似だろ。戻り値は成功／失敗のみで、オブジェクトはＲｅｆで。

>>362
どの言語の話をしてるんだ？

オブジェクトのRefかぬるりーを返すとか。

>>362
Cとか例外が存在しない言語の場合は
この方法が有効な場合もある。

>>249
> >>231
> それはバグの温床になるのでは？
> (スーパープログラマーだけで作ってるのならかまわないだろうけど)
ArrayListクラスを使わず、ArrayListクラスを集約した独自のクラスを作り
add()メソッドをラッピングし返り値をvoidにせず不変クラスとして扱い、同じクラスを返り値にすると良い。

例
pulic final class MyVector {
　private final ArrayList arrayList;
　public MyVector(){
　}
　public MyVector add(Object obj){
　　return ((ArrayList)arrayList.clone()).add(obj);
　}
　//以下略
}

この例はテンプレートを使っていないので確かに潜在的バグの温床が残っている。
add()メソッドの引数を限定できるなら限定したほうがいい。
if文でgetClass()などで判定し例外をスローするという手間をある程度まで省くにはテンプレートが必要。

できれば、>>232のように新しい型を作ったほうがいい。
そこでBridgeパターンやStrategyパターンなどを適用すればある程度は解決する。

>>244
> 問題はクラス、関数ひっくるめて何を共通機能として分離するかという次元の話だと思う。
> 引数を構造体にしても、その要素の選定や名前はやっぱり整理しなければならないし。
その問題の解決には数多くのパターンを学んで修行するしかない。

>>258
> >>254
> いやぁ、231あたりは複素数を例題としてたりするので、業務経験ないのではないかと。
ん？　喪前は研究開発部門では無いな？
信号処理もやらないのか？
学生時代に複素数を使った経験が無いのか。

>>261
XPはそう簡単に受け入れられないプロジェクトもあるだろうが
オブジェクト指向の場合はどうだろう。
クラスを作ることを禁止していなければ勝手にクラスを作って
それがないとどうしようもない位にプログラミングの規模を早い者勝ちで
巨大化させてしまった場合、オブジェクト指向からは逃れられないぞ。
とはいえ、オブジェクト指向によって開発が楽になればそれはそれでいいことじゃないか。
どれだけデザインパターンなどを使いこなせる能力があるかによって
オブジェクト指向を使った効果は変わってしまうが。

>>270
> >>269　そだね
> 特に、学のXP厨なんてその存在すら認められない。
> 実践抜きで、書籍からの知識のみでほざいてるってことだからな。
あれはそんなにXPのことを説明しているとは思えないのだが。
OOP == XPと勘違いしていないか？

XPを知らない大学教授は多いが、RUPくらいを講義で教えている大学教授はいるもんだぞ。

>>273
> COBOLのことは知らんが、基幹業務用データベースシステムの
> テーブル設計におけるOOP,XPってどんな感じになるの？
> 「オブジェクト」ないし「モジュール」と呼ばれるものごとに
> ばらばらに独自のデータベース持つの？
> 昔、SE不在で営業が打合せ→PGがそこまで作っては見せる→フィードバック
> という無茶な方法でやってたことがあったけど、そういうんじゃないよね。
> テーブル設計なんて、客のたった一言で根本的な構造が変わる場合があるから、
> 徐々に部分的に作るなんて無理だと思うけど。
> 溜めた膨大なデータは高速に検索・集計される必要があるので、動けばいいというものでもないし。

XPとは関係ないが(なぜXPだけに限定するのか理解しかねるが)
テーブル設計にオブジェクト指向を用いるとすれば
EntitBeanを使うことだ。

>>281
> >>233
> うわー粘着。こわ。
脳内解釈している君も粘着だ。

> Javaが初めて学んだプログラムなんだね。これで大体歴が３年程度ということが発覚したなぁ。
> 先走りｺﾞｸﾛｳだよ。ほんと。
残念ながら違う。果たして先走りはどちらだろうか。君こそ先走りご苦労。
今までにC/C++, MATLAB, Prolog、Perl, PHPなどを学んできた。
歴は少なくとも5年以上はある。

> 処理がうまくいったかいかなかったかを戻り値で戻すような関数の場合は
> その戻り値を第一引数にするのか、それとも最後の引数にするのかという事。場所をきめておくってこと。
> できれば変数名も。
> 例外で頭飛ばしするのはメンテがしにくくコードが見にくいという事で戻り値での判断が個人的には好きなので。
「個人的に」では話にならんな。例外クラスの自作もしたこともなければNullObjectパターンも知らないのか。

> まぁJavaやってっとビジネスロジック部分でさえ部品部品でsqlの一本も書けなくなるからねぇ。
何を言っているのかね。その発言からすると君はJDBCやEJBを使ったことがなさそうだね。
EntityBeanも知らずに何を言っているかね。

> ＭＱだのどこぞの誰さんが作った怪しいデータアクセスクラスだの。
> 個人的にはJavaもVB.NETも金が安くデジドカになってく気がして嫌い。
こいつは釣りの中に愚痴が含めた発言だと思うが、
とりあえずJavaをVB.NEＴを一緒だと思い込んでJavaを勉強しないでいるとはお門違い。

EntityBean知ってることがそんなにえらいのか？(ﾌﾟ

どうせショッピングモールレベルのことしかやったことないんだろ。ｗ

ショッピングモールレベルもやったことが無い人は口を出さない。
ショッピングモールのレベルを低く見積もっていることで程度が分かる。

>>371
俺はOracleを使ってるのでEntityBeanなんか使いませんが、なにか？

Ｊ２ＥＥ厨ってどうして偉そうな奴が多いのかねぇ

>>369
OOPはオブジェクト指向というパラダイムに基づくプログラミング。
XPはeXtreme Programmingのことで、プログラミングと名前はついているが、
プログラミングではなく、「プログラミングを行う方法」あるいは「開発手法／開発方法論」だ。
XPは12のプラクティスで構成されているが、これは経験により有用性が立証された
（と提唱者が言っている）実践項目の事だ。
#だから実践無くしてXPを語るのは「知識でしかない」ということだ。
この程度に説明すればいいか？

>>371
> 「個人的に」では話にならんな。例外クラスの自作もしたこともなければNullObjectパターンも知らないのか。
例外クラスの作成ってそんな大したことか？
あと例外処理を構文的にサポートしていない言語でも普通に現役なんだから
例外処理を前提に話をするな

>>270
XPのプラクティスは14個だよ。

>>379
いや13個だ。

>>374
図星？（爆
少なくともショッピングモールに複雑な副問合せ含む高速な集計はいらん罠。
業務要件も簡単だ罠。

商品は無制限可変階層で、複数の各商品につき複数の送付先を指定できるサイトを昔１人で作った罠。
昔なのでセッションやクッキを一切使わずに四次元情報を保持した罠。
画像も管理者がブラウザからうｐできる罠。

四次元情報って何？

>>380
19個。

今のプラクティスがいくつなのかは、XPのスレでどうぞ。
#最初は12だったのが、増えてるのは確かみたいだな。

>>382
失礼。テーブル２つ分に相当する情報（テーブル１個で二次元と考える）
商品Ａ：１０個、色等
　　送付先１：５個、氏名、住所等
　　（残り５個は本人）
商品Ｂ：２０個、色等
　　送付先１：５個、氏名、住所等
　　送付先２：５個、氏名、住所等
　　送付先３：１０個、氏名、住所等
な感じ。

>>380
XPのプラクティスは増え続けるらしいよ。
儲なら、何個かなんて気にせず全部頭に叩き込むべし。
http://www.extremeprogramming.org/rules.html

>>381
>>374と喧嘩するために虚勢張ってるだけなら知らんが、
成果物の種別と難度の関係は固定とは限らないのでは。
君が挙げた要件なら簡単だろうが、世の中にはもっと難しいつくりのモールもあるよ。

難しいシステムをシンプルに書き下せるのは実力だと思うけど、
セッションやクッキーを使わないで構築するあたり、>>381の実装には実力を感じないな。

>>385
そんな概念はじめて聞いたよ>4次元情報
つうかそれってそんなに大層なことか？

それにセッションやクッキーを使うなっていう要件の無いシステムで、使わないのは何故？
自己満足ですか？それとも単純に使い方が判らなかったんですか？
全部Web上からやる事に何か意味があるんですか？
適当なクライアントアプリで管理したほうが操作性はいいと思うんですが・・・

つうかシステムをシンプルに仕上げようっていう考え方はもってます？

こ の 話 は ス レ 違 い な の で も う や め れ

>>386
昔だからって書いてあるだろ。クッキのないブラウザが多かった。
その後はセッション使ってるよ。もちろん簡単になる。
それと、あれで要件の全部なわけないだろ。ｗ
でもモールは所詮お遊び。基幹業務の比じゃない。

関係ないけどJ-Skyどうする？クッキに頼らない技術は必要だよ。
J-Sky対応の病院用の予約サイト作ったことあるけど。
開始予想時刻とか他人のキャンセルによる時間帯内の繰上げがあったりして
画面は簡単だけどDBはショッピングよりはもうちょっと複雑かな。
それでも基幹業務の比じゃない。

こ の 話 は ス レ 違 い な の で も う や め れ

そういうのって例外処理を除いたらコード量が１割になるって本当か？
それで正常処理は新人にやらせて熟練者が例外処理を書くんだそうだ

>>389
恥ずかしいから、そのくらいでやめとけ。

>>377
> >>369
> XPは12のプラクティスで構成されているが、これは経験により有用性が立証された
> （と提唱者が言っている）実践項目の事だ。
> #だから実践無くしてXPを語るのは「知識でしかない」ということだ。
ある程度は同意できるが断言するのはどうかと。
しかもなんでXPの話しかしないんだか。
RUPもあるだろ。

>>387
＞つうかそれってそんなに大層なことか？

別に。ただ、そんな買い方できるモールは見たことないけど。
昔JavaおよびXML厨の似非ＰＭがモールの感覚で基幹業務に摘要しようとして
大失敗したのを見たことがあったもんで。
何のんびりしたこと言ってるんだろうと思って事例を見せてもらったら
モールだった。呆れて何も突っ込めなかったよ。ｗ

>>375
SessionBean厨か

>>368
どうも、研究開発部門と信号処理と複素数とOOPが固く結びついているようですね。

>>378
> >>371
> > 「個人的に」では話にならんな。例外クラスの自作もしたこともなければNullObjectパターンも知らないのか。
> 例外クラスの作成ってそんな大したことか？
作成自体は簡単だがどこでどの例外クラスを作成するかを考えることに少しだけ熟考させられる。
どのように例外を投げ、どのようにキャッチするかも考えねば堅牢性が高まらない。
catchステートメントを空にする奴はマジで氏んでほしい。

>>394
お前アレだろ。政治家が犯罪犯したら、
政治家は全員犯罪者だと思ってしまう奴だろ。
んで、逮捕したらやっぱり政治家だったとか言う奴。

>>396
信号処理に複素数がつくのはほとんど当たり前だと思うが。
オブジェクト指向がつくことが納得いかないといいたいのかい？
そりゃ組み込み系でDSPやってる香具師には納得できないだろうなあ。

>>366
一生懸命引数の型チェックを行う(または行わなくてすむようにする)理由がわからない。

>>392
反駁できないお前が一番恥ずかしい

>>400
テンプレートがあればチェックを行う必要はないのだが。
J2SE1.5から出るGenericsに期待。

>>399
いやぁ、OOPの例として複素数が出てくるのが幼稚だと。

>>402
コンパイラに任せましょう。

気づいてないのか・・・。

>>400
あれはあくまでも一例.
全部同じ型だったらチェックする必要が無いのは確かだな。

> J2SE1.5から出るGenericsに期待。
そんなもの出ませんがなにか？

>>406
一個addし忘れたら？

>>403
ほう。では何が幼稚でないと思うのかね。
馬鹿に説明するには複素数がシンプルで楽だという配慮の
もとに複素数で説明してやったのだが。
それともお前には複素数が理解できないのかね。

いいから複素数以外の例をだせよ。
それくらい考えつかないから幼稚だといわれるんだよ。

>>408
getterメソッドで例外をthrowsさせるようにif文を書く。
もしくはadd()に相当するコンストラクタを用意し、
生成時にいきなり最低ひとつでも引数を追加できるようにする。

>>411
だから、コンパイラに任せればいいじゃん。

>>410
じゃあ、これはどうかな。

public abstract class 馬鹿 {
　private String 馬鹿の名前;
　private long 馬鹿指数;
}
public class アンチOO厨 extends 馬鹿 {
　private double OO理解度;
}
public class アンチJava厨 extends 馬鹿 {}
　private double Java理解度;
}

>>397
> catchステートメントを空にする奴はマジで氏んでほしい。
まあな
例外をかき消すくらいならメソッドの外に丸投げしる

>>412
object型なのにどうやってコンパイラにまかせろと？

>>409
複素数が入門書でよく出てくるのは確かだけど、オブジェクトである
ありがたみは薄いからねぇ。まだ犬クラスのほうが有用でしょ。

>>413
必死だな（藁

このままでは、アンチOO厨とアンチJava厨とを同時に満たすことができないな。
集約しておかないと。

public class >>410 {
　private アンチOO厨 untiOO;
　private アンチJava厨 untiJava;

　//(ry

}

>>415
?

まあコンパイラにまかせるのは不可能だな。

>>418
そんなことするから、変数を日本語(ローマ字表記)にしろとか言われるんだよ。

むしろこっちのほうがいいか

public class 馬鹿の典型 {
　private アンチOO厨 untiOO;
　private アンチJava厨 untiJava;
　public 馬鹿の典型(アンチOO厨　untiOO, アンチJava厨 untiJava){
　　this.untiOO = untiOO;
　　this.untiJava = untiJava;
　}
}

public class　馬鹿のためのデモ {
　public static void main(String[] args){
　　String 馬鹿の名前　低脳417 = ">>417";
　　long 馬鹿指数 = 100;
　　doube OO理解度 = .1d;
　　doube Java理解度 = .01d;

　　馬鹿 untiOO厨 = new アンチOO厨(低脳417, 馬鹿指数, OO理解度);
　　馬鹿 untiJava厨 = new アンチOO厨(低脳417, 馬鹿指数, Ｊａｖａ理解度);
　　
　　馬鹿の典型 馬鹿レス417 = new 馬鹿の典型(untiOO厨, untiJava厨);

　　//(ry
　　
　}
}
//不足したコンストラクタも(ry
//馬鹿クラスの馬鹿の名前が重複しているのは問題だな。

アンチのスペルが…

>>423
うんちが好きなんでしょ。

>>421
なになに、>>410をからかうためにわざとやっているんだよw
いっておくと、変数">>410"以外は、UTF-8で保存すればコンパイルも実行もできるぞ。
わかっているとは思うが括弧が余分についたミスなどをはずし
全角スペースも半角スペースに直してからな。

>>418 >>422 はやぶ蛇のアフォ

>>425
恥の上塗りか（藁

>>423
>>410をからかうためにわざとウンチにしておいたよw

>>427
では、恥の上塗りクラスでも作るか？(藁

つまりXP厨、OOP厨は英単語もおぼつかないということか。

いや、インターフェースにしたほうがいいなw

public interface 恥の上塗り {
　public abstract void 恥をかく();
}
馬鹿の典型クラスを改良。
public 馬鹿の典型 implements 恥の上塗り {
　private java.util.Stack 蓄積される恥 = new java.util.Stack();
　public void 恥をかく(恥 恥){
　　蓄積される恥.push(恥);
　}
　//(ry
}

public class final 恥 {
　//(ry
}

つまんねーよ。

このｽﾚもﾋｯｷｰと厨房のたまり場になってしまった。

バレー見てた。どーせ脱線してるみたいだし、てきとーにレスさせておくれ。

>>389
昔って、Netscape以前ってこと?
いずれにせよ、セッションが書けるなら、IDだけ受け渡せば良いとわかると思うけど。
J-Skyも同様。

ちなみに、漏れは「解り易い」「美しい」の到着点は「シンプル」にあると思っている。
君の「モール=レベルが低い」みたいに証明が面倒な主張は、「上手」だとは思えないな。

>>434
セッションIDを渡すのにクッキが必要なんだが。
タグに埋め込んで渡してやっても、次に来る時には別人なので、
セキュリティ上他人のセッションは覗けないし、
その前に前回の接続によるセッションは切断されたものとして消滅してる。
Netscape以前ってどういうこと？付いてないバージョンもあったし、
特にMacユーザはNetscapeでもセッションを切ってる人が多かった。

＞ちなみに、漏れは「解り易い」「美しい」の到着点は「シンプル」にあると思っている。

んでどのような業務でもJavaでやると。
オラクルのストアドでも時間のかかる処理があって、それでもユーザをもっと待たせてJavaでやると。

ここはJavaスレじゃないぞ。あと、上手な日本語を(ry

>>435
糞も味噌も一緒にすんなや。

1. 一度サイトを去った人が再度来訪した際に同一人物と扱われること。
2. 上記処理を自動化すること。
3. Cookieをサポートしないブラウザでも利用可能にすること。
4. カスタマイズされたブラウザに対応すること。
5. セキュリティ上他人のセッションが覗けないようにセッションIDを随時変えること。

1と2はID認証の方が適切なので、本件業務に要求されうるのは3と4と5だけ。
3と4を実現するにはセッションIDをURLやPOSTデータに含めて送ればいいし、
5はサーバ側で実装が完結するため、クライアントの仕様を問わない。

あと、Cookieの無いNetscapeなんて初めて聞いた。
後学の為にバージョン番号を教えてください。

数年前使ってたcad開発用unix（なんだかわからん）に入ってた
1.xは無かった気がした。

うわ、馬鹿ばっか
このスレ

>>435
>>ちなみに、漏れは「解り易い」「美しい」の到着点は「シンプル」にあると思っている。

>んでどのような業務でもJavaでやると。

頭ん中なんか湧いてる？
>>434にはどこにもJAVAでやるなんて書いてないぞ。
もしかして話の振り始めがJAVAだったから、みんなJAVAでショッピングモールを作る話を
していると思い込んでる？？

まぁ複数テーブルにまたがる情報を保持した位で天狗になっている位だから、思い込みが
激しいのはしょうがないのかなぁ・・・

まあ、Javaで複数テーブルの複雑な連携を、JAVAで設計したクラスと連携させるとなると
面倒だけどね。
RDBとオブジェクト指向設計って根元が違うからなー。

とはいっても、テーブル連結したぐらいでえばられちゃね。

>>393
270を書いたときはOOP厨とXP厨がうるさかったからその二種の香具師らにレスしただけ。
XPが一番有名なのはマーケティングが成功したからで、
開発プロセス改造方法論として最適だということを実証されたからではないことを知ってくれ。
ご指摘の通りRUPもあるし、他にはCMM,SCRUM,FDDなどもある。
それらを全部説明しろってか？自分で勉強汁。

>>439-440
>>394

漏れは434=436だが、別に開発言語をJavaと仮定して貰っても良いよ。
ただ、言語固有の話をしても局所的で潰しがきかないので、
共通で適用出来るノウハウを優先するほうが有意義だと思う。

>>371がEntityBeanの話をしてるのが気になるのかね?
ざっとぐぐってみた感じ、一番わかりやすかったのは@ITの記事かなあ。
http://www.atmarkit.co.jp/fjava/rensai/smartj02/smartj02_2.html

大事なのは、それがEJBであったかどうかでなくて、
こういう着想でもって「上手な」プログラムを書けるかどうかでないの?
少なくともこの例ではsql叩くよりEntityBeanの方が「上手」という話だけでしょ。

方言使わないと考え方を説明出来ないのも良い事ではないが、
意図を汲もうともせずに物事を決めつけてしまうのは良くないよ。

で、なんでそんなにJavaにこだわるのかと思って過去ログ読み返したが、
>>18の反論部分には全面的に同意だな。
ただ、>>233に書いてあるよな「一般常識」というような曖昧な主張は好ましくない。
アンダーバー区切りのメソッド名との比較で語ってくれれば面白いね。

>>13も、前時代的なプロジェクトでは有効なのかも知れないね。
「事業部」のくだりは、たとえば「東区」を「East Area」ではなく
「Higashi Ku」と表記する、という意味なら共感できる。さて、なぜでしょう?

>>444
> 「東区」を「East Area」
固有名詞を英語にすると訳分からないだろ

日本のプログラマーってレベル低いよね・・・

そうだよな。
俺がいなかったら全滅じゃん。

そもそも英語で組み立てるのに英語のできない人が多すぎ…。
だからニュアンスの部分で狂ってきて、バグがでやすくなる。
向こうに本社があり、日本語版の出てるソフトで、
英語版でバグが無いのに、日本語版だけのバグがあるのは有名だし…。

ほほー、バグのないソフトがあるんだ。

底辺な人たちは凄腕のプログラマーに会う機会すらないみたいだな

>>450
凄腕のプログラマーって何処にいるの教えて。
というのは冗談だ。
#どうせ「ここにいる（俺だ）」って返ってくるわな。
「凄腕のプログラマー」に師事しなければ「凄腕のプログラマー」にはなれないというものではなかろう。
開発プロセスをまのあたりに見ることは出来ないにしろ、その成果物（ソース）は入手可能な環境なっているし。

最初の「凄腕のプログラマー」はいかにして「凄腕のプログラマー」になったか。

>>449
1000行程度のプログラムならあるだろうな

>449
Micro$oftの製品。
何がどうなっても全ては仕様どおりだからバグではないのだ。

>>453
「潜在的な不具合」も確認されてるがな

>>454
きっと『潜在的な仕様』なんだよ。

>>1
>１つの関数は１００行以内にする。
行という単位でしか判断しないってのはアセンブラを引きずっている。
#車の積載上限を荷物数で指定するようなもんだ。重量で指定するのがほんとだろ。
関数内での識別子の種類数が有力かな。
２０だと多すぎるな。

>>456 なるほど。識別子の数ですか！感動した。

行数よりはずっとコードの意味を反映しているかもしれませんね。
行数はコーディングスタイルを統一しておかないと誤差が大きくなって
しまうけど、識別子の数だとそういうことは少なそうですね。
gotoを使わない替わりにフラグを使う、っていう悪いスタイルの
抑制できそうです。

問題は、行数ほど簡単に数えられないことかなぁ...

なぜgotoをそんなに嫌う？
フラグにしろ命令にしろロジックにしろ
意味がgotoならばgoto使ったほうがすっきりするだろ。

だといいね( ´,_ゝ｀)

>>457-459　フラグについて論じるのはいいが、gotoは専用スレがあるのでそちらでどうぞ

goto hell;

>460
おめーのBBSか？
おめーがどっかいけ

goto ヘルス;

hell:

>>1
俺は個数ベースで５％程度の関数にだけ「関数の説明」を書く。
それ以外のコメントはほとんど書かない。
コメントを書くことが解りやすいプログラムにつながるとは思えないし、
コーディング上の鉄則とも思わない。
「コメントが無いから解りにくい」ってプログラムは
「コメントを追記すべき」では無く、書きなおすべきなんだ。

「わかりやすいコメントを書く」というのと同じくらい
「わかりやすい変数・関数名をつける」ってのは重要

>>465
アルゴリズムのコードなどの場合は
何をやっているのか事前に分かっていた方が
理解しやすい

俺の気を付けていることと言えば
「意図のわかる分岐」かな

他人から引き継いだソースとかだと、意味のわからないif文とかが
大量にあったりするので、修正、テスト、レビューの時にすっごく困る。
せめて自分がプログラムを作るときは、「なぜその分岐が必要なのか」を
コメントするようにしてる。

>>468
なるほど

自分は、自分の作ったプログラムでも
２年くらい経っていると、
「なんでこんな処理やってんだ？」ってなります。

そうならない為に、どんなことをするのが良いですか？

>>470
記憶力を鍛えろ。
そのために携帯も手帳も持つな。

>>470
上達した証拠だぉ

老化した証拠

>470
>1-469の中に答えがある。・・・かな？

>>467　その通り。それに該当する関数が５％くらいなんだ。

>>470
それは一つの関数が長すぎるからだ。
コーディングスタイルではなくプログラム設計方法論の話になってしまうが、
各関数名称をその機能を表明するものにする。
そうすれば「なんでこんな処理やってんだ？」なんて事にはならない。

なるよ。

キケー！

>>470
上達した証拠だと思うよ

>>476
コードにはHowしか書けんよ。WhatやWhyを関数名、変数名だけで表現
できるかな？

クラスで背の高い奴を10人選ぶためのソート関数とか、優先度の高い
プロセスを選択するためのソート関数とか、そういう名前の関数を毎回
作るのか？

>>480
> コードにはHowしか書けんよ。
宣言型プログラマへの挑戦ですか？

>>481
そうですが何か？
つか宣言型言語なんて使われてないし、そもそも使わない場合の話だろ。

>>482
> つか宣言型言語なんて使われてないし、そもそも使わない場合の話だろ。
(ﾟДﾟ)ﾊｧ?

>>458
> なぜgotoをそんなに嫌う？
> フラグにしろ命令にしろロジックにしろ
> 意味がgotoならばgoto使ったほうがすっきりするだろ。
>

お前はダイクストラを否定するのか！
20年以上も前からgoto文の問題は議論されてつくされ済みだというのに！

>>456
> >>1
> >１つの関数は１００行以内にする。
> 行という単位でしか判断しないってのはアセンブラを引きずっている。
> #車の積載上限を荷物数で指定するようなもんだ。重量で指定するのがほんとだろ。
> 関数内での識別子の種類数が有力かな。

識別子の種類数だけで考えるのも、まだまだ荷物数で数えているのと
同じように見えるが・・・・。
識別子の数が少なくなっても長いクラス名を
大量に使ったコードは見づらくなるが。

72カラム7行以内

>>465
そのメソッドがどんな処理をするのかの概要を記述し
メソッドの戻り値、引数の情報くらいかけよ。
とくに、引数にいれても構わない定義域の範囲について
記述することは重要だ。

>>468
> 他人から引き継いだソースとかだと、意味のわからないif文とかが
> 大量にあったりするので、修正、テスト、レビューの時にすっごく困る。
だからテストファーストという考え方が生まれた。
どのプログラマのテストを基準にプログラムをつくる。
どちみちテストをやるなら、最初からテストケースを作ったほうが
効率がいいのはこれゆえにあり。

チームプログラミングにはテストファーストは重要だ。

>>477 私はならないと言い、あなたはなると言っている。
「なんでこんな処理やってんだ？」っていうソースを晒して見てくれ。

テスト無し。これ最強。

>>480 yes

>>484
ダイクストラは「gotoは有害を引き起こす」と言っただけで、goto全てを否定したわけではない。
gotoを否定したのはその後のストラクチャード定理だろう。
gotoの問題についての議論は終わっていないよ。

>>485　識別子はクラス名を含む

>>487　そのようなコーディング標準が存在すれば、そうする。

>>487　追加
×引数にいれても構わない定義域
○引数にいれても構わない値域
それを書くと値域の境界値の試験を関数毎に行わなければならなくなるが、
あなたは、そんなことが出来るだけの工数をもらっているのかな？

結局工数の話かよ
アホか

つまり465はテスタにバグを発見されるのが嫌だからコメントを書かないわけか

>>480 追加
汎用ソート関数を参照して、コメントに「使用目的」を書くべきだ。
ということですね。
やはり回答はyesです。

>>497　工数を無視して開発が出来るかってんだ。
>>498　通常、テスタはブラックボックス試験しかしないよ。

特殊用途のソート関数にそれらしい名前を付けて
その関数の内部で汎用関数を呼ぶということか

無理矢理コメントを書くまいとしているようにしか見えないね
英語でコメント書く方がマシ

>>465はコメントを書かないことで他人が読みにくいコードにしておいて
もし他人がコメント無しのコードを書いて自分が読むのに苦労したら
もっと分かりやすいコード書けと言うんだろうな

>>499

// クラスで背の高い奴を10人選ぶためにソート
sort(...);

これを

クラスで背の高い奴を10人選ぶためのソート(...)
{
sort(...);
}

こうするわけね。
そうしたいと言われれば別にいいけど、コメントでもいいじゃん。

でもさー

// ABC規格で必要とされているXYZ処理
// アルゴリズムは論文hogehogeに記述されているgerogeroを採用
// mogamoga処理の都合でpiyopiyoの部分はhugahugaを選択
...

はどんな名前の関数になるのさ。

おそらく５％と答えると思われ

>>502
もう一度>>465を良く読んでくれないかな。
「コメントがある＝＝読みやすい」＆「コメントが無い＝＝読みにくい」
っていう二元論自体が誤りだって言っているんだよ。
コメントが無くても解りやすいコードを目指して日々研鑚しているだけだ。
ちなみに俺が他人のコードに文句をつけるのはリーダーであるときだけだ。

>>505
コメント無しで分かるプログラムの例を貼れや( ﾟДﾟ)ｺﾞﾙｧ！

>>505
二元論が誤りはわかるけど、そうだったら「コメントは書かない」にはなら
ないでしょ。良いコメントを書きましょうという話になる。

どのような処理をしているかよくわかるコード+コードにできない情報をコメ
ントに書く、でどうよ。

当たり前すぎてつまらんけどな。

しかし>>503がどんな名前の関数になるのか気になる。

printf("hello, world.\n");

(format t "Hello, world!\n")

(display "Hello, world!\n")

>>507 支持する。
「当たり前すぎる」かもしれないが、表層だけ見て「コメントが少ないですね」と言う香具師のいかに多いことか。

>>496
> >>487　追加
> ×引数にいれても構わない定義域
> ○引数にいれても構わない値域
> それを書くと値域の境界値の試験を関数毎に行わなければならなくなるが、

やらなかったらとんでも無いバグを生み出す可能性が大きいだろ。
-1をいれて欲しくないところに-1を入れた場合に例外をスローするくらいの
記述は重要だ。それから、二つの配列を引数にとるメソッドを自作したとき、
双方の配列のサイズが同じでなければならないようにしたい場合にも
判定が必要だ。

そんな程度のことで工数云々と文句を言うのか？
その後におきるとんでもないバグを修正する工数、
バグによて生じた顧客の損害を補償する工数と比べたらそんな程度の工数、
対したものじゃない。

関数ごとに決まりきった処理を書くのが面倒なら判定用関数でも
作ってみると良い。それでも手間がかかるならソースコードテンプレートで
ソースコードを自動生成すればいい。

まさかとは思うが、抽象クラスやインターフェースを作っただけで工数が
かかるとか文句を言うのか？
テストファーストは工数がかかるからやらないほうがいいとか言い出すのか？
(テストファーストをしなかった場合のほうがバグ修正による工数が多いのだが)

>>500
> >>498　通常、テスタはブラックボックス試験しかしないよ。
だからバグが多いソフトしかつくれないんだ。
ガラスボックステストも知らないんだなお前は。

>ガラスボックステスト
初耳だ、そのテスト
ホワイトボックスってのなら知ってるんだが．．．きっとそれより
ずっと中身見えてるんだろうなぁ

>>496
仕様をコメント内に書くのと、テストの有無とは別だろう。

>>512
文句なんぞ言っていないぞ。「当然実施するべきだ」という意見は支持する。
だが「実施するべきだ」という見解と、「実施するだけの工数がある」かというのは全く別次元の話だ。
ここはプログラムの書き方を論じるスレであって、
各プログラムが持つべき機能や、試験の密度を論じるスレではないと思うが。
#あなたの仕事は「顧客の損害を補償する」場合もあるのか。すばらしいじゃないか。

ブラック・ボックス、オープン・ボックス、またはガラス・ボックス: どんな場合にどれがふさわしいか?
http://www-6.ibm.com/jp/developerworks/java/020208/j_j-diag0925.html

>>516
> #あなたの仕事は「顧客の損害を補償する」場合もあるのか。すばらしいじゃないか。
藻前は完成後の、潜在的バグ浮上に対する対策もしないのか？

>>513
ふーん。テスタがホワイトボックステストをする組織が実在するのか。
当然、カバレージ100%が最低条件なんだろうね。

んなもんオープンソースの常識だろ

>>518
「完成後」っていつ？リリース後？前？どちらかでレスの意味がずいぶん違う。
「潜在的バグ浮上」ってなに？。説明希望。
#もう少し一般的な用語を使って欲しいな。

「潜在的バグ」を知らないのか！？

>>520 ふーん。そーなんだ。勉強になりました、

>>522
「バグの不在は証明できない」は昔からの正の命題。
バグは顕在したものと潜在しているものがある。これも当然。
通常、顕在化したバグはつぶされてリリースされる。
#そうでなく「運用回避」とかほざいてリリースする組織も存在するが。
リリースした後に顕在化するバグへの対策のこと？
どんなバグかも判らないのに対策なんか出来るわけがないと思うが如何

質問なんだが、一つのクラスにおけるメソッド数はどのくらいまでなら許せる？

共同で開発している香具師が100↑のメソッドを持つクラスを作ってきて、激しく使いづらいわけで（；´Д｀）ｯﾃﾕｰｶﾂｶｲﾀｸﾈｪ
おまけにコメントが全く無い上に似たようなメソッド名と似たような引数とってたりetc・・・＿|￣|○

自分的には20〜30あたりが限界なんだが一般的にはどのくらいなのかと・・・（´・ω・｀）

>>525
顔文字使いすぎ

（；´Д｀）

＿|￣|○

（´・ω・｀）

つうか、コメントは最低でも、なにをやるってのを書けよ。
関数の枠を書いたら次にコメントで書いとく。

int hoge(int xx)
{

}

って書いたら、次の作業として、

int hoge(int xx)
{
//なにをやる
//これをやる
//こんなことまでしちゃう
}

って書く。

>>524
ユニットテストや最近のソフトウェア開発手法で多少緩和できる可能性が高まることを知らんのか？
過去に経験した事項からどのようなバグがおこりうるかある程度想像できるだろう。

>>525
> 質問なんだが、一つのクラスにおけるメソッド数はどのくらいまでなら許せる？
Javaでは255個までコンパイラが許す。

> 共同で開発している香具師が100↑のメソッドを持つクラスを作ってきて、激しく使いづらいわけで（；´Д｀）ｯﾃﾕｰｶﾂｶｲﾀｸﾈｪ
> おまけにコメントが全く無い上に似たようなメソッド名と似たような引数とってたりetc・・・＿|￣|○
それは設計に非常に問題がある。

理由があるなら説明を聞いたほうがよい。
機能が似て名前が若干異なるようなメソッドは早めに削除したほうがいい。
XPでは使うかどうかわからないが今は確実に使う予定が無いメソッドは作らないという原則がある。
基本的なメソッドだけを用意すればよい。
さもなければバグの原因を追及するのが困難になる傾向が高まる。

それでもメソッドを増やしたいならば、そいつには「分割し、統治せよ」の原則に従わせるべきだ。

よほどのことでなければ20〜30は正解例として妥当。

>>528
私とは違う。
int hoge(int xx){
　なにをやる();
　これをやる();
　こんなことまでしちゃう();
}
#もちろん関数名は通常の識別子
#返り値の参照は省略
と書く。
関数内に複数のパラグラフ（段落）があるなら、パラグラフ間のインターフェースを
検討し、それぞれのパラグラフを下位関数化すべきか否かを検討する習慣を持っていた。
過去形で書いたのは、現在は普通に設計しても、
各関数には複数のパラグラフが記述されることがなくなったからだ。

レベル低すぎてお話にならない。

>>529
＞ユニットテストや最近のソフトウェア開発手法で多少緩和できる可能性が高まることを知らんのか？
主語が省略されていて文意が理解できない。
＞過去に経験した事項からどのようなバグがおこりうるかある程度想像できるだろう。
「想像が可能」ならそれは試験済みでかつ、つぶされているバグではないのか？

>>465
レベルが低いというのはお前のことだ、馬鹿。

>>532
そりゃそうだ。読んでいる集団の技術レベルの幅は広い。
中には>>528のような二年生くらいの技術レベルの書きこみもある。
相手のレベルに合わせてレスしないと。

int hoge(int xx)
{
//そこはだめ
//だめだって言ってるのに
//いやーん♪
}

>>534 私が本当にレベルが低いのなら、低いレベルに合わせて具体的に指摘してくれ。

>>535
処置無し。

あははは、コイツ自分のことレベル高いと思ってるらしいぞ。

>>537
最近お前のような奴がほんと増えたよ。
お前の馬鹿さ加減を懇切丁寧に指摘してやったとして、俺には何の利益も
無いということに気づかないんだろうか。それにもかかわらず、さも相手に
説明責任があるような書き込みをする。
レベルが低いと指摘されただけでも感謝されてもいいはずだがなぁ。

（　゜д゜）ポカーン

>>540
お前の意見には同意できないが465がレベル低いというのは同意する（ｗ
なんか君うざいよ>>465

>>535
君はその２年生ぐらいのことも出来ない愚か者。
仕事ってのは集団でやるもんだからね。

君がレベルたかかろうがひくかろうが関係ない。

>>540
＞お前の馬鹿さ加減を懇切丁寧に指摘してやったとして、俺には何の利益も
＞無いということに気づかないんだろうか。
掲示板への書きこみは、「自分に利益をもたらす」ものではなかろう。
「馬鹿」とか「レベルが低い」とか書きこんで「気分がすっとする」という利益を求める
輩もいるようだが。
ただ単に「レベルが低い」とだけ書いて、「感謝されてもいいはず」ときたか。

>>544
ほんと君って頭悪いよね。

>>465
>>465-476くらいをもう一度読み直してみろ。
いちいち指摘はしないがな。

まあ>>465はレベルが低いというか
古い考え方しか知らないだけでしょ。
アジャイル開発といわれてもわからない人なんでしょうね。

>>535
養老孟司は、誰にでもわかる平易な文章を書くが、誰も彼のことをレベルが低いとは
言わない。なぜだと思う？

465たたかれまくり（ｗ

>>547
俺も>>465は思考停止したオヤジか、やっとこの業界に慣れた3年生くらいじゃないかと思う。
まぁ、前者かな。

まぁ、平日のこの時間に書き込むような奴なんだから推して知るべしだな。俺も同類だが。

まあ、実務経験上では>>465みたいな奴のソースって大体独りよがりで癖が強いんだよな。

>>550
オヤジでしょ。自分のこと「私」なんて書き込むんだから。

>>465 >>467 >>475の流れだけで、465がアフォだと俺は断言できるね。

キティガイはスルーの方向で。

>>531
意味わかんないんだけど…。
設計はしないということか？

>>556
彼じゃなくてもとのコメント書きを書いたものですが。

多分、あなたの指している設計＝詳細設計（関数定義とか）ってのはやらない場合が多い。
業務によるのかもしれないけど、そこまで設計はせずに、I/Fとかが固まったらコーディングってのが多い。
そういう場合に設計を兼ねてああいうコメントで自分の考えをまとめるようにしてる。

>>555
基地は言いすぎです。
少々偏屈な粘着だよ、人の言を絶対きかなそうだよ、理屈こねて。

>>557
俺も同じやりかたしてる。
つーか、いまどき公開しないメソッドの詳細設計まで事前にしてるところなんてあるのか？

>>553 御名答。療養中のオヤジですよ。
>>557
「少々偏屈な粘着」ですか。
「スレの趣旨に沿った、自分のスタイルを書き込みして、来た質問に答えただけ」
の認識なんだけど、それがここでは「少々偏屈な粘着」になるのであれば別に異議は唱えません。
ただ二年生と表現したのは侮辱でした。謝罪します。ごめんなさい。
＞人の言を絶対きかなそうだよ、理屈こねて。
そうかもね。実務では「自分の言を人に聞かす」事ばかりだから。八方美人じゃ仕事にならんし。
だからこそ、ここでは批判を聞きたくて、「具体的に書いて」と発言したわけ。
そういう意味で>>547や>>548のレスは嬉しい。

>>556　「私は>>350でもある」が回答

>>559
あなたが上にたつ人ならこういう聞き方がいいのかな？

あなたの配下でプログラマが書いたコードにコメントが少ない。
可読性も悪く、どうしてだとたずねたところ、ソース読めばわかると言われた。
その場合、あなたは彼のコーディング技術は責めるけど、コメント記述がないことは責めないんですよね。

あと、もっと極端にコードを書いた奴がもういないとした場合、
あなたはそのコードの解析工数ってのをどこから捻出するんでしょうか？

そのための予防線としてもコメントは不要でしょうか？

>>560
>コーディング技術は責めるけど、コメント記述がないことは責めないんですよね。
yes。
>>465の最後の二行にも明記したけれど場合によっては書きなおしをしてもらいます。
書きなおしとなるのはプログラム構造自体が駄目である場合だけですが。
しかし実際、書きなおしてもらったケースは今までありません。
プログラム設計書を書かないという表明と矛盾する様ですが、その前段階のプログラム設計書
を見ることにより、その時点でプログラム設計のやりなおしとなるからです。
つまり、プログラム設計書を書く人と書かない人の見極めができていなければなりません。
この見極めは、前の仕事のソースを提示してもらい、それを見ることによって可能です。

＞あと、もっと極端にコードを書いた奴がもういないとした場合、
＞あなたはそのコードの解析工数ってのをどこから捻出するんでしょうか？
コメントは予防線にはなりません。
「保守不能なプログラムが、コメントをいれることによって保守可能となる」というのは幻想です。
保守可能というのは「新規再開発するより、今回＋将来の保守作業の累計の方が安い」という意味です。
また、「コメントをいれることにより解析工数／保守工数が安くなる」というのも懐疑的です。
嘘のコメントが書いてあってもわかりませんからね。
私は、解雇されようとも、保守不能なプログラムを保守しません。
#本場の例をあげると、開発部門と保守部門がある会社では、
#保守部門は開発部門の開発したプログラムの保守を拒否する権限が確保されています。

なるほど
言いたいことは分かる

保守できない＝能力不足

早く気づけよヴォケ。

プロと呼べるプログラマは世界に数パーセントしかいないと聞いたけど本当か？

>>563
(ﾟДﾟ)ﾊｧ?
保守できないプログラムも見たことないのか
まだ甘ちゃんだな

>>564
間違ってるとも思えないな

>>564
0.1%もいないと思います( ´д｀)ﾉ

99.9%は土方要員？

0.1%ってことは1000人に1人か。
もっと少ない気が・・・。

分かりやすい上手なプログラムを書くにはどうしたらいいか？
コードに不吉な匂いを感じたらリファクタリングを行いそれを改善したらいい。

不吉な匂いとは？以下のページを参照してくれ。
ttp://objectclub.esm.co.jp/UnderstandingRefactoringByChart/refact-smell.html#22

その中の一つ、コメントに関する不吉な匂い。

>コメントを書くのはとても良いことで、コードの読解に役に立ちます。
>しかし、非常に丁寧に書かれているコメントは、わかりにくいコードを補うために書かれていることもあります。
>コメントの必要性を感じたときにはリファクタリングを行って、コメントを書かなくても内容がわかるようなコードを目指しましょう。

>>465はこれを言ってるんじゃないか？なんで>>465は執拗に叩かれてる？
つーか、ここには誰一人リファクタリングを知る人は居ないのか？
上手なプロクラムを書くにはというスレタイなのに？まったくもって訳がわからない。

>>570
「不吉な匂い」の一覧がまさにおぞましいメンバの好例。整理分類しる。
コメントの工夫にしろメンバの工夫にしろ、センスのない人はどっちをやっても駄目。
フロー図も整理整頓しる。いかにもバグが潜んでそうだ。

>>565
保守できないプログラムを保守したことないのか
おまえ尼ちゃんになれ

>>570
>>465がそれを言ってるとはとても思えない。

>>570
それとファウラーやベックがいう「よくリファクタリングされたクラスライブラリ」は
たしかSmalltalkで平均3行程度、Javaでも5行程度のものだよ。
業務アプリのしょーもない関数の話じゃない。そういうライブラリにおいての、
「内容を表すメソッド名」であり「表明」だよ。

>>574
C3プロジェクトではたしか６行だったと思う。

>>572
保守できてないのに保守したつもりになってるのか？
やはり甘ちゃんだな

>>570
本筋と関係ないが>>465が大勢に叩かれてるように見えるのは、
実際は１人か２人が執拗に妙な書き込みをしてるんじゃないかな？
匿名掲示板はそういうの注意しないとね。

>>465
わかったか？
相手に合わせてレベルを落としたつもりが、内容までレベルが落ちてりゃせわないな。
まぁ言いたかったことはわからんでもないがな。

>>578
おまい一人でいい加減しつこいよ

普通は、コメント書きましょう、でいいと思うが。

加えて，コードの分かりにくさをコメントで誤魔化さないようにしよう
（リファクタリングより）

でいいのかね結論としては

isSHIT() // これは無能な発言を2chで見かけたことを（以下略
↓
名前変更
↓
isFoundIncompetentResOn2ch()

まあそんなもんだろ

>>571
おおっ。読まなければならないと思っていた本にそんなことまで書いてあるか。
わがいをえたり。早速買って読まなければ。どうもありがとう。
　「なぜ叩かれるか」ですが。
「慣習を無条件に信じ込んでいる人がいるから」だと思います。
コードを書くようになって以来、ずっと正しいと思っていた事柄を否定するような見解には
感情的に反発するのでしょう。人間だから仕方ありません。
私見ですが、このことに限って言えば、これは慣習ではなく因襲なのですが。
#「慣習とみなされている事項を無条件に信用するべきではない」という教訓も得られますね。
##叩きが再発するかな？

>>581
支持しますよ。加えて、（コピペですが）
＞コメントを書かなくても内容がわかるようなコードを目指しましょう。
を追加したいなあ。

>>584 失礼しました。>>571は>>570の間違いです。（誤爆って言うのかな）

Vector vector(){
while(this.vector.add(return(new Vector(Integer.MAX_VALUE)))
}

当事者じゃないんだけど、過去ログチェックすると、
465が叩かれたんじゃなくて、465が一人でレス増やしただけに見えるが。
レスが増えれば必然的にそのレスも増えるし、連続投稿は目立つ。
>>492-496参照。

いやいや>>465に対する人格攻撃はどう見ても多いぞ。まぁ2chらしいっちゃらしいけど。

保守やってたけど、コメントが嘘ばっかで、騙されまくって、
ある意味無いほうがマシだと思った。
上手なコードだったらコメント無くても分かると思うが、
クソなコードだと、作ったやつ自体がバグってるので
そんな奴が書いたコメントがあると更にクソだな。

>>584
「慣習を無条件に信じ込んでいる人がいるから」とかは全然関係ないと思うが。
自分のしたい話の主題と相手のが異なっていてお互い上げ足取り(あるいは
頭が固い)みたいに見えるだけ。(人間見たいものしか見えない)
netnewsなんか長文+恣意的引用コメント文化だったからもっとひどかった。

実装や設計に文句言うのは簡単。

もっと言うと、他人がやったことに文句言うのは簡単。

ウチの会社に、トリッキーで、自分にしか読解不能なプログラムを作る奴がいるんだが、
そいつに「おまえのプログラムは分からん、読解不能」って言ったら、
「それは、おまえのレベルが低いから」などとヌカシやがった。

こういう勘違い野郎が一番困る。

そういう勘違い野郎のコードは、そいつが席を立ったタイミングで誰にも何も言わずに
「外部からの利用に何の影響も出ないように」書き直します。

文句を言うのは勘違い野郎だけですから。

コメントは銀の弾丸ではない。やたらと書けば幸せになれるってもんじゃない。

必要なら、100行であろうと書く。アスキーアート使ってでも書く。
仕様書が虚空に消えても保守できるくらいに書く。来年の俺でも
理解できるように書く。来年入ってくる新人でも理解できるように書く。

そして要らとこには、書かない。コードが説明責任を果たしているから。
そういうときには、IDEが自動生成するのに任せてしまえばいい。
引数と例外くらいは列挙してくれるだろう。してくれない？ そのIDEは捨てろ。

しかし、だ。

Assert.assert(arg > 0); // 無能なプロジェクトには存在しない表明のコード

表明用のコードが無いんなら、せめてコメントで表明しろ。

@param 1以上の値

世界的な常識だ。というか、唯一絶対の真理だ。
颯爽と人の道を踏み外して微笑んでんじゃねえぞ。

おまいら他人が書いたコメントを信用するのか？
もれは絶対に信用しないぞ。

馬鹿なコメントでも無いよりましなときもあるよ。
何を勘違いしたかの手がかりになれば、同類のバグとかって芋ずるに出来るときとかあるし。

なんていうか、馬鹿が書いたプログラムよりは、馬鹿が書いた日本語のほうが１mm程度は正解に近いかもと。

冒頭でどーんと複数行コメント書いてそれっきりというのは確かに信用できないな。ｗ
ソースは短い方が読み易いが、階層は浅い方がメンテし易い。
例えば初期化するブロックに５行ぐらい関数が並んでて、各々その中で何かやってると。
その５行をさらに「initializeHoge()」という名前の関数にまとめて無理矢理１行にし、
「初期化」というコメントを書かなくていいようにするよりは、
その５行のブロックの先頭に「初期化」って書いとけば済むような。
それに、その５ステップぐらいはその場で見えた方が読むのも早いし。

>>598
その場に書いてあるのが一番早いってのは否定しないけど
initializeHoge()の定義がスクロールキーを一回押すだけで見える
になっていても駄目ですか？
エディタのタグジャンプ機能は？
>>87に書いてあるようなプログラムは？

読みやすいプログラムを書くには、まず文章力が必要です。

コメントは、文章につける注釈であったり、読めない漢字の振り仮名だったり
します。ひらがなに、振り仮名する人はいませんよね。

文章に口語調があったり、文語調があったり、するように、プログラムにも同様のことが
あります。ですから、レ点がついた漢文のようなものは止めて欲しい。

条件文での込み入った、判定処理は、マクロで記述します。マクロ名を適切につければ
それだけで、機能は十分説明つくはずです。

ちなみに、章立てして文章が書けない人は、プログラムでもまともな関数を書けないようです。

>600
おまえのソース晒せよ

Java的コメントは
throws宣言をつけるべきときはつける。
それだけでもコメントの何割かを書いたことになる、こともある。

>>602
つうか、JAVAならJavaDoｃに従え。

つうか、PGはSEに従え。

コメントは道路標識と似ている。
「踏み切りあり」とか「横断歩道あり」とか「飛び出し注意」とか「駐車禁止」とか

適切な正しい道路標識によって運転はより安全になる。
それ以前に安全な道路があることが前提となるが。

適切な正しいコメントがあれば保守も楽になる。
それ以前に理解出来るコードがあることが前提となるが。

どうりで東京の道路はコメントだらけで、わけがわかんないはずだ

>>600は章立て以前の問題

○句点の位置がどう考えてもおかしい
○思いつきで改行するのはやめて下さいネ

読点だった

はぁ・・・疲れてんな・・・漏れ・・・

>>603
従ってる。
さらにCVSにも従おう。
コメントつける手間を省くためにJakarta Velocityを使ったりIDEのテンプレートをつかったりすると
なお良い。

>>609
べろしてーがコメントと何が関係あるのか、圧死には里香射できませんが。

一年後の自分自身が即座に理解でき修正や流用ができるような
ソースとコメントとドキュメントを書こうと思ってる
その時の集中にまかせて無茶苦茶書くことがあるけど
まともに動き出してから、それで終わった終わったではなくて
できるだけわかりやすく直していかないと
自分自身反省点多い

全部見てないから既出かもしれないけど
嘘コメントにだまされるのを回避する工夫はある？
勘違いとかじゃなくて、コード継ぎ足してコメント修正忘れたりってやつね。
これはわかりやすいとかそういうレベルじゃないよね。

若造はやっぱりだまされて一日無駄にしたりするんだよね。。。

>>611
ドキュメントはコメント以上に嘘が多くなる確率が高いんだなぁ。

できる奴は最初からコメントやドキュメントに頼らないし
できない奴はだまされたり、わかったつもりで満足したりするし
「わかりやすさ」を目指すのって無駄なんじゃないかなと思うときもある。

>>613
できる人もドキュメントからやらないと、結局はぐちゃぐちゃになるよ。
ドキュメントなしでバージョンアップが繰り返されたプログラムは、
無駄に画面が多くて、交錯してて、あとから画面遷移図なんて書けない。
IC回路図みたいになっちゃうから、書けたとしても人間の頭で認識できない。
プログラム上はなんでもできるからって、なんでもやるのはまずいと思う。
できるからこそなんでもやっちゃう。裏技みたいな使いまわしとか。
ドキュメントから入ると、ドキュメントが書きやすいように
設計するから、そのような問題はなくなる。
ドキュメント上ですっきりした設計なら、プログラムもすっきりする。
業務用の場合は業務構造が主体だから、プログラムが凄くても、
それが業務整理に繋がってないと意味ないんだよね。

>>612-613
「嘘コメントにだまされるのを回避する工夫」
コメントを信じないこと。コメント削除フィルタを作ることもある。（言語によっては結構難しい）

「ドキュメントはコメント以上に嘘が多くなる確率が高いんだなぁ」
そうだね。一箇所でもソースと違っている個所が発見されたらだけど、
プログラム構造、プログラム内インターフェース、ロジック、変数説明
などのコーディング直前のドキュメントは全く見ないことにしている。

新人らしくていいなココ
ほのぼのするよ

>>616
「デスマでギスギスしているような香具師はこないから」ですかね。
それとも「わかりやすさなんていう定量的な評価が出来ない特性には関心がない」
なのかな。

>>614
極論すぎ。
ドキュメントが「わかりやすい」必要はないだろってことだよ。
そいでもって「わかりやすさ」が必要な人には中途半端があだになる。

ソースがコメントでありドキュメントであり仕様書である

>619
それ賛成ｗ
でも客はうんとは言わない罠

>>619
ということにしたい

>>619
今まで何十年もプログラマはそのように主張してきたが、
保守性の高いコードを書いたためしが無いというのが現状。

>>618
さっそく意味不明。「あだ」の要件が定義されてない。

>>599
> initializeHoge()の定義がスクロールキーを一回押すだけで見える
> になっていても駄目ですか？

そういう機能を前提に考えるなら全部グローバル関数で作っても同じだと思うんだが。
従って、その機能に頼ってるとグローバル変数に頼るCOBOLerのような汚い設計にならないかな。
全員が常にその開発環境使うなら問題ないんだろうけど。

関数分割についての話題が出てきたのだが、
１関数（メソッド）あたりの行数について
１画面に表示できる範囲だとか、長くても100だとか、短くしろといわれるのだが、
１度しか使われない関数は作るなとも言われる。
この辺はどうなのでしょう。
長いという理由だけでわざわざ関数分割をすると、それぞれの関数の命名
に苦労するし、特に分割するような区切りがない場合（例えばＤＢから
フォームに表示するたくさんの内容を引っ張ってくるなど）でも、分割
したほうがいいのですか。

エディタを使って下記の内容のバッチファイルを作って、”c:\”に保存します
ってどうやればいいのですか？エディタの出し方がわかりません。お願いします。

test.bat

:start
goto start

ありがとうございます
これを打つのですか？

>626
そーゆー質問するときはせめてOSくらいは書くように。

俺の環境ならシェルでviもしくはemacsだ。

エディタを使って下記の内容のバッチファイルを作って、”c:\”に保存します。ファイルの名前は、”lsic.bat”とします。

set PATH=c:\lsic330c\bin;c:\lsic330c\temp;%PATH%
cd c:\lsic330c\temp

”set PATH=”というコマンドで、MS-DOSはファイルを探すときに、まず、カレントディレクトリを探し、なければこのコマンドで指示したディレクトリ（フォルダ）を探すようになります。カレントディレクトリとは、現在開いているフォルダのことです。

上記の文の２行目はカレントディレクトリを”c:\lsic330c\temp”に変更せよというコマンドです。

大変失礼しました。　上記のようなことを行いたいのですがお願いします。
ＯＳはＷＩＮＤＯＵＳ2000を使ってます。

訂正　WINDOWS 2000です。

>630-631
ファイル名を指定して実行でnotepadを起動すればいいだろうに。

今度からそういう質問はこっち（↓）でしてね。
スレッドを立てるまでもない質問雑談スレ13
http://pc.2ch.net/test/read.cgi/prog/1065814199/

>>625
> １度しか使われない関数は作るなとも言われる。
抽象化の概念に真っ向から対立してるな

（´-`）.｡ｏＯ（何か�dでもなく板違いなﾔｼが…)

ありがとうございます、参考になりました。
本当に感謝してます。あと忠告も守ります。

（・∀・）ｲｲﾖｲｲﾖｰ

あと最後に
set PATH=”というコマンドで、MS-DOSはファイルを探すときに、まず、カレントディレクトリを探し、なければこのコマンドで指示したディレクトリ（フォルダ）を探すようになります。カレントディレクトリとは、現在開いているフォルダのことです。

上記の文の２行目はカレントディレクトリを”c:\lsic330c\temp”に変更せよというコマンドです。

とはどういうことを意味しているのでしょうか？教えていただけませんか？

緑髪メイドロボがいるな

無計画にその場凌ぎ行き当たりばったりでコーディングしてくから
途中で収集がつかなくなる。
思考の整理が出来ていないことは容易に想像できる。
モジュール化も全然要領を得ていないし、「モジュール化の意味はあんまよくわからないけど、
とりあえずモジュール化してみました」みたいなモジュールがゴロゴロある。
思考の整理、分類がヘタクソだから、そいつはコーダーとしてはおろかＳＥとしても無能である。
それはつまりＩＴ業界において無能だってことだ。しかもシステマティックに考えられていないってことは、
今の時代、どこの業界に行っても無能で平均以下の働きしかできないだろう。
思考の整理もできていない、モジュール化もド下手では、とりあえずプログラムは動いても、
小さなバグが連発するし（あっちを直したらこっちがバグるの繰り返し）、
システムに柔軟性は皆無。細かな追加機能や仕様変更など出来やしない。
プログラムってのはそれを書いた人間の性質が良く出るからな。
上記のような穴だらけのプログラムを書く奴は私生活も穴だらけだ（笑）。無計画で無頓着。
人間として無能だと思っても良い。

639相当たまってそうだね。
たぶんいつも会社で同じような事言われてるんだろうね。
なんか可哀相だ。
みんなで励ましてやろうよ。

>>639
釣りなのかマジなのかわからんじゃないか（ｗ

分類って難しいんだよ。
そういう学問もあるし。

コメントもプログラムなの？
コメントもバグるの？
コメントもテストしないといけないの？
誰か教せて

test

Visual Basic 、Visual Studio、Visual C#、Visual C++
と様々なソフトがありますが、違いを教えてください。
Visual Basicと Visual Studioの言語は何ですか？

>>645 くだ質へ行けよ。
http://pc.2ch.net/test/read.cgi/prog/1065814199/

コメント、仕様書、共になし。これ最強。

>>643
コメントはプログラムじゃない

コメントはバグらない。だから大嘘が書いてあることもある

コメントはテストしなくともいい。
コメントだけを追記したソースはobjモジュールのバイナリ比較を行い、
一致してれば、再テストは不要。

そういや、昔、コメント消したらうまく動いたCのプログラムがあった。

それはコンパイラがタコなんだろ。

　int a = 15, b = 15;

　// a = a / 10 * 10;
　a /*= 10;

　// b = b * 10 / 10;
　b */= 10;

　printf( "a=%d, b=%d\n", a, b );

>>651
嘘だろ。代入演算子に「/*=」や「*/=」なんてあるのかよ。

>>651 別のパターン。
int i=10;
int *a=&i;
int b;
b=30/*a;

コメントは

#

にして、プリプロセッサディレクティブは

@

にすりゃ良かったんだよ。

>>652
ねたにマジレスかこ悪い。

っつーか、>>651は別に間違ってねーだろ。
C言語で//コメントを使うことについては別にして・・・・

>>653 は使えねー香具師だな。ﾌﾟ

>>655
>>653の「b=30/*a;」のが単なる除算なのか、それともコメント開始記号があるのかを教えてくらさい。

かっこを揃える。

System.out.println("aaaaaaaaaaaaa"　　);
System.out.println("aaaaaaaaaaaaaa"　);
System.out.println("aaaaaaaaaaaa"　　　);
System.out.println("aaaaaaaaaaaaaa"　);

これはずれてるけど、まあ、そういうこった。

>>657
ダサイ。超ダサイ。今時、非プロポーショナルなエディタでしか通用しない
「揃える」なんてこと超流行らない。無駄。キモイ。修正が面倒になるだけ。
String HOGE=
"asfasdfasdf"+ // foo
"adfasdfa"+ // bar
"afsad"+ // fooo
"asfasfasdfasfasdfaf"; // barr

こういうときに、無駄な労力でコメントを揃えたりしてるのか！？（哄

気の利いたIDEだったらそもそも揃えられない気がするが。
いまだにインデントとかで苦労してるのか？

「いで」って何ですか？

頭悪そうに見えるからひらがなで書くな！　漢字で書け！

>>660
ほら、科特隊の。

>>662
古杉っ！

いるねぇ〜新人で658みたいなの

>>658
複数行にまたいで記述するとき=や+の演算子は行末じゃなく行頭だな。
で、コメントは揃える。
お前の書いたソースは全部直させることになりそうだ

>>665
細かいこと気にしていると禿げるぞ

>>666
細かいところに気が回らない奴はプログラマにならなくていいよ。

>>667
禿げるならプログラマなんかにならないよ

細かい所に気が回る俺は、
if(!get_pointer()) は禁止して、
if(GetPointer()!=NULL) と書かせていますが何か？

オブジェクトにNullableインターフェイスを実装させて、
if(! GetPointer().isNull())と書き、
可能な限りNullオブジェクトにロジックを移すのが普通です。

>>665
演算子を行末じゃなく行頭というのにどのような根拠があるのか知らんが

少なくともコンピュータサイエンスの論文の数式では行末に演算子を置く
（＝などは例外だが）

行頭に演算子置くと行の追加・削除が楽

if (
a |
b |
c
)

とかだとc以降に追加したくなったときとかは
cとそれ以降を編集する必要がある。

if (
a
| b
| c
)

とかだとcは編集しなくていい。

くだらね

つうか、絶対書かないことを議論してもね・・・。
>>672に関して言えば、根本的にどっちも糞。

>>674
つまりお前はどんなに長くなっても絶対に行を分割しないと言うことだな。
そして、どのような場合でも条件にはコメントを付けないと言うことだな。

>>672
ラインエディタ常用してるの？

ラインエディタってなんだよ？

( ﾟДﾟ)ﾊｧ?

俺はcopy conでプログラム書いてるYO！

>>672
a を削除してみろ

>>677
もしかして、エドりん
しらんのか？

今時、えどりん･･･　懐かしくて涙が出る。
よくあんなモンで仕事してたよな。

>>680
672じゃないけど、aを削除することってめったにないよ
printfとかね。

あ、if文だったか。
printfの場合は
printf("書式"
,b
,c
,d
);
みたいなこするよね？ね？

>>684
悪いけどそれは…

しねーよ

ここは「修正間違いを起こしにくいソース」スレじゃないぞ。
「わかりやすい、上手、美しい」のテーマとは方向性が違うじゃねーか。

関数のはじめに↓こういうの↓を書く。どんどん装飾華美になっていくが。
//‥。　　　　　　　　　　　　　　　　　　　　。*
//　☆★　┏━┓┏━┓┏━┓┏━┓┏━┓　★☆
//　　☆★┃メ┃┃イ┃┃ン┃┃関┃┃数┃★☆
//　☆★　┗━┛┗━┛┗━┛┗━┛┗━┛　★☆..
//"　　　　　　　　　　　　　　　　　　　　　　*

>>687
それは洗練された美しさとは程遠いな

>>687
そのうち色を付けたいっていう不満を持つようになると見た

俺もここ見て気持ちがかわった
面倒だけど今日から日本語の部分バイナリーにするよ

//　000000　83 81 83 43 83 93 8A D6　90 94
void main()

慣れてきたら文字コードもレアなのにするね
これで俺もついに、あすきーてきすとが書けるぜ！！！

>>687
すばらしい！　プログラミングが楽しくなりそう
そのうちＡＡとかも導入したいね

>>691
例外来たー！とか書いてあるのか？顔一回転して。
処理待ちは猫が茶飲んでたり。
メッセージはメッセージまだーって茶碗をチンチン。

>>690
ついでにmainもint main()に変えることを勧める

必死こいてゴミを作ってるような気がしる・・・・＿|￣|○

>>692
（・∀・）ｲｲ!

就職してからずっと他人のゴミばかり修理している俺＿|￣|○
美しいソースが見たい

オブジェクト指向言語（Java)で、

// ○○関数
public void hogehoge() {
　　..................................
　　..................................
　　..................................
　　..................................
}

っていうふうに「関数」って文字列を発見するとムカツク。
しかもjavadocじゃない。
あと、モデリングされた形跡がないクラス群ほどムカツクものはない。
フィールド宣言だけで、3000ステップ。総ステップ数13000のJavaソース。
正直、メンテできねーよ。

>>697
なんとなく分かるわ。
ついでに、Javaの大規模システムは、できるだけ有名FW使ってほしいよな。

>>698
挙動が広く知られてるって意味じゃ有名なやつがいいだろうけど、
別に自社製フレームワークでも構わない。意味のあるクラス群ならば。

>>658
文字定数の連結に+つかうなよ・・・

>>610
Velocityでソースコード自動生成するならばワンパターンでいつも同じのばかりなコメントにも
Velocityをつかうべきだ

>>700
Cライクに連結演算子抜きで書けと？しかしJavaには連結演算子しかないのだぞ？
それとも一リテラルに全部書けというつもりか？
文字列各行に意味があるからわざわざ分割しているのだと察っする心づかいは皆無なのか？
そしてあれだ。貴様。
ヒアドキュメントすら持たない貧弱なコンパイル言語のコンパイラが
必死でコンパイル時に文字定数の連結を最適化しようと進化してきたのを
蔑ろにする暴言を吐くのはその口か。恥を知れ。

ヒアドキュメントはインデントを壊す。

>>700
>>702
ちゃんと、javaコンパイラが置き換えてくれるから安心しろ。

誰でもすぐにソースコードを見られるソフトで、
ソースコードがきれいなのって何があるかな？

>>705
どんな言語を仮定してるんだ？

>>702
安心しろ。単なるVB厨だから。

うちは、激しく狭いので風呂の脱衣場はカーテンのみ。
こないだスッポンポンになってたら、いきなり父親にカーテン開けられました。
16歳にもなって、父親に全裸見られました。凄く恥ずかしかったです。
父は心臓が悪いのですが、娘の裸を見たショックで軽い発作を起こしやがりました。
だ〜か〜ら〜普段から、誰も居ないか開ける前に気をつけろと言ってんのになぁ…。
http://www.dfnt.net/t/photo/column/kabuto.shtml

>>706
特に想定はしていません。
「このプログラムのこのあたりが (こういう理由で) 美しい」
という意見があるといいなと思ったんです。実際に動いていて
使われているプログラムが例になってれば説得力があるので。

聞きかじりで申し訳ないんですが、例えば GhostScript とか
NetBSD がきれいだという話は聞いたことがあります。これは
両方とも C ですが、他の言語に関しても有名な例があれば
教えてほしいんです。例えば Java ではどうでしょう。

>>709
Java 2 SDK 自体は結構綺麗だと思うが

>>710
禿道。

jdkのソースをhackするのが比較的良い。

>>710,711
なるほど。Java SDK は盲点でした。
読んでみようと思います。

プロは始めからリリースモードで作成する。
原因が特定できないバグが発生した時、
初めてデバッグモードに切り替えデバッグする。
素人はデバッグモードで作成し、リリースモードに切り替えると
動かないプログラムを作り上げる。
素人はそれをデバッグせずに納品する。

>>713
それって何の言語処理系のこと？。もしかしてM$が出しているやつ？

713はprintfデバッガ使い

>>716はOutputDebugStringデバッグ使い

↑一人突っ込み？

良スレなので上げます。

>>713
まじレスしてくれると有り難いんだが、それ普通じゃないの？

マジレスするが、プロなら原因が特定できないようなバグは発生しない。

age

条件によっては必要ないこともある変数とか処理を書かない。
本人はちょこっと修正して対応できたと思ってるかもしれないけど
これってスパゲッティでしょ

スパゲッティ＝処理の流れが複雑に絡み合っていること。

急ぎ、調査しています。知恵を貸してください
？は k　を　表してますよね。？は何を表すのでしょうか？
スペースでしょうか？明日、朝までに解読する文書が有り。ここが判らず困って
います。宜しくお願い致します。

すれ違いかも知れませんがしってる方いたら教えて下さい。

>>724
＞？は k　を　表してますよね。？は何を表すのでしょうか？
こちらWinXP+A Boneだが、↑こう見えている。
他人にも分かるように書け。

＞７２６　
すいません。ちゃんと打ってるのですが。＆＃６５３５５　＝　ｋ
＆　＃　１２２８８　　がわかりません。ちゃんと打ったんですが今度はスペース入れて打って
みました。　本当は繋がってkを表します。

＆　＃　６５３５３　＝　i　　
＆　＃　６５３５４　＝　ｊ
＆　＃　６５３５５　＝　k
と変換されますよね（全部スペース無）
＆　＃　１２２８８　が判りません、多分記号かスペースと思うのですが。
ちゃんと打っても　？　と表示されてます。コードだからでしょうか？

>728
IMEパッドで調べればわかるが、
＆＃12288＝ユニコードU+4800＝MS明朝等(日本の環境)では未定義。
台湾の繁体文字の1個という可能性は高そうだが。

729＞
スイマセンどうやれば判りますか？ここだけが解読出来なくて。
意味だけでも知りたいのです。これを書いた者は外国人です。
ロシア語、英語、ヒブン？(イスラエル文字）を使う者です。アルファベット
に気付くのにかなり時間がかかり、最後ここだけが判りません。知恵を貸して下さい。

12280から 12290まで変換しました。多分スペースの様です。
今、全文変換したところですが。文として意味が通りました。
やっと、ゴハン食えそうです。
ただ、こんなモノ普通使いますか？メールのアドレス帳に・・・
外国では、一般人もこんな事してるんでしょうか？別のナゾが・・・

>>729は、俺の勘違い
×　＆＃12288＝ユニコードU+4800＝MS明朝等(日本の環境)では未定義。
○　＆＃12288＝ユニコードU+3000＝いわゆる全角スペース。

よって、>>731で正解

＞ただ、こんなモノ普通使いますか？メールのアドレス帳に・・・
＞外国では、一般人もこんな事してるんでしょうか？別のナゾが・・・
漢字を打てない環境で漢字を表現するには、
そんな手を使うほかないでしょ。

>732
THANKS
とりあえず、前文繋がりましたので。意味も判り。
本人を助けてあげられそうです。

・・・曜日や時間帯とから判断するに、本当に緊急だったんだね
おれの生活と対比して考えられないような生活だなあ
とりあえずこれしかいえないよ
「よかったね」

>734
お蔭様で。今起きました。これで、諸準備をして、月曜日。朝一間に合います。
PCは、殆ど判らないのですが。情報理論等は必修でやっていたので。後、いい歳
なんで。むかしBasic で変換プログラムを課題でやったものですから。何とかなりました。

ふと、「【緊急】助けて下さい！【事態】」等というスレを作ったら良いのではないか、
と思った。首になりそう、遅れたら多額の賠償必至など、本気で緊急事態の香具師を助けるための。

そんな状況で2ch見ているのかと。

ていうか、なぜこのスレに書き込んだんだろう……？
単に上に上がってたから？


何のための質問・雑談スレなんだか(´ー｀)

マジに答えます。ある方を助けたく、その子のメモの一枚が & # XXXXXで
書かれていて初め全く判らず。昔を思い出し。アルファベットは自分で変換し
英文になってることが判ったのですが。最後が判らず。困っていて２chをみていて
スレ違いと思いましたが。ここが一番、適切な意見を貰えそうに見えて書きました。
マジで昨日はあせってました。詳細は、裁判に係わること故、今は書けませんでした。

漫画のユウスケみたいな方なのかな？

asdfasdf

20連結ユニオンクエリ、
5重ネストサブクエリ、

鬼！

>>742
なんかそんなSQL書くはめになったことがあったな…。

根本的に、DB設計が腐ってると思うがどうよ。ｗ

dataモデリング

カット&ペースト禁止
↑
これだけで君のプログラムもずいぶんよくなる。
試してみたまえ。

int hogeHoge ()
{
　if(a > 0)
　{
　　b++; //なんか処理
　}
}
------------------------
int hogeHoge () {
　if(a > 0){
　　b++; //なんか処理
　}
}

括弧の付け方てどっちが正解？
漏れは上のが解り易いけど、
初心者っぽいから下で書いてる。

int hoge()
{
　　if (a > 0) {
　　　　// なにかする
　　} else {
　　　　// なにかする
　　}
　　return 0;
}

俺はこう書くけど、どれが正解なんてないんじゃないかな。

>>746
それは大昔からの「スタイル論争」だ。
平気で他人の習慣に文句をつける人達がやってきて不毛な論争になる
あえて言うなら「どちらも正解」

>>745
言ってる事は正しいけれど、試してみる人がいるとは思えんな

>746
漏れは上のパターンですな。
下のパターンだと引数や条件式を縦に並べた時に、何か見苦しいモンで。（作為的な例↓）

　int hoge(
　　　int arg1,
　　　int arg2){
　　　if( arg1>0
　　　 || arg2>0 ){
　　　　　arg1+=arg2;
　　　}
　　　return arg1;
　}

　int hoge(
　　　int arg1,
　　　int arg2)
　{
　　　if( arg1>0
　　　 || arg2>0 )
　　　{
　　　　　arg1+=arg2;
　　　}
　　　return arg1;
　}

>746
うちは下。上下に間延びするのがヤなんで。

美しさなら上なのかも。
pascal の begin 〜 end の記法を考えると上のが近いか。
初心者向けのCの解説書も上のが多いね。
ま、どちらでもいいと思うんで、書きやすい＆読みやすいほうでどぞ。

>>747-751
レスありが�d
上の例は教科書みたいって馬鹿にされるかと思ってた。
どっちでも良かったと、じゃあわかりやすい改行多目のほうで書きます。
ステップ数も稼げる(ﾟдﾟ)ｳﾏｰ

> ステップ数も稼げる(ﾟдﾟ)ｳﾏｰ

いまどきステップ数て…（呆

>745
>カット&ペースト禁止

ｱﾌｫか？
藻前、元の場所に残しといたままにするのか？

Ｃマガジンに掲載されていた、フィンローダさんの記事です。

タブは８文字がいいとか、きれいな変数宣言の仕方とか、結構参考になりました。

特集　Ｃプログラミングの秘訣
http://www.st.rim.or.jp/~phinloda/cprog.html

>755
> タブは８文字がいいとか
これ、何処に書いてあった？
漏れには「4文字にしろ」しか見付けられなかったが

>>756
すいません、タブは8文字がいいというのは、Ｃマガジンの別の記事だったかも。

8文字だと1行が長くなりすぎる場合には、その関数に機能を詰め込み過ぎているから、
複数の関数に分割しろと書いてあったような気がします。

機能の詰め込みすぎという状況はコーディングスタイルで解決すべき問題じゃないと思う。
本人の問題は慣れで解決してください。でないと他人の迷惑になります。

> 8文字だと1行が長くなりすぎる場合には、その関数に機能を詰め込み過ぎているから、
> 複数の関数に分割しろと書いてあったような気がします。
これどう考えても屁理屈だよな。

>757
タブ8文字はリヌス(Linuxカーネルの作者ね)の推奨スタイルだったかと。

リヌス？

フルネームはボツ・リヌス

Javaなら整形ツール（Jacobe,Astyle等）を使えば万事解決。
どういうスタイルで統一するかでもめるけどな。

カッコとかのコーディングスタイルどんなスタイルでも大抵はＯＫ
ただ終始一貫してそのスタイルが統一されてればいい

居るだろ、同一人物が書いてるのに途中で
スタイルが変化する奴。たとえば普段は

if(x == 0)
　　hogehoge_func(hoge, hoge);

なのに、いきなり

if(x == 0) y++;

みたいなのが混在してる奴。

http://kmaebashi.com/programmer/hoge.html

>>764
ごめん、それやっちゃう。
y++;みたいな短いのは、行数節約？のために同じ行に書くんだけど、
横スクロールしなきゃいけなくなりそうなくらい長いのは、
改行しちゃう。

コーディングスタイルなんてたいした問題ではない。
てきとーに決めてそれを守るだけ。
設計レベルの話はしないのか？

>>767
・・・そりゃあね。してもいいんだけど。
二つの障害があるような気がする
１．強度と結合度という基本的な知識も無い奴が割り込む
２．構造化も充分理解していないOO厨／ﾃﾞｻﾞﾊﾟﾀ厨が割り込む

まあ、OOPしてない人間にOOP前提の設計を提示されても困るよね（W

>>768
構造化も理解していないOO厨/ﾃﾞｻﾞﾊﾟﾀ厨がどういうコードを書くのか例よろ。

頭の悪い奴ほどインデント小さい。

美しさならなんといってもハンドアセンブルだぜ。
誰がやってもまったく同じだもんね。
ハンドアセンブルは人の上に人をつくらず。人の下に人をつくらず。

>>746
上を使ってるっす。
DOSの時代は画面が狭かったから下使ってたけど。
別にどっちのスタイルでもいいんでない？

一番嫌いなのは三項演算子をネストするヴォケ。
a = b > c ? ( d > e ? f : g ) : h;
みたいな。

一番嫌いなのはif文をネストするヴォケ。

x =
a1 ? b1 :
a2 ? b2 :
a3 ? b3 :
a4 ? b4 :
...
ay ? by : bz;

美しいじゃないか。

まず、明日の自分がわかるソースを書く。

高級言語を使ってるのに、
コメント文がないと解らないようなコード書く奴は低脳。

>>775
明日はデスマ突入という事が分かりました。

プロ用の関数を作らない

>>776
そういうこと言うやつの大半は自己満足で完了してる
非常に読みづらいソースを書く。

とか煽る>>779の書くソースなんて、俺は見たくない。

lisperならC/C++でも3項演算子のネストはそれなりに使うと思うけど。

コメント抜きでも読みやすいソースを書く能力は色々なソースを読んだ経験とかなり相関がある感じ。

関数字下げをしない。

間違っても「ネスト」などという低域俗語を使わない。
**********************************************************
新和英中辞典 第４版 （研究社） 【入れ子】 の検索結果
キーワードに該当する結果が見つかりませんでした
http://www.excite.co.jp/dictionary/japanese_english/?search=%E5%85%A5%E3%82%8C%E5%AD%90&submit=+%E6%A4%9C+%E7%B4%A2+&match=beginswith
**********************************************************

コメントはプログラムを冗長にするだけなので、できるだけ避ける。「コメント不要のプログラム」が常識。

データの引渡しはグローバル変数を使い、引数だらけで醜いプログラムを極力避ける。

「構造体がかっこいい」などと勘違いして何でも構造体にする「構造体バカ」にならないように、極力構造体は避ける。
変数が ダラダラと長くなり、非常に醜い。

>>782
国語辞典で調べろよｗ

大辞林 第二版 （三省堂） 【入れ子】 の検索結果 [1 ？ 12 / 12件中]
http://www.excite.co.jp/dictionary/japanese/?search=%E5%85%A5%E3%82%8C%E5%AD%90&match=beginswith

こっちの方が良かったか？

新英和中辞典 第６版 （研究社） 【nest】 の検索結果 [1 ？ 6 / 6件中]
http://www.excite.co.jp/dictionary/english_japanese/?search=nest&match=beginswith&dictionary=NEW_EJJE

>>782
よくそんなコボラーになりきりできるね！
書いてて腹立たなかった？

>>782
こぼらーごっこですか？

コメントに何をやってるかは書かなくてもいいけど、
どういう仕様を実現しようとしたのかは書いてくれ。

i = 1; //iに1を代入

>>782
そーいうネタを書くと、そーいうプログラムの保守の仕事が来るぞ

switch（）をなるべく使わないように心がける。
それだけでかなり変わってくる。
いつしか、switch（）見ただけで吐き気がするようになる。

このスレ頭から読んでつかれました。
プログラム経験はCを初めて書いて丸一年です。
とりあえず最近自分でいろいろソースコードを読んでいて思うのは、
読みやすいソースコードってのは…
・横スクロールなしで読める。（譲れない）
・無駄に縦のスクロールもしなくていい。
・スタックのメンバはpreとかprevとかっていうように決まりきった名前はそれを使う。
・変に（<-これ重要）関数を分離していない。一回しか出てこない関数はつくらない。
・関数の階層関係がしっかりしている。
・遅くてなにしたいのかもわからないループになるくらいならgoto使った方が増し。
・わかりにくいbit判定はマクロになってる。（一変数にフラグを詰め込んでるとか）
・日本人しかいないプロジェクトでなぜかコメントが狂った英語になってたりはしない。

番外編
・switchで書けるところを沢山並んだifで書かれてたりしない。（うちの学校こういうのがいる）
続く…

（続き）
その他思うこと
・未来の自分や他人がわかるか不安なところはHACK.txtとかつくってまとめとけばいいと思う。
・Cでどの書き方がいいか迷ったらコンパイラで変換されたときのことを考えればいいと思う。
・仕様書とか書くようなプロジェクトはやったこと無いけど普通に方針とか処理のだいたいの流れ図
くらいは書くべきだと思う。
・スタイルが気にくわないならindentとかのツールを使って、
文句いわずに勝手に変換して読めばいいと思う。
・上の方では関数にしか触れてないけどOOPにしたって階層・依存関係おかしいのはやっぱりダメだ
と思う。
（TCP<-POP3 ならわかるけど、TCP<-UDPはおかしい。おかしいのにたまにこういうのを見る。
この例そのまんまはさすがにないけど)
・たとえ行き当たりばったりなプログラムでも、
同じようなフレーズが何度も出てくるようになったらそれは当然のごとく関数化する。
または、マクロに出もする。
・透明性の高いFOPもできないやつはOOP使っても同じ。むしろ悪化する。
・ソースコードを暗号化して企業の秘密なりを守りたい人は勝手にスパゲッティーコードなり好きに
書けばいい。（んなモンわかっていりゃ買うわけ無いが…）


多分にCに片寄っててスマソ。

>>792

おまえとは仕事したくない。

>>791-792
だいぶ間違っているけど、もっと経験を積めば正しい方向に修正可能だ・・・と思う
コードのスタイルと、プログラムの構造を混同して考えないことを助言する

せっかくだから添削してやれよ。その添削も添削されたりして。

・横スクロールなしで読める。

右端で折り返せ。

・スタックのメンバはpreとかprevとかっていうように決まりきった名前はそれを使う。

スタックのメンバって何だ？ 決まり切った名前は、いい事だ。C++のbeginとかendとかもそうだね。

・遅くてなにしたいのかもわからないループになるくらいならgoto使った方が増し。

「遅くて」と「何をしたいかもわからない」は無関係。関係ない事柄を並列に並べるな。
gotoを使ったら速くなるわけじゃない。
何をしたいか分からないループはgotoにしても分からないだけだろう。

・わかりにくいbit判定はマクロになってる。（一変数にフラグを詰め込んでるとか）

そもそも1変数に詰め込むな。しょうがない時はマクロが確かにいいかな。

・未来の自分や他人がわかるか不安なところはHACK.txtとかつくってまとめとけばいいと思う。

設計書書け。コメントなら別のファイルにすると更新がしにくいだけだろう。

・Cでどの書き方がいいか迷ったらコンパイラで変換されたときのことを考えればいいと思う。

「考える」じゃなくて確認しろよ。定量的に評価する事。

・一回しか出てこない関数はつくらない。

一つの名前を付けて物事を表すと言うのが重要だ。

・たとえ行き当たりばったりなプログラムでも、同じようなフレーズが何度も出てくるようになったらそれは当然のごとく関数化する。

add()とか作るのか？ 関数はタイプ削減ツールじゃない。

・透明性の高いFOPもできないやつはOOP使っても同じ。むしろ悪化する。

透明性の高いって何だ？ 一般的でない用語を不用意に使わない事。
FOPってなに？検索しても関係ないのがたくさん当たるが。

>>795-796
おまえ意外に親切だなｗ

>>796

おまえと仕事したい。

>>790

今までswitch使うようにしていただけにショック。

なんでswitchだめなの？
分かりやすいと思うんだけど。。。

>>799
switch()使って問題ないだろ。

>>790は変なこだわりがあるんだろ。

うれしがってポリモーフィズムを使ってそうな悪寒。

ポリモーフィズムと呼ばずにアームドフェノメノンと呼んでくれ。
バルルル、バルルルゥ。

>>795
> ・横スクロールなしで読める。
>
> 右端で折り返せ。
それでもやっぱり読みにくいことは読みにくいけどね。

switchはgoto（ｒｙ

breakやcontinueはgoto(ry

まぁそんなこといってたらコンピュータ内部なんてJUMP、JUMPで
じゃんじゃんぷだぞ。そんなに気になるならプログラムなんてやめちまえ！

最近はMDAへの移行期にはいりつつあるし
ソースを綺麗に書くかどうかは問題にならなくなってきている

・設計書書け。コメントなら別のファイルにすると更新がしにくいだけだろう。
テスト作れ。コメントはテスト側に書け


・「考える」じゃなくて確認しろよ。定量的に評価する事。
シンプルに汁。それだけ


・一つの名前を付けて物事を表すと言うのが重要だ。
名前ぢャねー、メタファだろ。


・add()とか作るのか？ 関数はタイプ削減ツールじゃない。
シンプルに汁。それだけ


・FOPってなに？検索しても関係ないのがたくさん当たるが。
もれもシラネ

横スクロールしてもいいから、他人が見てわかる名前付けろ。

>・遅くてなにしたいのかもわからないループになるくらいならgoto使った方が増し。
ｱﾌｫか?
もまえプログラム書くのやめとけ(w

>>808 とは仕事したくない。

>>809
うちの上司は、「変数名には読んで意味がわかる名前を付け、コメントには
その変数が意味するところを必ず書け」と言い、
SumOfEstimateSubTotal とか DatePrintedInvoice　などと極端に長い名前を付けさせる

でもたしかにコード全体は横に長くなるが、他人が描いたコードを１ヵ月後に見ても
きちんと意味がわかるし以前 iとか jなどと描いていたやつよりバグが減っていて、
結果的によくなったような気がする。
漏れが洗脳されているだけのような気がするが、こういう記述はよくないのか？

関数内のローカル変数にあまり長い名前を付けるのは逆効果のような・・・

俺は変数のスコープに合わせて名前の長さを決めろって昔言われたな。

俺が言われたのは
二度と読み返す必要のない完璧なコードを書け!


俺が思うのは
誰も読む気が無くなるぐらい複雑でも完成されたコードを書くべし!

>>813
俺もそうしてるな。
スコープが広くなるほどくどい名前にして、ローカル変数のカウンタみたいなのは
i, j k, にしてる。

まあ、おっさんだからCode Completeを読んで以来あんまり考えてないけど。

iは複素数用に定数としてキープしてあるからな。
漏れ使えないー。

>>813>>815
�dクス。上司とそのことで話し合う時間をとってみるわ（話が通じない人じゃないので）。
まあ、カウンタは i, jにしてるが、以前誰かのコードを見たらネストが深くなるほど
i, ii, iii...にしていてﾜﾗﾀことがある。

>スコープが広くなるほどくどい名前にして
うちではスコープが広くなると p_...、g_...みたいなプリフィクスをつけてるけど
そういえばうちにもCodeCompleteはあった（よんだことないけど）ので、
あとで読んでみよ。

>814
>誰も読む気が無くなるぐらい複雑でも完成されたコードを書くべし!
シンプルに汁! それだけ

find()ってグローバル関数はちょっといや

完成すぎるコードは常人には理解できんのだよ。

常人に理解できないコードは不完全なのだよ。

>常人

素人は含んでないぞ、念のため(w

素人とプロの違いは何ですか?専門卒派遣PGはプロですか?

例えば、物理学者には相対性理論が非常に完成されたものに感じることができる。
一般素人や低級な学者にはその美しさが理解できない。

それと同じで、

完成されたコードは素人や低級なプログラマーには

理解できない。

前提がおかしいから結果もおかしい。

相対論が分からない奴にはその美しさが分からないのと同じで、
コードも理解できなければ美しさが理解できない。

当り前の事だな。

>>814
勝手に完成されたコードかいてればいいよ。

俺のちかくにいないならな。

>>817
実は、オイラi,ii,iii・・・・というのをやってたんだが
検索かけるときに特にiの検索がうまくいかなかったので
今ではi1,i2,i3・・・・にしているよ。

i, j, k, l, m, nかな。lは見難いので使わないけど。

その前にループを分けることを考えろよ…

何でもいいからさっさと動くプログラムを作れっ。

>>815
CodeCompleteという本はそれほどタメになるのか？
もし有意義だったら一度読んでみようかな。

>>799
オレは、switch()の存在そのものが悪だと思ってる。
世の中にあるswitchの殆どがテーブルに出来るし、テーブルの方がスッキリ組めるよ。
switchは処理で表を作る。
テーブルはデータで表を作る。
処理＝コードはなるべく少なくするってのは基本。「表を正しく処理できるロジック」を組めば、後の仕変はテーブルの変更で対応できるのが大きい。
switchだと処理だから、ソースなので追わないと判らないけれど、テーブルはデータなのでプログラム判らないヤツが見てもわかる事もあるしね。

文法的にバグを作り出す要素が多いのもダメだな。
まずbreak;の存在がダメ。ループのbreakなのかそうじゃないのか区別付かない。break付け忘れバグと、わざとbreak付けなかったのか、ソースを完全に追わなければ理解できない。

あとこれは絶対ではなく経験則なのだが、switchを不用意に使うやつは、どんどんcaseに処理を継ぎ足していく事が多い。
caseを羅列していくのって、どこからどこまでがcaseなのか見難い。上のbreakの事も合わせて、バグを作り出す要素、見つけにくい要素が揃ってる。
仕方なく使うならまだしも、率先して使うようなら、逆にテーブルよりswitchが優れてる理由を>>799がオレに教えてくれよ。

switchごときで鼻の穴を膨らませられる>>831に乾杯!

>>831
switchによる分岐をテーブルに置き換えるというと、
関数ポインタの配列みたいなイメージになるの？
だったらswitchのほうがシンプルでわかりやすい状況も多々あると思うが。

ネタに反応してもな。

>>831
に書いてる配列を用いた面倒な処理を無くすためにswitchが存在するんじゃないの？

まーね。つっこんで考えていけば、while文があればfor文は実現できるし、
else if 文があればswitch case 文は実行できる。case文はまれにbreakされないで
そのまま直下の処理を実行する書き方をするけど、まあ、それはもともとトリッキーな
コードの内に入るから推奨はされていないが。

「わかりやすい」プログラムは、やはりコメントの質が最重要かな。
適切なアルゴリズムやモジュール設計がなされているっていうのは前提条件でしょ？
そこがﾀﾞﾒだと、わかりやすいと美しいなんて段階じゃないし。ていうのが俺的見解。

>>815
古いが、コードの書き方(詳細設計から単体検証くらいまで)がうまくまとまっている。
納得行かない所があるだろうが、そのような意見もあると言う事が分かって勉強になる。
リファレンスも整っているけど邦訳が無かったり絶版だったりするんだよな。

これ自体は読み物だから一度読めばいいかな。

>>815でなくて>>830だ。

局所的にはシンプルなコードが良いコードかな。
コード量が少ないという意味ではなく、単純という意味でね。

>826
何故カウンタに対し検索をかける必要があったのか教えてクレ。

他に変えるべき所があるんじゃないか？

>>833
条件によって実行する項目にあんまりにも差分が出るようなら、ジャンプテーブルにすべきなんだけど、あんまりジャンプテーブルを使う場面は少ない。
状態遷移をするようなプログラムなら、ジャンプテーブルはswitchより有効なのは明かだ。
しかし、それ以外の場合、大抵はテーブルの内容を工夫したり、呼び出す関数のインタフェースを考える事で解決する事が多いよ。

>>835
経験的に、面倒な処理になる事は少ない。

いつもこの「switch使わない方がいいって」という話をすると、大抵、反発が起きる。
この板ではもうちょっと強い反発があるのかな、と思ったけどネタ扱いされたかな。

>>840
激同
そもそもループがネストする時点で、ロジックあるいはプログラム構造を疑うべきだ。

一番外のループはテーブルAのインデックス値のループ、
中のループはテーブルBのインデックス値のループ、
その中のループはテーブルCのインデックス値のループ……

なら、
（１）まず、そのようなループをする意味があるのかどうか再検討
（２）ループを関数化できるかどうか検討(ループそのものに単独の意味があるなら関数化すべき場面だと思う)
（３）しょうがないなら、indexTableA、indexTableB、indexTableCとでも名前を付けて３重ループ処理を行う
かな……

コマンドラインオプションの解釈を行うような
switch(option){
case 'd':
debug_flag = 1;
break;
case 'v':
varbose_flag = 1;
break;
}
といったコードでも関数テーブルを用意するのか？

>>790 とだけは仕事したくないな。せめてswitchくらい使ってくれ。そうすれば、わかりにくい変数名だらけのオマエのプログラムも、少しは まともになる。

>ループのbreakなのかそうじゃないのか区別付かない

字下げで区別できないじてんでプログラマー失格

>843 そんなコード、ifだけで十分だろが(w

>>845
ifとgoto駆使して頑張ってくれ。

goto ?
ｱﾌｫか

UnitTestさえちゃんとやっとけば
局所的なコーディングなんてどうでもいい話。
プログラム全体の上手さとは無関係。

（注）↓みたいな土方コーダを除く

ばれた？ｗ

>>848
その意見はシステムテストさえちゃんとやっていれば
単体テストはどうでもいいと言っているようなもんだぞｗ
局所的なところも全体的なところもそれぞれ大事だ。

>>841
「switchをジャンプテーブルに変更した方がいいコードもある」
を
「switchはジャンプテーブルに変更するべきだ」
と勘違いしちゃうタイプだろ？

>>850
>その意見はシステムテストさえちゃんとやっていれば
>単体テストはどうでもいいと言っているようなもんだぞｗ
ぜんぜん違いますが。

switchよりも多態を使え

>>852
どう違うのか言えないようじゃ、反論になりません。

システムテストはうにっとtestでできませ〜ん

>>855
UnitTestは局所的なコーディングのテストでは出来ないので同じことですね。

というか855意味不明。

>856 はぁ?

UnitTestをやっていても局所的なコーディングがどうでもいい話にはならないだろ。
局所的なコーディングには名前付け規約とかインデントとかコメントとか含まれるが、
それらはUnitTestじゃテストできん。
>>848は馬鹿ってことでFA

>>858
理解できない馬鹿は帰っていいよ。

>>859
土方呼ばわりされたくらいでムキにならんでも

ドカタ呼ばわりされた848が必死ですｗ

848 ：仕様書無しさん ：04/05/16 01:15
UnitTestさえちゃんとやっとけば
局所的なコーディングなんてどうでもいい話。
プログラム全体の上手さとは無関係。

（注）↓みたいな土方コーダを除く


849 ：848 ：04/05/16 01:18
ばれた？ｗ

>>861
そういう煽り無しでまともに話が出来んのか？
そんなことじゃ例え正しいことを言っていても
誰にも信用されないぞ。

>860
局所的なコーディングのテストってのが
>名前付け規約とかインデントとかコメントとか
って事なのか?

ならｽﾏｿ、理解できないバカでいいや

>>864
テストというのはコーディングミス以外のテストも含まれるってことだよ。
仕様自体に間違いがないか調べるのもテスト。
きれいな書き方が出来ているか調べるのもテスト。

>きれいな書き方が出来ているか調べるのもテスト

afo

まあ上手なプログラムと言われて設計を思い浮かべる人もいれば
命名規則・コーディングスタイル、コメント、switch・gotoを思い浮かべる人もいるわけだが
どれか一つにこだわってるやつはあふぉ丸出しってこった。

>>848
メンテで儲けようという考えも浮かばない程の技術馬鹿なのか？

というか>>848とか局所的なコーディングの重要性が分からん奴ヤバイよ。
UnitTestが出来ていればいいと考えるのは明らかに変。
UnitTestの目的の一つのリファクタリングは
局所的なコーディングをきれいにするための技術だろ。

>UnitTestの目的の一つのリファクタリング

ばーか
リファクタリングするのにUnitTest使うってだけの事だ、よーくお・ぼ・え・と・け

>>843
ちゃんと読んでくれてないでしょ。
＞８４１
＞状態遷移をするようなプログラムなら、
＞ジャンプテーブルはswitchより有効なのは明かだ。
＞しかし、それ以外の場合、大抵はテーブルの内容を工夫したり、
＞呼び出す関数のインタフェースを考える事で解決する事が多いよ。
とあるように、ジャンプテーブル自体、オレは推進してないんですよ。

大体、コマンドラインオプションの解釈の場合こそ、テーブル使うべきじゃない？
１つのコマンドラインオプションで複数のフラグを立てたり、内部処理の順番を変えたりするような場合、データテーブルの構成を変える方が全体のプログラムをスッキリさせると思うんだけどね。

まぁその程度の例であればif〜elseを使ったほうがいいという>>845のレスに賛成。

>>870
同じ事じゃん。

>>844
あんた頭腐ってるね。

while(1){
　if(flag){
　　break; (1)
　}
　switch(index){
　case(0):
　{
　　break;　(2)
:

の、(1)と(2)の「字下げ」、同じじゃないの？
プログラマ失格だってさ。へえーー。

>>870
局所的なコーディングをきれいにするのがリファクタリング、
リファクタリングをするのにUnitTestを使う。
局所的なコーディングが重要だからUnitTestを使ってリファクタリングをする。

ＯＫ？

>>851
君にも>>871と同じレスします。まともに読まずにレス返してるね。
オレはジャンプテーブル推進してないってばさ。そう読める記述があれば抜き出してレスよろしく。

やっぱり、ヒステリーレスが多いかな。ウヒヒ。

もく‐てき 【目的】
--------------------------------------------------------------------------------
1 実現しようとしてめざす事柄。行動のねらい。めあて。「当初の―を達成する」「―にかなう」「旅行の―」
2 倫理学で、理性ないし意志が、行為に先だって行為を規定し、方向づけるもの。
--------------------------------------------------------------------------------
[大辞泉]　


リファクタは UnitTestで"めざす事柄"ぢゃねー