変数名って、どの位こだわりますか？

1 ：仕様書無しさん：02/11/26 19:30

私の場合、"名は体を表す"とか言われ指導されたもので、
時々３０分位考えてしまうのですが。

2 ：仕様書無しさん：02/11/26 19:30

にげ

3 ：仕様書無しさん：02/11/26 19:31

っと

4 ：仕様書無しさん：02/11/26 19:32

適当に書いて良い物を思いついた時点でリファクタリングツールで変更する。

5 ：仕様書無しさん：02/11/26 19:32

6 ：仕様書無しさん：02/11/26 19:43

長くても3分で取り合えず決める
その後いいのが浮かんだらツールで置換する

7 ：仕様書無しさん：02/11/26 19:44

死ぬほど

8 ：仕様書無しさん：02/11/26 19:50

>>4
素人ですみません。
リファクタリングツールでどんなツールなんですか？

9 ：仕様書無しさん：02/11/26 19:50

Aから順番に１文字ずつ。

10 ：仕様書無しさん：02/11/26 19:56

英語とローマ字を混ぜる香具師、別にいいけどさぁ。

11 ：仕様書無しさん：02/11/26 20:04

少なくともハンガリアン則には縛られたくない。

12 ：仕様書無しさん：02/11/26 20:10

どう書いたって、内部的には、戻り型+変数名本体+引数型+・・・の名前に変わってるから、どうでもいい。

13 ：仕様書無しさん：02/11/26 20:46

toolと書こうとしてtookとなった奴は折れだけではないはずだ

14 ：仕様書無しさん：02/11/26 21:17

↑
おまえだけだ

15 ：仕様書無しさん：02/11/26 21:20

12>>
きみはプロかい？

16 ：12：02/11/26 21:30

>>15
単なる嘘ツキだ。
だってよ、何で変数に戻り型とか、引数がいるってよ。
それを言うなら関数メソッドだろ。って誰も突っ込んでくれない悲しい。

17 ：仕様書無しさん：02/11/26 21:35

自分さえ意味がわかればいい

18 ：仕様書無しさん：02/11/26 21:36

x,yですが何か？

19 ：仕様書無しさん：02/11/26 21:42

>>17,>>18
きみたちもプロですか？

20 ：仕様書無しさん：02/11/26 21:43

>>19
Haskellのプログラミングスタイルにならいました。

21 ：仕様書無しさん：02/11/26 21:44

このネタで1000レスかぁ・・・。
辛いなぁ～。

でも、がんばるよ俺！　>>1さんが好きだし。
チュッ（葉～戸

がんばれ >>19

22 ：仕様書無しさん：02/11/26 21:54

”支払い不能理由（再開不可能）”ですが何か？

23 ：仕様書無しさん：02/11/26 22:03

プログラミングとは名前付け作業である。

24 ：仕様書無しさん：02/11/26 22:05

「メモリにメモリ」を変数に使ったら
文句も嫌味も無しにお休みを３日くれました。
その後上司がとても優しくなりました。ちょっと嬉しい。

でも会社辞めさせてくれたらもっと嬉しかったよ。

25 ：仕様書無しさん：02/11/26 22:10

>>20
それで？

26 ：仕様書無しさん：02/11/26 22:14

>>24
Cat`sかな…

27 ：仕様書無しさん：02/11/26 22:16

int i1,i2;
とか
char c1[256],c2[256]
とか
long l1,l2;
ですが何か？

28 ：仕様書無しさん：02/11/26 22:17

まぁ、１個辺り３日３晩悩むのが普通なわけだが。

29 ：久留米人：02/11/26 22:18

intなら、i, j, k, l, m, nですが何か？

30 ：仕様書無しさん：02/11/26 22:20

異様に長い名前付けるJava房と、３秒ぐらいで思いついた
適当な名前付けるC使い。どっちが迷惑ですか？

31 ：仕様書無しさん：02/11/26 22:21

>>27
論外！
2ch.cpp(3) : error C2143: 構文ｴﾗｰ : ';' が 'とか' の前に必要です。

32 ：仕様書無しさん：02/11/26 22:24

というか変数名から意味を読み取ろうとする香具師はダメだろ。
分りやすいに越したことないけど、読む側のやり方としては
それじゃだめ。型名に短くて簡潔な名前を付けるのは大事だけど。

33 ：仕様書無しさん：02/11/26 22:29

>>30
どっちも迷惑。ついでにいうならわざわざJava使いとC厨に限定する理由は無い。

34 ：仕様書無しさん：02/11/26 22:36

>32
だから結論としてはなんなのよ？

35 ：仕様書無しさん：02/11/26 22:38

nXCounterならまだ許せるが、nCounterOfXAxisは許しがたい。

36 ：仕様書無しさん：02/11/26 22:40

>>32
変数から意味を読み取るのはダメ。意味が正確に書かれたヘルプなりコメントを見て意味を読み取り、
その意味を瞬時に思い出せるように何かの省略ではなくある程度の長さを持った
分かりやすい変数名にする。

37 ：仕様書無しさん：02/11/26 22:41

>>35
nXCounterって何のこと？

38 ：香具師：02/11/26 22:44

>>32
>というか変数名から意味を読み取ろうとする香具師はダメだろ。
そうそう、途中で変数の意味合いが変わってて痛い目にあった。

39 ：仕様書無しさん：02/11/26 22:46

変数名じゃなくてJavaのクラス名でインターフェースを実装しているクラスの
名前をどうつけてる？
「****Impl」ってつけているサンプルが多いけど、複数のインターフェースを
実装する場合もあるし、どうしたものかと。

40 ：香具師：02/11/26 22:48

>>37
最高～っす！

41 ：仕様書無しさん：02/11/26 22:48

>>38
それは命名者自体に問題があるだけで、意味を読みとれる変数名を付ける「努力を
する」のは大事では？

42 ：仕様書無しさん：02/11/26 22:49

>38
それはコード化いたヤツがダメなだけだと思うぞ。

>>36
コメントやドキュメントの類も、変数名と同程度には「信用できない」ものだと
思うけど。特にドキュメントの更新が遅れてたりすると最悪だし、そもそも
ドキュメントなんか書かないケースも多いだろう。

43 ：仕様書無しさん：02/11/26 22:49

結局おまえら変数名に。。http://pc.2ch.net/test/read.cgi/prog/1037244487/l50

44 ：仕様書無しさん：02/11/26 22:51

>>42
信用できないから適当な名前を付けるというのは間違っている。

45 ：仕様書無しさん：02/11/26 22:52

そうそう。mona とか giko とか最悪。

46 ：仕様書無しさん：02/11/26 22:52

>>39
いろいろ作ってきたけど、Javaでわざわざインターフェイス型と分かる
ような命名する必要はないと思う。
最初クラスで作ってきたものを、土壇場でインターフェイスにして拡張
性を与える事が多いんで、「I」とか「Inter」とか入れるのは愚行だ。

47 ：仕様書無しさん：02/11/26 22:56

>>37
窒素酸化物計測数

48 ：42：02/11/26 22:58

>44
俺は名前ちゃんとつける派だが。変数名だろうがコメントだろうが、利用できる
道具は利用しとけと思ってる。

ただし、限界を見極めつつ。

49 ：39：02/11/26 22:58

>>46
いや、インターフェースの方じゃなくて、それをimplementsしたクラスの方の話。

50 ：仕様書無しさん：02/11/26 23:02

>>47
double dblNOxPPM;
でどうだ！

51 ：46：02/11/26 23:06

>>49
ゴメン、そうだった。
でも、「StringExtendsObject」とは書かないでしょ。
ある種の型がその他のどういう型を併せ持つかは、クラスの継承で
あろうとインターフェイスの実装であろうと書いてたらキリがない
でしょ。

そこら辺は使用する側がドキュメントなり、ソースなりから判断し
なくちゃならない領分で、型名称に含むと面倒かと。

52 ：仕様書無しさん：02/11/26 23:08

>>50
残念ながら、濃度で無く総量規制でつ。

53 ：仕様書無しさん：02/11/26 23:13

もちつけ
　　　　　／＼⌒ヽﾍﾟﾀﾝ
　　　／　／⌒)ﾉﾍﾟﾀﾝ
　 ∧＿∧ ＼（(　∧＿∧
　（； ´Д｀））'　））（・∀・；）
　/　　⌒ノ　（ ⌒ヽ⊂⌒ヽ
.（O　　ﾉ　)￣￣￣(）__ 　）
　）_）＿）（;;;;;;;;;;;;;;;;;;;）（＿（

54 ：仕様書無しさん：02/11/26 23:14

>>35
最初のnってなに？ﾀﾞｻｲ

55 ：仕様書無しさん：02/11/26 23:15

結論としては
int i1,i2;
とか
char c1[256],c2[256]
とか
long l1,l2;
でいいですか？

56 ：仕様書無しさん：02/11/26 23:18

>>55
だめ。アルファベット3文字＋数字3桁でやるべき。
で別のドキュメントにそれぞれの役割を書いておく。

（例）
aaa001
aaa002
aaa003
.
.
.
zzz999

aaa001 -> xxx関数でのループカウンタ用

57 ：仕様書無しさん：02/11/26 23:20

>>56
ついでに、変数名にカーソル持ってくとドキュメントファイルを開いて
その変数名の解説をチップヘルプとして表示するエディタがあれば完璧だな。

58 ：仕様書無しさん：02/11/26 23:22

Dim Timpo as Long

59 ：仕様書無しさん：02/11/26 23:22

下ｘ桁のみが自由に使える領域

・・・あきた

60 ：仕様書無しさん：02/11/26 23:22

Dim Timpo as Strong

61 ：仕様書無しさん：02/11/26 23:23

Dim Tympo as short

62 ：仕様書無しさん：02/11/26 23:26

>>56
何系の(どんな)ソフト？
メリットが知りたい。

63 ：仕様書無しさん：02/11/26 23:27

>>56
単純な数値じゃなくてメモリマップのアドレスにしといた方が分かりやすいよ。
A800 B000 B800 E000みたいに。

64 ：仕様書無しさん：02/11/26 23:27

Dim Kintama as double

65 ：39：02/11/26 23:28

>>51
なるほど。
可読性の高さ＆インターフェースの場合最初からインターフェースとして設計するんで
「I****」としてたけど、クラス名にImplをつけないという点では同意。
しかしもう１年以上プログラミングしてないなあ・・・

66 ：仕様書無しさん：02/11/26 23:29

Dim Bokki As Extend

67 ：仕様書無しさん：02/11/26 23:29

>>64
二つあるんすか！？
・・・ってフツーじゃん

68 ：仕様書無しさん：02/11/27 01:33

VBやってる奴らはなんで変数宣言が"Dim"なのか疑問に思わんのだろう…

69 ：仕様書無しさん：02/11/27 01:36

>>68
その点はBASIC原理主義者によって既に解明済みです

70 ：仕様書無しさん：02/11/27 08:21

ax, bx, cx, dxですが何か？

71 ：仕様書無しさん：02/11/27 08:28

　　　　　　　　　 _人
　　　　　　　ノ⌒　丿
　　　　＿／　　 ::（
　　　/　　　　　:::::::＼
　　（　　　　　:::::::;;;;;;;）
　　　＼＿――￣￣::::::::::＼
　　ﾉ￣　　　　　::::::::::::::::::::::）
　　（　　　　　::::::::::::::;;;;;;;;;;;;ノ
　／￣―――――￣￣::::::::＼
（　　　　　　　　:::::::::::::::::::::::::::::::::）
　＼＿＿::::::::::::::::::;;;;;;;;;;;;;;;;;;;;;;;;ノ

72 ：仕様書無しさん：02/11/27 08:50

unsigned long eax, ebx, ecx, edx;

73 ：仕様書無しさん：02/11/27 09:06

>>68
printfやstdioが何の略か知らない人でも使えるように特に外国語それもなにかを
省略した形だと、その単語はそういう機能を持つと理解するのは良くあることです。

Dim a As Integerと書いてあるのを初めて見てDimを変数定義の意味
だと気づく人はいてもDimensionの略と気づく人は少ないでしょう。

74 ：仕様書無しさん：02/11/27 09:22

>>73
それって、探求心とか理解しようとする気持ちの問題。
求めたいよなあ。プログラマには。

75 ：仕様書無しさん：02/11/27 09:24

>>74
英単語が何の省略か調べようとするのと探究心や理解しようとうする気持ちは関係ないよ。

76 ：仕様書無しさん：02/11/27 09:53

>>75
74は、プログラマの心構えとして、象徴的な意味で記述しました。

オリジナルの関数やクラスなどと類似したものを作成する場合、
使用する単語や省略のパターンが似ている方がbetterではないでしょうか。

77 ：仕様書無しさん：02/11/27 10:07

one dimensionってことでいいだろ。

78 ：仕様書無しさん：02/11/27 10:13

ヴァカ新人の作ったＶＢ画面をメンテしたら
漢字の変数名とか使ってんの。小1時間アホかと馬鹿かと
オマエはヴァカ新人のクセして俺にＩＭＥのON/OFFを繰り替えさせるのかと。

79 ：仕様書無しさん：02/11/27 10:15

>>78
そりゃ新人だもの。ちゃんと教育せいや。

80 ：仕様書無しさん：02/11/27 10:38

VBって漢字変数使えたのか・・・

81 ：仕様書無しさん：02/11/27 10:47

>>73は探究心の意味も知らない文盲

82 ：仕様書無しさん：02/11/27 10:48

>>75　=　>>81

必死だな（藁

83 ：仕様書無しさん：02/11/27 11:08

ループのカウンタってなぜiが多いの？

84 ：仕様書無しさん：02/11/27 11:10

>>81　=　>>71

必死だな（藁

85 ：仕様書無しさん：02/11/27 11:14

>>81
ごめんね。
別にいじめようと思った訳じゃないの。
プログラム嫌いにならないでね。

86 ：仕様書無しさん：02/11/27 11:16

>>83
たぶん、integerの略では。

87 ：仕様書無しさん：02/11/27 11:21

int work;
string wk1, wk2, wk3;
object objtest1, obj2;

88 ：仕様書無しさん：02/11/27 11:26

>>86
んにゃ、indexの略だと聞いたことがある。

89 ：仕様書無しさん：02/11/27 11:30

>>87
厳重注意でしょう。

90 ：仕様書無しさん：02/11/27 11:32

>>87
嫌われるタイプだな。

91 ：仕様書無しさん：02/11/27 11:49

>>83
フォートランの名残りだ。

あの言語は、変数の名前の先頭で、暗黙の型が宣言される。
で、iはintegerのiの宣言の要らない最も簡単な変数名。

92 ：仕様書無しさん：02/11/27 11:50

fortranからの慣習で整数変数には i ～ nあたりを使うことが多くて、
i は筆頭だからよく使われると思っていたんだが。どうでもいいような
カウンタには i ～ n をよく使う。

93 ：仕様書無しさん：02/11/27 12:00

変数iはI am のiだと言った奴がいた。
で、ループで使うと、自分がグルグル回って、目が回るんだと。

94 ：仕様書無しさん：02/11/27 12:18

int UwaRite;
FILE FaileP;

95 ：仕様書無しさん：02/11/27 13:34

Pのあとにプロジェクトを通して一意の11桁の数字。

96 ：仕様書無しさん：02/11/27 13:46

>>95
君は天才だな。

97 ：仕様書無しさん：02/11/27 13:54

ループカウンタ
i,j

関数内の一時定数(ループカウンタ以外)
ret, dat, size, len

グローバル変数
意味が分かるようにする。和英辞書サイトで綴りを調べることも。

言語：C

98 ：仕様書無しさん：02/11/27 13:55

俺はUUID使ってる。

99 ：仕様書無しさん：02/11/27 14:01

CString strTmp;
CString strTmp2;

100 ：仕様書無しさん：02/11/27 14:08

昔、無理に英語で名前つけようと辞書ひいて、
後で、そのソース読むときに辞書ひいたこともあったなあ。

101 ：仕様書無しさん：02/11/27 14:13

>>99
変数名に型名を付けるのって、ホント無意味になったよな。

102 ：仕様書無しさん：02/11/27 14:13

来月産まれる子供の名前を考えてくれ
ゴットファーザァ達よ
よろぴく

103 ：仕様書無しさん：02/11/27 14:14

>>102
ぬるぽ

104 ：仕様書無しさん：02/11/27 14:21

>>102
胡簿流、帆都蘭、思惟、麝羽、把賺留、米志久、思惟麩羅麩羅、

105 ：仕様書無しさん：02/11/27 14:22

>>101
スコープでつけるのが今の流行りか？
グローバルはg～とかみたいに

106 ：仕様書無しさん：02/11/27 14:48

>>102
バグ男
憂意流棲

107 ：仕様書無しさん：02/11/27 14:52

>>102　まず、その子供の仕様を下さい。

108 ：仕様書無しさん：02/11/27 15:05

>>102
らっきょ

109 ：仕様書無しさん：02/11/27 15:18

>>105
子供の名前にスコープが適用されるのかと一瞬思ったよ。

110 ：仕様書無しさん：02/11/27 17:21

ところで、ｵｲﾗは同じ型の変数でも１行にまとめず複数行で宣言し後ろにコメント
入れるんだが、これはどうよ？

int i, j;

int i; // hoge
int j; // hogehoge

111 ：仕様書無しさん：02/11/27 17:25

>>110
エラー出たぽ

112 ：仕様書無しさん：02/11/27 17:26

>>111
では、↓これで。

int i, j;
extern int i; // hoge
extern int j; // hogehoge

113 ：仕様書無しさん：02/11/27 18:15

>>110
俺も基本的にそーする。
仕事の場合は特にする。

114 ：仕様書無しさん：02/11/27 19:12

マ板は自分の未熟さゆえ馴染めずあんまり来ないんだけど
こういうスレ見てると笑いのセンスが近い人間が多くてほっとする

115 ：仕様書無しさん：02/11/27 20:47

>110
メンバ変数だと、俺は上に書くな。

// ふにふに
int funifuni;

右だと幅が足りなくなることが。

116 ：仕様書無しさん：02/11/27 21:46

>>80
Javaでも余裕で使えますが何か？

117 ：仕様書無しさん：02/11/27 22:34

>>116
で、日本語の変数名を使うのですか？

118 ：仕様書無しさん：02/11/27 23:01

使わんな

119 ：116：02/11/27 23:12

>>117
もちろん使わんけどな。

120 ：仕様書無しさん：02/11/27 23:28

テーブル(DB)のフィールド名なんかの場合は、日本語アリですか？
大きなシステムでも、アリなのかなあ？

121 ：仕様書無しさん：02/11/27 23:43

>>101
なんで？
変数名見た瞬間に型がわかっていいじゃない。

122 ：仕様書無しさん：02/11/28 00:08

>>120
DBでも半角英数しか使わないな。それも型情報を含めた命名をしてる。

123 ：仕様書無しさん：02/11/28 00:29

日本語名マンセーを提唱してみよう。ただし、分野は業務系のみ。
理由は英名を考えるコストを削減するため。

数学や物理に関係あるものならば、必ず対応する英語はある。コンピュータ関係も
同じ。ブラウザを作る場合でも、メーラーを作る場合でも、全部英語の変数名でまかなえる。

がしかしだ。業務系は似たような言葉が多い。商品区分やら登録種別やら注文区分やら
契約識別やら処理種別やら業務区分やら。

果ては契約社員コード、契約会社コード、契約部署コード、契約支社コード。
まだあるぞ。注文受付番号、お客様側番号、ユーザ側番号、特殊ユーザ側番号、
代表ユーザ側番号。

そしてこんな感じの項目が数百個以上あるわけだ。

まぁ全ての名前に英名を考えることは不可能ではない。でも仕様書は全て
日本語のまま。意思の疎通にも苦労する。

124 ：123：02/11/28 00:32

よって、業務系に限れば変数・テーブル名/項目名の日本語使用は可、だ。

とはいえ俺がやるのは
　order->get("ほげほげ種別")
　order.set("ほげほげ種別", "XX");
てな感じだけどね。

これだとコンパイラが変数名チェックをしてくれないという欠点は
あるけどね (その対策として、項目名は全て getter/setter 内部で
チェックしている)。

125 ：仕様書無しさん：02/11/28 01:20

変数名に型ってクラスが小さくまとまってるといらなかったりする。
最近使わなくなったよ変数名に型。

126 ：八千代市民：02/11/28 01:26

上司：「八千代君、この○○miっていう変数名はどういう意味で命名したの？」
ボク：「初恋の彼女の名前」
上司：「…。逝ってヨシ」

127 ：仕様書無しさん：02/11/28 01:29

>125
DMA 転送みたいなハードウェアよりのコード書いてる場合、ポインタが 32bit int
指してるのか 128bit 境界さしてるのかとかが即座に分かると嬉しい場合もある。

32bit のデータでも浮動小数点、小数4ビット固定小数点、整数と混ぜ混ぜで
同一 DMA パケットに詰めたりするしさ。（すべてはハードウェアの制約ゆえに）

128 ：仕様書無しさん：02/11/28 02:21

それはべつだろ
そもそもクラスうんぬんのとこじゃねーだろ

129 ：俺ルール：02/11/28 07:16

temp型名　一時用
local型名短期スコープ用
意味名型名　同じ型が同一スコープに複数宣言され、違いを明示するとき用
a型名名無しさん用
型名s　名無し配列用

130 ：仕様書無しさん：02/11/28 08:22

ハンガリアン、ﾏﾝｾｰ。

Winで組むにはこれしかないっしょ。

131 ：仕様書無しさん：02/11/28 11:33

>>130
C/C++ において、文字列変数は
　　char *szHoge;
　　　　　　^^
とかって `sz'　つけるよな?
sはまぁわからんくもない。でも文字列は NUL終端って決まってるのに
何故 `z' 付けるの?

132 ：さっきうんこしてきました。：02/11/28 11:40

null-terminated string
Zero-terminated String

133 ：仕様書無しさん：02/11/28 11:41

>>127
むしろデータ幅を強調したい場合は、変数名につけるべきだろうな

134 ：仕様書無しさん：02/11/28 12:15

VBの漢字変数、漢字構造名は一時期重宝していたな～
最近業務でVB使わんから漢字系は使わないが。
よく「打ち間違いの可能性があるから漢字禁止」というﾔｼがいるが、
そいつらは CTRL+SPACEの候補表示を知らんことが多かったりする

135 ：仕様書無しさん：02/11/28 12:49

>>134
ヴァカハケーン

136 ：仕様書無しさん：02/11/28 13:42

>>126
きみの初恋の彼女の名前は「まるまるみ」さんと言うのか。

137 ：仕様書無しさん：02/11/28 14:37

まあ、最低限のマナーは守ってほしいよな。
nCode, nFlag でグローバルは無しにしようや！

138 ：仕様書無しさん：02/11/28 14:52

>>135
VBといえばすぐ煽るアホ

139 ：仕様書無しさん：02/11/28 15:03

結論としては
int i1,i2;
とか
char c1[256],c2[256]
とか
long l1,l2;
でいいですか？

140 ：仕様書無しさん：02/11/28 15:51

どこの会社でも、命名規則ぐらいあるんじゃないの？

141 ：仕様書無しさん：02/11/28 16:19

遊びで、int manko;
とかやってますが、何か？

142 ：131：02/11/28 17:00

>>132
いや、`sz' の `z' が zero-terminated ってのは知ってるんだよ。
だが、C/C++ において文字列っていったら NUL終端ってのは仕様
だろ。
なのに何故わざわざNUL終端って意味で `z' を付けるの？
NUL終端じゃない文字列が C/C++ にあるのか。

文字列はNUL終端ってのが決まってるんだから、String の `s' だけ
でいいじゃん　これだからハンガリアンは糞なんだよ　と思うの。

143 ：仕様書無しさん：02/11/28 17:08

>>142
俺もそう思う。

144 ：仕様書無しさん：02/11/28 17:16

sはshortだったから

と逝ってみる

145 ：仕様書無しさん：02/11/28 17:26

FILE型はハンガリアンではどういう命名するんだろう？
size_t型はハンガリアンではどういう命名するんだろう？
tm型はハンガリアンではどういう命名するんだろう？

Cですら破綻しているのC++で使う奴はアホ。

146 ：仕様書無しさん：02/11/28 17:27

CString とかは s
char *は sz と使い分けてます。

147 ：仕様書無しさん：02/11/28 17:28

Cのランタイムつかわねーし。

148 ：仕様書無しさん：02/11/28 17:30

>>142,>>143
"sz"に納得ができないから、ハンガリアンが嫌いなんですか？
ほかには？

149 ：仕様書無しさん：02/11/28 17:34

ハンガリアンで一番効果的なのは、ポインタを示すプレフィックスだな。
あれはわかり易いから今でも守ってる。型自体はどうでもよくなってるけど。

150 ：仕様書無しさん：02/11/28 17:37

どんな型でもハンガリアンに出来るほど仕様定義されてないだろ？
宣言部を見なくても変数名を見るだけで型が分かるようになるように、
自分なりに仕様定義すりゃいいじゃんか。
仕事でやってるなら、会社のコーディング規約に追加するだけだろ。

151 ：仕様書無しさん：02/11/28 17:41

FILEはfp, size_tはn,tmはtmだな。
何を表現として使うかより一貫性があることが重要なのでわ？

152 ：ハンガリアン＋：02/11/28 18:04

ハンガリアンって、言語標準の型(ポインタを含む)とか、
スコープとかのプレフィックスだけの定義じゃなかったけ？
それ以外は、自由でいいんじゃないの。

153 ：142：02/11/28 18:05

>>148
いや、ハンガリアンが嫌いだから単に難癖つけてるだけだよもん(w

154 ：仕様書無しさん：02/11/28 18:09

>>151
おえっ

155 ：仕様書無しさん：02/11/28 18:11

文字列といっても、C++の文字列クラスは 0 で終わってるとは限らんだろうに。

156 ：仕様書無しさん：02/11/28 18:18

>>155
>131で
　char *szHoge;
って書いてるやん。C++ だってchar型の文字列は、0で終わってると思うが。

157 ：仕様書無しさん：02/11/28 18:19

>>155
そうなのよ、だからって訳じゃないけど、
CString strName;
なのさ！

158 ：仕様書無しさん：02/11/28 18:22

予約語とかとの衝突考えると適当なプリフィックスを付けた方が楽だとおもー

159 ：仕様書無しさん：02/11/28 18:24

モンゴリアンage

160 ：仕様書無しさん：02/11/28 18:42

>>1
男の子なら３０分くらい粘らないといけません。早すぎると軽蔑されますよ。

161 ：仕様書無しさん：02/11/28 19:18

なんでハンガリアンって言うんだ！
教えてくれ！

162 ：仕様書無しさん：02/11/28 19:40

>>161
「俺って天才！」ってやりだした馬鹿でわがままな奴がハンガリー人だ
ったから。

163 ：150：02/11/28 19:53

>>157
いーんじゃない？それで。何か分かるから。
何も付けない香具師は、馬鹿でわがままなハンガリー人以上に、馬鹿で間抜けでわがままだな。

164 ：仕様書無しさん：02/11/28 20:23

>>150
「何か分かる」のは既にハンガリアンを用いて慣れているからだと思われ

165 ：仕様書無しさん：02/11/28 21:07

>162
ヤツはホントに天才だって。少なくとも俺よりは切れる。

166 ：仕様書無しさん：02/11/28 21:11

何も付けないとは度胸あるな。
ｵｲﾗはこの歳になっても生の度胸は無い。

167 ：仕様書無しさん：02/11/28 21:17

／　　　　＼　　　　　
　　 /　　 ∧　∧　＼　　／￣￣￣￣￣￣￣￣
　　|　　　　・　・　　 | ＜　悪いこといわないからつけとけ
　　|　　　　）●（　　|　　＼＿＿　　
　　＼　　　ー　　ﾉ　　　　　　　　
　　　＼＿＿＿_／　　　　　　　　　　　

168 ：仕様書無しさん：02/11/28 21:43

では変数名に型のプレフィックスを付けている漏れはウンコですか？

169 ：仕様書無しさん：02/11/28 22:09

ハンガリアン使いたがるやつは抽象的な思考が苦手なやつ。
数学の成績が悪かったろ。

170 ：仕様書無しさん：02/11/28 22:12

個人のコードなら抽象的思考でも良いんだけどな。

171 ：162：02/11/28 22:14

>>165
いや、まぁ、天才ってのはわかってるよ。
漏れなんかより遥かに遥かに．．．(中略)．．．遥かに切れものっす。

でもハンガリアンは糞
スコープのprefixはいいんだけどなぁ。

172 ：仕様書無しさん：02/11/28 22:15

>>169
根拠の無いこと書いて楽しいか？
お前さんの数学の能力の方が疑わしいんだが。

173 ：仕様書無しさん：02/11/28 22:21

結局、宣言(定義)場所見るのに何故に変数名に型をつけるのか。
そもそもデータの型ってそのデータ(オブジェクト)に属するもので
あって、変数に属するものとは違うんじゃないの?

174 ：仕様書無しさん：02/11/28 22:23

誤) 結局、宣言(定義)
正) 結局は宣言(定義)

誤) 変数に属する
正) 変数名に属する

175 ：仕様書無しさん：02/11/28 22:25

構造体のメンバだと、宣言箇所探すのうざいな。
まあ、DeveloperStudio使ってれば右クリック一発だけどね。

176 ：仕様書無しさん：02/11/28 22:28

>169
> 数学の成績が悪かったろ。
俺は数学は得意で未だにそっちとは縁が切れない仕事をやってるが、それと
ハンガリアン表記と何の関係があるんだ？

厳密なハンガリアン表記は使わんけど、整数変数に n, unsigned だと u, ポイ
ンタは p ぐらいのプリフィクスは良く使うな。システム絡みのプログラムだと

　unsigned int (32bit) ui
　unsigned long (64bit) -> ul
　u_long128 -> ul128

