1 :仕様書無しさん2010/01/24(日) 19:28:35
この会社辞めようと思ったソースコード。
プログラマとして幻滅するソースコード。
プログラマを悩ませるソースコード。
をつらつらと綴っていって頂戴。

ちなみにここは質問スレじゃないので
技術的な質問がしたいならム板 http://pc11.2ch.net/tech/ に逝って。

前スレ
この会社辞めようと思ったソースコード#1B
http://pc11.2ch.net/test/read.cgi/prog/1217149576/
2 :仕様書無しさん2010/01/24(日) 20:52:56
今から放送だからテレビつけろよ


24日放送の「NHKスペシャル」でREGZAやRYOMAの開発舞台裏を紹介
ファイル・ウェブ編集部

NHKは、「NHKスペシャル メイド・イン・ジャパンの命運」を1月24日午後9時から総合テレビで放映する。

番組内では、東芝やJVCケンウッドの商品開発や生産の舞台裏を紹介し、「『日本は今後どうやって食べていくのか」、
『日本人は何が得意なのか』と自問を繰り返す二つの電機メーカーの社運を賭けたプロジェクトに密着し、
メイド・イン・ジャパンの未来を見つめていく」(NHKの番組紹介より)という。

AVファンにとって興味深い話題が多く紹介されると予想されるこの番組、ぜひチェックをおすすめしたい。

