2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

1 :仕様書無しさん:03/11/04 00:46
『他の人が見て用意にソースが追える。』
『あとでメンテナンスや、機能追加しやすいしやすい。』
プログラムを作成する上で、
上手で美しいプログラムを書く為に、
どのようなことを、気をつけていますか?
心がけていますか?

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

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


2 :仕様書無しさん:03/11/04 00:46
2

3 :仕様書無しさん:03/11/04 00:48
いるな、読む気も失せるプログラム書く奴
そんな奴のプログラムに限って
うまく動かなくて(あたりまえ)
上司から「お前、ちょっと見てやってくれ」って言われる
すごい、苦痛

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

ということで、2ゲット


4 :仕様書無しさん:03/11/04 00:55
最低限、インデント汁!
頼むから面をそろえて書くのはやめて〜!

5 :仕様書無しさん:03/11/04 00:58
こんな過疎板で2ゲットやるやつがまだいたとは(w

6 :仕様書無しさん:03/11/04 00:58
>>1
まず、誤字を無くす所から始めような。

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

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

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

9 :仕様書無しさん:03/11/04 01:08
1. 用意にソースが追える
2. 追加しやすいしやすい
3. データの授受は引数を使う

ま、こんなとこかな。

10 :仕様書無しさん:03/11/04 01:26
>>1
単刀直入に言うと、XP, RUPを導入しろ。

11 :仕様書無しさん:03/11/04 02:16
if文を使わない方法を考える

12 :仕様書無しさん:03/11/04 02:21
おじいちゃんソース見づらーい

そんあときー

「インデントー」

これでスキリーだねおじいちゃん




ムカッ

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

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

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

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

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

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

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

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


14 :仕様書無しさん:03/11/04 04:19
コメント文はとりあえず重要だと思う。

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

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

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

15 :仕様書無しさん:03/11/04 07:40
>>13-14ってスゲーずれてるって思うの、俺だけか?

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

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

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

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

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

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

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

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

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

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

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

20 :仕様書無しさん:03/11/04 09:04
このスレでレスしている香具師はXPも知らずなんとレベルの低いものが多いのだろうか。

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

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

21 :仕様書無しさん:03/11/04 09:44
フラグの多用がダメっていうけど、
具体的にどういう風にフラグを使うのが、ダメなんですか?

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


iFlg = 0
for(iLC = 0; iLC < 500; iLC++){



if (条件) {

   iFlg = 1;
   break;
}



}

if (iFlg == 1) {

  何か処理;

}

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

22 :仕様書無しさん:03/11/04 09:52
とりあえず、まずは翌日の自分が見て判るコードかな?w


23 :仕様書無しさん:03/11/04 09:52
もしかしてブーリアンをビットフラグにマップしろって言いたいのか?

24 :仕様書無しさん:03/11/04 10:01
int i; // int型変数iを宣言と定義
++i; // i をインクリメント

25 :仕様書無しさん:03/11/04 10:11
>>21 突込みどころ満載だけど、
フラグに話題を絞ってレスすると以下
int iLC;  // ループカウンタ

for(iLC = 0; iLC < 500; iLC++){



if (条件) {
    some_processing(/*仮引数群*/);
    break;
}



}




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


26 :仕様書無しさん:03/11/04 10:15
仮引数と実引数が反対ですか?

27 :25:03/11/04 10:35
>>26 ご指摘の通りです。失礼しました。

28 :仕様書無しさん:03/11/04 11:15
>>21の将来のために
もっと突っ込んであげましょう。
あなたの、愛のムチで

29 :仕様書無しさん:03/11/04 11:18
if (0 == hogehoge){
}
って書かれているのを見ると、ムカツクよな。

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





30 :仕様書無しさん:03/11/04 11:24
またこいつか!!

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/




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

32 :仕様書無しさん:03/11/04 12:00
0か1かのフラグならBOOL/boolで宣言して
代入はTRUE or FALSE/true or false
比較は if ( flg ) / if ( !flg ) の方向で

33 :仕様書無しさん:03/11/04 12:20
具体的に>1はどんなコードを書いてるの?見てみたいな

34 :仕様書無しさん:03/11/04 12:56
>>29>>31

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



35 :仕様書無しさん:03/11/04 13:45
>>34
この話題は、お前のような馬鹿をあぶりだす役に立つな(w

36 :仕様書無しさん:03/11/04 13:49
>>35
バカはお前だ。
この手のことは、危険を回避するためにやるんだよ。
テメーができるできないとは別問題。


37 :仕様書無しさん:03/11/04 14:57
>>36
恥の上塗りはその辺にしとけよ(プ

38 :仕様書無しさん:03/11/04 14:58
ハンガリアン記法についてフレームするスレはここですか?

39 :仕様書無しさん:03/11/04 15:09
羹に懲りて膾を吹く

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

if (fp == NULL)

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

41 :仕様書無しさん:03/11/04 15:15
つーか、警告レベル上げとけよ。

42 :仕様書無しさん:03/11/04 15:26
またこの話かよ(w

43 :仕様書無しさん:03/11/04 16:07
他でもあったの?

44 :仕様書無しさん:03/11/04 16:11
>>41
禿堂

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

45 :仕様書無しさん:03/11/04 17:24
何でもかんでも外部変数に押し込む奴はたいていVB厨だな。


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

46 :仕様書無しさん:03/11/04 18:38
>45
VBはそういう類のワーニング設定がないからなー。

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

47 :仕様書無しさん:03/11/04 20:23
>>36
チェックの手間を惜しんでたら、バグ出すよ。

48 :仕様書無しさん:03/11/04 20:25
>>45
自分のことですね。

49 :1:03/11/04 20:45
言語は基本はVB
あとはCを使うこともある

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


50 :仕様書無しさん:03/11/04 20:48
やっぱ、他の人が、自分のプログラムを読んで、
読みやすい、解りやすい、って言って貰えるとうれしいよね。

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

51 :仕様書無しさん:03/11/04 20:51
>>21
コードの検証が面倒になるから。
5本のフラグ使った場合には単純計算で最大32通りのパターンを流す必要あるし。

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


52 :21じゃないけど:03/11/04 21:10
>>51

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

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

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

53 :仕様書無しさん:03/11/04 21:10
> 5本のフラグ使った場合には単純計算で最大32通りのパターンを流す必要あるし。
フラグやめて他のに変えても結局パターン数は変わらないわけだが。

54 :52:03/11/04 21:14
表現がまずかった。

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

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


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

56 :仕様書無しさん:03/11/04 21:34
flagをやめて固定の組み合わせを持つテーブルにする
proc_table[type]();

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

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

57 :仕様書無しさん:03/11/04 21:37
>>1
ネストのレベルは最大3。百歩譲っても4。

58 :仕様書無しさん:03/11/04 21:40
関数のネストも考えてくれ

59 :仕様書無しさん:03/11/04 21:42
再帰を使ってはだめなのか?

60 :仕様書無しさん:03/11/04 21:47
再帰はいいが、
A関数の中でB関数よんでB関数の中でC関数よんでC関数のなかで・・・
ってやられると頭がパンクする

61 :仕様書無しさん:03/11/04 21:50
そんな凄まじい相互再帰があり得るのか?

62 :仕様書無しさん:03/11/04 21:51
>>61
コボラーの作ったソースはそんなんです。
引数で処理されているものでないので、IOだけを知っていればという代物ではないのです。
(;´д`)

63 :仕様書無しさん:03/11/04 21:52
1関数=1機能
ってのは常識だと思うんだがコボラーさんは、
引数の値で動きを操作するように関数内のロジックがくまれているのでげす。
(;´д`)トホホ

64 :仕様書無しさん:03/11/04 21:53
>A関数の中でB関数よんでB関数の中でC関数よんでC関数のなかで・・・

ハェァ?普通ジャン?

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

66 :仕様書無しさん:03/11/04 21:58
>>64
普通じゃねーな。
A()

 戻り値=B(引数)
 戻り値=C(戻り値を引数にしたり、なんかしたり)
 戻り値=D(戻り値を引数にしたり、なんかしたり)

だろ。

67 :仕様書無しさん:03/11/04 21:58
>>65
if 文のネストのことじゃないか?

68 :仕様書無しさん:03/11/04 21:58
普通、関数は自分の呼び出し元や自分が呼び出す関数を意識せずにすむように作るだろ。
それが出来ていないということは、関数のネストが悪いのはなく、
全体の設計がゆがんでいるのが原因では?

69 :仕様書無しさん:03/11/04 22:00
>>68
汎用関数ならな

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

70 :仕様書無しさん:03/11/04 22:01
>>66
ハェァェァ?普通ジャャャャン?

71 :仕様書無しさん:03/11/04 22:02
>>66
おれもそうやる。
関数内関数の乱用はパーツ化ができていない証拠だな。
中に抱き込むと関数内の修正がでたときひどい目にあう。

72 :仕様書無しさん:03/11/04 22:04
すまん
関数内関数ってPascalくらいしか思いつかないのだが…

73 :仕様書無しさん:03/11/04 22:07
>>72
関数内関数はC++でもCでもできるよ。
でもここでは関数の中で関数をコールするのを深く深くやるのはやめてくれーっていってんでしょ?

74 :仕様書無しさん:03/11/04 22:11
ヲレも関数内での自作関数のコールネストは3を限界にしてる。
関数の中での関数コールは、関数内において小さい修正が入ると悲しいことになるし。

75 :仕様書無しさん:03/11/04 22:15
ソースの規模を確認しておこうか

76 :仕様書無しさん:03/11/04 22:15
メイン関数からメインループ関数に入って、その中で自作関数読んだらそこで終わり?

77 :仕様書無しさん:03/11/04 22:17
自作関数の中で自作関数を呼ぶってのを深くやってるようなやつは、関数と呼ぶよりオブジェクトと呼ぶほうがいいよ。
うちのCOBOLERも似たようなことやってる。
結果、同じようなサイズのでかいオブジェクトプログラムが大量にある。
びっくりすることに引数によっては、その中の5%くらいしがコードが有効にならないものまで(w

78 :仕様書無しさん:03/11/04 22:17
>>71 >>73

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

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

79 :74:03/11/04 22:18
>>76
ちゃう。区切り目ってもんがあるやろ。区切り目ごとをサブメインととらえてそっから3つ。

80 :仕様書無しさん:03/11/04 22:21





      引 数 は 3 つ ま で





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

81 :仕様書無しさん:03/11/04 22:23
>>80
それきっつい・・・。

82 :仕様書無しさん:03/11/04 22:23
>>81
そんなもんだろ

strncpy(dest, src, size);

83 :仕様書無しさん:03/11/04 22:23
>>77
それは、そういう設計レスなプログラムが根本原因。

84 :仕様書無しさん:03/11/04 22:24
英語ネイティブの感覚だと4つ以上は「たくさん」なのです。


85 :仕様書無しさん:03/11/04 22:24
引数三つまでとか、関数コール三つまでとか、なんつーかアホだね

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

86 :仕様書無しさん:03/11/04 22:28
>>85
引数3つまでってのは Effective Java の著者も言ってるけどな
オブジェクト指向言語の場合はインスタンス名と合わせて実質4引数だが

87 :仕様書無しさん:03/11/04 22:29
>>73
>関数内関数はC++でもCでもできるよ。
嘘だろ。多分、お互いの「関数内関数」の認識が違うんだ。

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

88 :仕様書無しさん:03/11/04 22:30
自作関数コール3っつまでってネタでしょ?

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

89 :仕様書無しさん:03/11/04 22:31
>>87
それは >>87 の視点で読みやすかったか?
可読性のための抽象化なら許容できる

90 :仕様書無しさん:03/11/04 22:32
>>88
さあ?
平面展開がお得意の COBOLer が訳の分からないこと言ってるんでしょ

91 :仕様書無しさん:03/11/04 22:34
でっけープログラムの10年20年選手ものだと自作コールの3つってのも気持ちわかるなぁ。
細かい修正に修正が重なるとひどいことになる。

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

93 :仕様書無しさん:03/11/04 22:37
一回作っておしまい。って感じの仕事しかしてないならわからないと思うし、その場合はネスト3なんか考慮の必要ない。

94 :仕様書無しさん:03/11/04 22:38
const使えないやつは美しいプログラムなど書けない

95 :仕様書無しさん:03/11/04 22:38
>>92
そういうソースを書かないためのスレじゃなかったのか?

96 :仕様書無しさん:03/11/04 22:39
>>95
そだな・・・・。

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

98 :仕様書無しさん:03/11/04 22:42
どちらにせよ・・・・・・・俺も>>66の書き方だな。
Aをオブジェクトとして、A関数がB、C、Dをコールするように作る。

99 :仕様書無しさん:03/11/04 22:42
>>92
ネストしたループをくくり出して別関数にするとお前には怒られる訳か?

100 :仕様書無しさん:03/11/04 22:43
オブジェクトって、どういう意味で「オブジェクト」なんだ?

101 :仕様書無しさん:03/11/04 22:44
>自作関数の中で自作関数を呼ぶってのを深くやってるようなやつは、関数と呼ぶよりオブジェクトと呼ぶほうがいいよ。

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

102 :仕様書無しさん:03/11/04 22:45

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

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

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

A:無難なサーバー。 お勧め!!  
 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/  

B:ある程度の障害は大目に。  
 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/

103 :仕様書無しさん:03/11/04 22:48
昔からある巨大プログラムを扱っている人と最近のプログラマーとの戦いだな。(w

104 :仕様書無しさん:03/11/04 22:52
>>99
cobolerのいう関数って言うのは、cでいう実行型マクロに近いものだよ。おそらく。
少なくとも単体でコンパイルできるソース単位ではないと思う。
だから「展開」とかいう単語が出て来るんだよ。

105 :仕様書無しさん:03/11/04 22:53
自作関数ネスト3までと言ってる方の使用している言語を教えて欲しいなぁ

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

が!

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

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

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

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

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

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



108 :仕様書無しさん:03/11/04 22:59
それから関数クラスは山ほど作りたい派かな。
小分け小分けにしたほうがメンテしやすいと思うけど。

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


109 :仕様書無しさん:03/11/04 23:09
きれいなプログラムを書くために心がけるべきことは…
「いきなりコーディングしない。ちゃんと設計してから作る」
だろ。

110 :仕様書無しさん:03/11/04 23:10
>>109
正論

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

112 :仕様書無しさん:03/11/04 23:13
>>109
基本はね。
ただ、設計段階踏まずに捨てプログラムを作らせても、
きれいなコードになってる奴と行き当たりばったりの
コードになってる奴がいるんだよな。

113 :仕様書無しさん:03/11/04 23:15
Cに関して,
どちらも中級者以上には基礎的過ぎるだろうが…

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

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

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

114 :仕様書無しさん:03/11/04 23:17
func(char *src, ...)
func( "..." );
これは通るけどね


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

116 :仕様書無しさん:03/11/04 23:27
>>114
gcc は通るな
警告レベルが低いのかな

SunOS の cc とかどうよ?

117 :仕様書無しさん:03/11/04 23:30
>>116
"string"は互換性のために、型はchar*になる。

118 :仕様書無しさん:03/11/04 23:34
>>117
なるほど

119 :仕様書無しさん:03/11/04 23:37
>>115
K&R の 2版を見たが,確かに const は付けていないな
標準ライブラリ関数を man で見れば大抵は const 付きだが

120 :仕様書無しさん:03/11/04 23:38
>>117
g++ でも通ってしまうのな…

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

122 :仕様書無しさん:03/11/04 23:48
VB使いな>1はこのレベルについていけず逃げたようだな。

123 :VB使い:03/11/04 23:53
>>1ではありませんが、全然ついていけません

124 :仕様書無しさん:03/11/05 00:02
>>123 言語仕様知らなきゃ、ついてこれるはずがない。

125 :仕様書無しさん:03/11/05 01:24
変な技巧に凝らずに、素直にプログラミングするのが、
一番分かりやすく、美しいプログラム。

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

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

126 :仕様書無しさん:03/11/05 01:26
>>125
かといって必要以上に愚直なプログラムもDQNだよな

何事もほどほどが肝心

127 :仕様書無しさん:03/11/05 01:34
>>125-126
少しレベルが高い話をしているね。
どっかにも書いたけどぴったりの格言があるんだ。
「不即不離」

128 :仕様書無しさん:03/11/05 01:39
関数内関数だけど
前提条件がない関数なら、いくらネストしてもOK。
そうでないなら1レベルでも絶対駄目ってのは当たり前?

129 :仕様書無しさん:03/11/05 01:46
>>113 こんなのが職業プログラマでいることが信じられない
状況はよくわからんが、他人のプログラムの単一の欠点だけ発見して、
へぼと決め付けるのイクナイ場合多いと思う。
(特に小ネタ覚えたてのプルブラマにこの傾向が強いとおもふ)

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


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


131 :仕様書無しさん:03/11/05 01:54
つづき

マジレスすると、他のプルグラマ達とは仲良くしてお互い精進するのが良いと思われ。

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

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

132 :仕様書無しさん:03/11/05 01:55
129=131 ね

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

134 :仕様書無しさん:03/11/05 01:58
人にクソテク/ウル技を濫用されても別に構わんというか気にならない
そいつに合わせればいいだけだし

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

135 :仕様書無しさん:03/11/05 02:06
>>130
ちょっとまて。嘘つくな。
わずか千回の「関数呼び出し」で「数十秒の差」?
一回の「関数呼び出し」に数十ミリ秒もかかっている計算になるぞ。
いったいどんなCPU使えばそんなに時間がかかるんだ。

136 :仕様書無しさん:03/11/05 02:10
↑漏れもそう思う。。
千回数十秒のオーバーヘッドのかかる関数呼び出しコストって・・・。
こんなCPU使ってたらC++やJavaみたいな高級言語はぴくりとも動かんな。

ほんでコンパイラのこたよく知らないけどそんなに呼び出しコストがかかるんなら、
短い関数はインライン展開されるようなオプションとか使うとえんちゃう?

137 :仕様書無しさん:03/11/05 02:19
130たんガンガレ(・∀・)

138 :仕様書無しさん:03/11/05 02:28
Z80とかZ80とかZ80とか?

139 :仕様書無しさん:03/11/05 02:38
>>130

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

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



140 :仕様書無しさん:03/11/05 02:41
最適化厨はRISCプロセッサが主流になってますます威厳がなくなったわけだが

141 :130:03/11/05 02:49
1000回というのは少なすぎだが
1000×1000回すると10秒の差は出る。

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

143 :仕様書無しさん:03/11/05 02:56
100万回実行で10秒程度なら可読性を上げたほうがいいと思うよ。
ゲームや組み込みならまた話は別だが。

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

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

144 :仕様書無しさん:03/11/05 06:07
>>20
若いな。若いうちはやたら関数化する。身に覚えがある。w
意味もなく関数だらけにして崩壊し、
2000万の赤字で解散したとある部署のソースを見た。
まして、ただ単に分割する目的で作った関数など
ソースを見難くするゴミでしかない。
「関数」と呼ぶにふさわしい意味のある関数だけにしよう。

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

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

146 :仕様書無しさん:03/11/05 07:48
10MhzのCPUの場合。

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

147 :仕様書無しさん:03/11/05 09:24
// 醜悪なコードの例
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);
}

148 :仕様書無しさん:03/11/05 09:28
ミスった。宇宙ヤバイ。
- if(isHait()) {
+ if(isHate()) {


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

150 :仕様書無しさん:03/11/05 10:21
>>149
いらない。

151 :仕様書無しさん:03/11/05 10:21
>>147
「isHate」って単語しか可読性の向上に寄与していない。
//優雅なコードの例
if ( isHate() ) {
 hoge();
}

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

152 :仕様書無しさん:03/11/05 10:28
>>151
この醜悪な言語は何?

153 :仕様書無しさん:03/11/05 10:31
>>150
(´・ω・`)ショボーン
生徒の提出課題を読みやすくするために10分で作ったソフトなんだけどね。
大学の非常勤講師やってます。

154 :仕様書無しさん:03/11/05 10:35
宗教戦争が勃発しそうなスレはここですか?

155 :仕様書無しさん:03/11/05 10:38
>>153
Winの方は知らないけど、
gccが動くunix環境ならcbとかindent(こっちはすごい)
っていうコマンドがすでにあると思うぞ。

156 :仕様書無しさん:03/11/05 10:41
>>154いいえ。
cobolerがcobolの感覚でレスして、「ずれてる」とか言われるスレです。

157 :仕様書無しさん:03/11/05 10:52
>>155
そんな便利そうなコマンドが。。今度調べてみます
Win一辺倒だったので、UNIXは詳しくないんです。

158 :仕様書無しさん:03/11/05 10:56
>>151
関数の中が糞かと。

159 :151:03/11/05 12:02
>>158 うん。おれも書いてて「クソだな」って思った。

160 :仕様書無しさん:03/11/05 12:48
はてさて

161 :仕様書無しさん:03/11/05 13:40
ふむー

162 :仕様書無しさん:03/11/05 14:14
>>160,161
『できるかな』の歌をこんなところで書くな!!

163 :仕様書無しさん:03/11/05 14:21
>>160
>>161
「はてはてふむー」じゃなかったのか!

164 :仕様書無しさん:03/11/05 14:43
はてはてはほー

かと思った

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

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


166 :仕様書無しさん:03/11/05 15:11
最初のデザインに失敗すれば全て台無し

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

168 :仕様書無しさん:03/11/05 15:41
2ch見てるとデキの悪い奴って結構いるんだなぁ〜って思う

169 :仕様書無しさん:03/11/05 16:10
あーたのむ 誰か暇な奴、上のレスを箇条書きかなんかでまとめてくれ
そんで、出版しよう みんなで小金もちになろう(  ̄ー ̄)


170 :仕様書無しさん:03/11/05 16:12
【解り易い】上手なプログラムを書くには【美しい】 by マ板の皆さん
出版社 2ch出版

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

172 :仕様書無しさん:03/11/05 16:32
優雅なコメントの書き方をご教授願いたい。

173 :仕様書無しさん:03/11/05 16:38
>>172
/* 20031105 これからマキシムでお食事なので今日はここまで */

174 :仕様書無しさん:03/11/05 18:19
関数型言語一回使ってみろよ

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

176 :151:03/11/05 18:37
>>171 うん。そうだね。
最後の2行は全面的には同意できないけど。
「設計書」ってどのような内容の設計書を意味しているのかな?

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

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

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

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

181 :仕様書無しさん:03/11/05 21:57
Cで関数の引数に、
/* (IN) */
とかいちいち書くんじゃなく、 const 付けろ。

182 :仕様書無しさん:03/11/05 22:05
値渡しの変数に const 付けるのはアホらしいしな

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

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

というソースを

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

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

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

背筋が凍るね。

184 :仕様書無しさん:03/11/05 22:25
>>183
それは何カ所からも呼ばれるからだな

185 :仕様書無しさん:03/11/05 22:26
値渡しの変数はそもそも
/* (IN) */
なんて書く必要すらない

186 :仕様書無しさん:03/11/05 22:29
>>185
そうだな

187 :仕様書無しさん:03/11/05 22:36
>>183
結局、呼ばれた関数で条件文を書き下すわけだが。

188 :仕様書無しさん:03/11/05 22:36
built in typeにconstをつけると馬鹿呼ばわりされるぞ。

189 :仕様書無しさん:03/11/05 22:39
引数で値を戻すときはretとか書かなければならない仕様だったら良かったのに。

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

191 :仕様書無しさん:03/11/05 22:46
だから情報処理技術者試験を受けろと。

192 :仕様書無しさん:03/11/05 22:47
スレタイトルの「わかりやすい」と「上手」と「美しい」って
必ずしも等価とはいえないと思うが、そこらへんどうよ?
(すべてを満たすプログラムがないとはいわないが)

193 :仕様書無しさん:03/11/05 22:57
たしかにジョーズは美味いとは思わない。

194 :仕様書無しさん:03/11/05 22:57
誰もオブジェクト指向には触れないのか?

195 :仕様書無しさん:03/11/05 23:07
>>194
スレの方向とは微妙に違うからね。

196 :仕様書無しさん:03/11/05 23:35
>>192
「わかりやすい」
これが再優先

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

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

197 :仕様書無しさん:03/11/05 23:55
「わかりやすい」 「美しい」
読み手のレベルによって異なる罠

198 :仕様書無しさん:03/11/06 00:00
そうでもないよ。

199 :仕様書無しさん:03/11/06 00:46
書き手に、読み手としての経験がないと、なにがわかりやすいかを正しく判断できないというのはあると思う。
変数全部にコメントつけろとか……。


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

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

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


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

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

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

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

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

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

初期処理では主にこんな事やってまーす。というのが解るようにする。
単に2、3行のソースだったとしても関数化する。
データアクセス、イニファイル読み込み、コントロール設定、初期表示

汎用的でなかったとしても大まかに細分化する事でコードは読みやすくなるし、テストがしやすくなる。



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


203 :仕様書無しさん:03/11/06 05:24
gotoを使うべきところでは使う。

204 :仕様書無しさん:03/11/06 06:05
bool ishoge(const int & num) { return ( 0 >= hoge && hoge >= 9); }

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

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

205 :仕様書無しさん:03/11/06 07:44
VBむずい、読めない意味わからない
助けてください

206 :仕様書無しさん:03/11/06 09:40
うつくしさだけなら、コピペで作ったスイッチ文とかいいよね。
スクロールすると波打つように流れる。w


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


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

209 :仕様書無しさん:03/11/06 10:01
素直に勉強不足で知りませんと言えよ。

210 :仕様書無しさん:03/11/06 10:07
混沌の申し子といえばPerlでしょう。

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

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

213 :211:03/11/06 10:31
 ∧||∧  精進します……

214 :仕様書無しさん:03/11/06 10:35
>>191そうではない。「勉強しろ」と言いたいだけ。
二種なんかの試験に出てくる知識ってのは、
技術者として知っていて当然だと思うから。
#知識が血肉になっていればもっといい。

215 :仕様書無しさん:03/11/06 11:56
>>211>>212
その辺りの話はVB5、VB6、VB.netで全部仕様が違うから。



216 :仕様書無しさん:03/11/06 12:41
VBは本気で難しいと思う
互換性って意味を真っ黒ソフトさんが知ってるなら
若干話は違ってくるが

217 :仕様書無しさん:03/11/06 15:34
>>201
早すぎる最適化は諸悪の根元だと Knuth 先生が仰いました
あと Jackson 先生は
素人は最適化するな,専門家は明らかに最適化されていないと分かるまで最適化するな
と仰いました

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

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

こんぐらいかな?



219 :仕様書無しさん:03/11/06 16:51
>>217
アルゴリズムうんぬんよりも、まずは最適化するべきかどうかの見極めからだな。


220 :仕様書無しさん:03/11/06 17:48
20代の若者には分からないかもな。脳が若いから。
30近くになって、記憶力や同時に把握できる量や体力や目が弱くなってくると、
それでも把握できるソースが欲しくなる。

221 :仕様書無しさん:03/11/06 18:04
>>217 作る前の話だよね
>>219 作ってから、アプリ側にレスポンスのボトルネックが発生したときのはなし?

222 :仕様書無しさん:03/11/06 18:10
>>220
で、まだ書いているの?だったらわかりやすいコードだろうね。
それとも、書いていなくて、部下のコードに文句をつけているだけ?
だったら部下が設計する前に「指針」を渡さなきゃ駄目駄目だよ。

223 :仕様書無しさん:03/11/06 18:14
最適化だってよ
おい
笑わせるな〜

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

225 :仕様書無しさん:03/11/06 18:20
>>61
> そんな凄まじい相互再帰があり得るのか?
相互再帰はCompositeパターンの常識

226 :仕様書無しさん:03/11/06 18:23
>>222
書いてるよ。
20代前半の時のソース見ると宇宙人が書いたのかと思う。
超パズルになってて自分で理解できない。
当時は500行ぐらいのファイルを30個ほど頭に入れた状態でできたらしい。
今は1個のプロシージャさえ頭に入りきらない。w
だからちょこまかコメント書いたり、関連するものが離れたところに行かないようにしたりする。
空白行の入れ方にも必死になったりする。

227 :仕様書無しさん:03/11/06 19:42
>>224
粘着は恥ずかしいよ。下らん思い込みもほどほどにな。

228 :仕様書無しさん:03/11/06 19:55
VB厨が粘るな

229 :名無し@沢村:03/11/06 20:06
>>207
>わざわざ無駄な変数を宣言して

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


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

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

以下に例を示す。


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

231 :仕様書無しさん:03/11/06 20:19
>>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));

232 :仕様書無しさん:03/11/06 20:20
また、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);
どうだ? 引数の数が減っただろう?

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


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

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

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

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

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

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

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

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

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

237 :仕様書無しさん:03/11/06 21:17
>>236
> >233
> 「一般常識」ではなくて、それはsunのjavaのコーディング規約だろ。
Smaltalkの規約もJavaとほとんど一致しているぞ。

238 :仕様書無しさん:03/11/06 22:07
>>236
>世の中に数多あるコーディング規約は大方これに準拠していることは認めるけど
おいおい、それを一般常識といわずして何と言う?

239 :仕様書無しさん:03/11/06 22:24
>>233
なんだ、唯のプログラム厨か。

240 :仕様書無しさん:03/11/06 22:24
>>234
学んでどうするのかな?

241 :仕様書無しさん:03/11/06 22:25
>>235
オブジェクト指向と、そうでないプログラムの違いをもっと勉強しよう。

242 :仕様書無しさん:03/11/06 22:30
>>231
技を使う必然性と、メリット・デメリットも考えよう。

243 :仕様書無しさん:03/11/06 22:38
>>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));


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

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

245 :仕様書無しさん:03/11/06 22:50

honya.excute(this);

public void excute(Hoge hoge)
{
this.x=hoge.getX();
this.complex=hoge.getComplex();

}
きっちりとgetterを使うのが正しい

246 :109:03/11/06 23:03
>>234
#ひょっとしたらだいぶ前にもアナタとワタシは同じような問答をしたかもしれない

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

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

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

247 :仕様書無しさん:03/11/06 23:03
>WinAPIやPHPのDB関連関数のように使い辛いものになるのは当たり前のことで、

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


248 :仕様書無しさん:03/11/06 23:04
コメント行に顔文字をふんだんに散りばめる香具師がいるんだけど
おかげで誰がコーディングしたのか一発でわかる。
ワーク領域( ̄ー ̄)ニヤリ、 処理成功(*゜ー゜*)b など・・

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

249 :仕様書無しさん:03/11/06 23:16
>>231
それはバグの温床になるのでは?
(スーパープログラマーだけで作ってるのならかまわないだろうけど)

250 :名無し@沢村:03/11/06 23:29
凡人が考えると、変数が3つで済むような場合、変数が5つ必要と考えるのが、一流のPG。

251 :名無し@沢村:03/11/06 23:37
つまり5/3の法則よ。
凡人が考えると、処理に必要なステップ数が4の場合、天才が考える必要なステップ数は7。
凡人が考えると、必要な関数の数が8の場合、天才が考える必要な関数の数は13。
凡人が考えると、コーディングに必要な行数が11の場合、天才が考えるコーディングに必要な行数は18。
天才は頭の構造そのものが複雑だから、そうなるんだよ。わかるかな?

252 :仕様書無しさん:03/11/07 00:15
すいません、>>231-232 が非常に香ばしいんですが。
OOP を単なるテクニックだと思っているんだろうか…?

253 :仕様書無しさん:03/11/07 00:52
>>231
OOPは現実に則しているからうまくいくのであって
小手先のプログラミング技術を駆使することでうまくいくわけではない

254 :仕様書無しさん:03/11/07 09:21
つうかXP厨うざい。
こういうのって、入社3〜5年目で新規の案件しかやったこと無いからだろうね。

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


255 :仕様書無しさん:03/11/07 09:33
なに言ってんだか。

256 :仕様書無しさん:03/11/07 09:36
新しいことを覚えたくないオッサン必死の遠吠え

257 :仕様書無しさん:03/11/07 09:39
>>254
全くだ。俺はOOP厨もうざい
自分の知識を披露したいがために、「ずれた発言」を拾ってきてレスつけてるやつが何人かいる。

258 :仕様書無しさん:03/11/07 09:56
>>254
いやぁ、231あたりは複素数を例題としてたりするので、業務経験ないのではないかと。

259 :仕様書無しさん:03/11/07 10:01
>>258
学生だとしても研究の経験もなさそうだしね

260 :仕様書無しさん:03/11/07 12:45
なんだよ おまいら
学生にまけてんじゃん
ぷっ

261 :仕様書無しさん:03/11/07 13:02
勝ち負けって・・・、XP厨、OOP厨の彼が、それを受け入れないプロジェクトに参入したときに
どのように振舞えるかが知りたいけど。

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

262 :仕様書無しさん:03/11/07 15:21
>>260
研究経験もない学生が吠えてるだけ
説得力の欠片もないよ

263 :仕様書無しさん:03/11/07 16:12
「いきなりコーディング」
賛成。でもそれが出来る奴だけに許可してくれ。

264 :仕様書無しさん:03/11/07 17:48
>>262
どこに研究経験もない学生が?
ノイローゼですか?

265 :仕様書無しさん:03/11/07 17:59
>>264
まぁ熱くなるなよ

266 :仕様書無しさん:03/11/07 18:01
>>265
そういうセリフは>>262にいいなよ。

267 :仕様書無しさん:03/11/07 18:31
学と業 両方持ち合わせたやしはいないっつーことですかね。

268 :仕様書無しさん:03/11/07 19:20
所詮は理系じゃなくて工学系なんだからさ。
業に適わなければ学もへったくれもない。

269 :仕様書無しさん:03/11/07 19:23
というより、ここのXP,OOP厨は学としても厨房レベルなのが問題では。

270 :仕様書無しさん:03/11/07 20:46
>>269 そだね
特に、学のXP厨なんてその存在すら認められない。
実践抜きで、書籍からの知識のみでほざいてるってことだからな。

271 :仕様書無しさん:03/11/07 20:50
このスレの流れ

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

272 :仕様書無しさん:03/11/07 21:06
COBOLとOOP,XPしか習ったこと無いというのはかわいそうだ。

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

274 :仕様書無しさん:03/11/07 23:12
10進数(小数)の2進数への基数変換はなぜ2をかけて1越したのを拾ってるんですか?
理屈は分かるんですが、聞いた人がなるほどと思うような面白い例えを使って説明してください。


275 :仕様書無しさん:03/11/08 00:05
>>274
気に入らないなら2分の1で割ってもいいよ。

276 :仕様書無しさん:03/11/08 00:16
>>273
まずはオブジェクト指向から理解しろ

277 :仕様書無しさん:03/11/08 00:17
素直にここみたら?

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

278 :仕様書無しさん:03/11/08 00:26
>>274
2進数(小数)の2進数への基数変換は2をかけて1越した(?)のを拾えばよいから。

279 :仕様書無しさん:03/11/08 01:26
XP厨はXPをやるように上司や教官を説得する能力もなければ
遊びでペアプログラミングする友達もいない

280 :仕様書無しさん:03/11/08 01:56
>>279
XPはコンサルティング・設計のできないニセSE等の上司と言われる人が楽するためや、
納品等の責任のない教官がカッコ付けるためにあるものでそ。
PGは何度も来る無計画な変更で大変になるはずだ。

281 :仕様書無しさん:03/11/08 05:25
>>233
うわー粘着。こわ。

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

Javaが初めて学んだプログラムなんだね。これで大体歴が3年程度ということが発覚したなぁ。
先走りゴクロウだよ。ほんと。

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

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

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

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

282 :仕様書無しさん:03/11/08 05:36
けっこう面白そうなスレだと思って見ていたが
やべ、ねみぃ。

283 :仕様書無しさん:03/11/08 08:28
新人のころにはみんな通る道だ
熱く語れ!!
それにしてもレベルが低いぞ
がんばれよ!
みんな!!


284 :仕様書無しさん:03/11/08 09:55
>>280
嘘つくな。俺はXP厨のつもりはないが、お前の言っていることは滅茶苦茶だぞ。
WaterFallマンセーか?

285 :仕様書無しさん:03/11/08 09:58
プログラムのスレで、プロセス方法論のXPの事を持ち出す理由を述べよ。

286 :仕様書無しさん:03/11/08 10:04
>>285
それをいうなら、OOPも同様だ。
OOP言語を使ってない奴もいるんだからOOP言語用の別スレ立ててそこでやって欲しいよな

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

288 :仕様書無しさん:03/11/08 10:27
>>286
OOP知らないなら、OOPの話題が出てるうちは黙ってるか、
自分が知ってる非OOP言語の話題を振ればいいでしょ。

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

289 :286:03/11/08 11:15
>>287
>>286
いつからここはjavaのスレになったんだ。

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

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

290 :仕様書無しさん:03/11/08 11:25
>>287
質問
connect()メソッド参照時のdbコネクションクラスの明示的な取得
各種insertメソッドやupdateメソッド参照時のデータ
などは隠蔽されている様だが、なぜか。

291 :仕様書無しさん:03/11/08 11:30
>>281
>>>233
>うわー粘着。こわ。

お前も十分粘着じゃん。

292 :仕様書無しさん:03/11/08 12:17
>>290
理由1.普通はスーパークラスに変数やメソッドが
    定義されているだろうという常識的前提。
理由2.例外処理の素晴らしさを伝道するためには、
    レスの行数が多くなるのは不都合だった。

293 :仕様書無しさん:03/11/08 12:23
>>287
closeはdeconnect()に隠蔽されているのか?

294 :仕様書無しさん:03/11/08 13:04
disconnectだろーが、ハゲ

295 :仕様書無しさん:03/11/08 13:25
>>293
もちろん。
しかしコネクションの取得、開放には何通りもやりかたがあるから
明示は避けた。
例えば、closeせずに、コネクションプールに戻すだけかもしれない。

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

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

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

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

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


297 :仕様書無しさん:03/11/08 14:06
30分以上かかってるぞ。

298 :仕様書無しさん:03/11/08 14:25
抽象的だけど、俺が気をつけていること。

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

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

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


299 :仕様書無しさん:03/11/08 14:27
  ∠二ミ:::::://  ...::::::ヽヽ、
  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'´--ヽ=:/  /   /7|| |.|゙! L::ノ     L;;ノ ||リクヽ.l| ||  .l⌒!
      |: : :/: :__/  、 '  /-r'┴、!||::::   ,   :::::::: | |!).ノ|| ||  / /
      ト|: : : /:ノ    ヽ、 レ'′ /ハ|'、         //'´  ||Ll/ /
      |: :Y: : /  \   !  /l/: :|| `゙ - ゚..__,.ィ´//_,--'´  、,/
      L; :|: : }    \  l   | !: : ∧  ,. --| //〃:r'´ 、  \ ヽ
      ト|: :.|   \  レ'  /: :: : {〃⌒l Lr' ̄`ヽ |:::| 、  ヽ  〉ノ
      |:ヽ: |     | / ,ィし!: : : ||...::::/r、| ....:::::/ ハ::| `Lヽ レ‐<
      ヽ ヽ|ヽ、  .し'r<ハ!: : : : :|トニノ ヽニニ人ヾヽ、  ̄  >'′
      ∧ ヽ::::`ー‐': : 人: : : : : :| |/::::::::::::::::::::::::::`゙´:::::r`ー'´

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

301 :仕様書無しさん:03/11/08 16:23
>>284
WaterFallはSEの負担が増え、PGの負担が減る。
つまりWaterFallをやめたいのはPGでなくSE。
やめたいというかできないんだろうけど。ただの営業だから。w

302 :仕様書無しさん:03/11/08 16:55
>>300
ゲームはほどほどにな。

303 :仕様書無しさん:03/11/08 18:43
OOPはわかるんだけどXPってなに?

304 :仕様書無しさん:03/11/08 19:04
まるまるピーはまる二つ
ばつピーはばつ一つ

305 :仕様書無しさん:03/11/08 19:05
>>303
顔文字だよ。
横から見てみな? モロに昭和中期の漫画キャラの顔だから。

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

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

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


307 :仕様書無しさん:03/11/08 20:30
粘着ハァハァ

308 :仕様書無しさん:03/11/08 23:20
>281
>処理がうまくいったかいかなかったかを戻り値で戻すような関数の場合
ワザワザ引数戻り値でなく、素直に関数戻り値で返した方がいい、とは
誰もツッコまないの??

309 :仕様書無しさん:03/11/08 23:36
>>308
きみってOOやったことないでしょ?

310 :仕様書無しさん:03/11/08 23:39
>>308
日本語が理解できていないようだな

311 :仕様書無しさん:03/11/08 23:55
君はもっと色んな言語をやったほうがいい。あ、一応Javaも.NETもやったからね。俺は。


312 :仕様書無しさん:03/11/09 00:02
>>309==>>310
ププッ
顔真っ赤にして目に涙タップリ溜めて頑張ってまつね(w

313 :仕様書無しさん:03/11/09 00:06
>>308
ファンクションの戻り値は基本引数のない関数の場合のみ
という指定が多いからな。
引数のある関数の場合の戻り値は引数で、ってのがよくあるパターンだな

314 :仕様書無しさん:03/11/09 00:08
>>312
どっちが赤いんだかなぁ。
Javaしかやった事ない事を認めてるなら
とりあえず他の言語やプロジェクトを経験してから書き込め。
オマエみたいなちっちゃいちっちゃい場所しか解ってないPGの書くプログラムが
一番見づらいんだよ。


315 :仕様書無しさん:03/11/09 00:15
プロジェクトの大小に関わらずアルゴリズムを考える部分は重要だからな
アルゴリズムの関係ない部分しか担当できない人間なら関係ないが

316 :仕様書無しさん:03/11/09 00:20
Java厨が暴れているようですね。
若いな。

317 :仕様書無しさん:03/11/09 00:25
>>315
アルゴリズムを考えてもいいプロジェクトは減ってるけどな。

318 :仕様書無しさん:03/11/09 00:31
>>317
それは単に君のレヴェルを物語っているだけ。
出来合のライブラリ使うだけでは、そりゃ無いよ。

319 :仕様書無しさん:03/11/09 00:34
>>317
ライブラリの組み合わせで出来る仕事は流通業と一緒
いつかネット時代の流通業と同じ運命を辿る

320 :仕様書無しさん:03/11/09 00:35
>>318
要するに、(自分でやってたら)人件費が高くなってしまうということ。
昔はコスト意識低いところも多かったけどね。

321 :仕様書無しさん:03/11/09 00:36
>>320
ほら
もうコスト削らないと採算が合わない時代になってる

322 :仕様書無しさん:03/11/09 00:37
>>321
そうやって、競争力落としていくんだ。

323 :仕様書無しさん:03/11/09 00:50
独自性がなくコストダウンでしか勝負できないのは
既に競争力がない証拠なんだがな

324 :仕様書無しさん:03/11/09 00:54
>>313
要はファンクションには引数つけちゃわかりにくいからダメって事だろ。
コーディングルールではお馴染みだからよく解るけどね。
個人的にはファンクションに引数つけてもいいじゃん。とか良く思うのだけど。


325 :仕様書無しさん:03/11/09 01:04
>>313>>324 はそもそも言ってることの意味が分からない
と思っているのは俺だけだろうか?

326 :仕様書無しさん:03/11/09 01:13
>>323
独自性なんて求めてないんだよ。

327 :仕様書無しさん:03/11/09 01:40
つまり誰でも出来るということだ

328 :仕様書無しさん:03/11/09 02:17
>>325
大丈夫、漏れも分かってないから(w

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

329 :仕様書無しさん:03/11/09 02:29
>>313 に突っ込むなら

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

ってことかな

330 :仕様書無しさん:03/11/09 02:31
なんかよくわからんが関数はvoidが基本だということか?

331 :仕様書無しさん:03/11/09 02:35
>>313
>>324

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

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

332 :仕様書無しさん:03/11/09 02:41
>>316
COBOL厨が暴れているようですね。
老いてるな。

333 :仕様書無しさん:03/11/09 02:49
またCOBOLerか。
COBOL知ってる香具師同士にしか通じない話をここでするな。
COBOL知らない人間が混乱するだろ。
#数多あるスレの中で今一番重要な名前を持ってるスレなんだから。

334 :仕様書無しさん:03/11/09 03:24
ファンクションは戻り値のある関数で
プロシージャは戻り値のない関数って事では?
VBとかPL/SQLなんかはそんな感じだったような気がする。


335 :仕様書無しさん:03/11/09 03:31
プロシージャという単語が出てきたレスは

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

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

336 :仕様書無しさん:03/11/09 03:44
ていうかストアドプロシージャの話してんじゃないの?
>戻り値が前か後ろか

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


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

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

339 :仕様書無しさん:03/11/09 04:18
わからねー。
関数には戻り値と引数があるよな。
それで、引数にはINとOUT(ValとRef)があるよな。
そのOUT引数は使うなってことか?

340 :仕様書無しさん:03/11/09 04:26
【逮捕祭り】
ファミコンのエミュレータを売るサイト
       ↓
http://www.geocities.co.jp/Playtown-Spade/7898/


341 :仕様書無しさん:03/11/09 04:36
プロシージャ、関数、メソッド、いずれも本質的には同様のもの
http://yougo.ascii24.com/gh/78/007837.html

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

343 :仕様書無しさん:03/11/09 05:23
多値を使えば解決。
あるいはCPS。

344 :仕様書無しさん:03/11/09 06:16
仕様書がきちんと書かれていれば
ソースが綺麗である必要はない

∴終了

345 :仕様書無しさん:03/11/09 06:24
ソースが汚いと仕様書通りに動かない可能性も高くなるがな。

346 :仕様書無しさん:03/11/09 09:14
>>344
君はもっと広い視点を持ったほうがいい。

347 :仕様書無しさん:03/11/09 09:17
視野だけ広くて役に立たない奴もいるがなw

348 :仕様書無しさん:03/11/09 09:24
>>344
ソースが綺麗ならば、機能仕様書以降の仕様書は不要である。

349 :仕様書無しさん:03/11/09 09:38
>>344
一回限りの開発で逃亡できるのならね。

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

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

351 :仕様書無しさん:03/11/09 12:34
>>337 >>338
PL/SQL とやらが分からないので,出来るだけ用語を一般的で一貫した表現にしてみた

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

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

352 :仕様書無しさん:03/11/09 13:16
rand()

353 :仕様書無しさん:03/11/09 13:28
rand()は状態を持ってるよ。srand()で状態設定できるし。

354 :仕様書無しさん:03/11/09 14:33
「引数があって戻り値がない(Void)なのは’ファンクション’ではなく
’サブルーチン’である」って言われることは未だに多いな。

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

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



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

あと「FORTRAN」な。

356 :仕様書無しさん:03/11/09 14:56
y = f(x, z)
は普通に関数だと思うが。

357 :仕様書無しさん:03/11/09 15:03
>>356
数学ならそうだね。FORTRANだとどうなんだろ?

358 :仕様書無しさん:03/11/09 15:18
FORTRANの「関数」(関数副プログラム, 文関数)でも2つ以上の引数は使える。
標準の組み込み関数の中にも複数の引数を持つものがある。

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

359 :仕様書無しさん:03/11/09 18:24
漏れが個人的にツールとか作るときは、返り値を必ずbooleanかvoidにしてる。
同じことしてる香具師いる?

360 :仕様書無しさん:03/11/09 18:32
いないだろうな。

361 :仕様書無しさん:03/11/09 19:08
>>359
その二つに絞るメリットはないと思うが。
オブジェクトを返してもらいたい場面はないのか?

362 :仕様書無しさん:03/11/09 19:19
>>361
くそAPIの真似だろ。戻り値は成功/失敗のみで、オブジェクトはRefで。

363 :仕様書無しさん:03/11/09 19:27
>>362
どの言語の話をしてるんだ?

364 :仕様書無しさん:03/11/10 09:08
オブジェクトのRefかぬるりーを返すとか。

365 :仕様書無しさん:03/11/10 17:52
>>362
Cとか例外が存在しない言語の場合は
この方法が有効な場合もある。


366 :仕様書無しさん:03/11/10 17:53
>>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パターンなどを適用すればある程度は解決する。

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



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

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

369 :仕様書無しさん:03/11/10 18:04
>>270
> >>269 そだね
> 特に、学のXP厨なんてその存在すら認められない。
> 実践抜きで、書籍からの知識のみでほざいてるってことだからな。
あれはそんなにXPのことを説明しているとは思えないのだが。
OOP == XPと勘違いしていないか?

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

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

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

371 :仕様書無しさん:03/11/10 18:15
>>281
> >>233
> うわー粘着。こわ。
脳内解釈している君も粘着だ。

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

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

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

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

372 :仕様書無しさん:03/11/10 18:33
EntityBean知ってることがそんなにえらいのか?(プ

373 :仕様書無しさん:03/11/10 18:57
どうせショッピングモールレベルのことしかやったことないんだろ。w

374 :仕様書無しさん:03/11/10 19:00
ショッピングモールレベルもやったことが無い人は口を出さない。
ショッピングモールのレベルを低く見積もっていることで程度が分かる。

375 :仕様書無しさん:03/11/10 19:01
>>371
俺はOracleを使ってるのでEntityBeanなんか使いませんが、なにか?

376 :仕様書無しさん:03/11/10 19:03
J2EE厨ってどうして偉そうな奴が多いのかねぇ

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

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

379 :仕様書無しさん:03/11/10 19:09
>>270
XPのプラクティスは14個だよ。

380 :仕様書無しさん:03/11/10 19:10
>>379
いや13個だ。

381 :仕様書無しさん:03/11/10 19:17
>>374
図星?(爆
少なくともショッピングモールに複雑な副問合せ含む高速な集計はいらん罠。
業務要件も簡単だ罠。

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

382 :仕様書無しさん:03/11/10 19:20
四次元情報って何?

383 :仕様書無しさん:03/11/10 19:23
>>380
19個。

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

385 :仕様書無しさん:03/11/10 19:34
>>382
失礼。テーブル2つ分に相当する情報(テーブル1個で二次元と考える)
商品A:10個、色等
  送付先1:5個、氏名、住所等
  (残り5個は本人)
商品B:20個、色等
  送付先1:5個、氏名、住所等
  送付先2:5個、氏名、住所等
  送付先3:10個、氏名、住所等
な感じ。

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

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

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


387 :仕様書無しさん:03/11/10 19:52
>>385
そんな概念はじめて聞いたよ>4次元情報
つうかそれってそんなに大層なことか?

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

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


388 :仕様書無しさん:03/11/10 19:54
こ の 話 は ス レ 違 い な の で も う や め れ

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

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

390 :仕様書無しさん:03/11/10 20:01
こ の 話 は ス レ 違 い な の で も う や め れ

391 :仕様書無しさん:03/11/10 20:01
そういうのって例外処理を除いたらコード量が1割になるって本当か?
それで正常処理は新人にやらせて熟練者が例外処理を書くんだそうだ

392 :仕様書無しさん:03/11/10 20:03
>>389
恥ずかしいから、そのくらいでやめとけ。

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

394 :仕様書無しさん:03/11/10 20:06
>>387
>つうかそれってそんなに大層なことか?

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

395 :仕様書無しさん:03/11/10 20:06
>>375
SessionBean厨か

396 :仕様書無しさん:03/11/10 20:10
>>368
どうも、研究開発部門と信号処理と複素数とOOPが固く結びついているようですね。

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

398 :仕様書無しさん:03/11/10 20:14
>>394
お前アレだろ。政治家が犯罪犯したら、
政治家は全員犯罪者だと思ってしまう奴だろ。
んで、逮捕したらやっぱり政治家だったとか言う奴。

399 :仕様書無しさん:03/11/10 20:15
>>396
信号処理に複素数がつくのはほとんど当たり前だと思うが。
オブジェクト指向がつくことが納得いかないといいたいのかい?
そりゃ組み込み系でDSPやってる香具師には納得できないだろうなあ。

400 :仕様書無しさん:03/11/10 20:15
>>366
一生懸命引数の型チェックを行う(または行わなくてすむようにする)理由がわからない。

401 :仕様書無しさん:03/11/10 20:16
>>392
反駁できないお前が一番恥ずかしい

402 :仕様書無しさん:03/11/10 20:17
>>400
テンプレートがあればチェックを行う必要はないのだが。
J2SE1.5から出るGenericsに期待。

403 :仕様書無しさん:03/11/10 20:17
>>399
いやぁ、OOPの例として複素数が出てくるのが幼稚だと。

404 :仕様書無しさん:03/11/10 20:17
>>402
コンパイラに任せましょう。

405 :仕様書無しさん:03/11/10 20:18
気づいてないのか・・・。

406 :仕様書無しさん:03/11/10 20:18
>>400
あれはあくまでも一例.
全部同じ型だったらチェックする必要が無いのは確かだな。


407 :仕様書無しさん:03/11/10 20:18
> J2SE1.5から出るGenericsに期待。
そんなもの出ませんがなにか?

408 :仕様書無しさん:03/11/10 20:20
>>406
一個addし忘れたら?

409 :仕様書無しさん:03/11/10 20:20
>>403
ほう。では何が幼稚でないと思うのかね。
馬鹿に説明するには複素数がシンプルで楽だという配慮の
もとに複素数で説明してやったのだが。
それともお前には複素数が理解できないのかね。

410 :仕様書無しさん:03/11/10 20:22
いいから複素数以外の例をだせよ。
それくらい考えつかないから幼稚だといわれるんだよ。

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

412 :仕様書無しさん:03/11/10 20:23
>>411
だから、コンパイラに任せればいいじゃん。

413 :仕様書無しさん:03/11/10 20:25
>>410
じゃあ、これはどうかな。

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


414 :仕様書無しさん:03/11/10 20:25
>>397
> catchステートメントを空にする奴はマジで氏んでほしい。
まあな
例外をかき消すくらいならメソッドの外に丸投げしる

415 :仕様書無しさん:03/11/10 20:25
>>412
object型なのにどうやってコンパイラにまかせろと?

416 :仕様書無しさん:03/11/10 20:25
>>409
複素数が入門書でよく出てくるのは確かだけど、オブジェクトである
ありがたみは薄いからねぇ。まだ犬クラスのほうが有用でしょ。

417 :仕様書無しさん:03/11/10 20:26
>>413
必死だな(藁

418 :仕様書無しさん:03/11/10 20:27
このままでは、アンチOO厨とアンチJava厨とを同時に満たすことができないな。
集約しておかないと。

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

 //(ry

}


419 :仕様書無しさん:03/11/10 20:27
>>415
?

420 :仕様書無しさん:03/11/10 20:31
まあコンパイラにまかせるのは不可能だな。

421 :仕様書無しさん:03/11/10 20:35
>>418
そんなことするから、変数を日本語(ローマ字表記)にしろとか言われるんだよ。

422 :仕様書無しさん:03/11/10 20:38
むしろこっちのほうがいいか

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, 馬鹿指数, Java理解度);
  
  馬鹿の典型 馬鹿レス417 = new 馬鹿の典型(untiOO厨, untiJava厨);

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

423 :仕様書無しさん:03/11/10 20:40
アンチのスペルが…

424 :仕様書無しさん:03/11/10 20:40
>>423
うんちが好きなんでしょ。

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


426 :仕様書無しさん:03/11/10 20:41
>>418 >>422 はやぶ蛇のアフォ

427 :仕様書無しさん:03/11/10 20:41
>>425
恥の上塗りか(藁

428 :仕様書無しさん:03/11/10 20:41
>>423
>>410をからかうためにわざとウンチにしておいたよw


429 :仕様書無しさん:03/11/10 20:42
>>427
では、恥の上塗りクラスでも作るか?(藁

430 :仕様書無しさん:03/11/10 20:44
つまりXP厨、OOP厨は英単語もおぼつかないということか。

431 :仕様書無しさん:03/11/10 20:47
いや、インターフェースにしたほうがいいなw

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

public class final 恥 {
 //(ry
}

432 :仕様書無しさん:03/11/10 20:48
つまんねーよ。

433 :仕様書無しさん:03/11/10 20:50
このスレもヒッキーと厨房のたまり場になってしまった。

434 ::03/11/10 21:40
バレー見てた。どーせ脱線してるみたいだし、てきとーにレスさせておくれ。

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

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


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

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

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

436 ::03/11/11 01:40
ここはJavaスレじゃないぞ。あと、上手な日本語を(ry

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

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

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

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


437 :仕様書無しさん:03/11/11 02:14
数年前使ってたcad開発用unix(なんだかわからん)に入ってた
1.xは無かった気がした。


438 :仕様書無しさん:03/11/11 03:41
うわ、馬鹿ばっか
このスレ

439 :仕様書無しさん:03/11/11 10:08
>>435
>>ちなみに、漏れは「解り易い」「美しい」の到着点は「シンプル」にあると思っている。

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

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

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



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

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

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

442 :仕様書無しさん:03/11/11 17:12
>>439-440
>>394

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

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

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

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

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

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

445 :仕様書無しさん:03/11/11 19:16
>>444
> 「東区」を「East Area」
固有名詞を英語にすると訳分からないだろ

446 :仕様書無しさん:03/11/13 08:35
日本のプログラマーってレベル低いよね・・・


447 :仕様書無しさん:03/11/13 12:06
そうだよな。
俺がいなかったら全滅じゃん。

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

449 :ageあしをとってみる。:03/11/13 19:40
ほほー、バグのないソフトがあるんだ。

450 :仕様書無しさん:03/11/13 20:12
底辺な人たちは凄腕のプログラマーに会う機会すらないみたいだな


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

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

452 :仕様書無しさん:03/11/13 20:44
>>449
1000行程度のプログラムならあるだろうな

453 :仕様書無しさん:03/11/14 04:31
>449
Micro$oftの製品。
何がどうなっても全ては仕様どおりだからバグではないのだ。

454 :仕様書無しさん:03/11/14 09:38
>>453
「潜在的な不具合」も確認されてるがな

455 :仕様書無しさん:03/11/14 14:05
>>454
きっと『潜在的な仕様』なんだよ。

456 :仕様書無しさん:03/11/14 21:26
>>1
>1つの関数は100行以内にする。
行という単位でしか判断しないってのはアセンブラを引きずっている。
#車の積載上限を荷物数で指定するようなもんだ。重量で指定するのがほんとだろ。
関数内での識別子の種類数が有力かな。
20だと多すぎるな。

457 :仕様書無しさん:03/11/14 22:56
>>456 なるほど。識別子の数ですか!感動した。

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

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


458 :仕様書無しさん:03/11/15 03:42
なぜgotoをそんなに嫌う?
フラグにしろ命令にしろロジックにしろ
意味がgotoならばgoto使ったほうがすっきりするだろ。


459 :仕様書無しさん:03/11/15 04:43
だといいね( ´,_ゝ`)

460 :仕様書無しさん:03/11/15 11:10
>>457-459 フラグについて論じるのはいいが、gotoは専用スレがあるのでそちらでどうぞ

461 :仕様書無しさん:03/11/15 12:02
goto hell;

462 :仕様書無しさん:03/11/15 13:20
>460
おめーのBBSか?
おめーがどっかいけ

463 :仕様書無しさん:03/11/15 14:45
goto ヘルス;


464 :仕様書無しさん:03/11/15 20:32
hell:

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

466 :仕様書無しさん:03/11/16 11:54
「わかりやすいコメントを書く」というのと同じくらい
「わかりやすい変数・関数名をつける」ってのは重要

467 :仕様書無しさん:03/11/16 11:59
>>465
アルゴリズムのコードなどの場合は
何をやっているのか事前に分かっていた方が
理解しやすい

468 :梨華狂:03/11/16 12:21
俺の気を付けていることと言えば
「意図のわかる分岐」かな

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

469 :仕様書無しさん:03/11/16 12:22
>>468
なるほど

470 :仕様書無しさん:03/11/16 16:03
自分は、自分の作ったプログラムでも
2年くらい経っていると、
「なんでこんな処理やってんだ?」ってなります。

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

471 :仕様書無しさん:03/11/16 16:08
>>470
記憶力を鍛えろ。
そのために携帯も手帳も持つな。

472 :仕様書無しさん:03/11/16 16:08
>>470
上達した証拠だぉ

473 :仕様書無しさん:03/11/16 16:09
老化した証拠

474 :仕様書無しさん:03/11/16 16:09
>470
>1-469の中に答えがある。・・・かな?

475 :465:03/11/16 16:09
>>467 その通り。それに該当する関数が5%くらいなんだ。

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

477 :仕様書無しさん:03/11/16 16:26
なるよ。

478 :いなむらきよし:03/11/16 16:32
キケー!

479 :仕様書無しさん:03/11/16 16:41
>>470
上達した証拠だと思うよ

480 :仕様書無しさん:03/11/16 16:50
>>476
コードにはHowしか書けんよ。WhatやWhyを関数名、変数名だけで表現
できるかな?

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


481 :仕様書無しさん:03/11/16 17:02
>>480
> コードにはHowしか書けんよ。
宣言型プログラマへの挑戦ですか?

482 :仕様書無しさん:03/11/16 17:04
>>481
そうですが何か?
つか宣言型言語なんて使われてないし、そもそも使わない場合の話だろ。

483 :仕様書無しさん:03/11/16 17:05
>>482
> つか宣言型言語なんて使われてないし、そもそも使わない場合の話だろ。
(゚Д゚)ハァ?

484 :仕様書無しさん:03/11/16 17:18
>>458
> なぜgotoをそんなに嫌う?
> フラグにしろ命令にしろロジックにしろ
> 意味がgotoならばgoto使ったほうがすっきりするだろ。
>

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

485 :仕様書無しさん:03/11/16 17:21
>>456
> >>1
> >1つの関数は100行以内にする。
> 行という単位でしか判断しないってのはアセンブラを引きずっている。
> #車の積載上限を荷物数で指定するようなもんだ。重量で指定するのがほんとだろ。
> 関数内での識別子の種類数が有力かな。

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


486 :仕様書無しさん:03/11/16 17:22
72カラム7行以内

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

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

489 :仕様書無しさん:03/11/16 17:27
チームプログラミングにはテストファーストは重要だ。


490 :465:03/11/16 18:17
>>477 私はならないと言い、あなたはなると言っている。
「なんでこんな処理やってんだ?」っていうソースを晒して見てくれ。

491 :仕様書無しさん:03/11/16 18:24
テスト無し。これ最強。

492 :465:03/11/16 18:36
>>480 yes

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

494 :465:03/11/16 18:42
>>485 識別子はクラス名を含む

495 :465:03/11/16 18:44
>>487 そのようなコーディング標準が存在すれば、そうする。

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

497 :仕様書無しさん:03/11/16 19:02
結局工数の話かよ
アホか

498 :仕様書無しさん:03/11/16 19:05
つまり465はテスタにバグを発見されるのが嫌だからコメントを書かないわけか

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

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

501 :仕様書無しさん:03/11/16 19:12
特殊用途のソート関数にそれらしい名前を付けて
その関数の内部で汎用関数を呼ぶということか

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

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

503 :仕様書無しさん:03/11/16 19:23
>>499

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

これを

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

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

でもさー

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

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


504 :仕様書無しさん:03/11/16 19:24
おそらく5%と答えると思われ

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

506 :仕様書無しさん:03/11/16 19:31
>>505
コメント無しで分かるプログラムの例を貼れや( ゚Д゚)ゴルァ!

507 :仕様書無しさん:03/11/16 19:46
>>505
二元論が誤りはわかるけど、そうだったら「コメントは書かない」にはなら
ないでしょ。良いコメントを書きましょうという話になる。

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

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

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


508 :仕様書無しさん:03/11/16 19:49
printf("hello, world.\n");

509 :仕様書無しさん:03/11/16 19:51
(format t "Hello, world!\n")

510 :仕様書無しさん:03/11/16 19:53
(display "Hello, world!\n")

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

512 :仕様書無しさん:03/11/16 21:26
>>496
> >>487 追加
> ×引数にいれても構わない定義域
> ○引数にいれても構わない値域
> それを書くと値域の境界値の試験を関数毎に行わなければならなくなるが、

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

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

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

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

513 :仕様書無しさん:03/11/16 21:28
>>500
> >>498 通常、テスタはブラックボックス試験しかしないよ。
だからバグが多いソフトしかつくれないんだ。
ガラスボックステストも知らないんだなお前は。

514 :仕様書無しさん:03/11/16 22:40
>ガラスボックステスト
初耳だ、そのテスト
ホワイトボックスってのなら知ってるんだが...きっとそれより
ずっと中身見えてるんだろうなぁ

515 :仕様書無しさん:03/11/16 22:55
>>496
仕様をコメント内に書くのと、テストの有無とは別だろう。

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

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


518 :仕様書無しさん:03/11/16 23:06
>>516
> #あなたの仕事は「顧客の損害を補償する」場合もあるのか。すばらしいじゃないか。
藻前は完成後の、潜在的バグ浮上に対する対策もしないのか?



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

520 :仕様書無しさん:03/11/16 23:14
んなもんオープンソースの常識だろ

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

522 :仕様書無しさん:03/11/16 23:26
「潜在的バグ」を知らないのか!?


523 :465:03/11/16 23:28
>>520 ふーん。そーなんだ。勉強になりました、

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

525 :仕様書無しさん:03/11/17 04:08
質問なんだが、一つのクラスにおけるメソッド数はどのくらいまでなら許せる?

共同で開発している香具師が100↑のメソッドを持つクラスを作ってきて、激しく使いづらいわけで(;´Д`)ッテユーカツカイタクネェ
おまけにコメントが全く無い上に似たようなメソッド名と似たような引数とってたりetc・・・_| ̄|○

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


526 :仕様書無しさん:03/11/17 04:12
>>525
顔文字使いすぎ

527 :仕様書無しさん:03/11/17 08:29

(;´Д`)

_| ̄|○

(´・ω・`)

528 :仕様書無しさん:03/11/17 09:22
つうか、コメントは最低でも、なにをやるってのを書けよ。
関数の枠を書いたら次にコメントで書いとく。

int hoge(int xx)
{

}

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

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

って書く。


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

530 :仕様書無しさん:03/11/17 09:43
>>525
> 質問なんだが、一つのクラスにおけるメソッド数はどのくらいまでなら許せる?
Javaでは255個までコンパイラが許す。

> 共同で開発している香具師が100↑のメソッドを持つクラスを作ってきて、激しく使いづらいわけで(;´Д`)ッテユーカツカイタクネェ
> おまけにコメントが全く無い上に似たようなメソッド名と似たような引数とってたりetc・・・_| ̄|○
それは設計に非常に問題がある。

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

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

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


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

532 :仕様書無しさん:03/11/17 10:48
レベル低すぎてお話にならない。

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

534 :仕様書無しさん:03/11/17 11:06
>>465
レベルが低いというのはお前のことだ、馬鹿。

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

536 :仕様書無しさん:03/11/17 11:10
int hoge(int xx)
{
//そこはだめ
//だめだって言ってるのに
//いやーん♪
}

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

538 :仕様書無しさん:03/11/17 11:11
>>535
処置無し。

539 :仕様書無しさん:03/11/17 11:14
あははは、コイツ自分のことレベル高いと思ってるらしいぞ。

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

541 :仕様書無しさん:03/11/17 11:24
( ゜д゜)ポカーン

542 :仕様書無しさん:03/11/17 11:27
>>540
お前の意見には同意できないが465がレベル低いというのは同意する(w
なんか君うざいよ>>465

543 :仕様書無しさん:03/11/17 11:31
>>535
君はその2年生ぐらいのことも出来ない愚か者。
仕事ってのは集団でやるもんだからね。

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


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

545 :仕様書無しさん:03/11/17 11:37
>>544
ほんと君って頭悪いよね。

546 :仕様書無しさん:03/11/17 11:40
>>465
>>465-476くらいをもう一度読み直してみろ。
いちいち指摘はしないがな。

547 :仕様書無しさん:03/11/17 11:44
まあ>>465はレベルが低いというか
古い考え方しか知らないだけでしょ。
アジャイル開発といわれてもわからない人なんでしょうね。

548 :仕様書無しさん:03/11/17 11:46
>>535
養老孟司は、誰にでもわかる平易な文章を書くが、誰も彼のことをレベルが低いとは
言わない。なぜだと思う?

549 :仕様書無しさん:03/11/17 11:47
465たたかれまくり(w

550 :仕様書無しさん:03/11/17 11:51
>>547
俺も>>465は思考停止したオヤジか、やっとこの業界に慣れた3年生くらいじゃないかと思う。
まぁ、前者かな。

551 :仕様書無しさん:03/11/17 11:56
まぁ、平日のこの時間に書き込むような奴なんだから推して知るべしだな。俺も同類だが。

552 :仕様書無しさん:03/11/17 12:03
まあ、実務経験上では>>465みたいな奴のソースって大体独りよがりで癖が強いんだよな。


553 :仕様書無しさん:03/11/17 12:05
>>550
オヤジでしょ。自分のこと「私」なんて書き込むんだから。

554 :仕様書無しさん:03/11/17 12:09
>>465 >>467 >>475の流れだけで、465がアフォだと俺は断言できるね。

555 :仕様書無しさん:03/11/17 12:29
キティガイはスルーの方向で。

556 :仕様書無しさん:03/11/17 12:42
>>531
意味わかんないんだけど…。
設計はしないということか?

557 :仕様書無しさん:03/11/17 12:46
>>556
彼じゃなくてもとのコメント書きを書いたものですが。

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

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



558 :仕様書無しさん:03/11/17 12:57
>>557
俺も同じやりかたしてる。
つーか、いまどき公開しないメソッドの詳細設計まで事前にしてるところなんてあるのか?

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

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

560 :仕様書無しさん:03/11/17 15:41
>>559
あなたが上にたつ人ならこういう聞き方がいいのかな?

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

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

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



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

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

562 :仕様書無しさん:03/11/17 18:18
なるほど
言いたいことは分かる

563 :仕様書無しさん:03/11/17 19:45
保守できない=能力不足

早く気づけよヴォケ。

564 :仕様書無しさん:03/11/17 19:46
プロと呼べるプログラマは世界に数パーセントしかいないと聞いたけど本当か?

565 :仕様書無しさん:03/11/17 19:50
>>563
(゚Д゚)ハァ?
保守できないプログラムも見たことないのか
まだ甘ちゃんだな

566 :仕様書無しさん:03/11/17 19:51
>>564
間違ってるとも思えないな

567 :仕様書無しさん:03/11/17 20:42
>>564
0.1%もいないと思います( ´д`)ノ

568 :仕様書無しさん:03/11/17 21:03
99.9%は土方要員?

569 :仕様書無しさん:03/11/17 21:05
0.1%ってことは1000人に1人か。
もっと少ない気が・・・。

570 :仕様書無しさん:03/11/17 21:31
分かりやすい上手なプログラムを書くにはどうしたらいいか?
コードに不吉な匂いを感じたらリファクタリングを行いそれを改善したらいい。

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

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

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

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

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

572 :仕様書無しさん:03/11/17 23:05
>>565
保守できないプログラムを保守したことないのか
おまえ尼ちゃんになれ

573 :仕様書無しさん:03/11/18 01:17
>>570
>>465がそれを言ってるとはとても思えない。

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

575 :仕様書無しさん:03/11/18 01:24
>>574
C3プロジェクトではたしか6行だったと思う。

576 :仕様書無しさん:03/11/18 01:40
>>572
保守できてないのに保守したつもりになってるのか?
やはり甘ちゃんだな

577 :仕様書無しさん:03/11/18 02:11
>>570
本筋と関係ないが>>465が大勢に叩かれてるように見えるのは、
実際は1人か2人が執拗に妙な書き込みをしてるんじゃないかな?
匿名掲示板はそういうの注意しないとね。

578 :仕様書無しさん:03/11/18 03:12
>>465
わかったか?
相手に合わせてレベルを落としたつもりが、内容までレベルが落ちてりゃせわないな。
まぁ言いたかったことはわからんでもないがな。

579 :仕様書無しさん:03/11/18 03:18
>>578
おまい一人でいい加減しつこいよ

580 :仕様書無しさん:03/11/18 03:38
普通は、コメント書きましょう、でいいと思うが。

581 :仕様書無しさん:03/11/18 03:51
加えて,コードの分かりにくさをコメントで誤魔化さないようにしよう
(リファクタリングより)

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

582 :仕様書無しさん:03/11/18 09:29
isSHIT() // これは無能な発言を2chで見かけたことを(以下略

名前変更

isFoundIncompetentResOn2ch()

583 :仕様書無しさん:03/11/18 09:35
まあそんなもんだろ

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

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

585 :465:03/11/18 11:50
>>584 失礼しました。>>571>>570の間違いです。(誤爆って言うのかな)

586 :仕様書無しさん:03/11/18 13:51
Vector vector(){
while(this.vector.add(return(new Vector(Integer.MAX_VALUE)))
}


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

588 :仕様書無しさん:03/11/18 20:26
いやいや>>465に対する人格攻撃はどう見ても多いぞ。まぁ2chらしいっちゃらしいけど。

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

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


591 :仕様書無しさん:03/11/19 00:26
実装や設計に文句言うのは簡単。



592 :仕様書無しさん:03/11/19 00:42
もっと言うと、他人がやったことに文句言うのは簡単。

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

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


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

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

595 :仕様書無しさん:03/11/19 07:46
コメントは銀の弾丸ではない。やたらと書けば幸せになれるってもんじゃない。

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

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

しかし、だ。

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

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

@param 1以上の値

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

596 :仕様書無しさん:03/11/19 10:33
おまいら他人が書いたコメントを信用するのか?
もれは絶対に信用しないぞ。


597 :仕様書無しさん:03/11/19 11:02
馬鹿なコメントでも無いよりましなときもあるよ。
何を勘違いしたかの手がかりになれば、同類のバグとかって芋ずるに出来るときとかあるし。

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


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

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

600 :仕様書無しさん:03/11/19 13:52
読みやすいプログラムを書くには、まず文章力が必要です。

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

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

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

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


601 :仕様書無しさん:03/11/19 14:08
>600
おまえのソース晒せよ

602 :仕様書無しさん:03/11/19 14:18
Java的コメントは
throws宣言をつけるべきときはつける。
それだけでもコメントの何割かを書いたことになる、こともある。

603 :仕様書無しさん:03/11/19 14:32
>>602
つうか、JAVAならJavaDocに従え。

604 :仕様書無しさん:03/11/19 15:00
つうか、PGはSEに従え。

605 :仕様書無しさん:03/11/19 15:09
コメントは道路標識と似ている。
「踏み切りあり」とか「横断歩道あり」とか「飛び出し注意」とか「駐車禁止」とか

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

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

606 :仕様書無しさん:03/11/19 15:21
どうりで東京の道路はコメントだらけで、わけがわかんないはずだ

607 :仕様書無しさん:03/11/19 15:57
>>600は章立て以前の問題

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

608 :仕様書無しさん:03/11/19 15:59
読点だった

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

609 :仕様書無しさん:03/11/19 16:07
>>603
従ってる。
さらにCVSにも従おう。
コメントつける手間を省くためにJakarta Velocityを使ったりIDEのテンプレートをつかったりすると
なお良い。

610 :仕様書無しさん:03/11/19 16:11
>>609
べろしてーがコメントと何が関係あるのか、圧死には里香射できませんが。


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

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

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

613 :612:03/11/20 01:50
>>611
ドキュメントはコメント以上に嘘が多くなる確率が高いんだなぁ。

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

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

615 :仕様書無しさん:03/11/20 02:16
>>612-613
「嘘コメントにだまされるのを回避する工夫」
コメントを信じないこと。コメント削除フィルタを作ることもある。(言語によっては結構難しい)

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

616 :仕様書無しさん:03/11/20 09:42
新人らしくていいなココ
ほのぼのするよ

617 :仕様書無しさん:03/11/20 10:42
>>616
「デスマでギスギスしているような香具師はこないから」ですかね。
それとも「わかりやすさなんていう定量的な評価が出来ない特性には関心がない」
なのかな。

618 :仕様書無しさん:03/11/20 19:21
>>614
極論すぎ。
ドキュメントが「わかりやすい」必要はないだろってことだよ。
そいでもって「わかりやすさ」が必要な人には中途半端があだになる。

619 :仕様書無しさん:03/11/22 06:58
ソースがコメントでありドキュメントであり仕様書である

620 :仕様書無しさん:03/11/22 11:30
>619
それ賛成w
でも客はうんとは言わない罠

621 :仕様書無しさん:03/11/22 15:20
>>619
ということにしたい

622 :仕様書無しさん:03/11/22 16:51
>>619
今まで何十年もプログラマはそのように主張してきたが、
保守性の高いコードを書いたためしが無いというのが現状。

623 :仕様書無しさん:03/11/22 18:10
>>618
さっそく意味不明。「あだ」の要件が定義されてない。

624 :仕様書無しさん:03/11/22 21:19
>>599
> initializeHoge()の定義がスクロールキーを一回押すだけで見える
> になっていても駄目ですか?

そういう機能を前提に考えるなら全部グローバル関数で作っても同じだと思うんだが。
従って、その機能に頼ってるとグローバル変数に頼るCOBOLerのような汚い設計にならないかな。
全員が常にその開発環境使うなら問題ないんだろうけど。

625 :仕様書無しさん:03/11/23 01:26
関数分割についての話題が出てきたのだが、
1関数(メソッド)あたりの行数について
1画面に表示できる範囲だとか、長くても100だとか、短くしろといわれるのだが、
1度しか使われない関数は作るなとも言われる。
この辺はどうなのでしょう。
長いという理由だけでわざわざ関数分割をすると、それぞれの関数の命名
に苦労するし、特に分割するような区切りがない場合(例えばDBから
フォームに表示するたくさんの内容を引っ張ってくるなど)でも、分割
したほうがいいのですか。



626 :仕様書無しさん:03/11/23 01:28
エディタを使って下記の内容のバッチファイルを作って、”c:\”に保存します
ってどうやればいいのですか?エディタの出し方がわかりません。お願いします。

627 :仕様書無しさん:03/11/23 01:35
test.bat

:start
goto start

628 :仕様書無しさん:03/11/23 01:36
ありがとうございます
これを打つのですか?

629 :仕様書無しさん:03/11/23 01:40
>626
そーゆー質問するときはせめてOSくらいは書くように。

俺の環境ならシェルでviもしくはemacsだ。

630 :仕様書無しさん:03/11/23 01:42
エディタを使って下記の内容のバッチファイルを作って、”c:\”に保存します。ファイルの名前は、”lsic.bat”とします。

set PATH=c:\lsic330c\bin;c:\lsic330c\temp;%PATH%
cd c:\lsic330c\temp

”set PATH=”というコマンドで、MS-DOSはファイルを探すときに、まず、カレントディレクトリを探し、なければこのコマンドで指示したディレクトリ(フォルダ)を探すようになります。カレントディレクトリとは、現在開いているフォルダのことです。

上記の文の2行目はカレントディレクトリを”c:\lsic330c\temp”に変更せよというコマンドです。

大変失礼しました。 上記のようなことを行いたいのですがお願いします。
OSはWINDOUS2000を使ってます。

631 :仕様書無しさん:03/11/23 01:44
訂正 WINDOWS 2000です。

632 :仕様書無しさん:03/11/23 01:47
>630-631
ファイル名を指定して実行でnotepadを起動すればいいだろうに。

今度からそういう質問はこっち(↓)でしてね。
スレッドを立てるまでもない質問雑談スレ13
http://pc.2ch.net/test/read.cgi/prog/1065814199/

633 :仕様書無しさん:03/11/23 01:50
>>625
> 1度しか使われない関数は作るなとも言われる。
抽象化の概念に真っ向から対立してるな

634 :仕様書無しさん:03/11/23 01:51
(´-`).。oO(何かdでもなく板違いなヤシが…)

635 :仕様書無しさん:03/11/23 01:53
ありがとうございます、参考になりました。
本当に感謝してます。あと忠告も守ります。

636 :仕様書無しさん:03/11/23 02:01
(・∀・)イイヨイイヨー

637 :仕様書無しさん:03/11/23 02:03
あと最後に
set PATH=”というコマンドで、MS-DOSはファイルを探すときに、まず、カレントディレクトリを探し、なければこのコマンドで指示したディレクトリ(フォルダ)を探すようになります。カレントディレクトリとは、現在開いているフォルダのことです。

上記の文の2行目はカレントディレクトリを”c:\lsic330c\temp”に変更せよというコマンドです。

とはどういうことを意味しているのでしょうか?教えていただけませんか?

638 :仕様書無しさん:03/11/23 02:18
緑髪メイドロボがいるな

639 :仕様書無しさん:03/11/23 03:35
無計画にその場凌ぎ行き当たりばったりでコーディングしてくから
途中で収集がつかなくなる。
思考の整理が出来ていないことは容易に想像できる。
モジュール化も全然要領を得ていないし、「モジュール化の意味はあんまよくわからないけど、
とりあえずモジュール化してみました」みたいなモジュールがゴロゴロある。
思考の整理、分類がヘタクソだから、そいつはコーダーとしてはおろかSEとしても無能である。
それはつまりIT業界において無能だってことだ。しかもシステマティックに考えられていないってことは、
今の時代、どこの業界に行っても無能で平均以下の働きしかできないだろう。
思考の整理もできていない、モジュール化もド下手では、とりあえずプログラムは動いても、
小さなバグが連発するし(あっちを直したらこっちがバグるの繰り返し)、
システムに柔軟性は皆無。細かな追加機能や仕様変更など出来やしない。
プログラムってのはそれを書いた人間の性質が良く出るからな。
上記のような穴だらけのプログラムを書く奴は私生活も穴だらけだ(笑)。無計画で無頓着。
人間として無能だと思っても良い。



640 :仕様書無しさん:03/11/23 04:08
639相当たまってそうだね。
たぶんいつも会社で同じような事言われてるんだろうね。
なんか可哀相だ。
みんなで励ましてやろうよ。

641 :仕様書無しさん:03/11/23 04:15
>>639
釣りなのかマジなのかわからんじゃないか(w

642 :仕様書無しさん:03/11/23 04:22
分類って難しいんだよ。
そういう学問もあるし。

643 :仕様書無しさん:03/11/23 05:33
コメントもプログラムなの?
コメントもバグるの?
コメントもテストしないといけないの?
誰か教せて

644 :仕様書無しさん:03/11/23 07:33
test

645 :仕様書無しさん:03/11/23 07:37
Visual Basic 、Visual Studio、Visual C#、Visual C++
と様々なソフトがありますが、違いを教えてください。
Visual Basicと Visual Studioの言語は何ですか?

646 :仕様書無しさん:03/11/23 09:22
>>645 くだ質へ行けよ。
http://pc.2ch.net/test/read.cgi/prog/1065814199/


647 :仕様書無しさん:03/11/23 10:55
コメント、仕様書、共になし。これ最強。

648 :仕様書無しさん:03/11/23 13:42
>>643
コメントはプログラムじゃない

コメントはバグらない。だから大嘘が書いてあることもある

コメントはテストしなくともいい。
コメントだけを追記したソースはobjモジュールのバイナリ比較を行い、
一致してれば、再テストは不要。

649 :仕様書無しさん:03/11/23 15:05
そういや、昔、コメント消したらうまく動いたCのプログラムがあった。


650 :仕様書無しさん:03/11/23 15:10
それはコンパイラがタコなんだろ。

651 :Cに隠れ潜む特殊演算子:03/11/23 15:14
 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 );


652 :仕様書無しさん:03/11/23 15:27
>>651
嘘だろ。代入演算子に「/*=」や「*/=」なんてあるのかよ。

653 :仕様書無しさん:03/11/23 15:29
>>651 別のパターン。
int i=10;
int *a=&i;
int b;
b=30/*a;

654 :仕様書無しさん:03/11/23 21:51
コメントは

#

にして、プリプロセッサディレクティブは

@

にすりゃ良かったんだよ。


655 :仕様書無しさん:03/11/24 18:52
>>652
ねたにマジレスかこ悪い。

っつーか、>>651は別に間違ってねーだろ。
C言語で//コメントを使うことについては別にして・・・・

>>653 は使えねー香具師だな。プ

656 :仕様書無しさん:03/11/24 21:23
>>655
>>653の「b=30/*a;」のが単なる除算なのか、それともコメント開始記号があるのかを教えてくらさい。


657 :仕様書無しさん:03/11/24 22:19
かっこを揃える。

System.out.println("aaaaaaaaaaaaa"  );
System.out.println("aaaaaaaaaaaaaa" );
System.out.println("aaaaaaaaaaaa"   );
System.out.println("aaaaaaaaaaaaaa" );

これはずれてるけど、まあ、そういうこった。

658 :仕様書無しさん:03/11/24 22:26
>>657
ダサイ。超ダサイ。今時、非プロポーショナルなエディタでしか通用しない
「揃える」なんてこと超流行らない。無駄。キモイ。修正が面倒になるだけ。
String HOGE=
"asfasdfasdf"+ // foo
"adfasdfa"+ // bar
"afsad"+ // fooo
"asfasfasdfasfasdfaf"; // barr

こういうときに、無駄な労力でコメントを揃えたりしてるのか!?(哄

659 :仕様書無しさん:03/11/24 22:56
気の利いたIDEだったらそもそも揃えられない気がするが。
いまだにインデントとかで苦労してるのか?

660 :仕様書無しさん:03/11/24 23:27
「いで」って何ですか?

661 :仕様書無しさん:03/11/24 23:32
頭悪そうに見えるからひらがなで書くな! 漢字で書け!

662 :仕様書無しさん:03/11/25 00:04
>>660
ほら、科特隊の。

663 :仕様書無しさん:03/11/25 01:00
>>662
古杉っ!

664 :仕様書無しさん:03/11/25 02:53
いるねぇ〜新人で658みたいなの

665 :仕様書無しさん:03/11/25 04:54
>>658
複数行にまたいで記述するとき=や+の演算子は行末じゃなく行頭だな。
で、コメントは揃える。
お前の書いたソースは全部直させることになりそうだ

666 :仕様書無しさん:03/11/25 05:03
>>665
細かいこと気にしていると禿げるぞ

667 :仕様書無しさん:03/11/25 05:41
>>666
細かいところに気が回らない奴はプログラマにならなくていいよ。

668 :仕様書無しさん:03/11/25 06:30
>>667
禿げるならプログラマなんかにならないよ

669 :仕様書無しさん:03/11/25 06:38
細かい所に気が回る俺は、
if(!get_pointer()) は禁止して、
if(GetPointer()!=NULL) と書かせていますが何か?

670 :仕様書無しさん:03/11/25 07:27
オブジェクトにNullableインターフェイスを実装させて、
if(! GetPointer().isNull())と書き、
可能な限りNullオブジェクトにロジックを移すのが普通です。

671 :仕様書無しさん:03/11/25 10:15
>>665
演算子を行末じゃなく行頭というのにどのような根拠があるのか知らんが

少なくともコンピュータサイエンスの論文の数式では行末に演算子を置く
(=などは例外だが)

672 :仕様書無しさん:03/11/25 11:23
行頭に演算子置くと行の追加・削除が楽

if (
a |
b |
c
)

とかだとc以降に追加したくなったときとかは
cとそれ以降を編集する必要がある。

if (
a
| b
| c
)

とかだとcは編集しなくていい。

673 :仕様書無しさん:03/11/25 12:42
くだらね

674 :仕様書無しさん:03/11/25 13:54
つうか、絶対書かないことを議論してもね・・・。
>>672に関して言えば、根本的にどっちも糞。

675 :仕様書無しさん:03/11/25 14:09
>>674
つまりお前はどんなに長くなっても絶対に行を分割しないと言うことだな。
そして、どのような場合でも条件にはコメントを付けないと言うことだな。

676 :仕様書無しさん:03/11/25 19:13
>>672
ラインエディタ常用してるの?

677 :仕様書無しさん:03/11/25 20:40
ラインエディタってなんだよ?

678 :仕様書無しさん:03/11/25 20:43
( ゚Д゚)ハァ?

679 :仕様書無しさん:03/11/25 23:02
俺はcopy conでプログラム書いてるYO!

680 :仕様書無しさん:03/11/25 23:31
>>672
a を削除してみろ

681 :仕様書無しさん:03/11/25 23:34
>>677
もしかして、エドりん
しらんのか?

682 :仕様書無しさん:03/11/25 23:50
今時、えどりん・・・ 懐かしくて涙が出る。
よくあんなモンで仕事してたよな。

683 :仕様書無しさん:03/11/25 23:50
>>680
672じゃないけど、aを削除することってめったにないよ
printfとかね。

684 :仕様書無しさん:03/11/25 23:51
あ、if文だったか。
printfの場合は
printf("書式"
,b
,c
,d
);
みたいなこするよね?ね?

685 :仕様書無しさん:03/11/26 00:53
>>684
悪いけどそれは…

しねーよ

686 :仕様書無しさん:03/11/26 01:17
ここは「修正間違いを起こしにくいソース」スレじゃないぞ。
「わかりやすい、上手、美しい」のテーマとは方向性が違うじゃねーか。

687 :仕様書無しさん:03/11/26 01:52
関数のはじめに↓こういうの↓を書く。どんどん装飾華美になっていくが。
//‥。                    。*
// ☆★ ┏━┓┏━┓┏━┓┏━┓┏━┓ ★☆
//  ☆★┃メ┃┃イ┃┃ン┃┃関┃┃数┃★☆
// ☆★ ┗━┛┗━┛┗━┛┗━┛┗━┛ ★☆..
//"                      *

688 :仕様書無しさん:03/11/26 01:54
>>687
それは洗練された美しさとは程遠いな

689 :仕様書無しさん:03/11/26 02:45
>>687
そのうち色を付けたいっていう不満を持つようになると見た

690 :仕様書無しさん:03/11/26 04:35
俺もここ見て気持ちがかわった
面倒だけど今日から日本語の部分バイナリーにするよ

// 000000 83 81 83 43 83 93 8A D6 90 94
void main()

慣れてきたら文字コードもレアなのにするね
これで俺もついに、あすきーてきすとが書けるぜ!!!

691 :仕様書無しさん:03/11/26 06:44
>>687
すばらしい! プログラミングが楽しくなりそう
そのうちAAとかも導入したいね

692 :仕様書無しさん:03/11/26 09:56
>>691
例外来たー!とか書いてあるのか?顔一回転して。
処理待ちは猫が茶飲んでたり。
メッセージはメッセージまだーって茶碗をチンチン。


693 :仕様書無しさん:03/11/26 10:54
>>690
ついでにmainもint main()に変えることを勧める

694 :仕様書無しさん:03/11/26 14:52
必死こいてゴミを作ってるような気がしる・・・・_| ̄|○

695 :仕様書無しさん:03/11/26 15:44
>>692
(・∀・)イイ!

696 :仕様書無しさん:03/11/26 21:24
就職してからずっと他人のゴミばかり修理している俺_| ̄|○
美しいソースが見たい

697 :仕様書無しさん:03/11/27 00:49
オブジェクト指向言語(Java)で、

// ○○関数
public void hogehoge() {
  ..................................
  ..................................
  ..................................
  ..................................
}

っていうふうに「関数」って文字列を発見するとムカツク。
しかもjavadocじゃない。
あと、モデリングされた形跡がないクラス群ほどムカツクものはない。
フィールド宣言だけで、3000ステップ。総ステップ数13000のJavaソース。
正直、メンテできねーよ。

698 :仕様書無しさん:03/11/27 00:58
>>697
なんとなく分かるわ。
ついでに、Javaの大規模システムは、できるだけ有名FW使ってほしいよな。

699 :仕様書無しさん:03/11/27 01:18
>>698
挙動が広く知られてるって意味じゃ有名なやつがいいだろうけど、
別に自社製フレームワークでも構わない。意味のあるクラス群ならば。





700 :仕様書無しさん:03/11/27 03:20
>>658
文字定数の連結に+つかうなよ・・・

701 :仕様書無しさん:03/11/27 04:14
>>610
Velocityでソースコード自動生成するならばワンパターンでいつも同じのばかりなコメントにも
Velocityをつかうべきだ

702 :658:03/11/27 09:56
>>700
Cライクに連結演算子抜きで書けと?しかしJavaには連結演算子しかないのだぞ?
それとも一リテラルに全部書けというつもりか?
文字列各行に意味があるからわざわざ分割しているのだと察っする心づかいは皆無なのか?
そしてあれだ。貴様。
ヒアドキュメントすら持たない貧弱なコンパイル言語のコンパイラが
必死でコンパイル時に文字定数の連結を最適化しようと進化してきたのを
蔑ろにする暴言を吐くのはその口か。恥を知れ。

703 :仕様書無しさん:03/11/27 10:01
ヒアドキュメントはインデントを壊す。

704 :   :03/11/27 13:05
>>700
>>702
ちゃんと、javaコンパイラが置き換えてくれるから安心しろ。

705 :仕様書無しさん:03/11/27 14:34
誰でもすぐにソースコードを見られるソフトで、
ソースコードがきれいなのって何があるかな?


706 :仕様書無しさん:03/11/27 15:48
>>705
どんな言語を仮定してるんだ?

707 :仕様書無しさん:03/11/27 17:01
>>702
安心しろ。単なるVB厨だから。

708 :仕様書無しさん:03/11/27 17:23
うちは、激しく狭いので風呂の脱衣場はカーテンのみ。
こないだスッポンポンになってたら、いきなり父親にカーテン開けられました。
16歳にもなって、父親に全裸見られました。凄く恥ずかしかったです。
父は心臓が悪いのですが、娘の裸を見たショックで軽い発作を起こしやがりました。
だ〜か〜ら〜普段から、誰も居ないか開ける前に気をつけろと言ってんのになぁ…。
http://www.dfnt.net/t/photo/column/kabuto.shtml

709 :仕様書無しさん:03/11/27 20:12
>>706
特に想定はしていません。
「このプログラムのこのあたりが (こういう理由で) 美しい」
という意見があるといいなと思ったんです。実際に動いていて
使われているプログラムが例になってれば説得力があるので。

聞きかじりで申し訳ないんですが、例えば GhostScript とか
NetBSD がきれいだという話は聞いたことがあります。これは
両方とも C ですが、他の言語に関しても有名な例があれば
教えてほしいんです。例えば Java ではどうでしょう。


710 :仕様書無しさん:03/11/27 20:34
>>709
Java 2 SDK 自体は結構綺麗だと思うが

711 :仕様書無しさん:03/11/28 12:22
>>710
禿道。

jdkのソースをhackするのが比較的良い。


712 :仕様書無しさん:03/11/28 22:00
>>710,711
なるほど。Java SDK は盲点でした。
読んでみようと思います。


713 :仕様書無しさん:03/11/29 21:04
プロは始めからリリースモードで作成する。
原因が特定できないバグが発生した時、
初めてデバッグモードに切り替えデバッグする。
素人はデバッグモードで作成し、リリースモードに切り替えると
動かないプログラムを作り上げる。
素人はそれをデバッグせずに納品する。


714 :仕様書無しさん:03/11/29 22:57
>>713
それって何の言語処理系のこと?。もしかしてM$が出しているやつ?

715 :仕様書無しさん:03/11/29 23:02
713はprintfデバッガ使い

716 :仕様書無しさん:03/11/30 13:56
>>716はOutputDebugStringデバッグ使い

717 :仕様書無しさん:03/12/04 22:06
↑一人突っ込み?


718 :仕様書無しさん:04/01/12 13:10
良スレなので上げます。

719 :仕様書無しさん:04/01/12 16:20
>>713
まじレスしてくれると有り難いんだが、それ普通じゃないの?

720 :仕様書無しさん:04/01/12 16:30
マジレスするが、プロなら原因が特定できないようなバグは発生しない。

721 :仕様書無しさん:04/03/20 20:52
age

722 :仕様書無しさん:04/03/20 21:24
条件によっては必要ないこともある変数とか処理を書かない。
本人はちょこっと修正して対応できたと思ってるかもしれないけど
これってスパゲッティでしょ

723 :仕様書無しさん:04/03/20 21:41
スパゲッティ=処理の流れが複雑に絡み合っていること。

724 :緊急:04/03/20 22:30
急ぎ、調査しています。知恵を貸してください
?は k を 表してますよね。?は何を表すのでしょうか?
スペースでしょうか?明日、朝までに解読する文書が有り。ここが判らず困って
います。宜しくお願い致します。

725 :緊急:04/03/20 22:34
すれ違いかも知れませんがしってる方いたら教えて下さい。

726 :仕様書無しさん:04/03/20 22:34
>>724
>?は k を 表してますよね。?は何を表すのでしょうか?
こちらWinXP+A Boneだが、↑こう見えている。
他人にも分かるように書け。

727 :緊急:04/03/20 22:45
>726 
すいません。ちゃんと打ってるのですが。&#65355 = k
& # 12288  がわかりません。ちゃんと打ったんですが今度はスペース入れて打って
みました。 本当は繋がってkを表します。

728 :緊急:04/03/20 22:51
& # 65353 = i  
& # 65354 = j
& # 65355 = k
と変換されますよね(全部スペース無)
& # 12288 が判りません、多分記号かスペースと思うのですが。
ちゃんと打っても ? と表示されてます。コードだからでしょうか?

729 :仕様書無しさん:04/03/20 23:09
>728
IMEパッドで調べればわかるが、
&#12288=ユニコードU+4800=MS明朝等(日本の環境)では未定義。
台湾の繁体文字の1個という可能性は高そうだが。

730 :緊急:04/03/20 23:21
729>
スイマセンどうやれば判りますか?ここだけが解読出来なくて。
意味だけでも知りたいのです。これを書いた者は外国人です。
ロシア語、英語、ヒブン?(イスラエル文字)を使う者です。アルファベット
に気付くのにかなり時間がかかり、最後ここだけが判りません。知恵を貸して下さい。

731 :緊急:04/03/20 23:40
12280から 12290まで変換しました。多分スペースの様です。
今、全文変換したところですが。文として意味が通りました。
やっと、ゴハン食えそうです。
ただ、こんなモノ普通使いますか?メールのアドレス帳に・・・
外国では、一般人もこんな事してるんでしょうか?別のナゾが・・・


732 :仕様書無しさん:04/03/21 00:12
>>729は、俺の勘違い
× &#12288=ユニコードU+4800=MS明朝等(日本の環境)では未定義。
○ &#12288=ユニコードU+3000=いわゆる全角スペース。

よって、>>731で正解

>ただ、こんなモノ普通使いますか?メールのアドレス帳に・・・
>外国では、一般人もこんな事してるんでしょうか?別のナゾが・・・
漢字を打てない環境で漢字を表現するには、
そんな手を使うほかないでしょ。

733 :緊急:04/03/21 01:25
>732
THANKS
とりあえず、前文繋がりましたので。意味も判り。
本人を助けてあげられそうです。


734 :仕様書無しさん:04/03/21 06:02
・・・曜日や時間帯とから判断するに、本当に緊急だったんだね
おれの生活と対比して考えられないような生活だなあ
とりあえずこれしかいえないよ
「よかったね」

735 :緊急:04/03/21 10:30
>734
お蔭様で。今起きました。これで、諸準備をして、月曜日。朝一間に合います。
PCは、殆ど判らないのですが。情報理論等は必修でやっていたので。後、いい歳
なんで。むかしBasic で変換プログラムを課題でやったものですから。何とかなりました。


736 :仕様書無しさん:04/03/21 19:06
ふと、「【緊急】助けて下さい!【事態】」等というスレを作ったら良いのではないか、
と思った。首になりそう、遅れたら多額の賠償必至など、本気で緊急事態の香具師を助けるための。

737 :仕様書無しさん:04/03/21 19:35
そんな状況で2ch見ているのかと。

738 :仕様書無しさん:04/03/21 19:44
ていうか、なぜこのスレに書き込んだんだろう……?
単に上に上がってたから?


何のための質問・雑談スレなんだか(´ー`)

739 :緊急:04/03/21 21:33
マジに答えます。ある方を助けたく、その子のメモの一枚が & # XXXXXで
書かれていて初め全く判らず。昔を思い出し。アルファベットは自分で変換し
英文になってることが判ったのですが。最後が判らず。困っていて2chをみていて
スレ違いと思いましたが。ここが一番、適切な意見を貰えそうに見えて書きました。
マジで昨日はあせってました。詳細は、裁判に係わること故、今は書けませんでした。

740 :仕様書無しさん:04/03/21 22:24
漫画のユウスケみたいな方なのかな?


741 :仕様書無しさん:04/05/06 03:31
asdfasdf

742 :仕様書無しさん:04/05/06 11:30
20連結ユニオンクエリ、
5重ネストサブクエリ、

鬼!

743 :仕様書無しさん:04/05/06 12:04
>>742
なんかそんなSQL書くはめになったことがあったな…。

根本的に、DB設計が腐ってると思うがどうよ。w


744 :仕様書無しさん:04/05/06 12:45
dataモデリング

745 :仕様書無しさん:04/05/06 14:23
カット&ペースト禁止

これだけで君のプログラムもずいぶんよくなる。
試してみたまえ。

746 :仕様書無しさん:04/05/06 21:21
int hogeHoge ()
{
 if(a > 0)
 {
  b++; //なんか処理
 }
}
------------------------
int hogeHoge () {
 if(a > 0){
  b++; //なんか処理
 }
}

括弧の付け方てどっちが正解?
漏れは上のが解り易いけど、
初心者っぽいから下で書いてる。


747 :仕様書無しさん:04/05/06 22:01
int hoge()
{
  if (a > 0) {
    // なにかする
  } else {
    // なにかする
  }
  return 0;
}

俺はこう書くけど、どれが正解なんてないんじゃないかな。

748 :仕様書無しさん:04/05/06 22:02
>>746
それは大昔からの「スタイル論争」だ。
平気で他人の習慣に文句をつける人達がやってきて不毛な論争になる
あえて言うなら「どちらも正解」

749 :仕様書無しさん:04/05/06 22:30
>>745
言ってる事は正しいけれど、試してみる人がいるとは思えんな

750 :仕様書無しさん:04/05/07 00:43
>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;
 }

751 :仕様書無しさん:04/05/07 01:28
>746
うちは下。上下に間延びするのがヤなんで。

美しさなら上なのかも。
pascal の begin 〜 end の記法を考えると上のが近いか。
初心者向けのCの解説書も上のが多いね。
ま、どちらでもいいと思うんで、書きやすい&読みやすいほうでどぞ。

752 :746:04/05/07 20:18
>>747-751
レスありがd
上の例は教科書みたいって馬鹿にされるかと思ってた。
どっちでも良かったと、じゃあわかりやすい改行多目のほうで書きます。
ステップ数も稼げる(゚д゚)ウマー

753 :仕様書無しさん:04/05/07 21:09
> ステップ数も稼げる(゚д゚)ウマー

いまどきステップ数て…(呆

199 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)