とかつけることもある。アライメント制約がメンドイ部分のプログラム（PS2 の
DMA パケットライブラリとかさ）書く場合には、変数のサイズやアライメントを
名前から読みとれるようにしておくと便利だ。

177 ：仕様書無しさん：02/11/28 22:32

>173
そこはプログラミング言語による。

変数には

o 決まった型のデータしか入らないもの（たとえば C)
o 一定の範囲で条件を満たせば格納できるモノ (たとえば C++ のポインタ、
　特定の型だけでなくそれを継承したオブジェクトも指せる）
o 一切制約がないもの（たとえば SmallTalk の変数)

と色々ある。

178 ：仕様書無しさん：02/11/28 22:41

ポインタの"p"は確かに便利だよな。ほかは符号の有無か8bit/16bit/32bitの区別が
付くプリフィックスしか使ってない。厳密なハンガリアンだと配列には何かつけるとかも
あったはず。つかさ、ハンガリアン以前もポインタ型だとそれとわかる変数名にしてなかった？

int *base_ptr;

とかさ。それをPG間で意思統一できるように規約化しただけのような気がするけど。

179 ：仕様書無しさん：02/11/28 22:50

char bit8Data:
short bit16Data;
long bit32Data;

怖いっ

180 ：仕様書無しさん：02/11/28 22:59

>>179
char cNameOne;
short sNameOne;
int iNameOne;
long lNameOne;

だろふつう。

181 ：179：02/11/28 23:10

>>180
178をからかっただけですが・・・

182 ：仕様書無しさん：02/11/28 23:10

まぁなんでも程々にって事で

========================= 終了 =========================

183 ：kei：02/11/28 23:40

cntと書くぐらいならcountと書け。

184 ：仕様書無しさん：02/11/28 23:41

for (int n = 0; ...
　　for (int n2 = 0; ...
　　　　for (int n3 = 0; ...
　　　　　　for (int n4 = 0; ...

185 ：150：02/11/29 09:09

>>173
どこに属そうが単体で見れば一変数。
わざわざ定義部を参照しに行かねばならぬのは、いつまでたっても
参考書から離れられない香具師と同じ。
覚えりゃあ終いだが、それは個人の能力に委ねられる。
つーわけで、グループ開発しているのにハンガリアンを否定する
香具師は迷惑だから
帰って糞して寝ろ。

大体、人の組んだプログラムの変数を読む時、わざわざ型属性を覚えてから
読むか？普通。

一人でPG組んでる香具師は好きにオナニーしろ。

186 ：仕様書無しさん：02/11/29 09:46

>>180
short が１ビット操作を表すキチガイコンパイラもあるようです。
http://www.picfun.com/cinst03.html

187 ：仕様書無しさん：02/11/29 10:00

>>150
おいおい、いつからグループ開発ではハンガリアン用いるって事に
なったんだ(w
グループ開発では、そのグループのコーディング規約に従うのは常
識だろ。
そのコーディング規約に従わず、一人ハンガリアンをしてるやつこそ
オナニーで我慢して炉よ。

188 ：150：02/11/29 11:01

>>187
過去ログよく読め、折れはコーディング規約にハンガリアンを入れろと言っている。
おまいは足らん子か。
別にハンガリアンが嫌いなら嫌いでいいんだよ。
だからオナニー組については言うことは無い。

189 ：仕様書無しさん：02/11/29 11:12

ﾆﾀﾞを付けてハングリアンにしる

190 ：仕様書無しさん：02/11/29 11:21

>>189 GoodJob!

191 ：仕様書無しさん：02/11/29 11:21

SHURYOU

192 ：187：02/11/29 11:30

>>188=150
>150で言ってる事か?
俺はあのレスを　「自分なりに仕様定義したもの」　を
「会社のコーディング規約に追加する」　と読んだ。
「ハンガリアンをコーディング規約に入れろ」　とは読まなかった。
おまえの意図したとおりに読めなくてスマナンダ。

で、おまえが「コーディング規約にハンガリアンを入れろ」と主張するな
ら、俺は「コーディング規約にハンガリアンは入れるな」と主張する。

ハングリアンなら興味あるかも(w

193 ：仕様書無しさん：02/11/29 11:56

んじゃ、ハングリアン以外に型情報を含める命名規約があればよいのだな。

int hoge_nida;
int *hoge_sumida;

194 ：仕様書無しさん：02/11/29 12:13

>>187
なぜ嫌い？
主な開発言語は？

195 ：187：02/11/29 12:23

>>ＣＯＢＯＬ

196 ：150：02/11/29 12:50

>>192
まあ、ハンガリアンに代わる手があるならいいんだけどさ。
毎度定義を参照するのか？結局。
なら効率悪いと思うが。

ハンガリアン否定論者って、見栄えが気に入らないだけではないか？

197 ：老人：02/11/29 12:54

わしは、UNIXやDOSの頃はＣでやっとったが、
ハンガリアンってのは聞かんかったな。

そうじゃなあ、世の中がＣ＋＋になりかけた頃じゃったかな、
どこぞの異国の者が来て、
『大きなやつを大勢で作る時は、これでやるように。』
と言うとったような気がせんでんもない。

まあ、Ｃの時代からの伝統を継承するもよし、新しく道を開くもよしじゃ！

198 ：仕様書無しさん：02/11/29 13:30

ﾊﾝｸﾞﾘｱﾝ最強ﾆﾀﾞ
全てのﾌﾟﾙｸﾞﾗﾏに強制するｽﾐﾀﾞ

199 ：仕様書無しさん：02/11/29 13:52

( ´∀｀)ﾉ　はーい、Cを叩き殺します♪

200 ：仕様書無しさん：02/11/29 13:54

>>196
毎度定義を参照して効率悪くなるようなスタイルってどんなんだよ。
何百行もあるでっかい関数を作って、関数の先頭で大量の変数を宣言してるとか?

201 ：仕様書無しさん：02/11/29 13:58

template使ってるのでハンガリアンできません。

202 ：仕様書無しさん：02/11/29 14:00

>>200
あちこちのファイルに散らばっているグローバル変数を使いまくってるので、
ハンガリアンを使わないと、変数の型を確認するのに、ファイルを開きまくって
効率悪くなります。
とか。

203 ：仕様書無しさん：02/11/29 14:10

ローカル変数にまでハンガリアンは使わないな。
でもグローバルはなってるとたまに助かるな。

204 ：仕様書無しさん：02/11/29 14:12

例えば、フラグとして使ってたshort(16bits)の変数があったとして、
static short sFlag;と定義されていたとしよう。
関数の引数・戻り値など、いろんな箇所で使用されていたとする。
仕様追加で16bitsでは足りなくなってint(32bits)を使わざるを得なくなった。

この場合、関連する関数の引数・戻り値を全部、int iFlagなどに
書き換えなきゃいけないのか？
その方が効率悪いと思うが。

205 ：仕様書無しさん：02/11/29 14:16

そんな重要な仕様追加があったら、どっちみち全箇所確認するから
かまわんｗ
むしろ、変わった部分がコンパイルエラーでも出してくれたほうが
よほどよい。

206 ：仕様書無しさん：02/11/29 14:31

最近、仕事で int64 を使うようになってきたんだが、
ハンガリアン記法ではどう扱おうか。

誰か考えるの手伝ってくれ～。

unsigned int64 の場合、漏れは q を頭につけてる。 quad word だから。

207 ：204：02/11/29 14:40

>>205
そだな。結局全確認するなら手間は一緒かもな。
大元の定義だけ変更すれば、使用箇所でコンパイルエラーが出るだろうし。

じゃあ、勘違いしてshortなのにiName;としてしまった場合。
もちろん、規約を守らない奴が悪いんだが。
そういうのが一個見つかると、間違ってるのはその一個の定義名だけではないのでは？
(もしかしたらint *strNameとか、char sNameとかも見つかるんじゃないか？)
という疑念に駆られることはないのかな。

208 ：205：02/11/29 14:46

>>207氏
ハンガリアン記法だからといって
そこに妙な信仰を置くことはしてないよ。
変数使う前に型は一度は確認するし。
（正しく表記されてたら以後さほど確認しないけど）

209 ：仕様書無しさん：02/11/29 14:55

>>206
そんなくだらないことで悩むのなら、ハンガリアンなんて使わないほうがいいよ。

210 ：仕様書無しさん：02/11/29 14:58

>>209 すでに膨大なソースがあるから今からそれは無理

211 ：仕様書無しさん：02/11/29 15:05

悩んだっていいんじゃないの？
1回決めちゃえば悩まなくなるんだし。
一貫性を作るための儀式と思えばそんなに高いコストでもないし、
くだらないってものでもない。

212 ：187：02/11/29 15:06

>>194
prefix部分が長いとパッと見その変数が「何を表しているのか」がわかり
ずらい、(漏れの場合)型情報より「何を表す」っていう情報が欲しい場合が
多い　から

C/C++ での開発

毎回宣言場所見るといっても、右クリックとか C-] とか、そうでなくても
せいぜい1、2ページさかのぼるくらいだし。

まぁハンガリアン信者は、JavaやC# でもハンガリアン使っててくれよ(w

213 ：仕様書無しさん：02/11/29 15:08

何かというとすぐに「信者」とかつけるやつの
狭量さはなんとかならないものか・・・

214 ：仕様書無しさん：02/11/29 15:14

ハンガリアンってのはそもそも型安全じゃない言語のための防護策の一つで、
型安全な言語にまで持ち込む類の物ではないとは思う。
つまるところ「使い分け」が肝心なだけだ。

＞まぁハンガリアン信者は、JavaやC# でもハンガリアン使っててくれよ(w

こんなつまらん煽りを入れるくらいなら、
もう少しバランス感覚を養えよ。

215 ：仕様書無しさん：02/11/29 15:18

ハンガリアン信者とか喚いてるやつに特に聞きたいんだが
単なるプレフィックスはどの辺からハンガリアンになるんだ？
プレフィックスはお前も使ってるだろ？

違いがわからん教えてくれ

216 ：150：02/11/29 15:24

>>207
勘違い・間違えてプレフィックス付けると後で困るとか、仕様変更した時に
困るとかってーのは、プレフィックスに限らないだろ？
そんな時って、もっと根本的な仕様・設計に影響を与えていると思うが。
んで、名前を書き換えるくらい、グローバル置換使えば終わりだろうが。

おまいらは世の中に広く出まわってるツール類を使いこなすことは出来ないのか？

>>212
分からないヤツだな。そんな頭固くてよくプログラマなんかやってるな。
オマエが分かっても、他のヤツが分からなければダメだろ。
分からないヤツは逝ってよしで終了なら簡単だがな。
（そーゆー開発グループで仕事してるんならそれで良し。）

大体、見づらいってのはどういう事だ？
プレフィックス部１～２文字の次は大文字英字で始まるだろ？フツー。
乱視か？

ソースにしても仕様書にしても、他人に如何に分かり易く書けるかっちゅー
所も技術者として腕の見せ所だろう。
「いらない」なんて言うのは簡単なんだよ。
逃げるなバカヤロウ。
もっと仕事に手をかけろバカヤロウ。

と言ってみるプレフィックス。

217 ：仕様書無しさん：02/11/29 15:30

>>206 >>211
というかさ、たとえばプロジェクトがC99を使うようになったとして、
整数型全部に違うプレフィックスをつけようとか、そういう思想なわけ?
ヘボ過ぎるよ。

218 ：仕様書無しさん：02/11/29 15:33

>>215
ぶっちゃけ、
プレフィックス付ける事＝ハンガリアン
でいいんじゃないの？
要は型を明示すれば良いっつーことで。

一般的にはnとかszとかを語頭に付けたらハンガリアンだと言われるが、
どんな形にせよ目的は「型の明示」なんだから、＝「プレフィックスを付けること」
になるんじゃないか？

そういう事を昔、技術書で見たけど。

それでもハンガリアンと区別するならば、見栄えの違いだろな。

219 ：仕様書無しさん：02/11/29 15:33

>>217
その思想がヘボいかどうかは知らんけど、
少なくとも一貫性があれば間違いは減るよ。

君とってヘボいかどうかは別に俺にとって問題じゃなくて、
全体の効率をみてるだけだが。

220 ：仕様書無しさん：02/11/29 15:36

> 勘違い・間違えてプレフィックス付けると後で困るとか、仕様変更した時に
> 困るとかってーのは、プレフィックスに限らないだろ？
> んで、名前を書き換えるくらい、グローバル置換使えば終わりだろうが。
最初からprefixなんてつけなければ、型が変わったところでそんな余計な作業は発生しないのだが。

221 ：仕様書無しさん：02/11/29 15:37

>>219
変数命名規則にプレフィックス表とかが載ってて、その項目が
何十もあるようなプロジェクトなんて、本人たちが思ってるほど
効率良くないよ。

222 ：仕様書無しさん：02/11/29 15:37

>>220
んで、作業しないついでに確認も怠るとｗ

223 ：215：02/11/29 15:38

>>218

そうか？

昔からクラス名にプレフィックスT/C/Iを付けたり
IBMのライブラリの引数aプレフィックス（これはSmalltalkが由来か）
とかは結構あっただろ。

俺もハンガリアンのlpszやstrには反吐が出るが
ハンガリアン叩きの奴って、ついでに
m_やg_等の型明示ではないプレフィックスを叩いたり
しかも_ポストフィクスにマンセーをしたりする奴が多いから
なんか見てて頭に来る。

224 ：仕様書無しさん：02/11/29 15:38

>>221
表にはしておくけど、
表にしないと覚えられないほど作るのは別の意味で愚かだな。
そんな愚かなことはしてませんが。

225 ：150：02/11/29 15:39

>>217
quad word ならなんか付けてもいいと思う。
WORD = w,DWORD = dwが一般的だろうから。
整数型なら、まだ不要な気がする。ちゅーか、使ったことないから思い付かん。

226 ：仕様書無しさん：02/11/29 15:39

利便性のために作るものを、利便性を損なうほど極端に扱っている
とわざわざ誤解するのは偏見を持ってる証拠では？>>221

227 ：仕様書無しさん：02/11/29 15:42

>>224
整数型全部に違うプレフィックスをつけようとか、新しい型が出るたびに
適切なプレフィックスはなにかとか悩んでるプロジェクトなんて、
愚かだよ。

228 ：仕様書無しさん：02/11/29 15:46

まぁ結局のところそのグループによるから、煽ってる奴はちゃんとグループ
の規約に従ってちょうだいね。

229 ：仕様書無しさん：02/11/29 15:47

>>222
何の確認を怠るの?

230 ：仕様書無しさん：02/11/29 15:48

>>227
プロジェクトが悩んでるんじゃねーってば。
そんなもの決めるために会議開けってか？おい
おバカの集団扱いはやめろｗ

w dw とつけて来てるから、qw でいいか？って承諾とる程度の話だろ。

231 ：150：02/11/29 15:49

>>220
> 最初からprefixなんてつけなければ、型が変わったところでそんな余計な作業は発生しないのだが。
プレフィックスを覚えないヤツ、確認すらしないヤツならなおさら、
何か分からない型を分からないまま変に使ってバグらせてしまうほうが
リスクが高く、余計な作業を遥かに超えるデスマーチを呼ぶ危険性も
あるだろう。

違う？

んでよ、１ページ２ページ戻るだけの作業が出来るなら、置換ツールくらい
も使えるだろ？
手間か？
仕様変更があるからハンガリアンが嫌・・といっても、その仕様変更で
"counter_2ch"が"counter_yahoo"に変わったら、結局置換するんだろ？
そのままなのか？

232 ：仕様書無しさん：02/11/29 15:50

>>231 そんな確認もできないやつに構造体やグローバル変数を
決める権限は与えません。

233 ：仕様書無しさん：02/11/29 15:51

word って16bitって決まってるの?
Windowsのみで使うコードならいいけど、そうでないならなんか違和感あるなぁ。

234 ：150：02/11/29 15:51

>>230
だったらそうしろよ。
それすら却下なのかと、はた目で見ててそう思った。

235 ：仕様書無しさん：02/11/29 15:53

>>232
先生！
そんな人がプロジェクトに交じってる時点で恐いです。
権限が無くても勝手に何かやりそうです。

236 ：仕様書無しさん：02/11/29 15:53

郷に入っては郷に従え＞all

237 ：仕様書無しさん：02/11/29 15:53

でも、現実に居るよ。そういうやつ・・・>>235

238 ：仕様書無しさん：02/11/29 15:54

>>234 どこを見てそう思ったのかが、よくわからなかったけど、まあどうでもいいか。

239 ：仕様書無しさん：02/11/29 15:54

>233
word=byte*2じゃないの？

240 ：150：02/11/29 15:57

>>238
いや、愚かだからしたくない・・・しませんがって>224にあったからさ。
すまそ。

241 ：仕様書無しさん：02/11/29 15:59

>>240 ああ納得。あそこは表現悪かったね。こっちこそ誤解させたみたいでｽﾏｿ

242 ：仕様書無しさん：02/11/29 16:02

もういっそのこと、モンゴリアン記法で統一。

243 ：仕様書無しさん：02/11/29 16:07

いや、ジャンガリアン記法で。

244 ：仕様書無しさん：02/11/29 16:07

これぞ、ヤーパン記法

245 ：仕様書無しさん：02/11/29 16:07

>>242 分かったから何か例をあげろや

246 ：ﾌﾞﾗｸﾗに挑戦する名無し：02/11/29 16:10

ﾌﾞﾗｸﾗｷﾎﾞﾝﾇ
ﾏﾀｰﾘ

247 ：仕様書無しさん：02/11/29 16:12

>>246
くでぇ、死んでよし！

248 ：仕様書無しさん：02/11/29 16:12

ハンガリアン信者って、ハンガリアンで効率が良くなるって
かたくなに信じてるけど、労力のわりには報われることが少ない
ような。

整数型のshortとintの区別がついてうれしい場面って、
I/Oとオーバーフローの恐れがあるときくらい?
でも、実際組んでてハンガリアンのおかげでオーバーフローが
防げたとかI/Oのサイズを間違えずにすんだなってことほとんどないしね。

249 ：仕様書無しさん：02/11/29 16:28

「ポインタにはpをつける」だそうなのでやってみたが。
short *pHogeA;
char *pHogeB;
char **pHogeC;
・・・この接頭詞ってなにか意味があるの？

250 ：ハンガリアン信者：02/11/29 16:29

>>248
髪の御加護がありますように。ﾏﾀｰﾘ

251 ：150：02/11/29 16:30

>>248
だから、人の資質によるってば。
おまいはそうなんだろう。それだけの話だよ。

折れだって、別にハンガリアンを好きでやってる訳では無い。
好きとかうれしいとかの次元でやるのが間違いなのよ。

そもそもプレフィックス付けるのに労力かかるかね？

・・と、こう書くと>220,>231辺りのループに陥りそうだなぁ。

252 ：仕様書無しさん：02/11/29 16:31

自分の不幸は脳裏に焼き付く。しかし、多くの幸福は忘れ去られるものさ。

253 ：仕様書無しさん：02/11/29 16:33

＞折れだって、別にハンガリアンを好きでやってる訳では無い。
＞好きとかうれしいとかの次元でやるのが間違いなのよ。

無意味だと思ってるけど、規則だから仕方なくやってるってこと?

254 ：150：02/11/29 16:33

shortのポインタはlpnとかpn違うの？
ポインタのポインタは～議論が分かれるかも知れんが、pのままか、
ppなんだろと思うが。
あと、文字列ならzが付いて・・・と。

ま、混乱しないよーにちゃんと会社でルール決めればいいじゃんか。

255 ：仕様書無しさん：02/11/29 16:34

＞そもそもプレフィックス付けるのに労力かかるかね？

3～5種類程度ならいいけど、10種類以上になると苦痛。

256 ：仕様書無しさん：02/11/29 16:36

コントロール名限定でハンガリアン使ってるけど、
確かに種類が少ないと効果的だよね。

257 ：仕様書無しさん：02/11/29 16:36

コントロールはGUIのControlね

258 ：150：02/11/29 16:37

>>253
違う。
好きか嫌いで言うなら、嫌いだと言っただけで、必要だと思うよ。

ちゃんと
＞好きとかうれしいとかの次元でやるのが間違いなのよ。
って書いてるじゃんかよ。

必要なの
意味あるの

259 ：仕様書無しさん：02/11/29 16:38

> ま、混乱しないよーにちゃんと会社でルール決めればいいじゃんか。
つまり無闇にハンガリアン記法を使うと、コード書く人が混乱する、と。

260 ：仕様書無しさん：02/11/29 16:38

ハンガリアンダメダメ派に質問。

なんでダメなの。

261 ：150：02/11/29 16:39

>>255
そーかい？
型覚えるくらいの作業量違うかなあ？
型は覚えられるっしょな？

262 ：249：02/11/29 16:41

「boolにはbをつける」だそうだ。
bool isCool;
bool bIsCool;
どっちが見やすいのかなぁ。

263 ：150：02/11/29 16:43

>>259
つまり、ルールが無いというのは無法地帯なのと同じだと思われ。
混乱以上が想定される・・・・違う？

まあ、「過ぎたるは～」なんとかって言うけどねえ。
ハンガリアン使うと混乱するってどんなのよ？
ぱるぷんてか？ハンガリアンは。

264 ：150：02/11/29 16:45

>>262
折れならbCoolにする。
trueかfalseしか無いんだからさ。

別にbIsCoolでも苦は無いけど。

265 ：仕様書無しさん：02/11/29 16:47

古から（おそらくソフトウェア登場以前）整数型変数にはi, j, k, l, m, nを使うが、
これも一種のハンガリアンといえなくは無い。

266 ：ハンガリアン信者：02/11/29 16:49

皆も見よ！
未熟者の為に、彼は敢えて異端を演じているのだ。

267 ：150：02/11/29 16:50

>>262
ちと思ったが、boolは真偽を表す物だろ？
isCoolと命名してるってことは、isで真偽を明示してるんではないの？
リッパにプレフィックス付けてるようなもんじゃないの？

大体、bool==bじゃなくても良いと思う。
用法用量が統一されていれば。

268 ：仕様書無しさん：02/11/29 16:57

プレフィックス付ける＝ハンガリアン記法かよ？
この勢いだとアクセサのget～やset～もハンガリアン記法の範疇に入れられそうだな。

269 ：仕様書無しさん：02/11/29 17:02

>>268
プレフィックス付ける＝ハンガリアン記法じゃないとしたら
ハンガリアンの定義って何よ？

270 ：仕様書無しさん：02/11/29 17:02

我が社の一部グループでの規則

a則)---
構造体は st
文字列は sz
intは n
unsigned longは ul
unsigned shortは us
配列は a
boolは f
--- を頭につける

ポインタは a則にp を更に付加
static は a即に s_ を更に付加
引数の入力値は a即に i_ を更に付加
引数の出力値は a即に o_ を更に付加
引数の入出力値は a即に io_ を更に付加

例)
PHogeList o_pstPupupu;

>>150
おいおい、ハンガリアン＝プレフィックスじゃないだろ。

271 ：仕様書無しさん：02/11/29 17:06

こんなページ見つけた
http://hp.vector.co.jp/authors/VA017405/hungarian.html

いっぱいあるねぇ。

272 ：150：02/11/29 17:07

>>268
> プレフィックス付ける＝ハンガリアン記法かよ？
大筋で、そういうことでいいんじゃないか？
だって、一般で言われているハンガリアンってどんな型でも明示できる
「仕様」なんか無いじゃんか。
真の目的は型を明示することなんだから、引用通りの解釈でも間違い
無いだろ。

「ハンガリアン＝語頭にn,sz等を使うこと」ならば、先に書いた通り
表すことができない型が出てくるだろう。
そういう不備が解消出来ないなら「ハンガリアン」は却下だ。

つーか、前にも色々書いたような。
読んどいてくれ。

んで、アクセサはアクセサだ。
あんたの脳タリンまで明示しなくて良い。

273 ：仕様書無しさん：02/11/29 17:08

>>270
なんか手間ばかりかかって、実効性のないルールの見本みたい。

274 ：仕様書無しさん：02/11/29 17:11

>>270
その例、どこまでがprefixか、どこからが変数名なのかわかりづらいな。
prefixの方が長いし。

275 ：270：02/11/29 17:12

>>273
もちろんこれはその規則の中の一部だ。
んで、そのグループのソースを眺めていて書き出したので実際はもっとしっかり
ドキュメント化されているのかもしれない。

>>272=150
ハンガリアンは確か、「型情報」をプレフィックスにつけるだと思った。
だから型情報でないプレフィックスはハンガリアンじゃないと思う。
(ってどんな型でも明示できる仕様なんか無いということは置いておく)

276 ：仕様書無しさん：02/11/29 17:13

あ、途中の'P'はprefixではないのね。
クラス名の先頭文字か何かを書くのかと思って間違えた。

277 ：仕様書無しさん：02/11/29 17:13

>>275
×)　ドキュメント化
○)　ルール化/ドキュメント化

278 ：270：02/11/29 17:18

>>276
漏れの例が悪すぎますた。スマソ。

char* io_pszString;
PCSTR i_pcszString;

とか(実際に)ある。

279 ：150：02/11/29 17:18

>>275
> ハンガリアンは確か、「型情報」をプレフィックスにつけるだと思った。
> だから型情報でないプレフィックスはハンガリアンじゃないと思う。
そうそう。そうだね。
とにかく、折れの主張は
> 真の目的は型を明示することなんだから
ってことで。

280 ：仕様書無しさん：02/11/29 17:25

> とにかく、折れの主張は
> > 真の目的は型を明示することなんだから
> ってことで。
変数の定義部分に型は明示されてるのだが。

281 ：仕様書無しさん：02/11/29 17:43

その定義部分を参照する手間が省けるではないか。

んで、ループ

282 ：仕様書無しさん：02/11/29 17:45

>>281
それ、とっくに論破されてるじゃん。

283 ：仕様書無しさん：02/11/29 17:50

何事にも程度というものがある
ソースが読みやすければいいんだよ
ハンガリアンもやり過ぎるとかえって見づらくなる

やり過ぎは体に悪いよ

284 ：仕様書無しさん：02/11/29 17:53

やり過ぎは体に悪いというだけなら誰でも言える。
問題はどこまでが良くてどこからが悪いのかだ。

285 ：仕様書無しさん：02/11/29 17:55

ウンコしたい

286 ：仕様書無しさん：02/11/29 17:59

>>284
できるだけ1文字で済ませる
1文字では意味不明の場合は2文字
特殊なものだけ3文字

4文字以上は体に悪い、おいらの場合

287 ：仕様書無しさん：02/11/29 18:06

>>286 念のため
もちろん変数全体の長さじゃないよ

288 ：仕様書無しさん：02/11/29 18:25

http://cm-solutions.com/cms/technical/guide/hungarian_naming_convention.htm
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvsgen/html/hunganotat.asp

わあ！だれか～！

289 ：150：02/11/29 18:46

>>282
どこで？

290 ：仕様書無しさん：02/11/29 19:21

わかつた。
ハンガリアンどうこうではなく。
150>> は変数名の中に型情報もたせる派
280>> は変数名の中に型情報もたせない派
または、ともにアオリタガリアンだな。

291 ：MS信者：02/11/29 19:45

馬鹿が。お前ら低脳は天下のマイクロソフト様におとなしく従ってればいいんだよ。
お前らが幾ら能書きたれようがマイクロソフト様以上の仕事が出来ないことぐらい
わかりきってるからな（藁

292 ：仕様書無しさん：02/11/29 19:50

>>291
MSの方ですか？

293 ：MS信者：02/11/29 19:51

>>292
お前には関係の無いことだ。
くやしかったら、こんなとこで遊んでないでコーディングに禿げむんだな（藁

294 ：仕様書無しさん：02/11/29 19:54

>>289
変数の定義を参照が負担になるようなコーディングスタイルが悪い。
そっちを直すほうがいいよ。

295 ：仕様書無しさん：02/11/29 19:57

>>289
変数の型に強く依存するになるようなコーディングスタイルが悪い。
そっちを直すほうがいいよ。

296 ：仕様書無しさん：02/11/29 20:02

ふつうはインターフェイス名で命名するので、特定の型に依存などしませんが？

297 ：仕様書無しさん：02/11/29 20:07

あと、集団で開発をやる場合にハンガリアンが役に立つみたいなことを
言ってる奴がいるけど、意味がわからん。

298 ：仕様書無しさん：02/11/29 20:16

>>297
失踪したやつのコードをメンテする時に役立つんだよ。

299 ：仕様書無しさん：02/11/29 20:18

そうだそうだ！全部Variantだ。

300 ：仕様書無しさん：02/11/29 20:20

>>298
なんで?

301 ：仕様書無しさん：02/11/29 20:25

版画りあんでは

std::vector<std::pair<int, std::string> >::const_iterator

にはどういうプレフィックスがつきますか？

302 ：仕様書無しさん：02/11/29 20:25

>>297
ハンガリアン記法をどう解釈してる？

303 ：仕様書無しさん：02/11/29 20:28

変数がどのようなインターフェイスを持つかということが集団開発にとって何よりも重要なのだよ。

304 ：仕様書無しさん：02/11/29 20:29

変数が？
インターフェイスを持つ？

？？？

305 ：仕様書無しさん：02/11/29 20:42

>>303
ここまでの議論を理解できない奴は、
相手にするな。疲れるだけだ。

306 ：仕様書無しさん：02/11/29 20:48

>>303
今までループしてる話題を違う言葉で言い直しただけ。
けっきょく何も説明できなくて、逃げるんだろ?

307 ：仕様書無しさん：02/11/29 20:53

コーディングルール決めておけば、しっかり仕事してるように見えるからな。
それが効能。

308 ：305：02/11/29 21:11

>>306
1.何がループしてんだ。
2.ハンガリアン記法をどう解釈しているか。
3.何がどう納得いかないんだ。
教えてくれ。
悪いが、返答は来週になる。スマンナ。

309 ：仕様書無しさん：02/11/29 21:12

BufferedOutputStream bos = null;
とかいうコード書くくらいなら、ハンガリアンにしる！

310 ：仕様書無しさん：02/11/29 21:15

ifstream ifs

311 ：仕様書無しさん：02/11/29 21:18

＞1.何がループしてんだ。

インターフェイスがどうとかって
「集団で使うとハンガリアンが役にたつ」以上のことを言ってる?

312 ：仕様書無しさん：02/11/29 21:37

Vector resultBookList = new Vector();
みたいに書けば、下手な一行コメント以上に明瞭なコードになる。

わかってると思うが、Listはインターフェイス「型」の名前だからな。
将来の互換性のために、型名にはVectorとそのまま書かないのは常識。
特定の型との強い結びつきなんか無いよ（笑

313 ：仕様書無しさん：02/11/29 21:42

>>312
それはハンガリアンとは言わない。

314 ：仕様書無しさん：02/11/29 21:54

それなら、tempStringBufferなんかはどうだろうか。

作業用の一時変数だとすぐに理解できるだろう？
この理解しやすさこそが、インスタンス変数に型情報を含めることの意義なのさ。

315 ：仕様書無しさん：02/11/29 21:56

s/作業/文字列作業/

316 ：仕様書無しさん：02/11/29 22:00

>>314
おいおい、お前は `インスタンス変数' に一時変数定義するのか?

317 ：仕様書無しさん：02/11/29 22:05

アゲアシトリカコワルイ

318 ：名無しさん＠お腹いっぱい。：02/11/29 22:07

>>316 OOPならいたって普通のことですがなにか？

319 ：仕様書無しさん：02/11/29 22:10

>>314
それは、変数の用途が「文字列作業用」だから分かりやすいんだろ。
たとえばデータファイルのパスを格納する文字列変数に、
StringDataPathとか、型情報をつけるのって意味あると思う?

320 ：仕様書無しさん：02/11/29 22:10

プリミティブな型とかその言語標準の型なら多少はハンガリアンも意味あるかも。
でも、開発途中だったらいくつも新しいデータ型は定義されるだろ？
そいつを変数名に含めたって、なんも理解しやすくなんかないぞ。

321 ：仕様書無しさん：02/11/29 22:13

こんなもんワードで開いて校正チェックすればＯＫだろ！

322 ：仕様書無しさん：02/11/29 22:15

Public glngi as long 'ループカウンタ

323 ：仕様書無しさん：02/11/29 22:17

プリミティブ型にまで記法の利用範囲を拡張するかは状況依存だと思うね。
私はめったにやらないよ。
特にこの場合、Pathが数値型のわけがないから、メリットはない。

324 ：仕様書無しさん：02/11/29 22:26

>プリミティブ型にまで記法の利用範囲を拡張するかは状況依存だと思うね。
？

325 ：316：02/11/29 22:28

>>318
ん?　インスタンス変数だよ?　つまりはオブジェクトの属性のようなものだよな。
318はオブジェクトに `一時的な' 属性持たせるの?

326 ：　：02/11/29 22:29

BOOL に is ﾒﾝﾊﾞに m_　グローバルにg_　これはいいね
あとは不要

327 ：仕様書無しさん：02/11/29 22:30

変数の名前に何でこだわる必要があるんだ？
関数の命名法にこだわるならわかるが。
変数を複数の開発者がアクセス関数なしで参照するほうが可笑しいと思うが。
きちんとカプセル化してあれば常識の範囲内でどんな名前つけてても関係ないと思うが。

328 ：仕様書無しさん：02/11/29 22:34

>>327 関数の中でどんな処理をしてるかを見た時に変数名がaとかb_02だったら嫌だぞ。

329 ：仕様書無しさん：02/11/29 22:37

>>327の作ったソースには>>87みたいな変数がうじゃうじゃと・・・

330 ：仕様書無しさん：02/11/29 22:40

>>327
非常識な輩がおるから盛り上がるのでは。

331 ：仕様書無しさん：02/11/29 22:40

>>326
canもたまに使う。
isがしっくりこない場合は、canがしっくりくる場合が多い。
this.xxxと書けばこのクラスのメンバ変数であることを
言語仕様レベルで明示できますが、何か？
super.xxxとか書けば、親クラスであることも（以下略

332 ：仕様書無しさん：02/11/29 22:50

なるほど、たしかにthisのほうがわかり易い

333 ：仕様書無しさん：02/11/29 22:50

>>331

言語の規則に合わすしかないよな。

334 ：仕様書無しさん：02/11/29 22:51

thisは良く使うなぁ。どこに属しているメンバかがパッと見てわかるから。

335 ：仕様書無しさん：02/11/29 22:55

>>328-329
まあそれはイヤだが(W。あくまで常識的な名前ね。
・・・常識が一人一人で違ってるのか。
学校の授業に「算数」みたいに「情報」が加われば、非常識なヤシもいなくなるかもね。

336 ：仕様書無しさん：02/11/29 23:08

>197
UNIX の名付け規約で有名なヤツだと、構造体の要素の頭二文字を予約ってのが
あるね。

struct netent {
　　char *n_name;
　　char **n_aliases;
　　short n_addrtype;
　　unsigned long n_net;
};

あとは int, long みたいな型ではなく、もう少し粒度が細かく「お約束の変数名」が
決まってる。socket なら s, ファイルデスクリプタなら fd みたいな感じで。

>220
> 最初からprefixなんてつけなければ、型が変わったところでそんな余計な作業は発生しないのだが。
言語や設計によって柔軟性を確保できる部分もあるが、確保できなかったりトレードオフが発生する部分も常にある。

C, C++ だと型の変更は「致命的」に影響が大きいから、変数名云々どころの問題では
ない。というか構造体の要素名をハンガリアンにしとくと、型変えたときに軒並みコンパ
イルエラーになって、かえって助かると思われ。

>301
iterator は単純に i を使う場合が多いなぁ。iterator を広いスコープに渡って保持して
おくことはあまりない。

337 ：仕様書無しさん：02/11/29 23:11

ハンガリアン信者ってまだ生存していたのか・・・

338 ：仕様書無しさん：02/11/29 23:16

>>337
全てはハンガリー人が悪い。

339 ：仕様書無しさん：02/11/29 23:17

>327
> 変数を複数の開発者がアクセス関数なしで参照するほうが可笑しいと思うが。
たとえカプセル化してあっても、そのカプセル化したクラス自体に手を入れる場合
もあるだろうに。というか、それって日常茶飯事のような気が。

340 ：仕様書無しさん：02/11/29 23:33

>>339
日常茶飯事なのかも知れないが、それを容認しようとは思わないよ、ね？
十分に練られていればそんな変更は最小限で済むはずなんだけど、ね？
つか、それってカプセル化してる意味ないんじゃないって思うよ、ね？

341 ：仕様書無しさん：02/11/29 23:36

>>339
クラス内ローカルな変数なら（a001みたいな記号は困るが）counterくらいなら
見て判ると思う。読んでて理解できないならクラスが複雑すぎる（設計し直したほうがいい）のでは？

342 ：仕様書無しさん：02/11/29 23:38

>>338
国籍や人種に偏見を持つのは悪いことニダ

343 ：仕様書無しさん：02/11/29 23:43

誰かジャパニーズ記法作れ。
あるいは２ちゃんねら記法。

344 ：仕様書無しさん：02/11/29 23:44

>>343
popをage
pushをsage

345 ：仕様書無しさん：02/11/29 23:47

ハン・ガリ・アン！！
ハン・ガリ・アン！！

346 ：仕様書無しさん：02/11/29 23:50

ハンガリアンってC爺？

347 ：仕様書無しさん：02/11/29 23:50

ハングリアンを普及させるﾆﾀﾞ

348 ：仕様書無しさん：02/11/30 05:15

バンコクミン絶滅宣言

349 ：仕様書無しさん：02/11/30 09:49

>340
> 十分に練られていればそんな変更は最小限で済むはずなんだけど、ね？
リファクタリングしないのか？

350 ：(　 _。。)_ ﾊﾞﾀ。 ◆eJlUd9keO2 ：02/11/30 09:54

個人的に
iCounter　とか lpStrings とかって、見難いので
i_Counter や lp_Strings ってアンダーバー入れちゃうクセが……。

こだわりってもんじゃないね。　Ｔ－Ｔ

351 ：仕様書無しさん：02/11/30 10:31

変数名とかって、プロジェクトによって、普通、規約書とかないの？

352 ：150：02/11/30 11:01

おまいら分かってないな。
他人が見て分かり易くなる手段として、ハンガリアンというものもある
ちゅーことだよ。
>319が書いたStringDataPathだが、このような命名がどのような場面でも
出来るかどうかを考えてくれ。また、ネーミングとは個人のセンスも
噛んでくる。
この結果、他人が見て理解出来るネーミングが出来なくなった時どうなる？

ハンガリアンはこういう問題を楽に解決する手段ともなるのよ。
前にも書いたが、個人でPG組んでるなら勝手に命名してオナニーしてくれ。

で、話がループしてると思うんだが、ループしてないというヤツの根拠が
分からん。丁寧に説明してくれたまえよ。

353 ：仕様書無しさん：02/11/30 11:06

ハンガリアン記法も言語仕様として含めといて、warning出すようにすればいいのに。
コンパイル時に記述の間違いもチェックできるし。
なぜC#の言語仕様はそうしなかったんだろ。ハンガリアンなんてMSのお家芸なのに。

354 ：150：02/11/30 11:08

>>294,295
もひとつ書かせてもらうが、おまいら過去ログ読んでないだろ。あほ。
おまいらのコーディングはすばらしい物なんだろうが、他人がそこまでの
スキルがあるという保証はあるのか？
入社したばかりの新人のソース見ても、苦もなくトレース出来るのか？
ま、スキル次第なんで、新人に限らんだろうが、スキルが低いヤツは
どうすべきだと思うのよ？
スキルが低くてもハンガリアンさえ徹底させとけば、データ周りに関して
はとりあえず信頼性が向上すると思えないか？
この場合、おまいがそのスキル低いヤツのソースを見る、スキルの低いヤツ
自身、ハンガリアンに助けられることになると思うのだが。

スキルが高いヤツのグループでしか仕事しなくて、ネーミングのセンスも
皆同じで解釈に苦労する事が全くないんなら、どうぞご勝手にしてくだしい。

355 ：仕様書無しさん：02/11/30 11:14

>もひとつ書かせてもらうが、おまいら過去ログ読んでないだろ。
...
>スキルが低くてもハンガリアンさえ徹底させとけば、データ周りに関して
>はとりあえず信頼性が向上すると思えないか？

ログを読んでないアホはお前だろ。
ハンガリアンのだめさかげんが今までずっと指摘されてて、
それに反論せずに、ハンガリアンを使えば
「とりあえず信頼性が向上する」
みたいな事を繰り返してるだけだし。

356 ：仕様書無しさん：02/11/30 11:15

一口にハンガリアン表記といっても、ほんっとに厳密なヤツから

　b　　ブール
　n　　整数
　p　　ポインタ
　sz　Cスタイル文字列
　str　C++文字列 (CString だったり std::string だったりするが)

程度であとは適当にって緩い基準まである。どのレベルで話してるのか明記しな
いと、話がスレ違うような。

俺は緩めのハンガリアン表記は使うが、さすがに某社のような

　c　const
　r　参照型
　str　Cスタイル文字列
　prm　引数

なんつー規約はどうかと思う。これ、マジメにやると仮引数が

　void foo(const CString& crstr_prmDir, const CString crstr_prmFile)

とかになって、やっとれんよ。

357 ：356：02/11/30 11:17

>355
> ハンガリアンのだめさかげんが今までずっと指摘されてて、
そうか？　ハンガリアンがダメな理由って幾つか出てきたけど、どれも決定力に
欠けるような。

型を変えたらどうするんだよ、とかは「名前がどうこうってレベルの問題じゃなく、
ソースコードレビューし直しだろうが」と突っ込まれてたし。

358 ：仕様書無しさん：02/11/30 11:32

>>354
> スキルが低くてもハンガリアンさえ徹底させとけば、データ周りに関して

意味ないと思うけど。
たとえばソース中に、nHogeCountという変数があったとして、
ハンガリアンのおかげでオーバーフローのバグが防げた！
みたいなことって、現実には無いんじゃない？

359 ：仕様書無しさん：02/11/30 11:35

ハンガリアン派が定義の参照が楽になるみたいなこと言ってる
けど、変数の型はじっさいに確認して頭に入れてコードを
書かないと、かえって危ないだろ。

360 ：150：02/11/30 11:46

>>367
確かに色々あります。
でも、ここではハンガリアン自体の有効性に絞って話した方がいいと思う。
開発チームそれぞれのスタイルとか好みもあるだろうし、事の本質に対する
対策をするかしないかが重要だと思う。

>>357
同意です。
これまでのダメ理由って、ハンガリアンの問題以前の問題を挙げている。
あらゆる可能性を考えればハンガリアンに則ってコーディングしといた方が
いいって言ってるのに、まだ>358みたいなこと言うんだよな。

>>358
それは確率・可能性の問題であって、バグが出てしまっても後のトレースの
しやすさとかが違ってこないか？
ハンガリアンがバグを100%防ぐ訳ない。バグが100%防げないならハンガリアン
は無用？そういう問題？

361 ：150：02/11/30 11:49

>>359
自分は良くても他人が読んだ場合・・・・過去ログ読んだ？
そんな単純なことだけならハンガリアンなんて普及しないだろ。
もっと奥が深いと思うんだけどなぁ。

なんでそんな簡単にハンガリアンを否定出来るのか分からん。
自分さえ良ければ・・・オレはいいんだよ～みたいな感じのヤツが
否定する側の人か？

362 ：仕様書無しさん：02/11/30 11:52

>>359
頭に入れた情報が100%信頼できるあなたは幸せですね。
私は目で見たことを信じて書くので、
500行も前のプライベートなメンバに宣言された情報をいちいち参照しにいくのが
苦痛なのです。
あなたのように頭に入った情報が100%信頼できればよかったのですが、ね。

363 ：仕様書無しさん：02/11/30 11:54

つまり、頭の悪い奴は半狩り案使えって事ですね？

364 ：仕様書無しさん：02/11/30 11:58

>>363
君が1年前の自分のコードを見たときにも
「すぐに頭に情報を入れられて」
「頭に入れた情報が100%信頼できる」ほどに賢いのなら、
そう解釈しても良いと思うよ。

365 ：仕様書無しさん：02/11/30 11:58

>>361
>自分は良くても他人が読んだ場合・・・・過去ログ読んだ？

人のコードを読むときでも同じだよ。

> そんな単純なことだけならハンガリアンなんて普及しないだろ。

普及してるって話題だったら、
ほとんど誰の異論もなしに普及してる技法とかスタイルはいろいろ
あるけどそれに比べてハンガリアンは使ってるのってMS文化の
影響下ところだけでしょ。

議論があると必ず割れるし。
結局、ハンガリアンってあってもなくてもほとんど影響ないって
ことじゃない?

366 ：359じゃないけど：02/11/30 11:59

>>362
>359は「じっさいに確認して」って書いてるじゃねーか。
お前は目で見たことを信じるっちゅうけど、変数名 *だけ* 見て信じれんのかYO！

367 ：150：02/11/30 11:59

>>363
神のように頭の良いヤツが組んだ神のようなPGは、一般人には理解出来ない
ことが多いでしょ。
逆に神から見た一般人が書いたコードってのは、多分苦痛なんじゃない？

もっと他人に優しく・・・・

368 ：仕様書無しさん：02/11/30 12:01

ねぇねぇねぇ、ハンガリアンを使うべきだ　と言ってるヤシは、
JavaやC#でも使ってるの？

369 ：仕様書無しさん：02/11/30 12:03

なんでハンガリアンとMSが関係あるんだよ？

370 ：仕様書無しさん：02/11/30 12:07

>>362
何百行もあるコードの全部の変数を覚えて、それから一気に
コード読むとか、そんなことをやってるわけじゃないので。

コードの10行～30行の範囲で使ってる変数は、だいたい数個程度
だから、簡単に確認して覚えられます。

371 ：150：02/11/30 12:08

>>365
「普及」とまで言うのは語弊があるかもね。
ちょっとそれは置いとこう。

おまいは人のコードを読むのにあなたは問題なくても、おまい以外の
どんな人でもそうなの？
人が作った数ある変数、全部頭に入りまつか？
全部頭に入れるの効率悪くない？

>>366
おまいが言ってる事は分かるが、最初の定義部に間違いがないと
確認出来たら、後は変数名だけ見てても十分に信じれるのでは？
それでも信じれないというのであれば、そもそもの定義部すら信じる
ことは出来ないよな？
WORD wData ・・・WORDの宣言が信じられない・・・と。

372 ：150：02/11/30 12:09

>>370
じゃあ、30行以上のコードはどうすんのよ？

373 ：仕様書無しさん：02/11/30 12:09

>>369
MSのプログラマが発祥で、MSのサンプルコードなどに使われていたから。

374 ：仕様書無しさん：02/11/30 12:09

>>366
信じますよ。
自分が書いたにせよ、同僚が書いたにせよ、ほかの誰かが書いたにせよ、
ハンガリアン式に命名された変数名が持つ型情報を信じなくてどうするんです？

逆に、唐突に「temp」とかいう変数名が現れて、検索しても見付からなくて、
実は親クラスのメンバで宣言されているFile型の変数だと知ったときには、
俺の時間を返せ糞コーダが！と思います。

何も言わずにsuper.tempFileと書け。頼むから。

375 ：　：02/11/30 12:10

ハンガリアンを使うことの弊害ってある？
意味が無いとかカッコ悪いとかいう主張しか聞こえないんだけど。

376 ：150：02/11/30 12:11

>>373
MS発祥なだけで、考え方はどれでもあてはまりまつ。
ちゅーか、MS以外のプラットフォームの方がハンガリアン使いやすい気がするけど。
型の種類の多さで思った。・・ま、MS以外はあまり知らないんだけど。

377 ：仕様書無しさん：02/11/30 12:12

一言で言って「無駄」だからだ

378 ：150：02/11/30 12:13

>>374
派外道。

379 ：仕様書無しさん：02/11/30 12:13

>>372
コードの機能は、たいてい数十行単位でわかれてるから、
読み書きもその単位でやればいいよ。

でかい関数でも、中身はあるていど機能単位で分かれてるでしょ。

380 ：366：02/11/30 12:15

>>371=150
確認するんだったらハンガリアンである必要無いじゃねーか。

>>374
`super' は型情報じゃなくむしろスコープに関するものだからハンガリアンじゃねーだろ。

381 ：仕様書無しさん：02/11/30 12:16

意味もわからず適当にハンガリアンつける
馬鹿がたまにいるからな・・・

382 ：150：02/11/30 12:16

>>379
ある程度スキルがあるヤツが組んだらって話じゃないの？
あと、グローバル部のは？

まあ、そこまで不要だと言われるなら強要しませんが。
同じ開発部じゃないし。

383 ：仕様書無しさん：02/11/30 12:17

>>375
見づらい
変数名を信頼しすぎて実際の型の確認がおろそかになる

384 ：仕様書無しさん：02/11/30 12:18

>>374
> 信じますよ。
> 自分が書いたにせよ、同僚が書いたにせよ、ほかの誰かが書いたにせよ

基本的に人間の仕事は信じないほうが。。。
(ハンガリアンが正しいかチェックしてくれるツールでもあるないいですけど)

> 逆に、唐突に「temp」とかいう変数名が現れて、検索しても見付からなくて、
...
> 何も言わずにsuper.tempFileと書け。頼むから。

これは結局、ハンアガリアンで解決してないのでは?
(この場合superやFileはハンガリアンとは言わないから)

385 ：368：02/11/30 12:20

ねぇねぇねぇ、ハンガリアンにするべきって言ってる人
>>368の返答まだぁー?

386 ：仕様書無しさん：02/11/30 12:21

>>382
>ある程度スキルがあるヤツが組んだらって話じゃないの？

うーん。
逆に、数百行のコードが機能が不可分で関連する変数も数十ある
ようなスパゲティーコードって、ハンガリアンを使う使わない以前の
問題で救済できないのでは?

387 ：150：02/11/30 12:21

>>380
はあ？
ハンガリアンやめたら、後でこの変数の型はなんだ？ってなるだろうが。
確認したときに全て丸覚えする訳じゃない。間違い探しするだけだ。

んで、"super"はハンガリアンじゃないぞ。単なる例でスコープ付けただけ
だろ。
おまい、ハンガリアンというものを知らないまま書いてるんじゃないだろな？

388 ：仕様書無しさん：02/11/30 12:23

>>384
ハンガリアンにするべきって言ってるヤシそれぞれで、俺製ハンガリアン
を使ってるみたいだな。

389 ：仕様書無しさん：02/11/30 12:23

つか、大昔も変数名に_ptrとか_flagとかつけてたずら。
「あれも型情報を変数名にもたせる。」という意味ではハンガリアンと一緒だべ
いいだしっぺがMSか各自勝手につけたかの違いだべ。

ま、Micro$oftは糞。大っ嫌い。つうんなら異論はないべ。

390 ：仕様書無しさん：02/11/30 12:24

で、ハンガリアンの欠点って何？

391 ：150：02/11/30 12:28

>>385
折れはC,CPPの人。

>>386
スキルの問題もあるし、スキルがあっても長いコードを書く事もない？
で、そんなときだけハンガリアン使う方が抵抗あると思うし、だったら
すっきり使う方向で統一してしまってもいいんじゃないかと。
スキル低いからって、あぼーん出来ないだろうし、なんとか一人前に
しなきゃいけないっしょ？
まあ、それでも社で不要だと結論が出てるなら、それでいいけど。

392 ：仕様書無しさん：02/11/30 12:28

ある程度はハンガリでやらないと、新人とかきついよ。
おれもコーディング規約なんて嫌いだけど新人にみようみまねで
変数名に気をつけてっていったら結構すごいことになっちゃうんだ。

しょうがなく俺の流儀をドキュメントにした。
人それぞれ癖があるから規約にするのはあんまり気が
進まないけど仕方ない。

393 ：仕様書無しさん：02/11/30 12:28

>>390
間違っていてもチェックされない

394 ：仕様書無しさん：02/11/30 12:29

構造体のメンバに単にnextってあるのと、pNextとかnext_ptrじゃ全然違う罠。

395 ：仕様書無しさん：02/11/30 12:29

>>390
意味がない。

396 ：仕様書無しさん：02/11/30 12:30

>>387=150
>380で「ハンガリアンじゃねーだろ」って書いてるジャンか。
おまい、わけわからん。

文句いうなら
>374で「検索しても見付からなくて、実は親クラスのメンバで宣言されてい
るFile型の変数だと知ったときには、俺の時間を返せ」
という風に、`検索しても見つからない'、`それは親クラスで宣言されているせいだ'
とハンガリアンとは関係ないことを書いた糞374に言ってくれ！

397 ：150：02/11/30 12:30

>>388
>>272を見てくれ。

398 ：仕様書無しさん：02/11/30 12:30

>>390
発祥がMS。Sunなら可。

399 ：仕様書無しさん：02/11/30 12:31

>>392
ぱっと見た目に整って見える以上の効果ってあるの?

400 ：仕様書無しさん：02/11/30 12:31

>395
ハンがリが優れてるかどうかは別として
意味が無いというのは見当違いもはなはだし

401 ：150：02/11/30 12:34

>>396
> という風に、`検索しても見つからない'、`それは親クラスで宣言されているせいだ'
> とハンガリアンとは関係ないことを書いた糞374に言ってくれ！
関係あるでしょ。

んで、>>272見て。折れの持論。
だから、super.tempFileの'File'が付くか付かないかを見るべきだと思う。

402 ：仕様書無しさん：02/11/30 12:34

>>394
ハンガリアンは無意味だと思ってるけど、
そういう省略記法的な使い方は、おれも使ってるよ。

hogeHandleみたいな変数がたくさんあったら、
hHogeみたいに書いたり。

403 ：仕様書無しさん：02/11/30 12:34

ハンガリアンの欠点は、変数名を信じすぎて実際の型チェックがおろそかに
なる可能性があるってところだな。

404 ：392：02/11/30 12:36

俺馬鹿だからコードレビューのとき、数行前の宣言でも
ハンガリで書いてくれるとたすかる。
ぱっとみNameIDとあるより
nNameID、strNameIDのほうがその行だけで理解できる、、、
俺馬鹿だから数行前の宣言でも、、、

で、世の中結構こんな馬鹿が多いと思う。

405 ：仕様書無しさん：02/11/30 12:37

>>384
ハンガリアン記法ってのは、型情報を含めることに意義があって、
特に、クラスライブラリ使うのが当然のJavaやC#において、
数文字の接頭字にこだわる理由は無いと解釈している。

そりゃあ、tempFileが厳密にはハンガリアン記法じゃないってのはわかるけど、
俺なりのJavaやC#での、現実的なハンガリアン記法の応用だと思ってくれぇ。

406 ：396：02/11/30 12:38

>>401=150
>374は temp が　*親クラスで宣言されていた* 事について文句言ってるだろ。
`File' の有無だけなら、`検索しても見つからなくて' 云々の文句は出ないだろ。

407 ：仕様書無しさん：02/11/30 12:38

意味があってやっていることを「意味が無い」って言うことがなんと簡単なことか。
「意味が無い」で説明がつくのならすべて「意味が無い」って言ってれば
すべて問題解決。

408 ：仕様書無しさん：02/11/30 12:41

実際の型をちゃんと確認するなら、極端に走らないハンガリアンならオーケーだと思うよ。

409 ：仕様書無しさん：02/11/30 12:42

ハンガリアンが結構いるみたいだから
ハンガリアンチェッカーを誰か作ってみたら？儲かるかもよ

410 ：仕様書無しさん：02/11/30 12:45

ローカル変数だと宣言部が近いんであんまり意味ないかもしれん。
構造体のメンバやクラスのメンバ変数だと助かるな。

411 ：仕様書無しさん：02/11/30 12:46

>>406
宣言部分が遠く離れていて、型名の確認に手間取ることもある。
そう言いたかった。わかりずらくてスマソ。

そのとき、tempは俺の行っていた作業には全く関係ないものだった。
tempFileって書いてあれば、完全に無視して作業できたんだが、
if (temp == null)とか書いてあるんじゃ、何が入ってるかが恐くて無視もできん。

412 ：仕様書無しさん：02/11/30 12:50

>>402
だよね。俺もUnixやDOSで開発してた頃は_ptrとかつけてたよ。
それが各自勝手にやるより規格化されたものが良いと判断したから、ウチでは導入された。

413 ：仕様書無しさん：02/11/30 13:14

>>410
昔のBASICみたいに、変数の型によって$をつけるとか%をつけるとか、
そういう文法にすればいいよ。

Rubyは(型じゃなくて)スコープでそういう記号をつけるようになってるし。

414 ：仕様書無しさん：02/11/30 13:15

413は間違えた。
>>410ではなくて>>409へ

415 ：仕様書無しさん：02/11/30 13:21

お昼休みの時間が過ぎたら潮を引くように人がいなくなった。
土曜日だというのに、みなさんお仕事中なのだろうか…

416 ：仕様書無しさん：02/11/30 14:08

>>411
> 宣言部分が遠く離れていて、型名の確認に手間取ることもある。
型名の確認ってそんなに手間がかかるものなのか。
ひょっとして、telnet越しにソースを編集してるとかそんな感じなのかな？

417 ：仕様書無しさん：02/11/30 14:19

多人数のプロジェクトだと、スキルの高いひとばかりでないから、
ハンガリアンが必要だ、という感じのことを言ってる人がいるけど、

・機能が局所化されてない
・変数名のつけ方が適切でない
・グローバル変数を多用している

こういうコーディングのまずさは、ハンガリアンを使っても、
改善されたり、マシになったりすることは無いよ。

418 ：仕様書無しさん：02/11/30 14:38

>>416
変数1～2個しか使ってないプログラムじゃないんだぞ。

419 ：仕様書無しさん：02/11/30 14:48

>359
条件を満たすファイルの数を調べるときに、

ファイル名　file_name, szFile
ファイル数　file_num, nFiles

どっちにしようが、もはや趣味の問題だと思うけどな。それさえ「ハンガリアンだから
やめとけ」というのは、もはや宗教としか。

>380
> `super' は型情報じゃなくむしろスコープに関するものだからハンガリアンじゃねーだろ。
厳密にはファイルスコープに関しても色々規程がある。っつかハンガリアンと
言っても細かく見ると流派多数なんで、「どのハンガリアンをどういう理由で
批判してるのか」を書かんと、話が収束せん。

>385
俺は Java も C# も使わんが Perl だと $nFiles とか書くことはある。書かないこと
もある。

ちなみに VCL 使うときには、マクロ定義は k, 整数レジスタは i, 浮動小数レジスタ
は v をプリフィクスにつけてる。

420 ：仕様書無しさん：02/11/30 14:49

>>418
grepとか使わないの?
(その前にコードを読むのが煩雑に感じるくらい
グローバル変数を使ってるのが問題という話は置いといて。。。)

421 ：仕様書無しさん：02/11/30 14:52

>420
せめて ctags と言ってくれ…

しかし継承が絡むと、定義箇所を見つけるのが割とめんどくさかったりする。
Java だとそれなりのコードナビゲーションやってくれるツールがあるんだけど、
C++ でお奨めってある？　（マクロが絡むとうまく動かんツールが多くて）

422 ：仕様書無しさん：02/11/30 14:58

>>419
>ファイル名　file_name, szFile
>ファイル数　file_num, nFiles

名前付けの問題とハンガリアンをごっちゃにしてるような。
ハンガリアンだったら、こういう感じでしょ。
szFileNmae
strFileNmae
nFileNum

明らかに冗長

423 ：仕様書無しさん：02/11/30 15:00

>>421
ハンガリアンだと、その問題は解消されるの?

424 ：仕様書無しさん：02/11/30 15:03

Nmae はありえんと思われ（ｗ

というのはボケとしても、実際にハンガリアンといった場合 szFileName ではなく
szFile で済ませる人も多いんじゃないかね。俺はなんちゃってハンガリアン使い
だが、型名が含まれることで「明らかに分かるよな」って場合には変数名を省略
することがある。

(この例なら、まず間違いなく szFile で済ませる）

425 ：仕様書無しさん：02/11/30 15:05

「ハンガリアンだからやめとけ」より「M$発祥だからやめとけ」のほうが説得力あったり

426 ：421：02/11/30 15:05

>423
ハンガリアンとは関係ない話題ってことで。良いツールあったら教えて下さいな。

427 ：仕様書無しさん：02/11/30 15:11

>>420
君は構造体やクラスを使うたびに、その定義を含んだファイルをgrepするのかね？
一体どれくらいの規模のプロジェクトだ？

428 ：仕様書無しさん：02/11/30 15:13

ハンガリアン必死だな。

429 ：仕様書無しさん：02/11/30 15:15

>>424
szFileよりfileNameのほうが好ましいと思うけど…

if (person.age < 12) {..

このスレのハンガリアン原理主義の人のルールだと、上のコードがこうなるようだし。

if (stPerson.nAge < 12) {..

430 ：仕様書無しさん：02/11/30 15:18

醜い見にくい

431 ：仕様書無しさん：02/11/30 15:21

すごく見やすい

432 ：仕様書無しさん：02/11/30 15:21

>>427
もしかして検索かけるのに、ルートディレクトリからやってるの?

確認作業が大変だっていうハンガリアンは、関数はどうしてんの?
関数名にも戻り値や引数の型情報をもたせて、ソースやドキュメントでの
確認を省いたりしてんの?

433 ：仕様書無しさん：02/11/30 15:23

>>429
stってなんだ？
nAgeでも醜くないと思うが。
それに単純な変数名のうちならいいがもっとややこしい名前の変数名のときに効果を発揮すると思うが？

434 ：仕様書無しさん：02/11/30 15:23

>429
> このスレのハンガリアン原理主義の人
クラスや構造体のインスタンスに対してプリフィクスを全部つける人は、さすがに
俺の周囲にはいないなぁ。クラス名は C から始める、ぐらいはあるけど。

ところで

　person.nAge

これに何か問題があるんだろうか。単に「醜い」という主観的な話？

435 ：仕様書無しさん：02/11/30 15:25

>432
ルートから検索しなくても、10万行ぐらいのプロジェクトで grep したら、定義ではなく
「使ってる場所」が山のように引っかかって見つからんと思うが。

> 確認作業が大変だっていうハンガリアンは、関数はどうしてんの?
ハンガリアンはともかく doxygen か ctags でしょ、ふつー。

436 ：仕様書無しさん：02/11/30 15:27

>>433
> stってなんだ？

このスレのハンガリアンのルール。ログ参照してください。

>>434
> これに何か問題があるんだろうか。

えーっと、その n になにか意味があるのでしょうか?

437 ：仕様書無しさん：02/11/30 15:28

>>423
そこそこの規模のプロジェクトになったら、検索場所は関係ないでしょ。

VisualStudioな人はインテリセンスがあるからね。Emacsな人はDoxygenかな。

438 ：437：02/11/30 15:29

失礼。>>423は>>432の間違い。

439 ：仕様書無しさん：02/11/30 15:31

>436
> えーっと、その n になにか意味があるのでしょうか?
おそらく「年齢が整数型で格納されている」んだろうな、とは思う。szAge とあったら
C スタイルの文字列型で格納されてるんだろうし、pszAge だとポインタなんだろうな、
と思うよ。

sz と psz の区別は、意外と役に立つよね。間違っても free(szXXX) なんてコードは
書かなくなるし。

440 ：仕様書無しさん：02/11/30 15:33

>>435
> ルートから検索しなくても、

ツールを使わないでって話でも、ディレクトリとか拡張子で
対象を絞れば簡単に見つかるとおもうけど。

441 ：仕様書無しさん：02/11/30 15:34

>440
思うのは自由だが、実際に経験あるのか？

442 ：仕様書無しさん：02/11/30 15:36

>>440のプロジェクトって、ソースファイルいくつくらいある？素朴な疑問なんだけど。

443 ：仕様書無しさん：02/11/30 15:36

>>440
はいはい。素人は黙っててね。

444 ：442：02/11/30 15:37

>>441, >>443
ｹｺｰﾝする？（ｗ

445 ：441：02/11/30 15:41

>442
ソースコード 100万行あるから偉いってわけじゃないが、小規模開発のノリで
その規模のプロジェクトに関わると死ぬよな。

小規模開発でコード書くのも一人って世界と、中・大規模開発では、自ずから
適する開発手法は変わってくる。

446 ：仕様書無しさん：02/11/30 15:44

>> 確認作業が大変だっていうハンガリアンは、関数はどうしてんの?
>ハンガリアンはともかく doxygen か ctags でしょ、ふつー。

変数ではふつーの方法は使わないの?

447 ：仕様書無しさん：02/11/30 15:54

>446
必要ならば使うが、必要なければ使わない。それだけのことだと思うぞ。

doxygen にしろ ctags にしろ、生成物を作るのにちょっと時間がかかる。だいたい
定期的に更新するか、キリの良いところ (cvs commit した直後) に手で更新する
のでタイムラグが発生する。そういうトレードオフがある。

448 ：仕様書無しさん：02/11/30 16:00

>>447
関数にハンガリアンみたいな手法を使ってないなら、
変数にも必要無いんじゃない?

449 ：仕様書無しさん：02/11/30 16:04

grepがあるからノープロブレム。grepを否定する香具師は性器表現を知らないシロート。
拡張子で絞れると思ってる香具師は、ひとつのディレクトリにファイルをなんでもかんでも
詰め込むシロート。性器表現、これ最強。

450 ：仕様書無しさん：02/11/30 16:06

>448
理屈が良く分からんが…

関数の場合は現実問題として「型情報を全部織り込むのは無理」という事実が
ある。引数一つとは限らんし、オーバーロードすることもあるし。

ただし bool を返すモノは isXXX, canXXX と名前を付けるといった命名規則は
使われてる。プリフィクスに戻り値の型情報が埋まってるというのは、ハンガリ
アンの変数名規約と同じだわな。

451 ：仕様書無しさん：02/11/30 16:10

>>449
任意の型で、tempという名の変数の宣言部分を探す正規表現を
10秒で組み上げてから言え。糞が。

452 ：450：02/11/30 16:17

あと

　nAge = person.getAge();

と書いてあったら、そりゃ getAge() は int を返すんだろうなと予想がつくって
のもあるか。

453 ：仕様書無しさん：02/11/30 16:22

>>450
> 理屈が良く分からんが…

うーん。
ハンガリアンを使う理由に、参照が大変だからというのがあったけど、
関数はそんなこと言われないから、そこはどうなんだと思っただけ。
(よく考えれば、引数は間違うとエラーになるか)

> ただし bool を返すモノは isXXX, canXXX と名前を付けるといった命名規則は

ここまでをハンガリアンと同一視すると、無いようを反映した名前付けは
ほとんどハンガリアンと同じになるよ。

454 ：仕様書無しさん：02/11/30 16:23

>>451
そんなグローバル変数つくるやつはプロジェクトにいません。

455 ：仕様書無しさん：02/11/30 16:24

> ここまでをハンガリアンと同一視すると、無いようを反映した名前付けは
> ほとんどハンガリアンと同じになるよ。
だから、批判する場合は、何を以て「ハンガリアン」というのかハッキリさせろと。

456 ：仕様書無しさん：02/11/30 16:25

>454
temp はアレだが、メンバ変数で count とか pimpl だと…

pimpl は名前で役割明確すぎか。

457 ：仕様書無しさん：02/11/30 16:26

>>453
>(よく考えれば、引数は間違うとエラーになるか)

if (person.age < 12) {...

ageが文字列だったらエラーになるけどな。

458 ：仕様書無しさん：02/11/30 16:27

>>456
メンバ変数なら、構造体のほうを検索すればいいのでは?

459 ：仕様書無しさん：02/11/30 16:28

>457
いや、その「文字列」の定義によっては暗黙の型変換が効いた上で、辞書式に
比較されてヤな結果に。

460 ：仕様書無しさん：02/11/30 16:38

>453
> 関数はそんなこと言われないから、そこはどうなんだと思っただけ。
それは使う頻度や使われ方の差だと思われ。

関数の場合は引数がいくつかあるし、まず「こういう処理がしたい」という目的が
あって関数を捜してくるのがスタートだから、まず定義なりドキュメントなりに
あたることになる。

変数の場合には、既存のコードを改修するときにスコープ内の変数を見て、
「これはこういう用途で使ってるんだな」というのを推測してコードに手を入れて
いくから、リファレンスまで遡らないことが多い。（もちろん必要なら遡るし、
グローバル変数を書き込む場合には要調査だが）

俺の場合は、こんな感じ。

461 ：仕様書無しさん：02/11/30 16:41

ハンガリアン万歳の人って、途中で型が変わったりしないの？
w -> dw とか

ハンガリアは、名前の頭に修飾文字をつけるから嫌い。

462 ：仕様書無しさん：02/11/30 16:49

> ハンガリアン万歳の人って、途中で型が変わったりしないの？
さんざん既出

……まぁ笑えない事例としては Win32 のウィンドウプロシージャの WPARAM
とかがあるが。あれは Win16 時代には WORD 型 (16bit) だったけど Win32
になって 32bit になった。悪しき事例ではあるな。

463 ：仕様書無しさん：02/11/30 17:12

>458
思うのは勝手だが、やってみたのかと

464 ：ハンガリアン至上主義：02/11/30 18:13

ハンガリアンにあらざれば人にあらず。

465 ：仕様書無しさん：02/11/30 18:16

まだ続いていいたのか・・・・

466 ：仕様書無しさん：02/11/30 18:16

人じゃなくて神ですが何か？

467 ：ハンガリアン教徒：02/11/30 18:19

もうすぐ私の娘が生まれそうなのですが
娘の名前にはどのようなプレフィックスを導入すべきでしょうか？

ハンガリアン主義の皆様、ご指導願います。

468 ：仕様書無しさん：02/11/30 18:22

>>467
fat- とか、
lowIQ- とか、

469 ：仕様書無しさん：02/11/30 18:24

timitim というのはどう？

470 ：仕様書無しさん：02/11/30 18:29

娘にか？

471 ：仕様書無しさん：02/11/30 18:31

>>469
そりゃ導入じゃなくて挿入するもんだろ

>娘の名前にはどのようなプレフィックスを導入すべきでしょうか？

472 ：　：02/11/30 18:34

moe

473 ：仕様書無しさん：02/11/30 18:36

なんか一気に下がったな。下半身の方に。

474 ：仕様書無しさん：02/11/30 18:53

myFirstChild

475 ：仕様書無しさん：02/11/30 19:06

ハングリアンage

476 ：仕様書無しさん：02/11/30 19:11

isSheYourChild

477 ：仕様書無しさん：02/11/30 19:19

>>467
kim とか paku はいかが?

478 ：ハンガリアン教徒：02/11/30 19:21

>>477
私の娘をザパニーズにする気はさらさらありません。

この邪教徒がッ！

479 ：仕様書無しさん：02/11/30 20:25

>>451
そもそも複数のファイルにまたがるようなグローバル変数を使うこと自体が間違い。

480 ：仕様書無しさん：02/11/30 20:58

グローバルのクラスは、便利なんだけどなあ。
g_SystemParam.GetDefaultFontName();
とか、邪道？

481 ：仕様書無しさん：02/11/30 21:14

>>480
プログラムに問題なければ全然いいんだよ。
コーディングだとかうるさいのは、複数人で作業して問題があるからであって、
もともと問題なかった部分までうるさく言うのは、こういう人達の生き甲斐。
そんなこと言ってる暇があったら仕事しろよな

482 ：仕様書無しさん：02/11/30 21:14

>479
それはさすがに極論過ぎ。

vim6 なんかは globals.h 作って、そこにグローバル変数宣言をまとめてるけど、
この手法が使えるのは「開発元が一つで比較的小さなプログラム」という条件が
つく。複数のモジュールに分割した上で別々の部署で並行開発してたり、ライブ
ラリを使うような場合には、なかなか難しい。

483 ：仕様書無しさん：02/11/30 21:26

>>479は学生。

484 ：仕様書無しさん：02/11/30 22:00

小学校の性教育で、自分が昔、精子だった事を知った

聞くところによると莫大な数の精子と戦ったらしい

そして最期に勝ち残ったのが俺様だという事だ

その結果得た人生が、この有り様

俺が思うに、精子たちは戦っていないのではないか

基本的には譲り合い

「・・・いえいえ、お先にどうぞ・・・」

この言葉に騙され続けたのが俺だと思う方が自然だ

・・・過去に戦った精子たち

今ごろ俺を笑っているのか

485 ：仕様書無しさん：02/11/30 22:08

>>483
いや。違うが。複数で開発してる。極論かも知れないがつくづく思うよ。

486 ：150：02/11/30 22:17

ちと出かけてた。

ハンガリアンが必要だと思ってるヤツは使ってるし、不要だと思ってる
ヤツは使ってないんだろう。
それぞれ、そういう体制で問題が出てないならそれでいいんだろう。
そんな状態で議論するのは無駄にも思えるから、ちょっと統計でも取ってみないか？
以下のＡ～Ｆに加えて、一応言語も入れよう。

Ａ．会社（仕事）・グループ開発・ハンガリアン（準拠）を採用
Ｂ．会社（仕事）・単独開発・ハンガリアン（準拠）を採用
Ｃ．会社（仕事）・グループ開発・ハンガリアン（準拠）を採用
Ｄ．会社（仕事）・単独開発・ハンガリアン（準拠）を採用
Ｅ．個人（学生or趣味）で開発・ハンガリアン（準拠）を採用
Ｆ．個人（学生or趣味）で開発・ハンガリアン（準拠）を不採用

ちなみに、折れは将来の開発体制の変更に備えてＢ。昔はＡ。
言語はC,C++

・・・新スレ立てた方が良いか？

487 ：150：02/11/30 22:18

すまん、まちがってた。

Ａ．会社（仕事）・グループ開発・ハンガリアン（準拠）を採用
Ｂ．会社（仕事）・単独開発・ハンガリアン（準拠）を採用
Ｃ．会社（仕事）・グループ開発・ハンガリアン（準拠）を不採用
Ｄ．会社（仕事）・単独開発・ハンガリアン（準拠）を不採用
Ｅ．個人（学生or趣味）で開発・ハンガリアン（準拠）を採用
Ｆ．個人（学生or趣味）で開発・ハンガリアン（準拠）を不採用

488 ：150：02/11/30 22:27

ageついでに補足。
ハンガリアン（準拠）ってのは、「型を明示的に」という意識を持って
プログラミングしているという意味でおながい。
規則がちがちのハンガリアンから、ゆるゆるのハンガリアンもあるだろう。
独自形式のハンガリアンもあるだろう。
それらは全てハンガリアンに属するものと解釈して頂きたい。

489 ：仕様書無しさん：02/11/30 22:47

AでC/C++だな。プロジェクト的には実行ファイルが1MB越えることも普通にある。

490 ：仕様書無しさん：02/11/30 23:06

>>484
自分は昔卵子だったとは考えないのですか。いや、コピペなんだろうけど。

491 ：仕様書無しさん：02/11/30 23:08

>>481
上司や先輩には、ツイてない方だな。
スーパーなヤツを見つけな。

>>150
ＡもＢも、今は主にVC++
規則だし、融通の利く形だったら必要だと思ってる。

492 ：仕様書無しさん：02/11/30 23:36

>>150
あんたの主張が一番筋が通ってる。
凡人がいっぱい集まって組織としてチカラを発揮するための標準化。

ドラえも～ん。他人のソースコードをみて、何考えて記述したかわかる
道具だしてよ～。

493 ：仕様書無しさん：02/11/30 23:58

>492
> 他人のソースコードをみて、何考えて記述したかわかる道具だしてよ～。
で、自分のソースを解読できないというオチだな。

494 ：仕様書無しさん：02/12/01 01:06

こんな統計取っても意味あるとは思えんなぁ。
グループ開発の場合、そのグループの開発規約に沿うのは当然だろ。
ハンガリアン使うグループに加わったら、いくらハンガリアンが嫌でもハンガリアン使うさ。

495 ：仕様書無しさん：02/12/01 01:26

> 凡人がいっぱい集まって組織としてチカラを発揮するための標準化。

なんでも標準化すればいいってものでもないよ。
ハンガリアンなんて、規則のための規則にすぎないよ。

496 ：仕様書無しさん：02/12/01 06:20

中国語のローマ字表記でなければこれでよし。

497 ：仕様書無しさん：02/12/01 09:29

>>495
> 規則のための規則にすぎないよ。
どういう意味ですか？ただの言葉遊びですか？

498 ：仕様書無しさん：02/12/01 10:14

自己目的化と言いたいのか？極論な気もするが。

499 ：仕様書無しさん：02/12/01 10:45

>>492
はい、タイムまし～ん！！

500 ：仕様書無しさん：02/12/01 10:51

ここは、

http://pc.2ch.net/test/read.cgi/prog/1027063848/l50
グローバル変数撲滅委員会

の2スレ目でつか？

501 ：仕様書無しさん：02/12/01 10:55

規則は偉大なる目的のために作られ、人は喜んだ。
しかしやがて、人は目的を忘れ、規則そのものを目的とするようになった。
プリフィクス式の伝統的ハンガリアン記法も、またその道をたどるのだろうか。
その偉大なる型明示という目的のため、JavaやC#のクラスライブラリにも利用できるように、記法を拡張する勇者は現われないのだろうか。

502 ：仕様書無しさん：02/12/01 10:57

>>492
はい、スモールらいと～！！！

503 ：仕様書無しさん：02/12/01 11:02

半狩り案使う間抜けが後を絶たんのは何故だ…

504 ：仕様書無しさん：02/12/01 11:04

>>492
ハイ、あんきパン～！

全ソース暗記しる！他人の分もな。

…腹こわせや。

505 ：仕様書無しさん：02/12/01 11:09

>>502
なぜスモールライトなのか説明しなさい
ドラえもん壊れたのか？

506 ：仕様書無しさん：02/12/01 11:14

；まじで？

507 ：仕様書無しさん：02/12/01 11:17

>>505
(1)小さくなって逃げる
(2)Sヨを小さくして踏み潰して川に流す
(3)クライアントを小さくして踏み潰して山に捨てる

どれかだな（ｗ

508 ：仕様書無しさん：02/12/01 11:29

>>492
はい、デスマーチ！

509 ：仕様書無しさん：02/12/01 11:32

>>508
はい、増えるミラー！

510 ：仕様書無しさん：02/12/01 11:36

>>509
増やすなヨ（ｗ

511 ：仕様書無しさん：02/12/01 11:39

はんがりあんによる、ドラえもんとのび太の漫才スレはここでつか？

512 ：仕様書無しさん：02/12/01 11:45

変数はよくわかりませんが、変態！とはよくいわれまふ。

513 ：150：02/12/01 11:58

>>492
さんくす。
と、何気にネタもありがとう。ってもスレ主でもないけど。

>>494
統計取ったら、グループ開発している場合はハンガリアンを採用している
事が多いんじゃないかと思ったのよ。
おまいが言ってることは当然の事だが、実はほとんどの開発グループでは
ハンガリアンを採用しているって結果が出たらどう考える？
その逆の結果がでても、ハンガリアン採用組に与える影響もなかなかの
ものじゃないかな？

で、今のところハンガリアン優勢。
なお、例えばＡとＢの両方を現在進行形で行っている場合は、ＡＢという
ことでカウントしておこう。
Ａ＝１
Ｂ＝１
ＡＢ＝１

あと言語のVC++はC/C++に加えまつ。

言語
C/C++＝３

514 ：仕様書無しさん：02/12/01 12:06

どこにでも逝けや！ドア～！

でどっかに飛ばしてくれ。
休日のしごとキライ！

515 ：494ではないが：02/12/01 12:28

>>513
ここで統計とったって数学的に意味がないような…。
母集団が明らかでないし、ここにカキコされたデータが
良い標本になりえるとは思えないよ。

516 ：仕様書無しさん：02/12/01 13:41

ここは、

http://pc.2ch.net/test/read.cgi/prog/1035116552/
【設計書は】ドキュメント【ソース】

の穴兄弟スレでつか？

517 ：仕様書無しさん：02/12/01 17:48

他人のソース見るときには
「翻訳こんにゃく」が必要では？

518 ：494 じゃないが：02/12/01 17:50

>>513
> 実はほとんどの開発グループでは
> ハンガリアンを採用しているって結果が出たらどう考える？
「バカばっか」

519 ：仕様書無しさん：02/12/01 17:54

>>518 必死だな

520 ：仕様書無しさん：02/12/01 17:54

“自分以外みんなバカ”病にかかってるヤツは、手に負えん。

521 ：仕様書無しさん：02/12/01 18:05

>>519-520
お互い様。

522 ：仕様書無しさん：02/12/01 18:09

なして、C/C++ の時だけハンガリアン使うの?

523 ：仕様書無しさん：02/12/01 18:15

こんなスレだけで統計とれると思ってる奴がいるとは…

524 ：仕様書無しさん：02/12/01 18:32

>522
そりゃあ、ハードに強く制約された「int 型」とか「0 で終わってる char 配列」なんて
プリミティブな型と相対せにゃならんから。

高度に抽象化された「型」や「そもそも型がない言語」を相手にする場合には、そん
な制約は忘れ去って構わんでしょ。ハンガリアンといっても、C, C++ で構造体やク
ラスのインスタンスに対してプリフィクスを使うヤツは少数だしさ。

っつか、何でハンガリアンがそれほど嫌われるのか謎だな。

u_int64* dma_header_ptr;
u_int64* pDmaHeader;

どっちだって、統一されてりゃ構わんと思うけどな。どっちに統一するかは趣味の
問題だが、広まってるのが後者だからそれに合わせておくかって話だろ？

525 ：仕様書無しさん：02/12/01 18:37

>>524
変数名に型情報含めないといけない程、その変数のスコープは広いのか？

526 ：仕様書無しさん：02/12/01 18:45

>>525
クラスや構造体だと定義している場所まで遠いからね。

527 ：仕様書無しさん：02/12/01 19:10

>525
メンバ変数だから、変数を利用してる部分を見てる場合には、定義部分は
画面内に収まってないよ。

もう少しぐらい的な話をしよか。たとえば、次のような DMA パケットをいくつか
作るとしよう。ヘッダは 64 バイト境界にアライメントされている必要があり、ヘッダ
中にそのパケットに含まれるデータの数を書き込む必要があるとする。

　+-------------+ <- ここが 64byte 境界
　| DMA Header.　 |　この中に DMA Packet に含まれる DMA Data 数が書いてある
　| 　　　　　　　　　.|
　+-------------+
　| DMA Data　　　.|
　+-------------+
　| DMA Data　　　.|
　+-------------+
　| padding　　　　 |
　| 　　　　　　　　　.|
　+-------------+ <- ここが 64byte 境界

DMA Packet を作り始める段階で DMA Data 数を確定するのはめんどいので、
最初は DMA Header の中には「Data 数 0」と書いておいて、途中で DMA Data
を追加した数を覚えておき、DMA Packet を Close するときに DMA Header を
更新すると決めた。利用例は、次のようになる。

DMAPacket pk;
pk.Open(転送先チャネルとか優先度とか色々);
pk.Add(data1);
pk.Add(data2);
pk.Close();　　　// <- ここで DMA Header に Data 数 2 を書き込む

528 ：仕様書無しさん：02/12/01 19:14

俺ならこんなコードを書くところだ。pDmaHeader という名前は、それほど
マズイか？　もし dma_header_ptr だの pDmaHeader だのが「ダサい」というなら、
どんな名前をつけるか聞いてみたいトコロだが。

// クラス定義
class DMAPacket {
　　u_int64* pDmaHeader;　// 現在の DMA パケットのヘッダ
　　u_int32* pCurrent;　　// 現在の DMA パケットの末尾
...
};

// 実装
void DMAPacket::Close() {
　　if (pDmaHeader != NULL) {
　　　　intptr_t len = (intptr_t)(pCurrent - (u_int32*)pDmaHeader - 1);
　　　　assert(len < MAXPACKLEN);
　　　　*pDmaHeader |= (len << 4);
　　}
　　pDmaHeader = NULL;
　　// padding
　　while (reinterpret_cast<intptr_t>(pCurrent) & 0x3f)
　　　　*pCurrent++ = 0;
}

529 ：仕様書無しさん：02/12/01 19:37

クラスや構造体には、プレフィックスつけないのに、
プリミティブな型にはつけるとか言ってる奴は、本質的なところで
分かってないだろ。

530 ：仕様書無しさん：02/12/01 19:41

つか、このスレ見て「定義箇所が遠い==グローバル変数」な奴が多くて驚いたよ。
クラス定義や構造体定義はいったいどうしているんだろう。

531 ：仕様書無しさん：02/12/01 19:43

>>529
プリミティブしか使えないんだろう

532 ：仕様書無しさん：02/12/01 19:46

>>530
何でもかんでも変数渡しなんだろうな。

533 ：仕様書無しさん：02/12/01 19:59

>>527
> メンバ変数だから、変数を利用してる部分を見てる場合には、定義部分は
> 画面内に収まってないよ。
当たり前。ふつー別ファイルだわな。
けどさ、ターミナルエミュレータのウィンドウ一枚で編集してるんでもない限り
それらは同時に見えるだろ？

>>528
別に中身なんてどうでもいいのに、その短さで3箇所もキャストした恥ずかしいコードを
態々晒してくれて有難う。

534 ：仕様書無しさん：02/12/01 20:08

複数ファイルを参照可能なことと、スコープの広さに何の関係があるのかと子一時間。

535 ：仕様書無しさん：02/12/01 20:10

>>534
さあ？>>525に聞いて味噌

536 ：仕様書無しさん：02/12/01 20:20

>533
> 別に中身なんてどうでもいいのに、その短さで3箇所もキャストした恥ずかしいコードを
> 態々晒してくれて有難う。
読めなかったら、素直にそう言えば良いのに。

ハードよりで効率的なコードを書こうとすると、どうしてもキャストは必要になる。
特に上に書いた DMA パケットだと、ヘッダは 64bit データは 32bit だったりする
わけで。

（全部 union 定義しても良いんだが、却ってダサいコードになりがち）

537 ：仕様書無しさん：02/12/01 20:21

>529
本質って何ですか（ｗ

538 ：仕様書無しさん：02/12/01 20:28

>>537
「本質」も知らないの？(W。小学校からやり直せば。

539 ：仕様書無しさん：02/12/01 20:33

コードが出てきたら、とたんに抽象論になったな。何なんだか。

540 ：仕様書無しさん：02/12/01 20:36

だね。だれか>>528の疑問に答えてあげればいいのにな。

541 ：仕様書無しさん：02/12/01 21:19

>533
キャストを使わずに、アライメント処理をどう書くつもりなんだ？　コード出してみ。

542 ：仕様書無しさん：02/12/01 21:23

単純に「DmaHeader」とかじゃ駄目なの？
コーディングする時って、どのみち変数とかの
定義は見るから変数名に型情報含めなくても
いいと思うんだけど・・・・

543 ：仕様書無しさん：02/12/01 21:29

最近の統合環境なら変数の定義を調べるくらい簡単だろ。
そういう機能がなかった頃の名残だろ。

544 ：仕様書無しさん：02/12/01 21:37

ハンガリアンって、いかに人間が教条主義に陥りやすいかの見本だな。
あんなもんCが型チェックが弱かったころの技法だろ。
MSのサンプルなんて32bit向けのコードでも、平気でlpとかプレフィックス
つけてたりするもんな。

545 ：150：02/12/01 21:42

>>515
何もこんな所で統計って言った所で、検証してハンガリアン論争を
終わらせられるなんて大層なことは思ってないよ。
少なくともここに参加しているヤツらの情報をまとめるだけでも、
このスレの話がちっとはマシなると思わんか？

折れの過去書き込みに反論するヤツらっつーのは、俺様ﾏﾝｾｰで視野の
狭いヤツらが多いからな。
真っ向から筋の通った反論出来ずに、なんにしても「不要だろ～」以外に
言うことしか出来てないし。
話がループしてたし。

なら、おまいらの立場・状況をはっきりさせた方がいいだろ。ってことで。

546 ：仕様書無しさん：02/12/01 21:49

>>545
このスレでがんばってる粘着って、数人程度だろ。

547 ：仕様書無しさん：02/12/01 21:49

>>545
> 折れの過去書き込みに反論するヤツらっつーのは、俺様ﾏﾝｾｰで視野の
> 狭いヤツらが多いからな。

自分のことは棚にあげて何を言う

548 ：仕様書無しさん：02/12/01 21:58

>>544
完璧な型チェックとは同バイト数の型でも型名が違えばエラーにしてくれること？

549 ：仕様書無しさん：02/12/01 22:00

>>534
いや、変数名の頭に“p”付ける阿呆にありがちな、最長不到関数でも
書いてるのかと思ってさ。そしたらメンバ変数にまで付けてるっつーんだもの。

550 ：仕様書無しさん：02/12/01 22:04

最長不到変数ってのがあったりして

551 ：150：02/12/01 22:04

>>546
それならそれで、それが検証できただけで折れ的には収穫だな。

>>547
どれのこと？このスレに関しては頑張って書いてきたつもりだが。
折れの書き込みに対する反論がどこにあるか教えてくれ。
見逃しかも知れんし。

552 ：仕様書無しさん：02/12/01 22:39

>>524=527=528
u_int64* pDmaHeader;
u_int32* pCurrent;

ポインタに p つけるくらいなら別にいいよ。
でもハンガリアンズなら

u_int64* puqwDmaHeader;
u_int32* punCurrent;

ってな感じになるんじゃない?
pはポインタ
uはunsigned
qwは64bit
nは数値

553 ：仕様書無しさん：02/12/01 22:42

ハンガリアンのデメリットって

a)実際の型の確認を怠る危険がある
b)見ずらい、読みずらい　　(これは逆の立場もありえるから慣れの問題かな)

ってのがあると思うけど、じゃあハンガリアンのメリットって何?

554 ：仕様書無しさん：02/12/01 22:55

ぶっちゃけ>>544の
>あんなもんCが型チェックが弱かったころの技法だろ。
が真理だと思われ。

てかそれが通説と違うんか？

555 ：150：02/12/01 23:01

>>530
> クラス定義や構造体定義はいったいどうしているんだろう。
それら定義しているのが別ファイルなら、わざわざそのファイルを開く
必要が出てきたら面倒だわな。

>>543
逆に、統合環境を使わなければ分からない訳ですが。

>>544
型チェックが必要なのは引数だけではなく、複数型変数を織り交ぜた
計算式中にも必要だろう。
暗黙的な型変換、暗黙的な型変換やキャストによる符号拡張によって
意図した計算結果が出ないこともある。
これを防ぐにはスキルの上昇に加えて、他にハンガリアンなどの工夫も
有効だと思われるが？
最近の言語・コンパイラって、こんな心配は無用なのか？

>>553
過去ログ嫁

556 ：八千代市民：02/12/01 23:07

以前に、無限増殖する変数名を管理し切れなくなって、
「変数名ジェネレータ」なるツールを後輩に作らせた
事があった。その効果は、俺プログラミング出来ないから
チェックしていなかったが、PG共がどうも文句言いたげだった。
聞いてみると、こりゃひどい。
早速ツール作った後輩を問い詰めたところ、なーんと、乱数を
ASCII変換して一文字ずつ当てはめていたそうだ。
ま、生成変数の一覧リストも同時出力されていたから、実務上
弊害は無いと、俺の権限で使用続行とした。

外注PGの人の出入りが早いのは、うちの仕事と縁を切るに切れない
その経営体質にも問題があると思われ。

557 ：仕様書無しさん：02/12/01 23:09

では、最新の記法ほどのようなものが？

558 ：554：02/12/01 23:11

>>557
ん？俺に聞いてんの？

559 ：仕様書無しさん：02/12/01 23:48

Perlみたいに言語仕様に型を表す記号を組み込んだものと何が違う？

560 ：仕様書無しさん：02/12/02 00:10

…で「統計」はどうなったよ（ｗ
もう終わりか？
俺はコボラだから、はんがりあんはパス（ｗ

561 ：仕様書無しさん：02/12/02 00:14

バリアントで全て解決。VBﾏﾝｾｰ

562 ：仕様書無しさん：02/12/02 00:18

>>560
変なおじさんﾊｹｰﾝ

563 ：仕様書無しさん：02/12/02 00:23

「なに、モンゴリアン記法だと」
「知ってるのか、雷電」

564 ：仕様書無しさん：02/12/02 00:55

変数名に型情報埋め込むの？半狩り安？
そんなことするくらいなら、見なきゃいけない範囲を狭くしる。
オブジェクト分割なり構造化なりしたほうが、よほど良いかと思われ。

自動変数ならまだしも、データメンバに意味不明な名前つけると
3年後の自分が意味わからんし。3年後はそのソースから逃げてるとか言うな。

565 ：仕様書無しさん：02/12/02 01:02

またループか・・・。

566 ：仕様書無しさん：02/12/02 01:05

1038306623番台、3回目のループに入りました！おめでとうございます！

567 ：仕様書無しさん：02/12/02 01:07

Unix系のオープンソースのプロジェクトは、大多数がハンガリアンなんて
使ってないよ。
彼らはハンガリアンを知らないわけじゃなくて、ハンガリアンを知っていて
その上で使わないわけよ。

568 ：すぷーん ◆spoonLv.3M ：02/12/02 01:12

漏れはハンガリアンを使ってるよ。

(慣れれば)努力無しでささやかなシヤワセを掴めるのに。。。

569 ：仕様書無しさん：02/12/02 01:17

Windowsでプログラムを憶えたので、初心者のころはハンガリアンを
使ってましたが、タイプ量が増えるだけで何の効能もないと気づいた
ので、最近は使ってません。

570 ：すぷーん ◆spoonLv.3M ：02/12/02 01:24

>>569
タイプ量が増えることを気にするほど、忙しい仕事をしてるんですね。
ご愁傷様です。

571 ：仕様書無しさん：02/12/02 01:27

うちの会社ではハンガリアン使うと
単調なプログラムを書きがちなので使うのやめますた。
まだ使ってるとこあるんですね。

572 ：仕様書無しさん：02/12/02 01:31

>>570
無意味にタイプ量を増やすほどヒマではありません。

573 ：仕様書無しさん：02/12/02 01:34

ここの所のハンガリアンを否定する人達って理由がｵｺｻﾏですね。

574 ：仕様書無しさん：02/12/02 01:36

ハンガリアンを薦める人って「シヤワセを掴める」とか理由が宗教がかってますね。

575 ：571：02/12/02 01:36

>>573
ｵｺｻﾏとは酷い言い様ですね。

「使うのやめた」の部分から導入して良し悪しを見極めた上で
発言していることがわからないのですか？

576 ：仕様書無しさん：02/12/02 01:38

善し悪しを列挙汁

577 ：仕様書無しさん：02/12/02 01:50

良い点
・自然と常に型を意識するようになるため、
　型変換が原因で発生する問題が減る。
　（特に型変換をあまり意識しない新人に有用）
・変数名に型情報が付加されることにより
　プログラムの見通しが良くなる。

悪い点
・複数のクラスライブラリ／フレームワークを
　利用した場合の型（クラス）名の爆発的な増加により
　規約が複雑化する。
・パターン・リファクタリング等によってOOPを学ぶ環境が向上し
　逆にクラス設計の粒度によって視野を切り替えることのできる
　開発者が増えたため、ハンガリアンが逆に邪魔になり始めた。

急いで書いたからめちゃくちゃだけど、
うちの会社ではこんな感じ

578 ：すぷーん ◆spoonLv.3M ：02/12/02 01:52

すんまソン。
ハンガリアンを使いたく無い人は使わなければいいだけだと思われ。
使えと強要するつもりもない。

でも、漏れは使った方が経験上良いような気がする。
慣れれば空気を吸ってるのと同じ自然体で、
なおかつご利益があるんんだから使わない手は無いと思われ。

579 ：571=577：02/12/02 02:01

>クラス設計の粒度
→オブジェクトの粒度

あと悪い点書いたつもりが辞めた理由書いてるし…

ほんとめちゃくちゃだ。ごめん。

580 ：仕様書無しさん：02/12/02 02:06

情報キボン
【うざい】八千代市民(=リアル厨房)を晒すスレ【コテハン】
http://pc.2ch.net/test/read.cgi/prog/1038753020/l50

581 ：150：02/12/02 02:11

>>567
なんで？

>>579
>571の理由のままだと単なるアンチハンガリアンとしか思えないが、
>577くらいのしっかりした事が書けるなら良いんじゃない？
ちゅーか、おまいはハンガリアンを否定してる訳じゃないんでしょ？

582 ：仕様書無しさん：02/12/02 02:21

>>150
うん。ハンガリアン記法には良いところもあると思ってる。
只ね、あなたがC++でハンガリアンを推してるのが俺には許せないのよ。

object-orientedやgenerativeなプログラミング等、
色々な角度からソフトウェアを見る方法が沢山あって
今なら新人でも学ぶための訳書は沢山あるわけでしょ。

なのに何故今更、型を強く意識する手法を推すの？

583 ：150：02/12/02 02:34

>>582
いや、折れも別に強制してないよ。前に書いたけど、使わなくても問題ない
ならそれで良いし。
ただ必要な場面もあるだろうから、ハンガリアンを完全否定してしまってる
輩には反対なのよ。
C++でも>555で書いた>544宛レスみたいな現象に出会うこともあろうし、
WinAPIをガンガン叩くなら、やはり型は意識するだろ？

んでね、言語や開発体制でハンガリアンの重要度も違うだろうし、そうなると
一概にどうすれば正しい道なのか判断付かないだろうから、とりあえず
統計っちゅーことも口走ってたのだよな。

584 ：仕様書無しさん：02/12/02 02:48

>>150
そうか。あんたは別にハンガリアン狂信者ってわけじゃないんだな。
俺は煽りへのレスとか見て勝手に脳内で膨張してあんたを誤解してたみたい。

>>571はひでえ言い方だった。今酔っててさ。
ごめんな。

585 ：仕様書無しさん：02/12/02 06:01

>582
> なのに何故今更、型を強く意識する手法を推すの？
型を強く意識せざるを得ないプログラムを書いてるから。DirectX にせよ
PlayStation 2 にせよ、型と無縁でいられるほど抽象度が高いプログラム
の世界にはいないし

（double と float 間違えるだけでてきめんにパフォーマンス落ちる世界だ
し、アライメント間違えると実行時に止まるし）

586 ：585：02/12/02 06:02

もちろんデザインパターンなんかは有効に使わせてもらってるし、そういう
由来のクラスにはハンガリアン使わんですよ。

587 ：仕様書無しさん：02/12/02 06:55

>542
> 単純に「DmaHeader」とかじゃ駄目なの？
それだとヘッダを「値」として持っているのか、それともヘッダ領域へのポインタとして
持っているかが一目では分からないのが難だ。DMA パケットライブラリといっても、
実装方法は何通りもあって、たとえば

o DMA Header を値として覚えておく
o DMA Data は連続したメモリブロックに書いてあると仮定して、ライブラリでは
　そこへのポインタを記憶しておく
o DMA 転送中に FIFO に DMA Data を埋めていく

なんてケースもある。一目見て「で、どっちよ？」というのが分かった方が俺は嬉しい
けどね。

> どのみち変数とかの定義は見るから
これも現実的には、難しいよ。いくら機能分割がうまくなされている場合でも、
使っているすべての変数・関数について定義まで遡っていたら、日が暮れて
しまう。

それと「無関係なものだと、人間が一度に覚えられるのは平均 7 つ」というのは
心理学でよく知られた事実で、変数の型なんてのはそうそう覚えられない。名前
に型情報というヒントを埋めるのは、この 7 つの壁を打ち破る一つの手段だと思
うよ。
（もちろん「名前」だけで十分な情報が埋まってる場合には、不要だけど）

>552
> でもハンガリアンズなら
そんなやつは 552 の脳内にしか居ません…

588 ：仕様書無しさん：02/12/02 07:28

>>556をネタだと思って放置してるみたいだけど
ここを読んだらマジだってことがわかるよ。
http://pc.2ch.net/test/read.cgi/prog/1038753020/l50

589 ：仕様書無しさん：02/12/02 09:41

>>567
なぜが知りたければ、歴史を勉強しよう！

590 ：仕様書無しさん：02/12/02 10:56

どーこからきーたのかハンガリアーン

591 ：仕様書無しさん：02/12/02 12:17

先頭は絶対小文字だろが
どうしても大文字にするならDMAHeader

592 ：仕様書無しさん：02/12/02 12:50

　　　　　　　　　　　　　　　　＼　│　／
　　　　　　　　　　　　　　　　　／￣＼　　／￣￣￣￣￣￣￣￣￣
　　　　　　　　　　　　　　　─（ﾟ ∀ ﾟ）＜　はんがりあん！
　　　　　　　　　　　　　　　　　＼＿／　　＼＿＿＿＿＿＿＿＿＿
　　　　　　　　　　　　　　　　／　│　＼
　　　　　　　　　　　　　　　　　　　 ∩ ∧　∧　　／￣￣￣￣￣￣￣￣￣￣
￣￣￣￣￣￣￣￣＼∩ ∧　∧　＼（ﾟ∀ﾟ）＜　はんがりあんはんがりあん！
はんがりあん～～！＞（ﾟ∀ﾟ）/ ｜　　　　/　＼＿＿＿＿＿＿＿＿＿＿
＿＿＿＿＿＿＿＿／｜　　　〈　｜　　　｜
　　　　　　　　　　　　　 /　／＼_」　/　／＼」
　　　　　　　　　　　　　￣　　　　 / ／

593 ：仕様書無しさん：02/12/02 20:32

age

594 ：仕様書無しさん：02/12/02 20:52

>567
で、あなた自身の見解はどうなんですか？　虎の威を借っても仕方ないでしょ。

俺はフリーの UNIX の開発にも関わってるけど、そっちではハンガリアンは
使わない。既存のコードが別のスタイルで書いてあるから、そこに異色のス
タイルを持ち込むと混乱するから。

UNIX だと型名を変数に含めるってのはポインタの p ぐらいなもんだが、代
わりに「お約束の変数名」みたいな、明文化されてないけどみんなが合意し
ている「命名規約っぽいもの」は存在してる。

e.g.　fd, fp, pid, s, sin, tm, ...
どれも名前見て、型が一発で分かるでしょ。

なんで UNIX と Win32 で命名規約が違うか考えてみたんだが、結局は
「今までのコードがそうなってる」っつーのが大きいんじゃないのかね。

Win32 でプログラム書く場合には MSDN Library や Platform SDK から
サンプルコードを引っ張ってくるのがスタートだし、UNIX だってライブラリ
のソースなり「UNIX ネットワークプログラミング」なりから引っ張ってくる
ことが多いわけで、どうしても影響を受けるよね。あとは標準ライブラリの
シンボル、特に構造体要素の名前は自分のコードにも多々出てくるし。

595 ：仕様書無しさん：02/12/02 22:08

2ch でチンコリアン記法つくろうYO!

596 ：仕様書無しさん：02/12/02 22:09

>>594
まぁ結局は慣れだわなぁ。

597 ：仕様書無しさん：02/12/02 22:13

>>594
「虎の威を借っても」っていうけどさぁ、名無しの一人が主張するよりは
説得力出てくるだろ。
おまえ何か悪いもんでも喰ったのか？

598 ：一階級上のプログラマ：02/12/02 22:30

オマエラまだ変数なんて使ってんの？フフ

599 ：仕様書無しさん：02/12/02 22:42

>>561
ウチの会社の方でつか？
型宣言してくださいって言われたでしょ？

600 ：仕様書無しさん：02/12/02 22:44

>598
階が上がって高階関数、という寒いギャグでしょうか？

601 ：仕様書無しさん：02/12/02 23:05

>>594
>なんで UNIX と Win32 で命名規約が違うか考えてみたんだが、結局は
>「今までのコードがそうなってる」っつーのが大きいんじゃないのかね。

ハンガリアンが役に立つようなことを言ってても、本当はこの程度の理由なんじゃないの?
単に周囲にあわせてるだけ。

602 ：仕様書無しさん：02/12/02 23:10

>601
まぁ UNIX で socket s と書くのと同程度には役に立つわな。

あと、周囲に合わせることは、それだけで十分な意味があると思うぞ。どっちでも
良いけど、ともかく合わせておくと便利だということは世の中沢山ある。アナログ
時計の回転方向とか、電話機の番号配置とかさ。

603 ：仕様書無しさん：02/12/02 23:35

>>602
そういうのと性質がちがうだろ。

サブルーチンの名前付けの規則が「コード+番号」となってる会社っていうのを
聞いたことがあるんだよ。
ARDF0012
↑こういう感じなるの。
大昔のCOBOLでそうやってたからって理由で、Cでもおんなじ規則でやってるの。

ハンガリアンってコレに近いものを感じるぞ。

604 ：仕様書無しさん：02/12/02 23:42

要するに、「惰性」だな

605 ：仕様書無しさん：02/12/02 23:42

>603
> ハンガリアンってコレに近いものを感じるぞ。
どこがだ？

(1) p_dma_head
(2) dma_header_ptr
(3) pDmaHeader
(4) m_pDmaHeader

いずれにせよ「DMA ヘッダ領域へのポインタなんだな」と分かるが ARDF0012
じゃあ何の処理するサブルーチンなのかサッパリだろう。

で (1), (2), (3), (4) 混ぜると見にくいし、コードに手を入れるときも「このクラスは
どの命名規約使ってたんだ？」と迷うことになるから、じゃあ (4) にしとくかって
話だろ。

606 ：仕様書無しさん：02/12/02 23:45

>>605
なにピントのずれたこと言ってんだよ。

607 ：528：02/12/02 23:45

528 への対案は出てこないのか。
誰か *BSD っぽく書き直してくれることを期待してたんだが。

608 ：仕様書無しさん：02/12/02 23:49

>604
惰性だと聞こえが悪いから、歴史にしとけ。

609 ：仕様書無しさん：02/12/03 02:29

おまいらの言いたいことは大体わかった！拘ってるんだな？
で、ハンガリアンは環境によって向き不向きがあるので、使う使わないは
TPOに合わせると言うことでよろしいでつか？

したら、もっとこう個人的なこだわりが聞くたいぞｺﾞﾙｧ。
必ず惚れた女のイニシャルをめり込ますとか、人体の部位を名前に割り当てる
とかそんな香具師はいねがぁ？

えと…1でもないのに勝手に進めていいのだろうか…。

610 ：仕様書無しさん：02/12/03 13:20

>>605
おまいの書いてる

(1) p_dma_head
(2) dma_header_ptr
(3) pDmaHeader
(4) m_pDmaHeader

はどれもハンガリアンじゃないぞ。
ハンガリアンなら 64bit とか 32bit っていう情報もちゃんと持たせろYo！

611 ：仕様書無しさん：02/12/03 18:21

age

612 ：仕様書無しさん：02/12/03 18:45

>610
> ハンガリアンなら 64bit とか 32bit っていう情報もちゃんと持たせろYo！
そこまで詳細に書くかは、ケースバイケースっつーのが、俺の見た範囲だと多いな。

っつーか m_XXX だの nXXX だの dwXXX ぐらいなら許容範囲なワケ？　それなら
最初から争点はなかったことになるが（ｗ

613 ：仕様書無しさん：02/12/03 18:53

ハンガリアンってintとlong、floatとdoubleのように、同じ種類だけど
それを表現するビット長を区別するプリフィックスをつけるということなんだね。

614 ：仕様書無しさん：02/12/03 19:06

アレをフル導入している例は少ないだろ。フル導入がﾀﾞﾒだから
完全否定つうのも妙な話し。

615 ：仕様書無しさん：02/12/03 19:10

ある型が何bitかなんて決まってないのに変数名にそんな情報まで持たせるのか？
移植性なんて考えてないのか？

616 ：仕様書無しさん：02/12/03 19:31

>615
> 移植性なんて考えてないのか？
そもそも移植性がない or 必要とされないコードもあるわけで。

Win32 のウィンドウプロシージャの引数とか、PS2 の DMA パケットのアライメント
とか、そんなところに「汎用性」なんて持ち込んでも仕方ない。せいぜい typdef し
て定数を #define, enum あるいは const 変数で持たせて、名前を付けて見やすく
するのが精一杯。

617 ：仕様書無しさん：02/12/03 19:44

>613
実際には、それに限らず

　h　　　ハンドル
　p　　　ポインタ　(Win32 だと lp が使われる場合もある)
　n　　　整数
　u　　　符号なし整数
　f　　　単精度浮動小数点
　d　　　倍精度浮動小数点
　b　　　ブール
　c　　　文字
　wc　　ワイド文字
　sz　　'\0'終端文字列
　wsz　L'\0' 終端ワイド文字列
　str　文字列 (CString か std::string)
　bstr　COM で使う文字列
　w　　　WORD 型 (Win32 の 16bit 符号なし整数)
　dw　　DWORD 型 (Win32 の 32bit 符号なし整数)

ぐらいから、適宜取捨選択って感じだと思うが。変数スコープに関しては

　g_　　グローバル
　s_　　static (ファイル内のみ可視)
　m_　メンバ

あたりを良く見かける。

618 ：仕様書無しさん：02/12/03 20:17

>>617
>>610にはpやm_はハンガリアンではないと書いてあるが。
統一しろ。

619 ：仕様書無しさん：02/12/03 21:51

h: ハンガリアン
p: セーフ
n: ハンガリアン
u: ハンガリアン
f: ハンガリアン
d: ハンガリアン
b: ハンガリアン(ぎりぎりセーフ？)
c: ハンガリアン
wc: ハンガリアン
sz: ハンガリアン
wsz: ハンガリアン
str: ハンガリアン
bstr: ハンガリアン
w: ハンガリアン
dw: ハンガリアン

620 ：仕様書無しさん：02/12/03 22:00

まだやってんのかよー。

621 ：仕様書無しさん：02/12/04 08:44

半下痢嫌ん

622 ：仕様書無しさん：02/12/04 09:10

よっこいしょ

623 ：bloom：02/12/04 09:28

http://www.agemasukudasai.com/bloom/

624 ：仕様書無しさん：02/12/04 10:42

>>619
ビット情報をもたないstrやszがなぜハンガリアンになるのか？
つーかほとんどのものがビット情報をもたない気もするが。

625 ：仕様書無しさん：02/12/04 13:02

>>617
前に出向した職場では、先輩が教育せず新人が勉強せずのため
　「pを頭につけるとポインタになる」
という解釈をしていた新人がいっぱいいたっけなあ・・・

int pI;

「なんでこれポインタにならないんでしょう？」

626 ：619：02/12/04 15:43

>>624
持つのはビット情報じゃなく型情報だよ。

>610のﾔｼは64bit、32bitという情報と言ってるが、
ビット情報じゃなく、64bit整数、32bit整数という整数型の情報を持たせろ
と言いたかったんだろう。(w, dwみたくな)

まぁ、単にハンガリアンの事知らない厨房なのかもしれんが(w

627 ：Linus：02/12/04 16:46

関数の型を関数名に含める方式（通称ハンガリー方式）なんて使う連中もどう
かしてる。そんなことをしなくてもコンパイラは型を知っているし、型チェッ
クもできる。結局はプログラマ自身を混乱させるのがおち。Microsoft が不安
定なプログラムを作っているのもうなずけるよね。

628 ：Linus：02/12/04 16:48

http://www.linux.or.jp/JF/JFdocs/kernel-docs-2.2/CodingStyle.html

629 ：仕様書無しさん：02/12/04 17:07

>>627
型を知りたいのはコンパイラじゃなくて人間なんだがねぇ。
MSが嫌いな人間に正常な判断は期待できないね。
まあLinusが好きでタブは8文字で括弧の位置や大文字小文字を混ぜた名前を
つけないとかに全部賛成ならLinusにしたがうのもいいんじゃない。

630 ：仕様書無しさん：02/12/04 17:09

>>626
でpはハンガリアンなの？

631 ：仕様書無しさん：02/12/04 17:13

コリアン記法で。

632 ：仕様書無しさん：02/12/04 17:27

正直、型が分からなくなるほどのスコープを持つ変数を作りたくない。

633 ：仕様書無しさん：02/12/04 17:34

>>632
構造体やクラスはスコープが狭くても(メンバの)型は分からない。

634 ：仕様書無しさん：02/12/04 18:40

いつまでもやってろ

635 ：仕様書無しさん：02/12/04 19:09

>634
言われるまでもなく、続けたいヤツは続けると思われ。

636 ：仕様書無しさん：02/12/04 19:14

sage進行でやってね

637 ：仕様書無しさん：02/12/04 19:31

>>636
ん？

638 ：仕様書無しさん：02/12/04 19:52

かんぶりあん～

639 ：仕様書無しさん：02/12/04 20:48

名前を見てメンバなのかポインタなのか分かるということはとても重要な事。
これはとりもなおさずオープンなソースコードであることを意味する。

char** m_ppszInstalledPath;

上記は一瞬でインストールされたパス情報を管理する領域へのポインタのポインタと
言う事が分かる。

UNIXのほうはいまだに

for( int i=0; ...

などと一文字変数を使ってるようだが。
つまりオレが20年前にBASICで遊んでいた頃から意識に変化がないように見える。

640 ：仕様書無しさん：02/12/04 20:53

アフォ丸出しやの

641 ：仕様書無しさん：02/12/04 21:00

>>639
m_は型情報じゃないのでハンガリアンじゃない。

642 ：仕様書無しさん：02/12/04 21:04

>639
> for( int i=0; ...
いや、さすがにループ変数は i で良いだろう。

>641
> m_は型情報じゃないのでハンガリアンじゃない。
ハンガリアンの厳密な定義って、どこかにあるのか？

643 ：仕様書無しさん：02/12/04 21:09

>>642
> ハンガリアンの厳密な定義って、どこかにあるのか？
MSが嫌いな人がMS関連のソースでプリフィックスをつけたものを見ると
すべてハンガリアンになります（ｗ

644 ：仕様書無しさん：02/12/04 22:05

ハンガリアンの場合、インスタンスにはprefixつけんの?

645 ：仕様書無しさん：02/12/04 22:24

>644
とりあえず、このスレ見る限りだと「つけない」人間ばかり。

ポインタやスマートポインタ (std::auto_ptr や CComPtr で持ってる場合) の
プリフィクスは付けるかもしれんが。

646 ：仕様書無しさん：02/12/04 22:31

そもそも変数名に大文字を使うなんて気持ち悪いし、読みづらい、
って俺は思ってしまう。それに変数名がやたら長いとなにかは
わかりやすくても、コードの流れが追いにくくてしょうがない。

647 ：仕様書無しさん：02/12/04 22:33

変数名の略記は別によいと思う。それがソースの中で統一されていれば。

aio = asynchronous input/output

を表すとか。

648 ：仕様書無しさん：02/12/04 22:40

統一感のあるソースはホント読みやすいよね。

649 ：仕様書無しさん：02/12/05 00:37

>646
> それに変数名がやたら長いとなにかはわかりやすくても、コードの流れが
> 追いにくくてしょうがない。
これは訓練次第で、慣れます。

っつっても、俺もエディタで開いたときに画面が文字で埋まってると「うげ」となる。
重要なシンボルは目立つように長く、どーも良いヤツは短くひっそりってのが理想
かねぇ。

650 ：仕様書無しさん：02/12/05 00:41

>648
最悪なのは、コードの場所によって省略記法が違う場合だよね。

変数名はまだ許せるが、似たような処理なのに初期化や後始末が init() だったり Initialize() だったり、場所によっては PreInit() を読んでから Init() 呼ばないとダメ
だったり、複数回呼んでも大丈夫なのとダメなのが同じ名前で混在してたり。

危なすぎ。

651 ：仕様書無しさん：02/12/05 00:45

>>650
そゆのは勉強中のやつに多いね。

652 ：仕様書無しさん：02/12/05 00:52

>651
いや、現実に動いてるコードでも見かける。複数人で開発していて、各人「自分が
必要な部分」だけ直接担当者と話をして情報出してもらう、みたいな開発スタイル
だとありがち。

コードレビューして、少なくとも一人は全体像を把握してるようにしないとダメだ。

653 ：仕様書無しさん：02/12/05 00:56

>>652
規約どころの話ではないってこと？

654 ：仕様書無しさん：02/12/05 09:48

>>649
これは、ソフトウェア作法からの引用なんだけど：

for (theElementIndex = 0; theElementIndex < numberOfElements; theElementIndex++)
　　elementArray[theElementIndex] = theElementIndex;

と、

for (i = 0; i < nelems; i++)
　　elem[i] = i;

どっちが読みやすい？俺は後者が圧倒的に読みやすくて、情報に不備が
あるとも思わない。

名言：「明快さは簡潔さによってもたらされる」

Unixなら"int s"でソケットディスクリプタを表すなんて常識的に
すぐわかるんだが、まあ"skfd"なら十分だし、"socketDescriptor"
なら市ねだし、"telnetServerSocketDescriptor"なんて出てきた
日には全部置換してしまいたい衝動にかられてしまう。

655 ：仕様書無しさん：02/12/05 10:58

>>652
長期開発系にもありがち
制御関係や工場系だと、もっとありがち

>>648
漢字変数、漢字関数で統一されていても？

>>654
649じゃないけど断然後者。
windowsアプリになってから、長い変数名が当たり前になってきて
ちょびっと疲れる３０代。
どうでもいいが、ループ変数はいつもiiとかjjにしているなあ。
検索や置換時、一文字変数は怖いから。

656 ：仕様書無しさん：02/12/05 12:00

> 検索や置換時、一文字変数は怖いから。

(ﾟДﾟ)ﾊｧ?

657 ：仕様書無しさん：02/12/05 12:38

> どうでもいいが、ループ変数はいつもiiとかjjにしているなあ。
> 検索や置換時、一文字変数は怖いから。

こういうレベルのやつが加わってるから、議論が収束しないわけで。

658 ：150：02/12/05 15:19

>>654
圧倒的に前者。
前者と比較すれば後者の方が簡潔に見えるが、後者だけ見た場合は
組んだヤツの意図が読み取りにくいぞ。
elemとnelemから意味が読み取れなかったらどうすんだよ？
（しかも、nelemだけハンガリアンのつもりか？）

意味が読み取れなかったら、前後のソースを見て推測するしかないだろうが。
だからオナニーPGと言うんだよ。

>>656,657
おまいらはどう解釈してんだ？
折れは>655の言ってる意味が分かるから、変だともレベルが低いとも思わんが。

１文字変数を置換する時、関係ない変数、関数まで置き換える危険性がある
って意味だろ？

659 ：仕様書無しさん：02/12/05 15:30

一文字の変数がそんなに影響力をもつようなソースが
そもそもどうかと思われ。
せいぜい短いループの中で使われるだけだろうが。

660 ：仕様書無しさん：02/12/05 15:32

>（しかも、nelemだけハンガリアンのつもりか？）

ハア？

> １文字変数を置換する時、関係ない変数、関数まで置き換える危険性がある
>って意味だろ？

アホ

661 ：仕様書無しさん：02/12/05 15:40

>一文字の変数がそんなに影響力をもつようなソースが
>そもそもどうかと思われ。
>せいぜい短いループの中で使われるだけだろうが。

こういう奴が、「俺的にはキレイ」なスパゲッティソースを生み出すのである。
常に万全を期しておくのが、本当のプロ。

662 ：150：02/12/05 15:45

>>659
そういうことじゃなくて、短いループの中で使われるだけであっても、
置換ソフトが意図しない所まで置き換える可能性がある事に対する
注意が必要だってことでしょ。
操作ミスさえしなきゃいいんだろうけど、それでも間違って
「i -> jに全て置換」みたいな事をソース全体に適用してしまった時に
イヤな思いするだろ？

ま、大袈裟な言い方だけど、危機意識の持ち方の差じゃねーの？
１文字変数はダメということじゃない。

>>660
典型的な「何がなんでもアンチハンガリアンオナニーPG」的レスだな。(藁

663 ：仕様書無しさん：02/12/05 15:48

> 置換ソフトが意図しない所まで置き換える可能性がある事に対する
>注意が必要だってことでしょ。

頭おかしいんじゃないの？

> 典型的な「何がなんでもアンチハンガリアンオナニーPG」的レスだな。(藁

少しは頭使ったら？

664 ：150：02/12/05 15:55

頭おかしいんじゃないの？
少しは自分の考えを書いてみたら？
まあ、反論出来ないんだろうな。

665 ：仕様書無しさん：02/12/05 15:57

> まあ、反論出来ないんだろうな。

そう思い込むと幸せになれますか？

666 ：仕様書無しさん：02/12/05 16:01

>>662
iをjに、しかもソース全体に適用してしまったら、イヤな思いする
だけでは済まされないと思われ。iとかiiの問題じゃないよー
だけど短いコードでも検索くらいはするだろうからiiでもいいとは思う。
漏れはしないけど。見た目にｶｺﾜﾙｲから。

667 ：仕様書無しさん：02/12/05 16:25

高校生が１名混じっている模様

668 ：仕様書無しさん：02/12/05 16:57

このスレを盛り上げるための釣り師じゃねーの?
そう考えないとあまりにアホ過ぎる。

669 ：仕様書無しさん：02/12/05 17:02

>そういうことじゃなくて、短いループの中で使われるだけであっても、
>置換ソフトが意図しない所まで置き換える可能性がある事に対する
>注意が必要だってことでしょ。
>操作ミスさえしなきゃいいんだろうけど、それでも間違って
>「i -> jに全て置換」みたいな事をソース全体に適用してしまった時に
>イヤな思いするだろ？
>
>ま、大袈裟な言い方だけど、危機意識の持ち方の差じゃねーの？
>１文字変数はダメということじゃない。

デンパ?

670 ：仕様書無しさん：02/12/05 17:16

高校生１名どころではありません

671 ：仕様書無しさん：02/12/05 17:17

煽りじゃなくて純粋に聞いてみたいんだが、
プログラムソースを対象にして i をすべて j に置換する、という
ケースって、どんな場合？

自分には想像がつかないんだが・・・。

672 ：仕様書無しさん：02/12/05 17:21

つまんねぇからsage進行頼むわ

673 ：仕様書無しさん：02/12/05 17:29

>>654
(1) 普通は、
for( i = 0; i < nCountOfElements; i++ ){
　　nElementArray[i] = i;// ０からの連番で初期化
}

(2) nElementArrayのアクセスにnIndexを使うと決めている場合
for( nIndex = 0; nIndex < nCountOfElements; nIndex++){
　　 nElementArray[nIndex] = nIndex;// ０からの連番で初期化
}

(3) 同一関数内に n***Index という変数がある場合、
または、インデックスを表す変数は、n***Index と決めている場合
for( nElementIndex = 0; nElementIndex < nCountOfElements; nElementIndex++ ){
　　 nElementArray[nElementIndex] = nElementIndex;// ０からの連番で初期化
}

メンバ変数を定数で初期化するの場合は、
CExample::CExample()
{
int i;

for( i = 0; i < MAX_OF_ELEMENTS; i++ ){
　　m_nElementArray[i] = DEFAULT_VALUE;
}
}
と、iを使う場合がほとんどかな。

674 ：150：02/12/05 17:29

>>671
折れは
>「i -> jに全て置換」みたいな
と書いているんだが、揃いも揃って「i -> jに全て置換」限定としか
解釈されていないようだな。
１文字変数を他の名前に置換する事はあり得ないのか問いたいね。

675 ： ◆qQ4COMPILE ：02/12/05 17:35

>>674
ありえなくはないが極めて稀だと思うのだが？

で、あらためて、
> 検索や置換時、一文字変数は怖いから。

これってどういう意味なの？マジでわからんのだが･･･

676 ：671：02/12/05 17:41

>>674
ん？別に i から j への置換に限定はしてないよ。

> １文字変数を他の名前に置換する事はあり得ないのか問いたいね。

たぶん、ほとんどないと思うよ。
全体にわたって変数の名前だけ変える必要っていうのがそもそも
ないしさ。
もちろん、どっか一箇所とか数箇所、変数名を間違えた、っていうのなら
その範囲だけ手で直すけど？

で、それと「危険性」うんぬんとはどうつながるの？
まだあなたの言ってる意味がよくわからないんだけど。

677 ：671：02/12/05 17:44

ああ、書き込んでからやっとわかった。
つまりこういうことね。

たとえば変数に i という一文字名をつけた場合、それをたとえば
j に全置換しようとすると、 printf というのが prjntf に置換されたり
して面倒だ。
だから一文字名はやめたほうがいい。

↑こういうことかな？

で、自分の場合はね、そういうときは秀丸なんかの正規表現での
置換を使って、 [^\w]i[^\w] みたいに「独立したiだけ」を対象にする
ようにするよ。

678 ：仕様書無しさん：02/12/05 17:46

というか、何のためにわざわざiをjに変える必要があるわけ？
それもソース全体にわたって。

679 ：150：02/12/05 17:47

>>675
おまい、視野が狭いな。
折れはたとえ話で置換のケースを書いたが、検索の時はどうすんだよ。
ループ変数を検索してトレースする事は無いのか？
そんな時に変数名が１文字だったら、ループ変数以外にもヒットしてしまう
可能性が高いだろ。

これを嫌う嫌わないは個人の自由。
前にも書いたが、一文字変数の善し悪しまで論じてないぜ？

他のヤツもそうだが、こういう所まで気が回らずに不要だの無意味などと
簡単にほざくヤツはPG不適合。

680 ：655：02/12/05 17:51

なんか盛り上がってますな。バグ対応してたら、iiの話題でこんなに・・・
150さん大便いやもとい代弁どもう

言いたいことは大抵言ってくれてまつ。

更に言うと
ここにいる反論メンバーは

　・自分がコーディングすることしか考えていない

という欠点あり。
新人に何かの作業やらせたとする。
そいつがミスって関係ないもんまで置換しちまったとする。
とーぜんそいつのミス、説教する。

という時間も勿体無いので、そういうことがおきないよう最初から対処してるのさ。
誰かのコメントじゃないけど、それがプロってもんだろ？

681 ：仕様書無しさん：02/12/05 17:53

>>679
> おまい、視野が狭いな。
おまい、スキル低いな。
まともな正規表現が使えないことを晒して楽しいか？

他のヤツもそうだが、まともなスキルがあれば簡単なことを
スキルが無いために無駄なことをする奴が多すぎる
そんなヤツはPG不適合。

682 ：仕様書無しさん：02/12/05 17:55

>>680
馬鹿にソースをいじらせる事態を想定するよりも
馬鹿にソースを触らせないような方法を考えましょう。

683 ：仕様書無しさん：02/12/05 18:00

>>681　は限られた条件下での仕事なんてしたことないんだろうな・・・・幸せな奴だ

684 ：仕様書無しさん：02/12/05 18:05

>>683
>は限られた条件下での仕事なんてしたことないんだろうな・・・・幸せな奴だ

今時正規表現も使えないような環境で仕事している奴がＤＱＮ

685 ：仕様書無しさん：02/12/05 18:06

「エディタの置換ミスに備えるためにループカウンタはiを使わずにiiを使う」
↑これをマジで主張して譲らないやつがいるなんて…
世の中広いね。

686 ：仕様書無しさん：02/12/05 18:06

>>682
一見、まとものようも聞こえるが。

687 ：仕様書無しさん：02/12/05 18:07

新人に何かの作業やらせたとする。
そいつがミスって長い長いループカウンタの変数名をタイプミスしたとする。
とーぜんそいつのミス、説教する。

という時間も勿体無いので、そういうことがおきないよう最初から対処してるのさ。
誰かのコメントじゃないけど、それがプロってもんだろ？

688 ：永久ループ：02/12/05 18:09

for(intmyloopcounter=0; intmyloopcounter<10; intmyloopcountre++){

　・・・

}

689 ：仕様書無しさん：02/12/05 18:10

>>684
正規表現ってなんですか？
すみませんが、教えて下さい。

690 ：仕様書無しさん：02/12/05 18:11

>>685
iをiiに変更しても、全部の関数でiiを使ってれば、
ミスったときには結局置換されてしまうとおもうが。

691 ：仕様書無しさん：02/12/05 18:11

「エディタの置換ミスに備えるためにループカウンタはiを使わずにiiを使う」
で、例えばasciiがascjjに変換されることは問題ないのですね？

692 ： ◆qQ4COMPILE ：02/12/05 18:12

別に私も、悪いとはいってないけど？　意味がわからない、といっている。

自分にわからない大きな利点があるのなら自分のコーディングにも影響があるかもしれないし
理解があればそういうコード見たときもそれを書いた人の気持ちもわかりやすくなるだろうし。

んで、ひとつの利点として、
自分が正規表現等で正確に識別子を判断させ作業ができたとしても、
同時に仕事をしている新人等はそうとは限らない、そのために
多少引っかかりにくい識別子にすることで、危険性が下がることがある。

で、OK？

// そのくらいじゃ自分には導入理由にはならないが、まあ理解はした。

693 ：仕様書無しさん：02/12/05 18:15

>>689
> 正規表現ってなんですか？
以下の本を買って読め
詳説　正規表現
Jeffrey E. F. Friedl 著
歌代　和正　監訳
春遍雀来、鈴木　武生　共訳
1999年4月発行
371 ページ
本体価格4,300円
ISBN4-900900-45-1
http://www.oreilly.co.jp/BOOK/regex/

694 ：仕様書無しさん：02/12/05 18:21

交通事故にあったことがないやつは　交通事故にあった奴が
「事故ったら怖いから速度はあまり出さないよ」
というコメントに対して
「事故るやつがバカなんだよ」
と飛ばしまくる

という例と同じだな

695 ：仕様書無しさん：02/12/05 18:25

>>694
仮に置換ミスに備えるのが必要だとして、iをiiに変えたら、
なにか状況がよくなるのでしょうか...?

696 ：仕様書無しさん：02/12/05 18:28

>>693
ありがとうございました。
これって、Perlとかで使うんですか。
ＶＣバカなんで、勉強しま～す。

697 ：694：02/12/05 18:33

置換ミスにこだわりすぎ。

694の例でいえば「事故るやつがバカなんだよ」と答えるやつは
「事故られる可能性」「車が故障する可能性」「速度オーバーの最中に道に何かがあってそれを踏んでしまってハンドル操作が効かなくなる可能性」
とか、そういうのを考えられない、いわゆる「言葉どおりの判断しかできない」人

それでも世渡りはできるけど、いい状態とは言えんよな？

698 ：仕様書無しさん：02/12/05 18:36

事故るやつの運がないだけ
仕事でも置換ミスされる奴が悪いんだよ

699 ： ◆qQ4COMPILE ：02/12/05 18:40

>>698
飛ばさなかったばっかりにカマ掘られたりとかね。

700 ：仕様書無しさん：02/12/05 18:41

>「事故られる可能性」
>「車が故障する可能性」
>「速度オーバーの最中に道に何かがあってそれを踏んでしまってハンドル操作が効かなくなる可能性」
それはiiを全置換される可能性より高いのか？

701 ：655：02/12/05 18:43

俺は
　検索や置換
であって
　置換
についてそこまで主張した憶えないぞ

反論するやつは、検索についても反論しているのか？

702 ：仕様書無しさん：02/12/05 18:43

脱線が転覆に…

703 ：仕様書無しさん：02/12/05 18:45

> いい状態とは言えんよな？
そうだな、車は免許を持った奴しか運転できないように
プログラムも一定の資格を持った奴しか触れないようにしないと
いい状態とは言えないな。

ハッキリ言って馬鹿に合わせられるほど俺のレベルは低くないのだよ。

704 ： ◆qQ4COMPILE ：02/12/05 18:49

>>701
すまん。検索時に、変数 i は何が危険なの？

705 ：仕様書無しさん：02/12/05 18:51

>>701
> 反論するやつは、検索についても反論しているのか？
検索と置換を区別する理由ってあるのか？
また、>>655の最後の１文で
> 検索や置換時、一文字変数は怖いから。
思いっきり置換についても主張していますが、忘れたんですか？

706 ：655：02/12/05 18:53

怖いと主張するのが
iiをjjに
とか
asciiがascjj
にとか
全置換
とか
危険である

とか・・・お前ら日本語ダメだなあ

707 ：仕様書無しさん：02/12/05 18:54

>>703
> ハッキリ言って馬鹿に合わせられるほど俺のレベルは低くないのだよ。
馬鹿な奴にも合わせられるやつって、

・相手がどの程度馬鹿かがわかる
・どの程度までレベルを下げればいいか分かる
・相手に合わせてレベルを調節しても、自分には支障が無い

ってことでしょ？俺的には凄いレベル高いと思うんだけど。

708 ： ◆qQ4COMPILE ：02/12/05 18:57

>>706
タブと先頭の半角スペースは無効だよ。

709 ：仕様書無しさん：02/12/05 18:59

>>707
> ってことでしょ？俺的には凄いレベル高いと思うんだけど。
了解、訂正しよう。
　ハッキリ言って馬鹿に合わせられるほど俺のプライドは低くないし、
　馬鹿に合わせられるほど俺のレベルもコミュニケーション能力も高くない。
これでいいか？

710 ：655：02/12/05 19:02

655 「俺、幽霊とかホラー話怖いから、そういう本読まないようにしているんだ」

Ａ「幽霊が銃撃つとでも思ってんのか？アホだなお前」
Ｂ「ホラー話聞いて死ぬ奴がＤＱＮ」
Ｃ「幽霊の何がどう危険なんだ？」
Ｄ「幽霊見たら呪い殺されると思ってるおまえは最低」

こう返されたような印象ですな（´ー｀）

711 ：655：02/12/05 19:07

>>708
すまん、書いた後気付いた（ｗ
あんまりこういうまともな話を解説しないといけない状況ってないから
つい忘れてしまうんだよ（ｗｗ

712 ：仕様書無しさん：02/12/05 19:08

>>710
と、思いたいんですね;)

713 ：仕様書無しさん：02/12/05 19:13

>>709
> 　馬鹿に合わせられるほど俺のレベルもコミュニケーション能力も高くない。
そこまで自分を卑下せんでも良かろうに。
年食って場数を踏めば、大抵は自然に出来るようになるかと。

714 ：仕様書無しさん：02/12/05 19:14

>>710
> 655 「俺、幽霊とかホラー話怖いから、そういう本読まないようにしているんだ」
つまり、「検索や置換時、一文字変数は怖い」ということは
幽霊やホラーの類を見たときのような恐怖だと主張したいんですか？

715 ：仕様書無しさん：02/12/05 19:14

>>710
「幽霊とかホラー話」って言ってるとこが絶妙。
現実はともかく「怖いもんは怖いんだよ」ってことだよね。

716 ：仕様書無しさん：02/12/05 19:27

検索が大変だから一文字変数使わないって奴も、そうとうアホだな。

717 ：仕様書無しさん：02/12/05 19:35

>>716
きっとそういう奴は、実際に「やっちゃった」んだよ。
羹に懲りて膾を吹くよりは、羹をうまく捌く術を叩き込めばよろし。

718 ： ◆qQ4COMPILE ：02/12/05 19:47

　　　 ∧＿∧∩　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　（　´∀｀）/＜　先生！あつものってさばくものなんですか？
　＿ / /　　 /　　　＼　　
＼⊂ノ￣￣￣￣＼　＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　||＼　　　　　　　　＼
　||＼||￣￣￣￣￣||
　||　 ||￣￣￣￣￣||
　　 .||　　　　　 ||　　　

719 ：仕様書無しさん：02/12/05 19:47

int aIterator

720 ：仕様書無しさん：02/12/05 19:59

>>717
>きっとそういう奴は、実際に「やっちゃった」んだよ。

>>694
を読め。

721 ：仕様書無しさん：02/12/05 20:02

一文字の変数が検索が大変だって、どういうシュチュエーションなんだろ。
グローバル変数で使ってるって事ですか?

722 ：仕様書無しさん：02/12/05 20:08

私は一日に5回くらい、全域正規表現置き換えをしてリファクタリングしてる。
努力のかいがあって、保守にかかる労力は一定のままだ。むしろ、書けば書くほど見やすくなってくるようだよ。
個人的には…、一文字変数は嫌いだなぁ。
パッケージを持たないクラスを見たときと同種の嫌悪感を持ってしまうんだ。
ループが次第に大きく、分かりづらくなってきても、添え字を分かりやすくしようと思うプログラマは少ない。
意味の無い慣習が怠慢を産み、あっという間に保守性を低下させる。
嘆かわしいことさ。

723 ：仕様書無しさん：02/12/05 20:15

>>720
交通事故の例えは、あてはまらないﾀﾞﾛ。
むしろ、お守りだな。
なんの効力も無いけど、やってる本人はけっこう意味あると思ってる。

724 ：仕様書無しさん：02/12/05 20:19

>722
> ループが次第に大きく、分かりづらくなってきても
ふつー添え字をどうこうするより、下請けの関数作って処理を分離すると思うが。

725 ：仕様書無しさん：02/12/05 20:20

>>721
もしくは、何百行もある関数作って、しかもあちこちで使いまわしているとか。

726 ：仕様書無しさん：02/12/05 20:20

> 私は一日に5回くらい、全域正規表現置き換えをしてリファクタリングしてる。

てか、こいつアホだろ。

727 ：717：02/12/05 20:23

>>720
> 事故るやつがバカなんだよ
とは思わないよ。

一括置換で失敗したり、その失敗からさらに悪影響を出さないような
方策をちゃんと立てようよって言いたかった。
「あつもの」の例えが悪かったかも知れぬ。

728 ：仕様書無しさん：02/12/05 20:27

ソースコードで一括変換なんかするなよ。

729 ：150：02/12/05 20:27

本当に視野の狭いヤツばかりだな。真性DQN・厨房がイパーイ釣れてしまったなｗ
未だに>721みたいなヤツ居るし。

>>692
それでＯＫ。
別に折れ達ゃぁ１文字変数使うなと言っている訳でないし。
・・とこれで終いかと思いきや、なんだ>704は？
分かってないのか？どっちだ？

「危険」の意味をそのまんまマジで取るなよ。
「弊害」なら分かるか？

ま、どちらにせよ、これを害と思うか否かは人によるがな。

730 ：仕様書無しさん：02/12/05 20:27

>727
> 一括置換で失敗したり、
正規表現と CVS 使いましょう。失敗したら cvs update -C で戻せるようにね。

731 ：仕様書無しさん：02/12/05 20:29

わいはアホやない！
おまいらが釣られたんや！
こないとこもうくるかい！
しまいじゃボケ！ウワアァン

732 ：仕様書無しさん：02/12/05 20:31

>>729
で、iをiiに変えたら置換のミス防止にどんな効果があるの?

733 ：仕様書無しさん：02/12/05 20:32

変数名？
VBAツールが自動的に作ってくれるやん。

734 ：仕様書無しさん：02/12/05 20:34

iをhogeに置換するとする・・・
この場合、iiはhogehogeになる。という効果かな？

735 ：仕様書無しさん：02/12/05 20:36

>>732
出だしで思いっきり厨房発言してるから、いくら取り繕っても
かえってみっともないよ。

736 ：150：02/12/05 20:45

>>732
なんで読解力の無いヤツらがこんなに多いんだ？
引きこもり厨だからコミュニケーション能力に欠けているのが原因か？

まあそれはさておき、i -> ii なら、多少の効果があるとしか言えないな。

事の本質は、
「１文字変数には問題（検索精度・置換リスク・etc）が多い（可能性がある）」
ということであり、iiなら良いのだと言っている訳では無い。
さらに、iiという変数名は折れが言い出した訳でもない。

１文字変数の問題を回避するのに１文字以上の命名をすること以外に、
正規表現を使う方法もある。知ってるならそれでいいよ。

折れは１文字検索するのに正規表現で何文字も入力しなければいけない
のなら、最初から分かりやすい変数名にしとく。

737 ：150：02/12/05 20:52

事の本質に補足しておくと、

「１文字よりも２文字、２文字より３文字と、文字数が多いほど先に書いた
問題を回避する確率も上がる。ただし、長すぎると別の問題も発生するので、
短すぎず・長すぎずが良い。」

ま、これでも理解出来ないヤツはいるんだろうな。

738 ：仕様書無しさん：02/12/05 21:14

> まあそれはさておき、i -> ii なら、多少の効果があるとしか言えないな。

ぜんぜん効果ないよ。

> さらに、iiという変数名は折れが言い出した訳でもない。

同意してたじゃん。

739 ：仕様書無しさん：02/12/05 21:22

150って、新卒？

740 ：仕様書無しさん：02/12/05 21:26

iをii？
アホじぇねーのオマエラ
iなんて変数何回使うと思ってんだよ
iなら１回でいいのにiiなら２回もキーボード打たないといけないんだぞ
だだでさえ仕事で疲れるのにそんな無駄な労力使ってられるか？
だから俺はいつもiはグローバル変数で切っている。
その方があちこちの関数で宣言するよりメモリ少なくて済むしな！

741 ：仕様書無しさん：02/12/05 21:27

>>736
他人の意見を見てから、後であたかも分かってるように取り繕うのって本当にみっともないよ。
正規表現で置換ミスが防げるとか言ってる時点で、なんにもわかってないってモロばれじゃん。

742 ：仕様書無しさん：02/12/05 21:29

>だから俺はいつもiはグローバル変数で切っている。
>その方があちこちの関数で宣言するよりメモリ少なくて済むしな！

ネタだと言ってください、お代官様

743 ：仕様書無しさん：02/12/05 21:30

エディタにマクロを登録すれば、どんなに長い定型句でも一発で挿入されるんだが。

744 ：仕様書無しさん：02/12/05 21:37

なんか長い名前を嫌う奴って、タイプ速度も遅いし、エディタ基本的な機能も使えないし、
正規表現もよくわかってないし、総じてDQNな傾向があるな。

745 ：仕様書無しさん：02/12/05 21:39

>>740
あらゆるファイルにextern iとか書いてるのか？この厨房。
共通ヘッダに#define I extern iくらい書いとけよ。

746 ：仕様書無しさん：02/12/05 21:41

>>743-744
けんとうはずれなことを言ってるお前らのほうがDQNに見えるぞ。

747 ：仕様書無しさん：02/12/05 21:42

>>742
どう見てもネタだと思うが。

748 ：仕様書無しさん：02/12/05 21:43

見当違い？
iだろ？i。

749 ：某研究者：02/12/05 21:46

矢張り愛よりエッチが先であろうか

750 ：仕様書無しさん：02/12/05 21:51

i を ii にしてると誇らしげに言ってるﾔｼは馬鹿以外の何者でもないが、
慣習的に用いられてきたもの(for文カウンタの i、j、k、ソケットのsなど)以外は
一文字変数は使わんな。
変数名はできるだけどんなデータを扱っているのかがわかるようなものを
つけるようにしている。
大抵の人間はそうだろう?

751 ：仕様書無しさん：02/12/05 22:00

>>741
何の為に掲示板使ってるんだ？
他人の意見を取り入れて自分の意見を補完するのは極自然な事だと思うが。
揚げ足とるだけなら何も生み出さないからやめておけ。

752 ：仕様書無しさん：02/12/05 22:07

>>751
補完つーか、後付けの理屈でいいわけしてるようにしか見えんけど。

753 ：仕様書無しさん：02/12/05 22:08

正解:
for( int nCount = 0; nCount ...

一文字変数の恐ろしさは、コメント書かないヤツが多段ループ作ったときに思い知らされる。
どうせバグは当たり前と思ってる。
iやjやkがコーダの意図どおりに使われているのかどうかコメントなくては不明だし、
そもそも一文字を見つけるのがｳｾﾞｴ。
プロからおそわりゃこんなことはありえなくって、独学できたから1文字平気のコメントなし平気。
しねーぼけー。
しぬまでおまえのコードはお前が直せ！

754 ：仕様書無しさん：02/12/05 22:09

深いループは書くなや。

755 ：仕様書無しさん：02/12/05 22:15

wString
wInt
wIdx

だな．．．．。こんな俺は i,j が許せません

756 ：仕様書無しさん：02/12/05 22:24

Uzeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee

757 ：仕様書無しさん：02/12/05 22:25

>753
深い多段ループを作るようなヤツは、変数名を長くしてもダメだって。そんな
対処療法ではなく、根本からたたき直さんと。

758 ：仕様書無しさん：02/12/05 22:26

>>756 の変数は良くないと思う。こんなの使われたらウザイと思う。

759 ：仕様書無しさん：02/12/05 22:28

>>758
1行80桁にこだわる香具師への嫌がらせにはいいかも

760 ：仕様書無しさん：02/12/05 22:33

unsigned int uZeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee

761 ：仕様書無しさん：02/12/05 22:34

;

762 ：150：02/12/05 22:41

あのー、最初から正規表現出来ますと宣言していないと却下なの？
iiだけは同意出来ませんと宣言していないとiiﾏﾝｾｰ野郎になって
しまうの？

あ、ごめん。
ｷﾐﾀﾁは揚げ足取るしか言い返せないからね。ごめんごめん。
もっと言ってｗ

未だに事の本質を理解出来ないDQN達よ・・・

763 ：仕様書無しさん：02/12/05 22:41

>i を ii にしてると誇らしげに言ってるﾔｼは馬鹿以外の何者でもないが、
>慣習的に用いられてきたもの(for文カウンタの i、j、k、ソケットのsなど)以外は
>一文字変数は使わんな。
お前同レベルだよ（ｗ
痛すぎ！　「俺はオタクじゃない！」と言い張っているメガネデブオタと同レベル

764 ：仕様書無しさん：02/12/05 22:43

i,j 位までは許してくれ。
3段以上の多段ループは、多段にならない方法を考えるからさ。

765 ：仕様書無しさん：02/12/05 22:44

その甘さがiiのような奴を生むんだよ、ぼけ

766 ：仕様書無しさん：02/12/05 22:44

>761
それで思い出したが、空ループも罠だよな。目立つように、行を変えて書いて
欲しいんだが。

こういうやつね↓
for (p = head; p->next != NULL; p = p->next);

767 ：仕様書無しさん：02/12/05 22:47

>762
分かったから、もう終わりにしてくれ。いまさら言葉を積み重ねたところで、
読んでるヤツの評価は変わらんよ。

（良いにせよ、悪いにせよ）

768 ：仕様書無しさん：02/12/05 22:48

>765　iiはおさるさんだよ！

769 ：仕様書無しさん：02/12/05 22:49

>>766
for (p = head; p->next != NULL; p = p->next); //要約コメントで事足りない？

770 ：晒しage：02/12/05 22:50

>>763
「オタク」という言葉には悪意が込められているから、
そりゃ普通否定するだろ。
「お前はバカだ」と言われて、「はい私はバカです」なんて
答えるバカは滅多にいないからな。

普通レベルの香具師を痛い香具師扱いする>>763は、
自分の痛さを白日の元に晒していると思わないかい？

771 ：仕様書無しさん：02/12/05 22:51

>>768
何気にうまいなあ。

772 ：仕様書無しさん：02/12/05 22:51

だから、headやnextじゃなくてpHeadとpNextにしろよ。あー読みにくい。

773 ：仕様書無しさん：02/12/05 22:53

>>772
You are right.

774 ：仕様書無しさん：02/12/05 22:53

>769
コメントあれば OK。個人的には

for (p = head; p->next != NULL; p = p->next)
　　;

だけど、まぁ趣味の問題だよな。

775 ：768：02/12/05 22:54

>771　さんきゅ！

776 ：仕様書無しさん：02/12/05 22:54

>>762
>あのー、最初から正規表現出来ますと宣言していないと却下なの？

正規表現はカンケーないだろ。
正規表現がどうこう言ってる厨房の言葉尻に乗ってこんな事を言ってるから
後付けだとか言い訳だからとか言われるんだよ。

777 ：仕様書無しさん：02/12/05 22:55

それより、p->next != NULLのほうが気になる。
!= NULLなんて書かなきゃいいじゃん。

778 ：リアル厨房：02/12/05 22:55

>for (p = head; p->next != NULL; p = p->next)

???分からん???
矢印は何かの演算子？

779 ：766：02/12/05 22:55

>772
悪いことは言わん。このコードで読みにくいと思うようなら std::list 使っとけ。

780 ：仕様書無しさん：02/12/05 22:55

漏れはこうしてる。

for (p = head; p->next != NULL; p = p->next){
　　　　/* 処理無し */
}

781 ：150：02/12/05 22:56

>>767
どう評価してくれてかまわんが、おまいの本質に目を瞑る盲目さ加減は
ピカ一だと評価してやるよ（藁

782 ：仕様書無しさん：02/12/05 22:57

nextだけじゃポインタってわからんがな。

783 ：仕様書無しさん：02/12/05 22:58

>777
ああ、それは俺が「bool 以外は真偽値として使うな」教の信者だから。

ハンガリアンが変数名に型を含めることで可読性を上げる技法なら、「bool 以外は
比較しろ」は式に型を含めることで可読性を上げる手法やね。

784 ：仕様書無しさん：02/12/05 22:59

>>781
そういうセリフは、自分がなにか本質的なことをひとつでも
語ってからにしなさいね。

785 ：150：02/12/05 22:59

>>776
ああ、揚げ足の材料になるからヤメトケと？
わかりますた。

>>777
!=NULL でもいいじゃん。
明示的でいいなと折れは思う。
ま、これも好きずきだねえ。

786 ：仕様書無しさん：02/12/05 22:59

誰がどう評価されてるのかはどうでも良いんだけど、
結局の所ループ変数はどうするのがベストなんだ？

787 ：某研究者：02/12/05 23:00

変数名に型を含めることは否定しつつ式に型を含めることは肯定しているわけだが

788 ：仕様書無しさん：02/12/05 23:02

>>786
ループを深くしないという条件付きで i, j でもいいじゃん
に1票

789 ：仕様書無しさん：02/12/05 23:02

>>782
実はポインタじゃ無い罠(ダサッ

790 ：150：02/12/05 23:02

>>784
盲目とは過去ログも読めないヤツも指すのだよ。
折れは「本質」をちゃんと語ったぜ。
折れが言う「本質」が間違ってるならそう言いなさいな。
ま、国語の勉強からだねキミは。

791 ：仕様書無しさん：02/12/05 23:03

int ♥;

792 ：某研究者：02/12/05 23:04

ループスレでループ変数を語っているわけだが（苦笑）

793 ：仕様書無しさん：02/12/05 23:04

>786
1. 明示的なループは使わず、すべて for_each などのアルゴリズムを使う。
2. 末尾再帰マンセー

とか。（それはそれで極端だな）

794 ：仕様書無しさん：02/12/05 23:05

int ♠;

795 ：仕様書無しさん：02/12/05 23:06

>>793
効率悪っ！

796 ：仕様書無しさん：02/12/05 23:07

int ♣;

797 ：仕様書無しさん：02/12/05 23:08

>782
p != NULL とか p = p->next と書いてあるのを見て一瞬で「next はポインタ型
だな」と理解できないようなら、さすがに首を吊った方が良いと思う。

798 ：仕様書無しさん：02/12/05 23:08

>>791,794,796
そろそろセミコロン付け忘れてボケる香具師登場予定。

799 ：仕様書無しさん：02/12/05 23:09

int _; ←こういう変数つかってる奴を見たことあるよ。

800 ：仕様書無しさん：02/12/05 23:10

>>150 って、近年稀に見る電界強度だなぁ。

801 ：仕様書無しさん：02/12/05 23:10

>799
int _ = 0;
for (;_;)
　　;

こういうコードとか？

802 ：仕様書無しさん：02/12/05 23:10

>>790
本質つーか、ただの勘違いや言い訳発言しかみつからんよ?

803 ：仕様書無しさん：02/12/05 23:11

>>797
お前クソコード読み慣れてないな。
型の確認を怠ると非道い目に遭うぞ。

804 ：仕様書無しさん：02/12/05 23:11

int ①, ②, ③, ④, ⑤;

805 ：仕様書無しさん：02/12/05 23:14

int　 ∧＿∧; 　　
int　（　´∀｀）＜　ぬるぽ;

806 ：仕様書無しさん：02/12/05 23:16

>803
p = p->next

これ next がポインタ型でなかったらあり得んと思うが。next がポインタでないと
p もポインタ型でないわけで、p-> の時点でコンパイルエラーだろう。

まぁ C++ だと operator->() とか operator=() いじれるけど、ダメプログラマは
そんな高度な技術は身につけてないハズ（ｗ

807 ：VBなら余裕だがな：02/12/05 23:17

Sub test()

　　　Dim ① As Integer

　　　① = 840

　　　MsgBox ①

End Sub

808 ：150：02/12/05 23:18

>>802
おまいは国語力もさておき、検索能力も無いようだ。
>736-737
真っ向反論は今のところないな。
言い訳だとかおまえはiiﾏﾝｾｰ論者だ同じだとかいう、横道それたことしか
言われないもんな。
で、揚げ句の果てには>800の常套句だねえ。
手応えの無いヤツらばかりだぜ。

809 ：仕様書無しさん：02/12/05 23:19

int 　　∧＿∧;
int 　（　・∀・）　　　|　|　ｶﾞｯ;
int 　と　　　　）　　 |　|;
int 　　Ｙ　/ノ　　　人;
int 　　　 /　）　　 < 　>_∧∩;
int 　＿/し'　／／. Ｖ｀Д´）/　← >>805;
int 　（＿フ彡;

810 ：仕様書無しさん：02/12/05 23:20

そろそろ >>150 の相手も飽きて来たわけだが。

811 ：仕様書無しさん：02/12/05 23:20

>>808
え？それが「本質」だったの…
突っ込みいれられて、苦しい言い訳してるだけじゃん。

812 ：150：02/12/05 23:20

>>810
ちゅーか、煽りネタが尽きたんだろ？

813 ：仕様書無しさん：02/12/05 23:21

>>810
かまって君を相手にするのは、いいかげんにしてほしいが。

814 ：仕様書無しさん：02/12/05 23:22

>>812
つーかネタ振ってよ。

815 ：150：02/12/05 23:23

>>811
頭の悪いヤツが多いから解説してやったのに、やはり未だにそういう解釈
しか出来ないんだな（藁
真っ向からかかってこいや。ネタ含めて。

よーく考えて書けよ。風呂はいってくるわ。

816 ：仕様書無しさん：02/12/05 23:25

>>809
>>805でモモラーがボケて、>>809でモモラーがギコをガッしてる・・・
おかしいと思わないか？本来ならこう↓なるべきだろ。

int 　　∧_∧;
int 　（　´Д｀）　　　|　|　ｶﾞｯ;
int 　と　　　　）　　 |　|;
int 　　Ｙ　/ノ　　　人;
int 　　　 /　）　　 < 　>＿∧∩;
int 　＿/し'　／／. Ｖ　｀∀´）/　← >>805;
int 　（＿フ彡;

817 ：仕様書無しさん：02/12/05 23:26

>>150
ねえちゃんと風呂入ってる？

818 ：仕様書無しさん：02/12/05 23:28

>>816
こっちの方がすき
int 　　∧_∧;
int 　（　´Д｀）　　　|　|　ｶﾞｯ;
int 　と　　　　）　　 |　|;
int 　　Ｙ　/ノ　　　人;
int 　　　 /　）　　 < 　>＿∧∩;
int 　＿/し'　／／. Ｖ　｀Ａ´）/　← >>805;
int 　（＿フ彡;

819 ：仕様書無しさん：02/12/05 23:30

>818
805bit も右シフトして大丈夫なのか？

820 ：仕様書無しさん：02/12/05 23:31

>>818
それならこうだろ。
こっちの方がすき
int 　　∧_∧;
int 　（　´Д｀）　　　|　|　ｶﾞｯ;
int 　と　　　　）　　 |　|;
int 　　Ｙ　/ノ　　　人;
int 　　　 /　）　　 < 　>＿∧∩;
int 　＿/し'　／／. Ｖ　｀Ａ´.）/　← >>805;
int 　（＿フ彡;

821 ：仕様書無しさん：02/12/05 23:33

>819　きっと、そこでアラーだ…。

822 ：仕様書無しさん：02/12/05 23:34

>>820
一体何処が違うんだと思ったら、ピリオド1個かよ！

823 ：818：02/12/05 23:35

>>820
参りますた

824 ：820：02/12/05 23:36

>>822-823
このスレに相応しいだろ？

825 ：仕様書無しさん：02/12/05 23:36

for (p = head; p->next != NULL; p = p->next)
　　;
または
for (p = head; p->next != NULL; p = p->next);
以外を使いたがるやつは、とりあえずしんどけ。

826 ：仕様書無しさん：02/12/05 23:38

>824
座布団1枚！

827 ：818：02/12/05 23:40

>>824
よく見るとこうかな
int 　　∧_∧;
int 　（　´Д｀）　　　|　|　ｶﾞｯ;
int 　と　　　　）　　 |　|;
int 　　Ｙ　/ノ　　　人;
int 　　　 /　）　　 < 　>＿∧∩;
int 　＿/し'　／／. Ｖ　｀Ａ´..）/　← >>805;
int 　（＿フ彡;
ますますこのスレに相応しいね

828 ：766：02/12/05 23:42

>825
だから行末の ; は目立たんからコメントを入れてくれと…。

自分で書いておいて何だが、最近、この手の「自前リスト構造」あまり使わんな。
4.4BSD から持ってきた <sys/queue.h> か std::list<> 使ってしまうことが多い。

829 ：仕様書無しさん：02/12/05 23:42

そもそも>>150にとっては、カーニハンすらオナニーPG
らしいから、返答するのすらバカバカしくなってくる。

「アホ」で片付けるのが簡単なんだが、説明してやんないと脳内妄想
で、つけあがる。だれか、説明してやってくれ。俺には気力がない。

830 ：仕様書無しさん：02/12/05 23:43

おまいら、あんまりこだわり過ぎると禿げますよ。

831 ：仕様書無しさん：02/12/05 23:43

>829
放置すれば寂しくなって、そのうち消えるって。

832 ：仕様書無しさん：02/12/05 23:45

>830
逆に、あまりに拘ってないコードをメンテさせられて禿げてるヤツも多いと思われ。

833 ：仕様書無しさん：02/12/05 23:47

>>830
もう禿げてますが何か？

834 ：仕様書無しさん：02/12/05 23:57

>>829
> 説明してやんないと脳内妄想で、つけあがる。

煽られて引っ込みがつかなくなってるだけで、自分でも自分の意見が
屁理屈だって、分かってるんじゃない?
都合の悪い書き込みには、見えない振りしてぜんぜん反論してないし。

835 ：仕様書無しさん：02/12/05 23:58

>>834
都合の悪い書き込みって具体的にはどれよ？

836 ：仕様書無しさん：02/12/06 00:01

>835　>>768　

837 ：仕様書無しさん：02/12/06 00:04

>>770
>「お前はバカだ」と言われて、「はい私はバカです」なんて
>答えるバカは滅多にいないからな。

そりゃ、本当のバカは自分をバカといえないわな。

838 ：仕様書無しさん：02/12/06 00:05

「うち～馬鹿やも～ん♪」

839 ：仕様書無しさん：02/12/06 00:06

はっはっは。俺がバカ？よーわかってるなあ
そやで～俺はバカやで～～

と言えるやつは、大抵大馬鹿か自分を理解している知能者

何！俺がバカやと！
バカ言うやつがバカだ！

は、大抵バカ

840 ：仕様書無しさん：02/12/06 00:09

>>839はバカ。

841 ：仕様書無しさん：02/12/06 00:12

>>840
ハゲドウ。
こういう分かったような口ぶりで、意味のない一般化をするやつほど
自分がバカだとわかってない。

842 ：仕様書無しさん：02/12/06 00:13

150は名無しになったのか。最後までコテハンで逝けよ。

843 ：仕様書無しさん：02/12/06 00:14

ばかばかばかばか、ばかっ

844 ：仕様書無しさん：02/12/06 00:15

>>843
わんわんわんわん、わんっ

845 ：仕様書無しさん：02/12/06 00:17

>>837-844
おまいら、もう少しスレタイにこだわって下さい。

846 ：仕様書無しさん：02/12/06 00:18

擦れた胃？

847 ：仕様書無しさん：02/12/06 00:19

　　∧＿∧　　　　　
　（　´Д｀）
　/ ⌒＼　＼　　ばかね♥
　|　　＼　＼＼　　　
　|　　　 |＼　ｖ' ））　　
　|　　　／⌒ー'∥　
　|　　/　　イ　 ||　　
　|　　　　/　|　 ||　　　　　
　＼＿/　　（＿＿つ　

848 ：バカでいいもん。いいんだったらっ。：02/12/06 00:22

えへへー　わたしバカだよおー
ループインデックス探すのにF3キー押しまくっちゃったよぉー
Console.WriteLineの i にも引っかかっちゃって辛かったよぅ
よーやく到着したからデバッグしてたら・・・・・・・・・・・・・・・・・・・・・
インデックスの j と i 入れ間違えてた（汗）あはははは（大汗）

直そうと思って一括置換で「i」→「j」ってやったら大変なことにっ！！（泣）

849 ：仕様書無しさん：02/12/06 00:24

>>841
アホ
>>840
マヌケ
>>843-844
スネークマンショーかいっ（ｗ

エディ～

850 ：晒しage：02/12/06 00:26

>>849
>>839ハッケソ。

851 ：849：02/12/06 00:29

いや・・・・マジで違うんだけど（Ｔ－Ｔ

852 ：晒しage：02/12/06 00:30

>>851
>>849=839ハッケソ。

853 ：仕様書無しさん：02/12/06 00:33

>>848
キモい。氏ね

854 ：晒しage：02/12/06 00:38

>>853
>>852=851=849=839

855 ：仕様書無しさん：02/12/06 00:40

for(i=0;i<10;i++){
　　for(j=0;j<10;i++){
　　　　･･･
　　}
}
だな!

856 ：仕様書無しさん：02/12/06 00:46

>>855
昨日やっちまったよｿﾚ!

857 ：仕様書無しさん：02/12/06 00:49

ばかばかばかばか、ばかっ

858 ：仕様書無しさん：02/12/06 00:54

わんわんわんわん、わんっ

859 ：150：02/12/06 01:15

>>829
どこからカーニハンが出てくるのか、おまいの妄想のほうを問い詰めたいが。
単に折れのオナニー煽りにムカっときて煽り返したが、心が収まらないので
本題すら覆してやろうとして挫折したんじゃないのか？もしかして。

>>835
同感。どれよ？

>>842
今帰ってきたよ。風呂から。
コテハン通すつもりだよ。

860 ：829：02/12/06 01:16

>>859
だから、ちょっとは頭使うとか勉強するとかしたら？

861 ：仕様書無しさん：02/12/06 01:34

みんなよく使う略語ってなに？
たとえば
number -> num
見たいな感じで
おれは
tmp, err, val, buf, msg, max, min, sum, ans,とかかな。
ありきたりだが。

862 ：仕様書無しさん：02/12/06 01:39

Number -> Noはやめて欲しいな。

863 ：150：02/12/06 02:01

>>860
はあ？
相変わらずハズした煽り方しか出来ないヤツだなあ。
しかも、ここに至っては会話にもなってない。
おまいの「だから」は何にかかってるんだ？

どんな書き込みに対しても「アホ」「頭つかえ」しか言えねーんだろな。

864 ：829：02/12/06 02:17

>>863
思考力のなさと、無知をさらけ出しているのでそれを指摘しているだけですが。

指摘されても何を指摘されているかすらわからないなら、日本語から
勉強しなおしては？

865 ：仕様書無しさん：02/12/06 02:18

>>861
>tmp, err, val, buf, msg, max, min, sum, ans,とかかな。
ansをアヌスと読んだやつは、オレ一人ではあるまい。

866 ：150：02/12/06 02:23

>>864
はっは。おまいは真性だな。
おまいのどこに指摘部があるのやら。
折れの指摘にまったく反論出来ていないという部分が、おまいの無能さを
証明しているな。

あ、あたかも理論的な書き込みをしているフリをする新手の煽りか？(藁
そうか、ごめんごめん。煽られておいてやろう。努力賞だ。

カーニハ～ン！>829がいぢめるよ～。ｳｪｪｪｪｪﾝ

867 ：仕様書無しさん：02/12/06 02:24

>861
obj, vec, mat, tex(ture), i(nterrupt), pt, wnd, dc (device context),
db, app, enc(encode, encrypt), prim(itive) とかか。

868 ：150：02/12/06 02:28

>>867
ほとんど同意出来ん。
ひどいぞ。

869 ：仕様書無しさん：02/12/06 02:31

ハンドルかどうかの区別がつかない問題と
enc, primが解説付きじゃないと理解出来ない

870 ：150：02/12/06 02:31

というか、i(nterrupt)はないだろ。

871 ：仕様書無しさん：02/12/06 02:35

今読んでた本の中で、識別名と表意名の違いについて書いてた。
変数名には、識別するための工夫と、表意するための工夫の両方が
必要なんだろうね。
識別に有利な名前の付け方と、表意に有利な名前の付け方を分けて
考えてみては？

872 ：仕様書無しさん：02/12/06 02:53

>869
単体で出てくるとアレだが、コード中だとだいたい分かる。

prim は 3D 描画プリミティブ (POINTLIST とか TRISTRIP とか) 関係で使って
るんだが、開発用ライブラリでも頻繁に primXXX って名前が出てくるし。

873 ：仕様書無しさん：02/12/06 04:10

iiって変数名にすると、２ちゃんねらーだと言われるからiiだけはぜったいにやらない

874 ：仕様書無しさん：02/12/06 06:23

iiって変数名にすると、おさるさんだと言われるからiiだけはぜったいにやらない

私事恐縮だが、iiといえば元カノ思い出すなぁ。

875 ：仕様書無しさん：02/12/06 07:01

自分なら、コードを見ればだいたいわかる変数名
→新人にとっては、コードと睨めっこしないと分からない変数名

876 ：仕様書無しさん：02/12/06 10:11

>>875
で、おまいのコードは新人が見てすぐわかるようなコードなのかね?

877 ：仕様書無しさん：02/12/06 10:16

手数を惜しんで頭の負荷を増やす奴は愚か者。

878 ：仕様書無しさん：02/12/06 10:24

相手の日本語能力をやたら気にするわりには、

>>729
> 「危険」の意味をそのまんまマジで取るなよ。
> 「弊害」なら分かるか？

醜態晒してるな。

879 ：仕様書無しさん：02/12/06 10:26

つーか、検索や置換の危険性って何？
「単語ごとに検索／置換」のオプションをチェックするだけでしょ？
それとも、そういうオプションのないエディタにしがみついてるの？

880 ：仕様書無しさん：02/12/06 10:29

>>742
ちゃんとviolate付けてるか？
グローバル変数には全部つけるんだぞ。

881 ：仕様書無しさん：02/12/06 10:35

volatile?

882 ：仕様書無しさん：02/12/06 11:48

>>877
たいして効果無いのに手数ばかりかける奴は愚か者。

883 ：仕様書無しさん：02/12/06 11:59

こんなとこで、ぬるぽ

884 ：仕様書無しさん：02/12/06 12:00

なんか一日ぶりに見たら、途中からだんだん150のレスが尊大になって
きて粘着になってきてるな。

「オレの言ってることのどこがおかしい、反論できないだろ、馬鹿」って
言ってるみたいだけど、そもそもの発端は

　「一文字の変数名は検索や置換のとき『恐い』から使えない」

という発言はおかしいんじゃないの？って話で。
でもっておかしいことはもうはっきりしたわけで。

これ以上ここにしがみついて「ば～か、ば～か」って言い続けてる
意味はあんのか？

885 ：仕様書無しさん：02/12/06 12:02

どうしようもない糞スレに成長しましたな。

886 ：仕様書無しさん：02/12/06 12:51

まぁ少なくとも極論どうしがぶつかってることは確かなようですな。

887 ：仕様書無しさん：02/12/06 13:03

ばかばかばかばか、ばかっ

888 ：150：02/12/06 13:04

折れは阿呆粘着に構ってやってるだけよ。
>884も同じだな。話をそらして「そもそもの発端は」なんて言い出すから
ループするんだよ。
>878みたいな低レベルも多いからな。

まったく手応え無いカキコが多くてスマンな。
ヤツらの代わりに謝っとくよ。

889 ：仕様書無しさん：02/12/06 13:22

　（　・∀・）　　　|　|　ｶﾞｯ
　と　　　　）　　 |　|
　　Ｙ　/ノ　　　人
　　　 /　）　　 < 　>__Λ∩
　＿/し'　／／. Ｖ｀Д´）/ ←>>883
　（＿フ彡　　　　　　　/

890 ：仕様書無しさん：02/12/06 13:23

> >878みたいな低レベルも多いからな。

ﾌﾟ
何でそういう指摘が出てきたか理解してないでやんの

891 ：仕様書無しさん：02/12/06 13:27

>>888
で、879 に対する反論は？

892 ：仕様書無しさん：02/12/06 13:29

ちなみに、i を j に変える事で既存の j と衝突する問題は、SomeValue を
SomeVriable に変更する場合でも発生する。
変数名が 1 文字かどうかは関係ない。

893 ：150：02/12/06 13:30

>>890
というか、阿呆なおまいらに分かりやすいように言葉替えて説明して
やったんだが、やはり理解出来ずに煽りネタに使うしかなかったんだなあ。
おまいら、煽りレベル低いぞ。他のヤツらに迷惑だからカエレ！

894 ：仕様書無しさん：02/12/06 13:41

>>893
どうせお前、ぬるぽなんだろｗ

895 ：仕様書無しさん：02/12/06 13:44

ばかばかばかばか、ばかっ

896 ：150：02/12/06 13:46

>>891
ん？
別にそういう機能が無いものにしがみついてる訳ではないが？
「毎度」言ってるように、１文字変数を否定してる訳じゃないんだよ。
ものの考え方について言ってる。

語単位の検索・置換が出来るから折れは１文字変数でいいんだと言うなら
それでいいんだよ。
それが出来ないなら他の工夫が必要だって話で、ならば２文字以上の変数
ってのも１つの案だろ？って話なんだよ。

おまいらは「現実的にこうだから不要なんだ～」っていうスタンスだが、
折れは「あらゆる可能性・危険性について予測・回避能力を付けとこう」
っていうスタンスだ。

897 ：150：02/12/06 13:52

>896
ハンガリアン論争にも言える事だな。

898 ：仕様書無しさん：02/12/06 13:54

>>896
最初のころといってることが全然違う気がするが・・・。

まあこういうタイプは最後まで「間違えました」と言えない人だから
しょうがないね。

再掲：
（>>655）
649じゃないけど断然後者。
windowsアプリになってから、長い変数名が当たり前になってきて
ちょびっと疲れる３０代。
どうでもいいが、ループ変数はいつもiiとかjjにしているなあ。
検索や置換時、一文字変数は怖いから。

（>>658 by 「150」）
>>656,657
おまいらはどう解釈してんだ？
折れは>655の言ってる意味が分かるから、変だともレベルが低いとも思わんが。

１文字変数を置換する時、関係ない変数、関数まで置き換える危険性がある
って意味だろ？

899 ：仕様書無しさん：02/12/06 13:54

> 「あらゆる可能性・危険性について予測・回避能力を付けとこう」

つまり、年月日を扱うプログラムを書くときはいつでも RFC2550 に対応させている
という事か？
仕事なくすからやめとけ。

900 ：仕様書無しさん：02/12/06 13:57

>>898
見にくいから今度から引用符つけてくれな。

901 ：仕様書無しさん：02/12/06 13:59

ぶぁっはははははーーーっ！！
何の脈絡もなく取って付けたようにハンガリアン論争だと！？
ぶぁっはははははーーーっ！！
ぶぁっはははははーーーっ！！

902 ：150：02/12/06 14:10

>>898
「１文字変数を置換する時、関係ない変数、関数まで置き換える危険性がある
って意味だろ？」
最初から言ってること同じだと言うことをわざわざ証明してるじゃないか。
アホかおまいは。
>655も後で折れの言っていることで正解だと言ってただろ？

最後まで「間違えました」と言えないのはおまいだろ。
もしかして、strcmp(元の文,現在の文)==0にならなければ言っていることが
違うとでもいうのか？（一言一句同じでないと認められない）
うーん。電波。

>>899
いずれ必要だと（可能性がある）思うなら採用するだけの話。
長期にわたって無用（可能性が無い）だと思うなら不採用にするだけの話。

だーら、「絶対にこうしろ」なんて言ってないだろ？折れは。

>>901
いつまでも足らん子だなおまいは。

903 ：仕様書無しさん：02/12/06 14:21

>>902
見苦しいな。
「置換や検索のミスを防ぐために一文字変数名を使わないように
している（あまつさえ恐い、とまで言ってる）」
というのは「ヘンじゃないか？」ってのがずーっとみんなが言いつづけてる
ことで、あんたは「ヘンではない、危険を避けるという意味では当然じゃないか」
と言ってるんだろ？
だから「そんなところにヘンにこだわらなくてもそんな危険に遭わない工夫は
いくらでもあるんだから、無意味じゃん」で結論出てるだろうが？

だから
> 「絶対にこうしろ」なんて言ってないだろ？
あんたが「絶対にこうしろ」と言ってる、なんてだれも言ってないんだが。

904 ：仕様書無しさん：02/12/06 14:22

いいから 892 に反論してくれよ。

905 ：仕様書無しさん：02/12/06 14:24

> 「１文字変数を置換する時、関係ない変数、関数まで置き換える危険性がある
> って意味だろ？」

ちなみに、2 文字以上の変数でも同じ問題は発生する。

906 ：仕様書無しさん：02/12/06 14:24

「街を歩いてたら、逆ナンパされてホテル行ってエッチしてナマで中出しして
相手を孕ませて、望まないできちゃった結婚させられる危険性があるかも
しれないから、オレはコンドームを持ち歩いてます」
ていうようなレベルだわな。ｗ

・・・もちろん「それでもいいじゃないか」って言えば「そうだね」で終わりだが。

907 ：仕様書無しさん：02/12/06 14:30

つーか漏れは、別の部分に置換検索が及ぶのが怖い時、別のエディタウィンドウに
コピペしてから行っている。
もっとも、VC++ の MSDEV なら選択したテキストに対して置換検索ができる。

「あらゆる可能性・危険性について予測・回避能力を付けとこう」というなら、
そういう機能があるエディタを手に入れるぐらいした方がいいだろう。

変数名を、置換検索対策の為にいじろうとするのは何かおかしい。

908 ：150：02/12/06 14:41

>>903
なに勝手に「無意味」だという結論にするんだ？
>655が「恐い」といった真の意味は折れが解説した通りだったんだろ？

おまいらが「無意味」といくら言い張っても、意味がある人にとっては
意味があるんだ。
おまいらは書き方は「意味がある人」すら否定した書き方じゃないかよ。

>>904,892
なんでそんな例えに例えで返すような話になるのかね。不毛な気がするが？
i -> j置換はあくまでも例え。主張を分かり易く伝える意味でしかなく、
例え自体に例えで返すのではなくて、主張自体に反論があるのかないのか
を明確にした上で、反論してくれ。

>>906
ま、その通りさ。
今までは「そうだね」じゃなくて「不要だ」で終わらせるヤツばかり
だったからな。

909 ：仕様書無しさん：02/12/06 14:42

>>902
> いずれ必要だと（可能性がある）思うなら採用するだけの話。

固定桁の年月がいつか破綻するのはわかりきっている話。
つまり、採用するわけだな、RFC2550 を。
がんがれよ。

910 ：仕様書無しさん：02/12/06 14:44

>>908
> 例え自体に例えで返すのではなくて、主張自体に反論があるのかないのか
> を明確にした上で、反論してくれ。

例が不適当なら主張は普通伝わらない事を理解してくれ。

911 ：150：02/12/06 14:45

>>907
> 「あらゆる可能性・危険性について予測・回避能力を付けとこう」というなら、
> そういう機能があるエディタを手に入れるぐらいした方がいいだろう。
それも一手だ。
しかし、そういう機能があるエディタを使いこなせない素人の対処とかを
考えてしまうんだよね。折れは。
だから、
> 変数名を、置換検索対策の為にいじろうとするのは何かおかしい。
と言い切られると、ちと困る。

912 ：仕様書無しさん：02/12/06 14:47

> なんでそんな例えに例えで返すような話になるのかね。

(ﾟДﾟ)ﾊｧ?
例えに例えで返してるんじゃなくて、それは例えにならないと否定しているんだが。

913 ：仕様書無しさん：02/12/06 14:50

> しかし、そういう機能があるエディタを使いこなせない素人

一つ例を挙げよう。
フリーのテキストエディタ TeraPad。
これが使えない人はおそらく PC に関して素人だから、プログラムなどいじらせない方がいい。

第一、検索／置換のダイアログにでんと出てくるオプションをチェックする事が
そんなに難しい事なのか？
検索／置換に強い名前なんか考えているよりずっと易しいはずだが。

914 ：150：02/12/06 14:52

>>909
いつか・・・っていつだよ？
開発してるシステムがいつまで使われるのか次第だろ。
100年も1000年も寿命があると思われるなら採用しとけ。

>>910
伝わってないなら折れの力量が足らんということだ。すまん。
しかし、例えに例えで返す以前に、おまいのスタンスが分からんから、
例えだけでは返事しようがない。

915 ：仕様書無しさん：02/12/06 14:52

TeraPad、ちょうど今 v0.75 にバージョンアップしたな。

916 ：150：02/12/06 14:53

>>912
あー、そういうことね。わかった。ごめんよ。

917 ：仕様書無しさん：02/12/06 14:54

一括変換かけてソースを壊してしまうような素人までを想定して
コーディングルール決めるより、そういうのは雇わないほうが
いいと思うよ。

918 ：仕様書無しさん：02/12/06 14:58

>>917
そもそも、そういうのはコーディング規則で救えないような気がする。

919 ：仕様書無しさん：02/12/06 15:00

> > 変数名を、置換検索対策の為にいじろうとするのは何かおかしい。
> と言い切られると、ちと困る。

何で？
変数名は、置換検索のためにあるんじゃない。
エディタとかの支援が使えない場合の最終手段というならわかるが、率先して
変えてしまっていいものじゃない。

920 ：150：02/12/06 15:01

>>913
大概はおまいの言う通りだよ？
前に書いたが、検索・置換範囲の問題もある。>907の言うような対処法も
あるし、折れの言う対処法も有効だと思うが？

921 ：150：02/12/06 15:04

>>919
いやだから、置換ついて言えば、「可能性がある」ならば何らかの対処は
必要だと思うし、検索の場合は、トレースで追っかけたりしないの？

922 ：150：02/12/06 15:07

>921
ごめそ。日本語へんだな。
変数は「基本的に」置換対象でないというのは同意。
だが、置換することもあるっしょ？
検索もするっしょ？

923 ：仕様書無しさん：02/12/06 15:10

>>920
> 大概はおまいの言う通りだよ？

つまり、その通りじゃない可能性もあるのか？
どんな場合だ？

924 ：仕様書無しさん：02/12/06 15:10

もう知らないっ　ばかばかばかばか、ばかっ

925 ：仕様書無しさん：02/12/06 15:11

> 折れの言う対処法

892 や 905 が否定した方法の事か？

926 ：仕様書無しさん：02/12/06 15:12

>>924
黙れ。
漏れは今、150 と命がけで討論しているんだ。

927 ：仕様書無しさん：02/12/06 15:14

>>921
> トレースで追っかけたりしないの

ステップ実行はするが、それは変数名と直接関係ないよな。
トレースって何の事？

あと、エディタの支援機能が常に使える状況では、あなたの危惧している
可能性は全く考慮しなくていいんだが。

928 ：150：02/12/06 15:24

>>925
すまそ。「対処法」では語弊があるな。
折れの言っていること＝１文字変数は避けた方がいいんじゃないの？
にしといて。

>>927
トレースって言葉そのまんま。
変数を検索キーにして次々参照して流れを見るとか・・まあ、色々あるわな。
とにかく、「変数を検索キーにして次々参照」はしないのか？ってことで。

> あと、エディタの支援機能が常に使える状況では、あなたの危惧している
> 可能性は全く考慮しなくていいんだが。
いいんじゃないのー？
そういう状況が前提なら。
とにかく、お互いの前提条件が違うと「こうすべき」という論法は成り立たない
ってことだ。

929 ：150：02/12/06 15:25

>>923
>920の下２行

930 ：仕様書無しさん：02/12/06 15:28

>>911
> しかし、そういう機能があるエディタを使いこなせない素人の対処とかを
> 考えてしまうんだよね。折れは。
つまり、「自分はお寒い職場にいるんです」と主張しているんですか？
そんな幼稚園児の保母さんみたいなことをやって暇があるなら
転職でもすれば。少なくとも俺の職場では試用期間中にエディタも
使いこなせない素人は試用期間が終了したらいなくなってるけどな。

931 ：仕様書無しさん：02/12/06 15:30

>>928
> １文字変数は避けた方がいいんじゃないの？

突っ込みたいが、どうも話がループしそうだ。

> 、「変数を検索キーにして次々参照」はしないのか

漏れはあんまりしないね。
するにしても、それこそ単語単位で検索できるエディタの出番だ。

> 前提条件

漏れはこうだ。
仕事場でなら、エディタは統一。
フリー等で出まわっているソースは「自己責任」が基本。

932 ：仕様書無しさん：02/12/06 15:31

>>928
> とにかく、「変数を検索キーにして次々参照」はしないのか？
しますけど何か？
一文字変数でも正規表現を使えば他の文字にヒットさせない方法はある。
二文字変数でも他の文字にヒットしてしまう可能性はある。

つまり、君はエディタすら満足に使いこなせない素人ですか？

933 ：仕様書無しさん：02/12/06 15:32

>>929
> 第一、検索／置換のダイアログにでんと出てくるオプションをチェックする事が
> そんなに難しい事なのか？

に対する返事が

> 前に書いたが、検索・置換範囲の問題もある。

なのか？
意味が通らないぞ。

934 ：仕様書無しさん：02/12/06 15:33

>>932
堂々廻りになるから、正規表現の話はやめてくれ。

935 ：仕様書無しさん：02/12/06 15:40

>>934
> 堂々廻りになるから、正規表現の話はやめてくれ。
了解、じゃあ
150がグローバル変数を一文字で宣言しているような
どうしようもない馬鹿では無いと仮定すると、
ローカル変数を検索するような事態に陥った時点で
関数の分割を考えられないような馬鹿である。

という結論でいいかな？

936 ：仕様書無しさん：02/12/06 15:50

え？
関数の分割が何の関係あるの？

937 ：936：02/12/06 15:52

ごめん、検索に限った話ね。

938 ：150：02/12/06 16:03

>>930,931
だから、おまいらがそれでいいんならそれでいいじゃんかよ。
ウチではエディタの統一はされていない。好きな物つかう傾向があるな。
賛否両論があるだろうが、嫌いなエディタは強制されたくないしな。折れは。

>>933
ごめんな、もっと明確に書くべきだったか？
> 第一、検索／置換のダイアログにでんと出てくるオプションをチェックする事が
> そんなに難しい事なのか？
難しくないよ。
しかし、
> 前に書いたが、検索・置換範囲の問題もある。
だろ？という意味で書いた。
下のも読んでくれ。それで意図が伝わると思う。

>>935
アホかい。
関数を分割してても、同一ソースで別の関係ない場所まで置換・検索
する可能性もあるだろって、前にも書いただろうが。
もちろん、これもツールで回避出来る内容ではあるが。

939 ：仕様書無しさん：02/12/06 16:05

>>938
> 関数を分割してても、同一ソースで別の関係ない場所まで置換・検索

適切に分割されていたら、変数の検索なんて要らないという話だと思われ。

940 ：仕様書無しさん：02/12/06 16:08

>>933
> 賛否両論があるだろうが、嫌いなエディタは強制されたくない

気持ちはわかるが、ソースコードの置換や検索に不向きなエディタを使う事は
妥当とは言えない。

> 検索・置換範囲の問題もある。

検索／置換のダイアログにでんと出てくる「選択範囲のみ検索」オプションを
チェックする事がそんなに難しい事なのか？

941 ：150：02/12/06 16:09

>>939
ケースバイケースだろ。
複雑な処理、変数量が多ければ、短い処理でも検索することがあるし。
なんでおまいら、いつもそんな簡単に答えが出せるんだ？
事前に危険を意識しておくか、いきあたりばったりで対応するかの差か？

942 ：仕様書無しさん：02/12/06 16:13

> 検索・置換範囲の問題もある。

別々の関数で同じ変数名使ってたら、変数名の長さがどうのこうのなんて関係ないじゃん。

943 ：仕様書無しさん：02/12/06 16:15

> 変数量
> 短い処理

相反する言葉ですな。

944 ：150：02/12/06 16:15

>>940
すまんが、置換・検索範囲の指定に手間がかかるのだよ。折れのエディタは。
というか、検索範囲は指定出来ないな。折れのエディタ(MIFES)もVC++も。
しかし、あらかじめ選択範囲を指定するのも面倒な気がしなくもないぞ。
置換はまだいいとして、検索はなぁ。
ま、たしかにエディタにこの問題を解消してもらうのが楽には違いないが、
自己対処する努力は別に無駄と言うほどのものでもないだろ？

945 ：仕様書無しさん：02/12/06 16:15

>>941
> 事前に危険を意識しておくか、いきあたりばったりで対応するかの差か？

違うと思う。
>>906の言ってるような感じ。
「危険といえば危険ではあるかも知れないが、そもそもその前にそういう
状況にならないような前提があるほうが普通だろ」ということだと思われ。

「山で熊に出くわしたとき、大声だしたら危険だよ」って言われても
「いや、おれそもそも山なんか行かないし」ということ。

946 ：仕様書無しさん：02/12/06 16:17

そろそろ次スレという頃合いなので、スレタイに沿ってまとめてみると

　と　り　あ　え　ず　150　は　変　数　名　に　か　な　り　こ　だ　わ　り　ま　す

という結論でよいかと。

947 ：仕様書無しさん：02/12/06 16:18

「そういう機能を持つエディタを使う」という解を遠のけて、892 や 905 が指摘
したような問題を無視してまで、変数名の改変による検索置換効率を上げる方法を
推し進める理由は何だ？
第一、常に危険を意識してるような香具師が検索置換でミスしたりしないだろ。

948 ：仕様書無しさん：02/12/06 16:18

みんな、150 はWindowsのメモ帳しか使えないんだYO。
苛めないでやってくれ。・°・(ノД`)・°・。

949 ：150：02/12/06 16:20

>>942
つまり、１文字変数を採用しつつ、別々の関数で別の変数名を付けるのも
不可能と言える訳で。
あの～いつの間にか２文字以上ならＯＫだと折れが言っているように解釈
されているようだが、そんな単純な答えは出してないぞ？折れは。
つい最近の書き込みだけで見ればそう見えるんだろうな。

>>943
相反してても、成り立つこともある。
経験したことないのか？

950 ：仕様書無しさん：02/12/06 16:21

> 検索範囲は指定出来ないな。折れのエディタ(MIFES)もVC++も。

VC++ はできますが何か？

951 ：仕様書無しさん：02/12/06 16:25

>>949
> 相反してても、成り立つこともある。
> 経験したことないのか？

一関数の数量が多いというのは経験した事がない。

952 ：仕様書無しさん：02/12/06 16:28

> ま、たしかにエディタにこの問題を解消してもらうのが楽には違いないが、
> 自己対処する努力は別に無駄と言うほどのものでもないだろ？

違う。
プログラムの内容に拠らない変数名の変更は間違っていると言っている。

953 ：150：02/12/06 16:28

>>945
なるほどね。
ちゅーか、それならいいんだが、「山なんか行ってんじゃねーよ。馬鹿。」
と言ってたヤツが多いと思うが。

>>946
いいよ。それで。
おまいらは変数名に全然こだわりません。
という結論も入れておいてくれ。

>>947
別に指摘された問題を無視してないが・・・・。
というか、ハナからずれたレスだぜ？あれは。
誰が「２文字なら完璧です」なんて言ったんだ？

>>948
VC++標準エディタが良いとは思わんが、使っちゃいけない・使うと厨房的
だという理由はあるのか？

954 ：150：02/12/06 16:31

>>952
だからそれは了解済みだって。
検索は？って。

955 ：仕様書無しさん：02/12/06 16:36

> 誰が「２文字なら完璧です」なんて言ったんだ？

１文字を２文字にしたら、なにかマシになるのか?

956 ：仕様書無しさん：02/12/06 16:38

>>953
> おまいらは変数名に全然こだわりません。
> という結論も入れておいてくれ。

違うね。
漏れらは、あんたと違って、そんなくだらない事では変数名を変えたりしない
というこだわりを持っている。

957 ：仕様書無しさん：02/12/06 16:38

>>953
> ちゅーか、それならいいんだが、「山なんか行ってんじゃねーよ。馬鹿。」
> と言ってたヤツが多いと思うが。
いや、それも微妙に違う。
そうではなくて
「コーディングするのにわざわざ山なんか行ってんじゃねーよ」
だと思う。

958 ：仕様書無しさん：02/12/06 16:39

> VC++標準エディタ

(　´д)ﾋｿ(´д｀)ﾋｿ(д｀ )

959 ：仕様書無しさん：02/12/06 16:42

>>953
> 使っちゃいけない・使うと厨房的
> だという理由はあるのか？

Windows メモ帳の話が、何で MSDEV にすり替わるんだ？
まあ、Windows メモ帳だとして、ソースコードに対して検索置換をかけるのに
ふさわしくないエディタを選ぶ事の何が悪くないと言うんだ？

960 ：仕様書無しさん：02/12/06 16:43

いい加減諦めてくれよ。
検索置換の問題は、変数名の長さと直接関わりないんだってば。

961 ：150：02/12/06 16:53

>>955
何％とか。

>>956
あんた、未だに置換にこだわってるね。しかも、ちょっとズレてきてるね。
折れの例えに問題があるということで終わってたんじゃねーのか？

>>957
スタンスは同じ気がする。

>>959
折れはそれ以前からVC++orMIFESだと書いてるにもかかわらずメモ帳
だと勘違いしてるから、暗に訂正やって書いていたのだが。
メモ帳だとして話を進める意味がどこにある？

>>960
なんでそこまで執着するんだか。
そういうおまいらは、変数を置換しない。
折れは必要に応じて置換することもある。
それだけのことだ。

962 ：150：02/12/06 16:55

>>950
見逃してた。
VC++で検索範囲指定できるか？
できねーぞ？
折れのはVC6だが。

963 ：仕様書無しさん：02/12/06 16:59

>>961
> 何％とか。

ふうん。
あんまり効果ないんだね。

> あんた、未だに置換にこだわってるね。

956 のどこをどう読んだら置換の話になるんだ？

> メモ帳だとして話を進める意味がどこにある？

メモ帳と仮定する必要は確かにないね。
でも、そんな事にとらわれて、その後に書いてあるその人の言いたい事を読み
飛ばすようじゃ修行が足りないね。

> 変数を置換しない。

するよ。
ただし、その場合には置換をかけて問題がないか調査する。
それは変数名に工夫が施してあっても一緒だろ。
だったら意味ないじゃん。

964 ：仕様書無しさん：02/12/06 17:01

>>962
置換はあるけど、検索はなかったね。

965 ：仕様書無しさん：02/12/06 17:06

MIFESってダサイな。
インストールして少し使ってみたが、
何で置換には開始行と終了行が指定できるのに検索では指定できないんだ？
マーキングはできるのにマーク指定で検索や置換ができないんだ？

貧弱なエディタを使っていると貧弱な発想しかできなくなるんだね。
MIFESとかメモ帳とか貧弱なエディタを使ったり、素人がソースをいじるような
職場なんかにいるとそういう羽目になる。

966 ：仕様書無しさん：02/12/06 17:08

つーか、MIFES って独自のショートカットキー引きずっててキライ。
テキストを編集するために使うのであって、エディタを覚えるために使うわけじゃないのに。

967 ：150：02/12/06 17:09

>>963
>> 何％とか。
> ふうん。
> あんまり効果ないんだね。
おいおい、もっと深読みしろよ。
前にも書いたが、２文字以上より３文字以上、短すぎず長すぎず、
明示的な名前が最適だと言っとる。

>> あんた、未だに置換にこだわってるね。
> 956 のどこをどう読んだら置換の話になるんだ？
「そんなくだらないことで変数名を変えたりしない」って書いてるじゃんか。
ということは、置換が主題じゃないのか？

> メモ帳と仮定する必要は確かにないね。
> でも、そんな事にとらわれて、その後に書いてあるその人の言いたい事を読み
> 飛ばすようじゃ修行が足りないね。
だから、折れはVC++はふさわしくないのか？という意味で聞いている。

> ただし、その場合には置換をかけて問題がないか調査する。
当然だ。
しかし、変数名に工夫している方が調査の役にも立つと折れは思うが。
調査に役立てないなら、確かに無意味だわな。

968 ：仕様書無しさん：02/12/06 17:10

大体、プログラム組む人が、検索や置換に困るような事があるのか？

969 ：150：02/12/06 17:12

>>965
検索・置換に関してはだけで判断してしまえるのか？
折れはともかく、他のマイフェッサーから反論が来そうだが。

つか、やはり検索に関してはVC++も同じじゃねーかよ。

おまいは何使ってるんだ？

970 ：仕様書無しさん：02/12/06 17:18

>>967
> 前にも書いたが、２文字以上より３文字以上、短すぎず長すぎず、
> 明示的な名前が最適だと言っとる。

でも、それでも結局別関数と突合するよね。
例えば、Windows で hWnd だらけなのはよくある話。
hWnd はいつも同一かまたは不特定のウィンドウを指してる事が多いから、
ヘタな修飾をするとプログラムが分かりづらくなるので本末転倒。

> 「そんなくだらないことで変数名を変えたりしない」って書いてるじゃんか。
> ということは、置換が主題じゃないのか？

そこで言っている「変える」は、あんたの言っている「置換検索がしやすい
ように変数名を変える」のことであって、置換の話じゃない。
人の日本語能力を気にする割に、あんたの方は大丈夫なのか？

> だから、折れはVC++はふさわしくないのか？という意味で聞いている。

置換であればいいんじゃないの？
意図する範囲内で検索したいという場合には不適当だろう。
それくらい自分で考えて判断できないか？

> しかし、変数名に工夫している方が調査の役にも立つと折れは思うが。

本当か？
仮に ii とか書いてあったりして、しかしコメントでも振っていなければそうとは
気付かない。

971 ：仕様書無しさん：02/12/06 17:21

>>969
> 検索・置換に関してはだけで判断してしまえるのか？
エディタの重要な機能って検索・置換だろ？
あと、他のツールと組み合わせられるような柔軟性や拡張性だろう？

> おまいは何使ってるんだ？
vi(winの場合はvim or vivi)ですが何か？
ちょっと使ってみた感想としてはMIFESは秀丸より多少ましな
糞エディタだということはわかった。

972 ：仕様書無しさん：02/12/06 17:30

例えばローカル変数iをjに置換したい場合、
MIFESはいちいち関数の開始行数と終了行数を調べて、
置換開始行と終了行に入力する必要がある。
一文字置換自体はMIFESにも正規表現があるんで問題ないが、
置換開始行と終了行を調べるのが面倒。

viの場合、[[で関数の先頭にジャンプしてmaでマーキングして
%で関数の終了にジャンプして:'a,.s/\<i\>/j/gで終わり

973 ：仕様書無しさん：02/12/06 17:39

漏れの場合は、色分けとインデントの方が重要だと思うけどね。
検索や置換はほとんどしない。

974 ：仕様書無しさん：02/12/06 17:44

検索にヒットした部分を色分けしてくれる、サクラエディタ最強

975 ：仕様書無しさん：02/12/06 17:47

>>973
> 色分けとインデントの方が重要だと思うけどね。
MIFES, 秀丸, vimあたりはそこら辺はクリアしてる。
というか色分けができないエディタってメモ帳ぐらいしか思いつかない。

> 検索や置換はほとんどしない。
まさか編集もしないとか言わないだろうな。
それならばエディタではなくてビュワーじゃないか？
まぁ、優れたエディタは優れたビュワーでもあるけどね。

976 ：仕様書無しさん：02/12/06 17:48

どっちかと言うと、エディタを選ぶより変数名を変えてしまう方が場当たり的じゃないか？

977 ：仕様書無しさん：02/12/06 17:53

>>976
> 変数名を変えてしまう方が場当たり的じゃないか？
リファクタリングでは変数名/関数名を変えることは
日常茶飯事ですが何か？

仕様変更などで関数／変数の持つ意味が変わってしまった場合、
適切な名前に変更するべきであり、また変更しやすいエディタを
使いこなせることがプロとしての態度だと思うが？

978 ：仕様書無しさん：02/12/06 17:53

俺、たまにメモ帳でソース書くよ。
でかいプロポーショナルフォントで、長い変数名を使ったコード書くと、英文書いてるみたいな気分になるのさ。
気分転換したいときは、メモ帳だね。

979 ：仕様書無しさん：02/12/06 17:54

あ、ただ、１文字変数の意味が変わるケースってあんまり思いつかないけどな。

980 ：150：02/12/06 17:57

>>967
>ヘタな修飾をするとプログラムが分かりづらくなるので本末転倒。
ま、どこまで装飾すれば良いのかは人それぞれだろう。
１文字変数使ってしまって、全く分からない状況よりはマシだと
思えるなら無駄ではないし、そう思えないなら無駄なんだろう。

>そこで言っている「変える」は、あんたの言っている「置換検索がしやすい
>ように変数名を変える」のことであって、置換の話じゃない。
>人の日本語能力を気にする割に、あんたの方は大丈夫なのか？
変な解釈するなよ。
折れは「置換検索がしやすいように変数名を変える」と言ってるんじゃなくて、
「普段から良い名前付けしとけ」に言ってるに過ぎない。
別におまいの現行ソースを修正しろとまで言ってないぜ？
そんなのはおまいの自由だ。でもまあ、現行ソースを修正しなきゃいけない
と感じてるなら、結局は置換の話に辿り着くと思うが。

>> だから、折れはVC++はふさわしくないのか？という意味で聞いている。
>置換であればいいんじゃないの？
>意図する範囲内で検索したいという場合には不適当だろう。
>それくらい自分で考えて判断できないか？
はあ？なにそれ？
おまいは、名前付けの工夫をするのが無駄だと言い、エディタでなんとでも
なるような事を言っているからには、最適なエディタがあるわけだろ？
それを書けよ。

>> しかし、変数名に工夫している方が調査の役にも立つと折れは思うが。
>本当か？
>仮に ii とか書いてあったりして、しかしコメントでも振っていなければそうとは
>気付かない。
iiみたいな名前付けならそうだろうな。

981 ：末吉亮介：02/12/06 17:58

http://genie.gaiax.com/home/ffppppffpfp

982 ：150：02/12/06 18:00

>>971
まあね。
ただ、>967もそうだが、そこまで言うからには、プロならxxxエディタを
使うのが常識というものがあると言いたいんだろ？

とりあえず、vimか？　見てみるわ。

983 ：仕様書無しさん：02/12/06 18:01

5行だ。
ひとつ確かなことは、それより大きいブロックで一文字変数を見付けたときには、俺はぷっつんするだろうってことだぜ！

984 ：仕様書無しさん：02/12/06 18:14

>>980
> １文字変数使ってしまって、全く分からない状況よりはマシだと

確かに、単なるループカウンタの i の意味が全く分からない状況は
問題だな。

> 折れは「置換検索がしやすいように変数名を変える」と言ってるんじゃなくて、
> 「普段から良い名前付けしとけ」に言ってるに過ぎない。

それは置換検索の問題の解決にはならない。
「良い名前付け」が関数別にユニークな変数名を産む事を押さえることには
普通ならない。

> おまいは、名前付けの工夫をするのが無駄だと言い、エディタでなんとでも
> なるような事を言って

言っていない。
どこに常にエディタに頼れと書いてある？
ちなみに 907 を書いたのも漏れだが・・・。

「良い名前付け」には基本的に賛成だが、それで置換検索の問題に充分
対応できるわけではない。
なのに「名前付けの工夫も有効」なんて言うのは、「置換検索の問題は
変数名を変えて対処せよ」と言ったのと同然ではないか？

> >仮に ii とか書いてあったりして、しかしコメントでも振っていなければそうとは
> >気付かない。
> iiみたいな名前付けならそうだろうな。

ii じゃなくても、もっと長い名前でもそうとは気付かない。
試してみればいい。

985 ：984：02/12/06 18:15

> 「良い名前付け」が関数別にユニークな変数名を産む事を押さえることには
> 普通ならない。

訂正。
「良い名前付け」が別々の関数に同じ変数名を産む事を押さえることには普通
ならない。

986 ：仕様書無しさん：02/12/06 18:21

class A
{
　int count, maxCount;
　A(int arg_count, int arg_maxCount) : count(arg_count), maxCount(arg_maxCount) {}
};

最近、C#のサンプルの影響で、メンバ変数はaaBbbCccの形式です。
上の例でコンストラクタの引数に"arg_"と付けているところが気持ち悪いのです。
A::A(int count, int maxCount) : count(count), maxCount(maxCount) {}
↑これができれば一番いいんだけどね。こんなときはみなさんどうしてます？

987 ：仕様書無しさん：02/12/06 18:22

>>982
> そこまで言うからには、プロならxxxエディタを
> 使うのが常識というものがあると言いたいんだろ？
いいや、でもCやPerl, Javaなどの{}がブロックの開始/終了を示す言語の場合、
vi, emacs系のエディタは他と比べて使いやすいと思う。
また、俺の場合Unixで開発する場合が多いのでWin系のエディタに馴染めない
とかいうのもある。
よって、選択肢としてはvi系とemacs系しかないわけだが、先に洗脳されたのが
viなんで未だにviを使っている。

逆にviを使っていると{}がブロックの開始/終了を示さない言語
例えばVB, Delphi, RubyとかはCとかと比べて非常に編集しにくいと感じる。
その場合はvi以外のエディタを使った方がいいのだろう

988 ：150：02/12/06 18:42

>>984
>それは置換検索の問題の解決にはならない。
> 「良い名前付け」が関数別にユニークな変数名を産む事を押さえることには
> 普通ならない。
そこまでの抑止力はないだろね。
折れの言ってることはせいぜい「マシな工夫」程度。
どうすれば100%良いかまでは、折れも追求しきれてない。

>言っていない。
>どこに常にエディタに頼れと書いてある？
そうだったか。すまん。
単に折れの言っている事では不十分だと言っているに過ぎないのだな？

>なのに「名前付けの工夫も有効」なんて言うのは、「置換検索の問題は
>変数名を変えて対処せよ」と言ったのと同然ではないか？
折れは「置換検索の問題は変数名を変えて対処せよ」と既成のものまで
言及する気はないよ。
過去の産物に手を入れるには色々な問題があるだろうし、折れがそこまで
立ち入って意見出来る立場では無い。

>ii じゃなくても、もっと長い名前でもそうとは気付かない。
>試してみればいい。
経験上、これまで折れ自身は困ったこと無いし、困らせたことは無い。
気付くか気付かないかは、たしかに名前付けだけに依存しないな。
スキルの問題もある。
とにかく折れとしては、100%の成果が出なくても多少効果があるのなら実践する。

989 ：150：02/12/06 18:43

ま、折れだって今後どう進化するか分からんもんな。
己の信じる道があるならそれで良し。
他人の考えでも筋が通ってれば否定する気は無い。
自分の考えに筋が通ってると確信している間は、筋を曲げる着は無い。
筋に対する賛否議論は歓迎だが、ハナから結論をもって括られるのは反対。

990 ：150：02/12/06 18:52

>>987
ちとvimを使ってみたが、987が言うような点についてはまだよく分からん。
でも、検索の問題とは別なんじゃないの？
名前付けで工夫するより、エディタの機能を活用すべし、貧弱なエディタ
を使ってるヤツが悪い論調が漂ってたから、常識的にxxxを使ってないと
おかしいのかと思った。

991 ：仕様書無しさん：02/12/06 19:18

>>990
> 検索の問題とは別なんじゃないの？
例えばvimでは検索すると>>974のサクラエディタのように
検索にヒットした部分を色分けしてくれる。
また、置換の場合>>972のようにMIFESよりも楽に置換できる

> 名前付けで工夫するより、エディタの機能を活用すべし、貧弱なエディタ
> を使ってるヤツが悪い論調が漂ってたから、常識的にxxxを使ってないと
> おかしいのかと思った。
その通り、言語に応じてエディタを使い分けられるようになれば最高だろう。
現時点で俺は自分のよく使うプログラム言語と相性が良く、自分の使う環境で
使えて、自分に一番慣れて、使いやすいエディタは「現時点では」vi

君のよく使うプログラム言語と相性が良く、君の使う環境で使えて、
君に一番慣れて、使いやすいエディタは何だい？
別に俺と答えが違っていても構わないが、上記の問いを一度も考えず、
惰性で使い慣れたエディタを使う奴はプロの態度ではないと言いたい。

992 ：仕様書無しさん：02/12/06 19:35

> 識的にxxxを使ってないと

エディタ固定になるのはよくない。
やりたい事によってエディタを使い分けるべし。
欲しい機能が全部揃ってるエディタがあるなら別だが。

993 ：仕様書無しさん：02/12/06 19:36

1000取り合戦・・・どころじゃなさそうだな。

994 ：仕様書無しさん：02/12/06 19:40

>>1はPart2の準備をするように。

995 ：995：02/12/06 19:51

995

996 ：仕様書無しさん：02/12/06 19:52

まもなくここは　乂1000取り合戦場乂　となります。

　　　＼∧＿ﾍ　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣
　,,､,､,,,　/ ＼〇ノゝ∩ ＜　1000取り合戦、いくぞｺﾞﾙｧ！！　　　　　　　,,､,､,,,
　　　　/三√ ﾟДﾟ)　/　　＼＿＿＿＿＿＿＿＿＿＿＿＿　　,,､,､,,,
　　　　/三/| ﾟＵﾟ|＼　　　　　　,,､,､,,,　　　　　　　　　　　　　　　　　　　　　　　,,､,､,,,
　,,､,､,,,　Ｕ（:::::::::::）　　,,､,､,,,　　　　　　　　　＼オーーーーーーーッ！！／
　　　　//三/|三|＼　　　　　∧＿∧∧＿∧ ∧＿∧∧＿∧∧＿∧∧＿∧
　　　　　　∪　 ∪　　　　　　（　　　　）　　　（　　　　）　　　（　　　　）　　　）
　,,､,､,,,　　　　　　　,,､,､,,,　　∧＿∧∧＿∧∧＿∧ ∧＿∧∧＿∧∧＿∧∧＿∧
　　　　　　,,､,､,,,　　　　　　（　　　　）　　　（　　　　）　　　（　　　　）　　　（　　　　）

997 ：仕様書無しさん：02/12/06 19:53

９９７！！！！！

998 ：仕様書無しさん：02/12/06 19:54

九百九拾八ですが、何か？

999 ：仕様書無しさん：02/12/06 19:57

最後は譲ってやるよ

1000 ：AAAA ◆uILP78dVVc ：02/12/06 19:57

　　　＼∧＿ﾍ　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣
　,,､,､,,,　/ ＼〇ノゝ∩ ＜　1000取ったぞｺﾞﾙｧ！！　　　　　　　,,､,､,,,
　　　　/三√ ﾟДﾟ)　/　　＼＿＿＿＿＿＿＿＿＿＿＿＿　　,,､,､,,,
　　　　/三/| ﾟＵﾟ|＼　　　　　　,,､,､,,,　　　　　　　　　　　　　　　　　　　　　　　,,､,､,,,
　,,､,､,,,　Ｕ（:::::::::::）　　,,､,､,,,　　　　　　　　　＼ワーーーーーーーイ！！／
　　　　//三/|三|＼　　　　　∧＿∧∧＿∧ ∧＿∧∧＿∧∧＿∧∧＿∧
　　　　　　∪　 ∪　　　　　　（　　　　）　　　（　　　　）　　　（　　　　）　　　）
　,,､,､,,,　　　　　　　,,､,､,,,　　∧＿∧∧＿∧∧＿∧ ∧＿∧∧＿∧∧＿∧∧＿∧
　　　　　　,,､,､,,,　　　　　　（　　　　）　　　（　　　　）　　　（　　　　）　　　（　　　　）

1001 ：１００１：Over 1000 Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。