ソース
ttp://www.phileweb.com/news/d-av/201001/22/25182.html
5 :仕様書無しさん2010/01/24(日) 22:13:44
>2
見たけどダメだな、ありゃ
バイデザインとセルレグザじゃ競争のレイヤが違うんだよ
ケータイのソ\\\フトと作り方一緒じゃん!
6 :仕様書無しさん2010/01/24(日) 22:42:49
csvデータファイルの変換を行うプログラム。頭から書き直したくなった。
int i;
void main(){
fp = fopen(...

(略)

getOneLine(fp,buf);
for(i=0;i<320;i++){
getToken(buf,i,token);
switch(i){
case 0:
func0(buf);
break;
case 1:
func1(buf);
break;

(略)

case 319:
func319(buf);
break;
}
}
8 :仕様書無しさん2010/01/25(月) 19:55:04
public class ぬるぽ : NullReferenceException { }


すべて検索 "throw new ぬるぽ", 大文字と小文字を区別する, 完全に一致する単語だけを検索する, サブ フォルダ, 検索結果 1, "現在のプロジェクト"
(略)
一致した行: 339 一致したファイル: 65 検索ファイル総数: 2011
9 :仕様書無しさん2010/01/25(月) 23:47:00
それ、ちゃんと処理しているだけマシだと思う。
すくなくともエンドユーザには不様な姿を見せてないもの。
10 :仕様書無しさん2010/01/26(火) 10:39:59
>>8
Java辺りからきたマだったんだろw
11 :仕様書無しさん2010/01/26(火) 12:18:23
>>8
どのあたりがひどいのかがよく分からん。
15 :仕様書無しさん2010/01/26(火) 13:44:27
NullReferenceExceptionはランタイムから飛んでくるもんだろ
ユーザが意図して投げるならArgumentNullException辺りが妥当じゃね?

あるいは
catch(NullReferenceException){throw new ぬるぽ();}
とかやってたんかな

// しかしC#て日本語でクラスかけるんだな
// 2年やってて気づかんかった
16 :仕様書無しさん2010/01/27(水) 01:44:22
>>15
ソリューション名に日本語入れてデフォルトでウィザード終えるとクラス名から実行ファイル名までごっそり日本語ぶち込まれるんだよな。
流石Unicode
17 :仕様書無しさん2010/01/27(水) 22:57:21
まぁ結局プログラマーなんて」ゴミみたいなもんだからな
18 :仕様書無しさん2010/01/27(水) 23:26:55
>>17
お前、昨日からそればっかしだな。
20 :仕様書無しさん2010/01/27(水) 23:59:59
興奮しててENTERと一緒に押したの気付かなかっただけじゃね
21 :仕様書無しさん2010/01/29(金) 20:32:33
>>17
こういうやつはいずれウィルスみたいな人に迷惑をかけるプログラムを書きそうだ
23 :仕様書無しさん2010/01/30(土) 22:12:05
>>6
こういうプログラムに限って、途中で

case 231:
func232(buf);
break;
case 232:
func231(buf);
break;

とかコメントもなくなっていて、
意図的なのかミスなのかわからないんだよなぁ・・・
24 :仕様書無しさん2010/01/31(日) 14:44:34
>>23
あるあるあるあるwww

思い出すどころか想像するだけでゲンナリする。
VBでコントロール配列使わず、100個ほどボタンを置いたフォームの
OnClickの群れの方が対照させやすい点でまだいいな。
まぁ今更VB自体使いたくないけど。
25 :仕様書無しさん2010/01/31(日) 16:21:41
VB6はvistaで動作保証がある。
たぶん7でも問題なく動くケースが多いから、あと数年は確実に残るんじゃないか。

つ〜か、この不況でvb.netやC#に移行する金が出せる企業は……
(言語本体は安いけど、サードパーティ製の各種コンポーネントが……)
26 :仕様書無しさん2010/02/20(土) 15:34:58
>>24

唐突に思い出したんだが、配列が嫌いなプログラマが書いたコードがあった。

リングバッファの処理らしいんだが

void DetaSettei( int atai )
{
atai1 = atai2;
atai2 = atai3;
.........
atai255 = atai254;
atai0 = atai;

genIchi = ++genIchi % 256
}

うちでは技術力はあると言われている人
ちなみに、関数名とか変数名は若干いじったが、元も大抵ローマ字っぽい何かが多い
27 :仕様書無しさん2010/02/20(土) 15:48:14
配列使ってても書き直せ馬鹿って言われるであろう計算量だな
28 :仕様書無しさん2010/02/20(土) 16:43:33
>>27

計算量は変わらないだろ。メモリアクセスはかなり増えるが。

昔、配列 と memcopy で 26 のコードを見た事がある。
Verilog HDLで回路設計やってる人だったけど、
ゲートのシフトレジスタ・FIFOのイメージでと言ってた。



29 :仕様書無しさん2010/02/20(土) 17:13:04
>>27
動いてればまだ多少は許せるのだが、この人たちのプログラムは正直、
アレなバグがやたら多いんだよね。

atai221 = atai220;
atai222 = atai220;

みたいな

直せと言われて、直すんだけど、大体配列なり、変なグローバル変数の使い方を改めると
1/3ぐらいそれで直る(笑)

そこまでしてこだわる理由を聞くと、配列使うより、こうした方が処理が早くなると言われるんだ。

その割に、デバッグビルド(最適化オプションなしか緩め)で客先に納品されたり、
なかなか間抜けなことが多い
30 :仕様書無しさん2010/02/20(土) 17:25:15
組み込みやってる(やってた)人ならパイプラインのストールを嫌って
単純ループなプログラムを回避したと推測してみる
31 :仕様書無しさん2010/02/20(土) 17:44:58
>>30
今のコンパイラならオプションである程度
展開してくれるから、そこまで変わらん
33 :仕様書無しさん2010/02/21(日) 09:24:23
>>26
そのバッファからデータを取り出すときって genIchi による switch 文を使うの?
case が256行並ぶのは壮観だろうなw

>>28
配列使えばデータを動かす必要無いと思うよ

>>29
『処理が早くなる』って言われたら気絶しそうだ
34 :仕様書無しさん2010/02/21(日) 09:47:00
>>33

当然ですが、switch〜case文が256個並びます(w

バグを調査しようとしてたらしく、至る所にTRACEとかファイル(ログ)、
書き出しとかの残骸が転がってました。
256個のデータダンプするコードとかを全部ベタ書きしてたときは、
壮観というか卒倒しそうになった。

ファイルIOとかの処理挟んだら、処理が早くなるとか言ってもぶちこわし(w
35 :仕様書無しさん2010/02/21(日) 10:07:53
>>34
よく考えるとセット関数も書き込み位置インデックスによるswitch〜case256行にすればデータをズラす操作は不要だね
書いた奴は相当頭が固いんだろうね

関数コール毎に256個のデータダンプ?
んなもん出したところでチェックするのは至難の業だと思うんだけど...
36 :仕様書無しさん2010/02/21(日) 14:16:20
>>35
それって、配列でインデックスアクセスするのと何処が異なるの?
大差のないアセンブリソースが出力されそうな気が……
37 :仕様書無しさん2010/02/21(日) 14:39:43
>>28
バッファ長をNとして、
>>26の例のようにデータを動かす場合、計算量はO(N)。
producerもconsumerもインデックスを動かせば、計算量はO(1)。
39 :仕様書無しさん2010/02/21(日) 23:12:45
>>36
確かめもせずに大差ないとか言ってませんか
40 :仕様書無しさん2010/02/21(日) 23:18:28
>>36
switchは効率悪いからね、 else if の連鎖と同じアセンブリを吐くのが普通じゃないかな
一回のアドレス演算で済む配列とは雲泥の差が有るぉ
41 :仕様書無しさん2010/02/21(日) 23:36:22
256個もcaseがあれば、まともなコンパイラはテーブルジャンプに変換します。
42 :仕様書無しさん2010/02/22(月) 00:59:58
最近のコンパイラではアセンブル結果見た事ないからね、認識が古いかな?
どっちみちジャンプテーブルを確保したり無駄なジャンプが発生する以上、『大差ない』とは言えないよ
43 :仕様書無しさん2010/02/22(月) 01:11:03
>26
 似たようなのだが、16進二桁を数値化するのに、if 文合計272個、ってのが……
※C ですぜ

 1個目が 0〜F で一段目の if (これが16個)、
 2個目が 0〜F で、各一段目の中に16個ずつの if ……
※よって、16 + (16*16) = 16*17 = 272個

 これでもソースレビュー通ってたらしい。
 むろん、書き直したけどな。
44 :仕様書無しさん2010/02/22(月) 09:22:27
組み込み屋とアプリ屋で話かみ合ってなくない?
45 :仕様書無しさん2010/02/22(月) 14:07:05
>>44
組み込み用のコンパイラでも配列くらい使えるだろう
そもそも >>30 はループなんて言ってるから問題点を理解してない気もするし
46 :仕様書無しさん2010/02/22(月) 14:23:43
お前が30の言ってる意味分かってないだろw
49 :仕様書無しさん2010/02/22(月) 19:14:07
>>26で晒されたコードを書いたのはお前か〜>>46
50 :仕様書無しさん2010/02/22(月) 20:41:03
46じゃないよ
>49
繰り返すけど>46
52 :仕様書無しさん2010/02/22(月) 22:13:19
44なんだけど、リングバッファ知ってる人と知らない人で噛み合ってなかったのかな?
まあ俺は知らなかったよ
使ったこと無いし
>>30,42は速度の点を問題にしたのじゃないの?
あと>>45はループの問題が分かってないのじゃないの
要る要らないじゃなく
分かってたらゴメンね
53 :仕様書無しさん2010/02/23(火) 04:18:24
>>52
リングバッファも知らない人に馬鹿にされて く や し い で す!
54 :522010/02/23(火) 09:03:12
   , -‐−-、  ヽ∧∧∧ //  |
.  /////_ハ ヽ< 釣れた!> ハ
  レ//j け ,fjlリ / ∨∨V ヽ  h. ゚l;
 ハイイト、"ヮノハ     //   |::: j  。
  /⌒ヽヾ'リ、     //     ヾ、≦ '
. {   j`ー' ハ      // ヽ∧∧∧∧∧∧∨/
  k〜'l   レヘ.   ,r'ス < 初めてなのに >
  | ヽ \ ト、 ヽ-kヾソ < 釣れちゃった!>
.  l  \ `ー‐ゝ-〈/´   / ∨∨∨∨∨∨ヽ
  l     `ー-、___ノ
  ハ   ´ ̄` 〈/‐-、
55 :仕様書無しさん2010/02/23(火) 09:14:47
>>54
むしろ、初めてのほうが食いつきがいいんだよ?
56 :仕様書無しさん2010/02/23(火) 19:08:05
>>54
くやしいねえ。
10年後にその書き込みをもう一度読む自分を想像してみ?
かなりくやしいねえwww
57 :仕様書無しさん2010/03/03(水) 10:56:51
外の会社でやっているときに、修正してと言われたVBのソースが、case文が100個近くあるものだった事があるなぁ

これ「だけ」だったらまだ「汚いソースだな」と思うだけだったんだが…
・CASE文が1000行近くある。
・ほぼ同一のコードが、異なる条件式に「多数」存在する。
・似て非なるコードも多数ある、通らない条件式も多数あるが、条件が「ハードコーディングされている」のでどれが何だかわからない
・このcase文がある関数は、3000行近くある。

まだ、これなら「最低のソース」なのだけど、極めつけはこれ
・以前に修正したものらしきソースがコメントとして残されている。ほとんど5行おきに交互に。しかも大量に。

よくここまで非論理的で可読性を無視したソースが、たぶん全国にある某店のシステムとして運用できるものだと思ったよ
60 :仕様書無しさん2010/03/03(水) 22:12:00
>>1
区切りが全然ないとかかなあ。
しょっちゅう見かけるけど、何でコンパクトに分けないのかな?
まるで読書してるようで、とてもソースコードとは思えない。
カプセル化した方がとは言わないけど、丸で読書。
関数分けしてない人って、どういうソースの組み方なんだろう。
あとコメントが丸で無いから、分らなくて
一から読み直しかと思うと、苛々します。
バグ発見も、非常に邪魔臭いです。
時々でいいんです。後で触る人の事、思い出してください。
61 :仕様書無しさん2010/03/03(水) 23:47:12
「細かく関数に分けると、処理があちこち飛んで読みにくい」

だそうです。
63 :仕様書無しさん2010/03/04(木) 00:27:29
しっかりってなんのこっちゃ
64 :仕様書無しさん2010/03/04(木) 09:22:47
>>60
昔駆け出しの頃に、新人だからやっぱりスパゲッティソースを書いた事があって、そのときに超ベテランの人にこういわれたことがあったな
「ソースは自分のためにではなく、他人のために書く」
当時は何のこっちゃいと思ったけど、今はいろいろあってそれが根底になっているな
それでも汚いソースになることがあるから、まだまだなんだが

>>63
関数が機能として独立してないとかかな
中途半端にグローバル変数なんか使っていたりするとかなり泣きが入る
65 :仕様書無しさん2010/03/04(木) 13:04:50
あるフリーソフトのソースを買いたいが、まず一部を見せてくれと言われたことがある(日本の会社ではない)。そのとき汚いなら買えないと言われた。
66 :仕様書無しさん2010/03/04(木) 13:34:07
海外のほうが汚いけどな
67 :仕様書無しさん2010/03/04(木) 15:13:56
>中途半端にグローバル変数なんか使っていたりするとかなり泣きが入る
相等やばいな。流石に、それはなかった。

>>66
まさに”人による”部分が大きい。
大手でも、中小の自宅開発でも。
68 :仕様書無しさん2010/03/04(木) 16:29:40
確かに人によるね。
綺麗に書く人はとことん綺麗に書く。書くんだが…
前にコメントを細かく書いてソースもそれなりに綺麗に書いてくれる奴がいたんだが、これがまた困ったもので

コメントを細かく書いてくれるのは結構なんだが、だからって関数内でコメント>>コードなものを書くなと
コードを見てすぐに分かる部分は一々書かなくて良いし、ただでさえ簡単なのやらせても遅いんだから、もっとシンプルかつスピーディーにコードを書いてくれと

自信満々に「自分のプログラムはバグ出ません!」と言われても、そりゃそうだ
君の代わりにこっちは同じ開発期間で8倍のPG組んで、おまけに仕様書が書けないSEの代わりにPGのロジック考えて、ついでに現地でテストも立ち会っているんだから('A`)
それで自分がバグだしたら意味無いんだが、それでももう少し納期や必要の是非を考慮する関数がコーディングされていれば、もうちょっと何か違ったのかなと思う

自宅開発なら良いPGだったのかもしれないけどね
69 :仕様書無しさん2010/03/04(木) 21:36:04
プログラムを作る人は、時間的感覚が無くなってしまう事ってあるね。
でも無理な工程で作らせたり、動と静の共存こそ、バグの原因だと思った。

しかし変な話だよな。プログラマなら分ると思うが
オブジェクト指向が、作業全体ではなく、プログラムにしか適応されないのって
何でだろう?って思う事は多いね。

でも、頭で考える世界って、静止した世界なんだろうな。
地球はその間も絶え間なく動く、動の世界。

結局、動の世界がなければ、静の世界も認識できなくなり、I/Oと同じ仕組みが見て取れる。
という事は、バグは自然に作られる、イレギュラーという名の正規のものなのか。
と矛盾した事を考えてしまう。

バグは大嫌いだけど、そんな自分も実は地球のバグなのでは、と
仕事帰りに考えたり。
70 :仕様書無しさん2010/03/04(木) 21:55:23
おまえ、自分でわかってないのかもしれないが、精神病じゃないか?
71 :仕様書無しさん2010/03/04(木) 22:06:15
>>69
自然界ならバグは進化の過程といえる。
最近も新発見はバグ(失敗)が原因だったりする。
しかし、そふとうぇあの世界ではバグで新発見などない。
せいぜい誤変換や誤読で池沼などの言葉が生まれる程度。

あ、日本では鳥がさまざまな姿をしているという話は聞くね。


日本には謎の鳥がいる。 正体はよく分からない。
中国から見れば「カモ」に見える。
米国から見れば「チキン」に見える。
欧州から見れば「アホウドリ」に見える。
日本の有職者には「サギ」だと思われている。
オザワから見れば「オウム」のような存在。
でも鳥自身は「ハト」だと言い張っている。
それでいて、約束をしたら「ウソ」に見え
身体検査をしたら「カラス」のように真っ黒、
釈明会見では「キュウカンチョウ」になるが、
実際は単なる鵜飼いの「ウ」。
私はあの鳥は日本の「ガン」だと思う。
75 :仕様書無しさん2010/03/06(土) 01:02:45
>>70
そこはお前、「お前バグってんなー」だろ
76 :仕様書無しさん2010/03/06(土) 18:57:07
>中途半端にグローバル変数なんか使っていたりするとかなり泣きが入る

中途半端というか、完全に全関数に影響があったこともある。
以下、担当新人に言われたこと。


え〜〜〜〜
毎回ループ文書くときにint iって書くのメンドイじゃないっすか〜?
だからグローバルでiを書いたんッスけど〜?
何が悪いんスか〜?説明してくださいよ!
(俺の説明)
あ゛〜〜!もう何言ってるのかワカンネーッスよ!
(レベル下げて再度説明)
・・・もういいから黙れクソが!
てめぇ何さっきから俺に説教タレてんの?
てめぇ偉いのかよ?何様のつもり?
78 :仕様書無しさん2010/03/07(日) 11:21:40
>>76
昔派遣で行ったところが会社全体でそんな感じ
N88日本語BASICと同じ感じでCとかのプログラム組んでて、
本当にカウンタ変数をグローバルで定義してて、それを
複数関数で使ってんの

当然わけわかんないバグがてんこ盛りで、グローバル変数の
害悪やら何やら説明してリファインの必要を説いたけど、
そこで「使える」マですらその新人並みの反応だった
79 :仕様書無しさん2010/03/07(日) 11:45:52
>>78
Nでしょ?汎用機上がりの部門は
今も変わらないよw
80 :仕様書無しさん2010/03/07(日) 14:14:09
COBOLあがりならスコープって何って人も居るかも知れない
でも >>76 のはCOBOL未経験と思われる新人だからレアなクソかと
81 :仕様書無しさん2010/03/07(日) 14:17:06
そもそもループのカウンタに i のような無意味な名前をつけることですら、推奨されなくなっているのにな。
88 :仕様書無しさん2010/03/07(日) 18:49:53
グローバルを絶対使うなとは言わないけど grep しやすいように長めの変数名にして欲しい
89 :仕様書無しさん2010/03/07(日) 23:15:29
>i のような無意味な名前

悪しき風習?だろうが、既にデファクトスタンダードになってるからね〜
あながち無意味とは思えないけどね。
90 :仕様書無しさん2010/03/08(月) 02:08:51
悪しき風習なんてとんでもない。
昔の低機能エディタなら、「i」で検索するといっぱい引っかかって追いにくい
という理由もあったんだけど、今は分かりきった動作のただのカウンタに
counterなんてムダに長い名前つける意味無いよ。
そっちよりは、意味のある変数こそ、下手な省略しないで長い名前にして欲しい。
91 :仕様書無しさん2010/03/08(月) 06:55:10
ループ変数を検索したければ
int +i
で正規表現健作すればいいだろ。
92 :仕様書無しさん2010/03/08(月) 09:28:50
iをカウンタに使うやつは、二重にループするときはjにするんだろ。iとjでどっちがどのインデックスなのかが分かりにくくなって、そのコードに他人が手を入れ出したり、コピペしだすと崩壊が始まる。
93 :仕様書無しさん2010/03/08(月) 11:09:34
外から順に i, j, k, l だよ
どっちがどのインデックスか分からないのは cnt1, cnt2 でも同じだろ
それとも array[ first_index ][ second_index ] みたいなループカウンタでも使うのか?
94 :仕様書無しさん2010/03/08(月) 11:39:29
>>93
もちろんそんなのではだめだ。counterやindexという意味はiにもあるが、それだけの意味しない。
95 :仕様書無しさん2010/03/08(月) 13:53:57
>>92
すべてのカウンタを無条件にi, j, k にするからそーなるんだろ。
シンプルに回数で回る奴に限定しとけばそんな問題はおきない。
というか、それで問題を起こす奴にソースコードをいじらせるな。
96 :仕様書無しさん2010/03/08(月) 14:05:56
c++とかだったら
for(int i ; i <maxSize; i++)
とかでいいとおもうけどな。
97 :仕様書無しさん2010/03/08(月) 14:07:28
>>96
うん。だからこーゆーのでこんがらがるってどういう脳みそしてるんだろうと。
98 :仕様書無しさん2010/03/08(月) 15:33:20
こういうやつらが集まって、わけのわからないコードが出来上がる
99 :仕様書無しさん2010/03/08(月) 16:49:13
> c++とかだったら
> for(int i ; i <maxSize; i++)

鼻から悪魔
101 :仕様書無しさん2010/03/08(月) 18:06:17
こういうことで喧嘩になっているのか?

for (int i; i < 9; i++)
{
for (int j; j < 9; j++)
{
printf("%d*%d = %d\n",i,j,i*j);
}
}

for (int grpNum; grpNum < grpMax; grpNum++)
{
for (int manNum; manNum < manMax; manNum++)
{
printf("名前は%sでデスマッチ\n",Name[grpNum][manNum]);
}
}
104 :仕様書無しさん2010/03/08(月) 23:24:55
iとかjじゃわからなくなるぐらいデカイfor文書く奴がいるから
一律でそんな変数名はやめましょうという話になるんだよ
105 :仕様書無しさん2010/03/08(月) 23:35:29
>>104
問題は添え字じゃなくて配列名だろ
107 :仕様書無しさん2010/03/09(火) 09:23:11
配列の全要素に同じ処理を施したいって程度の
小さなループならiやjでも十分な気がする
ループカウンタの値によってループ内の処理が違うようなら
それなりに意味のある名前があったようがいいと思う
108 :仕様書無しさん2010/03/09(火) 11:11:25
>>104
たしかにでかい多重ループが頻発するようじゃあ
そもそも設計が悪いとは言えるわな
109 :仕様書無しさん2010/03/09(火) 15:37:47
{ から } までは50行くらいに収めたいよな
そうなってれば変数名がうんぬんとか低レベルな話をしなくても済むから
110 :仕様書無しさん2010/03/09(火) 16:44:50
変数名というくくりでの議論は低レベルじゃないよ
内容を矮小化しないでね
112 :仕様書無しさん2010/03/11(木) 10:06:26
ロジックの意味によると思うんだが…

単純に配列に格納したい場合や初期化する場合など
大まかに把握して問題ないロジックならi,j使って問題ないけど、
ロジック内で重要な部分や複雑なことしているのであれば
変数名に明確な意味を持たせた方が後々他の人が見たときに理解しやすい

そんな感覚で書いてる
113 :仕様書無しさん2010/03/11(木) 12:37:36
ループ制御変数が単純な配列の添え字なら、i, j 以外の名前にするのは馬鹿げている。

for (int i = 0; i < a.size; ++i) {
do something on a[i]
}

114 :仕様書無しさん2010/03/11(木) 12:54:45
>>112
でも
for( i = 0; i < hoge_max; i++ )
と書くと i が hoge に関するカウンタである事は自明でしょ、hoge_cnt にするとくどい気もするんだけど
もっとも for ブロックが巨大ならその限りではないけどね

カウンターに i, j を使わない人は転置行列を作成するときどんな名前のカウンターを使うのか謎
115 :uy ◆e6.oHu1j.o 2010/03/11(木) 18:19:08
nmkoiu
俺様がいくら一文字変数が好きといっても
jとlだけは使わない。

この世界はまず、
集団真理によってゴミみたいなもんが是とされてて、うざい


それでもお前らゴミにヒントを与えてやろうかね
iとjはね、 見間違う見間違わないの問題じゃない。
パッと見たときの、認識速度だよ
aとi が違う文字だってのはすぐ分かるけど
jとi だと、 aとiとの違いを見つけるよりも、10〜20倍の処理時間がかかってる
勿論、人間の処理速度は高速だから、目に見えて処理落ちするような事はないけれど
i、j、lしか変数の無いコードをかいてるより
i、o、z、n なんかで構成したコードのほうが、疲れは少ない。

こういうのに本当は、誰でも気づいてほしいものだけど、
ゴミみたいな奴に限らず、 ほとんどの人間は問題を小さくみすぎてて、
実際は降り積もって大きな障害となってるのに、対処しない
3重ループになると、i、j、l とか使い出す奴もいるね
まぁゴミっていうより、 周りに合わせるのが良いこと だと教えられて育っちゃった奴だろうな
i、jときてl、 関連性はある。、 みんな似てる。 1番2番に似ているものを、3番目にもってきた。
そうなんだね。
116 :uy ◆e6.oHu1j.o 2010/03/11(木) 18:37:00
二重ループでi,jを使わなく日が来るとすれば
ソースコードを読めるAIを誰かが作って、
その論文を誰か偉い人発表するときだろう
「AIを作ってみて分かった、カウンタは似ている文字を使ってはいけない」などと言葉をもらす
そして次第にそれが、ようやくゴミみたいなマたちの間にも広がって、
長きにわたるi,jの風習は終わる。
別に、i,jを使ってるのが貴様等がバカだからだとは思ってない
そういう流れなんだから仕方が無いよね。
ほとんどの人間は、流れに逆らえないってことは、このことからよくわかる。

さらにゴミみたいな奴は、このレスにたいし
フォントだの、色だの、視力だの、言ってきそうだが、そんな何も考えてないようなゴミみたいなレスはかかなくていい
117 :仕様書無しさん2010/03/11(木) 18:50:59
>>114
たしかに教科書や論文に出てくる数式をそのままパクって実装するときは
符合していた方が間違いが少なくてデバッグが楽だった。
118 :仕様書無しさん2010/03/11(木) 18:53:08
>>115
見難いっていうのは有るね
数学式で n, m は個数を表すものとして使用されて i, j  がカウンタ変数として使用されていたのがそのまま使われたと思うんだけど
手書きでは識別しやすくてもフォントに起こすと識別しにくかったって事なのかな
でも i, k, o, p の順でループ作ると j, や l は何処に行ったんだと騒ぐ奴が出そう

>>116
『ソースコードを読めるAI』が何故視認しなければならないかが疑問だな
ネタにマジレスカッコ悪い、自分で書いとくわ
119 :仕様書無しさん2010/03/11(木) 19:13:54
アホコテにマジレスは不要
本人が「ネタ」のつもりらしいから
120 :仕様書無しさん2010/03/11(木) 21:39:42
>>118
【プログラマは】uyのプログ... Part2.1【ゴミ】
http://pc11.2ch.net/test/read.cgi/prog/1267804456/
121 :仕様書無しさん2010/03/11(木) 22:59:20
ちょっとまえC#で仕事をしてるときのことだけど、.netのDB関連のクラスを
ラップして、ひとまとめにしたクラスを渡されてこれを使ってねって言われた。

コネクションのクラスとか、コマンドのクラスとか、トランザクションのクラスとか
そういうのを全部ひとつのクラスにぶちこんで、
hogeDb.Connect();
hogeDb.BeginTransaction();
hogeDb.sqlSql(".....");
hogeDb.setParam(...);
hogeDb.exec();
hogeDb.commit();
hogeDb.Close();
みたいに使うのな。

で、いまPHPで仕事してたら、グラフ作成関連の細かいクラスをやっぱ全部
一つのクラスにぶち込んでるようなクラスを使えって言われた。

なんでへぼいやつって、そろいもそろってこういうのが好きなのか。
123 :仕様書無しさん2010/03/11(木) 23:45:53
>>121 おまえ、こいつか? http://pc12.2ch.net/test/read.cgi/tech/1170599322/521
124 :仕様書無しさん2010/03/11(木) 23:50:38
>>123
おまえ、見えない敵と戦ってね?
125 :仕様書無しさん2010/03/12(金) 08:42:37
>>121 は謎すぎる
こうゆうのってのが何を意味するのか教えてくれ
128 :仕様書無しさん2010/03/12(金) 13:37:50
>>121,125
一人で開発している分には不要だと思うけど
多人数でやっている場合には、機能毎にある程度まとめてラッピングした共通クラスを用意しておいた方が、
いざDB周りなどの仕様を変えたいときに楽

同じ処理やらせるにしてもPG毎に方言は出てくるし、同一のコードを異なるソースに書くのは非常に無駄だし、
後の修正面考えたら非効率でもあるので、アプリのコードはアプリのソース、共通のコードは共通のソースと分けて、
コードの一律化をはかって、担当のPGにはそういうのを意識させないために用意するね

また大概は、DB周りはクリティカルな例外を起こすのでラッピングして、そのとき例外時のエラーメッセージ、中断処理なども仕込んでおくことも多いね
そもそも、そういう共通部分はPG毎にかかせたら、絶対に例外処理なんかをかかない奴が続出するの目に見えていて、
バグの元になるのは目に見えているしな('A`)

まぁ、なんでこんなの用意するんだろうと考えられるのは、ヘボもまともなコードになるように、
こういう部分をうまく隠してもらえているせいであって、ある意味幸せなPGだと思うよw
129 :仕様書無しさん2010/03/12(金) 13:48:58
あ、一人で開発でもいるな。
いらないのは、1本のプログラムだけとかそういうときだけだな

2本以上のプログラムで、機能としてくくれる部分は、機能としてまとめるべき
130 :仕様書無しさん2010/03/12(金) 20:06:59
>>121
結局どうしたいの?どうなっていて欲しいの?どういうのが理想だと思うわけ?
131 :1252010/03/12(金) 22:19:01
>>128
俺にアンカー向けるなよ
俺が疑問なのは >>121 が何を言いたいかなんだから
132 :仕様書無しさん2010/03/13(土) 01:39:34
>>128
>いざDB周りなどの仕様を変えたいときに楽

元の.netのDB関連のクラスも十分抽象化されてる

>ヘボもまともなコードになるように、
>こういう部分をうまく隠してもらえているせいであって、

標準のDB関連クラスと処理の粒度がおなじで、まったく隠してないだろ。
処理を共通化したいなら、もっと粒度の大きいレベルでやれ。

>>121みたいなクラスを使って標準クラスに比べてなんかコードの質がよくなる要素があるのか。
だいたい、DBへのコネクションとかトランザクションとかそういう下請け的な処理で、
内部で勝手にエラーメッセージだすとか、筋が悪すぎるだろ。
エラーが起きたら例外も中でつぶして、リターン値で判定させるとか考えてんの?
ほんとうにダメすぎ。
手続き型的に処理を上から下に並べるしか考えられないおっさんの発想だろ。>>121とか。
133 :仕様書無しさん2010/03/13(土) 03:32:41
>>132
粒度が同じでもラップしてログ(正常系を含む)を埋め込む事に意味は有るよ
ログ出力を重視しない処理系なら関係ないだろうけどね
そもそも >>121 のグラフ作成関数なんかだと粒度も大きいと思うけどね

エラーや例外が起きたらログを出力した後に上位にリターン値で伝播するのは非常に一般的な手法だけど何故『ダメすぎ』なの?
納品したシステムが不具合を起こした場合、客先から得られる情報はシスログだけだったりする
シスログを見ただけで問題点を発見するには細かいログが必要だから下位関数がだんまりだと困るよ
134 :仕様書無しさん2010/03/13(土) 06:22:07
>>128の日本語訳:
「だって、いっぱいクラス覚えるの面倒なんだもん」
135 :仕様書無しさん2010/03/13(土) 15:23:40
グラフ作成のクラスライブラリも、表示エリア、プロットデータ、マーカー、座標軸とか細かく分かれてない?
おれもそんなにたくさんしらんけど、そういうタイプのを一つにまとめるなって文句言ってるんでしょ。
あと、エラーメッセージとか扱うならフレームワークみたいな役割のクラスに任せるのがいいと思う。
下請けみたいなクラスにやらせるのはどうかね。
DB 関連の処理にログを吐かせるのも無くはないと思うけど、クラスを一個にまとめちゃうのとは別の話だよね。
136 :仕様書無しさん2010/03/13(土) 16:39:53
> DB 関連の処理にログを吐かせるのも無くはないと思うけど、クラスを一個にまとめちゃうのとは別の話だよね。

別な話だよ、粒度が同じでもラップする意味は有るって書いたんだけど理解できなかった?
137 :仕様書無しさん2010/03/13(土) 16:50:27
>>121 は言語の方で用意されてる機能ならコメント一切書かないとかやりそうで怖い
138 :仕様書無しさん2010/03/13(土) 16:52:56
>>134
アンカーミスってない? >>121 じゃないの?
>>121 が言っているラップクラスは元のライブラリに接頭文字を付けた程度だから『いっぱいクラス〜』って指摘も的を射ていないけどね

>>121 は若い人だと思う
無駄な事してるって考えるのは良い事だけど、何故そうしてるか問わないのはどうかな
明快な理由が帰って来なかったその時始めて罵倒すれば良いと思う
141 :仕様書無しさん2010/03/13(土) 17:49:19
>>138の読解力の低さに唖然とした
142 :仕様書無しさん2010/03/13(土) 19:08:33
>>136
別な話をあたかも反論のように書いてたのか。
143 :仕様書無しさん2010/03/13(土) 19:15:02
>>136
だから、一個にまとめなくてもラップはできるじゃん。
ラップするのと一個にまとめるのとは別の話で、一個にまとめるのを避難してるカキコに
「ラップするから一個にするのも意味がある」って反論しても意味ないだろ。
(この場合はせっかく抽象クラスが用意されてるからラップよりそれを使う方がいいか)
144 :仕様書無しさん2010/03/14(日) 00:55:21
>>121 は一つのクラスにまとめる事を否定してるのか?粒度の低い抽象化を否定してると思っていたけど
もっとも >>121 は問題点が明確ではないし、粒度について触れているのは >>132 だったね
「ラップするから一個にするのも意味がある」なんて誰が何処に書いたの?

では『まとめる』事について
DB関連の例だとほとんどのメソッドは使用されるはずなので一つのクラスにまとめるデメリットは無いはずだ
グラフの例だとC++なら共通メソッドのみをスーパークラスとしグラフ種毎にサブクラスを作成するべきだけど、
サブクラスのソースが短い場合はファイル管理の都合上、複数をまとめる可能性も有るだろう
そもそもPHPに派生って概念が有るか知らないけど

実際100ステップ程度のソースが山ほど有ると管理が面倒くさい
オブジェクトサイズのデメリットが気にならない環境なら、ファイル管理効率の為に類似処理を一つのソースに
まとめる事は大きな問題では無いよ
145 :仕様書無しさん2010/03/14(日) 07:07:06
>>144の読解力の低さに唖然とした。
146 :仕様書無しさん2010/03/14(日) 16:50:34
>>144
「ひとつにぶち込んでる」→「ヘボいやつ」って書いてあるな。
147 :仕様書無しさん2010/03/14(日) 17:59:09
>>144は始まりに過ぎなかったのだ・・・

Pre粒度...
148 :1442010/03/14(日) 20:09:53
俺の読解力が話題の中心にシフトしてるなw

>>121 の文章から『まとめる』事を問題視してると感じなかったのは何故『まとめる』事が『ヘボい』のか理由が書かれてないからだ
ちなみに >>125 も俺なんだが >>121 が何を問題視してるか全くわからなかった
それに対して >>128 がラップの有用性を説いたが、>>132 が反論として粒度について触れた
俺は問題点を粒度と捉えて >>133 や >>135 を書いたんだが >>143 がトンチンカンな反論してきたので >>144 で答えた

まぁ経緯はどうでも良いけど >>121 及び同調する奴は『何故まとめる事はヘボい事なのか』を書いて欲しいな
149 :仕様書無しさん2010/03/14(日) 20:28:28
>>148
>>135はお前が書いたんじゃないだろ。
150 :仕様書無しさん2010/03/14(日) 20:42:43
それぞれ役割ごとに分かれるクラスを一個にまとめるのやつがへぼい

ログとかエラーメッセージとか出させるからラップするのは有用

ラップするのと、分かれてるクラスを一個にのは別の話だろ。
(分かれたままでもラップすることはできる)

って流れなんで、>>143は頓珍漢でもなんでもない。まっとうな指摘。
151 :1352010/03/14(日) 20:59:45
とりあえず後だしじゃんけんするなとだけ言っておく
152 :仕様書無しさん2010/03/14(日) 21:10:31
>>149
御免間違えた >>136 ね
153 :仕様書無しさん2010/03/14(日) 21:20:50
>>150
全く分かってないな
>>133 で『粒度が同じでもラップする事に意味が有る場合も有る』って書いたのは粒度について触れた >>132 に対するレスだ
そもそもその段階では『まとめる』事が主題だという意識は無いしね
アンカーってなんの為に付けてるんだろう...
154 :仕様書無しさん2010/03/14(日) 21:25:57
>>150
細かい経緯なんてどうでも良いんだよ
俺が知りたいのは関連処理をクラスにまとめる事を何故ヘボいと感じるかなんだよ
もしくは何のデメリットを危惧してるのかとかね
>>121 ってもう居ないの?
155 :仕様書無しさん2010/03/14(日) 21:35:35
>>154
細かいことはいいなら、最初から頓珍漢とか言うなよ。
156 :仕様書無しさん2010/03/14(日) 21:39:36
>>153
アンカーは>>121から、>>133まで連続してるんで、>>121からの流れだね。
自分は違う話題をしてるつもりとか、なんのためのアンカーなんだろ。
157 :仕様書無しさん2010/03/14(日) 21:41:26
>>151
なんで名前が135なんだ。なんかのミスか。
158 :仕様書無しさん2010/03/14(日) 21:51:23
>>156
流れw もう面倒だから反論しないよ
159 :1512010/03/14(日) 21:54:14
自己主張したけりゃコテ付けろやw
160 :仕様書無しさん2010/03/14(日) 21:56:25
>>158
技術的な話じゃなくて、おれはそんなことを言ってるつもりじゃないとか、
ああいった、そういうつもりじゃないとか、そんな話ばっかりだもんな。
もう辞めた方がいいよ。
161 :仕様書無しさん2010/03/14(日) 21:59:11
>>159
そりゃ逆だろ。なんで自己主張したいってことになってるんだ。
162 :仕様書無しさん2010/03/14(日) 22:37:45
>>160
うん、知りたいのは >>121 の意図だけなんだ
もし >>121 が現場を知らないだけなら良いんだけど、我々が気付かないデメリットについて危惧してるのならば知りたいよ
関数一つをラップする事も使われないメソッドが山ほどぶら下がったクラスが存在する事も現場では何の疑問も持たないよね
それは理由も知ってるしデメリットが小さい事も知ってるからだ
それに対して不満を持つフレッシュな感覚から出た危惧点なら少しは意識すべきではないかなと思う
我々が気付けない問題点を教えて貰えれば、それが有効な考えであるか否かを論じれるし、有効であれば自分の実装にも生かせると思う
まぁ、後者にはほとんど期待してないけどね
163 :仕様書無しさん2010/03/15(月) 00:36:11
>>162
なんのメリットもないのに、デメリットがないってだけで同じ機能のクラスを作ってたらふつーにだめでしょ。
(デメリットはあるけど)

GUIで、ウインドウクラスやら、ボタンクラスやらテキストボックスクラスやらぶち込んでまとめちゃったら
さすがにだれでもアホだって気づくはずだけど。

DBとかグラフ作成のクラスでそれをやっちゃう人がいるってのは、具体的なものをオブジェクトとして
扱うのはわかるけど、トランザクションとかコマンドみたいな状態とか抽象的なことをオブジェクトと
して認識するのに抵抗があって、そういう構成のクラスライブラリを使いにくいって感じちゃうんだろうね。
164 :仕様書無しさん2010/03/15(月) 01:03:45
>>121
>>130
165 :仕様書無しさん2010/03/15(月) 02:21:30
>>130 >>164
ひとつにぶちこんでるのをdisってるから、そうしないのが理想なんだろ。
それ以外に解釈のしようがあるのか。
166 :仕様書無しさん2010/03/15(月) 09:31:31
その理想とやらがさっぱり浮かばないなぁ
なんというか、ラッピングとか上等な話じゃなくて、>>121だと単に「ろくに仕様がわかってないんだから、こっちで用意したものを使ってくれ」ってことで用意されたものだろ
168 :仕様書無しさん2010/03/15(月) 21:15:01
>>163
『ふつーにダメ』は理由と呼べないな
先に示したログの件も有るし、抽象度(粒度)の高いメソッドを実装する予定があって派生(もしくは作成)したかも知れない
その辺の意図は作った人に聞いてみれば良い

『GUIで〜ぶち込んでまとめちゃったら』ってどうやってやるの?多重継承?
例え作るのも知識が無いと苦しいよね

最後のブロックは何を言いたいか不明なのでレス不可
トランザクションもデータの一種なのでクラスを適用してる現場も有るよ
169 :1682010/03/15(月) 21:17:08
×例え作るのも知識が無いと苦しいよね 

○『例え』を作るにも知識が無いと苦しいよね 
170 :仕様書無しさん2010/03/15(月) 22:00:08
>>166
それなら処理の粒度をあげたのを渡さないと。
元の.netのライブラリとおんなじような粒度で、だた一個にまとめただけじゃ意味がない。

元のを使えないと、使えないようなライブラリ渡して「これで使いやすくなっただろ」とか
言ってるから、ヘボいって2chに書かれてる。
171 :仕様書無しさん2010/03/15(月) 22:09:12
>>168
>『GUIで〜ぶち込んでまとめちゃったら』ってどうやってやるの?多重継承?
>例え作るのも知識が無いと苦しいよね

最初にだしたDBクラスと同じように作るってこと。
このDBクラスって筋が悪いねってたとえ。
>>121のクラスの筋の悪さがわからないあんたでも、GUIで例えたら無理なクラスだって
一発でわかったってことは、すごい適切な例だったことだな。

>最後のブロックは何を言いたいか不明なのでレス不可
>トランザクションもデータの一種なのでクラスを適用してる現場も有るよ

それはわかってるよ。
それがわからないような人だらか、適切なクラスで作られたクラスライブライブラリを
一つにまとめるなんてことをしてるんじゃないかって推測してるんじゃん。

その推測はおかしいって反論ならわかるけど、俺が言ってることと同じことを繰り返して
反論ってのはおかしいよ。
172 :1682010/03/15(月) 22:34:10
>>171 を誰か翻訳してくれ orz
173 :仕様書無しさん2010/03/15(月) 22:47:58
>>172
反論ができないから、わざとピンぼけの受け答えをしてるのか、
まじで読めないのかわからないからやめろよ。
174 :仕様書無しさん2010/03/15(月) 22:49:19
いつも言い訳ばっかりしてそうだなw上司に嫌われるタイプ
本人じゃなくてもいいから、誰か簡潔に>>121の改善案を出せよw
175 :仕様書無しさん2010/03/15(月) 22:56:28
>>174
繰り返し言ってるじゃん。
>>121のクラスを使わなければいいんだよ。
176 :仕様書無しさん2010/03/15(月) 23:09:29
むしろ>>121のどこがいいと思ってるのか説明しろよ。

↓ガイシュツの説明は反論済みだから繰り返さないでね。

理由 ラップしてエラーメッセージやログ出力を組み込むんだよ
反論 こんな下請けクラスにメッセージ出させるなよ
   ログは、まあ、なくなないけど、こんな不格好にひとまとめにしなくてももとの構造を
   保ったままラップできるだろ
   あとラップより抽象クラスつかったほうが筋がいいね

理由 おまえみたいな低レベルでもつかえるようにしてやってるんだよ
   低レベルが何人もいる現場なら処理のやりかたが統一できるしな
反論 もとのクラスに比べてぜんぜん簡単になってないだろ。
   ぎゃくに使い勝って悪くなってる。
   処理の粒度がおなじだから、統一の役にもたたねえ

理由 はぁ、なんか>>121を使うデメリットあるのか
反論 メリットがないのに、独自クラスとかそれ事態だがデメリットだよ
177 :仕様書無しさん2010/03/15(月) 23:21:53
>>176
これに対する反論が無いようだね
理由:抽象度(粒度)の高いメソッドを実装する予定があって派生(もしくは作成)したかも知れない 

抽象クラスの概念を理解していないようだけど大丈夫?
178 :仕様書無しさん2010/03/15(月) 23:28:59
>>176
誰か書いてくれるかなと思ってずっと書かなかった理由もそろそろ書こうかな...

理由:DBアクセス関連で構築するコード群にポータビリティを持たせたい
 その為には環境依存であるクラスメソッドを直接コールしないでラップクラスをコールして実装し、
 環境によってラップクラスを変更する事で対応すればコードの修正量が減少する
179 :仕様書無しさん2010/03/15(月) 23:37:08
>>177
粒度と抽象度は別の概念だけど、どっちのことだろ。
抽象クラスはもうあるから、あらたに作る意味がわからない。
あとで粒度の高いクラスを作るつもりでも、今現在、標準クラスの構造を変える意味がわからない。

>>178
ポータビリティーをもたせたいなら、標準の抽象クラスをつかったほうがいいね。
あらたに使いにくいクラスを作成する意味がない。
180 :仕様書無しさん2010/03/16(火) 00:13:43
>>179
メソッドに対して用いるなら粒度も抽象度も同じ概念だよ
1メソッドに多くの処理を含む=粒度が高い=抽象度が高い

抽象クラスが既に有るって何の話?標準クラスとは?
標準クラスがライブラリで提供されているクラスを意味するならその構造を変える事はできないよね
できるのは標準クラス(?)から派生させたクラスにメンバ・メソッドを追加することで >>121 にあるラップクラスがそれだろ

標準の抽象クラスって何?

抽象クラスで検索する事を強くお勧めする
181 :仕様書無しさん2010/03/16(火) 00:40:25
>>180
>メソッドに対して用いるなら粒度も抽象度も同じ概念だよ

処理の粒度って書いてるだろ。
つられておれも「抽象度」ってかいちゃったけど、抽象度って言葉が急にでてきたな。
抽象度じゃなくて抽象クラスって言葉しか使ってなかったけど。

> できるのは標準クラス(?)から派生させたクラスにメンバ・メソッドを追加することで
> >>121 にあるラップクラスがそれだろ

>>121は標準クラスから派生させていない。みればわかるだろ。
こんなのが標準クラスだったら、MSはおしまいだ。

>標準の抽象クラスって何?

あるだろ。
(abstractクラスじゃなくてinterfaceだとか、そういう揚げ足とりじゃないよな。
どっちでも論旨は同じだし)
182 :仕様書無しさん2010/03/16(火) 00:46:19
>抽象クラスが既に有るって何の話?標準クラスとは?
>標準クラスがライブラリで提供されているクラスを意味するならその構造を変える事はできないよね
>できるのは標準クラス(?)から派生させたクラスにメンバ・メソッドを追加することで >>121 にあるラップクラスがそれだろ

っていうか、こういう認識で>>121がいいとか言って絡んでたのかよ。
ひでえ。まったく時間の無駄だった。
183 :仕様書無しさん2010/03/16(火) 00:52:57
まあ、時間の無駄は最初からわかってたからいいか。
まともな感覚なら>>121がいいとか言わねえもんな。

元のクラスがどうなってて、>>121とどう違ってるかとかも認識してなくて
わかったような口ぶりでへりくつ言ってたんだもんな。
184 :仕様書無しさん2010/03/16(火) 01:19:51
>>181
抽象度は抽象化の度合いね、抽象クラスとは全く関係ない

>>121 が標準クラス(MSで提供してるクラス?)からの派生かどうかを >>121 見て判断できるのか?
>>121 は単にメソッドを並べてるだけだから判断はつかないよ
もっとも派生クラスであれ定義したクラスであれたいした差は無いけどね
ポータビリティを考えると基底クラスのメソッドを直にコールする馬鹿が出ない様にあえて派生させていないかも知れないし

インターフェイスクラスの事を抽象クラスって呼ぶんだ、ふーんw

とにかくポータビリティの為にラップクラスをかませる事のメリットに対する反論は?
>>121 のラップクラスがどんなにクソクラスでも直に標準クラスのメソッドをコールするより良い場合は有るよ

>>182-183
罵倒だけには反論のしようが無い
185 :仕様書無しさん2010/03/16(火) 04:08:09
そろそろ>>121はコテハンを付けないか。
191 :仕様書無しさん2010/03/16(火) 18:23:23
法学の奴らの会話みてーだな
もっと論理的にビシッといけよ
192 :仕様書無しさん2010/03/16(火) 20:43:40
>>184
> >>121 は単にメソッドを並べてるだけだから判断はつかないよ

おまえの技術力がよくわかった。コテハンつけてくれ。NGするから。
193 :仕様書無しさん2010/03/16(火) 21:04:52
>>192
派生クラスに他のクラスをメンバとして追加する事も、それを使用したメソッドを追加する事もなんら珍しく無いと思うけど?
君の言う『標準クラスの構造を変える』って事はそういう事を指すのかな?

>>121 に強いてケチをつけるなら大文字と小文字の使い分けに疑問が有るかな
もっとも実装を見れば何らかの意図を汲み取れるかも知れないけどね
194 :仕様書無しさん2010/03/16(火) 23:00:41
>>180
> できるのは標準クラス(?)から派生させたクラスにメンバ・メソッドを追加することで >>121 にあるラップクラスがそれだろ

↑この人は >>121の「へぼいやつが作った関連クラスを一つのクラスにぶちこんだクラス」ってのをみて

class HogeDB : IDbConnection, IDbCommand, IDataReader…

みたいなクラスを思い浮かべて、これのどこが悪いって暴れてたんだ。

よくオブジェクト指向の入門書なんかにのってる継承と集約の説明で、車クラスなんかを例に
だして、タイヤクラスやエンジンクラスは車の部品だから、車クラスに集約してあつかうみたいな
説明があるけど、この人は、タイヤクラスやエンジンクラスを継承して車クラスを作っちゃう
センスなんだ。

>>184
>>121 が標準クラス(MSで提供してるクラス?)からの派生かどうかを >>121 見て判断できるのか?

普通のセンスだったら、上のコードのような実装はあり得ないから、派生クラスでないって判断できるね。
>>121のコードより数段ひどい。
現場で見たら失笑もんだよ。

> インターフェイスクラスの事を抽象クラスって呼ぶんだ、ふーんw

この話題のばあい、抽象クラスとインターフェースと厳密に区別する意味が
ないんで、まとめて抽象クラスって言ってもまったく問題ないですね。
逆に、C++のように言語仕様上インターフェースがない言語でも、話題に
よっては、インターフェースと抽象クラス使い分けるし。
195 :仕様書無しさん2010/03/16(火) 23:05:26
まあ、でもこの件は >>176-179 のまとめで終わりだな。
あとは、ことばの定義どうこうみたいな、論旨とは関係ない
揚げ足とりしかでてこないだろうし。
196 :仕様書無しさん2010/03/17(水) 00:00:07
こんなんじゃオブジェクト指向が普及しないわけだ
俺の職場にこのへんの議論を理解できる奴、一人もいないわ
>>194の説明でやっとある程度見えたけど
197 :仕様書無しさん2010/03/17(水) 00:03:38
>>194
それは誤解だね、そもそもインターフェースクラスからの継承イメージは無く、例えばOBDCクラスからの継承をイメージしていた

class Hoge : OdbcConnection
{
  private OdbcCommnad mCommnad;
  private OdbcDataReader mReader:
  ...

みたいなのをイメージしてた
継承しないなら private OdbcConnection mConnection; がメンバに追加される事になるだけの違いだ

>>193 を読めば判ると思うけど
198 :仕様書無しさん2010/03/17(水) 00:16:07
>>197
集約で作ってるのに、OdncConnectionだけ継承って意味がわからない。

あと、DBとロジックを分離させたかったら、具象を継承するんじゃなくて
抽象クラス(インターフェース)を使った方がいいね。
より疎結合になるよ。

クラスも独自に作って構造を変えちゃうより、標準のやつを使った方がいい。
199 :仕様書無しさん2010/03/17(水) 00:23:25
> 継承しないなら private OdbcConnection mConnection; がメンバに追加される事になるだけの違いだ

その違いは(本質的には)大きな違いじゃないか
今の文脈だと確かにどうでもいいかもわからんが
200 :仕様書無しさん2010/03/17(水) 00:40:54
>>198
まぁ理由が有るとすれば手抜きだね
Open() とか Close() を定義しなくても良いから
最初にそう感じたのは >>121 で Connection 関連メソッドだけ大文字だったからなんだけどね

疎結合にする目的ってポータビリティだよね
でも実はこの目的って C# の現場で必要有るのかって気がする(移植先なんて有るのか?)
>>178 で嫌々書いたのはそんな理由なんで >>121 のケースだと気にしなくて良いと思う

標準のクラスをラップしただけだとバカチョンクラスにならないからじゃないのかな
世の中にはSQL書けるだけの人も居るからそういう人でも使える様にって
『バカチョンクラス』も『SQL書けるだけの人』も侮辱する意図は無いよ(バカチョン自体は差別語だけど)

>>199
勿論、用途によって使い分けるべき、 >>121 を何故判別できないかの理由として書いた
201 :仕様書無しさん2010/03/17(水) 01:03:23
>>200
> でも実はこの目的って C# の現場で必要有るのかって気がする
>(移植先なんて有るのか?)

DBを変更する場合は考えられるね。
DBも変更する可能性もOに近いときでも、具象でも抽象でも使う手間は
変わらないんで抽象をつかうほうがベター。
(DBはSQLの方言とか、どうしても吸収しきれない所もあるけど)

> >>178 で嫌々書いたのはそんな理由なんで >>121 のケースだと気にしな
> くて良いと思う

>>121の作りはポータビリティー理由で正当化されるって説は引っ込めることっすね。
了解です。

> 標準のクラスをラップしただけだとバカチョンクラスにならないからじゃないのかな

>>176-179のまとめでも書いたけど、>>121の場合、処理を元のクラスと同じような
粒度でメソッドにしてるんで簡単にはなってないね。
逆に、usingとかつかえなくなって、クラスを利用するのがめんどくさくなってる。
バカちょんクラスなら、もっと思い切って簡素な使い方にしてあげないと、
かえって学習コストが高くなりそう。
202 :仕様書無しさん2010/03/17(水) 01:07:59
C#ならこーゆーのはジャマなだけだと思うなあ
PHP(フレームワークなし)とかならまだ利用価値があるだろうけど
204 :仕様書無しさん2010/03/17(水) 01:48:45
>>201
今時 M$ のクラスに適合しないDBなんか有るのかね
具象と抽象の実装コストは抽象の方が高いよ
DB使ったビジネスアプリにそんな手間かけるのはナンセンスてのが大方の見解じゃないの

可搬性もビジネスアプリにww

簡単になってるんじゃないの
hogeDB のメソッド呼ぶだけで事が全部足りるんだから Query定義クラスがどうのとか知らなくてもSQL文法だけ知ってれば使えるよ
>>121 以上に粒度を上げると対応できないケースも出てきそうだ(Connect() と BeginTran() はまとめても良いかもしれんけど)
粒度を上げたもっとバカチョンなメソッドを用意しても良いかも知れないね
学習コストは低いだろ、引数あるメソッドが setSql() と setParam() しかないんだから、せいぜいリターン値くらいか
205 :仕様書無しさん2010/03/17(水) 02:08:44
>>204
> 今時 M$ のクラスに適合しないDBなんか有るのかね

最初からそれは問題になってない。
具象だと適合してるDBでも変更のコストはかかるね。

> 具象と抽象の実装コストは抽象の方が高いよ

ほとんど変わらないよね。
徹底的にやろうとすると、ちょっとファクトリメソッドやらファクトリクラス
やらがいるかもしれないけど。

> 簡単になってるんじゃないの

なってないよ。
標準のクラスを使って書いた場合とコードの複雑さは変わらないか
よけい複雑になるか。

> 学習コストは低いだろ

高いね。
こからこのクラスに関わる人は全員このクラスの使い方を新たに調べなきゃならない。

標準クラスだけで作ってたら、そのクラスに関するは知識が使い回せる。
ドキュメント、資料もばっちり。
206 :仕様書無しさん2010/03/17(水) 02:18:21
っていうか、>>176-179でまとめてるんだから、反論するなら
繰り返すんじゃなくて、べつの視点とか、詳細にするとか
してほしいよね。
俺は詳細な突っ込みがきたら詳細に反論するけど、おんなじ突っ込みを
繰り返してるのには、おんなじ反論しかしないから、ループするだけだよ。

もうちょっとがんばって勉強してほしい。
207 :仕様書無しさん2010/03/17(水) 02:28:33
>>205
簡単になってるとか学習コストに関しては対象者のフレームワークに関する知識が関係する
フレームワークに精通している人にとっては標準ライブラリのクラスを使用した方が楽かも知れないけど、
C#とSQLの文法だけ知ってますってレベルの人にとっては hogeDB の方が圧倒的に簡単だ

どんな現場か知らないけど派遣が入ってる現場だとプロジェクトメンバーの質はまちまちだから、
プロマネはフレームワーク未熟者にも対応できるインフラを用意しなければならない
フレームワーク精通者は『こんなクソクラス使わせるな』と不満を感じるだろうがそれだけの話だ

未熟者を切り捨てるか?未熟者レベルに合わせるか?ビジネスアプリではどっちが一般的だろう

この件に関しては水掛け論にしかならないからこれで止めるよ
208 :仕様書無しさん2010/03/17(水) 02:30:16
> 具象と抽象の実装コストは抽象の方が高いよ

前も、なんかいろいろわかったような口ぶりでいろいろ書いてたけど
結局、標準のクラスと>>121のクラスがどのくらい違うか知らないで
書いてたし、↑これもDBの具象クラスと抽象クラスを使って書いた場合
どのていど違うコードか把握しないで、勘で書いてるんでしょ。
(で、こういう突っ込みを入れられてから慌てて調べるとか)

こんなんにつきあわされる身になってほしい。(とか言ってみる
209 :仕様書無しさん2010/03/17(水) 02:38:57
>>207
> C#とSQLの文法だけ知ってますってレベルの人にとっては hogeDB の方が圧倒的に簡単だ

C#の文法を知ってれば標準のクラスも簡単でしょ。
サンプル見れば一発のレベル。

hogeDBは別に標準クラスに比べて簡単じゃないよ。
標準クラスの使い方を知ってないと使えないレベル。
よけいめんどくさい。

> この件に関しては水掛け論にしかならないからこれで止めるよ

水掛け論に入る前に、hogeDBが簡単って前提が間違ってるしな。
>>206でも書いたけど、hogeDBで書いたらこんなに簡単になるとか
もっと踏み込んだ論証で反論してほしいよね。
210 :仕様書無しさん2010/03/17(水) 02:43:14
>>121以降ここまで>>121書き込んでないと思うんだけどどうよ?
>>121はコレ使えって言われた後メリット聞くとかデメリット説明してクラスの使用をやめる方向に持って行くよう説得するとかしてないんだろ?
211 :仕様書無しさん2010/03/17(水) 02:46:28
121は文章読んでもわかるとおり
はいはいと従うしかない立場だろJK
212 :仕様書無しさん2010/03/17(水) 02:59:50
>>121 が簡単簡単言われてるけど、まさか>>121がそのまま
使われてると思ってないよな。
エラーチェックとか例外とかループとかなしで一直線にメソッドを並べてるだけとか。

これは、うろ覚えで、こんな感じですよってのを適当に打ち込んだだけだ。

こんな細かさでメソッドが作られてて、>>121みたいな使われ方はできないだろJK
念のため。
213 :仕様書無しさん2010/03/17(水) 03:05:45
上のほうで、connect()とbeginTran()をまとめてもいいかもとか
書いてるから、>>121のコードがそのまま使われると思ってるっぽいな。
214 :仕様書無しさん2010/03/17(水) 03:07:03
>>210
>>212 は >>121 みたいだけど説得する立場には無いんだろうな、ちゅか昔の現場の話かな

>>212
戻り値チェックが無いコードはお遊びプログラムだけだし、このスレには仕事でコード書いてる人しか居ないはずだよ
215 :仕様書無しさん2010/03/17(水) 03:14:56
引数が少なくて>>121は使いやすいとかって発言とか、メソッドの
大文字小文字もおかしいとかってあるけど、
うろおぼえで適当にかいたから、もちろん、そんなもん適当に書いてるよ。
216 :仕様書無しさん2010/03/17(水) 03:16:56
>>209
HogeDBが簡単かどうかが水掛け論になるって話だよ

HogeDB を用いたらこんなにステップが短くなりましたって話はしてないよ
一つ断言できるのは HogeDB を使って書いた部分は誰が書いても同じような個性の無いコードになるだろうね
これはライブラリを直に叩いても同じかもしれないけど HogeDB を使った方が確実だ

>>213
処理ごとにエラーチェックして戻り値でステータス返すのは抽象化の基本だけどね
217 :仕様書無しさん2010/03/17(水) 03:26:22
>>216
> これはライブラリを直に叩いても同じかもしれないけど HogeDB
> を使った方が確実だ

同じでしょ。
大昔、Pascalがはやったとき、Pascalは教育用の言語でシンプルだから
誰が書いても同じコードになるとかデマが流れたけど、そんなん大嘘だったし。
こんなので無個性化は無理。標準と同程度。

> 処理ごとにエラーチェックして戻り値でステータス返すのは抽象化の
> 基本だけどね

connect()とbeginTran()がまとまる話との関連がわからない。
めんどくさくでなかったらでいいけど、詳しく。


218 :仕様書無しさん2010/03/17(水) 03:29:47
>>216
> HogeDBが簡単かどうかが水掛け論になるって話だよ

水掛け論にはならないよ。
ほげと標準でコードを書いてみて、ならべれば一発じゃん。
やらなくても考えればわかるけどね。
同じ粒度の処理で、同じように処理したら、コードも同程度の複雑さになる。
hogeはusingとか、便利な構文が使えないから、よけい行数が増えると思われる。
219 :仕様書無しさん2010/03/17(水) 03:40:13
>HogeDB を用いたらこんなにステップが短くなりましたって話はしてないよ

ああ、検証不能だけど、ヘボい人たちにはきっと使いやすいはずだって話かな。
むしろヘボい人たちって、コード行数とか目に見えて減らないと、使いやすさ
を実感できないと思うよ。


220 :仕様書無しさん2010/03/17(水) 03:42:30
>>217
>>213 がまとめてエラーチェックも何も無いコードを書くつもりかって読めたからそんなコード書く奴は居ないだろって事
>>214 でも同じ事書いたな、寝ぼけてきたかも知れん

>>218
HogeDB の仕様が無いから並べられないよ、検証方法がないから水掛け論だって
221 :仕様書無しさん2010/03/17(水) 03:50:25
>>220
仕様は>>121で十分でしょ。
標準クラスつくって、やるのと同じような粒度。
エラー処理は、リターン値か例外かわかんけど。

いままでずっとその前提で話が進んできたし、それもあやふやで
だめだって話なら、なにかも仮定ができないから、まず自分の「簡単だ」
って前提もすててよ。
「簡単だ」って言うくらいだから、ある程度自分でも仕様の
イメージあるんでしょ。
222 :仕様書無しさん2010/03/17(水) 04:06:38
>>218
using 使う局面もそんなに無いと思うよ
HogeDB 以外に生成するべきオブジェクトは無いし、DBみたいな資源オブジェクトは上位で作成して下位は使いまわす事も多いからね
行儀は悪いけど効率は良い

>>221
>>207 については?
君の言うヘボの目から見て簡単かどうかは擬似サンプル並べたって判別できないでしょ
C#をほとんど知らないヘボに見てもらわないとね
223 :仕様書無しさん2010/03/17(水) 04:16:46
粒度とかは関係なく、ヘボの目から見れば対象クラスが一つであるというだけで
「使いやすい」と思えるものじゃないかな

で、現場ではそういうヘボのために hogeDb のようなクラスが量産される
悲しいかなこれが現実
224 :仕様書無しさん2010/03/17(水) 04:28:49
>>222
> using 使う局面もそんなに無いと思うよ
> HogeDB 以外に生成するべきオブジェクトは無いし、

usingを使いたい局面はおなじだよ。
内部に各種クラスのインスタンスを抱え込んでるんだから。
でも、それを外側からユーザーがメソッド越しに操作する必要があるから、
使いにくいって言ってる。

> 君の言うヘボの目から見て簡単かどうかは擬似
> サンプル並べたって判別できないでしょ
> C#をほとんど知らないヘボに見てもらわないとね

判断不能だけど>>121は標準クラスに比べて簡単だって思ってるんでしょ?
簡単だってのは根拠のない自分の思い込みってこと?
225 :仕様書無しさん2010/03/17(水) 04:35:57
>>223
ま、そうかもね。
でも、Javaとかの現場で、ヘボが大量にいるところとかでみてると、
ヘボも、すでにできているコードをコピってちょろちょろ改造とか
けっこう適応力はあるもんなんだけどね。
226 :仕様書無しさん2010/03/17(水) 04:45:03
>>224
外側からメソッド越しに操作する必要はないだろ
HogeDB 内部で生成してエラーを検出したら例外なりエラーコードで返すんだから

もう思い込みでも何でも良いよ
ここのスレタイを思い出してくれよ
クソだと言う人と擁護する人が半々くらいで延々と100レスくらい消化してる
これは大したクソではないということ
例えてみればKOTYにFF13をエントリーさせようとしてる様なもん
徹底した議論がしたいならIDが出る板へ行った方が良いよ
227 :仕様書無しさん2010/03/17(水) 04:45:25
ネットでコーディングルタイルの話をしていて、こういう書き方ひでーな
みたいなことを言ってると「おれは人を使ってる立場だ、
こういう書き方はヘボを使うのに有効だ」みたいなことを言って暴れる人って
よくいるんだよね。
分かってるけどあえてやってるみたいな。

で、おれも仕事だから不本意なコーディングルスタイルで書かされる
ことはしょっちゅうだけど、そのスタイルがネットでバカにされているのを
発見しても、べつにムカつきはしない。
逆に、そうそう、あれはダサいよなって同意する。

ヘボを使うためにやってるみたいなことを言って暴れる人って、絶対
仕方なくやってるとかじゃなくて、本人がヘボくて、それまでそんなこと
考えたこともなかった奴だって思ってるよ。

228 :仕様書無しさん2010/03/17(水) 04:51:09
>>226
擁護が半々って言っても、ヘボじゃないって根拠は、ヘボい人には使いやすいって
ことで、それも本当に使いやすいかどうかは自分の思い込みのみ意外に根拠がない
ってことでしょ。

じゃ結局>>121の書き方はヘボいってことで決着ですね。
了解です。
229 :仕様書無しさん2010/03/17(水) 04:57:32
>>226
いま、ネットでいろいろ見てみたら、DB関連のクラスって
あんがいusingを使わないもんだね。

いぜん、使ったときには、なんかすごい使ったような気がしたんだけど。
なんであんなに使ったか思い出せない。
230 :仕様書無しさん2010/03/17(水) 11:43:53
アンマネージリソースはちゃんと解放しないと気持ち悪くね?


俺の居る会社で作られたコードにはUsingもDisposeもなければ
Try〜Finallyも無い。Catchでエラー捕まえたら、わざわざ-1とかの戻り値にして・・・

さらに>>121のような(自称)自社製フレームワーク完備&アドホッククエリ強制
232 :仕様書無しさん2010/03/18(木) 22:40:56
そもそもDB使うこと自体をひっくりかえされるかもしれない
そういうときにhogeDBにしといてよかったと思うんじゃないか
233 :仕様書無しさん2010/03/18(木) 23:11:19
hogeDBは標準のDBクラスをメソッドの呼び出しに
置き換えただけなんで、hogeDBの中身をいじって対応できる
程度の変更なら標準のDBクラスでもおk。
234 :仕様書無しさん2010/03/18(木) 23:57:07
>>233
修正量が全然違うだろJK
235 :仕様書無しさん2010/03/19(金) 00:11:24
>>234
変わんないと思うよ。
236 :仕様書無しさん2010/03/19(金) 00:18:08
どして?
ラッパーを修正するのと標準クラスを使ってる部分を修正するのとでは量が全然違うと思うけど
ラッパーが一箇所でしか使用されてないなら別だけどね
237 :仕様書無しさん2010/03/19(金) 00:26:10
>>236
hogeDBはそれの中身だけ修正して、呼び出し側は修正なしでいいってこと?
標準クラスも、お作法どおり作っていれば、呼び出される側だけ修正でおk。
238 :仕様書無しさん2010/03/19(金) 00:29:35
>>237
ラッパーの呼び出し側に修正が必要ならそれはラッパーとは呼ばないよ
標準クラスもお作法どおりってのは派生したラッパーを用意しとけばって話だろ、論点が違うよ
239 :仕様書無しさん2010/03/19(金) 00:37:24
>>238
だから呼び出される側だけの修正でおkって言ってるじゃん。
240 :仕様書無しさん2010/03/19(金) 00:39:10
新参の人なのか。
上のほうで発言してる人は、そこらへんはつっこんでこなかったんで
分かってるっぽかったけど。
241 :仕様書無しさん2010/03/19(金) 01:03:54
>>239
呼び出される側ってのは具体的に何を意味してるの?


242 :仕様書無しさん2010/03/19(金) 01:14:57
>>241
標準のDB関連のクラス。
243 :仕様書無しさん2010/03/19(金) 01:21:23
>>242
OdbcConnection とかの事?
244 :仕様書無しさん2010/03/19(金) 01:47:33
>>243
そう。↓みたいに使う。

IDbConnection conn = new OdbcConnection();
conn.open();
IDbCommand select = conn.CreateCommand();
select.CommandText = "SELECT …";
using(IDataReader reader = select.executeReader()) {
 while(reader.read()) {
   Console.Writeline(reader[0]);
 }
}

new OdbcConnection();の所とか接続文字列をファクトリメソッドやら
ファクトリクラスにやらせるようにすれば、ロジックとDB関連を完全に切り離せるね。
SQL Serverでも、Oracleでもすげかえられる。
インターフェースの実装を自前でやれば、DB以外でもおk。
SQLの方言は吸収できないけど、それはhogeDBおなじ。
245 :仕様書無しさん2010/03/19(金) 01:56:18
>>244
> new OdbcConnection();の所とか接続文字列をファクトリメソッドやら 
> ファクトリクラスにやらせるようにすれば、ロジックとDB関連を完全に切り離せるね

それの事を >>238 で書いたんだけどね、派生クラスではなく仲立ちクラスって方法論は異なってもラッパーを噛ませるって本質は同じ
ラッパーを噛ませる事の有用性を議論してたのにラッパーの優劣の話にすり替えちゃダメだよ

>>244 みたいなコードが量産されたらdb変更に伴う修正量は非常に多いって事は認めるよね
246 :仕様書無しさん2010/03/19(金) 02:10:15
>>245
> 話にすり替えちゃダメだよ

すり替えてないよ。
起点にファクトリメソッドをかませるってだけで、hogeDBと同じ扱い?

> みたいなコードが量産されたらdb変更に伴う修正量は非常に多いって事は認めるよね

いや?
hogeDBとかわらないんじゃない?
むしろ、hogeDBの中でOdbcConnection()とか直で使ってたら、hogeDBのほうが
修正量おおくなりそう。
非RDBに変更するとか、むちゃな変更だと、ちょっと大変そうだけど、
それはやっぱりhogeDBでも同じだし。
247 :仕様書無しさん2010/03/19(金) 02:16:25
>>246
hogeDBも OdbcConnection() を直でコールしないって観点ではファクトリクラス/メソッドを噛ませるのと同じだろ

>>244 みたいに OdbcConnection() を直でコールしてるコードは全部直さなければならない
hogeDB 内部では OdbcConnection() を直にコールしていてるだろうけどそこだけ直せば良い
どうして変わらないなんて言えるの?
248 :仕様書無しさん2010/03/19(金) 02:27:08
>>247
だからnew OdbcConnection()のところにファクトリメソッドかませれば、
いいって最初から書いてるじゃん。
上のコードはサンプルだから、適当に直書きしたけど。
249 :仕様書無しさん2010/03/19(金) 02:31:28
>>248
直書きしたコードを示されたからこんなコードだと修正量が多いと書いただけ
ファクトリを噛ませたコードを示されたらこれってラッパーと同じでしょって書くよ
結局 >>238 で話は終わりさ
251 :仕様書無しさん2010/03/19(金) 02:40:45
>>249
そもそも>>121は、関連クラスを全部ひとつにぶち込むのってへぼいよねって話。

で、それに対する反論で、hogeDBのようにラップしていればDBを切り替えられるって話がでた。

それに対して、>>121みたいに不格好にひとまとめにしなくても標準の
仮想クラスをつかえば、簡単に切り替えられると反論。
一つのクラスにぶち込むことは正当化できてませんねって結論。

最初からラッパーの否定なんてテーマになってない。
勝手に相手はラッパー全否定と、レッテルはって
「はいファクトリーメソッドつかったね、ラッパーまんせー」って勝利宣言とか
ずれすぎてる。
252 :仕様書無しさん2010/03/19(金) 02:45:04
>>249
っていうか、よく読んでなかっただけかよ。
253 :仕様書無しさん2010/03/19(金) 02:46:36
俺は >>121 の優劣に対して議論してるつもりは無いよ
なんらかのラッピング手法を用いて標準ライブラリ呼び出しを隠蔽する事に意味が有るって書いてるだけ

>>121 優劣(というよりクソ度)を議論するにはコードが出てこないと水掛け論にしかならないと(俺は)思ってるし
254 :仕様書無しさん2010/03/19(金) 02:50:33
>>253
じゃ、>>232で、hogeDBとか名前出すなよ。
途中から>>232と変わったのか?
じゃ、すこしくらいアンカーをさかのぼって何が争点になってるか確認しろ。


255 :仕様書無しさん2010/03/19(金) 02:58:23
ヘボいやつに限って、これは水掛け論とか宗教戦争とか言い出すな。
自分に理はないのに、どっちもどっちみたいな口ぶりで。
256 :2532010/03/19(金) 03:24:01
俺 >>232 じゃないけどね

もう少し突っ込もうか?
>>244 を
IDbConnection conn = CreateConnection(); //new OdbcConnection(); 
conn.open(); 
IDbCommand select = conn.CreateCommand(); 
select.CommandText = "SELECT …"; 
using(IDataReader reader = select.executeReader()) { 
 while(reader.read()) { 
   Console.Writeline(reader[0]); 
 } 

とファクトリメソッドを組み込んで修正したとしよう
これで標準の ????Connection() を切り替えるのは簡単だ
だが DB 自体が独自のストレージ機構に置き換わったって標準クラスでは対応できなくなった場合はどうなるのか?
IDbConnection, IDbCommand, IDataReader のインターフェイスを持つクラスと必要なメソッドを全て実装しなければならないし、
それらインターフェイスの関連が独自ストレージにそぐわない場合は非常に面倒な実装となる

完全なラップを考えるのならIDbConnection, IDbCommand, IDataReader も隠蔽するべきだ
それを実現するには?
hogeDB が優秀な設計かどうかは知らないが隠蔽という意味では hogeDB 以外のクラスを意識しなくても良いという点は評価できる
257 :仕様書無しさん2010/03/19(金) 03:32:56
>>256
さんざん言ってるけど、hogeDBは、対応するクラスと同じ粒度で
メソッドに置き換えただけだから、置き換える手間は標準クラスと
大差ないよ。
そこらへんもへぼいと言ってる要因。
258 :仕様書無しさん2010/03/19(金) 03:37:43
>>257
粒度および利便性については評価していない
標準クラスの隠蔽についてのみ評価した
259 :仕様書無しさん2010/03/19(金) 03:39:27
ま、変更ってのが非RBDを想定してるなら、この作りのクラスで、
ライブラリの内部だけの変更ですまそうっては無理筋だわな。
260 :仕様書無しさん2010/03/19(金) 03:41:41
>>258
>>121もRDBのアーキテクチャをもろに反映していて、隠蔽はできてないよな。
261 :仕様書無しさん2010/03/19(金) 03:48:31
>>259-260
確かにRDB操作手順を反映してるから非RDB環境になったら対応しきれない可能性は高いな
そこまで高度な隠蔽を実装するには概念的な設計が必要とされるけど現場のインフラ如きにそこまで要求するのは...
262 :仕様書無しさん2010/03/19(金) 06:45:18
From: [562] デフォルトの名無しさん <sage>
Date: 2010/03/13(土) 09:11:34

ソフトウェア業界はたまーにこういうのが潜んでるから面倒だよね。
一見わかってるふうだからたちがわるい。
_________________________________________________________________________________

From: [563] デフォルトの名無しさん <sage>
Date: 2010/03/13(土) 09:21:22

>>562
簡単な見分け方がある
「?は駄目だ」と言う奴は99%役立たずの勘違い馬鹿
コイツの戯言は何一つ聞き入れる必要が無い

「そこは?にすると良い」と言える奴は99%有益な意見を持つ人間

この見分け方は別にソフトウェア業界に限らない
263 :仕様書無しさん2010/03/19(金) 10:11:57
ラッパ談義になってるあたり、羨ましい環境の人が多いようで・・・

>>121が今でもここ見てるかどうか知らないが
こんなサンプルコードとセットで渡されたりしなかったか?

//stringでSQLを組み立てるのは遅いので禁止
StringBuilder sb = new sql();
sb.Append("SELECT hoge\n");
sb.Append(",hoge1\n");
sb.Append(",hoge2\n");
sb.Append("FROM foo");

string strSql = sb.ToString();

hogeDb.sqlSql(strSql);
264 :仕様書無しさん2010/03/19(金) 10:54:28
>>263
したり顔でそんなサンプルコードよこされたら確かにいやになるな
265 :仕様書無しさん2010/03/19(金) 12:17:08
何とかは駄目だというヤツは99%駄目だ。
そいつのいう事は何一つ聞き入れる必要はない!

↑こいつクレタ人っぽくね?
266 :仕様書無しさん2010/03/19(金) 12:49:01
複雑な SQL を発行させたくない、という理由でラッパを通してしか DB アクセス禁止になり、
俺にそのラッパ製作のお鉢が回って来たことがある。
利用者は同じフロアーの近所に座っている人たちなので気楽に考えていたら、
テーブル名引数にサブケリーを埋め込んで呼び出された。
267 :2632010/03/19(金) 12:51:39
>>264
実際にあった話。具体的には俺の勤め先。
そして、これをヤバイと感じられる同僚が居ないという冷たい現実。

ちょうど今目の前に良いコードがあるな。

hogeTextBox.InputChar = "1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"

正規表現の使えない自社製入力文字制限。
なお、コーディング規約では、わかりにくいので正規表現は使用禁止とされている。
268 :仕様書無しさん2010/03/19(金) 12:53:34
>>266
いっそのことストアド以外のSQL禁止しちまえw
269 :仕様書無しさん2010/03/19(金) 12:58:47
>>268
セキュリティ面でも望ましいことだな
270 :仕様書無しさん2010/03/19(金) 17:34:24
ストアドなんか使ったら整合性が取れなくなるって言われるのに100ペリカ
272 :仕様書無しさん2010/03/19(金) 19:47:40
ここまでスレタイに沿った書込みがない件
273 :仕様書無しさん2010/03/20(土) 00:15:04
>>272
>>26 は凄いぞ正にスレタイ通り
>>121 は見習え
274 :仕様書無しさん2010/03/20(土) 00:23:58
>>121とか、ひでーコードだろ。
275 :仕様書無しさん2010/03/20(土) 00:58:41
>>26 と比べてみろよ
横綱と十両くらいの差が有るぞ
276 :仕様書無しさん2010/03/20(土) 01:01:48
横綱と十両、どう違うの?どっちも外人でしょ?
278 :仕様書無しさん2010/03/20(土) 01:09:35
>>276
そうか、俺が悪かった m(_ _)m
279 :仕様書無しさん2010/03/20(土) 01:23:36
>>263
javaの仕事をしたとき、プロジェクトに入る前に意見があったらくださいって、
コーディングルールがくばられた。
文字列の連結はパフォーマンス悪いから+じゃなくて、StringBuffer()を使えっ
てのがあったんで、javaのドキュメントみせて、+はStringBuffer()に変換さ
れますよって言ったけど、StringBuffer()使う慣習だからって却下された。

でも、さすがにみんな、常にStringBuffer()を使うのはめんどくさかった
らしくて、文字列の連結はconcat()使ってんのな。
おれは最初は規則どおりStringBuffer()使ってたけど、べつに周囲も
コーディングルールで注意されてないみたいなんで、途中からconcat()
使うようになった。

素直に+使わせてたよりパフォーマンス悪くなってるじゃん。
281 :仕様書無しさん2010/03/20(土) 01:26:37
さすがにそろそろStringBuilderが常識になって欲しい。
282 :仕様書無しさん2010/03/20(土) 01:33:36
>>281
新規の案件なのにjavaの1.4だった。
strutsも古いバージョンで、ネットでいろいろ検索してたら、
「未だに検索してくる人がいるってことは、まだこのバージョンが
使われているってことですね」みたいなことが書いてあるページが
ヒットして悲しかった。
283 :仕様書無しさん2010/03/20(土) 04:47:20
>>279
素直にStringBuffer.append() を使えばパフォーマンスは上がってたんじゃないの?

String+ がStringBuffer に変換されるってのはワークのStringBufferを作成して結合処理をした結果を StringBuffer.ToString() で
書き戻すって話じゃなかったっけ?
効率の悪さでは一番だよ
String.concat() はワークを作らないから String+ よりパフォーマンスは上がってるんじゃないの?

String は操作を行なうごとにメモリの確保を行なうけど StringBufferr はサイズがはみ出ない場合はメモリ確保を行なわないはず
よって StringBuffer.append() の方が String.concat() よりも速いんじゃないのかな(未確認だし状況によると思うので自信無し)

君の現場で配られたルールは間違っていないと思うけどね
284 :2832010/03/20(土) 05:05:04
君の現場で配られたルールは間違っていないと思うけどね
の続きは有るな
String+みたいな便利な書き方を禁止してまでnsecオーダーのパフォーマンスを優先するプロジェクトなのかって思うから縛りすぎ
286 :仕様書無しさん2010/03/20(土) 10:49:12
>>29
>その割に、デバッグビルド(最適化オプションなしか緩め)で客先に納品されたり、
>なかなか間抜けなことが多い

そういうプログラムって、最適化ビルドすると動かない事もあったりするから
さらに困るw
287 :仕様書無しさん2010/03/20(土) 11:14:55
>>283
こういう文章をよめないタイプは突っ込むとめんどくさそう。
288 :仕様書無しさん2010/03/23(火) 04:23:23
>>279-284
http://www.ne.jp/asahi/hishidama/home/tech/java/string.html
http://d.hatena.ne.jp/hyperash/20051202/p1
あたりを見る限り、ルールは

・ループの中で毎回結合するような場合はStringBuilder(StringBuffer)を使う

で十分な気がするな。

・複数行で結合する場合もStringBuilder(StringBuffer)を使う

は、速度が求められる処理以外は必須ではない気がする。
289 :仕様書無しさん2010/03/23(火) 22:48:29
ループとかで結合するときは、StringBuilderで、
結合する回数が固定のときには+って定石だろ。
議論するレベルの話じゃない。
290 :仕様書無しさん2010/03/24(水) 11:29:06
>>289
そうはいっても
>>279 の現場とか、>>283 とか、まるで中身を理解してないで
金科玉条のごとく StringBuilder(Buffer) を信奉(ていうか "+" を敵視)
している人・現場は残念ながら山ほどあるからね・・・
291 :仕様書無しさん2010/03/28(日) 08:53:19
>>290
1.4の頃、+とSBでベンチマークとってみたけど有意な差はなかった。
(雑誌に差はないと書いてあったので確認したら本当に無かった。)

ごちゃごちゃと屁理屈を並べる前に、走らせて確認しろよ。
292 :仕様書無しさん2010/03/28(日) 10:13:42
+使っても、コンパイラが勝手にStringBuilder使うように最適化してくれる。
だったら、それぞれの状況で、読みやすく保守しやすいほうを選択すればいい。

それすら知らずにStringBuilder使えとばかり言うアフォは業界から足を洗ったほうがいい。
293 :仕様書無しさん2010/03/31(水) 22:41:13
ぬるぽをプログラム開始早々freeしているソースに出会ってしまったわけだが。
295 :仕様書無しさん2010/04/01(木) 00:14:54
>>293
NULLならば何の問題もない筈では?

ttp://www.bohyoh.com/CandCPP/C/Library/free.html
|ptrが空ポインタの場合、何も動作しない。
|それ以外の場合、実引数がcalloc関数、malloc関数もしくはrealloc関数によって以前に返されたポインタと一致しないとき、
|またはその領域がfreeもしくはreallocの呼出しによって解放されているとき、その動作は未定義である。
296 :仕様書無しさん2010/04/01(木) 01:01:50
>int main(void) {
> char * p = NULL;
> free(p);
> /* ... */
>}
こんなソースがあったら、問題はないけどイヤになるかもしれん
300 :仕様書無しさん2010/04/22(木) 23:49:09
変換結果ほとんど見ないでコメント書いただけだろう。
これでスレタイ通りのことを思ったなら気が短すぎるwww
302 :仕様書無しさん2010/04/23(金) 00:10:13
そういう細かいところが配慮出来ないヤツのコードはバグってるという定説を信仰されてるかたなのでは
303 :仕様書無しさん2010/04/23(金) 00:40:51
誤変換より「15kai kurikaesu」のほうが衝撃的だな。

短気には同意。新人ぐらいならやりそうだ。
304 :仕様書無しさん2010/04/23(金) 01:23:40
その2つのコメントが同時にあるというのがよくわからんね
書いたのは違う人とか
305 :仕様書無しさん2010/04/23(金) 08:46:55
批判しているお前らはちゃんと TestCase 書いているのか?
すぐに動かなくなるきれいなコードよりも、汚くても動くコードの方がいい。
306 :仕様書無しさん2010/04/23(金) 12:51:01
>>305
>すぐに動かなくなるきれいなコードよりも、汚くても動くコードの方がいい。

汚くて動いてるけど、たまーに動かなくなるコードならたくさん・・・orz
307 :仕様書無しさん2010/04/26(月) 22:25:42
JSPにDBアクセスのコードがそこら中に書いてあった。
保守性ゼロ。
動いてるのが不思議なくらい。
いっぺんしね。
308 :仕様書無しさん2010/04/29(木) 03:28:01
>>265
>265 :仕様書無しさん:2010/03/19(金) 12:17:08
>何とかは駄目だというヤツは99%駄目だ。
>そいつのいう事は何一つ聞き入れる必要はない!

>↑こいつクレタ人っぽくね?

安心しろ、そいつは残りの1%だ。
309 :仕様書無しさん2010/04/29(木) 16:35:02
ソースの一行一行にコメントがあった時は本当に辞めたくなった。
しかもそのコメントが「ここで1を加算」とか「FALSEの場合は関数を抜ける」とかばかり。
310 :仕様書無しさん2010/04/29(木) 16:56:52
スパゲッテーよりましだろ
311 :仕様書無しさん2010/04/29(木) 17:01:38
一定時間おいてから自分で読み直すと、良し悪しが時間できるんだけれど
自分の書いたコードなんて、読みたくないものの筆頭だしなあ
312 :仕様書無しさん2010/04/29(木) 20:55:31
うちじゃ何かコードを書いたり修正があったりするたびに「関数や変数を組み込みたい」という申請をさせられる。
そして関数名・変数名には、……そのとき発行された管理番号を使うんだ。
その結果コードは↓みたい暗号になる。

int F_PJ0001_XXX0000( ... )
{
 ……省略……
 return V_PJ0001_A0001[ V_PJ0001_N0001 + V_PJ0001_N0001 ];
}

もし本当の関数名・変数名を知りたいならば EXCEL で書かれた [管理番号と変数の関連づけ一覧] を調べる必要がある。
誰が考えたんだ、こんなクソ制度……
313 :仕様書無しさん2010/04/29(木) 20:57:14
おっとミスった。
> return V_PJ0001_A0001[ V_PJ0001_N0001 + V_PJ0001_N0001 ];

 return V_PJ0001_A0001[ V_PJ0001_N0001 + V_PJ0001_N0002 ];
と書くつもりだった。
314 :仕様書無しさん2010/04/29(木) 21:31:39
>>312
末恐ろしい・・・
315 :仕様書無しさん2010/04/29(木) 21:37:55
なんで変数名付け替えスクリプトって定番ツールになっていないんだろうな・・・?

心に余裕のあるうちなら軽く作成できる気がしなくもないのだが
317 :仕様書無しさん2010/04/29(木) 21:42:10
>>312
良く会社生き残っていられるな。かなりヤバくね?
318 :仕様書無しさん2010/04/29(木) 22:38:39
過去のデータが残らないの
過去のデータを表示したいなら
一番古い方から全部引く作業を行ってる
319 :仕様書無しさん2010/04/30(金) 02:37:51
>>310
コメントの話をしてんのに”スパゲッテー”てw
320 :仕様書無しさん2010/04/30(金) 08:23:11
>>313
どこを訂正したのか悩んだ
321 :仕様書無しさん2010/04/30(金) 08:35:43
>>320
>>312の気分を体感するのに役立った!w
322 :仕様書無しさん2010/04/30(金) 18:51:24
>>312
なんか似たようなレス前に見たぞ。
同じ会社かそれともそういう会社が他にもあるのか。。
発行された番号を使うって事は、その申請してからじゃないと新しい変数使えないんだよな?
とにかく面倒くさそう。
323 :仕様書無しさん2010/04/30(金) 19:09:03
>>315
既存のツールがあるしね
324 :仕様書無しさん2010/04/30(金) 20:52:53
>>322
けっこうデカイ会社だから同じ会社か同じグループ会社の人なのかも。
こんなアホなこと他にも(独自に)やってる所があるとは思いたくないなぁ。
326 :仕様書無しさん2010/05/01(土) 01:35:08
>>312
大型汎用機の世界だな。
大昔、識別名の桁数制限が5桁とか7桁だった時代に大量の変数を使用するには
連番でつけて台帳管理するしか方法がなかった。

# 形骸だけが残ったんだね。
327 :仕様書無しさん2010/05/01(土) 02:06:57
>>326
なるほど
勉強になるなあ
329 :仕様書無しさん2010/05/01(土) 07:21:40
ローカル変数っていうものがないもので巨大なプロジェクトをやるとそうならざるを得ない
331 :仕様書無しさん2010/05/05(水) 02:36:57
if (v == null && v.equals("")) {
return;
}
がいたるところにある
「||」になっているところもあるんだが、同じように直さないのかな
332 :仕様書無しさん2010/05/05(水) 02:56:14
( ´∀`)<ぬるぽ
333 :仕様書無しさん2010/05/05(水) 03:04:51
>>331
> if (v == null && v.equals("")) {
> return;
}

* vがnullのときは条件式の右辺でぬるぽ発生
* vが非nullのときは条件式の左辺が偽になり、&&演算が短絡で偽になる
のでこのreturnには絶対に到達しないわけで、コンパイラに未到達文
があるぞと怒られる気がしたが、試してみたら言われなかった。

334 :仕様書無しさん2010/05/05(水) 07:00:32
||なら問題なかったけど、
そもそも""と等しいかチェックするあたりイケてない。
同じコードを繰り返すのもイケてない。メソッドにするべき。

どうでもいいけど、Eclipse使っててメソッド抽出しらないとか
現場がそんなんばっかりなんだが、全員殺したいよう。
336 :仕様書無しさん2010/05/05(水) 20:40:46
教えてないとでも思ったか?
毎度毎度教えるのはさすがに疲れるよ。
339 :仕様書無しさん2010/05/06(木) 17:57:32
スレタイ通りのこと思ってんなら出来るだろ?
やめたいやめたいばっかり言ってるだけなのか?
341 :仕様書無しさん2010/05/20(木) 03:12:12
>>71
【赤松】外遊先でゴルフ
ttp://tsushima.2ch.net/test/read.cgi/news/1274289979/
> 赤松大臣は口蹄疫の発症が確認された後の4月30日から5月8日まで、キューバやメキシコなどに出張しました。
> 複数の民主党幹部が19日夜に赤松大臣のこの時期の長期出張について「問題だ」との考えを示したうえで
> 外遊中に海外でゴルフをしていたことを明らかにしました。
> (20日01:39)

> 8 名前: アロサ(愛知県)[] 投稿日:2010/05/20(木) 02:28:53.82 ID:eiWoTSxR
>   アルバトロス

> 11 名前: ホテイウオ(東京都)[] 投稿日:2010/05/20(木) 02:29:39.13 ID:XA1lo79p
>    >>8
>    阿呆鳥だっけか
342 :仕様書無しさん2010/05/20(木) 07:23:18
>>332
だれもガッしてなかった件
すごい長い間放置されていたな
345 :仕様書無しさん2010/05/23(日) 14:14:47
-- project.resource.txt
SOME_VALUE = 入力が間違っています。

-- app.config
<appSettings>
<add key="ProjectResource" value="project" />
</appSettings>

--とあるクラス
const PROJECT_RESOURCE = "ProjectResource";
const SOME_VALUE = "SOME_VALUE"
public void hoge(){
Resource resource = ResourceFactory.get(ConfigurationManager.AppSettings(PROJECT_RESOURCE));
string fuga = resource.getString(SOME_VALUE);
}

こんなの出来たんだけど(泣

347 :仕様書無しさん2010/06/01(火) 07:09:56
1 :名無しさん@どっと混む:2009/12/14(月) 20:45:15 ID:unnBMLw10
高根社長のSM趣味サイトMaskRと
副業のSMクラブ銀座プレジス・動画配信専門リアルミストレスばかり語られるが
高根社長の本業コムラッドについても語ろう

銀座プレジス
http://www.prezis.jp/top.htm

MaskR
http://maskr.com/

プレジスを語ろう
http://set.bbspink.com/test/read.cgi/sm/1246009466/

動画配信専門リアルミストレスってどうよ?
http://set.bbspink.com/test/read.cgi/sm/1249183350/

9 :名無しさん@どっと混む:2010/01/03(日) 18:27:00 ID:RSEbBiG0O
高値はもう大麻やめたの?

10 :名無しさん@どっと混む:2010/01/04(月) 05:15:29 ID:A3l1qdv+O
タカネ社長ってどうやってばれないように脱税してんだろ?
億単位で脱税して億ション暮らしなんて凄いよな
監査役の奥さんもグルなのか?

12 :名無しさん@どっと混む:2010/01/05(火) 01:47:06 ID:KAHwqMrBO
株式会社Comrade株式会社コムラッド株式会社Comrade株式会社コムラッド株式会社Comrade株式会社コムラッド株式会社Comrade株式会社コムラッド株式会社Comrade
株式会社Comrade株式会社コムラッド株式会社Comrade株式会社コムラッド株式会社Comrade株式会社コムラッド株式会社Comrade株式会社コムラッド株式会社Comrade

13 :名無しさん@どっと混む:2010/01/05(火) 01:47:47 ID:KAHwqMrBO
高根英哉高根英哉高根英哉高根英哉高根英哉高根英哉高根英哉高根英哉高根英哉高根英哉高根英哉高根英哉高根英哉高根英哉高根英哉高根英哉高根英哉高根英哉
348 :仕様書無しさん2010/06/01(火) 07:10:47
18 :名無しさん@どっと混む:2010/01/07(木) 09:26:06 ID:5NL2jyJpO
高根はMASKRでレイプ仲間募集するのやめたんだね
mixiで募集中か

21 :名無しさん@どっと混む:2010/01/10(日) 19:36:45 ID:FdRwgXUTO
風俗店やってるってことは高根社長は暴力団と繋がってるんだね
どこの組にいくらみかじめ料払ってるんだかw

23 :名無しさん@どっと混む:2010/01/23(土) 03:43:12 ID:Pdcv8aq0O
タカネ社長未成年に酒飲ませてレイプ

24 :名無しさん@どっと混む:2010/01/29(金) 18:16:06 ID:zMwtdkIsO
高根社長のレイプ趣味は病気だから治らない

25 :名無しさん@どっと混む:2010/02/01(月) 01:39:32 ID:uaH5mo2nO
前科者

26 :名無しさん@どっと混む:2010/02/09(火) 00:52:46 ID:JwGmN2cG0
>>25
容疑はレイプ?買春?管理売春?公然猥褻?薬物?脱税?詐欺?傷害?

28 :名無しさん@どっと混む:2010/02/14(日) 22:56:30 ID:lykq8x1VO
どこかのスレで人を死に追いやったと書いてあった

33 :名無しさん@どっと混む:2010/03/04(木) 12:49:19 ID:J8YxaRGO0
金がないって脱税がばれて追徴課税でも来たか?
せっかく脱税の隠れ蓑にプレジス営業してるのに残念だったなw

38 :名無しさん@どっと混む:2010/03/12(金) 21:09:53 ID:L0W4+sivO
首吊り首絞めプレイ大好き高根英哉
349 :仕様書無しさん2010/06/01(火) 07:11:34
53 :名無しさん@どっと混む:2010/05/17(月) 13:14:06 ID:E/7OZVtz0
>>18
高根英哉blogでレイプ仲間募集中

私とともにマスクの女どもを弄ぶ仲間を募集する
急に思いついたら連絡をして、集まれるような仲間だ
だから、複数名募集するし、いついつという日時があるわけでもない
条件は以下のとおりだ
    ・SMを実践している、または興味がある
    ・マスクを用意できる
    ・都内でイベント参加できる
    ・イベント内容およびこの仲間を通じて知りえた情報を口外しない
    ・成人男子である
    ・携帯電話および携帯メールアドレスを私に公開できる
    ・酒が好きである
希望者は私宛にメールを送ってほしい
全員が参加できるわけでもないので、こちらの選択に任せてもらう
なるべく想いを書いてもらうほうがわかりやすいし
経験や顔写真も歓迎。
r2007@maskr.com
maskr_2008@yahoo.co.jp
hide@comrade.co.jp
350 :仕様書無しさん2010/06/04(金) 17:18:41
>>339
それ、結局捏造だったわけだが、
お前はデマを流した責任をどう取る気だ?
353 : ◆dxxIOVQOvU 2010/06/13(日) 02:19:56
お前は俺のやりたかったことを理解しろよ

>>331のソースコードをみたら100人中99.9人が「死ねw」って思う
それを弁護してやろうとしたけど無理だった死ねカス


つうか俺には
「同じソースコードで複数の言語処理系でも動くことを考慮したソースコード」
を生成するという構想がある

はいはい支離滅裂 しちめつれrつ

ねむいだよカス
354 :仕様書無しさん2010/06/13(日) 02:56:18
>>353
誰が見ても、&&と||の間違いとはわかるけどね。
""でもそれ以下のコードが正常に動作するので、気がつかないんじゃないか?
356 : ◆5MBke502AE 2010/06/13(日) 16:08:37
>>354
もしこれが正しいとしても
if (v == null || v.equals("")) {
return;
}
NullかEmptyのチェックなら
Rubyのblank?のようなメソッドを作るべきだし、
それを作っていない時点で書いた奴は素人
だから、その部分だけは記述冗長してるけど && で正しい可能性もあるから
結論をいえば
NullとEmptyがイコールになる言語かどうかで見解が違ってくる
イコールにならない言語で、勝手に&&を||にしたら>>331の条件は逆になってしまう
357 :仕様書無しさん2010/06/13(日) 16:34:34
たしかに、そういう無意味なチェックって見過ごされがちだよな。
一度メンテナンス期に入っちゃったら、動作に問題ない部分は見ないことが多いから。

if (x >= 5 || x <= 10) {
// 数十行のコードブロック
}
else {
// ほとんど同じ内容のコードブロック
}

みたいなの。
358 :仕様書無しさん2010/06/13(日) 17:56:24
>>356
Javaではべたに書くのが普通だな。
360 :仕様書無しさん2010/06/14(月) 17:31:27
誰も言わないから不安になってきたんだが、&&だとNullReferenceExceptionが発生しないか?
361 :仕様書無しさん2010/06/14(月) 17:40:57
>>360
もちろん発生する。
再現性を良くするために、
敢えて確実に発生させているのだろう。
364 :仕様書無しさん2010/06/18(金) 03:15:36
>356
> && で正しい可能性もあるから

ねえよ
バカなの?
365 :仕様書無しさん2010/06/18(金) 19:52:21
>>331
ぬるぽ
366 :仕様書無しさん2010/06/18(金) 20:13:56
!$omp parallel
 do i=1, imax
  >>365 "ガッ"
 end do
!$omp end parallel


「おかしい・・・どうして速くならないんだろう・・・」
367 :仕様書無しさん2010/06/22(火) 11:33:46
>>331
それ、中は入れないじゃん
368 :仕様書無しさん2010/06/27(日) 21:38:46
# use strict;はエラーで止まるから禁止。

ウソみたいだろ・・・間接的だが人命に繋がるシステムなんだぜこれ
370 :仕様書無しさん2010/07/07(水) 17:48:26
条件分岐があるとひたすらロジックが枝葉のように広がり
同じコードが書いてあるソース
376 :仕様書無しさん2010/07/08(木) 01:16:59
COBOL案件の手伝いに行った時、if文の中でperform呼んだら怒られた。
構造化してはいけないらしい。

あとGAME屋は、わざとループを展開して書くよね。
378 :仕様書無しさん2010/07/17(土) 02:55:58
java StrutsのActionメソッドで2000行。
SQLを発行するのにCreateStatementだったりPreparedStatementだったり、独自拡張だったり
それで動いてるから困ったわwww
解読するのに3日近くかかったwwww
379 :仕様書無しさん2010/07/17(土) 03:06:05
>>331 これってべたに書くものなのか?
StringUtils.isEmpty(v) とか使うものだと個人的に思ってたけど、上司は使ってなかったな
もちろん存在は知ってたけど

boolean bool = true;   if(bool == true){}  
も普通かな?

個人的には
boolean bool = true;   if(bool){}  

こう書くけど
380 :仕様書無しさん2010/07/17(土) 03:22:42
>>378
Struts作ってる人ってガチで馬鹿だと思う
なにあのモジュール群、なにあのドキュメントの不親切さ
そんなだからへんてこな実装でよく分からないものが動いてるって状況が生まれる
381 :仕様書無しさん2010/07/17(土) 04:18:20
Strutsってフレームワークにしては緩いし、拡張もしやすいから使い勝手がいいかも知れないが
不必要なモジュールが多数あり用途が定まらない。
結果あれこれやっているうちにソースが汚くなって行くって感じがする。
V+MCになってくるよね。
個人的にはドキュメントやサンプル等がネットに落ちてるから実装しやすいけどね。
因みに1.x系ね


Struts2.Xは少ししか触ったことがないがMVCを1系よりも分けやすくなっているため
多少よさげなきがする。
382 :仕様書無しさん2010/07/17(土) 04:29:21
確かに書きやすさという意味では多少マシにはなってるけど
モジュール群のカオス具合は変わらんな
383 :仕様書無しさん2010/07/19(月) 22:22:10
VMwareをインストールしたらプログラムの挙動がおかしくなった。
ソースを調べてみたらこんなコードが!
ipconfigの出力結果を行と列を決め打ちして切り取ってる!
こんなコードがたくさん散りばめられているんだが・・・

system("ipconfig >ipconfig.txt");
fp = fopen("ipconfig.txt", "r");

for (i = 0; i < 8; i++) {
  fgets(buf, 256, fp);
}

for (j = 44; buf[j] != '\n' && buf[j] != '\0'; j++) {
  ipaddress[44 - j] = buf[j];
}

fclose(fp);
system("del ipconfig.txt");
384 :仕様書無しさん2010/07/19(月) 22:24:33
>>383だけど訂正

× ipaddress[44 - j] = buf[j];
○ ipaddress[j - 44] = buf[j];
385 :仕様書無しさん2010/07/19(月) 23:34:57
>>383
なんという手抜きw
386 :仕様書無しさん2010/07/20(火) 00:25:06
でもFTPクライアントとかオークション管理ソフトとかって、大体決め打ちじゃないの?
387 :仕様書無しさん2010/07/20(火) 00:29:58
>>376

>COBOL案件の手伝いに行った時、if文の中でperform呼んだら怒られた。
>構造化してはいけないらしい。

それで怒られるのは変だと思うけど
if文の中でperformを呼ぶことを構造化と言うのかというと
それもまた違うのでは
388 :仕様書無しさん2010/07/21(水) 09:04:21
>>387
同じ処理を行うとこを1箇所にまとめたんだけど?
(分岐数10程度のif文だが、大半が同じ処理)

はっきりした見解をお持ちのようなので、
COBOLのモジュール内で可能な「構造化」について、是非とも御意見を頂きたい。
(できればサンプルソース付で)
389 :仕様書無しさん2010/07/31(土) 07:30:58
>>383
本当に客先環境が変わらない保証があれば、そういうのもアリなんだけどね。
下手すりゃWindowsUpdate当てただけで変わる可能性があるのはちょっとなあw
390 :仕様書無しさん2010/07/31(土) 12:03:16
>>383
DHCPから固定IPに変えただけで動かなくなりますな……

でも何でipconfigを使うんだ?
素直にgethostbynameとか呼び出した方が簡単なのに。
392 :仕様書無しさん2010/08/01(日) 10:22:57
忙しいが口癖のPM


ふぉr(印t胃=0;胃<=下賃st「ん」;++い){
印t いんsってmp=0;
wひぇ(!いんstfぁg){
いんsてmp=すんまいん。m_;


画面見ろ
397 :仕様書無しさん2010/08/07(土) 21:30:09
つーか、PMまで動因してそんなの打ってるPJは、10年前ならともかく、
現代においてはPJ終わってるだろう。
398 :仕様書無しさん2010/08/08(日) 14:41:00
書けるから作業してるか、書けないから管理してるか
PMってこの二種類しか見たことないわ
399 :仕様書無しさん2010/08/08(日) 14:55:14
PMは、自分が打たなければ間に合わない場面に出くわした場合、
自分で打つよりも、なぜ自分が打たなければ間に合わなくなっているかの、
根本原因に対する対策を考えるべきである。

しかもその対策は、遅くなればなるほど腹水盆に還らず度が増すので、
まず打ってから対策などもありえないはずなのである。
400 :仕様書無しさん2010/08/08(日) 17:12:57
>腹水

そんなものが盆に返っても困るw
401 :仕様書無しさん2010/08/08(日) 21:30:20
>>400
今月の中頃帰ってくるみたいだけど?
405 :仕様書無しさん2010/08/12(木) 12:50:11
VC++のreleaseとdegubで動作が異なるソースがあった

原因:
char *hoge(…){
 char ret[100];
 (省略)
 return ret;
}

結構使われてる関数だから修正もできない…
406 :仕様書無しさん2010/08/12(木) 17:09:04
どう動作が異なっているのかわからんが、問題があるとしたら
hogeを呼び出してるほうに問題が出るんじゃないのか?
hogeはスタック範囲内のアドレスを返すだけだろ
debugだときちんとアドレスが返って、releaseだとNULLが返るのか?
408 :仕様書無しさん2010/08/12(木) 17:39:27
こんないい加減な戻り値で仕様にしちまってる時点で終わりだろう。
こんなんじゃ似たようなことやってるとこ他にもありそうだな。
全部調べてサッサと修正して回るべきだな。
膿を出すなら早いうちの方が、結果的には被害が少ない。
409 :仕様書無しさん2010/08/12(木) 18:19:18
素早く終わってくれるアプリなんだったらmalloc書くだけで万事解決しそうだな。
あー、こいつもfreeしやがらん。ぐらいで済みそう。
410 :仕様書無しさん2010/08/12(木) 18:33:42
>>405
さすがにこれはやらねーわ
411 :仕様書無しさん2010/08/12(木) 19:28:30
>>406
デバッグ情報を積むかどうかでスタックフレームのレイアウトがかわるんだろ。
412 :仕様書無しさん2010/08/12(木) 20:38:00
>>411
スタックフレームのレイアウトが変わっても、指しているポインタは同じはず。
うまく動かないのは、使う前に使われちまってるんだろうな。
どちらにしても、これを放置するような会社はつぶれたほうが世のため。
413 :仕様書無しさん2010/08/12(木) 23:22:40
>>405がまじめにわかんない。教えて。
414 :仕様書無しさん2010/08/12(木) 23:25:56
グローバル最適化とかリーフ省略とか
スタックフィルとか、原因はいろいろ
ありそう。
415 :仕様書無しさん2010/08/12(木) 23:28:52
>>413
auto変数は、ブロックスコープ。
ブロック外で参照してはいけない。
416 :仕様書無しさん2010/08/12(木) 23:28:58
>>413
ローカル変数は、そのスコープから外に出ると消えてしまう。
関数の復帰値として、ローカル変数で定義した配列の先頭アドレスを返した場合、
復帰した瞬間に、配列本体が消えてしまう。
戻り先で、配列を参照しようとしても、配列の内容は保証されない。(不定になる)
417 :仕様書無しさん2010/08/12(木) 23:30:46
>>413
おい……
ローカル変数は関数抜けたらなくなるだろ?
だから、char ret[]は、関数を抜けたら意味がなくなるのに、戻値として返してるとよろしくないじゃないか。
strcpyみたいに引数にもらうとかしないといかん。
418 :4132010/08/12(木) 23:35:35
みなさん、即レスありがとう。

で、わかんないのは、releaseとdebugで何が違ったのだろうと・・・
コンパイルした結果が違ったって意味ではなかったのですかね?
たまたま動作が違ったってことなら了解です。
419 :仕様書無しさん2010/08/12(木) 23:42:34
リリースビルドしたら、コンパイラが適当に端折ったり、メモリを効率的に使うようになったりする。
420 :仕様書無しさん2010/08/12(木) 23:46:04
>>418
大抵の場合、デバッグモードでは動きます。
リリースモードにすると、スタック上の変数領域に獲得に余裕がなくなるので、
デバッグモードでは『運良く保存されていた』データが、リリースモードでは破壊される事が多々あり……
421 :仕様書無しさん2010/08/13(金) 00:36:49
>>418
デバッグモードで動作したのは全くの偶然。
コンパイラのバージョンを変えたり、プログラムをちょっと書き換えただけでも動かなくなる可能性がある。
423 :仕様書無しさん2010/08/13(金) 01:19:23
Java や C# ばかりを相手にしてるとたまに C, C++ をさわったときに >>405 のパターンではまりそうで怖い
424 :仕様書無しさん2010/08/13(金) 08:39:57
>>405
やるとしてもこうだろうか。
使い終わったらどっかでfreeしてくれ。

char *hoge(…){
#if 1
char *ret:
ret = malloc(99+1);
if ( ret != null ) {
#else
 char ret[100];
#endif
 (省略)
#if 1
}
#endif
 return ret;
}
425 :仕様書無しさん2010/08/13(金) 08:43:11
mallocとfreeが直感的に結びついてないコードは高い確率でリークする
426 :仕様書無しさん2010/08/13(金) 09:34:42
mallocした領域を返す関数には、名前に _alloc という接尾辞を付ける、という
かったるそうなコーディングルールを導入してはどうだろう。

char* hoge_alloc() { ... }
#define hoge_free(p) free(p)
427 :仕様書無しさん2010/08/13(金) 10:56:17
仕組みが分からないまま「動けばOK」で、仕様としてOKにしちゃうってこと自体が、大きな問題点だと思う。
428 :仕様書無しさん2010/08/13(金) 11:08:50
Java/C#のメリット->GC
Java/C#厨->自分でメモリ管理もできないDQN
C/C++厨の実態->メモリリークどころか解放したメモリを参照しても動けばOK

429 :仕様書無しさん2010/08/13(金) 13:17:33
メモリー管理を全部手動でやれば最高のパフォーマンスが得られる
という理由にてC++では只管メモリーの手動管理に拘ってきたわけだが…

得意とする言語に関係なく、世の中は自分でメモリー管理できないDQNばかりである。
答えは出てるんだよ。C#でそういう結論に達したということだろ。
430 :仕様書無しさん2010/08/13(金) 15:20:50
でもGCって意外なときに走ったりするからウザい。
一回VB.netで機械と話すときに、結構タイミングがシビアな部分があって再現ししづらくて悩んだ。
Win32のリソース(Form)とかはdisposeしないとうまく開放されないとかあったし。
結局disposeいるんじゃん。って思った。当たり前だけどな。
Cで書いたほうが万倍シンプル。
431 :仕様書無しさん2010/08/13(金) 16:50:27
>>425
ヘ?API側で確保するから、caller側で解放してね、ってよくあるパターンだろ…
433 :仕様書無しさん2010/08/13(金) 17:33:15
>>430
こいつ馬鹿すぎる
435 :仕様書無しさん2010/08/14(土) 01:21:34
>>430
VBの場合、動的に資源を取得しては駄目。
プログラムの最初で全資源を確保し、それを使い回せ。
(要するに処理のメイン部分では解放しない。生成しない。)

VBで実装するような処理で何万件も処理するようなケースは滅多に無いので、これで十分。
436 :仕様書無しさん2010/08/14(土) 01:37:03
>>435
まじで??

俺、普通にメモリの生成・解放やってるよ。

Function Foo(...) as Boolean
 Dim ret as Boolean
 Dim objHoge as clsHoge
 Set objHoge = New clsHoge
 ...
 Set objHoge = Nothing
 Foo = ret
End Function

みたいな感じでさ。

Nothing代入したら本当にメモリが解放されるかはしらんがな!
437 :仕様書無しさん2010/08/14(土) 01:46:00
>>425
一番いいのは呼び側でメモリ確保なんだが、>>424の戻り値をみた感じそれをやると結構な工数がかかりそう。
438 :仕様書無しさん2010/08/14(土) 01:56:23
>>435
GCがないから解放されないと思っているのかな?
参照カウント方式でやってくれる。循環参照しているのでなければ、GCよりもいいことが多い。
VBはデータベースで多用されているので、巨大なデータを扱うことが多い。
というか、VBで最初に全資源を確保ってどうやってやるんだ。
440 :仕様書無しさん2010/08/14(土) 04:45:57
リファレンスカウントはGCじゃないと思ってる人がGCを語ってるスレはここですか?
441 :仕様書無しさん2010/08/14(土) 07:50:04
>>438
画面フォームの生成→破壊を繰り返すと、何故かメモリが減る現象が発生した。
原因は不明。

画面フォーム類を起動時点ですべて生成し、非表示にしておき(WIN32API利用)、使用する時に表示状態を切り替えるようにしたらリークしなくなった。

大き目のワーク領域はWIN32APIでとる。
DBはOO4Oを使用。
ややこしい処理はストアドにするか、サーバ側バッチ処理にする。(極力VBでの処理を減らす)
442 :仕様書無しさん2010/08/14(土) 08:14:31
>>440
リファレンスカウンティングはGCの実装に使われることがあるアルゴリズムのひとつ。
COMがリファレンスカウントでGCを実行しているわけではない。
443 :仕様書無しさん2010/08/14(土) 08:52:01
>>441
VBのランタイムがオブジェクトにアロケートしたメモリ領域を解放することと、
OSがVBのランタイムにアロケートしたメモリ領域を解放することは
別物だから注意するように。
444 :仕様書無しさん2010/08/14(土) 10:10:06
つか、.NET自体がメモリーをリークしている(つまりバグ)だと俺は思っているw
446 :仕様書無しさん2010/08/14(土) 23:15:38
おまえらVB.net馬鹿にするけどな、未だに6が現役で使われてるシステムあるんだぞ。
まだマシだ。
あと俺も何故か、VB.netでCIntとか入ってるDLLを参照すると、かなりリークしたことがある。
MSに言うと、それは参照するな、と。
馬鹿かと思ったわ。
447 :仕様書無しさん2010/08/15(日) 00:37:01
おまいら、
「MS製品上で動作=ある程度ちゃんと動かないのは許容範囲」
というノリがバックボーンにあるってのは、
ありがたいMSの親心なんだぜw

MS製品が、ちゃんと動いてると仮定するなら、
「ちゃんと動かないのは全部アプリのせい」
というクライアントの意識の下で仕事することになる。
精神的に全然違うぞww
448 :仕様書無しさん2010/08/15(日) 02:51:18
アホ言うな
アプリのバグかMS提供のDLLのバグか特定するほうの身にもなれ
449 :仕様書無しさん2010/08/15(日) 06:43:50
>>447
MSがどうだろうが、どのみちクライアントは
「ちゃんと動かないのは全部アプリのせい」
と言ってきて瑕疵責任で修正させるついでに
新しい仕様までネジ込んでくる罠。
451 :仕様書無しさん2010/08/15(日) 08:31:27
>>446
> VB.netでCIntとか入ってるDLLを参照すると
よくわからんなあ。参照しないことはできるのか?
それとも、別のCIntか?
452 :仕様書無しさん2010/08/15(日) 14:11:40
>>451
プロジェクトの参照設定からはずせるよ。
VisualBasic.dllかなんか。
Integer.parse使えってさ。
453 :仕様書無しさん2010/08/16(月) 13:12:58
>>405
static char ret[100];
に修正すると期待する動作にならないって話なら重症だな
454 :仕様書無しさん2010/08/16(月) 14:58:42
static?char?ret[100];
にするなら当然
static char *hoge(…){
だろ。
これでつまり大幅な仕様変更だ。
マルチスレッドまで考慮してるなら、仕様変更は没決定。
455 :仕様書無しさん2010/08/16(月) 15:00:02
おいおい、半角スペースを変なコードで書くなよ。
コピペしたら変になっちまったぞい。
456 :仕様書無しさん2010/08/16(月) 15:30:55
>>454
なぜそうなるw 馬鹿じゃないの?
457 :仕様書無しさん2010/08/16(月) 16:16:53
>>454 関数内の変数のstatic コンパイル単位(≒ファイル)レベルの変数/関数のstatic 説明してみようか?
458 :仕様書無しさん2010/08/16(月) 18:55:02
>>457
わかりにくい文章だなw
でもまあ、454が説明できるわけないじゃんw
constと混同してるわけでもなさそうだし、454の脳内で何が起きているのか本当に謎だ。
459 :仕様書無しさん2010/08/16(月) 20:51:26
>>458
454のコードの方が「この会社……」だな。
460 :仕様書無しさん2010/08/17(火) 17:58:17
>>454 は静的メンバ関数の static と混同してるんじゃないかな、いや自信は無いんだけどね

マルチスレッドを考慮してスタックを返すのなら return 直後に確保された領域にコピーすれば
ちゃんと動くかも知れないけど、かなり危険だね(hogeの引数が十分に多ければ大丈夫?)

シングルスレッドで static char ret[100]; にすると期待する動作にならないって場合は非常に重症
何か不明なモノに上書きされたスタックで正常動作してるってのは、もはやプログラムとは呼べない
461 :仕様書無しさん2010/08/17(火) 19:03:24
>>460
multi-threadで排他制御なしにstaticな領域に書き込みしている時点でアウトだろ。
462 :仕様書無しさん2010/08/17(火) 19:14:59
>>461
???マルチスレッドなのかも不明だし、問題のコードはスタックを使用しているよ???
何が言いたいの?
463 :仕様書無しさん2010/08/17(火) 23:42:46
>>462
454のコードがスレッドセーブでない点について論じている。
464 :仕様書無しさん2010/08/18(水) 07:32:23
元のコードは、スレッドセーフのことなんか語ることもできないような、糞コードだけどね。
466 :仕様書無しさん2010/08/18(水) 13:57:44
別にコア吐くようなバグではないよ
期待した文字列が得られないから変な動作になるけど
467 :仕様書無しさん2010/08/18(水) 14:31:37
>>466
なわけないだろ。返値をそのままどこかの関数に渡してたりしたら、任意のコードを実行される危険性だってある。。
468 :仕様書無しさん2010/08/18(水) 15:34:13
バグの重要性を現象面でしか把握できない奴に開発させんなよw
469 :仕様書無しさん2010/08/18(水) 18:40:53
>>467
任意のコードを実行させる危険性って何だよ?抽象的すぎるぜ
バッファーオーバーランの危険性が有るからコアを吐く可能性が有るよってツッコミを期待してるのにガッカリだ
470 :仕様書無しさん2010/08/18(水) 18:44:08
>>467
現実に動作しているらしいんだから、
実際にそんな危険はなかった、ってこと。
472 :仕様書無しさん2010/08/19(木) 00:40:24
char* hoge(・・・)

使うほうも、引数で渡してるんじゃなかったら、このリターン値の
バッファはどこで取ってるんだって気になるはずだけど。

すでにあちこちで使われたら、あえて指摘しないで気づかないふりして
使おうってことになるのかな。
476 :仕様書無しさん2010/08/19(木) 04:32:08
>>469
この場合、バッファーオーバーランしなくても、危険になるのだが、理解できてないみたいだな。
477 :仕様書無しさん2010/08/19(木) 05:14:16
>>476
うん解らんな
バッファオーバーランによるスタック破壊が生じなければ、コアを吐く様な状況には陥らないはずだ
hoge() の戻り値が関数ポインタを char* にキャストしたモノであるとかの特殊な状況でなければ、
任意のコードを実行させる様な現象は生じないと思うんだが
説明よろ
478 :4772010/08/19(木) 05:23:12
hoge() の戻り値に書き込みを行なってもスタック破壊が生じるけど、これも特殊な状況だよ
479 :仕様書無しさん2010/08/19(木) 05:23:28
>>477
もう一度、>>405 を見てスタックの状態とスタックポインタと返値のポインタが指しているところを考えてみたら。
480 :仕様書無しさん2010/08/19(木) 05:25:28
>>478
const 付いていないのに、なぜ特殊なのだ?
482 :仕様書無しさん2010/08/19(木) 12:14:39
>>453
hoge()から戻った後に、特定の無関係っぽい関数を呼ばないと期待した動作にならないとか?怖すぎる…
483 :仕様書無しさん2010/08/19(木) 16:36:09
>>479
hoge() の戻り値に対する書き込み、hoge() の戻り値を strcpy() 等の src として使用した時に生じるかも知れない
オーバーラン、この二つしかスタック破壊の可能性は無いと思うんだが、それ以外に有れば教えてくれ

>>480
いくらなんでも書き込みを許す領域を返す関数にスタックは使わないと思うんだが...
まぁ俺の常識が通用するならあんなコードは生まれないか
484 :仕様書無しさん2010/08/21(土) 06:42:58
>>483
その関数の仕様を見た人が、戻り値がすでに巻かれたスタック上にあることを予期できると思う?
その関数を実装した時点では返り値の領域に書き込む予定がなくても、
後々の改修でとんでもない地雷になるぞ。
485 :仕様書無しさん2010/08/21(土) 06:56:51
すでに破棄されている領域を指しているものを返しているという時点で、どのような不具合が発生する可能性があるかを考えられない人もいるんだな。
486 :仕様書無しさん2010/08/21(土) 07:00:23
解放したスタックは、参照する前に割り込みで使われてしまう場合がある。
487 :仕様書無しさん2010/08/21(土) 07:38:54
よし、strを参照する間は割り込みと関数禁止してもちろんスレッドも全部停止。
489 :仕様書無しさん2010/08/21(土) 12:24:05
strtokをマルチスレッドで多用してるせいか、頻繁に落ちます。
まあテスト用ツールだからまだいいんだけど、リスタートがめんどくさい。
491 :仕様書無しさん2010/08/21(土) 12:46:25
リエントラントにすることでスレッドセーフにするものがある場合、
_r が名前の末尾についている。
492 :仕様書無しさん2010/08/21(土) 12:48:57
組み込み用だし、今の環境じゃstrtok_rを自作しないといけない。めんどい。
493 :仕様書無しさん2010/08/21(土) 21:21:31
>>492
strtokに一枚皮被せて排他制御すれば?
494 :仕様書無しさん2010/08/21(土) 21:33:41
>>493
タスクAでstrtok使ってる途中で、
優先度の高いタスクBが起き出してstrtok使って、
タスクBの仕事が終わったらタスクAに戻る。
そんな状況で排他制御なんか解になるかよ。
495 :仕様書無しさん2010/08/21(土) 23:15:17
_beginthreadex() でスレッドをスタートさせれば、strtok() って勝手に
スレッドセーフになるんじゃなかった?
496 :仕様書無しさん2010/08/22(日) 00:08:13
>>494
489の
|テスト用ツールだからまだいい
という文はスルーですか?
497 :仕様書無しさん2010/08/22(日) 08:54:56
>>495
CRE_TSK()でそんな高級なことやってるんかいな。
499 :仕様書無しさん2010/08/22(日) 13:55:49
工夫して使えばええがな

#include <stdio.h>
#include <string.h>

int main()
{
    const char *delim = " \t";
    char str[] = "om mani padme hum";
    char *end = str + strlen(str);
    char *pp, *p = strtok(str, delim);
    while(p) {
        printf("%s\n", p);
        pp = p + strlen(p) + 1;
        if(pp >= end) break;
        p = strtok(pp, delim);
    }
    return 0;
}
500 :仕様書無しさん2010/08/22(日) 16:23:21
>>499
その工夫+排他ラップが必要じゃね?
501 :仕様書無しさん2010/08/22(日) 16:30:31
次のライブラリ関数は、static 変数に結果を保存して返すので、スレッド・セーフではない。

getlogin() readdir() strtok() asctime() ctime() gmtime() localtime() rand() getgrgi() getgrnam() getpwuid() getpwnam()

らしい
502 :仕様書無しさん2010/09/14(火) 19:48:00
String flg;
(中略)
if(flg == "1")

String型でフラグ宣言するのって実際どうなの?
1かブランク以外使わないならbool型じゃダメなのって思うんだけど。

あとよく会社の人が処理の流れを「ロジック」って言ってるけど
「アルゴリズム」とどう違うのだろうか、前者は回路的な論理だった気がするんだけど
504 :仕様書無しさん2010/09/14(火) 20:34:29
>>502
異なるプラットフォーム間でやりとりするなら文字列を使うのは結構良い方法だよ
505 :仕様書無しさん2010/09/14(火) 21:01:47
>>504
同じプラットフォーム間でかつVCだったらどうなるのっと
506 :仕様書無しさん2010/09/14(火) 22:11:58
別に気にするほどのものでもないような。

それよりflgって名前のほうがなんかいやだ。
507 :仕様書無しさん2010/09/14(火) 22:39:55
前に居た会社はがっつりそんな感じで文字列でフラグ立ててた。
dbに落ちてる、ゼロ詰めアルファベット混在の謎のフィールドなんてのもあったからかな。
フィールド名はyobi。まだ何桁目が何か大体覚えてる。
なんで手遅れになる前にalterしない? とか最初は思ってたけど、麻痺した。

転職して、正気を取り戻したけど。
508 :仕様書無しさん2010/09/14(火) 22:55:23
プラットフォームの設計はDBの項目設計が全て。
プラットフォーム間はどの項目を転送するか?の設計に尽きる。



みたいな古の考えの元に動いてるプロジェクトは多いからなあ。
大量の設計者、会議、コーダー、工数を武器に、
大金掛けて作るのなら、それでも良かったんだけどな。

時代が変わったっての理解出来ない人が多いのが、
日本のこの業界のダメなところ。
509 :仕様書無しさん2010/09/14(火) 23:23:55
>>502
アルゴリズム∈ロジック じゃね?

特定の問題を解くためのロジックがアルゴリズム
510 :仕様書無しさん2010/09/15(水) 02:37:41
>>507
「某T社で保守やってる友人から聞いた話。テーブルにカラムが一つしか無くて、char型だったそうだ。0から○バイト目まではIDで、×バイト目までは名称で、△バイト目までは○○で、みたいな造りで泣いたとのこと。」
ttp://twitter.com/vjroba/status/13780881900
511 :仕様書無しさん2010/09/15(水) 07:08:25
>>510
昔はそういう風にしかできない場合もあったし、高速化のためにやっていたのかもしれないので、叩くほどのこともない。
しかも、関数一個作れば、普段は気にしなくてもいいはず。
513 :仕様書無しさん2010/09/15(水) 13:48:08
>>511
MSSQLで、substringでselectするんだぜ。
信じられんかったよ。
514 :仕様書無しさん2010/09/15(水) 14:01:57
>>513
それはひどい。
516 :仕様書無しさん2010/09/15(水) 19:44:12
そういうダメな作りがいつまでも生き残るのは、既存の技術者がわざとそうしているためだ。
例えば関数化していちいち気に無くても済むように工夫をすると、
誰でも入ってこれるようになるので、自分の立場が危うくなる。
あくまでも、自分しか触れない領域を確保したいがためなのだ。

望み通りサッサと辞めて上げるのが吉
517 :仕様書無しさん2010/09/16(木) 03:41:18
>>513
まあ仕様がきっちり決まってるならビュー1個作れば解決な気もするな。
520 :仕様書無しさん2010/09/16(木) 12:54:09
>>516
それなんて年金システム?
521 :仕様書無しさん2010/09/16(木) 13:20:58
RDBではない時代に設計されたんじゃないのか? 単純な方法でランダムアクセスできるから、用途によっては非常に高速。
522 :仕様書無しさん2010/09/18(土) 18:24:45
昔、パンチ屋さんに入力を頼むと、そういう固定長で返してきたな
アンケートとか名簿入力で万件単位だったけど
523 :仕様書無しさん2010/09/18(土) 22:03:13
>>522
汎用機のデータフォーマットは、たいてい固定長だよ。
COBOLと相性が良いため……というか、COBOLが開発された時代に大量データを扱うには固定長しか選択枝がなかった。

CSVやXMLはPCやunixのフォーマットだと思った方がいい。
524 :仕様書無しさん2010/09/19(日) 00:58:31
>>523
どうやったら選択枝って変換になるんだ?
変換辞書にいたずらされてるのか?
運輪省とか国士交通省とか
525 :仕様書無しさん2010/09/19(日) 02:01:25
>>524
Google IMEの4番目の候補にありやんのw
さすがに選択肢のほうが上だったけど。

”選択枝”でググってみると「役所の文書で「枝」が使われていることがあるが、
当用漢字に『肢』が入ってなかったせいかもね」といった推測もあった。
531 :仕様書無しさん2010/09/20(月) 18:24:48
ATOKは金掛かるけどGoogle IMEはタダだから薦めやすい。
MS-IMEに文句いいながら使い続けるくらいならGoogle IMEのがなんぼかマシ。

ま、俺はATOK使うけど。
533 :仕様書無しさん2010/09/22(水) 02:22:37
よっぽど糞なIMEでもなけれまMSIMEより悪いってこたあないだろう。
どうせMSIMEも中華製だしな。
534 :仕様書無しさん2010/09/22(水) 02:29:53
万が一最高の変換精度を誇るほどのモノであったとしても
百度には絶対に手を出さないわ
535 :仕様書無しさん2010/09/22(水) 02:38:07
>>533
WJEベースの頃はまだマシだったんだけどね。
やっぱり男は黙ってSKKだ。
最近はemacs vs viって聞かないなぁ。
537 :仕様書無しさん2010/09/23(木) 00:22:33
>>535
私の最初はegg だったなぁ。
そして、なんで vi なんか使ってるんだろうと不思議に思ってた。
538 :仕様書無しさん2010/09/23(木) 06:49:14
いまだにいるぞ
「俺はスーパーハッカーなんだぜ」的な顔で鼻穴をヒクヒクさせながら得意げにviを使っているがき
539 :仕様書無しさん2010/09/23(木) 23:47:43
本番機にはviすら入っていませんでした…… orz
edは入っていたのでコレで何とかしましたが……

vi と ed は使えるようにしておかないと困ると思いました。
(使うコマンドは5つ位なのでメモを持ち歩けば十分かな?)
540 :5372010/09/24(金) 00:14:23
確かに使いこなせなくとも全く使えないのはマズイと知るのにそう年月はかかりませんでしたね。

もし ed すら入ってないとしたら、、、あなたならどうする?
541 :仕様書無しさん2010/09/24(金) 00:14:27
>>539
あるある。
echoとheadとtailで一生懸命ごまかしたことがある。
542 :仕様書無しさん2010/09/24(金) 00:20:06
>>540
cat > file
くらいか‥‥‥。
543 :仕様書無しさん2010/09/24(金) 07:52:04
DOS端末(?)でcopyコマンドでバッチファイルを組んでた先輩の目はいきいきしていたのお
544 :仕様書無しさん2010/09/25(土) 06:31:26
メクラ打ちで全部打って、間違えがあったら死ぬので、
1行づつファイルにしといて、最後に copy + だな。


つか、edlinすらなかったのかよ。


つか、今vistaで試したが、未だにedlin入ってんだなw
545 :仕様書無しさん2010/09/25(土) 08:48:34
vistaのedlinのメンテとかしてる人ってどんな気持ちだろうなw

「あなたには新Windowsの開発に参加していただきまます」
「このedlinのバージョンを・・」
546 :仕様書無しさん2010/09/25(土) 10:27:04
うほっ
楽な仕事回ってきた
どうせ誰も使ってないし
バグも糞もないよな
547 :仕様書無しさん2010/09/25(土) 11:03:24
>>544,545
存在すら忘れてたけど、まだ入ってるんだな。
でも、それを使う状況って考えたくねぇよw
549 :仕様書無しさん2010/09/25(土) 15:14:16
edlinは、
昔のバッチファイルで、パイプでedlinにつないで、テキストファイルを編集しているものがあるので、残っていたのだろう。
しかし、7でとうとうなくなった。
551 :仕様書無しさん2010/09/25(土) 19:37:49
>edlin
どうせ仮想86で動かすんだから
コンパイルしなおすだけじゃねーの?w
552 :仕様書無しさん2010/09/25(土) 20:00:43
うむ。
>>545 が言う開発の仕事というのも、ヴァージョンを書き直してリコンパイルするだけだろうなww
553 :仕様書無しさん2010/10/04(月) 21:57:39
>>537
おれも昔はviのよさがぜんぜん理解できなかったけど、
仕事とでつかわざるをえなくって、使ってみたらすごいよかった。

今はVSを使ってるけど、VSにviのキーアサインがあったらそれ使ってるとこだよ。
554 :仕様書無しさん2010/10/04(月) 22:00:48
>>553
VimとかVSに組み込めるけど。
555 :仕様書無しさん2010/10/05(火) 06:50:37
具体的にはviのどういうところがいい?

使ってみようかなとは思うんだけど、仕事では使う機会無いし、
なかなか踏ん切りが・・。
556 :仕様書無しさん2010/10/05(火) 07:47:24
踏ん切りってなんだ。
vi自体の良し悪しはさておき、Linux/Unix使うなら常識的に使えるべきエディタだろ>vi

「Linuxは超詳しいですけどviは使ったことないっすww」なんて人間は有り得ない。
Linuxのセットアップすらしたことがないと自爆してるようなもんだ。
558 :仕様書無しさん2010/10/05(火) 19:21:01
>>556
emacsが使えれば、99.99%の用事が
すむけどな。w
559 :仕様書無しさん2010/10/05(火) 20:31:32
viなんて基本スキルの一つだろ
使えない事を自慢してもいいこと無いぞ
560 :仕様書無しさん2010/10/05(火) 21:07:03
10年前はvi派だったけど、久しぶりに使ってみると
さすがに古いエディタだなぁ、と思うよ。
範囲選択して削除するだけで:.,+23dとか、やってられない。超しんどい。
561 :仕様書無しさん2010/10/05(火) 22:45:49
vimしか使ったことがない俺にemacsとの比較を頼む
562 :仕様書無しさん2010/10/06(水) 00:17:23
>>561
差はあまりないぞ。どちらもコマンドを入力すると各コマンドの実行モードになる。
viはコマンドの数が少なく、キーバインドの変更が面倒なだけ。
564 :仕様書無しさん2010/10/06(水) 02:13:35
>>560
そりゃそんな使い方してたらしんどかろうよ
普通24dd
566 :仕様書無しさん2010/10/06(水) 06:34:47
vi は i、w、q、x、: と ESC だけしか知らないけどなんとかなっている
569 :仕様書無しさん2010/10/06(水) 09:17:01
20年以上使ってるけど、
マークとかタグとか使ったことねえw
572 :仕様書無しさん2010/10/06(水) 17:10:13
>>562
それはvimとviの比較だ。
573 :仕様書無しさん2010/10/06(水) 17:12:28
viは、
* cw とか d/ は編集コマンドと移動コマンドの組み合わせ
* コマンドの前にアドレス指定できる
* .

あたりを知ると目の前にいろいろ開ける感じ。
574 :仕様書無しさん2010/10/08(金) 05:51:49
俺は/etc/passwdや/etc/hostsも含め、
ほとんどのファイル編集作業をeclipseでやってるなあ。
575 :仕様書無しさん2010/10/09(土) 19:51:27
俺はsambaでつなげてWindowsクライアントから秀丸で編集してたなあ。

7年前の思い出。
576 :仕様書無しさん2010/10/10(日) 00:43:25
秀丸と卓駆がTurboLinuxにあればなぁ…と思ったのも懐かしい思い出
577 :仕様書無しさん2010/10/10(日) 01:58:33
viを使うのは、ほかの便利な
エディタが入ってないからってだけ。
昔DOSでedlinを使ってたのと同じ理由。
578 :仕様書無しさん2010/10/10(日) 08:05:53
>>577
何を言っているんだ、君ぃ?
viがなくたって、edがあるじゃないか!exもあるじゃないか!
579 :仕様書無しさん2010/10/10(日) 18:57:09
>>577
viってのは、UNIXの標準エディタでね。
とりあえず、vi使えれば、大抵のUNIXはなんとかなったもんだ。

初めて仕事で触ったのがSolarisでね、
もちろん、GUIなエディタもあったけど、
telnet接続でも使えるってのはよかったね。
最初は面倒くさいと思ったけど、
実際はよく練られてると思うよ。
いまでも使ってるし。
580 :仕様書無しさん2010/10/10(日) 20:09:27
>>579
Joyは練らずに作ったと言っている。
581 :仕様書無しさん2010/10/10(日) 20:14:54
exとviは同じもんだろ
exだけあってviがない環境などありえない
582 :仕様書無しさん2010/10/10(日) 21:06:55
おまいらがうらやましいよ。
俺の周囲では、変数のないクラスを作るヤツが平均的。
使用するときは外で変数定義してねって。アホすぐるw
583 :仕様書無しさん2010/10/10(日) 22:13:06
>579
今のviは残骸。
本当はずっと機能豊富だったのに度重なるハードウェア故障でソースが失われ、
やる気を失った作者がバックアップが残っていた何世代か前のソースでケリつけたもの。
584 :仕様書無しさん2010/10/11(月) 06:59:21
>>579
そうか?
俺がUNIX触り初めた時には、
rootはviが使えない状況でも編集できなきゃいけないということで
edとexも必須だった。

まさか、viはいつでも使えると思っているほど「ゆとり」世代なのか?
586 :仕様書無しさん2010/10/11(月) 15:26:56
>>573
俺はカーソルの移動だけで開けた感じがした。
587 :仕様書無しさん2010/10/11(月) 15:45:18
>>584
そゆんじゃなくて、
emacsがなくったって、viはあったってことでふ。
588 :仕様書無しさん2010/10/11(月) 20:01:14
>>587
そうじゃなくて、
viが使えない状況というのもあるのだから、
viさえ使えれば絶対というわけでもない。

はっきり言って、今時ならviもemacsも大差ない。
589 :仕様書無しさん2010/10/12(火) 00:54:21
SELinuxの場合、タイプラベルをきちんと扱うエディタはVimが無難とか。
今はどれだけ増えたか知らないけど。
590 :仕様書無しさん2010/10/14(木) 01:37:08
vi 使えない状況で思い出したが、ls を消してしまったときはどうしようかとオモタよ
591 :仕様書無しさん2010/10/14(木) 01:54:19
SunOSの 4.1.3 くらいの頃のマニュアルに、非常手段の例として
ファイル一覧を見るには echo *
ファイルを作るには echo ... > outfile
ファイルを表示するには while read ... ... < infile
みたいなのが載ってた希ガス。
592 :仕様書無しさん2010/10/17(日) 00:22:25
10年くらい前に emacs 禁止の現場が有ったな
理由はメモリ消費量だったんだが、あの頃のマシンってどのくらいのメモリ積んでたんだろ?
593 :仕様書無しさん2010/10/17(日) 02:35:41
unix系マシンのメモリは高価だったので必要最小限しか積んでいなかった筈。

ヘタすると128MBとか256MBとかだったり……
595 :仕様書無しさん2010/10/17(日) 07:18:15
10年前にはもうemacsぐらい問題にならないぐらいメモリ積んでたろ。
20年前ぐらいのSun3とかの時代にはemacsの禁止には意味があった。
596 :仕様書無しさん2010/10/17(日) 13:08:06
>>595
10年前の時点での最新機種ならば、問題にならなかったろう。
開発機が、その時点での10年モノだった可能性は?
・開発機はコンパイルとテスト実行だけできればよいという観点でメモリをケチるケースが結構あった。

本番機はそもそもemacsが導入されていないケースが多い。酷い時はviすら入っていない……
597 :仕様書無しさん2010/10/17(日) 15:35:18
>>596
えっと、Y2K問題まっさかりの頃に、開発機がemacsが動かないスペックだったの?
それはかなり少数派だと思うよ。
598 :仕様書無しさん2010/10/17(日) 15:54:36
いや少数派というか偽装ハケンやら3重請負とかそういうところならあるかも。
599 :仕様書無しさん2010/10/17(日) 16:28:03
>>596-598
開発マシンは ultra-sparc(スペル正しい?)だったかな、Emacs が動かないスペックでは無いよ
正にY2K対応の現場だったんだけど、とにかく人数が多い現場で一つのマシンに20人くらいぶら下がってたからかなぁ


600 :仕様書無しさん2010/10/17(日) 16:36:04
>>599
ultra sparcなんて十分に贅沢なマシンじゃねえかw
俺の知ってる現場じゃ、68kのsunでemacs普通に使ってたぞ。
601 :仕様書無しさん2010/10/17(日) 17:52:39
emacs禁止は、シェアしている場合のルール。
専用ならそんなルールはできない。
ぶら下がっている奴が多ければ、今でもあり得る。
602 :仕様書無しさん2010/10/17(日) 17:52:42
>>600
CPUの問題じゃないからねぇ

68000 使った sun なんて何時の話だよ、20年前でも 68020 だった記憶が有るんだけど
603 :仕様書無しさん2010/10/17(日) 19:13:47
いま使っているUNIX鯖はemacs入ってないな。viだけ。

若干修正するには使えるけど、これでコーディングとかは
無理だなぁ。


604 :仕様書無しさん2010/10/17(日) 20:07:18
>>601
emacsのフットプリント計測してみろ。それがどんなナンセンスなことかわかるから。
605 :仕様書無しさん2010/10/17(日) 21:02:17
>>604
CPUパワー食うからなあ
610 :仕様書無しさん2010/11/08(月) 18:10:31
最近よく奴隷化だ奴隷化だって、さも正論のようにのたまうドヤが多いが
じゃあ、なんなら奴隷じゃないと言えるのか
人間社会、利権を主張するヤツしかいなかったら回らんよ
これは日本に限ったことじゃないし、会社に限ったことでもない
そして、どうしようもない環境に立たされている人間が
それでも幸せに生きようと自分を騙してまで頑張ることに対し
誰がそれを間違っていると言えようか
612 :仕様書無しさん2010/11/10(水) 23:40:35
日本に生まれたからには、90%以上の確率で奴隷としての生涯が確定するわけだよ。
こんな国は、アフリカも含めて、現代では日本だけだろう。
613 :仕様書無しさん2010/11/11(木) 01:03:52
いやいや、何をもって90%とか言ってるのか意味わかんないし
何をもって奴隷としてるのか定義してないから説得力ないよ

とりあえず>>612は早く会社やめられるといいね
614 :仕様書無しさん2010/11/14(日) 06:40:15
奴隷なら仕事をやれるという自由もないはずなんだが、日本にそんなところあるのかなあ?
借金重ねたやつは、死ぬまで働け
615 :仕様書無しさん2010/11/14(日) 15:08:08
>>614
>借金重ねたやつは、死ぬまで働け
今の引退前後世代と国会議員と役人どもに言ってくれ
616 :仕様書無しさん2010/11/14(日) 16:57:18
人間の馬鹿さ加減に失望した書き込み
>>615
インフラ使わずに生活してるのか?
その書き込みのために使った電力インフラと通信インフラとPC入手までの流通インフラは無料で整備されたのか?
列島改造計画があったからこそのインフラ整備、国債残高。恩恵を享受してる現代世代に文句言う資格はない。
620 :仕様書無しさん2010/11/16(火) 07:01:08
if [ !-e ${foo} ]; then
  echo -e "" > ${foo}
fi
621 :仕様書無しさん2010/11/18(木) 21:49:35
>>620
何そのキモイ書き方……。
逆に興味出てくるわ……。
624 :仕様書無しさん2010/12/05(日) 06:16:20
>>405
これと同じようなのFで見たな。
strtokモドキ作っておきながら中身がこんなやつw
ン10年前に造られた奴らしいから下手にいじれないとか言ってたけど、
とりあえずプロファイラ通したら超腐ってたw
かなり昔のコンパイラだったからretarn(0);っとかあったな。
625 :仕様書無しさん2011/01/03(月) 21:12:15
C# なコード

private void Giko(Mona mona)
{
  if (mona == null)
    throw new ArgumentNullException("mona");

  // 以降monaはまったく使用されない。
}

----

これって何がしたいの?
monaを削除しても問題なく動くんですけど……
626 :仕様書無しさん2011/01/03(月) 21:21:04
C#関係ないじゃん
627 :仕様書無しさん2011/01/03(月) 21:24:06
>>625
mona != null っていう条件で使われてるじゃん
628 :仕様書無しさん2011/01/03(月) 21:44:51
>>625
最初は使っていたのがいらなくなったか、使うところまでインプリメントできていないか。
629 :仕様書無しさん2011/01/03(月) 23:33:18
引数無しの同名のメソッドが存在してないか?
たぶん、そっちと区別するためにダミーの引数を……
630 :仕様書無しさん2011/01/04(火) 00:14:40
答えは仕様書の中にある。
仕様書があればだが。
631 :仕様書無しさん2011/01/04(火) 00:16:36
フレームワークが自動で呼び出す類のメソッドだったりかな
632 :仕様書無しさん2011/01/04(火) 00:19:17
>>626
確かに関係なかった、すまない。

>>627
いや……それは関係ないんだな。

>>628
素直に、これが正解だと思うけど。こゆのってどうやってデバッグしてたんだろ。
デバッグしてる時に気づくよね?

>>629
探してみたがなかった。

>>630
予測していると思うが仕様書はついてなかった。


マジでいったいどういう経緯で書かれたソースなんだろ。
書いた人本人は読んでるのかなぁ……
633 :仕様書無しさん2011/01/04(火) 00:30:09
>>631
うんにゃ違う。

あと、実際にはmonaだけじゃなくて、
5つ引数があって、2つはnullチェックだけ、1つは使ってない。残り2つはちゃんと使ってる。

あとわかれば教えていただきたいのだが、
この手のデッドコード(っていうの?)はどうやって探せばいいのかね。
静的解析ツールとかで、向いてるのないのかな。
Resharperと、VSULTIMATEを合わせ技で使っても、nullチェックだけってのは検出できないのよね。
634 :仕様書無しさん2011/01/04(火) 00:38:55
同じエラーメッセージでも、
「、」:「,」とか「。」:「.」の組み合わせで発生箇所を把握できるようにしてるパターンあるな。
エラーメッセージまで仕様書で指定されてたら、行頭・末尾スペースの数とか。
メッセージボックス表示中にCtrl+Cでコピーできるから確認できる。
635 :仕様書無しさん2011/01/04(火) 00:42:18
>>633
その引数を、引数定義から外せば何故か落ちるという素敵仕様だったりする
かもしれないので、触らぬ神に祟りなし。
気持ち悪ければプロジェクトでdefineするか、ラッピング関数を作る方針で。
DBの不明カラム(どうやら文字列で0〜Fのフラグ16桁)も同じく。
636 :仕様書無しさん2011/01/04(火) 00:59:28
リファクタリングツールを使うと、無意味な引数があるメソッドができてしまうことがある。
637 :仕様書無しさん2011/01/04(火) 01:37:56
遙か彼方でこの引数につっこむヤツが再利用されるが
そこでnullだとこのメソッドが完走しようが何の意味もない
そこで先に呼び出されるであろうこのメソッドの中で
例外吐いて終了させればいい!
なんて気持ち悪い超やっつけコードだったりしてね
638 :仕様書無しさん2011/01/05(水) 02:44:11
>>625
monaのnullチェックを兼ねてるとか。
それにしても、やり方ってもんがあるだろうとは思うが。
639 :仕様書無しさん2011/01/05(水) 10:59:17
ぺてん師「王様、このプログラムには馬鹿には見えないコードで書いてあります」
640 :仕様書無しさん2011/01/05(水) 19:19:39
>>633
その2つの引数が共にnullでない時だけ処理をしたい、
いずれかがnullの時には例外を投げたい、
ということだろう。

例えば、銀行の振り込み処理で、口座に振り込み金額を加算する時、
振込人の名前と振り込み受付者は、口座残高への加算には何の関係もないが、
法律上の関係で振り込み人と受付者がないと加算してはいけないという制約があり、
念のためにnullかどうかチェックして、nullだったら例外を投げなければならない、
というのはあり得るかもしれない。

その他、いろいろとそのオブジェクト内の制約も、他のオブジェクトにもまたがった
制約もあり得るから、そのメソッドが動いているからといって、nullチェックを外して
いいとは限らない。
641 :仕様書無しさん2011/01/06(木) 10:56:45
それってnullチェックの場所がおかしいんじゃねーの?
642 :仕様書無しさん2011/01/06(木) 18:07:32
>>641
Giko()処理とmonaに設計上の制約関係があり、
それを確実にやらないほ非常にマズいのであれば、

if (mona != null) Giko();
else throw new MonaException();
を100箇所に書くよりも、

100箇所の呼び出し側は
Giko(mona);
にしておいて、Giko()内で
if (mona == null) throw new MonaException();
したほうがマシなこともある。

繰り返すが、これはあくまでGiko()処理とmona != nullの
間に設計上の制約関係が必須の場合な。
644 :仕様書無しさん2011/01/10(月) 03:29:30
>642

なるへそ。
でもそのケースならGiko()にパラメータを渡して判断させるよりも
-----
if (mona != null) Giko();
else throw new MonaException();
-----
をメソッド化しないか?
645 :仕様書無しさん2011/01/10(月) 05:37:49
>>644
ヒント: Giko(mona)とGiko()が併存していたとして、君ならどっちを使う?
646 :仕様書無しさん2011/01/10(月) 11:39:37
Giko(mona)の方が安全だろ
メソッド側で広域変数を勝手に読めってのは恐ろしすぎる
こんな実装したらクビにするよ俺は
649 :仕様書無しさん2011/01/10(月) 21:50:53
>>642
概ね理解した。

しかし、1点理解できない部分があるので教えてほしい。
>繰り返すが、これはあくまでGiko()処理とmona != nullの
>間に設計上の制約関係が必須の場合な。

これって、実際上ほとんどあり得ない場合じゃないかな。
そして、あり得たとしても推奨できない場合じゃないかな。(つまり、設計見直しが必要になるということ)

このような設計上の制約関係が必須であり、かつ、それが設計上推奨されるような場合って想像つかないのだが。
650 :仕様書無しさん2011/01/10(月) 21:52:51
>>646
お前さん、事の発端となったコードを勘違いしている。

>メソッド側で広域変数を勝手に読め
>>625を見りゃわかるが、メソッド側ではnullチェック以外で読んでない。
651 :仕様書無しさん2011/01/11(火) 07:51:16
>>642
その場合、Gikoを別クラスのメソッドにしたほうがいいと思う。
Yaruo yaruo = new Yaruo(mona);
yaruo.Giko();
----
で、
public Yaruo(Mona mona)
{
  if (mona == null) throw MonaException();
}
652 :仕様書無しさん2011/01/11(火) 19:13:22
>>651
それじゃGiko()を呼ぶたびにnew Yaruo(mona)しなきゃならない。
はっきり言って、最低。
653 :仕様書無しさん2011/01/11(火) 21:04:26
この話って、monaがずーーーっと先で使われてるかもしれんってこと?
よーわからねーけんど、

Giko(mona);  //ここではnullチェックのみ。

/* ずーーーーーーーっと先 */

MonaTsukauMethod(mona);  //nullだとダメ。

ってことだよね? だとすると、
Yaruo yaruo = new Yaruo(mona);   //ここでnullチェック
yaruo.Giko();   //ここではmona使わない。
/* ずーーーーーーーっと先 */
yaruo.MonaTsukauMethod();  //ここでmona使う。

ってことなんじゃね?

657 :仕様書無しさん2011/01/22(土) 11:49:57
まあ所詮VBAなんて

「作業楽にするために組んでみました」
「アレもできると便利だな、組み込んじゃえ」
「おいおい便利なの使ってるじゃないか、独り占めしてないでチームに展開しようぜ」
「というわけでプロジェクト正式ツールに採用しますた」

みたいな感じで話が広がってくもんだから
保守性とかコードの見やすさなんて最初っから考慮されてないんだろうな

で、泣きを見るのは正式採用後にメンテさせられる人達。
658 :仕様書無しさん2011/01/22(土) 12:19:33
>>657
それを同一のguiでクラウドに載せろと言われる。プロでも涙目。
660 :仕様書無しさん2011/02/17(木) 16:52:18

【IT】インド政府、日米欧などのメーカーにソフトウェアの「ソースコード」開示を義務化…インド企業への技術移転を求める
http://raicho.2ch.net/test/read.cgi/newsplus/1297905103/
661 :仕様書無しさん2011/02/18(金) 09:18:56
>>660
やだ・・・・全部見せろだなんて恥ずかしい
662 :仕様書無しさん2011/02/18(金) 15:06:27
>>660
見ても分からんだろうし、そんなものに価値はない。

プログラマなら分かるはず。

この仕事で本当に価値があるのは、頭の中であって、成果物ではない。
663 :仕様書無しさん2011/02/18(金) 16:21:02
これから先のプログラマには難読化する技術も求められるようになるなw
664 :仕様書無しさん2011/02/18(金) 16:48:35
コメントを削除したり変数関数名を無意味な文字列化するツールがいるなw
667 :仕様書無しさん2011/02/18(金) 22:53:08
ソースなんて、馬鹿どもには良い目晦まし。
技術者は、既に次のステップに入ってる。
668 :仕様書無しさん2011/02/19(土) 18:07:00
C言語。
gotoで処理をあっちゃこっちゃに飛ばすのは辞めて欲しいなぁ。
ラベルで処理の内容を示す所まで行って、なんで関数にする事は頭に浮かばないんだ。
669 :仕様書無しさん2011/02/19(土) 23:54:24.85
ループ開始か

深いネストから飛び出すにはgotoが一番。
670 :仕様書無しさん2011/02/20(日) 01:12:22.38
>>669
深いネストをしないのが一番
671 :仕様書無しさん2011/02/20(日) 08:57:59.44
>>669
不快なネストをしないのが一番
674 :仕様書無しさん2011/02/20(日) 20:47:19.37
daemonは無限ループだぜ。
winだったメッセージループはくるくるまわってるぜ。
675 :仕様書無しさん2011/03/02(水) 15:59:28.74
C++なんだが、これってどうよ?

int hoge = true;
676 :仕様書無しさん2011/03/02(水) 16:50:33.46
>>675
じわじわ来るな
680 :仕様書無しさん2011/03/03(木) 00:09:17.98
#define true (int)~0

とかできるのかな?
683 :仕様書無しさん2011/03/03(木) 18:37:37.94
そう思っていてもいつの間にか
朱に交われば〜
になってたりして
684 :仕様書無しさん2011/03/03(木) 22:44:27.76
>>680
CはTRUEとかFALSEとか定義しないで素直に0かそれ以外使ったほうがいいな。

定義してあるとたまに
#define TRUE 0
#define FALSE -1
だったりするから油断できない。
685 :仕様書無しさん2011/03/03(木) 23:14:42.64
まぁ 耳タコかもしれんが
if(fp) と return 0

の関係ね。

0が正しいのか 1がTRUEなのか
途中でどっちにしたっけ? となる。
686 :仕様書無しさん2011/03/03(木) 23:25:13.17
enum FLAG_ON_1 { ON_1 = 0, OFF_1 = 1 };
enum FLAG_ON_0 { OFF_0 = 0, ON_0 = 1 };
てのを思い出した。何の嫌がらせかと

// 初期値をオンに設定
SetIntParameter(ID_XXX, (int)ON_1); // ××は負論理
SetIntParameter(ID_OOO, (int)ON_0); // ○○は正論理
...
// もし××が0なら
if (GetIntParameter(ID_XXX) == (int)ON_0) ...

みたいにあちこち取り違えてて、項目表でどっちの論理か確認しながら直さないといけないし
つか、そこ0って書かれたらオンオフどっちにしたかったのかわからんだろ
687 :仕様書無しさん2011/03/03(木) 23:59:54.06
_Bool とか stdbool.h の立場はどうなる?
689 :仕様書無しさん2011/03/08(火) 21:46:30.40
>>684

> #define TRUE 0
> #define FALSE -1

移行するプログラムにこれと同じのがあった。
さらに、そのソースから呼んでいる関数があったのだが、そこでは

#define TRUE -1
#define FALSE 0
とか定義されてるし。疲れた
690 :仕様書無しさん2011/03/08(火) 22:37:24.37
正常終了の0 と
if文の0以外が真 は
不条理だよね。

どこかで何かがねじれたんだね。
695 :仕様書無しさん2011/03/12(土) 22:45:11.13
インド人が悪いってことで
goto >>660;
696 :仕様書無しさん2011/03/19(土) 22:40:01.65
public void getHoge
public String setHage

もう嫌
697 :仕様書無しさん2011/03/19(土) 23:55:09.74
>>696
それはバグだろう。
699 :仕様書無しさん2011/03/23(水) 23:14:10.35
C言語で日付の加減算を自前でコーディングしてあった。
2012/02/30, 2012/02/31 とかありえない日付を出力してくれるし。
さらに1日加算すると2012/03/03と出力する素敵な作りorz
#うるう年のテストパターンで発覚

マイクロソフト ワイヤレス ブルートラック マウス Arc Touch Mouse RVF-00006
マイクロソフト ワイヤレス ブルートラック マウス Arc Touch Mouse RVF-00006