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

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

この会社辞めようと思ったソースコード#D

1 :Ponkotsu Generator:04/02/21 20:16
この会社辞めようと思ったソースコード。
プログラマとして幻滅するソースコード。
プログラマを悩ませるソースコード。
Modula-2 ライクなソースコード。(゚д゚)ウマー
をつらつらと綴っていって頂戴。

ちなみにここは質問スレじゃないよ。
技術的な質問がしたいならム板に逝って。

2 :仕様書無しさん:04/02/21 20:19
● 過去スレ
1:http://mentai.2ch.net/prog/kako/997/997104873.html
2:http://pc.2ch.net/prog/kako/1001/10010/1001076034.html
3:http://pc.2ch.net/prog/kako/1015/10158/1015861447.html
4:http://pc.2ch.net/prog/kako/1021/10215/1021560641.html
5:http://pc.2ch.net/prog/kako/1029/10291/1029120005.html
6:http://pc.2ch.net/prog/kako/1029/10291/1029120005.html
7:http://pc.2ch.net/prog/kako/1036/10367/1036779521.html
8:http://pc.2ch.net/test/read.cgi/prog/1040451049/ (dat落ち中)
9:http://pc.2ch.net/test/read.cgi/prog/1045401372/ (dat落ち中)
A:http://pc.2ch.net/test/read.cgi/prog/1049973793/ (dat落ち中)
B:http://pc.2ch.net/test/read.cgi/prog/1054362467/ (dat落ち中)
C:http://pc.2ch.net/test/read.cgi/prog/1067794604/

3 :仕様書無しさん:04/02/21 20:21
● 関連
この会社辞めようと思った上司の一言#E
http://pc.2ch.net/test/read.cgi/prog/1075987262/

まな板娘、誕生の記録 (この会社辞めようと思ったソースコード#B)
http://pc.2ch.net/test/read.cgi/prog/1054362467/920-n

まな板娘[まないた・むすめ]

マ板における幾多の妄想の産物キャラのうちの一人。
上記過去スレ参照。
転機となる一言は該当スレ >>945 参照。
キャラ的には萌える要素満載だが、未だに絵はない。


というわけで今スレでも画像キボンヌ

4 :仕様書無しさん:04/02/21 20:31
>1

乙。

5 :仕様書無しさん:04/02/22 00:30
5?

6 :仕様書無しさん:04/02/22 06:56
6 goto 1

7 :仕様書無しさん:04/02/22 16:01
漏れ埋め立て乙。

8 :仕様書無しさん:04/02/22 16:10
>>7
氏め

9 :仕様書無しさん:04/02/22 20:11
乙〜

10 :仕様書無しさん:04/02/23 03:18
全スレ986のことだけど、デバックモードでしかしないんだったら
ゆるせるかなと一瞬思ったけど、デバックモードどそうでない状態で
プロトコル変わっちゃうの?そりゃまずいんでないですか。

11 :仕様書無しさん:04/02/25 08:10
>>10
typoばっかりある中で、そこに注視せよ、っつても無理のある事ではあるのだが、
いちおう、
#ifndef _DEBUG
なんだ…………。

12 :仕様書無しさん:04/02/25 12:52
なかじま かおる 1960ねん あいちけん とよかわしうまれ。26さい。
おまんこなめてーよぅ えっちする女の子がほしい
チツちゃん クリちゃん すき!すき!

13 :仕様書無しさん:04/02/25 12:56
1960ねんうまれ。
   ↑
間違ってないか?
   ↓
26さい。


14 :仕様書無しさん:04/02/25 13:06
>>13
当時26歳だったのだよ。

15 :仕様書無しさん:04/02/25 13:07
>13
12は昔のファミコン用ゲームにあったコメント

16 :仕様書無しさん:04/02/25 13:08
20年も前にいったい何が?!

17 :仕様書無しさん:04/02/25 13:11
URLぐらい貼っといてよ。
http://www.geocities.co.jp/SiliconValley/8474/yoiko/yoiko5.html

18 :仕様書無しさん:04/02/25 23:46
>>12
それってでもソースじゃないよな。バイナリに直接・・・ってもはやどうでもいいが。

19 :仕様書無しさん:04/02/27 01:36
「GridBagLayout使うと可読性落ちるからやめましょう」
と言われたんだが、レイアウト合わせるためにラベルやテキストフィールド幅に
定数値多用しているのよりはよっぽど可読性高いと思った今日この頃。


20 :ヽ(´ー`)ノ:04/02/27 10:10
>>10
(そいつにとっては)可読性低い。


21 :仕様書無しさん:04/02/28 00:55
可読性をうるさく言う奴に限って自分では読まない

22 :仕様書無しさん:04/02/28 01:46
>>21
自分で読むからこそ、うるさく言うけど

23 :仕様書無しさん:04/02/29 21:03
コーディング規約をうるさく言う奴に限って自分では読まない


24 :仕様書無しさん:04/02/29 23:51
ツールの実行一発で判定/修正できるコーディング規約のみ指定する。
規約自体は必要だが、検査に人手を介するのはダメプラクティス

25 :仕様書無しさん:04/03/03 01:42
コーディング規約はいいんだが、
規約のためにいらん書類が増えるのは勘弁。

public class ClsYamashitaA0001 extends ClsUITantou001Gaichu0001

クラス1個作るのに「クラス概要仕様書」「クラス詳細仕様書」
「クラス仕様書一覧表」「クラス作成者一覧表」を書けと。

外注に丸投げしてヒマなのか?


26 :仕様書無しさん:04/03/03 02:02
>>25
あるにこした事はないが、まあ普通JavaDocだろうな。

27 :仕様書無しさん:04/03/03 15:00
>>25
結局ソース読むことになるから、いらないよな

同じようなクラスを重複して作らな無いような仕組みはほしい

28 :仕様書無しさん:04/03/03 16:05
社長自らが新人教育と称して
自分のキャパを超えた知識を教えている会社
知ったかぶりのTOPを持つと部下は最悪・・・
赤字プロジェクトはすべて責任を社員に押し付ける社長
小さな会社は社長が法律です


29 :仕様書無しさん:04/03/03 21:33
新人教育でコーディングシートにコーディングをさせる会社
よりはまだマシです。
まだあるのよ。こういう会社。

30 :仕様書無しさん:04/03/03 22:03
よく今どきコーディングシートなんか調達できるな。
まだ作ってるところあるのか?

31 :仕様書無しさん:04/03/03 22:14
>>30
コボラーが絶滅しない限りコクヨあたりが作ってくれるでせう。


32 :仕様書無しさん:04/03/03 23:19
>>26
ドキュメントはWordで作るという規約

33 :仕様書無しさん:04/03/03 23:30
クラスに「概要書」なんて求めるのは,
クラスを「サブルーチンの集合体」だと思ってるからに相違無い

34 :仕様書無しさん:04/03/03 23:31
エリカ・ユングって可愛くな〜い?

35 :仕様書無しさん:04/03/03 23:33
コーディングシートと鉛筆っていうのがまるっきり悪いとは言えないよ。

うちの会社の連中は新機能追加の修正とかの場合
いきなりソースファイル開いてあてずっぽでコピペし始めるからなぁ。
結果はもちろん突然脈絡も無く使ってもいないフラグを立てたりとかばっかり。

ソースコードじゃないけど別なチーム担当システムとの連携で発生した障害対応中
「とりあえずそっち側で日付がX日になってるデータを全部出してみて」と
そっちのチームの中堅クラスに言ったら
select * from XXXX
ってクエリを実行して結果をExcelにコピペしてフィルタとか使われた時には
本気でそいつらのシステム全て葬りたくなったなぁ。

36 :仕様書無しさん:04/03/03 23:45
コーディングシートって言うのは、その昔
端末の台数が限られている環境なんかで
プログラマがパンチャーさんにソースのパンチ(入力)
をお願いするために使われていたものだよ。

依頼からコンパイルが完了までどれだけの時間を要した
ことか(⊃д`)

37 :仕様書無しさん:04/03/04 00:04
>>35
そういう人たちはコーディングシートにもあてずっぽうで書き込むんだよ、きっと。

38 :仕様書無しさん:04/03/04 00:09
>36
タコなパンチャに当たるとパンチミスだらけでヒサンだたw
まあ、ふつうは別人がベリするので問題なかったんだが、
ベリを省略されることもあった。そういうときの話。
(ベリ=ベリファイ=別人が同じカードにまったく同じ内容を打ち、
食い違いがあったらハジく作業)

39 :仕様書無しさん:04/03/04 00:44
昔はコンパイルにもカネがかかったから、それの節約も兼ねてたとしても
今はそんな時代じゃないし。

40 :仕様書無しさん:04/03/04 00:47
>>36
ふるーいアセンブラとかFORTRANとか
カラムによって意味が決まってる言語の場合で
パンチカードとかで入力するの場合は、
あった方が便利だったそうだ。

41 :仕様書無しさん:04/03/04 13:56
>「とりあえずそっち側で日付がX日になってるデータを全部出してみて」と

この要求に対して、

>select * from XXXX
>ってクエリを実行して結果をExcelにコピペしてフィルタとか使われた時には

このアプローチって有りに見えるが。
要求は満たしているんじゃないのか?


42 :仕様書無しさん:04/03/04 14:45
まあ間違ってはいないわな


43 :仕様書無しさん:04/03/04 15:35
いや、おかしい。感覚的に。理由を書いてみようか。

コピペ
 (再現性のない)オペレーションは極力するな。操作というものは間違えるものだ
execl
 db上で行うべきフィルタリングを何故に、よりによって表計算ソフトなぞつかう
 なんのためにsqlがあると思っているのか
データ量
 この場合は問題にならないだろうが、この方法はデータ量に上限がある

要求を満たせばいいという感じ方にも問題があるなあ。
ちゃんとsqlを切ることが出来る人ならどっちの方法を選ぶべきかは、自明だ。
まあ「この方法しか知らないとか思いつかない香具師のヘタレぶり」が話題なんだけど

44 :仕様書無しさん:04/03/04 16:06
要求さえ満たせばいい=動けばいい=それらしく見えればいい

なんつうか、糞コード量産する奴らの基本姿勢だな
まあ、それさえも出来ない奴もいっぱい居るけどなー

45 :仕様書無しさん:04/03/04 18:30
>>41
>このアプローチって有りに見えるが。
いや、中堅クラスでそーゆー「オラクルマスターうんこ色」レベルってのはちょっと…

46 :仕様書無しさん:04/03/04 18:57
>>43
べつに>>35で槍玉に上がってる奴らを擁護する気は無いが、
障害対策のためのデータ抽出なら別にいいと思うが。
むしろ>>43みたいにガチガチにかたまって、柔軟性のなさの
方が障害対策時には厄介だとおもうけどな。

47 :仕様書無しさん:04/03/04 20:51
>>43
まあ、excel とするべき所を、execl としているところが、
プログラマらしくていいな、と思ったり。

48 :43:04/03/04 21:41
>>46
了解。それもまた一つの見解だ。
#ガチガチっていうが、俺は「ちゃんとselectすべきだ」って言っただけだけど。二次障害に直面したことが無いんだろうね

>>47
_| ̄|○

49 :仕様書無しさん:04/03/04 21:57
>>48
見苦しいね…

50 :仕様書無しさん:04/03/04 23:30
>46
 どうまかり間違っても無駄だが。

 仮に日付を where に書いたとしてもインデックスが使われてない、という場合でも、
データ抽出にかかる時間は select * と変わらないよね。でも RDBMS がデータを送り出
す手間は明らかに減る。
 加えて、得られたデータを再加工する手間考えたら、ふつーに where 書いて当然だろ。

 だいたい、障害対応ってことはその RDBMS、本番稼働しているマシンじゃん。そんなの
に迂闊に select * かけたりしたら、それこそ二次災害起こしかねないんだがねえ。

 そもそもの条件が曖昧で、where で一発で取れない、ってんなら、ある程度余裕もたせ
て取ってきてから吟味するのはよくあることだが、日付限定できるのにしないってのは
馬鹿と言わずしてなんなのだろう。

51 :仕様書無しさん:04/03/04 23:52
本番稼動してるからといって全面的に信用してしまう姿勢が「ガチガチ」って言われるのだよ
問題が潜んでるから障害対策してるんだろ?

52 :仕様書無しさん:04/03/05 00:14
>>51
よくわからんが
RDBMS が信用できない状態で
テーブルの全件取ってこれるのか?

それだけでも
RDBMS が信用できないから
って理由は消えると思うのだが

53 :仕様書無しさん:04/03/05 00:33
多分、稼動2日目くらいで * で取ってきてもたいした数じゃなかったんだよ。


54 :仕様書無しさん:04/03/05 00:39
>>52
ガ チ ガ チ

55 :仕様書無しさん:04/03/05 00:58
俺 の ち ん こ だ け は ガ チ ガ チ

56 :仕様書無しさん:04/03/05 01:02
>>55
小さいけどな

57 :仕様書無しさん:04/03/05 01:03
>>56
何で知ってるんだ。ちなもに仮性でもあるのだが。

58 :仕様書無しさん:04/03/05 01:08
>>56
マイクロカーネルです。


59 :35:04/03/05 01:58
なんか論じられてる(w

>>この方法しか知らないとか思いつかない香具師のヘタレぶり
まぁ俺としても感じたのはそこ。
っつーかそんな奴が作ったシステムをどう信じろというのか…

ちなみに障害の原因ももちろん向こうのシステムだった。
詳細を述べるのは差し控えるが、要するにはデータ操作があったら必ず行う処理を
追加の時はやってて修正の時はやっていなかったという凡ミス。勘弁してくれ。

60 :仕様書無しさん:04/03/05 02:25
>>59
勘弁するから詳細よろ

61 :仕様書無しさん:04/03/05 06:48
コボラーにSQLを書かせるとWHERE句無しのSQLを書いてくるよ。
全件取得したデータを1件ずつIF文で処理対象か否かを判定するのさ。

..._| ̄|○ <何のためのSQLなんだ

62 :仕様書無しさん:04/03/05 09:19
>>61
っつーかそれが奴らのオンリーワンなやり方だし。
コボラーの手にかかればRDBだろうがXMLだろうが全てCOBOL色。
一体なんなんだよ固定長XML(うちの会社のコボラー命名)って。

63 :仕様書無しさん:04/03/05 09:38
delete する時は、
必ずselectして
行があるのを確認してからdeleteします。


64 :仕様書無しさん:04/03/05 09:46
彼等にはコダシルが必要なんだ。

65 :仕様書無しさん:04/03/05 10:17
deleteは必ずキー値で抽出して一件ずつ削除します。

66 :仕様書無しさん:04/03/05 11:01
今一緒に仕事をしてる先輩は最初、Accessのプロという触れ込みだった。
「教科書的な作り方をしてもパフォーマンスはでない。
テクニックをいろいろ知ってるから教えてやる」
みたいな感じの強気の発言してた。
でも、実際仕事をしてみると、そもそもセオリーをまったく知らないし
一般的なセオリーどおりに作ったよりぜんぜんパフォーマンスのでない
作り方しかできない人だった。

テーブルの設計でパフォーマンス出すために非正規化してるわけじゃ
なくて、そもそも「正規化」という言葉を知らなかったし。

SQLも自分では書けなくて、AccessのGUIツールで作って、それを
コピペしてるし。
あとあとマルチユーザーにも対応でるように、データベースは
SQL Serverかほかのものに変更できるように設計しようという
話が出たときに、なぜか動揺してて、SQL ServerもAccessから
接続できて今まで通りGUIでリレーション作れると教えたら
嬉しそうにしてやんの。

67 :仕様書無しさん:04/03/05 11:18
COBOLにて。
西暦2000年対応やっていたら、うるう年ベタ打ち発見。
YYが84の時か88の時か92の時か96の時…(略) ってなんだよぉ(涙

って、でもこのパターンはありがちなのかしら。

68 :仕様書無しさん:04/03/05 11:34
>Accessのプロ
この表現自体がかなり痛いわけだが。

69 :仕様書無しさん:04/03/05 11:34
このスレに出てくるような人間を生で見たい。 次プロジェクトが何千人月規模でCOBOL満載(MQで完全隔離)だから、嫌というほど見られるかな。

70 :69式フリーPG ◆hND3Lufios :04/03/05 12:33
DELETE文でWHERE句を設けずにループして一行一行消してるのはみたことあるな。
「日次処理のときパフォーマンスが出ないんです。この糞Windows!何とかしてください」
と言われてみたらそんなコードだった。

71 :69式フリーPG ◆hND3Lufios :04/03/05 12:34
失礼、WHERE句はあった。ただ、一行を指定するようなWHERE句だったな。

72 :仕様書無しさん:04/03/05 16:59
>>67
ヲレは取り敢えず、4年・100年・400年毎の補正は組み込んでるなぁ。
西暦3200年・・・・ヲレの作ったプログラムが1200年も使われるとは思えんw

73 :仕様書無しさん:04/03/05 17:14
>>72
2100年の事は考えないことにしている

74 :仕様書無しさん:04/03/05 19:18
>>73
まー、みんな芯でるだろうしな。

75 :仕様書無しさん:04/03/05 22:14
400年ルールのおかげでとりあえず2000年は救われた香具師>>73-74

76 :仕様書無しさん:04/03/05 22:27
閏年かどうかなんて、>>72の考え方なら一行で書けるだろうがよー
まったくよー

77 :仕様書無しさん:04/03/05 23:47
>>67
うちにもそういうのあった。
年ごとに各月の日数が定義してあるようなヤツ。

まぁ、何も見なかったことにした。

78 :73:04/03/06 00:27
漏れの場合は、Windowsのプログラム専門だからなあ。
2100年まで、Windows使ってるとも思えんしなあ。

と、20世紀のプログラマ達も、そう思っていたんだろうなあ

79 :仕様書無しさん:04/03/06 00:29
小惑星が衝突して自転周期が変わってしまう罠

80 :仕様書無しさん:04/03/06 02:37
最近、暦のほうを修正したほうがひょっとして楽なんじゃないかと思い始めたわけだが


81 :仕様書無しさん:04/03/06 08:36
>>80
禿同。
毎日11月23日なら尚良し。

82 :仕様書無しさん:04/03/06 08:56
>>80
11月23日生まれの人の年齢計算が大変だぞ

83 :仕様書無しさん:04/03/06 12:31
>>61-62
その方法はCOBOLとしては「正しい」コードだったらしいよ。
SQLで条件絞るよりもよっぽど速いそうなので。

プラットフォームが変わってもそれしか知らないのなら
ちゃんと教えてやらないといけない。

あー、当然Java屋がCOBOL書けって言われたときにSQLで
がりがりがんばってもきっと馬鹿にされるだけだぞ。


84 :仕様書無しさん:04/03/06 13:07
>>83
それってJavaとかCOBOLとかの問題じゃなくて、データベースの問題だと思うが。

85 :仕様書無しさん:04/03/06 13:10
>>83
ちょっと信じがたいのですが、そのCOBOL屋は信用できますか。
RDBMSの黎明期ならまだしも、今でもそんなにSQLが遅いとは考えにくい。

86 :仕様書無しさん:04/03/06 13:23
>あー、当然Java屋がCOBOL書けって言われたときにSQLで
>がりがりがんばってもきっと馬鹿にされるだけだぞ。

慣れてない環境でセオリックに組んでいてパフォーマンスでないのは
単に慣れの問題で、ベテランが教えてやればそれで済む問題だと思う。

DELETEで1レコードずつ消すのが早いとか裏技的なテクニックを
当然と思い込んでるのは明らかに勉強不足だから、周囲がその間違いを
教えてやっても、他の箇所でもいろいろ変な書き方をしてそう。



87 :仕様書無しさん:04/03/06 14:52
一行ずつ処理?
どうもCSVかなんかのテキストベースのテーブルを処理してるような感じがするな。

コボルはあまり知らないんだが、要するにDBエンジンに仕事をさせるための言語がSQLで、
DBエンジンにさせたほうが速い仕事もコボラーは自分でやりたがるんだろう。
必然的に総てのデータを処理したがるわけだ。
まあ、それが第三者が見て一番解りやすいやり方なのかも知れないけど。

確かにサブクエリが何層にもなったSQLや、5つも6つもつなげたユニオンクエリを書いて
一発で通る時の充実感は確かにあるけど、第三者のことは考えてないもんな。処理速度はこの方が速いんだろうけど。

だからコボラーにはデータベースは無理なんだって。

88 :仕様書無しさん:04/03/06 15:27
>>87
程度にもよるけど、サブクエリーがネストした程度のSQLなら普通に読んでもらいたい。


89 :仕様書無しさん:04/03/06 16:17
>サブクエリが何層にもなった
俺は一つのSQLにSELECTが13個ある命令を見たことがある。

90 :69式フリーPG ◆hND3Lufios :04/03/06 16:25
COBOLの時代はISAMだったんじゃないの?
よく知らないんだけど。

91 :仕様書無しさん:04/03/06 17:44
select * from (select * from (select * fromselect * from(select * from (select * fromselect * from(select * from (select * from(elect * from(select * from (select * from ta_data))))))))

92 :仕様書無しさん:04/03/06 17:46
( がおかしい。シモタ

93 :剛万太郎 ◆uuJAVAsys2 :04/03/06 17:48
カッコ悪い

94 :仕様書無しさん:04/03/06 18:22
>>91
from の後に select 書けるの?

95 :仕様書無しさん:04/03/06 18:24
>>87
プラットフォーム(広義の意)にあわせた開発をしてくれればいいんだがな。
つこて
>だからコボラーにはデータベースは無理なんだって。
こーゆー言い方しかできないやつは、全く別の環境にいくと使い物にならないやつになりそうだな。

96 :仕様書無しさん:04/03/06 20:32
客先のオサーン達は、CSVファイルという概念がいまだに理解できてません。
こんなオサーンを引っ張って開発せにゃならんと思うと鬱。

97 : ◆SparcUTLAw :04/03/06 20:42
>>96
俺も「CSVファイルの区切り文字は、タブ文字とする。」なんていう
客先SEのメールで目が点になった。
#いや、俺もタブ区切り嫌いじゃないが…それCSVじゃないよ…


98 :仕様書無しさん:04/03/06 22:40
from (select〜)は常識だぞ!
>>94が俺様の究極の13重サブクエネストのSQLを見たら100年かかっても理解できねぇだろうな。

99 :仕様書無しさん:04/03/06 22:52
>>98
そうなん?
select は where 節にしか書けないと思っていたのだが?

100 :仕様書無しさん:04/03/06 22:54
>>98
そんなネストが必要なのは
スキーマの設計の段階で終わっているからだと思うが?

101 :仕様書無しさん:04/03/06 23:15
流れを切って一つ愚痴を。
今回入ったプロジェクトの変数の命名規則が
「ソースファイル名+YYYYMMDD」
なんだが、非常に見にくい罠。
ちなみに言語はc。
発案者は誰なんだーっつーか死んでください

102 :仕様書無しさん:04/03/06 23:26
>>101
1つのソースファイルで、1日1つの変数しか宣言できないの?

103 :69式フリーPG ◆hND3Lufios :04/03/06 23:28
しかもローカル禁止とかw

104 :仕様書無しさん:04/03/06 23:30
>>99
俺も最近知ったけど、FROM句にも書けるんだよねぇ。

105 :仕様書無しさん:04/03/06 23:34
>>104
それどころかselect句にも書ける罠

106 :仕様書無しさん:04/03/06 23:59
失礼
DDMMの後に分と秒があった

107 :仕様書無しさん:04/03/07 00:03
>>106
時はないのか?

108 :仕様書無しさん:04/03/07 00:28
>>101

int hentai20040307000312=0;
int yamete20040307000313=0;
int sukebe20040307000314=0;
char ahan20040307000315[100];

?


109 :仕様書無しさん:04/03/07 00:36
select * from (select * from (select * fromSelect * from(select * from (select * fromSelect * from(select * from (select * from(Elect * from(select * from (select * from ta_data))))))))

大文字にした所をよくみるがよし。
通らないよコレ

110 :仕様書無しさん:04/03/07 00:43
IF〜
IF〜
IF〜
IF〜
・・・
条件多すぎ、おえねぇよ

モウヤメテェヨナ

111 :仕様書無しさん:04/03/07 01:21
SQLくらい勉強してくださいよ…
副問合わせぐらい覚えようよ、MySQLでも使ってない限り

112 :仕様書無しさん:04/03/07 01:41
>>111
ごめん。俺オラクルプラチナもっているけど既に忘れた。
なんかあったね。そういうの。

113 :仕様書無しさん:04/03/07 01:59
>>112
Oracle7のプラチナは9iのシルバーに劣るよな。
まじで。

114 :仕様書無しさん:04/03/07 02:01
ひとつのselect文はその結果自体が一つの表(つーかビュー)になってるわけだから
それをfrom句に書けるのは当然。という考え。

115 :仕様書無しさん:04/03/07 02:35
>>108
hoge.c

int hoge20040307023229=0;
int hoge20040307023243=0;
int hoge20040307023246=0;
char hoge20040307023250[100];

for(int hoge20040307023301=0;hoge20040307023301<100;hoge20040307023301++) {
 …

という感じになるのでは…

116 :仕様書無しさん:04/03/07 09:35
>>101
前の会社にも変な規則あったけど、そんなのは初めて。
世の中には変なことを考える人がいるもんだね。
意図がわからねぇ

117 :仕様書無しさん:04/03/07 10:19
>>105
どう書くのか教えて!

118 :仕様書無しさん:04/03/07 10:37
selectをselectに書く場合
select (select hoge from tbl),hoge2 from hogehoge


119 :仕様書無しさん:04/03/07 10:53
俺が見た究極のSQL
25連結ユニオンクエリ、、、鬼。


120 :仕様書無しさん:04/03/07 11:03
別名つけなされ

121 :仕様書無しさん:04/03/07 11:07
25回もUNIONしなきゃいけない理由ってなんだろう…?

122 :仕様書無しさん:04/03/07 11:17
や、俺が書いたんじゃねーから、読むのもウザかった。
どうもね、売上データに20種類ぐらいの場合分けがしてあって、
しかも、同じテーブルに一定の比率を掛け合わせたものを別々のデータとして扱う必要があったみたい。
それを計上日順にソートしなくちゃならないから、そうなった。

同じ内容の奴もいくつかあったみたいだけど。

123 :仕様書無しさん:04/03/07 11:21
>>118
ほほー、こんなのもアリなのか。
勉強になった。サンクス!

124 :仕様書無しさん:04/03/07 11:26
悲しいとき〜、
超苦労して書いた長いユニオンクエリやサブクエ多重ネストが通らなかったとき〜。
どのSelectが問題おこしてるか解らない〜!

125 :仕様書無しさん:04/03/07 12:17
>>123
いっとくが、select部分に副問い合わせを書くのはSQLに慣れた人から見ると
ここでよく紹介されるコボラー並みにみっともない行為だぞ。

FROM句に書いて結合させればいい話なんだから。

126 :仕様書無しさん:04/03/07 12:19
>>113
9iのプラチナ(当時)だけどね。今はゴールド扱いだっけ?

127 :仕様書無しさん:04/03/07 12:20
コボラーはみっともなくないぞ!

128 :仕様書無しさん:04/03/07 12:38
>>126
こんなヤシがいるから、オラクルマスタが改定されたんだな…

129 :仕様書無しさん:04/03/07 13:01
>>125
心配してくれてありがとん。
知識が増えて喜んでただけだよー。
どう使うか(使えないもの)は、ちゃんと考えるよ。


130 :125:04/03/07 13:50
うっす。
要らぬ心配だったようだな。失礼した。

131 :仕様書無しさん:04/03/07 22:48
for (i=0; i<3; i++) {
  switch (i) {
    case 1:
      …
      break;

    case 2:
      …
      break;

    case 3:
      …
      break;

    default:
      break;
  }
}


  ふ  ざ  け  る  な

132 :仕様書無しさん:04/03/07 22:58
forとswitch使いたかっただけと違うんか

133 :仕様書無しさん:04/03/07 23:24
>>131
おれ、一連のシーケンスを実行するときは、そういうループ書くけどな。
大抵、switchの前と後ろに、なんかやりたいことがあるんだけど。
ふざけてるんじゃないよ。

134 :仕様書無しさん:04/03/07 23:27
プログレスバー進めたいとか
処理をいくつかのステップに明確にわけたい事情があったのかも。
あるいは、その名残のようなものなのかも。

まあ、違うんだろうけど

135 :仕様書無しさん:04/03/07 23:31
各ステップの処理を関数にでもして、
各関数を順に呼ぶだけの方が解り易いのに…。

136 :仕様書無しさん:04/03/08 00:07
時と状況によっては、>>131のコードは問題ないと思うんだが。
要は、中にどんな処理を書くかでしょ

137 :仕様書無しさん:04/03/08 00:14
>>131が怒ってるのは、default: についてだと思うよ

138 :仕様書無しさん:04/03/08 00:15
まあ最初の1ループはまるっと無駄だよね

139 :仕様書無しさん:04/03/08 00:20
中でiの値書き換えてるんだよ
...それはそれでブチ切れる鴨

140 :仕様書無しさん:04/03/08 00:24
>138
「case 3:」も無駄だよね

141 :仕様書無しさん:04/03/08 00:26
>>137
>>140
お前等>>131を馬鹿にしすぎです。w

142 :仕様書無しさん:04/03/08 01:50
iの値を書き換えていくわけか
i++があるから1少なく書くわけだな
なんかオラワクワクしてきた

143 :仕様書無しさん:04/03/08 12:39
俺よりベテランで、今までVBやってきたという人とC#の仕事をしてる。
「Cになれて無いから」と頻繁に言い訳するけど、仕事が遅いのはそれ以前の
問題というか。
(C#とCは違うと、それとなくツッコミを入れてもCと言い続けてるし)

F1でヘルプが出る事を知らなかったし、デバッグのやり方も、ソースを変更
して実行を繰り返すやりかたで、ブレークポイントを仕掛けてステップ実行
とか全然やらないの。
横からチラチラと覗いていても原因が分かるレベルのバグだったので、
それとなく「ここにブレイクポイントを入れて、ステップ実行したら。。。」
という感じでアドバイスしたけど、その後もステップイン、ステップオーバー、
とかを使い分けたりしないで、ひたすらステップインをクリックするだけ。
余計なメソッドやループに入ってしまったら、ステップインのアイコンを
連打して脱出で効率悪すぎ。

このあたりの統合環境の使い方はVBでも同じはずなんだけど、この人はVBで
いままで何をやってきたのか謎。

ヘルプの使い方とかデバッグのやり方とか、それとなく本人の前でやって
みせるのだけど、ぜんぜん盗んでくれないし。

144 :仕様書無しさん:04/03/08 22:30
>>142
>なんかオラワクワクしてきた
ワラタ

145 :仕様書無しさん:04/03/08 23:00
>>143
俺より10年ベテランの人はJP1スクリプトのことをJAVAスクリプトと呼ぶ
・・・JP1スクリプトって何者?


146 :仕様書無しさん:04/03/08 23:18
>143
当方リアルVB厨(2年目)ですが、
それはソイツが糞なだけですよ。
デバッグくらい自分レベルでも当然やってますし。
因みに副問い合わせのSQL書けない方、自分以下ですのでそこんとこよろしこ

147 :仕様書無しさん:04/03/08 23:32
>>146
副問い合わせ?
SQLでのすべての問い合わせは「こうやって取り出したい」と思ったの
かければいいんだよ。楽しみながら実験していけば、
本読んで勉強するより短時間に覚えられるよ

148 :仕様書無しさん:04/03/08 23:32
>>143
あんたいい人だ。・゚・(ノд`)・゚・。
がんがれ。

149 :仕様書無しさん:04/03/08 23:43
>>143
多分VSの一枚目しか持ってなかったんだよ。

150 :仕様書無しさん:04/03/09 00:17
>146
 んじゃあ、「副問い合わせを使わずに、副問い合わせ使って欲しいデータを、SQL 一発で取る」
のはレベル上なのか下なのか?(w

 MySQL は副問い合わせ使えないから、join で書き直す癖が付いたなあ……癖抜くのに少し
手間取った(w

151 :仕様書無しさん:04/03/09 00:21
>>150
書かないのと書けないのは違うだろ。

152 :仕様書無しさん:04/03/09 01:14
遅レスだが。。。
>>131
俺も似たようなコード見たことある。
もっとヒドイ

for(i=0; i<2; i++){
if( i==0)
f000();
if( i==1 )
f001()
if( i==2 )
f002()

f(); // なにやら共通っぽい処理

if( i==0)
f010();
if( i==1 )
f011()
if( i==2 )
f0012()


}

みたいな。
頭の硬い年よりはイラネ

ま、辞めたけど

153 :仕様書無しさん:04/03/09 09:33
131も152もどちらにもありえない判定文があるのは
こういう書き方をするプログラマにとっては必然なのだろうか。

154 :仕様書無しさん:04/03/09 09:47
>>153
直接関係あるかどうか知らんが、
そういう香具師の多くがデバッグ用printfに副作用のある式を入れたりする。
で、「普通に動くんですけど、デバッグオプション付けると動かないんですぅ」
とか言い出す。

155 :仕様書無しさん:04/03/09 10:58
>>154
「デバッグオプション付けると普通に動くんですけど、取ると動かないんですぅ」
っていうパタンもあるし

156 :仕様書無しさん:04/03/09 12:41
>>155
デバッグビルドのまま納入しますけど、何か?

157 :仕様書無しさん:04/03/10 00:30
>>153
ヒント:iはグローバル変数

158 :仕様書無しさん:04/03/10 00:34
グ・グム〜

159 :仕様書無しさん:04/03/10 01:40
sedで

s/ "/"/
s/  "/"/
s/   "/"/
s/    "/"/
s/     "/"/
(中略)
s/                          "/"/

CSV末尾の余分なスペースを取りたかったらしい。
性器、もとい

160 :159:04/03/10 01:42
正規表現使えよ、とオモタ。

#途中で送信してしまった。。

161 :仕様書無しさん:04/03/10 17:54
>>76
#defineMAXDAY(y,m)(((m)==4||(m)==6||(m)==9||(m)==11)?30:((m)==2?(((!((y)%4)&&((y)%100))||(!((y)%4)&&!((y)%400)))?29:28):31))
どうだ?

162 :仕様書無しさん:04/03/10 18:51
>>161
正しいか否かを確認する気にもなれないぞ
「一行で書ける」は「一行で書くべきだ」とは違う
たとえ十行を超えたとしても、もっと読みやすい書き方で書いてある方を評価する


163 :仕様書無しさん:04/03/10 19:50
>>162
まあ、「1行で書ける」と言われたから1行で書いたのだろう。
これを読みやすいからという理由で、複数行で書いたのでは、
>>76への答えにはならんだろう。

しかしな、>>161よ、お前は>>76をもう一度読み直せ。
これがテストなら、お前の答案は0点

164 :仕様書無しさん:04/03/10 19:55
>>161
#defineMAXDAY(y,m)(((m)==4||(m)==6||(m)==9||(m)==11)?30:((m)==2?( ((y)%4)||(((y)%100)==0)&&((y)%400)?28:29):31)
どうだ?


165 :仕様書無しさん:04/03/10 20:31
>>76は「閏年かどうか」と言っているので
これでいい
((year % 4) == 0) && ((year % 100) != 0 || (year % 400) == 0)

166 :仕様書無しさん:04/03/10 20:39
>>164
#define MAXDAYS(y,m) (((m)==4||(m)==6||(m)==9||(m)==11)?30:((m)==2?(((y)%4)||!((y)%100)&&((y)%400)?28:29):31))
ちょっと修正させてもらった

167 :仕様書無しさん:04/03/10 21:05
日数算出で、
現在日付から年と月1つずつずらしながら
延々ループ回して求める関数。
10年やってんならユリウス日ぐらい知ってろ!

168 :仕様書無しさん:04/03/10 21:13
・・・ライブラリ使わないのか?

169 :仕様書無しさん:04/03/10 21:16
きっとライブラリ作る人なんだよ

170 :仕様書無しさん:04/03/10 21:33
(mktime(&to_tm) - mktime(&from_tm)) / 86400;
じゃダメか?


171 :仕様書無しさん:04/03/11 01:42
ユリウスとグレゴリオの違いがわからない

172 :仕様書無しさん:04/03/11 01:49
文字数が違う

173 :仕様書無しさん:04/03/11 01:53
グレゴリアはショタ。ユリウスは年増キラー。

174 :仕様書無しさん:04/03/11 14:22
>>170
from_tm をどうやって求めるかも書かないと片手落ちだぞ

175 :仕様書無しさん:04/03/11 15:23
最近は片手落ちも差別語らしいね
まあ2ちゃんねらーには関係ないか

176 :仕様書無しさん:04/03/11 15:53
片輪より片手落ちのほうがかなり直接的な表現だけど、
なぜかカタワのほうが差別度は高いな。
どうでもいいけど。

177 :仕様書無しさん:04/03/11 16:15
そのうち「手抜き」も差別用語になるかな。

178 :仕様書無しさん:04/03/11 20:48
めくらタイピング

179 :仕様書無しさん:04/03/11 21:09
>>167
ユリウス暦は常識 (とは言え使われていない) が、
ユリウス日を知っている人はそう居ないのでは?

180 :仕様書無しさん:04/03/11 22:06
そのうち「口抜き」も差別(ry

181 :仕様書無しさん:04/03/11 22:17
そのうちけんけんも差別遊戯と(ry

……そろそろ流れ戻そうよ。

182 :仕様書無しさん:04/03/11 22:45
>>178
いいなそれ。あえて広めようぜ。俺は面倒だからやんないけど。

183 :仕様書無しさん:04/03/12 04:46
おさわりタイピング

184 :仕様書無しさん:04/03/13 00:09
接触打鍵

185 :仕様書無しさん:04/03/13 08:34
我流一本指打法

186 :仕様書無しさん:04/03/13 11:35
コロンブスメソッドって知ってる?

187 :仕様書無しさん:04/03/13 16:43
十字キーで全て解決!

188 :仕様書無しさん:04/03/13 16:58
interruput_fuck( )
{

}

189 :仕様書無しさん:04/03/14 01:08
>>188
ワラタ

190 :仕様書無しさん:04/03/14 17:30
>>164 >>166
最短
inline MaxDays(int y,int m){return m==4||m==6||m==9||m==11?30:m==2?y%4||!(y%100)&&y%400?28:29:31;}


191 :仕様書無しさん:04/03/14 21:39
>>179
天文オタなら常識

192 :仕様書無しさん:04/03/14 22:42
inline MaxDays(int y,int m) { int max_days[] = {略}; return max_days[y*12+m-1]; }

193 :仕様書無しさん:04/03/15 01:06
>>192
y は西暦で与えるんでしょうか?
 そんな膨大な配列をインライン展開されたら目が眩みそうでし。


194 :仕様書無しさん:04/03/15 01:27
static constな配列にしとけば全然大丈夫。きっと。
つか、引数が定数なら計算結果の値だけになるかも。こっちの可能性は低いけどな。わら。

195 :仕様書無しさん:04/03/15 02:23
>>194
まさか>>193
int max_days[] = {略};
にstatic constを付けるとか言うつもりじゃあるまいな?

196 :仕様書無しさん:04/03/15 03:13
>>190
inline MaxDays(int y,int m){return m-4&&m-6&&m-9&&m-11?m-2?31:y%4||!(y%100)&&y%400?28:29:30;}

197 :仕様書無しさん:04/03/15 03:48
おまいらのコードじゃあ全部会社辞めたくなるな。
エラーチェックくらいしる!


198 :194:04/03/15 04:48
>>195
ダメなの?
# ダメだと主張するコンパイラがあることは知ってるけど。

199 :194:04/03/15 04:50
>>197
細かいinline関数にはエラーチェックを入れるなよ?
あいだをとって、assert()にしとけ。

200 :仕様書無しさん:04/03/15 07:12
>>191
それは普通常識とは言わん。

201 :仕様書無しさん:04/03/15 10:00
>200
すべての人間にとっての常識なんてあるか?
範囲は必要だろう。

202 :仕様書無しさん:04/03/15 12:11
200にとって、「日本人なら常識」な事は常識とは言わないらしいね

203 :190:04/03/15 13:00
>>196
マイリマシタ > orz

204 :仕様書無しさん:04/03/15 14:55
>>196
int MaxDays(int y,int m){return m-2?31-(1&2644>>m):29-(y%4||y>1582&&!(y%100)&&y%400);} // 1<=y<=INT_MAX, 1<=m<=12
グレゴリオ対応。


205 :仕様書無しさん:04/03/15 19:13
そのうち >>196>>204 が各社のソースにコピペで氾濫する事でしょう。
その時は、是非以下のコメントを入れておいてください。

// この会社辞めようと思ったソースコード#D

206 :仕様書無しさん:04/03/15 22:34
さすがに>>204は却下されそう。
>>196>>190をもうちょっと分かり易いように
書きかえて使うかも。

207 :仕様書無しさん:04/03/15 23:16
m-2?31-(m+(m<8))%2:(以下略)
というのを考えたが、>>204と字数変わらんかった。

208 :仕様書無しさん:04/03/16 01:22
>>205
実際にコピペする機会がありそうだから怖いな

209 :204:04/03/16 13:29
>204 はコピペ禁止な。
代わりにだいたい等価な関数を貼っておく。

#define SMALL_MONTH_BITS 1322 // 010100101010b
#define SMALL_MONTH_BITS_1 (SMALL_MONTH_BITS << 1)
#define GREGORIAN_YEAR 1582
//#define GREGORIAN_YEAR 1699
// return value={28-31}, 1<=year<=INT_MAX, 1<=month<=12
int MaxDays(int year, int month)
{
int days;

assert(1 <= year && 1 <= month && month <= 12);
if (month != 2) {
if (SMALL_MONTH_BITS_1 >> month != 0) {
days = 30;
} else {
days = 31;
}
} else {
if ((year % 4 != 0) ||
(year > GREGORIAN_YEAR) && (year % 100 == 0) && (year % 400 != 0)) {
days = 28;
} else {
days = 29;
}
}
return days;
} // MaxDays() End

あと、グレゴリオ対応は意味が変なので、紀元後〜1582あたりに対応と訂正で。


210 :仕様書無しさん:04/03/16 16:50
>>209
グレゴリオ対応とか要らん。
それと、等価な関数……を自分で書けないような奴が、このスレに
来るとも思えん。


211 :204:04/03/16 22:13
上司が >>210 の会社は今月で辞めようと思った。
#define MaxDays(y,m) 31


212 :仕様書無しさん:04/03/16 22:17
>>211
日本語もうちょっと勉強しろ

213 :仕様書無しさん:04/03/16 22:26
>>212
すみませんでした。許してください。

214 :仕様書無しさん:04/03/16 22:36
やだ

215 :仕様書無しさん:04/03/16 23:43
>>214
そんなこといわないで、ゆるして〜

216 :仕様書無しさん:04/03/17 00:54
会社を辞めようと思った。上司が>>210。今月。

217 :仕様書無しさん:04/03/17 09:05
if(上司 == 210){
switch(month){
case 今月: 会社を辞めようとおもった。 break;
default:   温もりに包まれる。 break;
}
}

218 :仕様書無しさん:04/03/19 03:24
うるう年に対応は当然だが、うるう秒に対応してるのは見たことが無い

219 :仕様書無しさん:04/03/19 11:05
必然性がない。


220 :仕様書無しさん:04/03/19 11:20
>>219
んー、そうでもないよ。

221 :仕様書無しさん:04/03/19 11:28
そもそもうるう秒は予測可能なのか?
それとも過去のうるう秒の話?

222 :仕様書無しさん:04/03/19 11:31
ここが噂のdate timeについて語るスレですか?

223 :ヽ(´ー`)ノ ◆.ogCuANUcE :04/03/19 11:33
http://jjy.crl.go.jp/Pub/leapsec.html
規則性は無さそうだな。

仮に規則性があったとしても、一秒単位で時刻の調整をするくらいなら
NTP で同期取った方がいいんだろう。

224 :仕様書無しさん:04/03/19 11:34
>>223
ファームとかではちゃんとやるぜ

225 :仕様書無しさん:04/03/19 11:47
>>218
NTP

226 :仕様書無しさん:04/03/19 12:26
閏秒があると、秒が 58 → 59 → 60 → 00 → 01 と一回だけ 60 になる。
OSによって対応度合いが違うだろうけど、アプリ側で対応してないと
拙い事もあるだろう。

まあ、12/31 から 1/1 の間にリアルタイムでデータ収集してるとか
そーゆーシステムでもない限り関係ないわけだが。

227 :仕様書無しさん:04/03/19 12:27
>>226
秒数のカウントとか、影響は色々あるでしょ。

228 :仕様書無しさん:04/03/19 12:38
>226

そんなもん、解析時に考慮すればいいだけだろ。

229 :仕様書無しさん:04/03/19 12:41
char* mage()
{
  char ret[MAX_RET];
処理

  return ret;
}


230 :仕様書無しさん:04/03/19 12:44
おめーら皆素人だろ。
閏秒ごときを考慮しなきゃなんないシステムなんかない。
年間どころか週間一秒の誤差を考慮する必要あるシステム上げてみぃ!


231 :仕様書無しさん:04/03/19 13:03
>>230
リアルタイムに絡むシステムなら、結構関係するのがあると思うが。
イベント間の時間間隔がクリティカルになる計測系とか。

232 :仕様書無しさん:04/03/19 13:15
>>231
そうだとしてもどのように対応するの?
閏秒ってある程度溜まった時点でやるよーっていってやるじゃない。
それを管理してる側かそこからリアルタイムに時刻をもらってない限りは、通常の時刻調整と同じだろ。

233 :仕様書無しさん:04/03/19 13:34
>>232
>イベント間の時間間隔がクリティカルになる計測系とか。

イベント間の時間間隔は相対的なものだ。
うるう秒は絶対的なもの。

ここでは絶対的な時間が(時計やカレンダーみたいに)
クリティカルな意味を持たなければいけない。


234 :仕様書無しさん:04/03/19 13:45
>>233
各イベントがタイムスタンプ持ってたら?

235 :仕様書無しさん:04/03/19 13:59
>>234
その出力時刻がシステム内で定義された時刻か、外界の時刻かによるでしょ?

時間間隔でクリティカルなシステムなら、外界の時間を当てにしない。
外界の時間が大事なら、それに従う。

外界の絶対時間が重要なシステムって、基準時を管理してる組織だけじゃないのか?w


236 :仕様書無しさん:04/03/19 14:03
>>235
> 外界の時間が大事なら、それに従う。

で、外界の時間が閏秒を入れていたらどうする?

237 :仕様書無しさん:04/03/19 14:08
秒単位の絶対時刻で記録するような計測システムはまずいことになりそうだが。

238 :仕様書無しさん:04/03/19 14:12
>>236
外界の時間を何で取得するかによるでしょ?
普通にシステムコールしてるならば、それがフォローしてるし、OSがカバーしてる。

それ以外でどっかと通信して時刻を取ってる場合、予めその仕様に明記されているはず。
秒は0から60ですよって。

239 :仕様書無しさん:04/03/19 14:13

↓のスレで馬鹿がオナニーしてます
http://sports5.2ch.net/test/read.cgi/base/1076476572/l50


てめえの趣味はてめえでホームページでも作ってやれ。
ここは公共の掲示板だ。オナニーする場所じゃねえ。


↑このコピペを書きむだけでいいです。協力おねがいします。

240 :仕様書無しさん:04/03/19 14:17
>>238
> 秒は0から60ですよって。

で、いつ60があるのかわからなければ秒数が計算できないでしょ?

241 :仕様書無しさん:04/03/19 14:19
>238 本気でそれで問題ないと思っている同僚がいたら会社辞めたくなりそうだ

242 :仕様書無しさん:04/03/19 14:22
>>240
仕様でそのように書かれていれば、外部から時間を取り込む際に変換するだけ。

>>241
逆に通常業務で閏秒とか考えてる奴がいたら嫌だけどね。

大体さ、閏秒を考慮しなくちゃいけない場面って今までに存在したか?
普通にOS上で動くアプリであれば、そもそもそんな時刻存在しないし。

243 :仕様書無しさん:04/03/19 14:43
>>242
> 仕様でそのように書かれていれば、外部から時間を取り込む際に変換するだけ。

じゃ、その変換プログラム、擬似コードでもいいから書いてみてよ。
1つ目のイベントがYYYY年MM月DD日23時59秒で、
2つ目のイベントがYYYY年MM月dd日0時0秒だったとして、
1つ目のイベントから2つ目のイベントまでの秒数がいくつか、
閏秒がいつ入るかわからなくてもちゃんと計算できるやつ。
もちろん閏秒が入っている時には2秒と答えるように。


244 :仕様書無しさん:04/03/19 14:45
>242 マジ、こいつが同僚だったら転職考えるな。
自分の狭い世界だけで「ありえない」とか判断する奴、最低。

245 :仕様書無しさん:04/03/19 14:55
何必死になってんの?

246 :仕様書無しさん:04/03/19 15:01
>>243
つうかさ、相対時間が必要ならば、外部から時間は取らないよな。
仕様レベルであなたの前提がおかしい。
もし、過去に遡ってそういうのが必要ならば、閏秒があった年月日を予め与えて
そのイベント間にその時刻があったかを考慮すればいいだけ。
与えるのは人がやるしかない、それは当たり前。

>>244
ありえないとはいってないだろ、存在したかと聞いただけ。
絶対的な時刻差が必要ならば、外部から時刻を取らずに自分で時刻基準を持つだろ普通。


247 :仕様書無しさん:04/03/19 15:09
>>234
イベント間の時間の距離が問題となる状況で
その記録方法にタイムスタンプを採用しているのは
根本的な設計ミスだと思う。

ま、確かにそんな糞設計をしていれば 2038年問題なんて
心配する必要は無かったろうな。それぐらいしか利点は無いが。


248 :仕様書無しさん:04/03/19 15:09
>246
> つうかさ、相対時間が必要ならば、外部から時間は取らないよな。
> 仕様レベルであなたの前提がおかしい。

アッパレな先入観だな。
発行元がタイムスタンプを作成するシステムなんていくらでもある。
タイムスタンプ間の秒数が必要になるシステムだっていくらでもある。
たまたまあんたがそういうのに関わらなかっただけ。

よかったね、その「たまたま」が起きて。

249 :仕様書無しさん:04/03/19 15:10
>>247
> イベント間の時間の距離が問題となる状況で
> その記録方法にタイムスタンプを採用しているのは
> 根本的な設計ミスだと思う。

世の中、システム全体を設計できる案件ばかりではあるまいに・・・

250 :仕様書無しさん:04/03/19 15:13
>>248
逆にさ、発行元が閏秒のままそんなデータを垂れ流すほうが糞仕様だと思うけど。
屁理屈だよ。あんたの意見。


251 :仕様書無しさん:04/03/19 15:14
>>249
日本標準時を管理してる組織以外で、閏秒のままを外に出す必要のある設計ってあるのか?


252 :ぷろじぇくとりぃだぁ:04/03/19 15:18
おえらこんなとこでウダウダやってないでとっとと仕事シルヽ(`Д´)ノゴルァ

253 :仕様書無しさん:04/03/19 15:19
時間に秒単位の精度が重要なシステムで閏秒が問題になるのは、設計が悪い。時間と時刻は違う。
秒単位の時刻が重要なシステムなら、閏秒以前にどうやって時刻を構成するのか教えてくれ。
本音は、スレ違いだからいい加減にして欲しい。

254 :仕様書無しさん:04/03/19 15:21
>>250
> 逆にさ、発行元が閏秒のままそんなデータを垂れ流すほうが糞仕様だと思うけど。

そういう糞システムは全部あんたが無償で再設計してくれるみたいな言い方だな(藁

強弁するのはいいが、自分の視野の狭さを恥じる心も持ったほうがいい。
世の中、JSTと同期している機器だって一杯あるし、
そこからの絶対時間を信用する必要があるシステムだってある。

ま、どうでもいいスレ違いになっちまったから、俺はこの話題から降りるけど。

255 :仕様書無しさん:04/03/19 15:21
>>253
ハードとして、電子だっけか?の振動を数える機械を内蔵して・・・。w


256 :仕様書無しさん:04/03/19 15:29
>>253
スレ違いなのは禿道。だから
> 時間に秒単位の精度が重要なシステムで閏秒が問題になるのは、設計が悪い。時間と時刻は違う。
> 秒単位の時刻が重要なシステムなら、閏秒以前にどうやって時刻を構成するのか教えてくれ。
こういうマヌケな燃料は遠慮してくれないか?


257 :仕様書無しさん:04/03/19 15:31
>>253
>本音は、スレ違いだからいい加減にして欲しい。

いや、"糞仕様" という点でこのスレの意図にしっかり沿った
内容だと思う。


258 :仕様書無しさん:04/03/19 15:34
だから、そこまで時間の差が重要なシステムならば、設計段階で考慮するって。
そうではない日常使うアプリに出力する時間差にまでそんなことを気にする奴がいたら、そいつが馬鹿なだけ。

259 :仕様書無しさん:04/03/19 15:34
>>254
>世の中、JSTと同期している機器だって一杯あるし、
>そこからの絶対時間を信用する必要があるシステムだってある。

一点、突っ込みを入れさせてもらう。
それは「秒単位」で、か?

260 :254じゃないが:04/03/19 15:40
>>259
> それは「秒単位」で、か?

漏れはmsec単位のタイムスタンプ付きの情報が0.01-10/secぐらいで送られてくる
システムに関わったことがあるよ。実際に使うのはsecまでだったけど、なんか規則
でmsecまで記録するんだと。

261 :仕様書無しさん:04/03/19 15:44
>>260
だから、それはその相手装置内のタイムスタンプでしょ?
そんなの幾らでもあるよ。

そうじゃなくてJTSから取る時刻を秒単位で行ってるかじゃないのか?
通信による遅延があるから意味ないじゃないっていいたいんでしょ?>>259は。

262 :仕様書無しさん:04/03/19 15:50
>254
貴方がそういうシステムを知ってる物知りさんだってのはわかったけど・・・

それで、それらのシステムは閏秒に対応してたの?

263 :仕様書無しさん:04/03/19 16:12
わざわざ恥を晒しにきた260がいるスレはここですか?

264 :254じゃないが:04/03/19 16:47
>>261
> そうじゃなくてJTSから取る時刻を秒単位で行ってるかじゃないのか?

JTSってJSTのことか?
だとしたらたしかmsec単位で同期取ってたと思うが、ちょっと曖昧。
少なくとも秒単位では取れてた。

> 通信による遅延があるから意味ないじゃないっていいたいんでしょ?>>259は。

遅延があるから相手装置のタイムスタンプを信用せざるを得ないわけだけどね。
って、まさかJSTからの遅延を言いたいんじゃないだろうな?



265 :仕様書無しさん:04/03/19 16:52
JST、というか日本標準時と厳密に同期をとっているシステムだったら、閏秒は重要だな。
時刻→時間差の変換には気を使う必要がある。
そんなの滅多にないと思うし、想像もつかないけど、きっと世の中にはあるんだろう。

それ以外の場合は不要。

266 :仕様書無しさん:04/03/19 16:54
> そうじゃなくてJTSから取る時刻を秒単位で行ってるかじゃないのか?
> 通信による遅延があるから意味ないじゃないっていいたいんでしょ?>>259は。

いいかげん自分の見苦しさに気付け


267 :仕様書無しさん:04/03/19 16:56
>>265
秒単位が「厳密に同期」かよ…マジで自分の常識の狭さに気付いてないのかね…

268 :仕様書無しさん:04/03/19 16:57
>>254
こういうやつがいたら、会社辞めたく(辞めさせたく)なるな。

269 :265:04/03/19 16:58
>>267

日本語読めてる?

270 :仕様書無しさん:04/03/19 16:59
>267 気付いてないみたいよ、>268たんは(苦笑

271 :仕様書無しさん:04/03/19 17:01
>268 そう思うのなら、君は他の業種に転職したほうがいいと思うよ

272 :仕様書無しさん:04/03/19 17:03
>>266 - >>277
揚げ足ばかりじゃなくて、きちんとした反論しろよ。
自分は高見から見てるつもりかもしれないけど、全然話になってないよ。

273 :仕様書無しさん:04/03/19 17:04
>>266
たかが2chで時間潰してる新米SE君相手にムキになっても無駄だといいかげん気付け


274 :仕様書無しさん:04/03/19 17:08
>>272
これも揚げ足かな(藁

275 :仕様書無しさん:04/03/19 17:09
>>272
これも揚げ足なんだろうな(藁
次のレスも、そのまた次のレスも揚げ足なんだろうな

276 :仕様書無しさん:04/03/19 17:14
>>275
いいかげんにしとけ。電波取りが電波だぞ。

277 :仕様書無しさん:04/03/19 17:22
で、具体的な反論はできないと。
それに閏秒を実際にリアルタイムで処理してるとかの具体例も挙がらないと。

後から時間差を出すのに閏秒の考慮が必要ならば、その発生日時を渡すのはシステム的にありえる。
そんなのは当然だ。


278 :仕様書無しさん:04/03/19 17:34
>>277
> 後から時間差を出すのに閏秒の考慮が必要ならば、その発生日時を渡すのはシステム的にありえる。

それじゃ因果関係が狂いまくりだろ。そうじゃなくて正しくは
「発生日時から後から時間差を出すのなら閏秒の考慮をすることは
システム的にありえる。」だろ。
渡されるのが発生日時ではなくエポックタイムからの相対時間ならば
時間差を計算するのに閏秒など関係ない。


279 :仕様書無しさん:04/03/19 17:34
勉強になりそうなので閏秒を処理する必要のあるシステムの事例が知りたい。
俺の頭では考え付かないんだ。
このスレには期待してるんだけど。

280 :仕様書無しさん:04/03/19 17:37
>>277
> で、具体的な反論はできないと。
> それに閏秒を実際にリアルタイムで処理してるとかの具体例も挙がらないと。

いつのまに>>260は無かったことになったんだろうか...
自分に都合が悪い事を無視するってのは技術屋として最低だね。
まあ>>277が何を理解して何を理解してなくても俺には実害ないから
どうでもいいが。アフォらし。

281 :仕様書無しさん:04/03/19 17:39
>>279
http://www.google.com/search?q=%E9%96%8F%E7%A7%92&sourceid=mozilla-search&start=0&start=0&ie=utf-8&oe=utf-8

よかったね、たくさんあって。

282 :仕様書無しさん:04/03/19 17:43
>281
"必要なシステム"の事例ではないような。

で、260は閏秒に対応してるシステムだったの?
つか、タイムスタンプを記録するだけの場合、閏秒ってどうやって保持するんかな。

283 :仕様書無しさん:04/03/19 17:58
>>282
> "必要なシステム"の事例ではないような。

必要だから対応してるんじゃねーの?
それとも、どれも酔狂か何かで対応してるとでも?

284 :仕様書無しさん:04/03/19 17:59
結論:
不毛な議論をしてるなぁ
いい加減飽きないか?

285 :仕様書無しさん:04/03/19 18:16
『糞システム』が『翼システム』に見えた。(鬱

286 :仕様書無しさん:04/03/19 18:28
>>280-281

アホかと。

閏秒という概念があるかどうかだけなら、Cのtmにだってある。61秒まで(だったかな)。
システムとして対応する必要があるかどうか、重要かどうかとは別。

287 :仕様書無しさん:04/03/19 18:41
>>286
なんだコイツ。。。
ただ受け付けるかどうかと閏秒処理するのと同じだとでも思ってるのかよ
マジで馬鹿だな。。。

288 :仕様書無しさん:04/03/19 18:42
閏秒という概念があるかどうかだけなら、Cのtmにだってある。61秒まで(だったかな)。
閏秒という概念があるかどうかだけなら、Cのtmにだってある。61秒まで(だったかな)。
閏秒という概念があるかどうかだけなら、Cのtmにだってある。61秒まで(だったかな)。
閏秒という概念があるかどうかだけなら、Cのtmにだってある。61秒まで(だったかな)。
閏秒という概念があるかどうかだけなら、Cのtmにだってある。61秒まで(だったかな)。
閏秒という概念があるかどうかだけなら、Cのtmにだってある。61秒まで(だったかな)。
閏秒という概念があるかどうかだけなら、Cのtmにだってある。61秒まで(だったかな)。
閏秒という概念があるかどうかだけなら、Cのtmにだってある。61秒まで(だったかな)。
閏秒という概念があるかどうかだけなら、Cのtmにだってある。61秒まで(だったかな)。
閏秒という概念があるかどうかだけなら、Cのtmにだってある。61秒まで(だったかな)。


289 :仕様書無しさん:04/03/19 19:28
話がそれてきました。

290 :仕様書無しさん:04/03/19 19:37
    スレ違いの話題
--------------------------↑ ここまで

--------------------------↓ ここから
「この会社辞めようと思ったソースコード#D」

291 :仕様書無しさん:04/03/19 20:01
#define SORT_DIRECTION_A 0
#define SORT_DIRECTION_D 1
↑のように書いていたら、いつの間にやら、

//#define SORT_DIRECTION_A 0 // アップをローマ字で書くな
#define SORT_DIRECTION_U 0

と修正されていた……。

292 :仕様書無しさん:04/03/19 20:24
>>291
で、再修正しておいたのか?


293 :仕様書無しさん:04/03/19 20:26
スペルを省略しないように再修正をかけておけ。

294 :仕様書無しさん:04/03/19 20:37
//#define SORT_DIRECTION_A 0 // アップをローマ字で書くな
//#define SORT_DIRECTION_U 0 // アップじゃねえよ禿
#define SORT_DIRECTION_AFTER 0

295 :仕様書無しさん:04/03/19 20:51
//#define SORT_DIRECTION_A 0 // アップをローマ字で書くな
//#define SORT_DIRECTION_U 0 // アップじゃねえよ禿
//#define SORT_DIRECTION_AFTER 0 //なげーよ、ばか。
#define SDA 0


296 :仕様書無しさん:04/03/19 20:54
//#define SORT_DIRECTION_A 0 // アップをローマ字で書くな
//#define SORT_DIRECTION_U 0 // アップじゃねえよ禿
//#define SORT_DIRECTION_AFTER 0 //なげーよ、ばか。
//#define SDA 0 // 何故か AFTER がスルーされている・・・
#define SORT_DIRECTION_A 0


297 :仕様書無しさん:04/03/19 21:07
//#define SORT_DIRECTION_A 0 // アップをローマ字で書くな
//#define SORT_DIRECTION_U 0 // アップじゃねえよ禿
//#define SORT_DIRECTION_AFTER 0 //なげーよ、ばか。
//#define SDA 0 // 何故か AFTER がスルーされている・・・
//#define SORT_DIRECTION_A 0 // だから省略するなよ
#define SORT_DIRECTION_AGE 0

298 :仕様書無しさん:04/03/19 21:14
Dは何の略?

299 :仕様書無しさん:04/03/19 21:37
デスマ

300 :仕様書無しさん:04/03/19 21:39
INITIAL-D(デスマ)

301 :仕様書無しさん:04/03/19 21:40
ダメポ

302 :仕様書無しさん:04/03/19 21:49
突然蒸し返す事の
ドケチな秒単位課金プロバイダとか閏病考慮要るかもとか

303 :仕様書無しさん:04/03/19 22:03
Sort順って、ふつうAscending/Descendingを使うような…

304 :303:04/03/19 22:18
ああ、だから>>291はホントは正しいって話ね。ハイハイ。

305 :仕様書無しさん:04/03/19 22:56
こんだけの説明でわかるのか。
すげーなおい。


306 :仕様書無しさん:04/03/19 23:00
>>291
でもさ、SORT_DERECTIONまで略してないなら、最後まで略すなよと言いたくなる。


307 :仕様書無しさん:04/03/19 23:02
みんな!
そんなことをいちいち気にしていたらコードなんて1行も書けないぜ!

308 :仕様書無しさん:04/03/19 23:05
>>307
変数名・定数名は一番悩む部分だぞ。


309 :仕様書無しさん:04/03/19 23:30
>>308
俺は悩まない。
自分のルールを持ってるから。
もちろん、規約があれば準拠するが。

310 :仕様書無しさん:04/03/19 23:45
むしろ略すならDIRECTIONの部分の方を略した方がいいかと思う。
DIRECTIONがなくてもASCENDINGとかDESCENDINGとか付いていれば十分だし。

311 :仕様書無しさん:04/03/19 23:48
ASCENDING_SORT/DESCENDING_SORTでいいと思われ

312 :仕様書無しさん:04/03/19 23:58
つーか、命名規則とかある場合がほとんどだと思うんだけど
そんなことないんすか?
仕事するときは、大体ルールがあるけどなー

まぁ、それでも、英語で悩むわけでorz

313 :仕様書無しさん:04/03/20 00:09
>>312
うちみたいな零細企業にはコーディング規約も命名規則もありません
前いた会社にはあったけど

314 :仕様書無しさん:04/03/20 00:28
ASC/DESCでいい

315 :69式フリーPG ◆hND3Lufios :04/03/20 00:30
>>314
SQLっぽくてそれがいいね。

316 :仕様書無しさん:04/03/20 00:49
>>191
天文オタはそう居ない。

317 :仕様書無しさん:04/03/20 00:51
>>316
超亀レスイイね

318 :仕様書無しさん:04/03/20 01:46
よーし、パパも亀レスしちゃうぞー

>>33
クラスだから、詳細設計より概要設計の方が重要なのであ?

319 :仕様書無しさん:04/03/20 02:52
給湯室で電気ポットでお湯沸かそうと思ったらよ、
コンセントに挿すほうんところにとんかつソースがべっちょりついてたんだよ。


320 :仕様書無しさん:04/03/20 03:26
>>308
ハンガリアン【我流】命名するようになってからはけっこう楽になった。
あんたもどう?

321 :仕様書無しさん:04/03/20 04:22
結局プログラマという人種はスレ違いだろうが討論がお好きなようで・・・

322 :仕様書無しさん:04/03/20 04:27
>>308
時々それに悩みすぎてコーディングがえらく遅い子いるよね・・・

323 :仕様書無しさん:04/03/20 05:27
>>319
そのまんまですね。

324 :仕様書無しさん:04/03/20 05:35
>319
できれば「べっちょり」という言い方をやめて欲しいものだ。
我が故郷の言葉では「べっちょ」=「お○んこ」なのだよ。

そんなの(゚听)シラネといわれそうだが。

325 :仕様書無しさん:04/03/20 05:54
給湯室で電気ポットでお湯沸かそうと思ったらよ、
コンセントに挿すほうんところにとんかつソースがおまんこりついてたんだよ。

326 :仕様書無しさん:04/03/20 06:29
>>320
じゃあ漏れも今後はニッポリアン【我流】命名しようかな

327 :仕様書無しさん:04/03/20 07:13
>>311
SORTが前にきたほうが、入力補助とかで並ぶからいいような。

328 :仕様書無しさん:04/03/20 07:19
ハンガリアンとかニッポリアンとか言われても、でんでん分かんねーYOヽ(`Д´)ノ
具体的に、どうやるのか教えてくらさい。

329 :仕様書無しさん:04/03/20 07:53
じゃあ、おれは英語リアンで

330 :(゜Jし゜):04/03/20 09:19
この前見たテーブルの列名
table1.RirekiNum
table2.RirekiSeq
table3.RirekiNo
table4.RirekiBango
頼むから名称くらい統一してくれ…

331 :仕様書無しさん:04/03/20 09:23
>>330
多分全部違うんだよ。
数値、連番、No、番号・・・それでもNoと番号は一緒だな。w


332 :仕様書無しさん:04/03/20 09:35
>>331
Noは0から始まってて、番号は1から始まってたりするともう。

333 :仕様書無しさん:04/03/20 09:47
RirekiYes があったりするとか。

334 :仕様書無しさん:04/03/20 10:03
BangoがBingoのタイプミスとか。

335 :仕様書無しさん:04/03/20 10:12
#define MAX_MIN_VALUE 300

・・・どっちなのかはっきりしろ。


336 :仕様書無しさん:04/03/20 10:20
最大値の中にも種類がいくつかあって
その中の最小値なんじゃね?

337 :仕様書無しさん:04/03/20 10:23
>>336
いや、最小値として設定することが許される最大の値だろう。

338 :仕様書無しさん:04/03/20 10:50
MAXのファンなんだよ。

339 :仕様書無しさん:04/03/20 10:52
>>338
新幹線か?


340 :仕様書無しさん:04/03/20 10:55
>>339
アムロのおまけのほう。

341 :仕様書無しさん:04/03/20 11:00
連邦の白い奴か

342 :仕様書無しさん:04/03/20 11:01
MAXってまだ解散してないの?

343 :仕様書無しさん:04/03/20 11:09
>>341
いや、マクロスの青い髪の奴。

344 :仕様書無しさん:04/03/20 11:17
マックス桐島

345 :仕様書無しさん:04/03/20 13:54
俺は会社でマックスって呼ばれてるよ

346 :仕様書無しさん:04/03/20 14:17
( ´∀`)<オイデ マックス! エサノ ジカンヨ♥

347 :仕様書無しさん:04/03/20 17:05
概要設計なんてのは設計ごっこだよ。
詳細設計と呼ばれているフェーズを徹底的に行うべし。

デマルコ『デッドライン』より

348 :仕様書無しさん:04/03/20 17:07
>>347
そんなものはどうでもいいんだよ!
動けばいいんだよ!動けば!

349 :仕様書無しさん:04/03/20 18:12
「動いている状態」を定義しないと、動けばいい、というのも満たせないぞ。

350 :仕様書無しさん:04/03/20 19:07
俺が動いていると思ったら、それが動いている状態だよ。
文句ばっかり言ってないでさっさと作れよ

351 :仕様書無しさん:04/03/20 19:51
目立系の仕事って設計ごっこのフェイズ長いよな。
プロパーが実装知らないからだけど。
スレ違いでした。


352 :仕様書無しさん:04/03/20 20:18
>>347
「詳細設計と呼ばれているフェーズ」ってそんな重要か?
何か俺の考えてるのと違うものを言っているだと思うが…

353 :仕様書無しさん:04/03/20 20:32
>>352
俺もデッドラインを読んでそこに引っかかった。

デマルコ曰く
 デバッグの時間が開発の大部分を占めるのなら、デバッグ自体を無くせばよい。
 バグのほとんどはインタフェース部分に潜んでいる。
 すべてのインタフェースをプログラムコードと一対一で対応できるほど丁寧に設計しろ。
 そうすればバグを激減でき、デバッグしなくてもよくなる。

インタフェースの設計は基本設計フェーズでやるものだと思うので、引っかかった。
しかし、どのフェーズで実施するかはどうでもよくて、
インタフェースを丁寧に設計することが主張の本質なので、
trivial だとみなせばいいよ。

354 :仕様書無しさん:04/03/20 20:36
>>353
インターフェースについてはその通りだが、
「trivial」という言葉の使い方がわからん。
普通、「trivial」は「些細な」とか「取るに足りない」とかいう意味なんだが、
何が些細で取るに足りないんだ?インターフェースじゃないよな?
デマルコの主張も些細だとは思わんし。謎だ。


355 :仕様書無しさん:04/03/20 20:37
「どのフェーズで」という部分を trivial だと書いたつもり。
誤解を招く語順だね、すまん

356 :仕様書無しさん:04/03/20 20:48
>>353
> インタフェースの設計は基本設計フェーズでやるものだと思うので、引っかかった。

デマルコの言っているインターフェースはもっと具体的な、型なんかの情報も
含んだもの。だから詳細設計で正しい。


357 :仕様書無しさん:04/03/20 20:59
基本設計時のインターフェースと
詳細設計時のインターフェースは
別ものですか?

358 :仕様書無しさん:04/03/20 21:02
デマンコって誰?

359 :仕様書無しさん:04/03/20 21:06
>>356
そうかな。
たとえばコンポーネントの開発を外部(他チーム、外注チームなど)が行うと仮定する。
設計書とともに、class や interface の仕様を共有するはず。

具体的に言えば、コンポーネントのコンテキストを説明する仕様書のみならず、
class や interface のソースファイル(ないし .jar ファイル)も渡す。


デマルコが言うのは、
すべてのコンポーネントを設計で抽出し、レビューを重ね、
そのインタフェースの設計を厳密に行えというものだと理解している。
開発を外部が行うか自分のチームが行うかは関係しない。

コンポーネントを同定するのは基本設計。
コンポーネント間の関係を示すインタフェースを設計するのは基本設計。
インタフェースに従って設計するのは詳細設計。
上記の定義をもっているので、基本設計フェーズと認識している。

デマルコの問題提起は、基本設計までに抽出されるものでは粒度が粗すぎるということ。
正しさを誰も検証できないということ。
それをとらえて「設計ごっこ」と呼んでいるのです。

#件の書では「管理ごっこ」の方がインパクトある言葉ですが。



360 :仕様書無しさん:04/03/21 01:40
>305
某ネットオークションのCGIに渡すパラメータには表示順制御パラメータとして
o1=d (逆はo1=a)
てのがある。てゆーかリンクのURLにaとあったから試しにdにしてみたら通った。
漏れ的にはトリビア(ORDER BY ASC/DESC)が役に立ってしまった瞬間だった。
オークション止めたくはならなかったがw

361 :356:04/03/21 04:25
>>359

> デマルコの問題提起は、基本設計までに抽出されるものでは粒度が粗すぎるということ。

だからもっと具体的に定義したインターフェースを練れってことだろ。
だから詳細設計で徹底的にやれってことだろ。

362 :仕様書無しさん:04/03/21 07:28
詳細設計時に問題が発生し、基本設計にまで影響があることが判明した場合にどうするか、
を決めておけばいいんじゃなかろうか

基本設計はここまでやるべし、詳細設計はこうすべし、
なんてガチガチに決めてしまうのはオーターフローと変わらんと思う

363 :仕様書無しさん:04/03/21 07:50
でも書く紙が決まってるからな。
基本設計書と詳細設計書のリリース期限があるからどっかで線は引かないと
なんないのね。

>コンポーネント間の関係を示すインタフェースを設計するのは基本設計。

になってない所多いよ。
データ構造すら基本では決めないとかね。

364 :仕様書無しさん:04/03/21 07:59
方法論を教科書として鵜呑みにしている初心者のスレはここですか?

365 :仕様書無しさん:04/03/21 08:08
>>364
確かに方法論は多種多様で、「小中学生の教科書の鵜呑み」の様なスタンスは誤りだけど

366 :仕様書無しさん:04/03/21 13:44
方法として定義するための方法が欲しいねえ

367 :仕様書無しさん:04/03/21 16:06
詳細設計の段階で、ソースと一対一で対応できるほど丁寧に設計することは、
・プログラムのほとんどの部分ではやらないが、
・インターフェイスについては行え
ということではないのか?

詳細設計前にインターフェイスをどこまで設計しておくか、については、
詳細設計段階でインターフェイス以外の部分に戻りが発生しない程度に詳しく
でいいんじゃないの。


368 :仕様書無しさん:04/03/21 16:08
壮観な滝ですなあ

369 :仕様書無しさん:04/03/21 16:42
プログラマは猪突猛進な人が多いのかな?

370 :仕様書無しさん:04/03/21 17:11
引数に float をとるとして、
Float.NaN をちゃんと検査してるか?という話。

371 :仕様書無しさん:04/03/21 22:42
>>370
不勉強で申し訳無いけど
「NaNの検査」ってどうやるの?

372 :仕様書無しさん:04/03/22 01:05
「ナンノの検査」やりたい…


373 :仕様書無しさん:04/03/22 01:12
「ナンノの検査」

ttp://my.reset.jp/~mars/btg/document7/sukeban2a.htm
>抜き打ち検査と言ってもハタから見るとほとんどレイプまがい。
>国家公務員にしては、やってることが非道すぎます。

374 :仕様書無しさん:04/03/22 01:38
おっさんage

375 :仕様書無しさん:04/03/22 21:08
>>371
int isNan(double a)
{
return ! (a < 0 || a>=0);
}


376 :仕様書無しさん:04/03/22 23:36
Cなら:一応isnan()はansiでmath.hに入ってることになってる
他の言語は知らん

377 :仕様書無しさん:04/03/25 18:06
bool check_flg;

if(check_flg);
{
  //check_flgがfalseであってもこの場所が実行されてしまう
}

int value;

if(value = 1)
{
  //なぜか常にこの場所のコードが実行される
}

しかも書いたの俺。あまりにも古典的な間違いに
辞めたいってより感動した。


378 :スコア:-1,フレームのもと:04/03/25 18:52
>>377
そういうことをしないように、
if(1 == value)
と書けばいいのさ。

379 :仕様書無しさん:04/03/25 20:03
VC

warning C4390: ';' : 制御が空の文が見つかりました。意図した記述でしょうか?
warning C4706: 条件式の比較値は、代入の結果になっています。

380 :仕様書無しさん:04/03/25 21:35
>>378
そんな小細工をする前にコンパイラの警告オプションをONにしなさい
その書き方では
if (foo=bar)
のような間違いは発見できません

オペレーターのオーバーロードをしているクラスのテストにはいいかもしれないけどね

381 :仕様書無しさん:04/03/25 21:43
>>379
親切なコンパイラだあなあ。でもその種のwarningを発見するのって
別ツールにするのが正しい方法だと思うよ(lintみたいにね)
文法的に正しいソースを書いたのにwarningを出すのは、「うるせえ」って感じだよ。
warning出力をoffにすれば良いだけなのかもしれないけど、
#「warning出力をonにしてwarningメッセージを全て除去すること」なんてえ規約が出来るのがイヤ

382 :仕様書無しさん:04/03/25 21:52
>>381
>親切なコンパイラだあなあ。
M$にいくばくかのお布施をして徳をつむ必要があります。

383 :仕様書無しさん:04/03/25 23:05
>>381
lintこそコンパイラに付属するべき機能だと思う

384 :仕様書無しさん:04/03/26 01:08
>>381
最近のコンパイラだと当たり前だろ。
潜在的な誤りの可能性は警告する方向に進んでるのに、
その機能を分離しろとは、あんた、時代に逆行してないか。

385 :仕様書無しさん:04/03/26 01:09
>>382
gccだってそうゆう警告はするだろ。ちゃんとオプションをつければ。

386 :仕様書無しさん:04/03/26 01:49
>>385
gcc version 2.95.4だけど、-Wallつけても警告でないよ。
man みてもそれっぽいオプションなさげ。

387 :仕様書無しさん:04/03/26 02:09
>>386
最近のは-Wallで文句言って来る。


388 :仕様書無しさん:04/03/26 02:56
>>384
「時代」は常に正解なのか?

389 :仕様書無しさん:04/03/26 12:55
>388
その時代に生きているならそう。

390 :仕様書無しさん:04/03/26 12:57
>>388
自分で判断する能力がないんでしょう。

391 :仕様書無しさん:04/03/26 13:50
>388
時代に沿うか逆行するかと正解かどうかは、全然違うものだから
相手の言ったことを自分で勝手に拡大解釈したって反論とはなりえないよ?
まずは384から「時代に沿うことが正しいこと」という発言を引き出さないと。

この手順を間違うと390みたいな論点をぼやかす抽象論が出てきちゃうんだよね。

392 :仕様書無しさん:04/03/26 17:26
>>391
388の頭から煙が出るからやめろ

393 :388:04/03/26 22:17
いや、全然、怒ってやしないよ

>>391
>時代に沿うか逆行するかと正解かどうかは、全然違うものだから
そのとおり。>388は>384が「そのことを発見してくれれば良いな」と思って発言しただけだヨ
その種の共通認識が>384には全然無いから、「>384は反論にもなっていない」と思うのだ。

ご指摘の「時代に沿うことが正しいことという発言を引き出さないと」については、
「俺には議論する気は無い」という返事をしておこう

394 :仕様書無しさん:04/03/26 23:22
要するに何か茶々入れたかっただけって事ね

395 :仕様書無しさん:04/03/26 23:35
時代に沿うかどうか、なんていう方向に逸らしても意味ナイっすよ。


396 :仕様書無しさん:04/03/26 23:59
夕べ一晩中かけてちまちまとコーディングして
朝方一眠りしてからいざ走らせたらTypoの嵐。
会社というよりマを辞めたくなる瞬間。

# つーか最近妙にタイピングが……速度は遅いわTypoは多いわ……

397 :仕様書無しさん:04/03/27 00:21
うちのプロジェクト、ソースコードというより開発ディレクトリが滅茶苦茶で泣きたい。

ルート直下に *.c や *.c.bk, *.c.bk2, *.c.bk2.org などが大量にあったり。

開発ディレクトリの各ディレクトリはどのように配置するのがお勧めでしょうか?


398 :仕様書無しさん:04/03/27 00:23
397です。
CVSを導入する前に
ディレクトリの意義を知らない奴が多すぎなんで。


399 :仕様書無しさん:04/03/27 00:27
デスクトップに全てのファイルを配置するのが一番漢らしい

400 :仕様書無しさん:04/03/27 00:32
>>397
ルート直下ってことはUNIXでしょ?
rootアカウントで開発しているってこと?

401 :仕様書無しさん:04/03/27 00:34
>>400 >>397です。
みんなrootアカウントで開発です。
PMに開発指針を尋ねても「まかせた!」としかいわず
みんな好き放題にやりだしてしまいました。


402 :仕様書無しさん:04/03/27 00:47
>>401を見て、ありえねーよ、とか思ったけど
今のプロジェクトのフルビルド環境は、
rootじゃないと確かどっかでエラー出たな。

まぁ、フルビルドなんて、一部のSI屋さんしかやらないし
他はまともだからいいんだけどね。

403 :仕様書無しさん:04/03/27 00:48
MULTICSで開発しているよりまし、と思えば、
少しは慰めになりますか? > 397

404 :仕様書無しさん:04/03/27 00:54
ところでMULTICSの仕様って公開されてたっけ?

405 :仕様書無しさん:04/03/27 01:09
>>397
叩いて殴って、身体にディレクトリの意義を教える。

何にしろ、バージョン管理システムくらい普通に使うような開発体制をとろうよ。
ていうか、そういうものがあるって、いい加減理解しようよ。
あんたのことだよ、社長!

406 :仕様書無しさん:04/03/27 19:26
// 特別な処理(管理番号:XXX001)

至るところにちりばめられているんですが意味がわからない。
管理台帳は課長のみ参照可能で一般には見せてくれない。


407 :仕様書無しさん:04/03/27 21:00
>>406
意味ね〜

408 :仕様書無しさん:04/03/27 22:45
PM_CLICKとかPM_CREATECOMPLETEとか
変なイベント用のメッセージ定数作らないでくれよ。
標準のメッセージで事足りるんじゃー。


409 :408:04/03/27 22:51
ついでに、スレ違いな質問なんですけど。

方書 ← これなんて読むの?

アパート・マンション名なんだけど、
「かたがき」って言ってるのも聞いたことあるし、
DBのカラム名は「HOUSYO」になってるし。

知ってる人教えてよ。


410 :仕様書無しさん:04/03/27 22:56
「かたがき」だと思う。
「方書」と「かたがき」で検索するとお役所関係の
ページやらPDFやらがいくつか引っかかるし。

411 :仕様書無しさん:04/03/27 22:57
MS Bookshelfによると、
 かた‐がき【方書】
  同居人や下宿人が住所に書きそえる「―方」という語。
らしい。
でも、KATAGAKIにすると肩書と間違われる罠。

412 :408:04/03/27 22:57
レス早っ!
サンクス。


413 :408:04/03/27 22:59
おおおっ。
411さんありがとう。


414 :仕様書無しさん:04/03/28 00:16
ほうしょ、かよ。。。

415 :仕様書無しさん:04/03/28 01:39
スズキの奉書焼き食いてぇ

416 :仕様書無しさん:04/03/28 12:41
4月から派遣される先の仕様書の一部

void SZIEGYt00001()

入力
 DATA_SIZAI.BUFFER00004
出力
 DATA_EIGYO.BUFFER00010
 DATA_EIGYO.BUFFER00001
解説
 資材課データ00004に対して資材課日次処理S00001Aを実行し、
 その結果データを営業課データ00010に書き込む
 営業課データ00001が1の場合は、未処理のデータが残っているので
 再度この関数を実行する必要がある。

ちなみにデータの型は全部char[1000]でもちろんグローバル。
日次処理S00001Aとかデータ00004とかの意味は
それぞれの課の課長印をもらって「データ参照表」とやらを借りなきゃ
わからないそうでつ。
関数名の「t」ってのは、作成中は「t」で、テストが完了したら
「T」にする…って、全部後からリネームしろと?



417 :仕様書無しさん:04/03/28 14:58
コボラーだ。
コボラーの臭いがする。

418 :仕様書無しさん:04/03/28 15:31
コボラーって、あの手の機械的なID臭い変数名とかどうやって理解してるんだろう。

ひょっとして、自動的に各変数を色分けして表示してくれたり、
(似たようなスコープや参照の変数は似た色に、そうでなければ全く異る色に)
変数の役割をアイコンでアノテートして直感的にわかるようにしたり、
あるいはハイパーテキスト的に参照をサマリ表示したりナビゲートしたり、

そういう素晴しい開発環境が標準だったりするのだろうか?(愕

419 :仕様書無しさん:04/03/28 15:48
漏れも初めて見たときはびっくりしたよ。全部同じに見えた。
てゆーかねぇ、他言語でやるの勘弁して。ほんとに。

420 :仕様書無しさん:04/03/28 16:09
>>418
帳簿に決まってんじゃん。
全部帳簿に表書いて、ファイルに綴じてあんの。
書き足すときは上司の判子が要るの。

あと念のため言っておくとスコープなんてないから。全部グローバル変数だから。
参照なんて無いから。全部要するにchar型みたいなもんだから。
可変長だとか動的確保だとかそんなもん一切無いから。

昔最前線でバリバリやってた、って自称する管理職の脳内はそんな状況。


421 :仕様書無しさん:04/03/28 16:26
ここ40(50?)年ほどに得られた経験を無かったことにすると>>416のようになる。

422 :418:04/03/28 17:06
>>420
> 帳簿に決まってんじゃん。

その帳簿って、電子化されてて、ハイパーメディアシステムに食わせてやると
ソースからハイパーリンクとして、その変数に関するドキュメントや関係した人
へのコンタクト情報とか、同じ人が同じ時期に作成した変数の一覧とか、
その変数に関連した変更履歴に、・・・って、ないよね、すまそ。
(そっち方向への管理なら、ここまでやらないと無意味だろと思うよ)

> あと念のため言っておくとスコープなんてないから。全部グローバル変数だから。

そういや、そうだった。指摘さんくすこ。


423 :仕様書無しさん:04/03/28 17:28
すげえぜ。ある意味漢!
char[1000]のとこまでCOBOLの仕様書だと思って読んでました。

424 :仕様書無しさん:04/03/28 17:34
voidで気づけよ

425 :仕様書無しさん:04/03/28 17:36
もう、萌え萌えですぅ♪♪

426 :仕様書無しさん:04/03/28 17:37
ここまで読んでようやくCOBOLじゃないことに気づきました。

427 :仕様書無しさん:04/03/28 17:42
四則演算とかどうするんだろう?(ガクブル

428 :仕様書無しさん:04/03/28 17:52
前々から疑問に思ってたんだが、COBOLってあの良く分からん暗号みたいな変数名にした方が、
member_code とかいう名前の変数にするよりもいいシステムが出来るもんなの?

429 :VBホブゴブリン ◆vb/Vb/gcNE :04/03/28 18:03
(・・;;; 全部char[1000]でもちろんグローバル?!
 VBやっていても そんな設計は時折見かける…
 そっか、可変長に順応できないコボラーの仕業だった ノカ!

>>423
ハイフンじゃなくてアンダーバー ダッタ時点で気づいたYO!
COBOLの変数名は A-B-C のようにやたらハイフンで区切る傾向にある。

>>429
数値計算は+-*/で普通に出来る。intやLongのような型はないケド。
01 SUUJI-WK 9(5)
のように、桁数指定で宣言。これだと0-99999まで。
やり方次第で小数点やマイナスも扱える。
…懐かしい。

430 :ヽ(´ー`)ノ ◆.ogCuANUcE :04/03/28 18:16
> COBOLの変数名は A-B-C のようにやたらハイフンで区切る傾向にある。
a-b と a - b で結果変わるのか?阿呆臭いな(´Д`)

431 :仕様書無しさん:04/03/28 18:36
>>430

COMPUTE って命令文の後でないと四則演算は無効になる
…だったと思う。
だからそういう間違いは起こりにくい か も

432 :ヽ(´ー`)ノ ◆.ogCuANUcE :04/03/28 19:00
> COMPUTE って命令文の後でないと四則演算は無効になる
(゚Д゚)ハァ?……とか思ったけど、よく話題になる

if (a = 1) {
  // ....
}

みたいなミスがなくて、それはそれでイイかも。マンドクセーけど。

433 :仕様書無しさん:04/03/28 19:11
>>432
代入はMOVEという命令でないと使えないから、その間違いも起こらんね。

434 :仕様書無しさん:04/03/28 20:11
つーか、派遣会社を知らんのでなんともいえないんだけど
そういうところに派遣されるのは、イヤです、とか言えないのでつか?
俺ならはっきり言ってそうだが。

っていうか、そういうとことは、おつきあいをしなければいいのであ?
とか思わないでもない。

435 :仕様書無しさん:04/03/28 20:12
>>432
最低限理解してから煽れよ

436 :仕様書無しさん:04/03/28 21:58
ちなみに関数とか入れ子とかって概念なんて無いから
(最近は関数とかオブジェクト指向とかどうせ誰も使わないのに無理やり押し込もうとしてるけど)
if ( a + b > c) {...}
とか
if (isCorrect(a,b,c)) {...}
みたいなのは出来ないよ。

典型的な書き方だと

COMPUTE D = A + B.
IF D > C THEN ... END-IF.
とか
MOVE A TO IS-CORRECT-IN-A.
MOVE B TO IS-CORRECT-IN-B.
MOVE C TO IS-CORRECT-IN-C.
PERFORM IS-CORRECT.
IF IS-CORRECT-OUT-D = TRUE THEN ... END-IF.

無論変数は全てグローバルね。
あーくそ。こんなもんを自然に書けるようになった自分が嫌だ。記憶を消してくれ。

437 :436:04/03/28 22:03
おっとと、補足。
しかもTRUEは

77 TRUE PIC X(1) VALUE '*'.

とかなってたり。
77 って言うのが const のような読み取り専用ですよっていう定義の仕方。

ま、どうでもいいよ。知らないに越したことは無い…。

438 :仕様書無しさん:04/03/29 00:09
俺、コボラーってすげえ頭いいと思うよ。
クラスどころかスコープ無しで変数の管理できるなんて、
俺の脳みそじゃ無理だし。
願わくはその脳みそを楽するためにつかってくれれば、と思うけどね。

439 :仕様書無しさん:04/03/29 00:40
>432
> if (a = 1) {
>   // ....
> }
これ今でもやっちゃうことあるわ。
てか皆もあるよな?な!?

440 :仕様書無しさん:04/03/29 00:52
>>439
ない。そのバグは出しても良いけど、一度だけだ。

441 :仕様書無しさん:04/03/29 01:53
>>436

こういうの見ると、その昔アセンブラしかやってなかった人間にとっては
COBOLってのもすごく使いやすい言語なんだろうなあって思う。

442 :仕様書無しさん:04/03/29 02:02
>>441
COBOLって、高機能マクロが十分そろってる汎用アセンブラといっていいもんな。

443 :仕様書無しさん:04/03/29 03:28
>>439
だから警告レベルをあげろと何度言えばいいのか。

444 :仕様書無しさん:04/03/29 08:44
アセンブラをつかってたものにとって
使いやすいのは、C言語
COBOLは全然違う


445 :仕様書無しさん:04/03/29 13:36
PDP11のアセンブラってほとんどCそのものらしいね。
*r1++ = *r0++; が MOVB (R0)+, (R1)+ とか。

ttp://pages.cpsc.ucalgary.ca/~dsb/PDP11/InsSet.html

446 :仕様書無しさん:04/03/29 13:59
PDPってUnix発祥のプラットフォームだからね
cが「PDP11のアセンブラ」を真似たんだ

447 :仕様書無しさん:04/03/29 14:17
以前古いPDP11のシステムを移行する仕事をやったことがあったけど、
あんなマシンでよくUNIXをこさえたもんだと感心した。
「表示」装置がラインプリンタだもんなあ。

448 :仕様書無しさん:04/03/29 15:44
小洞ーがコボルのコーディングをしていることは少ないんだけどね。
普通はマクロっぽい拡張言語でコボルコードを自動書き出しさせている。


449 :69式フリーPG ◆hND3Lufios :04/03/29 16:14
#define DATA /* おまじない */
#define DIVISION /* おまじない */

450 :仕様書無しさん:04/03/29 18:38
日本語マクロとかね。

451 :仕様書無しさん:04/03/29 19:15
>>448
自分の周囲の状況だけを見て「普通」とはいかがなものか。
しかし、特定マクロ言語の世界から抜け出そうとせずに
進化することを拒んでいるオッサン連中が居るのは確か。

452 :仕様書無しさん:04/03/30 12:05
>>449
まさか
>/* おまじない */
に置換される・・・のか?


453 :452:04/03/30 12:06
ごめん。なんか間違った。


454 :仕様書無しさん:04/03/30 12:50
>>452,453
(・∀・)ニヤニヤ

455 :仕様書無しさん:04/03/30 13:06
おまじないっつーか
マジックナンバーっぽい処理満載のソースは引き継ぎたくないなぁ

と言いつつ、自分が書くときはそういう処理満載になっちゃう罠

456 :仕様書無しさん:04/03/30 22:25
うちの会社のコードでは

#define VALUE1 1
#define VALUE2 2


とかがある。
さすがに、意味ないと思うんだけどなぁ、と。

457 :仕様書無しさん:04/03/30 22:36
>>456
検索でハケーンしやすいように。

458 :仕様書無しさん:04/03/31 00:19
>>457 (・∀・)ニヤニヤ

459 :仕様書無しさん:04/03/31 07:23
>>457
GREPerハケーンw

460 :仕様書無しさん:04/03/31 12:12
ぐれっぱ。

461 :仕様書無しさん:04/03/31 16:08
くわッぱ

462 :仕様書無しさん:04/03/31 18:16
>>451
>自分の周囲の状況だけを見て「普通」とはいかがなものか。

周囲って言っても日経コンピューターとか業界誌とか
メーカーとかが発行のソフトウエア集とか見ればそんなものが
満載だし、業界向け講習会とかでもコボル言語生講習会とかは
入門講座以外ないことを見て言っているんだが。

「普通」をどう定義するかは勝手だが、そんなこと言っていると
普通はどうこうって発言は一切できなくなるぞ。

俺はコボル9割の情報処理会社の中にある技術計算課なる
部署でC/C++を使っているわけだが。
#別に技術計算をやっているわけではない

463 :仕様書無しさん:04/03/31 18:34
>>462
>普通はどうこうって発言は一切できなくなるぞ。
それでいいんだ。リサーチ業じゃないんだから
「俺の周りはこうだ」
で充分さ。

464 :仕様書無しさん:04/03/31 22:15
>「俺の周りはこうだ」
そういうのを井の中の蛙と言います。

465 :仕様書無しさん:04/04/01 00:52
>>「俺の周りはこうだ」
>そういうのを井の中の蛙と言います。
そう言ってるのはお前の周りだけです。

466 :仕様書無しさん:04/04/01 07:11
>>464
>そういうのを井の中の蛙と言います。
「俺の周りはこうだ、だから世の中全てはこうなのだ」が井の中の蛙だな。
「俺の周りはこうなんだけど困ったもんだ」とか
「少なくとも俺の周りはこうなんだけどね」ならば普通の書き込みだ。

467 :仕様書無しさん:04/04/01 09:34
464はかなりヤバイかもね。

468 :仕様書無しさん:04/04/01 10:04
「食べられてしまった、だから消化されるだけだ」が胃の中の蛙だな。
「食べられてしまって困ったもんだ」とか
「あとはウンコになるのを待つだけだ」ならば普通の書き込みだ。


469 :仕様書無しさん:04/04/01 12:17
468はかなり間抜けかもね。

470 :仕様書無しさん:04/04/01 14:11
DB設計なんですが

「LINK_TABLE」と「LINK_COLUMN」という項目がある。
もちろん値はテーブル名やカラム名。


471 :仕様書無しさん:04/04/01 15:34
469のほうが間抜けだと思うぞ…

472 :仕様書無しさん:04/04/01 19:49
>「食べられてしった、だから消化されるだけだ」が胃の中の蛙だな。
>「食べられてしって困ったもんだ」とか
>「あとはウンコになるのをつだけだ」ならば普通の書き込みだ。
なら468はかなり間抜けかもね。

473 :仕様書無しさん:04/04/02 00:48
俺の胴回りはこうだ          104cm。

474 :仕様書無しさん:04/04/02 10:28
筑波山麓合唱団とキモデブのスレはここですか?

475 :468:04/04/02 12:16
>>472
適当に改変しただけのネタ書き込みにマジレスされても、対応に困るんですが…w


476 :仕様書無しさん:04/04/02 13:31
>>466
>「少なくとも俺の周りはこうなんだけどね」ならば普通の書き込みだ。
自分の周りだけを見て普通だと言うやつがいまだにいる

477 :仕様書無しさん:04/04/02 14:36
>476
それは466と同じ見解だね。

478 :仕様書無しさん:04/04/02 23:44
>>475
俺の目には>>472がマジレスにはとても見えないが…

しかも「かなり」だから「困った」の部分にマが残っているのかw

479 :仕様書無しさん:04/04/02 23:45
>>475
適当に改変しただけのネタ書き込みにマジレスしてるのは君だろう。

480 :仕様書無しさん:04/04/05 01:09
害虫に頼んだソースに、本当は information であるべき
エラー出力が inpomation と書かれていた。俺は気づかず納品。
しばらくして、こんなエラーが出ていますと客からメール...。_| ̄|◯


481 :仕様書無しさん:04/04/05 02:21
 *inpomation*
貴方はインポです

482 :仕様書無しさん:04/04/05 06:54
>>480
わざとじゃない?
オチャメな外注さんだね(w

483 :仕様書無しさん:04/04/05 07:34
"inphormation"と綴りたかったんじゃないかな?

484 :仕様書無しさん:04/04/05 12:43
>>483
英和辞典 [ inphormation ]の前方一致での検索結果 0件


485 :仕様書無しさん:04/04/06 18:55
>>483
fをphと書いてちょっとしたクール感を味わいたかったのかな

486 :仕様書無しさん:04/04/06 23:41
#include <stdio.h>

int main(void){
PHILE* php = phopen("hoge.txt", "r");
phprintph(php, "Hello, world!");
plclose(php);
return 0;
}

もう何が何やらw

487 :仕様書無しさん:04/04/07 00:58
inhormationでなかっただけまし。

488 :仕様書無しさん:04/04/07 10:07
joformation

489 :仕様書無しさん:04/04/08 13:16
inhuxome_syonn

490 :仕様書無しさん:04/04/10 00:45
直してくれ!と渡されたコードの先頭。


#define TRUE  1
#define FALSE 2


(;´Д`)逃げたい

491 :仕様書無しさん:04/04/10 00:54
>>490
さらにコードの途中では
FALSEが2であることに依存した場所が・・・

492 :490:04/04/10 01:22
さらにその後も突っ込みたいのは山々ながら
どこから突っ込んでいいかわからんコードの連続をガッと省略しつつ、
別のヘッダで極めつけを発見。


#define NORMAL 1
#define ABNORMAL -1


もうね、死ねよと

493 :仕様書無しさん:04/04/10 01:31
>>492
まさにアブノーマルだなw
それどんな文脈で使ってんの?

494 :490:04/04/10 01:39
>493
関数の戻り値で使っているらしい。

・・・じゃあさっきのTRUEとFALSEは?
とGREPしたところ、

  該  当  0  件

どうよ?

495 :仕様書無しさん:04/04/10 02:01
どうよ?っつわれても。

「どうしようもねえよ」
としか言い様がないw

496 :仕様書無しさん:04/04/10 02:03
使ってないなら却ってよかったじゃん







まあ、それを除いてもどんなソースかは察するが

497 :仕様書無しさん:04/04/10 02:07
#define TRUE 0
#define FALSE 1

ってのなら見たことある

498 :仕様書無しさん:04/04/10 09:19
>>101の事半ネタだと思ってたんだが、
今期から配属された銀行関連のプロジェクトの
コーディングルールがまさにそれで、目が点になった。
一応Cなんだけど、変数名は全てファイル名+4桁の連番。
しかもファイル名自体もシステム名+4桁の連番。
仕様書は古参SEの脳内にしかねーし、
ソース見ても定義だけされて使われてない変数ゴロゴロあるし_| ̄|○

499 :仕様書無しさん:04/04/10 11:14
事実はネタよりも奇なり

500 :仕様書無しさん:04/04/10 11:40
>>498
<<<<<<<<<<<<<<<<<<<<<<<<<;゚Д゚>>>>>>ガクガクブルブル

501 :仕様書無しさん:04/04/10 12:30
>>498
大昔のコボラーってそんなじゃなかったの?
そのシステムの一番古いソースとかドキュメント資料には
196x年とか入ってんじゃないの?
もっとも その流れで いまだにやってる やつらがいる話は
良くある話ですね それにしても 変数名までもですか?
これって
・ドキュメントしっかり だけど 頭使いたくない 仕様作成者 の作った仕様書
 ただし 物(Doc)は有るけど 中身めちゃくちゃってこともある
・仕様作成者 プログラマ パンチャ デバッガ が全部別々の
 人間が作業していた頃で
・デバッグもマシンではなくて ダンプを見ながらの作業だったり

こんな頃の流れでしょ

502 :仕様書無しさん:04/04/10 13:22
>>498
>仕様書は古参SEの脳内にしかねーし、
そのくせ仕様を確認したら「なぜそんな事も知らない!」とか
ぬかしやがるからタチが悪いね。
古参連中共が「結局このシステムは俺達がいないと動かねーんだよなー」
とか宣ってたり。「古参がいないと動かせない」ように仕向けてるんだろーが。

自分が関わったプロジェクトでは、項目名が
[ファイルID] + [開始位置] + "-" + [バイト数]
形式だった。ファイルレイアウトは度重なるコピーで解読不能なものしか
残ってなかった。。。

503 :仕様書無しさん:04/04/10 14:08

「改良して」と渡されたVBのソース。

Private Sub FileRead()

'省略

Call FileWrite 'ファイルを作成します

End Sub

ファイル名とか出力するデータが入ってる変数は当然グローバル。
作った人はすでに辞めてる。


504 :498:04/04/10 14:16
>>501
90年代頭ごろに作られたものだけど、
開発したのはCOBOLとBASICやってた人間ばかり。
ソースもBASICかシェルスクリプトかって代物。
ちなみにコーディングし終わったら、
コンパイルする前に一度ソースコードをプリントアウトして
コンパイルエラーが出ないか修正箇所をペンで追ってチェックするという
古き良き時代錯誤の風習もある。
さすがに俺はすぐにコンパイルしてしまうが。

>>502
そうそう。聞いても「ソース見てください」って言うばかりなんですよ。
しかもヤツラの頭の中じゃデータや処理が完全に数字と合致してるらしく、
ミーティングで「0010の処理なんですけどね」なんて平然と言うし、
ソースのコメントにも「/*合計額にxx00160085金額を加算*/」とか
平然と書いてあるんですよ。

古参の連中は十数年間この仕事しかしてないので、
その間、時間がずっと止まってて、自分たちがおかしな事をしてるとは
微塵も思っていないらしい。

505 :498:04/04/10 14:17
BASICってN88日本語BASICとかね。

506 :VBほぶごぶりん ◆vb/Vb/gcNE :04/04/10 14:43
(^_^; COBOLデモ 変数に日付入レルノハ 見タコト無イヨー
 恵マレテタ ノカナ?

507 :仕様書無しさん:04/04/10 15:26
>>131
俺も似た様なコードを見た。書き直そうと思ったが、
上司に、デグレードが怖いのでやめろと言われた。

(↓本当はVBだけど、分かりやすいように半分C風に。)

Do While(true)
 if (baka == 1) {aho = 56; Exit Do; }
 if (baka == 2) {aho = 22; Exit Do; }
 if (baka == 3) {aho = 46; Exit Do; }
 if (baka == 4) {aho = 79; Exit Do; }

 Exit Do
Loop

何がしたかったのか。俺には理解不能だ。

508 :仕様書無しさん:04/04/10 16:07
> 俺も似た様なコードを見た。書き直そうと思ったが、
> 上司に、デグレードが怖いのでやめろと言われた。

その上司が書いたんじゃないのかw

509 :仕様書無しさん:04/04/10 21:12
>>131
>>507
これこれ、人のプログラムコードをそのように言う物ではありません
これをコーディングした人は その仕事を ステップ=金額 で請け負った
のですから... ここまでせこいことをして ステップ数を増やしたいのです

プロというのは しっかり動く状態で プログラムコードを 余分に付け加えても
まだしっかり動く コーディングをするのです

『何がしたいのだか』は コーディングされたコードの動作ではなくて
プログラマした本人が 自分にとって『何がしたいのだか』を考えるべき ですね

って 全部嘘だっぴょーん って言いたいけど たいていこんな奴はいるぞ!
皆さん気をつけようね。
ちなみに こんなコードを見つけたら 『ばかやろー!』ってコメントを
追記するのは私です。


510 :仕様書無しさん:04/04/10 21:23
>>131のような事は良くやるけどなー。

switchの外に共通処理が入るんだけど、

511 :仕様書無しさん:04/04/10 21:28
スレの趣旨とずれて申し訳ないけど、
>509 氏の言う、ステップ数に応じた対価っていう形態は、あるんですか?
話には聞いたことあるけど。


512 :仕様書無しさん:04/04/10 21:49
>>511
鐵な某SIでは未だに「工数管理」とかいってプロジェクトへの貢献度を
ステップ数で評価してるようだ。
そこへ出向してた頃コードの無駄な処理を削る、なんて作業をした
俺は間違っているのか?


513 :仕様書無しさん:04/04/10 23:19
下記の者を懲戒処分とする。
>>512 ステップ数を削減して会社に損害を与えたため。


514 :仕様書無しさん:04/04/10 23:37
処分内容
削減したステップ数割合の減給3ヶ月とする

515 :仕様書無しさん:04/04/10 23:57
スパイラルな開発でもしてるのか
ウォーターフォールでファンクションぽいんt

('A`)情報処理試験来週か

516 :仕様書無しさん:04/04/11 00:17
>515

ソース見てたら
/* 真実は奏でられた……!! */
とかあるんかね > スパイラル

517 :507:04/04/11 02:15
そういや、その上司にステップ数を出せとか言われたな。
ステップの数え方は場合によって違うとか、どこかのサイトに書いてたので、
どういう基準で出すのかと聞いたら、答えられなかった。
ちなみに、その上司はいつも見積もりを間違って、赤字プロジェクトばっか生んでるという噂が...。

518 :仕様書無しさん:04/04/11 08:01
常に同じ基準で見積もる。んで、実際の値と比較する。
これを繰り返すことで、精度が上がってくる。

むしろ、組織にノウハウとして貯めるための仕組みがあるかどうかだな。
ない場合に>>517のようになる。

519 :仕様書無しさん:04/04/11 10:18
ソースの行数をステップ数と呼んで見積もりの根拠としてるんだとしたら
同じ基準もクソも無いがな…

520 :仕様書無しさん:04/04/11 10:26
そのために繰り返すのでは?

まさか、コメント行を省いてないからクソだとか、そういう低レベルな
話じゃないよね?

521 :仕様書無しさん:04/04/11 10:34
必死だなw

522 :仕様書無しさん:04/04/11 11:54
ソフトの価値を決めるのにソースの行数を根拠にしようとするのは
車の価値を決めるのに部品の総重量を根拠にしようとするような、
音楽の価値を決めるのに演奏時間を根拠にするようなもんだ。

そんなのを何度繰り返したって見積もりどおりにいくわけ無いだろうよ。

523 :仕様書無しさん:04/04/11 12:34
価値の話?

見積もりの話じゃなくて?

524 :仕様書無しさん:04/04/11 12:37
>523
ソフトの値段を決めるのにソースの行数を根拠にしようとするのは
車の値段を決めるのに部品の総重量を根拠にしようとするような、
音楽の値段を決めるのに演奏時間を根拠にするようなもんだ。

こう書けばいい?


525 :仕様書無しさん:04/04/11 12:45
繰り返していけば、見積もった行数と実工数は比例するようになるだろう。
つまりそれにしたがって価値もつけることができる。

ただ、これをやるだけの手順化や、情報の蓄積が進んでない、
管理レベルの低い職場だと無理だろう。そういう場所では、
必ずと言っていいほど反発がある。>>522 がその典型。

526 :仕様書無しさん:04/04/11 12:48
まあ、現実にはそうもウマくいかないわけで、
異なる指標を持ち出してはひっかき回してきたわけだが。

とはいえ、>>524みたいなトンチンカンなのを挙げた話は聞かないな。

527 :仕様書無しさん:04/04/11 13:24
価値そのものではないが作業量の目安にはちょうどよい。
ステップ数なんてそんなもの

528 :仕様書無しさん:04/04/11 13:28
カラ改行の数で作業量がわかるとでも・・

529 :仕様書無しさん:04/04/11 13:36
>>528
コメントと空改行をステップ数に加えたければ、そうすればいい。

530 :仕様書無しさん:04/04/11 14:54
コメントも指標としては重要だと思うよ。

計測してみたけど、ちゃんと作ったのは、
コメント込み行数がコメント抜き行数の二倍ぐらいになることが多いな。
手を抜いたのはコメントが少ない。

つーか、まだカラ行数とか言ってるのが居るの?すごいねココは

531 :仕様書無しさん:04/04/11 14:59
>>530
それをステップ数に加えるなという話だろ。
あとお前をこのスレに加えたくないという話でもある。

532 :仕様書無しさん:04/04/11 15:09
ようやくカラ行をステップ数に含めるかどうかの話になったのか
お前ら難儀なやつだなあ

533 :仕様書無しさん:04/04/11 16:22
いっそのことバイト数で計算したら?

534 :仕様書無しさん:04/04/11 17:05
>>532
煽るなら「ステップ数」の定義を勉強してからにしたら?

535 :仕様書無しさん:04/04/11 17:10
ウィザードで作られる部分はどう数えるの

536 :仕様書無しさん:04/04/11 21:02
>533
関数名や変数名ををGUIDにすればきっと価値が上がるな。

537 :仕様書無しさん:04/04/11 21:05
>536
いっそそこらの適当なファイルのMD5取ってそれを使ってはどうか。

538 :仕様書無しさん:04/04/12 10:58
>>510
君はコーディングの能力を高める努力をした方がいい。

539 :仕様書無しさん:04/04/12 12:19
空行やコメントをどーこーなんて余計なこと考えるなよ。
「目安」程度にしかならないものに、ルール作ったって無意味だろ。
ファイル容量を40で割るとか、そんな程度で十分。

540 :仕様書無しさん:04/04/12 18:05
>>525
技術革新が停止した世界なら反復により最適解を求められそうな気はする。
が、現実には、新しいプログラミング言語、新しいライブラリ、新しいIDE、
新しいシステム構成が次々と出ていて、以前の最適解が次回には最適でなくなる。
VBのC/Sアプリで培ったノウハウがASP.NETのWebアプリで有効かって言うと当然無理。

まあ、大脳皮質の発達が10数年停止したCOBOLerには向いてるかもね。

541 :仕様書無しさん:04/04/12 22:00
>>540
新しいのがでてくると有効でなくなるのは当たり前。
でも、最適化しなおすのに何年もかかるとは思えない。
まあ、Javaは出てきてからもう7年も経つね。

「変化した場合に最適化する手段」も決めておきたいもんだ。
新しい環境に慣れるのが苦手な人(540とか)も多いみたいだし。

542 :仕様書無しさん:04/04/12 22:20
>>541
そこでイテレーティブな開発方法論ですよ。

543 :仕様書無しさん:04/04/13 00:16
ステップ数の見積もりは結構出さされるなぁ
どっちかと言うと、

「納期までに割り当てられる作業量を調整するための言い訳」

だが。
結局難易度によって意味が違うから、根拠なんてないんだがな。


544 :仕様書無しさん:04/04/13 02:36
曖昧な見積りだって全く出さないよりまし。

545 :仕様書無しさん:04/04/13 02:54
結局のところステップ数は、目で見えない何らかのものを
「推測する目安」にはなり得ると思うが、
そんな数字で実績だのを評価するような運用じゃ
実態に則さないし、水増し等のひずみも出る。

そんな話じゃないのか?

546 :仕様書無しさん:04/04/13 08:29
実態に則した結果がでるように調節を続けるしかないんでは?
それがステップ数だかファンクションポイントだか知らんが。

547 :仕様書無しさん:04/04/17 20:01
おまいらの会社では仕様書に文章が書いてありますか?
漏れの会社ではスクリーンショットの束を指して「仕様書」と言いますが。


548 :仕様書無しさん:04/04/17 21:01
画面仕様書の一部にスクリーンショットが含まれるのは不思議ではないが
何の仕様書なんだ?

549 :仕様書無しさん:04/04/17 21:19
>547
完成してから全画面スクリーンショットとっているの?

550 :仕様書無しさん:04/04/17 21:22
>>547
画面を見れば判るような事は文章で書いてあります。

551 :仕様書無しさん:04/04/17 22:00
>>550
GUI仕様書。

左上50px 50pxに高さ36px 幅100pxでユーザ名入力のテキストボックス。
ユーザ名の位置から30pxあけて同じ高さ、幅でパスワード入力のテキストボックス。
左上100px 100pxの位置に高さ36px 幅70pxでOKボタン、
そこから20pxあけて同じ高さ、幅でキャンセルボタンがある。

見たいな感じか

552 :仕様書無しさん:04/04/17 22:03
ソースコードが汚いだけなら追うのがしんどいだけだからまだいい。
矛盾がのこったままの仕様をもとにプログラムを組まされるのはすごい苦痛。
もう辞めたい。


553 :547:04/04/17 23:17
画面レイアウトの仕様書として
VBでコントロールを並べただけのスクリーンショットでつ。
レイアウトはわかるんだけど、ボタンとかメニューが何の処理をするかが
まったく書いてないですよ?


554 :仕様書無しさん:04/04/17 23:30
>553
それ、仕様書じゃなくて画面イメージなのでは?


555 :仕様書無しさん:04/04/18 03:33
>>553
その画面だけ作れば良いんだよ。

556 :仕様書無しさん:04/04/18 09:51
機能を練りこまずに画面イメージを先に作らせるのって
どこでもあるんだ…。
うちのところも営業とかから話が来た管理職が
勝手に画面イメージをExcelで描いて客と話進めたりしやがんだよ…

無論機能を練りこんでいくとそんな雰囲気で作った画面イメージじゃ成り立たなくなって
喧々囂々…。

画面が無いと客もイメージ沸かないっていうのは分かるけど
その前に「システム化したいのは現状どういう流れで処理をしている事か」
を、ちゃんと解析させろよ…。
COBOLでファイルの中身を片っ端から印刷すりゃいい頃とは
話が違うんだよ…。

557 :仕様書無しさん:04/04/18 12:24
>>556
練りこまなきゃいけない機能にもよるけどね。
「COBOLでファイルの中身を片っ端から印刷すりゃいい」のと
大差ないシステム欲しがってるケース多いよ。

当然業務フローがきっちりわからなきゃだめなシステムもあるだろうけど、
単純なリプレースであればフローなんて変わらない。

558 :仕様書無しさん:04/04/19 09:51
>>556
漏れの経験だと、気張って業務フローの分析したら、大問題発覚してシステム作る
どころじゃ無くなったっていう事例があったな。
結構でかい案件だったんで、素直に言われた事だけやってりゃ良かったってチョット
後悔したよ。

559 :仕様書無しさん:04/04/19 10:12
>>558
デスマっちまうよりはマシかもわからんよ
それに、いい経験できたと思うんだが・・・

560 :仕様書無しさん:04/04/19 11:13
でかい案件潰した責任とらされて大幅減給、とかだったら確かに悔やむ気持ちもわかる

・・・が、実際は強行してもデスマになって大損害だして、結局大幅減給な罠

561 :仕様書無しさん:04/04/19 12:09
業務フローを書かずに、データモデルも書かずに、カーディナリティの分析もせずに基本設計ですって。 チームが20人弱いるってのに、意思疎通をどうやってはかれと。 使用の正しさをどうやって検証しろと。

562 :仕様書無しさん:04/04/19 12:19
成果物(作成するもの)にはすべて、
それを検証する方法が定義されている必要があるんだよねぇ

要件定義書しかり、仕様書しかり、コードしかり・・・

563 :仕様書無しさん:04/04/19 13:31
何気に>>558はいい仕事をしてるんではないかと。


564 :仕様書無しさん:04/04/19 13:47
先輩の書いたソースみたら全くインデントされてなかったよ。
行間隔が、1〜2行開いてる。
コメント一切なし!


565 :仕様書無しさん:04/04/19 14:02
ソフ開午後Uのアルゴリズム、





失望した。

566 :仕様書無しさん:04/04/19 14:07
>>565
自分の能力に?

567 :仕様書無しさん:04/04/19 14:13
>>565
あんたがちゃんと事前調査をしていれば
高度情報処理技術者試験を受けているはずじゃないのか?

568 :仕様書無しさん:04/04/19 16:02
あんな小学生でも思いつくような探索アルゴリズム。



なめてんじゃねーよ!


しかも、スタック使って失敗してやがるしwww


だいいち最短距離求めるために、関係のないエリヤまで全部マーキングしていくこと自体
パフォーマンスの面で問題あるだろよ。

数学的に考えるならとりあえず始点から終点まで直線引いて、
間の障害物の形状を分析するのが一番速いと思う。

569 :仕様書無しさん:04/04/19 17:02
一般的な経路探索法に関する知識に疎い俺が言うのもなんだが、
A* とか、そういう別の使った方がいいんでないかい?

まあ、スタック使って失敗はあんまりだな。
簡単なメモリ管理すらできてないってことだよな。

570 :仕様書無しさん:04/04/19 17:32
>>568
お前が午前で足きり喰らったのは分かったからおちつけ

571 :仕様書無しさん:04/04/19 19:23
>>569
そういう、スタックで大失敗してるアフォな問題が出たんだよ。
今年のソフ開に!

572 :仕様書無しさん:04/04/19 19:29
お前ら自分のバグは許せても、人の失敗には粘着しそうだな(w

573 :仕様書無しさん:04/04/19 19:30
去年みたいにSQLバリバリならそれはそれで文句いうくせにw

574 :仕様書無しさん:04/04/19 20:32
SQLはプログラミング言語じゃないしなー

575 :仕様書無しさん:04/04/19 22:27
>>574
俺的には、SQLとPerlの「プログラミング言語」度は同じくらい。

576 :仕様書無しさん:04/04/19 22:29
>>575
SQLはプログラミング言語じゃありません。
HTMLをプログラミング言語というのと五十歩百歩です。
PL/SQLは別。

577 :仕様書無しさん:04/04/19 22:36
>>576
プログラミング言語の定義って曖昧だよな。
とりあえず、おまえの定義を晒してみ。

578 :仕様書無しさん:04/04/19 22:40
でたな定義厨

579 :仕様書無しさん:04/04/19 22:44
>>577
とりあえずあらゆる問題を解くための汎用性は必要じゃない?

580 :仕様書無しさん:04/04/19 22:58
>>579
人間はプログラミング言語を定義できなくなりました。

581 :仕様書無しさん:04/04/19 23:10
http://e-words.jp/w/E38397E383ADE382B0E383A9E3839FE383B3E382B0E8A880E8AA9E.html
http://e-words.jp/w/SQL.html

582 :仕様書無しさん:04/04/19 23:12
>>577
ttp://www.duo.co.jp/column/06db_01.html
ttp://ja.wikipedia.org/wiki/SQL

583 :582:04/04/19 23:12
かぶった

584 :582:04/04/19 23:13
と思ったけど、よく見たらかぶってなかった。
まあいいや

585 :仕様書無しさん:04/04/20 06:34
SQLがプログラミング言語でないと主張する人は
Prologやlispはどうなのか?
己等が見慣れないものはプログラミング言語でないとか
述べやがったら怒髪天。
# おれ的には、コンピュータになにがしかの作業をさせるための
# 人工言語はなんでもプログラミング言語。おおらかに。

586 :仕様書無しさん:04/04/20 08:25
人間がデバッグしなきゃならないのは全部プログラミング言語。
おおらかに。

587 :仕様書無しさん:04/04/20 08:26
>>585
テキストに色を付けたり文字を大きくしたりして表示させる

HTMLはプログラミング言語

Wordもプログラミング言語

588 :仕様書無しさん:04/04/20 08:35
まあ待て、プログラミング言語かどうかが、そんなに大事なことか?

589 :仕様書無しさん:04/04/20 09:34
プログラム言語に必須の要素は以下の点だと思う。

・変数の定義とそれにたいするread/write/演算操作ができる
・条件分岐が出来る。
・ループ処理が出来る。

この定義に従えば、
HTMLはプログラミング言語ではない。
SQLはストアドを書けばプログラミング言語である。


590 :仕様書無しさん:04/04/20 10:29
ふと

もしPrologで業務プログラム組んであったら即辞めるっつーか逃走するな…

いやまぁ読めないわけじゃないけど…

591 :仕様書無しさん:04/04/20 10:50
チューリングマシンと等価な演算が実現不可能なのはプログラミング言語じゃない
したがって正規表現はプログラミング言語じゃない

592 :仕様書無しさん:04/04/20 12:03
>>591
それはわかりやすい。

593 :仕様書無しさん:04/04/20 15:18
JavaScriptは?

594 :仕様書無しさん:04/04/20 15:59
かなりお粗末な部類ではあるが、プログラミング言語だろう<JS

595 :仕様書無しさん:04/04/20 17:17
>>589
ってことは、DOSのバッチファイルも含まれそうだな

596 :仕様書無しさん:04/04/20 18:11
「プログラミング言語の定義」
あなたがそうだと思うものがプログラミング言語です。ただし、他人の同意を得られるとは限りません。

597 :仕様書無しさん:04/04/20 18:48
>596
誰か言うと思ってた。

598 :仕様書無しさん:04/04/20 21:02
>596
俺的には犬猫の鳴き声聞いてもそうは思わんが、
虫の鳴き声はプログラミング言語っぽいと思う。

599 :仕様書無しさん:04/04/20 21:33
>>587
HTMLが表示処理をしているのではない。
表示しているのはあくまでブラウザなのであり、
HTMLはどのように表示するかを指定しているだけだ。

600 :仕様書無しさん:04/04/20 21:59
>どのように表示するかを指定

違う。文書にどのような論理的意味が存在するかを示しているだけ。
それをどのように表示するかは、極端に言えばブラウザが好きにやっていい。

601 :仕様書無しさん:04/04/20 22:46
>>599
恥ずかしいヤシ発見!
したり顔で「Pコマンドは改行をするコマンドだ」とか
言っちゃうんだろうな(w

602 :仕様書無しさん:04/04/20 22:48
>>601
もまえさんも十二分に恥ずかしいと思われ

603 :仕様書無しさん:04/04/20 22:52
以下このスレは恥ずかしい>>599を晒すスレになりました。
外の用途では使用しないように。
とくに、>599。

多数の賛同をこの提案には得られると思う。
いや、反対するのは599くらいであろう。
なす大好き。

604 :仕様書無しさん:04/04/20 23:20
プログラムが処理をしているのではない。
処理しているのはあくまでハードウェアなのであり、
プログラムはどのように処理するかを指定しているだけだ。

605 :仕様書無しさん:04/04/20 23:23
>>603
お前自滅するタイプだな。

606 :仕様書無しさん:04/04/20 23:30
デグレがでまくるソースコードだな。

なにしろデグレなんてクソみてえなプログラム見たことすらなかった
からな!アフォアフォアフォ


607 :仕様書無しさん:04/04/20 23:31
ハードウェアが処理をしているのではない。
処理しているのはあくまで小人さんなのであり、
ハードウェアは小人さんの住処を提供しているだけだ。

608 :仕様書無しさん:04/04/20 23:33
[デグレ]

デーモン小暮の略。

[プログレ]

609 :仕様書無しさん:04/04/21 01:17
なんかそんなスレどっかにあったような……
[プログレ]
プロの画家にしか使うことを許されない、絶妙至極な灰色。

[Prolog]

610 :仕様書無しさん:04/04/21 02:10
[Prolog]

デスマが始まるきっかけ。
中途半端な仕様書のこと。

[dead end]

611 :仕様書無しさん:04/04/21 02:34
[dead end]

死こそ解放。

[スレ違い]

612 :仕様書無しさん:04/04/21 02:39
[スレ違い]

自治厨の切り札

[ぬるぽ]

613 :仕様書無しさん:04/04/21 02:48
[ぬるぽ]

2chを覚えてしばらく経った自称中級者がやたらと使いたがる言葉。
吉野家における「つゆだく」のようなもの。

[ポインタ]

614 :仕様書無しさん:04/04/21 10:49
あれ?なんでここ知ったかぶり辞典になってんの?w

>>605
オマエモナw

>>603
何が「以外と多い」んだ?


615 :仕様書無しさん:04/04/21 10:51
[ポインタ]

科学特捜隊が使用する車両

[終了]


616 :仕様書無しさん:04/04/21 11:13
[終了]

自治厨の切り札

[無限ループ]

617 :ヽ(´ー`)ノ ◆.ogCuANUcE :04/04/21 11:43
Perl で書かれた CGI が重いから、Java で似たようなサイト作ってくれって頼まれたんだが、
// なんかもう、その時点で嫌な予感がしてたんだけど。

$var_1435_1213 = '....';

エエエェェェ(;´Д`)ェェェエエエ

どうも、1435 がファイル名(に対する連番)で、1213 が変数名(に対する連番)らしい。

前にこの CGI をメンテしてた人の努力の結晶っぽい後付けの仕様書がある。
この仕様書を元に一から書き直した方が早いんじゃないだろうか……。

ちなみにその人は逃げたらしい。ケシカランとか言ってたが、そりゃ逃げたくもなるだろうよ……。

618 :仕様書無しさん:04/04/21 11:51
>>617
Perl->Javaなら、素直に書き直せよ。

619 :仕様書無しさん:04/04/21 13:09
>>617
その種の命名はインテリジェントコードと呼ばれるやつだ。皮肉な名前だが
俺も「書きなおし」したほうが良いと思う。規模に左右される問題では無いな。
「書きなおし」を正式に認めさせることが出来れば。だが

620 :仕様書無しさん:04/04/21 17:58
ぬるぽってマ板の用語かと思ってたんだけど、
2chの他板でも通用するんだー。
へぇへぇへぇ。
マ、ム以外の板あんまりみないから…

621 :仕様書無しさん:04/04/21 18:20
>>620
http://news.2log.net/mass/archives/blog74.html


622 :仕様書無しさん:04/04/21 19:06
>>621
>警備やマスコミの方々を悩ませた謎のプレート。

2ch のぬるぽスレ住人でも悩む。

何で???


623 :仕様書無しさん:04/04/21 19:38
ぬるぽスレなんてものがあったのか
いったいどんなスレだ

624 :仕様書無しさん:04/04/21 19:49
実体がないから参照できない・・・と。
もまえら引き篭もってないで外に出て来い・・・と。

625 :仕様書無しさん:04/04/21 20:38
MS-DOSにMS-Cなんて使ってたころは、よくぬるぽに書き込んで、
終了するときに "Null pointer assignment" なんて食らってたのを思い出した。

626 :仕様書無しさん:04/04/21 23:25
概要設計書があまりにも「設計ごっこ」だった。
基本設計フェーズだが、最低限これで概要設計レベルだろという程度に記述してレビューしてもらった。
おっさんたちは一様に「もう詳細設計できてるんじゃないの」とか言いやがった。

あいつら設計が何をすることだと思ってるんだ。

627 :仕様書無しさん:04/04/22 10:06
実装も出来ない連中に、実装に何が必要かなんて理解できるわけもないさ。


628 :仕様書無しさん:04/04/22 13:35
>>625
どこで書いてるかわかんなくて、強引に出ない様にした事があった…
いまは怒られるからすぐにわかるが。



629 :599:04/04/22 22:18
>>600
一応言い訳しときますが、そのへんのことは知ってますよ。
マジ、ホントだって。
「表示しているのはあくまでブラウザ」とも書いてるわけで、
そのへんをくんでくだされ。なんとか。
ですので、>>601みたいなことはありません。さらさないでください。

630 :仕様書無しさん:04/04/22 22:44
まあ、みんな揚げ足を取ってるだけだから。

631 :仕様書無しさん:04/04/23 20:55
変数名が全部大文字でしかも必ず3文字。
読みにくいし、コメントもないから何の用途で使ってるかわからん。

632 :仕様書無しさん:04/04/23 22:29
>>631
せめて1変数を1つの目的で使ってりゃマシなんだけどねぇ。。
複数の目的で兼用してたり、あちこちの処理で無造作に値を
変えられてると、なかなかつらいよ..._| ̄|○

633 :仕様書無しさん:04/04/24 00:49
TEMPとTEMP1とTEMP2とTMPとTMP1とIとIIとJが絡んだCOBOLソース。
今後の修正を任されそうになったので
「俺は『デジタルドカタ』じゃ無いんで」と言って突っ返した。
こんなシステムの責任取れるかボケ。

634 :仕様書無しさん:04/04/24 00:55
>>627
名ゼリフ ハケーン!

635 :仕様書無しさん:04/04/25 09:05
#define const

636 :仕様書無しさん:04/04/25 12:16
>>635 const_cast 知らん人が書いたのかなぁ

637 :仕様書無しさん:04/04/25 12:33
constのせいでコンパイルとおんない時に切れた人がよくやる

638 :仕様書無しさん:04/04/25 12:50
>637
で、後々のメンテする人がここに書き込む、と。


639 :仕様書無しさん:04/04/25 13:06
1関数に150行以上突っ込んでるのをみると嫌になってくる。
150でも多いようなきもするがな。


640 :仕様書無しさん:04/04/25 13:25
1関数で2000行なんて、ざらに見かけますけど(w
自分が見た最高は3000行こえてたなー。

641 :仕様書無しさん:04/04/25 13:29
実際に見たなかで最高は一万
聞いたなかで最高は五万

642 :仕様書無しさん:04/04/25 13:29
ttp://www.pro.or.jp/%7Efuji/mybooks/cdiag/cdiag.10.1.list
なんて639の人が見たら悶絶するでしょうな。



643 :仕様書無しさん:04/04/25 13:40
今時関数の行数なんてどうでもいいが、
カット&コピーだらけだったりするともう嫌。

644 :仕様書無しさん:04/04/25 13:57
カット&ペーストとかなしで、2万行の関数なら見たことあるよ。
ツールの吐き出したコードだけど。

645 :仕様書無しさん:04/04/25 14:14
>>644
>ツールの吐き出したコードだけど。
それならちょっと許せるかも... ツールは馬鹿だからなっ!
だけど そのツールを作った奴のことを 私は許せない!

それと 何千行もある 関数って コンパイラが
拒否するんじゃなかったっけ? これは昔の話か?

おおらかな時代になったもんだ....


646 :仕様書無しさん:04/04/25 14:25
>>645
僕はJavaでメソッドの長さが65535行を超えていますとかいう
エラーを出したことがありますよ

647 :639:04/04/25 14:37
>>642
いや、悶絶はしないけど、読みたくない。

俺の最高は、2千かな。
自分で書いたのは千行くらいだけど、書きたくないね。
修正の時大変なんだもん。
特に他人が書いたものだと(TДT)


648 :仕様書無しさん:04/04/25 14:40
ツールでコード生成するのは問題ないが、
GenerationGapを考えてない奴は激しく糾弾する。

649 :仕様書無しさん:04/04/25 15:06
ツールに罪はないだろう。っつうかツールが吐いたコードに直接手を加えて
コピペするのがツールの使い方を間違っているっつうか。
手を加えざるをえないならツールの罪だろうけど。

650 :仕様書無しさん:04/04/25 15:52
>>642
見てるだけで、気持ち悪くなった

651 :仕様書無しさん:04/04/25 16:12
HTMLは一種のフィルターだよ。

652 :仕様書無しさん:04/04/25 16:27
>>650
あなたは正常です。
ところが世の中には642のようなコードをかくことを自慢している
勘違い野郎や自称天才プログラマーがけっこういるんだよな。


653 :仕様書無しさん:04/04/25 16:45
このまえ「ソースコードが大きすぎます」ってエラーでちゃった。
なんでかなー?

654 :仕様書無しさん:04/04/25 16:54
1つの関数に何行くらいのコード書く?
漏れは100〜120位に出来るだけ抑えているが。


655 :仕様書無しさん:04/04/25 16:55
ものによる

656 :仕様書無しさん:04/04/25 17:30
>>654
100なんて長すぎるだろ
50超えたら分割すべきじゃないかと思え

657 :仕様書無しさん:04/04/25 17:36
>>654
この前、実測してみた。総行数四万で、
23.6だったな。

658 :仕様書無しさん:04/04/25 17:56
50越えたら分割ってアフォか
必要なら分割だろ

659 :仕様書無しさん:04/04/25 18:11
モジュールの強度と結合度の話をしてイイか?

660 :仕様書無しさん:04/04/25 18:13
いいんでないの

661 :仕様書無しさん:04/04/25 18:16
>>659
オブジェクト指向に構造化の思想はいらない。

662 :仕様書無しさん:04/04/25 18:22
ええ?なんで? >>661

663 :仕様書無しさん:04/04/25 18:31
>>658
その必要性を判断する基準の中に行数も入っているという話だろ 低脳



664 :仕様書無しさん:04/04/25 18:33
>必要なら分割だろ
「どれくらい長過ぎる時に、分割は必要か?」って話だろーが。

665 :仕様書無しさん:04/04/25 18:36
>>661
「既存のものを貶めて、新しいアプローチを提唱する」というマーケティング戦略に乗せられているぞ。
オブジェクト指向は構造化の発展形だ。
換言すれば「構造化はオブジェクト指向の基礎」なんだ。

666 :仕様書無しさん:04/04/25 18:42
>>658みたいな奴がこのスレを賑わすコードを大量生産してるんだろうな
頭悪そうだしw

667 :仕様書無しさん:04/04/25 18:58
ある行数越えたら分割なんて思考停止がこのスレのコード量産しているんだろ。
はやく気付や池沼

668 :仕様書無しさん:04/04/25 19:02
1.重複したコードがあってはならない
2.最小限のクラスからなるべき
3.最小限のメソッドからなるべき

基本中の基本だな。

669 :仕様書無しさん:04/04/25 19:06
>>668
今時XPですか(プゲラ

670 :仕様書無しさん:04/04/25 19:12
>>667
プロのアフォとお見受けしました
で、どういう基準で関数の分割の必要性を判断するんで?


671 :仕様書無しさん:04/04/25 19:14
強度と結合度だろ

672 :仕様書無しさん:04/04/25 19:17
なんでもかんでも分割ってアフォ以外の何物でもないからな。
可読性悪くなるし。
5行以内の関数、量産してるんじゃねえよ。
お前だよ、お前。引き継ぐこっちの身にもなれ。

673 :仕様書無しさん:04/04/25 19:26
>>668
> 1.重複したコードがあってはならない

int add(int a, int b)

この関数以外加算禁止。


674 :仕様書無しさん:04/04/25 19:28
おれは「コードが明瞭に頭の中にイメージ出来るようになったら分割を終了しろ」
と教わったが

675 :仕様書無しさん:04/04/25 19:49
>>640-641
なんかドラゴンボールみたいでかっこいいな

676 :仕様書無しさん:04/04/25 20:03
>>674
よーし、昼飯はスパゲッティだ!
分割終了。


677 :仕様書無しさん:04/04/25 20:14
Aという処理とBという処理が必ずペアで行われる場合に、ソースが長くなるからっつって
Aを定義し、Bを定義し、「A→B」と実行するCを定義するのはナンセンスだと思う。

単体でA、Bを呼び出す事が今後の変更などで想定されるとかならばさておきな。

678 :仕様書無しさん:04/04/25 20:17
>>677
>>671

679 :仕様書無しさん:04/04/25 20:33
俺の場合は、具体的な処理がイメージできる簡潔な名前を関数に
付けられるかどうかを一つの基準にしてるな。
長すぎる関数は、機能が詰め込まれ過ぎで名前が抽象的になりすぎる。
短すぎる関数は、機能が小さすぎて意味のある名前をつけられない。


680 :仕様書無しさん:04/04/25 20:52
>>677
そうすると
初期処理()
メイン処理()
終了処理()
つう分け方もナンセンスになってしまうのか?

681 :仕様書無しさん:04/04/25 20:56
> 長すぎる関数は、機能が詰め込まれ過ぎで名前が抽象的になりすぎる。
こっちは同意だが
> 短すぎる関数は、機能が小さすぎて意味のある名前をつけられない。
そんなことないだろ

機能別に分割した結果、関数内の処理がほんのわずかになることは
当然ありうるし、関数が小さいから悪いということにはならない


682 :仕様書無しさん:04/04/25 20:57
なにかしら値を渡さないならそれでも良いかと

683 :仕様書無しさん:04/04/25 21:05
メソッドのコードの行数が少ない設計だと、
圧縮のための圧縮が起こり、コミュニケーションが損なわれてしまう。

>>680
大概は実装上で分ける意味があるわけだが、それがないならナンセンス。

684 :仕様書無しさん:04/04/25 21:22
>>677
Chain of Responsibility

685 :仕様書無しさん:04/04/25 21:42
俺は20行越えたら長いと感じる。
オブジェクト指向だと委譲メソッドが増えるからなおさら。

686 :仕様書無しさん:04/04/25 21:51
20行は、さすがに短すぎだと思う。
それとも、かなーり上位のコードか?

687 :仕様書無しさん:04/04/25 21:53
動きをトレースする際に、「いくつの状態」を「何ステップに渡って」覚えておかなければならないか、
が読みやすさのキーだと思われ。
例えば↓の例ではAは約千行、Bは高々十数行だが、どちらがより読みやすいと思う?

 A( ) {
  func001( fp );
  func002( fp );
    :
  func999( fp );
 }

 B( ) {
  int hoge = hoge_init( );
  if( hoge>0 ){
   int moge = moge_init();
   if( moge>0 ){
    sage();
    moge_term();
   }
   hoge_term();
  }
 }


688 :685:04/04/26 01:18
>>686
C 屋や関数呼び出しのコストをケチりたい C++ 屋ならわからんでもないが
それ以外では最近の主流はコメントのように読めるプログラミングだぞ。

689 :(゜Jし゜):04/04/26 02:31
すいませんすいません。
仕様書どおりに作ったら1関数1000行くらいになりそうです。
仕様書上でGOTOっぽい制御が容赦なく行われており、
ついでに設計者は逃げて現場にいません。
どうしたらいいですか!?

690 :仕様書無しさん:04/04/26 02:39
>>689
「リーダーに相談する」
「可能なら勝手に仕様書を書きなおす」
のどちらかだなぁ。ゴリオシされるようなら逃げるのが吉

691 :仕様書無しさん:04/04/26 02:40
>689
首吊り用の縄と練炭が欲しければ用意してやるよ。

692 :仕様書無しさん:04/04/26 07:45
>>689
関数単位の処理まで他人が設計するような仕事のスタイルがダメダメ


693 :仕様書無しさん:04/04/26 09:20
普通、関数は処理内容で分割するだろ・・・
一定行数越えたら分割って、あほか?

分割するのは必要があって分割するのであって、分割する場所を
わざわざ探して、無理矢理一箇所でしか使われないような短い関数
大量に作る必要なんか全く無い。

694 :仕様書無しさん:04/04/26 09:27
>>693
基本的には間違ってはいないが。
あなたは、少し上に書かれている「強度と結合度」について理解したほうがイイな

695 :仕様書無しさん:04/04/26 09:49
>>694
ああ、お前、そんなのまだ信じてるんだ。

696 :仕様書無しさん:04/04/26 09:59
行数が100とか20とかで長いなんて・・・
よほど簡単な仕事しかしてないんですねぇ。うらやましい。

697 :仕様書無しさん:04/04/26 10:06
20は短すぎ。
100ぐらいで、「ああ、整理したいなあ」と思い出す。
200を超えると、「何が何でも、整理しなくては!」と切実に思う。

でも、めんどくさいから、やんない。

698 :仕様書無しさん:04/04/26 10:12
「100が長い」のは普通だなあ
「20が長い」という世界は遭遇したこと無いけど

>>696
自分の経験年数さらしてみなさい

699 :696:04/04/26 10:33
まだPG暦5年くらい。

・・・いや、100が長いってマジで言ってる?
俺が作った画像処理用の関数は1000行超えてるが、
ここまでくれば確かに長いとは思う。でも、分割したいとは思わない。

・・・長いかどうはか主観が入るとしても、長いから分割しよう、てのは
ちょっとどうかと思うけどねぇ。

700 :仕様書無しさん:04/04/26 11:10
たった五年か(プ


701 :仕様書無しさん:04/04/26 11:20
五年もやってそれか(プ

702 :仕様書無しさん:04/04/26 11:35
もう煽りあいでわけわかめ

703 :仕様書無しさん:04/04/26 11:47
696
次に触る人のことも考えな。
読むのが面倒なんだよ。


704 :仕様書無しさん:04/04/26 11:47
>>703
読む能力のない奴は、PG辞めろ

705 :仕様書無しさん:04/04/26 11:53
「読めない」んじゃなくて「読みたくない」んだが。
日本語読む能力のない奴は、人間やめろ。

706 :698:04/04/26 11:59
>>699
「100が長い」というのは真面目に言っているよ。「主観が入る」ってのは確かだけど、(一般論みたいだが)
「自分が作るときに把握できる長さの上限」は「他者の作成したものの把握可能な長さの上限」
というのは違うんだ。当然、前者は後者より長い。
自分の作ったプログラムを、その寿命が終わるまで保守するというのは通常、現実的でないのだから、
長さというのは、後者に合わせなくてはならない。
#例外はある。情報的強度を持つ関数だ

>長いから分割しよう、てのはちょっとどうかと思うけどねぇ。
書いてしまったものを(再コード化の手間を省くために)コードを物理的に分割し、論理的に複数の関数にするという作業は、
私も支持しない。

#本当は行数だけを判断基準にすることは誤りだ。「識別子の種類数」、「分岐の(ネストの)数」、「変数間の依存関係」
#等々のいろいろな判断基準がある。
経験年数をさらしてくれたので、自分もさらしておこう。25年だ

707 :仕様書無しさん:04/04/26 12:02
>>705
「読めない」事を「読みたくない」と脳内変換して
自己満足に浸る奴は、さっさと首吊って死ね。

708 :仕様書無しさん:04/04/26 12:19
>>699
長いから分割しよう、じゃなくて、長くならないように書くべきだ、と思う。
1000 行越える前に、自分のコードに疑問持たなかったの?

>>707
> 読むのが面倒なんだよ。
これ、どう読んだら「読めない」になるんだ?
建設的な議論じゃなくて煽り合いがしたいんなら他のところ行ってくれ。

709 :仕様書無しさん:04/04/26 12:23
>>708
>長いから分割しよう、じゃなくて、長くならないように書くべきだ
俺もこの意見には賛成だな。

>>699
時間のあるときに自分の書いたコードじっくり見直してみてはどうかな?


710 :696:04/04/26 12:30
>706
若輩者あいてにマジメにレスして頂いてどうもです。

100行が長いか短いか、は、まあこの際置いておいて。、
他人の見やすいソース≠関数を細分化したソース、と考えるよ俺は。

確かに他人の作ったソースは読みにくいけど、それは関数の長さとは
直結しないと思うんだけどね。
いくら関数によって細かい処理がブラックボックス化されたとしたって、
結局その中身まできっちりチェックしなきゃまともにメンテできないわけだし、
その際に細かい単位であっちこっちに飛ばされる方がストレスが溜まるし、
その分け方如何で可読性は180°変わると思う。

短いほうがわかりやすいに決まっている。
でも、「わかりやすくする」ために短くするのならいいけど、どうも話の流れは
「短くする」ことが目的になってるようで、それは違うだろと。

711 :696:04/04/26 12:42
>708、709

んー、まあその関数は、インラインアセンブラ使って速度重視で書いてるって
いう理由もあったりするけど。

関数内で、

・テーブルや必要情報の初期化

横一行の処理
 ・横先頭の処理
 ・横中間の処理
 ・横終端の処理

これが縦の先頭、中間、終端と続く。

これらはすべて、微妙に違う処理になるのでまとめる事は不可。
先頭の初期化時に取得する情報は膨大で、引数で渡すのもナンセンス。
この関数でしか使わない情報をグローバル変数にするようなアホもできない。

長いことは認める。でも、必要だから長くなっているわけで、
短くすることを目的にしようとはどうしても思えない。
読みにくい分、コメント等をきっちり書いてカバーしてるつもりだよ。

712 :仕様書無しさん:04/04/26 13:04
>>708
昼休みに暇な奴だな。
飯食ったか?ちゃんとカルシウム摂れよ(プゲラ

713 :仕様書無しさん:04/04/26 13:54
俺、まだ、昼休みもらってない。


714 :仕様書無しさん:04/04/26 14:12
>>711
>・テーブルや必要情報の初期化
>横一行の処理

俺だったらこの辺は別関数に分けると思う。

もちろん、極限まで速度を重視しなければならない状況ならそうしない可能性はある。

>先頭の初期化時に取得する情報は膨大で、引数で渡すのもナンセンス。

構造体に突っ込んで参照渡しじゃダメ?

715 :仕様書無しさん:04/04/26 15:26
冗長な関数はアルゴリズムの不適合かあるいは不親切なコメントアウトかのいづれかであるかと。

716 :696:04/04/26 16:04
>714
いいのでは?こんな感じになるんだろうね。

func(){
 Init(Rec);

 Y1X1(Rec);
 Y1X2(Rec);
 Y1X3(Rec);

 Y2X1(Rec);
 Y2X2(Rec);
 Y2X3(Rec);

 Y3X1(Rec);
 Y3X2(Rec);
 Y3X3(Rec);
}

実際はもうすこしごちゃごちゃすると思うけど。
そりゃ、この関数内はスッキリするんだろうけど、プログラム全体で見て
読みやすくなってるとは思えない、という話。

717 :仕様書無しさん:04/04/26 16:23
長い短いで関数分けする香具師はアフォということで

718 :ヽ(´ー`)ノ ◆.ogCuANUcE :04/04/26 16:25
書き直しは認められませんですた_| ̄|○


719 :仕様書無しさん:04/04/26 16:47
イ`

720 :仕様書無しさん:04/04/26 17:10
>>718
南無


721 :仕様書無しさん:04/04/26 19:24
>>714
>俺だったらこの辺は別関数に分けると思う。
>
>もちろん、極限まで速度を重視しなければならない状況ならそうしない可能性はある。

可読性を考えたら速度重視のコード展開でも、
インライン展開やマクロやファイルのインクルードを組み合わせれば、
同じ動作を行うコードの分割は可能なはず。

関数化するのは、流用性と可読性の為の手法の1つなのだから、
言語に依存しない構造化(ファイル分割等)は有用だと思うのだが。

速度重視を言い訳にしてもC言語で1000行もの関数を書くのは正気じゃないぞ


722 :仕様書無しさん:04/04/26 19:24
>>714
>俺だったらこの辺は別関数に分けると思う。
>
>もちろん、極限まで速度を重視しなければならない状況ならそうしない可能性はある。

可読性を考えたら速度重視のコード展開でも、
インライン展開やマクロやファイルのインクルードを組み合わせれば、
同じ動作を行うコードの分割は可能なはず。

関数化するのは、流用性と可読性の為の手法の1つなのだから、
言語に依存しない構造化(ファイル分割等)は有用だと思うのだが。

速度重視を言い訳にしてもC言語で1000行もの関数を書くのは正気じゃないぞ


723 :仕様書無しさん:04/04/26 19:34
熱いな

724 :仕様書無しさん:04/04/26 19:59
これだけは言える。

業務ロジック部分において
何でこんな書き方なの、という問に対する返答の一発目が
「この方が動作が速いんです」
だったソースの9割はゴミ。

725 :仕様書無しさん:04/04/26 20:31
ちょっと待て。
なぜC言語で記述することが前提で語るんだ??
結局単一環境・単一言語の範囲でしか語れない
ヴァカかよ。COBOLerと同レベルだな(pu

726 :仕様書無しさん:04/04/26 20:36
WindowsSDK時代(非MFC)のウィンドウプロシージャは平気で数百行に
なってたと思うんだけど、たとえばあんな感じのswitch/caseとかで、
構造的かつ論理的に明確な形で長いのは認めてもいいんじゃあないの?

つか、短くても読みにくいコードは読みにくいんだよ!

727 :仕様書無しさん:04/04/26 20:46
速さは定量的に検証されていなければならない。

728 :(゜Jし゜):04/04/26 22:23
すいませんすいません。
結局件のC言語のソースは800行になりました。
一つの処理呼び出しでCSV形式のファイルを出力するんですが、
その制御とか項目が微妙に似ていたり、違ったりといった感じで上手く関数分割できません。
(自分も無能な末端のコーダなんで偉そうなことはいえませんが)

基本設計はCobolerで詳細設計はVBerだそうです。
早く逃げたい!

おまけ
その仕様書の一部
A項目=0でB項目=0の時、””を編集する。
A項目=0でB項目≠0の時、””を編集する。
A項目≠0でB項目=0の時、””を編集する。
A項目≠0でB項目≠0の時、””を編集する。

729 :仕様書無しさん:04/04/26 23:04
VBerって「ぶいばー」って読めばええ?

730 :仕様書無しさん:04/04/26 23:06
>>699
自分は、一つの関数が200行超えた時点で、長さにヤバさを感じる。
500行超えるようだったら、まず最初から構造を見直す。
1000行になる前に、そのコードは絶対破棄する。

731 :仕様書無しさん:04/04/26 23:14
>>728
大騒ぎしたわりにはあれだな。0一個足りなくね?

732 :仕様書無しさん:04/04/26 23:25
Perlだと80行で書けたりしない?

733 :(゜Jし゜):04/04/26 23:42
すいませんすいません。
PerlとかVBScript、PL/SQLみたいなもう少し使い易い言語なら半分位で済んだかも知れませんが、
何せC言語は慣れてないもので…。
でもDBのカラム数が300オーバーとか数値で扱えばいい項目でも何でもかんでも文字列で取ってたりするんで、
あんま変わらないかもしれません。

更におまけ
DBの列名
生年月日 → UmareDate
ユーザ名 → UserIDName
後、KubunとKbunとKbnが混在してたりして…

734 :仕様書無しさん:04/04/26 23:47
>729
ビーバー

735 :仕様書無しさん:04/04/27 00:08
>>729
ぶいびゃ〜

736 :仕様書無しさん:04/04/27 00:16
>>729
ぶばー

737 :仕様書無しさん:04/04/27 00:26
ISer は?

738 :仕様書無しさん:04/04/27 00:39
>>716
既に何人かにきつく言われてるとこ悪いが

func(){
 Init(Rec);

 for (int i = 0; i < 3; ++i)
  for (int j = 0; j < 3; ++j)
   Y[i]X[j](Rec);
}

こんな感じにできたらいいなあ、
とか思わないのかなあ?
(上記のままだと駄目かもだけど…)

739 :仕様書無しさん:04/04/27 02:21
>738
Y,X の初期化処理を書くのに、結局>716と同じ位の行数がかさむ悪寒。
それに Y[i]X[j]( Rec ) でどの関数が呼ばれるか判り辛くなるので、
漏れは>716のままが良いと思う。

あと>716自身は読みやすくならんと述べているが、それは Y1X1〜Y3X3 の中身の
書き方次第だと思われ。
例えば↓のような書き方は最悪。
・統一規則で命名されてない、別々のファイルで定義する。
・Recを延々とバケツリレーした挙句、最深部でメンバの値をこっそり変える。
・const を適切に使用しない。

740 :仕様書無しさん:04/04/27 07:09
>>730
500行超えるまで見直さないんかい!


741 :696:04/04/27 09:08
まだ続いてたのか。
ちなみに、記述言語はDelphi。

うーん、まあ、きっと俺の関数の書き方には問題があるんだろうね。
Delphiだけどソース出すから。どうすりゃいいか考えてみてよ。

742 :696:04/04/27 09:22
直リンはまずいかな・・・

http://v.isp.2ch.net/up/30e5cace5ba8.txt

http://up.isp.2ch.net/upload/c=03okari/index.cgi

うpしときました。興味のある方はどうぞ。

743 :仕様書無しさん:04/04/27 10:26
興味ないからイラネ

744 :仕様書無しさん:04/04/27 10:42
Delphiはよめねーなー

745 :仕様書無しさん:04/04/27 11:30
>>742
インラインアセンブラの入ってるようなソースを持ち出してくるとは、卑怯なり。

746 :696:04/04/27 11:35
えー、711でもそう言ってるし・・・

747 :仕様書無しさん:04/04/27 12:50
話はがらりと変わるが、さっき後輩のPG読んだら、変数がローマ字だったよ。
こんな感じ、int kotae; とか、int adoresu; とか泣けてきたよ。

*)実際のPGはCじゃないので



748 :仕様書無しさん:04/04/27 13:04
adoresuはちょっと泣けるがkotaeとかは時々やっちゃったりするなぁ。
無理やり英語にすると混乱してくる。

749 :仕様書無しさん:04/04/27 13:21
>>742のソース・・・
>>716の形式でまとめられている方が
死ぬほどコード追っかけるのが楽だと思う俺は5年目では失格でしょうか?

引き継いだとしたら、できれば触りたくない関数になるよ

750 :仕様書無しさん:04/04/27 13:31
保守age

751 :仕様書無しさん:04/04/27 13:59
>742
 インラインアセンブラで書いてる部分だけ切り出して別関数にするくらいしか思いつかんな。
 後は緑・赤・青の3要素の処理を関数化する(オフセットだけの問題だからまとまる)
とかかねえ。


752 :仕様書無しさん:04/04/27 17:19
delphi じゃ評価しようがないが、取り敢えず
>>711
>コメント等をきっちり書いてカバーしてるつもりだよ。
コードを見れば判るような無駄なコメントは
書かない方がマシ。

753 :仕様書無しさん:04/04/27 17:55
>752
そんなに無駄なコメントあるか?
俺にとって無駄なコメントって、

i = a; // iに代入

こういうのなんだが・・・

754 :仕様書無しさん:04/04/27 17:57
行数の65%がアセンブラじゃないか
>まあその関数は、インラインアセンブラ使って速度重視で書いてる
「アセンブラをdelphiで包んでる」と表現した方が正しいと思うぞ。

ところで実感として、すべてdelphiで書いても速度は120%くらいにしかならないと思うんだけど、どう思う?

755 :仕様書無しさん:04/04/27 18:17
>>753
>XOR ebx,ebx // 初期化
とかかな?
まあ、神経質な奴は気になるんだろう。


756 :仕様書無しさん:04/04/27 18:40
>752は、無駄なコメントを省いてるつもりで必要なコメントを書いていないに一票


757 :仕様書無しさん:04/04/27 19:22
アセンブラ以外は全部コメント

758 :仕様書無しさん:04/04/27 21:14
>>740
てゆーか、500行超えたことないし。
おそらく、今まで300行を超えた関数は書いたことがない。

759 :仕様書無しさん:04/04/27 22:13
>>742
速いとか遅いとかいう以前に、BiLinearの拡縮(と平行移動?)で1KLはどーかと思うぞ。

760 :仕様書無しさん:04/04/27 22:35
>758
ケースバイケースだろ。威張るところじゃないぞ。

761 :仕様書無しさん:04/04/28 02:05
dictionary関数の乱用をみたときにやめようと思った。

762 :仕様書無しさん:04/04/28 08:13
>759
ほら・・・こういうふうに、速度重視って言ってるのに、それよりも長さにこだわるバカがいるから
行数の話になると荒れるんだよなぁ

763 :742=696:04/04/28 09:27
>754
まったく同じ処理をアセンブラ使わずに書いたソースと比べると、
拡大・縮小とも、倍近い速度で処理できるようになってる。
Delphiの最適化がしょぼいのか、俺のソースがしょぼいのかは分からないけど。
まあ、もっと高速にできる人もいるだろうけど、MMXとか使わない限り
俺にはこれが限界・・・

あと、そのアセンブラで書いてないソースは450行くらい。

764 :仕様書無しさん:04/04/28 11:33
高速化を考えている人はオブジェクト化とかモジュール化とかは考えないの?

765 :仕様書無しさん:04/04/28 11:46
>>764
場合による。限界イッパイイッパイまで最適化するならモジュール化しない。
というより、モジュール化して動くものを作った後、高速化しながらほどいていく感じ。

766 :仕様書無しさん:04/04/28 12:18
高速化を追求してくと、ループを展開したりとかって話にまでなるしね。
呼び出しのコストを考えれば、わざわざやるもんでもないだろう。

767 :仕様書無しさん:04/04/28 13:56
関数名で1行、関数の中括弧開いて1行。閉じて1行。
ローカル変数の宣言で3行(ぐらい)。
変数宣言とコードの間に1行。
forループがあったりして、開いて閉じて、合計2行
if文があって、開いて閉じて、elseの分も開いて閉じて、合計4行
return に1行。

残り6行にコードを詰め込むのか……俺には20行は無理すぎる……orz

768 :仕様書無しさん:04/04/28 16:07
行数稼ごうと思うと、短いif文をelseまで含めて一行で書いたりするんだろうな。
あれ、見にくいから嫌いなんだけど。



769 :仕様書無しさん:04/04/28 17:29
>>768
複数行のものを一行にまとめたら行数稼げませんよ?

770 :仕様書無しさん:04/04/28 17:39
実際に辞めた奴居ないだろ?

771 :仕様書無しさん:04/04/28 20:22
保守age

772 :仕様書無しさん:04/04/29 09:43
1000行くらいのプログラムだけど
そのうちの800行くらいがコメント

ソースを修正するときに、古いところは、コメントで残すきまりなので
残骸のなかに、本物のコードが少しずつのこってる

めちゃ読みづらい


773 :仕様書無しさん:04/04/29 09:52
コボリッシュだな

774 :仕様書無しさん:04/04/29 10:54
CVSとか知らなさそう >>772

775 :仕様書無しさん:04/04/29 10:56
>>772
そんなのコメントだけ取り除くスクリプト作れば良いだけの話だろ?
逆にコメントに対して「読みづらい」と文句垂れてる>>772の方が
以上だと思うけどね。

776 :仕様書無しさん:04/04/29 11:09
コメントは残す決まり、という文が読めないらしいな・・・文盲め
貴様みたいな無職には、世の中のしがらみなんぞ理解できないんだろうよ

777 :not775:04/04/29 11:49
>>776
「古いコードをコメントとして残す決まり」を、世の中のしがらみ
と表現し、(必要悪の様に)しかたの無いことと思ってはいけない
そんな決まりを決めた奴が愚かであるだけだろ
まず、規約を定期的に改定するというメカニズムを作れ


778 :仕様書無しさん:04/04/29 11:58
>>776みたいに何も考えずに人に言われた通りの仕事するだけの馬鹿こそ
社会の最大の癌


779 :仕様書無しさん:04/04/29 12:06
まぁ学生のうちはそうやっていきがってるのが仕事だ。

780 :仕様書無しさん:04/04/29 12:42
もしくはこの春入社した新人なのかもな。
それが当然と思ってないからこのスレに書き込んでる、と言う事も理解できない
低脳の新人なんて、先が知れてるが。

まあ、許せなきゃ辞めればいいし、そのコード規約を改定できるような権力を持てるまで
何年かかるかしらんががんばるのもいいんじゃないの?


781 :仕様書無しさん:04/04/29 12:50
能力がない奴ほど、環境のせいにしたがる。
権力もてるまでなにも努力しなかった奴が、いつのまにか権力を持つようになって・・・
まあ流転するってわけだよ。

782 :仕様書無しさん:04/04/29 13:37
コメントは日記ではない。

783 :仕様書無しさん:04/04/29 13:49
実際に規約を変えるのは結構難しかったりするけどなー
特に、過去の問題解決のために導入された規則だと。

784 :仕様書無しさん:04/04/29 13:58
問題解決のメリットと他の弊害のデメリットを比較検討して結論を
出せばいいだけのこと

785 :仕様書無しさん:04/04/29 14:53
>775
誤変換してるお前さんのほうが異常・・つーか、阿呆っぽい

786 :仕様書無しさん:04/04/29 16:01
>775 を弁護するとだ、読むときだけスクリプト通したテンポラリを読めと
言ってるんだと思うぞ。
というか漏れもよくやる。

787 :仕様書無しさん:04/04/29 16:07
やめた先輩のお下がりのPC使ってるんですが、
「きた」が「キタ━━━━(゚∀゚)━━━━!!」に変換されて困ります

788 :仕様書無しさん:04/04/29 16:26
>>787
変換辞書を削除しろ。次!

789 :仕様書無しさん:04/04/29 17:16
>784
組織によってはきっちり提案書作って上申しても
「これまでの方法で問題なかったんだから
 このままで良いじゃん」
で潰されることもある

790 :仕様書無しさん:04/04/29 17:26
>>786
それを言っちゃあ>>776が可哀相すぎw

791 :仕様書無しさん:04/04/29 17:47
使えない新人がいきがってるスレはここですか?

792 :仕様書無しさん:04/04/29 19:06
今会社で新人君達にCを教えてるのですが、
クイックソートのコードを作らせたら、
ソースファイル名がkuikkusouto.cの新人君がいました。
みんな四大卒なんですが...

793 :仕様書無しさん:04/04/29 19:24
君を笑わせたかったのだろう。

794 :仕様書無しさん:04/04/29 19:31
hogehoge01(int hoge01,int hoge02){
return(hogehoge02(hoge02,hoge02));
}

795 :3lj ◆9ckA/bJw7Q :04/04/29 19:51
>>792
最初はそんなもんなんじゃないの?

796 :仕様書無しさん:04/04/29 20:23
>>795
そんなやつどこまで行っても同じだろw

797 :仕様書無しさん:04/05/01 03:35
何気に>>782は名言の悪寒・・・

798 :仕様書無しさん:04/05/01 07:23
コメント欄に書く履歴は日記としても読めるものを書け

799 :仕様書無しさん:04/05/01 11:39
>>795
最初は中卒レベルなんですか?

800 :仕様書無しさん:04/05/01 11:49
中卒に失礼だろ

801 :仕様書無しさん:04/05/01 12:08
つづりがわからない、て事ならわかる。
ただ、それを調べるんじゃなくてローマ字で書いちゃう思考の持ち主って時点で
そいつがどう料理しても使えない人間だってことは確定なんだよなー。

・・・まさか、日本語だとは思ってないよな?
soutoってあたり、ちょっと危険なにほひもするが・・・

802 :仕様書無しさん:04/05/01 13:02
>>801
クイック相当

803 :仕様書無しさん:04/05/01 13:05
クイック掃討

804 :仕様書無しさん:04/05/01 13:15
>>803 ソレダ!!

805 :民明書房:04/05/01 15:06
戦時中に、戦艦主砲の弾道計算をすばやく行うために
九一九総統が考案した手法。

806 :仕様書無しさん:04/05/01 23:44
'右クイックの場合の処理
'左クイックの場合の処理
'ダブルクイックの場合の処理


807 :仕様書無しさん:04/05/02 00:05
>806
EyeToyで肩を動かして操作するUIのソースだろw


808 :仕様書無しさん:04/05/02 00:31
>>806
http://www.google.com/search?num=50&hl=ja&ie=UTF-8&oe=UTF-8&c2coff=1&q=%E5%8F%B3%E3%82%AF%E3%82%A4%E3%83%83%E3%82%AF&lr=lang_ja
http://www.google.com/search?num=50&hl=ja&ie=UTF-8&oe=UTF-8&c2coff=1&q=%E5%B7%A6%E3%82%AF%E3%82%A4%E3%83%83%E3%82%AF&lr=lang_ja
意外と普及してるらしい…

809 :仕様書無しさん:04/05/02 09:55
これもな
http://www.google.com/search?num=50&hl=ja&ie=UTF-8&oe=UTF-8&c2coff=1&q=%E3%83%80%E3%83%96%E3%83%AB%E3%82%AF%E3%82%A4%E3%83%83%E3%82%AF&lr=lang_ja

810 :仕様書無しさん:04/05/02 21:52
>809
漏れが見た時点でトップにヒットしたとこは誤用ではなさげだが
2件目がポカーン
なんだ、「開来ます」って。

いやしかし、もしコンパイラに意志があったら、
「あ〜あ、またretrunだとよ……typo何だろうけどなぁ、こいつほんと進歩ねーなー
とりあえず「未定義の識別子です」、と。さてさてこのファイルだけで後何個
エラーがあるんだか。ハァ ヤッテランネ」
と、同じようなことを考えるかもなぁ、と言ってみるテスト。

811 :仕様書無しさん:04/05/02 22:59
>810
その2件目の、A-1図を見てみろ。
さらに進化してワブルクイックになってるぞ。

812 :仕様書無しさん:04/05/02 23:21
>>809
ハードデスク ってのもある。固い机?フロッピデスク…

813 :仕様書無しさん:04/05/02 23:30
Windows判とかフォレダとか、このページを読めと言われる人たちが不憫だ

814 :仕様書無しさん:04/05/03 00:12
不思議なのは、すべてが「クイック」ではなく、「クリック」という部分もあることだ。
『間違って』クリックと打ってしまったのか???

815 :仕様書無しさん:04/05/03 00:30
そこでディスクトップですよ

816 :仕様書無しさん:04/05/03 01:13
スキャン+OCRなのか、音声認識入力なのか、口述筆記なのか。

817 :仕様書無しさん:04/05/03 04:10
URLが
me-ru/meru2.htm
なんだが、誰も突っ込まないのか??

818 :仕様書無しさん:04/05/03 12:25
インストゥールも忘れずに

819 :仕様書無しさん:04/05/03 12:52
インストロールしますた

820 :仕様書無しさん:04/05/03 17:43
リーダが決めたCの関数の戻り値の決まり。

「エラー値は "INVALID" という文字列を返すこととする」

一同、「ハァ?」です。

#つまり作成する関数の戻り値は文字列型で返される文字列で判定を行えと。


821 :仕様書無しさん:04/05/03 18:00
>>820
そのDQNな理由は聞いた?

822 :仕様書無しさん:04/05/03 18:08
知障の上司の下で働くとこっちまで知障になりそうな勢いになるのは仕様ですか?

823 :仕様書無しさん:04/05/03 18:28
当然のごとく、autoな配列のポインタを返すんですねセンセイ

824 :仕様書無しさん:04/05/03 18:33
>>820
推察するに、エラー値の自由度が最大であらゆる理由を含めることが可能になる
からなのではないか?またデバッグ時に一目瞭然でエラーであることがわかるから
ではないか?

使用している言語によってはエラー判定のための比較はそれほど大変ではないから。

825 :仕様書無しさん:04/05/03 18:34
>824
あちゃ。Cなのね。新でくる。

826 :仕様書無しさん:04/05/03 18:35
ちがうよ。
きっとこうするんだ。

 :
 :
 return INVALID;
}

827 :仕様書無しさん:04/05/03 18:38
ポイント:INVALIDはグローバル変数

828 :仕様書無しさん:04/05/03 18:40
#define INVALID 71

かな?

829 :仕様書無しさん:04/05/03 18:45
グローバルにエラー文字列テーブルがあって、
それのポインタ返すんだよな?

はっきりいってウざい仕様だ、>>820のリーダは
「ケツに牛乳3g流し込んだまま花の応援団ポーズでコンクリ詰めにし洞爺湖の湖岸に半分沈める」
刑とします

830 :仕様書無しさん:04/05/03 19:11
>>829
さっさと本人に指示して来い

831 :仕様書無しさん:04/05/03 19:14
>>ダブルクイック

「受信トイレ」を思い出したw

832 :仕様書無しさん:04/05/03 19:19
このスレ、読んでると頭痛くなルネ。
僕の見つけたソース。

#define R 0
#define G 1
#define B 2

for(int i = R; i <= B; i++)
 ...

普通ですか?

833 :仕様書無しさん:04/05/03 19:20
int
異常すぎ

834 :仕様書無しさん:04/05/03 19:55
事典のプログラム作るときに、関数名のprefixを
Encyclopediaにするのは長くてやだなーと思って、
Zitenにした俺のソースコードは、後に笑われますか?

835 :仕様書無しさん:04/05/03 20:02
俺は確実に笑う。
Enc でいいじゃん

836 :仕様書無しさん:04/05/03 20:10
>>835
残念ながらEncは別に使われていたのですよ。
Encyclopediaって、途中で切りにくいのよね・・・

837 :仕様書無しさん:04/05/03 20:31
Ped にしよう。PedSearch(), PedGet(), PedInsert()....

838 :仕様書無しさん:04/05/03 20:34
Encyclopediaはクラスや名前空間名じゃダメ?

839 :仕様書無しさん:04/05/03 20:38
>>837
その方が笑われそうでつ。

>>838
Cでの開発だったので・・・。

840 :仕様書無しさん:04/05/03 20:57
>834
語源的には
「encyclo」+「pedia」
EncPed
....わかりにくいな、忘れてくれ

841 :仕様書無しさん:04/05/03 20:57
>>834 Zかよ。どっちかつったらJだろ。

842 :仕様書無しさん:04/05/03 21:03
>>834
COBOLerなら
kansu+数字でいいじゃん、悩むことはないじゃん。
とさらっと言ってくれそうだ。

843 :仕様書無しさん:04/05/03 21:32
ずぃてんなんだろう>>841

844 :仕様書無しさん:04/05/03 21:37
兄さま、ずぃてんでぃすの

845 :仕様書無しさん:04/05/03 21:55
>>842
そして、別途関数コード表を配る、と。

846 :仕様書無しさん:04/05/03 22:11
グボオォン

847 :837:04/05/03 23:30
>>839
「通報しますた」とか「ペド野郎逝ってよし」てな反応を期待してたんだよぅ

848 :仕様書無しさん:04/05/03 23:37
>847
関数名にハァハァしてしまいましたが何か。

849 :仕様書無しさん:04/05/03 23:39
>>848
ペド野郎イッってよし

850 :仕様書無しさん:04/05/04 00:05
>834
辞典(Dictionary)ではなく、事典(Encyclopedia)なんですか?

851 :仕様書無しさん:04/05/04 00:42
ペドのネタが分からない俺は、プラグラマとして失格でしょうか・・・

852 :仕様書無しさん:04/05/04 00:58
>851
むしろ正常。

853 :仕様書無しさん:04/05/04 11:56
>>850
辞典(Dictionary)ではなく、事典(Encyclopedia)です。
ゲームの中に出てくるとある要素の一覧表示だったのですよ。

854 :仕様書無しさん:04/05/04 12:58
クラス的には Dictionary でいいじゃん。広義には Encyclopedia も含むし。
辞典と事典の違いはデータ側の問題で、プログラム側に違いはないだろ。

855 :仕様書無しさん:04/05/04 13:05
俺も賛成。
事典と辞典って、(見出し語, データ構造)の組というのは同じで、
事典のほうがデータ構造がリッチだというくらいにしか認識していない。

ポインタの型で分けるとか。

856 :仕様書無しさん:04/05/04 13:28
辞典と事典を一緒にするのは違和感あるなあ。
収録されていると期待される内容が全然違う。


857 :仕様書無しさん:04/05/04 13:49
ふむ、ということは"内容"を別クラスにすれば解決ですね。

858 :仕様書無しさん:04/05/04 14:44
DictionaryもEncyclopediaも連想配列のサブクラスだから似たようなもんだ

859 :仕様書無しさん:04/05/04 15:52
ごめん、辞典と辞書って何がどう違うの?

860 :仕様書無しさん:04/05/04 16:15
>859
ぐ ぐ れ 。

861 :仕様書無しさん:04/05/04 16:24
>>859
辞書で調べろ。
もっと詳しく知りたかったら、辞典で調べろ。

#「辞書」と「辞典」を調べても、大差ないことしか
#書いてないと思うが

862 :仕様書無しさん:04/05/04 16:42
辞典と事典が共通かどうかはおいといて、
このスレ的には「Encyclopedia」を表すにふさわしい
略語を見つける事はできなかったわけですな。

863 :仕様書無しさん:04/05/04 17:16
なぜ略語にしなければいけないかがワカラン

864 :仕様書無しさん:04/05/04 17:32
Encyclopediaがそのまますべての関数についている
事典ライブラリは嫌だな

865 :仕様書無しさん:04/05/04 18:05
俺だったらeccpにしちゃうな>Encyclopedia
略称にしちゃった時点でどうせノーヒントでは読めないんだし。
だったら強く発音する子音(と母音)を並べるのが一番いい気がする。

866 :仕様書無しさん:04/05/04 18:58
EccpPut()

エククププット

ガッチャン語でレビュー

867 :仕様書無しさん:04/05/04 19:48
5文字超えたあたりで変数eに代入して使うんだからどうでもいい派

868 :837:04/05/04 20:06
こんどはマジレス。
事典に名前を付けてしまって、(e.g. GamePedia)
それの略称を接頭辞にするのはどうだろう。(GPxxx())



869 :仕様書無しさん:04/05/04 20:20
>>832
あー、初心者時代にはそんな感じのことやってた。
enumとかtypedefとかの意義が分かってなかった頃だな。
しかし実際、きれいにforeach風なことを書くにはどうする?

870 :仕様書無しさん:04/05/04 20:21
>868
賛成

871 :仕様書無しさん:04/05/04 21:01
>>869
うーん。cにはenumの「次の列挙値」を取得する演算がないからねぇ
俺が書くなら
foo( RED, ・・・ );
foo( GREEN, ・・・ );
foo( BLUE, ・・・ );
みたいに、三回の関数参照の連接となりそうだ

872 :仕様書無しさん:04/05/04 21:24

おそらくRGBは配列になっているでしょうからXtNumberみたいなマクロを使う
方法もあるんじゃないかと。


873 :仕様書無しさん:04/05/04 21:27
>>871
C++ならenum型の演算子オーバーロードが出来る。
++とか--とかオーバーロードしよう。


874 :仕様書無しさん:04/05/04 22:27
>>872
XtNumber()がわかる人なんかどれだけいるのか?わら。
# うに板ならわかる人も多そうだけど。

875 :仕様書無しさん:04/05/04 22:32
>>873
最初と最後の値はどうしますか?
for (e=RED ; e!=BLUE ; ++e)
 foo(e,...);
なんかにしてみたら、>>871よりも読醜くなってるよね。

876 :仕様書無しさん:04/05/04 22:35
ボクなら、3個の要素の配列を用意してループするけど...

877 :仕様書無しさん:04/05/04 22:37
>>875
すなおにそれっぽい関数か定数を作る。

for (e=ColorBegin(); e<ColorEnd(); ++e) {
//...
}

しかしenumがスコープを作らない(classやstructみたいに識別子が閉じない)のは
困りもんだよな。
(真面目に言うとenumの演算子オーバーロードはやめたほうがいいと思う)

878 :仕様書無しさん:04/05/05 00:09
漏れが思いつくのは
foo( Rの情報を所有するbitmapなインターフェイスを持つクラス );
foo( Gの情報を所有するbitmapなインターフェイスを持つクラス );
foo( Bの情報を所有するbitmapなインターフェイスを持つクラス );
とするか
fooR( ... );
fooG( ... );
fooB( ... );
とするか
enum PrimaryColor{red,green,blue};
int PrimaryColorTable[]={red,green,blue};
でテーブルを使ったforループだな。

879 :仕様書無しさん:04/05/05 01:02
Cでコード書くなら

enum {
 ColorR,
 ColorG,
ColorB,
 RGBMAX = ColorB
};

for (i = 0; i < RGBMAX; i++) {
 //
}

か?

880 :仕様書無しさん:04/05/05 01:08
enumの列挙値として最大値を入れてしまうかどうか、未だに悩む。
その型の取りうる値としては不正だけども、
入れてしまわないとその値を確実に取得する方法が他に無い。

881 :仕様書無しさん:04/05/05 02:32
>>879
その場合は i<=RGBMAX ではないか?

enum {
 ColorR,
 ColorG,
ColorB,
 ColorEnd
};

for (i = 0; i < ColorEnd; i++) {
 //
}

882 :仕様書無しさん:04/05/05 02:54
最初のやつを明示的に0にしないと不安が不安が不安が

883 :仕様書無しさん:04/05/05 02:55
enumの最初の値って、0に保証されてなかったっけ?

884 :仕様書無しさん:04/05/05 03:05
>>883
されてるよ。
>>882
不安に思うなら勉強のほうをすべきでしょう。

885 :仕様書無しさん:04/05/05 04:31
C++っぽくしてみた。かつ無遠慮な演算子オーバーロードはやめる方向で。
namespace color {
enum primary {Red,Green,Blue};
primary begin(void);
primary end(void);
primary next(primary e);
} // namespace color

for (color::primary e=color::begin() ; e!=color::end() ; e=color::next(e))
  foo(e,...)


886 :仕様書無しさん:04/05/05 08:25
そういうコードを引き継いだ香具師がまた辞めようと思うわけですね

887 :仕様書無しさん:04/05/05 09:58
独断と偏見で書くが、
この手の問題にイテレータパターンを使おうとする奴は病気だぞ

888 :仕様書無しさん:04/05/05 13:10
enumがintサイズだという仮定のほうが問題だな

889 :仕様書無しさん:04/05/05 14:09
この例では3つしかないからint以下なのは確実じゃん。

890 :仕様書無しさん:04/05/05 14:18
enumって、省略したらint型じゃなかったっけ?

891 :仕様書無しさん:04/05/05 14:39
>>890
省略って指定できるんだっけ?

C++ではうまく収まる最少の型になってくれるので、intサイズを越える定数を
列挙子に付けることが可能。ただし符号付き型にしかならない。

892 :仕様書無しさん:04/05/05 15:22
>>890
ARM-C だと最低サイズになっちゃうよ。
例えば255までしか規定されてないと unsigned char になっちゃう。


893 :仕様書無しさん:04/05/05 15:50
まぁ、値で問題になるのは
 ColorEnd
だけなんだろうから、intにキャストしちゃえばいいのでは?


894 :仕様書無しさん:04/05/05 16:16
勉強が必要な奴は結構いるようだねえ・・・
intにキャストするなんてバカっぽいことはしないほうがいいと思うよ

895 :仕様書無しさん:04/05/05 16:19
>>893
なんでしないといけない?
int未満の整数型は必ずintに格上げされて演算されるのだが。
(C++の型一致チェックを除く)


896 :仕様書無しさん:04/05/05 19:36
不要なところでキャストしないのいいなぁ
うちの規約だと、型は全部明示的に変更する、ってルールがあるから
キャストしないといけないんだよな

897 :仕様書無しさん:04/05/05 19:51
>>896
Base* p = static_cast<Base*>(new Derived);
int a = static_cast<int>('A');
とか書くのかな?
そんなルールに何の利点があるの?

898 :仕様書無しさん:04/05/05 19:51
>>896
馬鹿は規約を決めないで欲しいよね。でも馬鹿ほど規約を決めたがるんだよな。

(void)(int)(a = (int)((int)(char)b + (int)(char)c + (int)1));
(void)(int)printf((const char*)"%d\n", (int)a);

なかなか楽しそうだ。

899 :仕様書無しさん:04/05/05 19:53
('A');// マンドクセ

900 :仕様書無しさん:04/05/05 20:12
('A`)

901 :仕様書無しさん:04/05/05 20:14
(;;)

902 :仕様書無しさん:04/05/05 20:15
(1)

903 :仕様書無しさん:04/05/05 20:17
さすがはこの会社辞めようと思ったソースコードスレの住人。
笑えるコード書くね。

904 :仕様書無しさん:04/05/05 20:25
enumはint型として扱って問題ないよね?

905 :仕様書無しさん:04/05/05 20:50
>>904
enum {
a,
b = LONG_MAX
};

for (int i=0; i<=b; i++) {
//...
}


906 :仕様書無しさん:04/05/05 23:32
>>892
仕様の話をするのに今さらARMを持ち出さないようにな。わら。
# すばらしい本だとは思うけどね。今読んでも楽しめるし。

907 :仕様書無しさん:04/05/05 23:36
>>887
どんな病気だと思うのか、なぜなのか、言ってくれ。
外部イテレータか内部イテレータかでも話が違うような気もする。

908 :仕様書無しさん:04/05/05 23:43
>>906
CPUのARM向けのCコンパイラじゃないかなあ? C++って書いてないし。
unsignedになるのは規格から外れていると重う。

909 :仕様書無しさん:04/05/06 11:35
>>908
いいみたい。

ISO/IEC 9899:1999 6.7.2.2.4
Each enumerated type shall be compatible with char, a signed integer type, or an
unsigned integer type. The choice of type is implementation-defined,108) but shall be
capable of representing the values of all the members of the enumeration. The
enumerated type is incomplete until after the } that terminates the list of enumerator
declarations.

910 :892:04/05/06 15:56
>>908
んだ。
携帯のシュミレータ(VC++)→実機移行で知った。
ずっと typedef  int  enum だと思ってたので新鮮だったの。

911 :仕様書無しさん:04/05/06 19:18
codewarriorは小さいサイズにしたと思う

912 :仕様書無しさん:04/05/06 22:46
むかしC++でenumがunsignedにならなくて困った覚えあり。
C++はだめなのか、自分が間抜けなのか?

913 :仕様書無しさん:04/05/06 23:12
>>909
それはいわゆるC99だが、組み込み用Cコンパイラがもう対応しているものなのか。
たぶんそうではないような気が。

914 :シス屋さん ◆kKvCN0tjXE :04/05/06 23:14
後輩が1ファイル2万行1メガバイツのソースと格闘中に見つけたフラグ。(ドキュメントなし)

  ガ マ ン フ ラ グ

なんだよそりゃ。_| ̄|○

このフラグがTRUEになるとステータスを出力することができるらしい。
FALSEのときは出力をガマンしているということなのだろう。


915 :仕様書無しさん:04/05/06 23:21
>>914
激シクワロタ

916 :仕様書無しさん:04/05/06 23:24
>>914
逆じゃんw

917 :仕様書無しさん:04/05/06 23:32
_ト ̄|○ もう出ちゃいそうだよ...

ガマンフラグ=FALSE; // まだイッちゃダメ!

918 :仕様書無しさん:04/05/06 23:35
>>914
>>ガマンフラグ
爆笑!
ひさしぶりに笑わせていただきました。
ていうかそのソース書いたぷろぐらま、変ななセンス持ってるんじゃないの?
それが吉となるか凶となるか・・

919 :仕様書無しさん:04/05/06 23:36
こりゃUwaRite以来のヒットか?w

920 :仕様書無しさん:04/05/06 23:36
まあ、iだのjだのkよりましか。コメント付いてりゃ。
結構わかりやすいし(w

921 :仕様書無しさん:04/05/06 23:56
ハライテェ

922 :仕様書無しさん:04/05/07 00:20
>914
きっと元ソース書いた香具師も何かを必死にガマンしてたんだよ。
まぁなんだ、機能不全家庭で育った子供は機能不全家庭を作りがちだとかいうあれだよ。

923 :仕様書無しさん:04/05/07 00:21
GamenFlag

のスペルミスじゃないのか?

924 :仕様書無しさん:04/05/07 01:54
ステータスの出力制御ということだから
画面フラグという可能性は低いかと。

つーか、ガマンフラグ面白すぎ。
ガッチャンかよ、ネタに続く面白さと認定

925 :仕様書無しさん:04/05/07 01:59
ステータスを画面に出力する時、画面が使用可能か否かの判定に使用する
よって>>923

926 :仕様書無しさん:04/05/07 09:20
>923、925
なんつうか、リアルでも周りが爆笑してる時に一人で冷静に
つまらないツッコミいれて場を白けさせるタイプ?

927 :仕様書無しさん:04/05/07 10:41
>>926はその場の空気でどんな悪いことでもしてしまうタイプだな

928 :仕様書無しさん:04/05/07 12:08
>927はいきなり見当違いな事を言い出して周りを混乱させるタイプだな


929 :仕様書無しさん:04/05/07 12:18
>>928は普段から「唐突に関係の無い話を持ち出さないこと」とか言って嫌われるタイプだな

930 :仕様書無しさん:04/05/07 12:24
俺のケツ毛は剛毛なタイプだな

931 :仕様書無しさん:04/05/07 21:03
>>932はしらけかけた雰囲気の中で最高のネタを披露して爆笑を誘うタイプだな

932 :仕様書無しさん:04/05/07 21:04
 

933 :仕様書無しさん:04/05/07 21:14
>>932
ハゲワラ

934 :仕様書無しさん:04/05/07 21:45
>>932
イイ!

935 :仕様書無しさん:04/05/07 22:45
そして俺が話を断ち切るタイプか。

もまえらいい加減に汁

936 :仕様書無しさん:04/05/07 23:02
だめだこりゃ。
次いってみよー

937 :仕様書無しさん:04/05/07 23:13


938 :仕様書無しさん:04/05/07 23:42
漏れも「ガマンフラグ」使おうかな?(w

939 :仕様書無しさん:04/05/08 01:10
if ( GamanFlag == 0 ) exit(1);

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

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)