07/05/19 22:21:05
int CR, CCでいいじゃん
351:仕様書無しさん
07/05/19 22:24:06
>>349
あー、説明不足で申し訳ナス。
メインC言語なんだが、「決まったプリフィクス」をつけることになってんだ。
癖でつけてしもた。
例えばこんなのが変数の先頭に付く
int → n
char → c
void * → p
int * → pn
構造体 → st
列挙型 → e
グローバル変数 g_
352:仕様書無しさん
07/05/19 22:28:17
ハンガリアンはいまどき、はやらないな。
353:仕様書無しさん
07/05/19 22:30:05
>>351
つか、M$すら使わなくなったDQN記法をなぜ採用する？
おまえの会社頭おかしくね？
354:仕様書無しさん
07/05/19 22:35:42
>>353
さぁ？そうなってる背景は知らんし、今んトコ困って無い。
良かったらどこがDQNなのか教えて貰えんか？
355:仕様書無しさん
07/05/19 22:45:41
一文字変数禁止なんてルールきめたやつって、コードを読み書きした経験がろくにないんだろうな。
356:仕様書無しさん
07/05/19 22:50:14
URLﾘﾝｸ(local.joelonsoftware.com)
ハンガリアン記法の暗黒面が支配権を得たのだ。
それがなぜなのか、どういう経緯でそうなったのか誰も知らないのだが、
どうやらWindowsチームのドキュメントライターたちが、不用意にシステム
ハンガリアンとして知られるようになるものを作り出したということらしい。
システムハンガリアンはlongを意味する"l"、unsigned longを意味する"ul"、
double word(これは、実際は、その、unsigned longと同じものだ)を意味する
"dw"のような、あまり役に立たないプレフィックスを使う。
システムハンガリアンでは、プレフィックスが教えてくれるのは変数のデータ型だけだ。
プログラマたちは、自分たちの使っているハンガリアン記法の誤解されたサブセット
がはなはだ煩わしくほとんど役立たずであることに気づき、反旗を翻したのだ。
Microsoftはついには人々に言い始めたのだ。「ハンガリアン記法は推奨しない」。
357:仕様書無しさん
07/05/19 22:55:28
うちの会社にもいまだにハンガリアンしてるやつがいて
ﾜﾛﾀ
358:仕様書無しさん
07/05/19 22:59:08
現在進行中の糞プロジェクトなんか、コーディング規約がめちゃハンガリアン
でかけりゃでかいほどハンガリアン率が高いと思う
359:仕様書無しさん
07/05/19 23:05:14
俺できるよねって感じで売り込んでるじじぃPGなんかは
ハンガリアン率が高い。
360:仕様書無しさん
07/05/19 23:07:36
JavaとかUnix系とかはハンガリアン使わないんじゃないの?
361:仕様書無しさん
07/05/19 23:08:03
int cntRaw,cntCol;
俺はこうかな。
362:仕様書無しさん
07/05/19 23:08:49
つかRawって何だ。Rowだよな。
363:仕様書無しさん
07/05/19 23:40:25
>>356を読んでみたが、デメリットが良く分からんかった。
個人的には変数名でデータの型がわかるだけで大分便利なんだが。
慣れてしまったら煩わしくも無いし。
慣れるまでに掛かるコストがメリットと釣りあわない(or無い)ので
ハンガリアンなコーディング規約はクソだ、ということか？
364:仕様書無しさん
07/05/19 23:47:00
>>362
冷凍と生のカウンタなんだろ
365:仕様書無しさん
07/05/19 23:51:15
>>363
型情報は名前にのせるほど重要じゃないってことだろ。
366:仕様書無しさん
07/05/20 00:07:38
>>362
フツーに間違えた・・・。
よく間違える。
>>365
JAVAとかRubyとかはさておき、C言語じゃ大事だと思ってたんだが、
世間的にはそういう認識なんか・・・。
勉強になりました。
367:仕様書無しさん
07/05/20 00:12:50
MSも捨てた記法だし
368:仕様書無しさん
07/05/20 00:18:39
MSはC言語自体捨ててる
369:仕様書無しさん
07/05/20 00:29:43
>>360
それが未だに使われてるから困る
死ねばいいと思う
370:仕様書無しさん
07/05/20 00:33:01
>>366
型情報を変数名に入れると、
型が変わる度に名前が変わる事になる。
そんなのおかしい、不自然だと思わないか？
例えば、「身長」がmm単位からcm単位に仕様変更され、
型が整数型から浮動小数点数になっても、身長は身長だろ？
371:仕様書無しさん
07/05/20 00:33:53
>>362
cunt rawの略。つまり生まんこってことだ。
>>363
変数の型を変えたい時に面倒なんだよ。
あと、型情報が重要じゃないわけではない。
変数の宣言箇所を見るのが面倒くさくなるほど
ソースをでかくする設計をまず見直せって事でしょ。
プリフィクスなんていらん。
372:仕様書無しさん
07/05/20 01:03:05
読み返してみたけど。
プレフィックスをつけるべきだ
という発言は誰もしていないね
373:仕様書無しさん
07/05/20 01:10:10
>>363
変数名って適当な長さがあるでしょ。
その中に重要な情報を載せていくと型名を載せる余地が無くなるわけだ。
型名は探せばわかるが、変数名に載せないとわからない情報がある。
あとは、機械的にチェックするツールが無きゃ信用できないから意味が無いと思う。
374:仕様書無しさん
07/05/20 01:11:44
>>372
皆>>354の質問に答えてるだけ
375:仕様書無しさん
07/05/20 02:09:24
if(i==0){
foo();
}else{
//空文
}
376:仕様書無しさん
07/05/20 02:18:26
規約でelse省略不可だったんじゃないの
377:仕様書無しさん
07/05/20 02:34:42
もともと処理あったけどいらなくなって消して、elseだけが残ったとか？
378:仕様書無しさん
07/05/20 02:42:21
>>269の逆バージョンという可能性も
379:仕様書無しさん
07/05/20 02:59:30
if(i!=0){
//空文
}else{
huu();
}
380:仕様書無しさん
07/05/20 07:10:11
Javaでハンガリアンやりたがる奴は頃してもいいよね。
381:仕様書無しさん
07/05/20 07:23:06
>>370
型が変わると変数名も変えないといけないってのはハンガリアン否定論としてよく聞くけど、
実際問題、型を変える頻度ってどれくらいあるもの？
変えるのだって、「拡張する必要があって止むを得ず」ならともかく、「使い方を間違ってたから
変更」みたいなのなら、それは設計をちゃんとやってないただのバカだと思う。
変数名の他の部分で、以前の型に依存した処理をやってて、バグを招く可能性がある。
それに、「変数名の型を変える」だけなら、今はエディタやIDEがマシになってるんだから、
一括置換ですむのでは？
>>356のリンク先で議論されている「チェックのしやすさ」の点で、システムハンガリアンも
有効活用できると思うんだけどな。こだわりすぎるとよくないけど。
382:仕様書無しさん
07/05/20 10:15:33
変数名を変えられるエディタなら、
変数の型もでてくるんでねーの。
＃ま、クラス・構造体に対して、システムハンガリアンは
＃大抵のところ無力だから、どーでもいいけど
383:仕様書無しさん
07/05/20 12:51:14
>>380
Yes
384:仕様書無しさん
07/05/20 12:54:09
ハンガリアン使ってるのはうざいなぁ…
醜くて仕方がない
385:370
07/05/20 13:01:44
>>381
頻度とかは無関係。
別に同じシステム内に限った話じゃなく、
全く別のシステムでも、同じ物を表す変数の名前を付ける場合でもいい。
同じ物を示すなら、当然同じ名前を付けるだろ？
名前に表現方法を入れるのは不自然だと言ってるんだよ。
身長の例でいくと、
単位がmmでもcmでもｲﾝﾁでも尺でも、身長は身長だ。
混在して使う必要がないなら、名前に表現方法など不要だろ？
386:仕様書無しさん
07/05/20 13:33:41
>>385
単位がmm、cm → 基本型
身長 → クラス
わざと混同してるのか？
387:仕様書無しさん
07/05/20 14:16:48
＞ハンガリアン
どーでも良いが、そろそろ大分スレ違いじゃまいか？
388:仕様書無しさん
07/05/20 15:06:41
相変わらずヴァカだなM$
389:仕様書無しさん
07/05/20 15:47:53
だから素人に文献書かせるとろくなことにならない
390:仕様書無しさん
07/05/20 15:51:12
自分が今書いてるところの変数の型も覚えてられないような奴とか、
覚えてられなくなるような無駄に長い処理書くような奴は
プログラム書く資格ねぇよ。
こう言うと「他人が書いたのを解析するときにいいじゃないか」とか出てくるが、
「そのハンガリアンで書かれてる型が実際の型と一致してること」はまったく保証されないんだが？
>>381
頻度は確かに低い。低いが、無いわけじゃないだろ？
それに、型に依存した処理をやってて型変更時バグるってのは、「変更時にチェックしたか」が問題であって、
変数名をハンガリアンで書いてようが書いてまいが同じこと。
391:仕様書無しさん
07/05/20 16:51:49
ハンガリアンは
その変数が出てくるたびに
いちいち/*コメント*/つけるようなもんだ。
392:仕様書無しさん
07/05/20 16:58:58
宣言部分を検索すれば済む話だよね
393:仕様書無しさん
07/05/20 17:12:54
検索するようでは駄目だ。
もう関数（メソッド）の長さの話になってしまうが。
394:仕様書無しさん
07/05/20 18:23:13
っつーかIDE使ってれば変数の型なんぞすぐに知ることができるだろうに
いったいいつの時代の開発環境なんでつか？
395:仕様書無しさん
07/05/20 18:32:51
viつこーてます
396:仕様書無しさん
07/05/20 18:53:55
VisutalStudio を使いまわしてると
わかるとおもうが、勝手に変数名に
dwとか付いたり開発者が言いくる
められたのかどうかしらないが、
仕様的にヴァカすぎる
その仕様を疑いなくそのまま放置する
M$の幹部どもも率直にヴァカまっしぐら
というかハンガリアン広めておいて
元の文献の趣旨理解していないとは
どういうカラクリになったらそうなる
んじゃい！
397:仕様書無しさん
07/05/20 21:08:12
>>390
型変更した時に変数名を変えれば、それによる挙動のチェックを
モレが出ないようにフレームワーク化出来る。
あと
＞「そのハンガリアンで書かれてる型が実際の型と
＞ 一致してること」はまったく保証されないんだが？
コーディング規約守れボケ。
約束事が守られてない前提で仕事出来ん。
規約に無いのにハンガリアンに頼る奴のことは知らん。
398:仕様書無しさん
07/05/20 21:36:53
IDE全盛の今となってはハンガリアンが嫌われるのもよくわかるけど、
他人のコードがハンガリアンだからと言って貶す資格はないよね。
まあ、結局はコーディング規約守れって話だよね。
399:仕様書無しさん
07/05/20 21:57:44
いや、だからハンガリアンがコーディング規約に無い以上、使ってもらっては困るんだがw
>型変更した時に変数名を変えれば、それによる挙動のチェックを
>モレが出ないようにフレームワーク化出来る。
あほか？これのどこがハンガリアンに関連すんだ？テストフレームワークとかコンパイラの仕事だろが
よけいな仕事をやっておいて自己満足してんじゃねえぞ
400:仕様書無しさん
07/05/20 22:02:40
このスレは基地外が多いですね
401:仕様書無しさん
07/05/20 22:07:41
>>399
コーディング規約にハンガリアンを入れるのを否定してるんじゃないの？
＞あほか？これのどこがハンガリアンに関連すんだ？テストフレームワークとかコンパイラの仕事だろが
型変える→宣言箇所の変数名を変える
→変数を使ってるところをチェックしたら、使用箇所の変数名を変える
という風にルール化すると、未チェック部分があったらコンパイルが通らない
402:仕様書無しさん
07/05/20 22:22:48
すべてを置換
403:仕様書無しさん
07/05/20 22:25:42
面倒だから、みんなboost::anyにしようぜ。それでハンガリアンも問題無し。
404:仕様書無しさん
07/05/20 22:29:26
わかった。
荒れる元ってだけでも
ハンガリアンは使わない方が吉、と。
論争する時間がもったいないわい。
405:仕様書無しさん
07/05/20 22:34:29
ええー、組み込みならシステムシステムハンガリアンは結構有効だよぉ
406:仕様書無しさん
07/05/20 22:37:43
Win16でFARポインタとNEARポインタを区別したいときには良かったけど
組み込みだとなにがいいのさ。
407:仕様書無しさん
07/05/20 22:44:41
Microsoftはついには人々に言い始めたのだ。「ハンガリアン記法は推奨しない」。
408:仕様書無しさん
07/05/20 22:53:52
ポインタのアラインとか、データ範囲（-0x80~0x7F）とか。
リソース少ないとなんでもかんでもlongにはできん。
409:仕様書無しさん
07/05/20 23:34:36
:
:
int i = 0;
array[i] = i++;
今までよく動いてたと思う。危なっかしいったら。
410:仕様書無しさん
07/05/20 23:45:08
なんかようわからんけど、変数名の頭にintとかfloatとか付けるのは
それが的確な名前ならそれでもいいという考え。
ハンガリアンが愚かなのはint型だからintってprefixを付ければ良い
とかいう思考停止故だと思ってる。
411:仕様書無しさん
07/05/20 23:56:50
ポインタの p とかはあった方がいいなーと思うことが多いな
それより vector が困る。
std::vector<HOGE> hogeVec;
HOGE hoge;
hogeVec.push_back(hoge);
Vec とかつけるのあまり好きでないんだが、他にいい案が浮かばない
412:仕様書無しさん
07/05/21 00:05:03
それあとでやっぱりdequeにしよう、とかいったときどーするの？
413:仕様書無しさん
07/05/21 00:07:05
>>411
うん、だから困ってるんだよ
変えるべきは下の HOGE hoge; なのかもしれないけど、いい案が浮かばないの
414:仕様書無しさん
07/05/21 00:15:38
名前の変更なんか、IDEのリファクタリングで一発じゃん。
hogeVecはいかがなものかとは思うが。
415:仕様書無しさん
07/05/21 00:29:39
ハンガリー人はテンプレートパラメータにどんな
プリフィックスをつけるの？
416:仕様書無しさん
07/05/21 00:54:41
>411
月並みだがVecを何の目的で使うかジャマイカ
ListでもBagでもCollectionでもお好きなのをだうぞ
417:仕様書無しさん
07/05/21 01:34:11
ﾊﾝｶﾞﾘｱﾝ、ﾊﾝｶﾞﾘｱﾝとか言うﾔｼに限って、
ｸﾗｽのﾌﾟﾘﾌｨｯｸｽがclsだったり、構造体のﾌﾟﾘﾌｨｯｸｽがstrとかだったりする。
ﾊﾝｶﾞﾘｱﾝの意味、利点を履き違えてるとしか思えない。
そこが、ﾊﾝｶﾞﾘｱﾝが愚かである所以だと思われ。
418:仕様書無しさん
07/05/21 01:36:11
>>414
それいったら型が何かなんて
IDEなら一発ジャン。
いいっこなしよ。
419:仕様書無しさん
07/05/21 01:59:42
>>417
strはstringとかぶるぞ。
420:仕様書無しさん
07/05/21 02:10:00
自分はその
「IDEが無ければ開発作業自体が出来ないPGを多量生産するような考え方」
は承服しない。
421:仕様書無しさん
07/05/21 02:12:34
>>420
テキストエディターが神
の派閥なわけ？？？？
422:仕様書無しさん
07/05/21 02:21:36
>>421
そんなものに派閥なんかあるか！ｗ
エディタが使われていないころから仕事をしているPGさ。
423:仕様書無しさん
07/05/21 02:28:19
>>422
「emacsは最高のIDE」という派閥がある
424:仕様書無しさん
07/05/21 02:31:00
>>422
あ・・・あれか？？
ベタでCやベーシック書いてた時代なのか？？
MSX世代の予感・・・・
425:仕様書無しさん
07/05/21 02:40:13
テキストエディタが神とは言わんが、
現局に行ってviしか無い環境でソース弄くるというのはある・・・
#もちろんデスマ中
426:仕様書無しさん
07/05/21 02:41:12
>>425
おまｗｗｗ
こんなところ書き込んでる場合じゃねええええ
427:仕様書無しさん
07/05/21 08:22:04
>>424
BASICにはエディタが組み込まれてたがな（俗にカーソルエディタと呼ばれてた）
エディタなしっつーとパンチカードの時代になるな
428:仕様書無しさん
07/05/21 08:33:23
コーディング用紙に書いてパンチャーに渡す
そんな時代もあ～ったねと～♪
429:仕様書無しさん
07/05/21 09:50:33
辞めようってほどじゃないんだけど、もうとっくに辞めてった奴が残した遺産。
BOOL InitInstance( HANDLE hInstance, int nCmdShow )
{
HANDLE hWnd;
hWnd = CreateWindow( 中略 );
if ( hWnd == NULL ) return ( FALSE );
ShowWindow( hWnd, nCmdShow );
UpdateWindow( hWnd );
return ( TRUE );
}
なんだその無駄な改行は。
430:仕様書無しさん
07/05/21 10:31:15
昔から一行おき／二行おきに書く人はいたけどねｗ
431:仕様書無しさん
07/05/21 10:46:14
コメント行を機械的に取り除いた跡かもしれない。
…UpdateWindowに何行コメント書いてたんだｙｐ！
432:仕様書無しさん
07/05/21 10:58:15
ハンガリアン云々と高尚な話題で議論出来る人たちが裏山しい。
俺なんか、今戦ってるソースが
Select Case Ret
Case 1
Call FuncA( 1 )
Case 2
Call FuncA( 2 )
Case 3
Call FuncA( 3 )
Case 4
Call FuncA( 4 )
Else
End Select
こんなんばっかりだぜ('A`)
433:仕様書無しさん
07/05/21 10:58:58
あ、>432の一番下のElseは無しね。
434:仕様書無しさん
07/05/21 12:38:48
>>432
とても見やすいコードダネ
435:仕様書無しさん
07/05/21 13:56:54
>>427
>パンチカードの時代になるな
紙テープもお忘れなく。
ソースの修正ツールはハサミとノリだ。
436:仕様書無しさん
07/05/21 14:06:17
>>435
磁気テープもお忘れなく。
修正ツールはユーティリティ起動とそれに対するバッチスクリプトを含むJCLだ。
437:仕様書無しさん
07/05/21 14:26:36
宇宙戦艦ヤマトの記憶媒体は磁気テープだぞ！
438:仕様書無しさん
07/05/21 14:39:23
jspとjavascriptでコードが汚いのは最悪だ、、、
439:仕様書無しさん
07/05/21 16:58:08
紙テープを目視で読んで東京湾に出現した怪獣を特定する。
440:仕様書無しさん
07/05/21 20:06:28
JSPとかJavaScriptが汚いのはもうしょうがないよ。
あれはそういう人力で何とかしましょう、っていうアーキテクチャだと思う。
さっさと諦めて他人に押し付けた方がいい。