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

1 名前：仕様書無しさん mailto:sage [2007/04/02(月) 12:45:06 ] この会社辞めようと思ったソースコード。 プログラマとして幻滅するソースコード。 プログラマを悩ませるソースコード。 をつらつらと綴っていって頂戴。 ちなみにここは質問スレじゃないので 技術的な質問がしたいならム板 pc11.2ch.net/tech/ に逝って。 前スレ この会社辞めようと思ったソースコード＃15 pc11.2ch.net/test/read.cgi/prog/1167117526/ 304 名前：仕様書無しさん mailto:sage [2007/05/19(土) 08:56:50 ] バグ、それも謎の挙動が多いと評判最悪のシステムのメンテを担当する事になった。 普通に順繰りに実行すればいい処理1〜3をわざわざ for(i=1; i<=3; i++){ switch (i){ case 1 : 処理1 case 2 : 処理2 case 3 : 処理3 } } みたいな謎のロジックで実行していたりしてアタマ痛い…他にも char *hoge(char *s, const char *ct, int n){ if n==0{ strcpy(s, ct); } else { strcat(s, ct); } retuen s; } を遥かに大規模にしたような、標準関数を1つに纏めて、引数で実行する関数を 選択するようなのもあって、作った本人はかなり自慢げに 「これで標準関数を覚える必要が無くなり、ソースの可読性も増した」と 94年当時の日付入りでコメントを残しているんだが、 その問題の関数の前後で情け容赦なく素でstrcpyとか使われていて、 もう何が何だが･･･ リファインして良いか責任者に聞いたら、結構重要な部分だから、 汚いソースでも動いている以上手直し不可だって。 305 名前：仕様書無しさん mailto:sage [2007/05/19(土) 09:11:22 ] >>304 上はよく見る。 下もよく見・・・るわけねえええええ 306 名前：仕様書無しさん mailto:sage [2007/05/19(土) 09:13:56 ] >>304 上は各処理の後にbreak;はあるの？ あったらただの馬鹿だな。 307 名前：仕様書無しさん mailto:sage [2007/05/19(土) 09:14:24 ] >>304 Fの仕事の後では全然なんでもないと感じる。 やつら車輪の再発明大好きで、標準関数同等品の再開発はもちろん、 それを作ったのが同じF内でも課が違えば、自分ところで再開発するからな。 一つのシステムに同じ機能が何箇所も独立してコーディングされてて、 成績上位者が軒並み逃げるのも判る気がする、と思った。 308 名前：仕様書無しさん mailto:sage [2007/05/19(土) 09:33:28 ] >306 >上は各処理の後にbreak;はあるの？ 実はある…orz 完璧、思いつきで組んでみた的な無駄なロジックいっぱい。 一つの関数内でローカル変数を初めはインデックスカウンタ、 下の方では値の交換のための受け皿に使ってたりもするし。 309 名前：仕様書無しさん mailto:sage [2007/05/19(土) 09:57:15 ] >>308 >一つの関数内でローカル変数を初めはインデックスカウンタ、 >下の方では値の交換のための受け皿に使ってたりもするし。 この誘惑に駆られちゃうことがあるな… 新しい目的のローカル変数が欲しいんだけど、既にいくつものローカル変数があって 新しく宣言するのは気が引ける時とか。 「おやこの変数この処理の後は使ってないや、使っちゃえ」って感じで。 保守を優先するなら、目的が違えば新しく宣言すべき？（規約にもよるだろうけど、一般論として） 310 名前：仕様書無しさん mailto:sage [2007/05/19(土) 10:28:46 ] >>309 > 保守を優先するなら、目的が違えば新しく宣言すべき？（規約にもよるだろうけど、一般論として） 当然だ。 ローカル変数多すぎってのは、リファクタリングの必要がある可能性があるよ。 311 名前：仕様書無しさん mailto:sage [2007/05/19(土) 11:06:29 ] クソみたいなソースをリファインするのは我慢できるが、 クソみたいなソースと付き合うのは苦痛だな。 312 名前：仕様書無しさん mailto:sage [2007/05/19(土) 11:34:09 ] >>309 確認したいが。 その関数内のローカル変数の現在の個数はいくつか？ （一般論を知りたいか？ｗ） 313 名前：仕様書無しさん mailto:sage [2007/05/19(土) 11:53:02 ] >>309 ジジイみたいに関数の先頭でどっさり宣言するからだろ。 スコープ絞って宣言すれば、ほとんどそんなことにはならん。 314 名前：仕様書無しさん mailto:sage [2007/05/19(土) 12:23:41 ] ＞２９６ freeってそんなもんでしょ。組み込みじゃなくても GNU　libcのmalloc/freeはもっとスゴイ、という話を聞くけど。 315 名前：仕様書無しさん mailto:sage [2007/05/19(土) 12:34:29 ] >>312 １０個かな。 ２次元矩形の現在の開始〜終了座標と更新前の同座標を保持する必要があって、 元データの構造体１個と、それぞれ単独変数に追い出した４個×２で９個。 それに、問題の変数１個。他にもあったかも。 単独変数に追い出した４個×２はなくてもいいと思うんだけど、それないとコード追いにくいって メンバがいるもんで、残してる。 リファクタリングの精神忘れてました。ありがと。見直してみる。 316 名前：仕様書無しさん mailto:sage [2007/05/19(土) 12:45:31 ] >>314 組み込みじゃなければmalloc/freeを使えば良いわけで。 317 名前：仕様書無しさん mailto:sage [2007/05/19(土) 12:55:01 ] そういや昔居た会社での事。 引数の数が8個9個が当たり前で、うち6個はどの関数でもやり取りされてるから、 「構造体にまとめませんか？」って提案したら、「難しくなるから駄目」って却下。 やたら構造体とかポインタだとかに拒絶反応のあるところだった。 318 名前：仕様書無しさん mailto:sage [2007/05/19(土) 13:03:11 ] >>306 >>304の上の処理はbreakが あるかないかよりもswitchの後に続く処理が あるかないかが重要なんでは？ 319 名前：仕様書無しさん mailto:sage [2007/05/19(土) 13:05:28 ] >>296 malloc/free周りは基本はそんなかんじでしょ。 俺も自作したとき、似たようなコード書いた。 320 名前：仕様書無しさん mailto:sage [2007/05/19(土) 13:13:34 ] >>309 俺は、単純なカウンタ変数やインデックスの 受け皿の変数は使いまわしてもいいと思う。 例えば int i, j, k; を意味ごとに int hoge_i; みたいに名前を変えたくないしな。 321 名前：仕様書無しさん [2007/05/19(土) 13:18:12 ] そんな素人コーディングだめだろ 俺等のところ同じようにしろ int int_id_0000001, int_id_0000002, int_id_00000003 こうやって全部定義すれば仕様書みれば全部意味がわかる 322 名前：仕様書無しさん mailto:sage [2007/05/19(土) 13:52:56 ] >320 必要な時にブロックを生成して、なかで int iを幾らでも定義すりゃいいじゃん。 323 名前：仕様書無しさん mailto:sage [2007/05/19(土) 13:58:09 ] >>309 グローバル変数として宣言すれば、宣言は１回で済むぞ。 同じものを幾らでも使いまわせる。 これは便利。覚えておけ。 324 名前：仕様書無しさん mailto:sage [2007/05/19(土) 14:53:47 ] 後輩がそのパターンをやてってくれて頭抱えてるんだが。 学歴あってもセンスないやつはダメだ('A`) 325 名前：仕様書無しさん mailto:sage [2007/05/19(土) 14:57:01 ] >>323 そういう時は、自分で同じパターンの 読みにくいコードを書いてやって、 後輩に読ませれてみればよい。 326 名前：仕様書無しさん mailto:sage [2007/05/19(土) 15:04:14 ] 本人はそれがわかりやすいと思って書いてるんだから 意図が理解できるはずもない 327 名前：仕様書無しさん mailto:sage [2007/05/19(土) 15:09:48 ] 仮に>>324みたいな事をやって、 そいつがそのソースを即理解できたのなら、 文句ないんじゃねえの？ だって本当に分かり易かったんだろ？ 328 名前：仕様書無しさん mailto:sage [2007/05/19(土) 15:12:24 ] とりあえずLispとかPrologとかマイナー系言語で書いて 「俺には判りやすいんだからいいだろ」といっとけ 329 名前：仕様書無しさん mailto:sage [2007/05/19(土) 15:29:50 ] >>327 自分が見て分かり易いかどうかより、 他人が見て分かり易いかどうかの方が重要なんじゃないか？ 330 名前：仕様書無しさん mailto:sage [2007/05/19(土) 15:32:20 ] 「俺はいつも"他人が見て分かり易いコード"を書くように努めている」 という奴に限って糞コードを書く件について、どう思う？ 331 名前：仕様書無しさん mailto:sage [2007/05/19(土) 16:10:17 ] >330 そこの会社のわかりやすいコードのレベル＝クソコードなだけ。 書いているうちにそれしかかけなくなる罠 332 名前：仕様書無しさん mailto:sage [2007/05/19(土) 16:31:38 ] みんないろいろなコメントありがとう。一般論もっと聞けるとうれしいけど。 >>320 i, j, k で思い出した。 漏れは i と j がぱっと見た目で区別しづらいことがあるから、 一文字変数は i, k, m, n, x, y, z, a, b みたいに、区別しやすい飛び飛びの アルファベット使ってる。l も大文字の I と混乱すると嫌だから使わない。 i, j, k のように一文字アルファベット連続で使うのは、どんな理由があるのかな？ 333 名前：仕様書無しさん mailto:sage [2007/05/19(土) 16:33:59 ] >>323 遠慮しときます。 ウッカリ、ある関数で使った後にもかかわらず別の関数で以前の値を保持しているつもりで 使おうとする実装をやってしまって、デバッグで痛い目にあったことがある。 334 名前：仕様書無しさん mailto:sage [2007/05/19(土) 16:41:27 ] >>332 大昔のFOTRANでI,J,K,L,M,Nで始まる変数は宣言なしで整数型になったから 335 名前：仕様書無しさん mailto:sage [2007/05/19(土) 16:53:02 ] >>334 とてもためになりました、ありがとうございます。 会社に入ってから勉強した文系プログラマなのでこうした基礎教養がないです。 336 名前：仕様書無しさん mailto:sage [2007/05/19(土) 17:13:00 ] N 　M Σ Σ　Aij i=0 j=0 こっちの法の使い方がもとだとおもうけどねー 337 名前：仕様書無しさん mailto:sage [2007/05/19(土) 17:19:11 ] 元来FORTRAN（FORmula TRANslation）ってのは数式の処理目的だから当然だな 338 名前：仕様書無しさん mailto:sage [2007/05/19(土) 17:25:33 ] 飛び飛びって初めて見たな。 それはそれで激しく嫌だ。 339 名前：仕様書無しさん mailto:sage [2007/05/19(土) 17:28:06 ] >>336 そして数式でiから始まる文字を使うのはiがindex(添え字)の頭文字だからだろうか。 iterationのiだと主張してる人もいたが数学に元を辿ると違いそうだなぁ。 340 名前：仕様書無しさん mailto:sage [2007/05/19(土) 17:32:41 ] 元FORTRAN屋なんて自分以外には何人生き残ってるか知らんが、 いまだにi〜nで始まる変数名を見ると「整数型」と思ってしまう。 たぶん、一生治らんなw 341 名前：仕様書無しさん mailto:sage [2007/05/19(土) 17:44:36 ] index j k length m number 一文字変数ならi〜nは整数だと感じる 342 名前：仕様書無しさん mailto:sage [2007/05/19(土) 18:26:05 ] それは普通だろ。 むしろ、「倍精度実数型」や「文字列型」とか定数のiを作るほうがどうかしてる。 何でうちの会社はこういうのがいるんだろう…。難読化か？ 343 名前：仕様書無しさん mailto:sage [2007/05/19(土) 18:33:01 ] 逆にaやbが整数だと気持悪い 344 名前：仕様書無しさん mailto:sage [2007/05/19(土) 21:20:44 ] >>338 漏れもすっきりしてるわけでありません。 i と j を打ち間違えてチェックに時間をとられたり、i I と l の区別に一瞬 ためらうことがあるので、そういうところで時間ロスしたくないと思って、 ぱっと見ても視認しやすい文字だけ使うようになりました。 皆さんはそういうことないですか？ 漏れが下手なんでしょうね。 345 名前：仕様書無しさん mailto:sage [2007/05/19(土) 21:58:25 ] >>344 そーゆー時はフォントを書き換えると良いよ 346 名前：仕様書無しさん mailto:sage [2007/05/19(土) 21:59:34 ] >>344 うちのコーディング規約では、そもそも1文字の変数名が禁止。 それと意味の無い変数名も禁止。 例えば表を処理する二元配列のループ回すカウンタとかなら、 int nCntRaw,nCntCol; とかになるかな。 347 名前：仕様書無しさん mailto:sage [2007/05/19(土) 22:13:21 ] >>345 そういう意見出ると思ってました。 開発環境が固定されてなくて、設定を持ち歩いたり、いちいちフォントを設定しなおすのが 面倒なんです。 使える開発環境のデフォルトの設定ですぐ読めるコードを優先してます。 >>346 普段は漏れもそうです。一文字変数は、ループカウンタのような限定された状況だけですね。 こんな感じ。 　　for ( i = nStartRow; i <= nEndRow; i++ ) { 　　　　for ( k = nStartCol; k <= nEndCol; k++ ) { 348 名前：仕様書無しさん mailto:sage [2007/05/19(土) 22:17:07 ] 寿命の短かったり重要でない、変数名が短いほうがいい。 ソースがうるさくなる。 349 名前：仕様書無しさん mailto:sage [2007/05/19(土) 22:19:17 ] >意味の無い変数名 だったら nXXXXって意味ないからやめろ int CntRaw,CntCol; でおけ 350 名前：仕様書無しさん [2007/05/19(土) 22:21:05 ] int CR, CCでいいじゃん 351 名前：仕様書無しさん mailto:sage [2007/05/19(土) 22:24:06 ] >>349 あー、説明不足で申し訳ナス。 メインC言語なんだが、「決まったプリフィクス」をつけることになってんだ。 癖でつけてしもた。 例えばこんなのが変数の先頭に付く int → n char → c void * → p int * → pn 構造体 → st 列挙型 → e グローバル変数 g_ 352 名前：仕様書無しさん mailto:sage [2007/05/19(土) 22:28:17 ] ハンガリアンはいまどき、はやらないな。 353 名前：仕様書無しさん [2007/05/19(土) 22:30:05 ] >>351 つか、M$すら使わなくなったDQN記法をなぜ採用する？ おまえの会社頭おかしくね？ 354 名前：仕様書無しさん mailto:sage [2007/05/19(土) 22:35:42 ] >>353 さぁ？そうなってる背景は知らんし、今んトコ困って無い。 良かったらどこがDQNなのか教えて貰えんか？ 355 名前：仕様書無しさん mailto:sage [2007/05/19(土) 22:45:41 ] 一文字変数禁止なんてルールきめたやつって、コードを読み書きした経験がろくにないんだろうな。 356 名前：仕様書無しさん mailto:sage [2007/05/19(土) 22:50:14 ] ttp://local.joelonsoftware.com/mediawiki/index.php/%E9%96%93%E9%81%95%E3%81%A3%E3%81%9F%E3%82%B3%E3%83%BC%E3%83%89%E3%81%AF%E9%96%93%E9%81%95%E3%81%A3%E3%81%A6%E8%A6%8B%E3%81%88%E3%82%8B%E3%82%88%E3%81%86%E3%81%AB%E3%81%99%E3%82%8B ハンガリアン記法の暗黒面が支配権を得たのだ。 それがなぜなのか、どういう経緯でそうなったのか誰も知らないのだが、 どうやらWindowsチームのドキュメントライターたちが、不用意にシステム ハンガリアンとして知られるようになるものを作り出したということらしい。 システムハンガリアンはlongを意味する"l"、unsigned longを意味する"ul"、 double word(これは、実際は、その、unsigned longと同じものだ)を意味する "dw"のような、あまり役に立たないプレフィックスを使う。 システムハンガリアンでは、プレフィックスが教えてくれるのは変数のデータ型だけだ。 プログラマたちは、自分たちの使っているハンガリアン記法の誤解されたサブセット がはなはだ煩わしくほとんど役立たずであることに気づき、反旗を翻したのだ。 Microsoftはついには人々に言い始めたのだ。「ハンガリアン記法は推奨しない」。 357 名前：仕様書無しさん mailto:sage [2007/05/19(土) 22:55:28 ] うちの会社にもいまだにハンガリアンしてるやつがいて ﾜﾛﾀ 358 名前：仕様書無しさん mailto:sage [2007/05/19(土) 22:59:08 ] 現在進行中の糞プロジェクトなんか、コーディング規約がめちゃハンガリアン でかけりゃでかいほどハンガリアン率が高いと思う 359 名前：仕様書無しさん [2007/05/19(土) 23:05:14 ] 俺できるよねって感じで売り込んでるじじぃPGなんかは ハンガリアン率が高い。 360 名前：仕様書無しさん mailto:sage [2007/05/19(土) 23:07:36 ] JavaとかUnix系とかはハンガリアン使わないんじゃないの? 361 名前：仕様書無しさん mailto:sage [2007/05/19(土) 23:08:03 ] int cntRaw,cntCol; 俺はこうかな。 362 名前：仕様書無しさん mailto:sage [2007/05/19(土) 23:08:49 ] つかRawって何だ。Rowだよな。 363 名前：仕様書無しさん mailto:sage [2007/05/19(土) 23:40:25 ] >>356を読んでみたが、デメリットが良く分からんかった。 個人的には変数名でデータの型がわかるだけで大分便利なんだが。 慣れてしまったら煩わしくも無いし。 慣れるまでに掛かるコストがメリットと釣りあわない(or無い)ので ハンガリアンなコーディング規約はクソだ、ということか？ 364 名前：仕様書無しさん mailto:sage [2007/05/19(土) 23:47:00 ] >>362 冷凍と生のカウンタなんだろ 365 名前：仕様書無しさん mailto:sage [2007/05/19(土) 23:51:15 ] >>363 型情報は名前にのせるほど重要じゃないってことだろ。 366 名前：仕様書無しさん mailto:sage [2007/05/20(日) 00:07:38 ] >>362 フツーに間違えた・・・。 よく間違える。 >>365 JAVAとかRubyとかはさておき、C言語じゃ大事だと思ってたんだが、 世間的にはそういう認識なんか・・・。 勉強になりました。 367 名前：仕様書無しさん mailto:sage [2007/05/20(日) 00:12:50 ] MSも捨てた記法だし 368 名前：仕様書無しさん mailto:sage [2007/05/20(日) 00:18:39 ] MSはC言語自体捨ててる 369 名前：仕様書無しさん mailto:sage [2007/05/20(日) 00:29:43 ] >>360 それが未だに使われてるから困る 死ねばいいと思う 370 名前：仕様書無しさん mailto:sage [2007/05/20(日) 00:33:01 ] >>366 型情報を変数名に入れると、 型が変わる度に名前が変わる事になる。 そんなのおかしい、不自然だと思わないか？ 例えば、「身長」がmm単位からcm単位に仕様変更され、 型が整数型から浮動小数点数になっても、身長は身長だろ？ 371 名前：仕様書無しさん mailto:sage [2007/05/20(日) 00:33:53 ] >>362 cunt rawの略。つまり生まんこってことだ。 >>363 変数の型を変えたい時に面倒なんだよ。 あと、型情報が重要じゃないわけではない。 変数の宣言箇所を見るのが面倒くさくなるほど ソースをでかくする設計をまず見直せって事でしょ。 プリフィクスなんていらん。 372 名前：仕様書無しさん mailto:sage [2007/05/20(日) 01:03:05 ] 読み返してみたけど。 プレフィックスをつけるべきだ という発言は誰もしていないね 373 名前：仕様書無しさん mailto:sage [2007/05/20(日) 01:10:10 ] >>363 変数名って適当な長さがあるでしょ。 その中に重要な情報を載せていくと型名を載せる余地が無くなるわけだ。 型名は探せばわかるが、変数名に載せないとわからない情報がある。 あとは、機械的にチェックするツールが無きゃ信用できないから意味が無いと思う。 374 名前：仕様書無しさん mailto:sage [2007/05/20(日) 01:11:44 ] >>372 皆>>354の質問に答えてるだけ 375 名前：仕様書無しさん mailto:sage [2007/05/20(日) 02:09:24 ] if(i==0){ 　foo(); }else{ 　//空文 } 376 名前：仕様書無しさん mailto:sage [2007/05/20(日) 02:18:26 ] 規約でelse省略不可だったんじゃないの 377 名前：仕様書無しさん mailto:sage [2007/05/20(日) 02:34:42 ] もともと処理あったけどいらなくなって消して、elseだけが残ったとか？ 378 名前：仕様書無しさん [2007/05/20(日) 02:42:21 ] >>269の逆バージョンという可能性も 379 名前：仕様書無しさん [2007/05/20(日) 02:59:30 ] if(i!=0){ //空文 }else{ huu(); } 380 名前：仕様書無しさん mailto:sage [2007/05/20(日) 07:10:11 ] Javaでハンガリアンやりたがる奴は頃してもいいよね。 381 名前：仕様書無しさん mailto:sage [2007/05/20(日) 07:23:06 ] >>370 型が変わると変数名も変えないといけないってのはハンガリアン否定論としてよく聞くけど、 実際問題、型を変える頻度ってどれくらいあるもの？ 変えるのだって、「拡張する必要があって止むを得ず」ならともかく、「使い方を間違ってたから 変更」みたいなのなら、それは設計をちゃんとやってないただのバカだと思う。 変数名の他の部分で、以前の型に依存した処理をやってて、バグを招く可能性がある。 それに、「変数名の型を変える」だけなら、今はエディタやIDEがマシになってるんだから、 一括置換ですむのでは？ >>356のリンク先で議論されている「チェックのしやすさ」の点で、システムハンガリアンも 有効活用できると思うんだけどな。こだわりすぎるとよくないけど。 382 名前：仕様書無しさん mailto:sage [2007/05/20(日) 10:15:33 ] 変数名を変えられるエディタなら、 変数の型もでてくるんでねーの。 ＃ま、クラス・構造体に対して、システムハンガリアンは ＃大抵のところ無力だから、どーでもいいけど 383 名前：仕様書無しさん mailto:sage [2007/05/20(日) 12:51:14 ] >>380 Yes 384 名前：仕様書無しさん mailto:sage [2007/05/20(日) 12:54:09 ] ハンガリアン使ってるのはうざいなぁ… 醜くて仕方がない 385 名前：370 mailto:sage [2007/05/20(日) 13:01:44 ] >>381 頻度とかは無関係。 別に同じシステム内に限った話じゃなく、 全く別のシステムでも、同じ物を表す変数の名前を付ける場合でもいい。 同じ物を示すなら、当然同じ名前を付けるだろ？ 名前に表現方法を入れるのは不自然だと言ってるんだよ。 身長の例でいくと、 単位がmmでもcmでもｲﾝﾁでも尺でも、身長は身長だ。 混在して使う必要がないなら、名前に表現方法など不要だろ？ 386 名前：仕様書無しさん [2007/05/20(日) 13:33:41 ] >>385 単位がmm、cm　→　基本型 身長　→　クラス わざと混同してるのか？ 387 名前：仕様書無しさん mailto:sage [2007/05/20(日) 14:16:48 ] ＞ハンガリアン どーでも良いが、そろそろ大分スレ違いじゃまいか？ 388 名前：仕様書無しさん mailto:sage [2007/05/20(日) 15:06:41 ] 相変わらずヴァカだなM$ 389 名前：仕様書無しさん mailto:sage [2007/05/20(日) 15:47:53 ] だから素人に文献書かせるとろくなことにならない 390 名前：仕様書無しさん mailto:sage [2007/05/20(日) 15:51:12 ] 自分が今書いてるところの変数の型も覚えてられないような奴とか、 覚えてられなくなるような無駄に長い処理書くような奴は プログラム書く資格ねぇよ。 こう言うと「他人が書いたのを解析するときにいいじゃないか」とか出てくるが、 「そのハンガリアンで書かれてる型が実際の型と一致してること」はまったく保証されないんだが？ >>381 頻度は確かに低い。低いが、無いわけじゃないだろ？ それに、型に依存した処理をやってて型変更時バグるってのは、「変更時にチェックしたか」が問題であって、 変数名をハンガリアンで書いてようが書いてまいが同じこと。 391 名前：仕様書無しさん mailto:sage [2007/05/20(日) 16:51:49 ] ハンガリアンは その変数が出てくるたびに いちいち/*コメント*/つけるようなもんだ。 392 名前：仕様書無しさん mailto:sage [2007/05/20(日) 16:58:58 ] 宣言部分を検索すれば済む話だよね 393 名前：仕様書無しさん mailto:sage [2007/05/20(日) 17:12:54 ] 検索するようでは駄目だ。 もう関数（メソッド）の長さの話になってしまうが。 394 名前：仕様書無しさん mailto:sage [2007/05/20(日) 18:23:13 ] っつーかIDE使ってれば変数の型なんぞすぐに知ることができるだろうに いったいいつの時代の開発環境なんでつか？ 395 名前：仕様書無しさん mailto:sage [2007/05/20(日) 18:32:51 ] viつこーてます 396 名前：仕様書無しさん mailto:sage [2007/05/20(日) 18:53:55 ] VisutalStudio を使いまわしてると わかるとおもうが、勝手に変数名に dwとか付いたり開発者が言いくる められたのかどうかしらないが、 仕様的にヴァカすぎる その仕様を疑いなくそのまま放置する M$の幹部どもも率直にヴァカまっしぐら というかハンガリアン広めておいて 元の文献の趣旨理解していないとは どういうカラクリになったらそうなる んじゃい！ 397 名前：仕様書無しさん [2007/05/20(日) 21:08:12 ] >>390 型変更した時に変数名を変えれば、それによる挙動のチェックを モレが出ないようにフレームワーク化出来る。 あと ＞「そのハンガリアンで書かれてる型が実際の型と ＞ 一致してること」はまったく保証されないんだが？ コーディング規約守れボケ。 約束事が守られてない前提で仕事出来ん。 規約に無いのにハンガリアンに頼る奴のことは知らん。 398 名前：仕様書無しさん [2007/05/20(日) 21:36:53 ] IDE全盛の今となってはハンガリアンが嫌われるのもよくわかるけど、 他人のコードがハンガリアンだからと言って貶す資格はないよね。 まあ、結局はコーディング規約守れって話だよね。 399 名前：仕様書無しさん mailto:sage [2007/05/20(日) 21:57:44 ] いや、だからハンガリアンがコーディング規約に無い以上、使ってもらっては困るんだがw >型変更した時に変数名を変えれば、それによる挙動のチェックを >モレが出ないようにフレームワーク化出来る。 あほか？これのどこがハンガリアンに関連すんだ？テストフレームワークとかコンパイラの仕事だろが よけいな仕事をやっておいて自己満足してんじゃねえぞ 400 名前：仕様書無しさん mailto:sage [2007/05/20(日) 22:02:40 ] このスレは基地外が多いですね 401 名前：仕様書無しさん mailto:sage [2007/05/20(日) 22:07:41 ] >>399 コーディング規約にハンガリアンを入れるのを否定してるんじゃないの？ ＞あほか？これのどこがハンガリアンに関連すんだ？テストフレームワークとかコンパイラの仕事だろが 型変える→宣言箇所の変数名を変える →変数を使ってるところをチェックしたら、使用箇所の変数名を変える という風にルール化すると、未チェック部分があったらコンパイルが通らない 402 名前：仕様書無しさん mailto:sage [2007/05/20(日) 22:22:48 ] すべてを置換 403 名前：仕様書無しさん mailto:sage [2007/05/20(日) 22:25:42 ] 面倒だから、みんなboost::anyにしようぜ。それでハンガリアンも問題無し。 404 名前：仕様書無しさん mailto:sage [2007/05/20(日) 22:29:26 ] わかった。 荒れる元ってだけでも ハンガリアンは使わない方が吉、と。 論争する時間がもったいないわい。

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef