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

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

ソースの見た目効率を語るスレ

1 :5年生:01/10/05 12:36
プログラム作成作業中、割と時間を食っているのが
「ソースを眺める時間」

この変数がどーつかおうかとか
つかわれてるかとか
ここのメソッドヘ渡す値は実値かアドレスかとか
このメソッドが受け取っているのはポインタだが中身さわって無いけど
ココで使われてるメソッドはどこのクラスのやつやねんとか
この計算式はどの仕様がもとになってんねんとかなどなど。

実際の作業中ちまちまと手が止まることはしばしばあると思われる。

ソースを打ちこんでる時間よりもひょとしたらナガーイかもしれない
こんな目に見えない作業時間を削るにはどうすればっ!?
を模索するスレ。

2 :1:01/10/05 12:42
一応おいらは業務アプリ作成が主な生業。

ゆえに、「実行速度至上主義っ!」ってのとは異なる。
どっちかっちゅうと「資源浪費万歳」なので、あしからず。

まぁ、実行速度云々だからってぇのは考慮はするが、
見易さが損なわれるならほっとく(こともある)っちゅう方針でんな。

3 :1:01/10/05 13:02
<言語>:問わず
<分野>:変数宣言のこと

<内容>
接頭詞と変数名の間に「_」(半角のアンダーバー)をつける

<理由>
接頭詞と変数名の区別がとってもつきやすい。

<たわごと>
接頭詞が3文字以内とかそんな規約があったとする。
その範囲におさまりゃいいのだ。問題無い。
けど世の中そんなことばかりじゃない。
3文字に略した瞬間かぶるやつらがでてくる。
それを回避すりゃ「おめそりゃどーやったらそーなんだ?」ってな
接頭詞もでてくる。
そんな時「くっついてたら判別できねーべや?」って思ったのが発端。

人間、区切りは目にとまる
 ↓
前半=接頭詞、後半=変数名と明確
 ↓
あとは「この接頭詞はなんやっけな?」っと、
「この変数名はなんぞいな」くらいの悩みが残るのみ
 ↓
微妙に(゚д゚)ラクー

4 :デフォルトの名無しさん:01/10/05 13:02
ソースを見ずに仕様書を見る。終わり。

5 :デフォルトの名無しさん:01/10/05 13:10
接頭辞: is_, get_, set_以上

6 :デフォルトの名無しさん:01/10/05 13:12
ながめている時間だって仕事のうち。
1はプロとしての自覚があるのか?
(趣味プログラマだったらゴメンよー)

7 :デフォルトの名無しさん:01/10/05 13:15
とりあえずハンガリアン記法は逝ってよしってことで。
個人的にはグローバルはg_、メンバ変数はm_みたいに
スコープを名前につけるのが好きだな。

8 :1:01/10/05 13:32
>>6
繰り返し見てるとき、「前も同じ事考えたな」とか感じたこと無い?
1週間に1回や2回ならともかく、3回も4回も5回もそこで詰まったら
鬱になるころあれへん?
自分の作るもんではそんなことならないようにややこいの作らないのも心がけだが。

9 :1:01/10/05 14:41
>>7
Cな言語で良く見かけますねぇ。おいらもマンセーざんす。
ところで。
話を発展させて、たとえば関数名にそれを適用したりします?

<言語>:C++
<分野>:クラスのメソッドのこと

<内容>:
private と protected と public に virtual まで区分けたりするか?

<おいらの場合>
private  : なんもつけない
protected : 「m_」 を頭に付加
public   : 「p_」 を頭に付加
virtual  : 今のところ無視する方向で
       (自分で1から作るプロジェクトにゃ入ったことないゆえに)

これしとくと、効果範囲がわかりよくなるんだけど、
関数名と、変数名の判別がわかりにくくなるっちゅうことも少々おきる。
なんぞ「これぞ折れ流!」っとか目の覚めるような解決方法はありませんかのぉ。

10 :デフォルトの名無しさん:01/10/05 15:24
関数名の規則ってあんまり考えずに書くこと多いけど、
余所から参照されないとこは小文字で始めて
public な関数は大文字で始めたりするなあ。
でも、あんま意味は無いと思われる。

関数名に m_ g_ 付けるとコード読みにくくなると思うんだけど…

11 :デフォルトの名無しさん:01/10/05 17:14
Borlanderなので、
・基本的に変数の区切りにアンダーバーを使わず、単語の先頭を大文字、後は小文字で記述
・型はTを頭に付加
・クラスのメンバはFを頭に付加
 ただし、公開用のものにはつけない。
・ポインタはpを頭に付加

12 :デフォルトの名無しさん:01/10/05 17:40
C++で・・

単語区切りは大文字で表現>LineGraphic
基本的に省略はしない>高解像度推奨
(ただし理由付きで例外は認める)

クラス名:大文字から始まる
その他:小文字から始まる

クラス名:名詞
変数名:名詞
関数名:動詞+名詞(引数があれば)

あとは常にわかりやすく的確な名前をつけることと
公開メンバ関数は宣言の最初にもってくること。
ある程度以上、規模が大きくなってきたら
クラスを細かく分割すること
あるいは実装とインターフェースを分離すること(ブリッジ)
クラス図を資料として残す事

こんなところですな。

13 :デフォルトの名無しさん:01/10/05 18:50
熱烈ハンガリアン信者でしたが(MSサンプルコードから入ったので)
誰も賛同してくれないので止め。
でも今でも文字列の頭にはsz、数値の頭にはnをつけることは多い。
変数名を考えるのは面倒で時間を食うから、なるべく少ない変数名
バリエーションを同時に使いまわすにはハンガリアンが都合がいい
ので。szlineとnlineのように。ハンガリアンって効率的〜(煽

メンバ変数は「最後に_」派に転向。

14 :デフォルトの名無しさん:01/10/05 19:10
VisualC++使いとJava使いの毎度おなじみ「m_」論争
オレにはm_を付けることにメリットはあってもデメリットはないと思うが・・・
Java使いはSun教祖の戯言を全て真理と崇めるただの盲目的信者ですな
m_などの接頭語をつけないのは、マイクロソフトの真似をしないこと以外には
理由はないだろ!

15 :ROMを決め込んでました:01/10/05 19:42
>>14
ちょっと前にjavaスレで、「これはソフトウェア工学にかなったプロの現場の方法なんだ。
おまえらホビープログラマやアンチMSにはわからないだろうが」とかのたまわる
井の中の蛙丸出しの人がいらっしゃいました。

…煽りじゃないっす。思い出したらつい懐かしくなったんで、sage

16 :14:01/10/05 19:48
>15
多分、それをオレも読んだと思うが、
双方の主張を聞いても、どう考えてもm_を付ける方がいいとしか
思えなかったが。
「見た目が汚い」とかそんなアホな意見ばかりだからな

17 :デフォルトの名無しさん:01/10/05 19:52
>>16
「見た目が汚いは」ちゃんとした意見だと思うが・・・
おれの場合、書くよりも見るほうが疲れる・・・


あ、おれは"m_" "g_"派です
sage

18 :デフォルトの名無しさん:01/10/05 19:53
スコープにプレフィックスつけるのは賢いやり方

19 :デフォルトの名無しさん:01/10/05 19:55
ほらやっぱり、Rubyは最高じゃん。おまえら(荒らし厨房君のことだよ)
何考えてんの?

20 :デフォルトの名無しさん:01/10/05 20:11
なんでRubyなんだよ。おりゃDelとC++だ。アフォな条件反射レスしてないで、
ちっとはそのメリットを考察しろ。

21 :デフォルトの名無しさん:01/10/05 20:12
>>20
誤爆と思われ・・・

22 :デフォルトの名無しさん:01/10/05 20:29
>>21
つ〜か、狙った誤爆だがな

23 :21:01/10/05 20:32
>>22
そうだったか・・・
逝ってきます・・・

24 :デフォルトの名無しさん:01/10/06 01:23
やっぱりソースを見て機能が把握しやすいと言ったら、
オブジェクト指向が有効なのでは?

25 :デフォルトの名無しさん:01/10/06 01:44
スコープが広いと定義位置が見つけ辛いっつーことで、
グローバルなオブジェクトにはプリフィクス付けて、
ローカルなオブジェクトには付けないというのはどうよ。
スコープ+型情報が一度に表現できるし、
iなどのカウンタ変数は普通修飾しないという慣習にも合う。

あとm_なんだが、意味無いと思われ。
外で使う場合はクラス名等で修飾するしのだし、内で使う場合はメンバ以外を
きちんと修飾してやれば良い。

26 :1:01/10/06 01:51
>>10
 >関数名に m_ g_ 付けるとコード読みにくくなると思うんだけど…
やはりか。
変数のスコープがあるのに関数のそれがないのはどぅよ?
っと思っていたのだが、そのまま適用したら見にくくなった経験があります(>9にて)
小文字と大文字で分ける方法は、なんとなーく見た時考えてしまうのね。
これは小文字だから…云々ってなかんじで。

>>11
おお。おいらが考えてみるきっかけになったともいえる
教科書にでてたよな命名だ。
おいらもそれに似たよな規約があったときに染まってたました。
しかーし!
変数と既存の関数と自作構造体とかイパーイあると頭混雑してましてん。
ぱっと見で判別しにくいって言う点で。
慣れたときには気にもならないもんですが、他の文化に触れたときに
気になりました。

>>12
作り手の気安さを踏まえてあるいいルールと感じます。
やっぱりここでもみえかくれするのが
大文字小文字で区分けしてまえってな感じな箇所。
う〜ん悩ましい。

27 :1:01/10/06 01:59
>>13
なにも規約なし<<<<<<<<<<<<<<<ハンガリアン
です。ただいまとなってはハンガリアンも微妙にみにくい記述法ですが。

>>14
マイクロソフトはひとつ踏絵ですかのぉ(主旨ズレ

>>15
やはりプログラマたるもの工学無視しても効率的な方法を見出さないと(主旨ズレ2

>>16-18
とりあえずスコープは「わかったほうがよい」ってのは共通意識ってことで。φ(..)

>>19-23
sage

28 :1:01/10/06 02:12
>>24
関係ないとおいらは思う。
クラス名もメソッドも変数も意味を持たせた文字列で定義しないことには
なんのこっちゃサパーリなソースがそりゃもぅ見事に出来上がるはず。
スパゲティもビクーリってな感じで。
この辺でソースは作り手によって「眺める時間が違ってくる」現実が
見え隠れしてると思う(強引に話を捻じ曲げ)

>>25
具体例あると助かり。
見易さと判断のし易さを万人向けに実現できれば
今より「生産性」は確実にあがると思うし、
ソース解析作業も多少であっても楽になるはずだから。

ちなみに今回のことを考えてからカウンタの「i」もどうかと思うように
なってきた。
書きやすいけど、「j」「k」を招く要因となり、
それらが絡み合うと目も当てられないループが出来上がったりすることが
しばしばあった。主に新入り技術者卵どもの作成物であったけど。
それにカウンタを検索つかって追えないし。
「i」なんざそこたら中で該当するし。
「(i)」とかの「i」だけ引っ掛けようと思ったら前後に空白とか指定して
絞ることがでけへんし。
これもソースと向かい合う時間の増大の要因だと思ったりする訳です。

29 :デフォルトの名無しさん:01/10/06 02:36
ソースを書いた奴が一生メンテする。

30 :デフォルトの名無しさん:01/10/06 02:41
>>29
やつも草葉の陰でそうしたかったと思っていることだろうよ。

31 :デフォルトの名無しさん:01/10/06 02:45
i は iterator の i
これ定説です

32 :デフォルトの名無しさん:01/10/06 02:54
スレの話題とずれてるけど、global知ってる?
http://wafu.netgate.net/tama/unix/
いまはサイトがおちてるみたい。

33 :デフォルトの名無しさん:01/10/06 02:55
なんかあったら責任取るちゅーことでソースに住所氏名メアドその他を書いておく。
ソースはそのまま成果物と一緒に納品。
質のいいコードが書けそうだ(w

34 :デフォルトの名無しさん:01/10/06 03:46
>>25
グローバル/ローカルだけでなく
パブリック/プライベートの軸で分けて欲しい。
パブリックな物程色々な人が使うので規約を統一するのは難しい
(その規約がどんなに良くても)

Cでstaticなグローバル変数とかにはプレフィックスあってもいいけど、
公開用のヘッダファイルに載せるようなものにはプレフィックスなしがいい。

その意味で>>9には反対なんだけど。

C++でよさげなクラスライブラリ見つけても、
APIに妙なプレフィックスついてると一気に使う気が萎える

35 :デフォルトの名無しさん:01/10/06 07:55
>31
for ループのカウンタに i,j とつける慣習は
Fortran の整数型変数 I,J からきています。

i が iterator と言い出したのは岩谷ドキュです。

36 :デフォルトの名無しさん:01/10/06 13:02
>C++でよさげなクラスライブラリ見つけても、
>APIに妙なプレフィックスついてると一気に使う気が萎える
OpenGL系のライブラリとかみるとうんざりして使う気萎える?

37 :sage:01/10/06 15:06
コード補完を多用しまくってメンバ変数へのアクセス
がすべてthis->〜となってるドキュがいる。(vc++の話ね。)

38 :  :01/10/06 15:13
>>37
それはOK

39 :デフォルトの名無しさん:01/10/06 15:27
>>38
ヨミニクイYO!

40 :デフォルトの名無しさん:01/10/06 15:30
縦に揃える。
 a1 =  b
 a2 =  b*2+c
 a3 =     c


       b= a+2
     c= b*3+2
   d= c+4
 e= d +5

みたいな感じ

41 :デフォルトの名無しさん:01/10/06 15:33
>>37
ヘタレだな。覚えられないような長い名前、多すぎるメンバ作る奴逝ってよし。

42 :デフォルトの名無しさん:01/10/06 15:51
>>36
萎える。OpenGL使ってないけど。
Cのツールキットはプレフィックスつけるのは仕方ないと思う。
けどC++のクラスライブラリならnamespace使って欲しい。

W3CのDOM APIとか最悪。
IXMLDOMElementとかVBとおんなじ。Perlの方がまし。

43 :デフォルトの名無しさん:01/10/06 15:58
>>42
>けどC++のクラスライブラリならnamespace使って欲しい。

現状開発環境がろくにnamespaceに対応してないのが問題だ
ね。vc++なんかグローバルな関数をnamespaceに入れるとク
ラスビューから消えるし。

ただ、VS.NETじゃきちんとネームスペース毎に分けて表示し
てくれるしWin環境なら使うものも増えてくだろう。
つーわけで、VS.NETマンセー。

44 :>42:01/10/06 15:59
俺はnamespace+prefixでも気にならないけどな。
それにprefixあるとコード補完の絞込みがやりやすくなるのが良いね。

45 :名無しさん@Emacs:01/10/06 18:50
>>18-19
微妙にあってる。

Ruby では変数の名前の最初の一文字が、変数の種類を表します。
* 小文字ではじまるものはローカル変数
* $ ではじまるものはグローバル変数
* @ ではじまるものはインスタンス変数
* 大文字ではじまるものは定数
ってな感じで。

46 :デフォルトの名無しさん:01/10/08 15:29
>>37
C++厨房なんですが、
メンバ変数と引数の名称をとちって被っちゃうと大変なので
this付けまくってます僕。どこか間違ってますかやはり?

47 :デフォルトの名無しさん:01/10/08 15:30
>メンバ変数と引数の名称をとちって被っちゃうと大変なので
このあたりが間違ってます。

48 :デフォルトの名無しさん:01/10/08 15:30
間違ってません。

49 :デフォルトの名無しさん:01/10/08 18:30
間違ってます。
prefixを使えばこの問題は関係できます。

50 :デフォルトの名無しさん:01/10/08 19:10
>>46
this->hogeよりもm_hogeかhoge_の方が短いし読みやすいし入力も速いだろ。
メジャーなエディタが大体コード補完備えたらそうでもないかもしれんがな。

51 :デフォルトの名無しさん:01/10/08 19:12
m_なんかより
getHoge
の方が何倍も気持ち悪い書き方だ..

52 :デフォルトの名無しさん:01/10/08 19:52
>>49-51
prefixで回避できるとして、m_hogeを好まない方々は
どう回避なさっているのでしょう?
このスレで言えば>>34さんとか。(指名しちゃってゴメンナサイ!)

被るような名前付けるなって言われればその通りなんですケド。

53 :デフォルトの名無しさん:01/10/08 19:56
thisメンバを優先的に表示するように
IDEのコード補完を修正。

54 :デフォルトの名無しさん:01/10/08 20:03
真面目にコードを書いてるときは補完を全く使ってないので
sage

そもそも、コードの可読性とIDEの補完は関係ないぞ

55 :51:01/10/08 20:05
俺は classのメンバ m_*
恥ずかしいけどファイルスコープ g_*

56 :1:01/10/10 00:42
例えばint型の宣言、しかもカウンタ用の変数宣言で
こんなんを想定して。
(1)「int  int_Cnt ;」
(2)「int  intCnt ;」
(3)「int  n_Cnt ;」
(4)「int  nCnt ;」
(5)「int  cnt ;」

見た目わかりよさランキングをつけるとこんな感じ。
(1)>(3)>>>(2)>>(4)>>>>(5)

まず変数のかる〜いネタふりから。
皆はどぅよ?

57 :(・∀・)イイ!!:01/10/10 01:06
intで足りなくなってlongとかになおしたらもちろん変数名はlong_Cntだね!

58 :デフォルトの名無しさん:01/10/10 01:11
>>56
int count;でいいじゃん。カウンタごときに型なんぞ付けんぞ。
勿論、ハンガリアンは嫌い。:-p

59 :デフォルトの名無しさん:01/10/10 01:16
(1)はデバッグ中にボケていると、intが重複してるように見えて
どっちかを消してドツボにはまる可能性アリ。
それに型情報を含めると、型の変更に余計な手間がかかる。
一括変換を使えば良いと思うかもしれないが、同一ファイル内に存在する
複数の関数が、同じ名前のローカル変数を持ってる場合などには使えない。

少なくともローカル変数は、型情報など少し上に移動すれば簡単に
調べられるのだから、含めない方が良いと思われ。
付けないと混乱するのなら止めないが。(pとか)

60 :デフォルトの名無しさん:01/10/10 01:23
スコープ指定は _でつなぐ。
他は版狩りアンでよし。

61 :デフォルトの名無しさん:01/10/10 02:09
コンテナみたく、後から型を変更する可能性があるオブジェクトの名前はハンガリアンで付けたくない。
でも、コード補完機能のおかげで普段はハンガリアンの方が便利。
混在させる? それは最悪。

ちょっとジレンマ。

62 :デフォルトの名無しさん:01/10/10 10:40
スコープと型のドッチを重視するかになっちゃう様な…

結局、型なんて宣言したら後は気にしない(普通、最大・最小値なんか気にしないでしょ?)から、
ドコで宣言されてるかを推測しやすいスコープに比重おいてる。

いやね、うちの会社のVB厨のソースを今保守してるから、その辺実感してるのよ(涙
何にもついてないからローカルかと思ったら、標準モジュールでパブリック宣言されてたり…

他人のソースをいじらなくてはならない場合の守ってて欲しい規則は、
スコープ問題:オレは g_、m_ つける派。宣言の場所さえ分かればどうにかなる。
型問題:少なくとも文字列や数値混在してるとこに、a とか b とかいう変数つけんな!
定数関係:enum 宣言までは強要しないから、せめて Public Const 宣言してる変数ぐらい全部大文字にしてくれ!

現場からは…この位にしときます。

63 :1:01/10/10 10:53
>>57
接頭詞は3文字くらいがええかんじ〜っと思うおいらは
intはそのままでしゃーないっと思い、
longは「lng」で
stringは「str」がいいな〜っと思うのであり。

>>58
「count」だとホンマにカウンタの型がわかれへん。
カウンタも複数になったときに「count2」とかが増えてくことが目に見えるよう。
んでなぜか「int count」「long count2」とか妙なことが見えないまま進行する
恐れもありと想定され。
自分がやらなくともソースを触るほかのだれかがやるかもしれない。
っちゅうかそんなソースをメンテした日にゃその日1日鬱になる。Σ(゚д゚lll)ガーン

上記の流れを組んで。もし、「int lng_Cnt」と命名するやつがいたら。
問答無用で頃そう。わしゃそう思う。
「long int_Cnt」ならナンボかましなので半頃しですます。

>>59
のはなしはドツボケースも深みにはまるからあかんと
いっているように聞こえるが、
「日頃のほほん作業が行えるならドツボにゃそうそうはまらんでぇ〜」
ってのが想定外と思われ。

他の誰かのソースのローカル変数を追う時に「この名前はなんやねん?」
ってのを追うのがうっとーしくてしかたがないの。
1画面で納まってないのが多いし(;д;)

>>60
半分銅胃

>>61
オブジェクトと自作クラスだのライブラリだのの接頭詞が悩みどころ。
「わかりにくいぞ(゚Д゚)ゴルァ!!」か、
「なげぇぞ(゚Д゚)ゴルァ!!」のどっちかに転ぶ。

おいらも(゚д゚)ジレンマー

64 :デフォルトの名無しさん:01/10/10 14:42
>>56
int linecnt; とか。

65 :デフォルトの名無しさん:01/10/10 15:59
カウンタ用なら1関数内だし、iでなんでだめなん?
ひとつの関数が大きくて追っかけづらいなら、それを小さくするように努力させるほうが効果的じゃ?

# Fortran の整数型変数 I,J の少なくともIはiterator から来てるような話があったような。

66 :デフォルトの名無しさん:01/10/10 17:13
変数だけ見てわかりやすくても意味がない。
プレフィックスのおかげでコードの量は増えてしまうわけで、
その分読みにくくなるともいえる。
型がわからなくてもある程度まではコードを理解することができる。
正確な型を知りたくなった時に定義を調べればよく、
それは大した手間ではない。

67 :デフォルトの名無しさん:01/10/10 17:58
> プレフィックスのおかげでコードの量は増えてしまうわけで、
> その分読みにくくなるともいえる。

TABやスペースのおかげでコードの量は増えてしまうわけで、
その分読みにくくなるともいえる?

> 正確な型を知りたくなった時に定義を調べればよく、
> それは大した手間ではない。

ソースが1個2個ならね。

68 :デフォルトの名無しさん:01/10/10 18:09
ObjectPascal以外の言語はどれもソースの見た目が汚いよ

69 :デフォルトの名無しさん:01/10/10 18:15
変数の型は名前にエンコードしてまで
あちこち持ち回るようなもんではない
と私は思う。

>>65
INteger だけに [I-N] で始まる名前がデフォルトで整数なんじゃないっけ?

70 :デフォルトの名無しさん:01/10/10 18:15
>>68はDel厨(C勉強中)なので無視しましょう

71 :デフォルトの名無しさん:01/10/10 18:34
違います802は今まで各スレをRuby厨という名前で荒らしてきましたが
今度はDel厨として荒らし行為を行っているだけです。

荒れるから何もいえなくなっているDelphiユーザーがこんな荒らしを
今行えるわけありません。

72 :デフォルトの名無しさん:01/10/10 18:43
>>67
> TABやスペースのおかげでコードの量は増えてしまうわけで、
> その分読みにくくなるともいえる?

TABや空白は「読まない」から読みにくいも何もない。

> ソースが1個2個ならね。

プリフィックスで表せる型なんてたかが知れてるからどのみち
定義を調べる必要はあるだろう。
int や char * などに限ればプリフィックスなしでもほとんどの場合
定義を見る必要がないからやっぱりプリフィックスは無駄。

73 :デフォルトの名無しさん:01/10/10 18:47
プリフィックス使う奴に限って変数名が長くてウンザリ

74 :デフォルトの名無しさん:01/10/10 18:49
正直、ハンガリアンはあふぉ。

75 :デフォルトの名無しさん:01/10/10 19:32
正直、強硬なアンチハンガリアンにはうんざり。

76 :sage:01/10/10 20:52
>>67
たとえが悪いが、
一関数が10〜20行程度に収まるコードだと
ローカル変数の型なんか一目瞭然。

そういうわけで、構造体やクラスのメンバみたいな、
宣言が別の場所にあるものにだけ
型情報とスコープを明確にするスタイルもある。

77 :デフォルトの名無しさん:01/10/10 20:59
sage=802だったよなあ。確か…

78 :デフォルトの名無しさん:01/10/10 21:03
Delギコスレがagaってきたのも、たった今だったね...
また来たのではない?

79 :sage:01/10/10 21:05
Σ(゜д゜lll)ガーン
いつからおれ802になったんだ

80 :デフォルトの名無しさん:01/10/10 21:18
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1001039863&st=071&to=081&nofirst=true
このあたりから。

81 :sage:01/10/10 21:27
Σ(゜д゜lll)ガーン ホントダ

C系以外で名前の付け方を決めてる人はいる?

82 :60:01/10/11 00:17
>>63
>「count」だとホンマにカウンタの型がわかれへん。
>カウンタも複数になったときに「count2」とかが増えてくことが目に見えるよう。

[count2]なんてアフォな名前は使ったことないな。付けるんなら[xxx_count]だろ。
目に見えるのはあんたが普段そんなコード書いてるからだろ。[flag]とかグレープ
したらずらっと出たりせんだろね?

83 :デフォルトの名無しさん:01/10/11 00:40
ぐれっぷて読むだろ。grepは。

84 :デフォルトの名無しさん:01/10/11 00:44
じーれっぷ
いいじーれっぷ

85 :hoge:01/10/11 10:15
ぐれっぷもグレープも間違い。
正しくはグレプー。

86 :1:01/10/11 14:35

>>62
悩ましぃソースと戦っておられますのね。
作成者見つけれたら「(゚Д゚)ゴルァ!!」っと一言いってあげてください。
内容はほとんど同意。

>>64
いやほら。

>>65
「i」については>>28 にて。
自作する時の心がけは大事です。<小さくする
しかし、追っかけるのがつらい状況というのはほぼ全て
「他人のソース」
であることなのです。
見やすいソースに出会ったことは数えるほどしかないよヽ(´ー`)ノ

>>66
1行目は同意。関数構成からクラス構成からインデントやらコメントやらその他イパーイ要素はあるよ。
だけど、それから下。
>それは大した手間ではない。
これをなくすにはどしたらええんかいのぉっちゅうのを今模索してるのですよ。

>>67
>ソースが1個2個ならね
烈しく同イ

>>69
1:型をもちまわらなかった時
2:型をもちまわった時
を比べて、
1でのデメリットには
「変数単体での役目のわかりにくさがある」ってのがある上に
 ・既存の関数名に紛れるとソースがややこしく見える
  → 関数に渡している変数の型の整合性をみる状況に遭遇した時
   「これはなぁに?」っと思うか
   「この型はあってるのぉ(まちごとる)」の判断がつくかの差に出る。
   ※そもそも型宣言がまちがってたら〜って言う反論はいりません。
    (>>63の中盤くらいで語ってます)
っていうのを重要視するのでおいらは2>1であるといいたい。

>>68 >>70-71
sage

87 :1:01/10/11 14:36
>>72
見易さ評価を100段階で表して、
プリフィックスなし:「5」(適当設定)
プリフィックスあり:「7」(これも適当設定)
として、
差分は2しかないから大して変わるもんじゃない!!
っと言いたそうだが、その2でも大事なのだ。
他の誰より引き継がれた人にとって。

そして得てしてプリフィックスのないソースを書いてるやつの書く
ソースはたいてい全体的に見難い、追いにくい、ばらしにくい
ってのを備えていると思うのだがどうだろう。


>>73
長くてもコピペで事足りるでしょ。

>>74-75
sage

>>76
それもまたアリかなとも思う。
統一された文化に即した形で書いてあり、それが他者にわかり良ければ
おいらはマンセーなので。

>>77-80
sage

>>81
わしゃVBもありますぞぃ。
っちゅても変数の方の命名形式は何も変わらず。

>>82
はなしを抽出されて煽られてそうなのでsage

>>83-85
sage

88 :1:01/10/11 14:40
/ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
| 行数圧縮しとるだけやないかゴルァ!!

   ̄ ̄ ̄|/ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
     ΛΛ   ||::::::::::|| アホカー
     (#゚Д゚)―||::::::::::||―――
     /   つ二二lニl       _______
   | ̄ ̄|__)―――ΛΛ―  /
   `ー┬‐''     (   ) <  先輩。同です折れ流美しソースの見た目は
     ┴      |  ヽ   \_______
             し___)〜   
           

  ∧ ∧  / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
  (,,・д・)< ッテユーノガ イチバン イヤ
 @uu)  \__________
   

89 :65:01/10/11 14:52
追っかけるのが辛い他人のソースが多いから自分のソースをきれいにしようという話だったのか。
# 追っかけるのが辛いソースを吐き出す他人に示せるようなガイドラインでも作ってるのかと思ってたよ

90 :デフォルトの名無しさん:01/10/11 15:56
型でプレフィックスを付けるのってMS文化圏の連中だけでしょ。

この板でも何度か同様の話題が挙がってるけど、
無邪気にハンガリアンを薦める人って、勉強不足な印象があるね。

91 :デフォルトの名無しさん:01/10/11 16:16
>>1
構造体とか、オブジェクトはどうするの?typedefは?

例えばCでは良くあるFILE *とかsize_tはどうするの?
FILE *FILE_in;  /* またはpFILE_inか? */
size_t size_t_filesize;
とかはいやだな。

92 :1:01/10/11 16:20
>>89
ガイドラインつくりたいと烈しく思うじょ。
さすれば新入り部下とかのソースもメンテナンスしようという気になるというもの。

>>90
で?

93 :64:01/10/11 16:29
>>86
> >>64
> いやほら。
まぁこんなのはどーでもいいんだが。

> >>69
> 1:型をもちまわらなかった時
> 2:型をもちまわった時
> を比べて、
> 1でのデメリットには
> 「変数単体での役目のわかりにくさがある」ってのがある上に
これには疑問がある。変数の役目を型で表すわけ? 役目を表すのは名前じゃな
いの? なら名前が適切なら型のプリフィクスはいらないと思うんだが。

94 :デフォルトの名無しさん:01/10/11 17:00
変数名に型情報をもたせて意味があるかどうか疑問。

person.name
person.age
↑たとえば、こんな変数名が使われても
「型名がわからない!読みにくいソースだ」とは思わない。
人の名前と年齢が入ってるって事がわかるから。


逆に、
person.str_name
person.int_age
なんて名前の付け方は冗長。
ソースの理解に役立たない。

95 :デフォルトの名無しさん:01/10/11 18:15
date.str_month
は役に立ちそうだ(09とか)
常に型が分かるような変数名をつけられるというなら、型情報付ける必要ないってのは同意。

96 :デフォルトの名無しさん:01/10/11 18:44
型がわかんなきゃ読めないつーのは、
単に名前の付け方が適切じゃないという話だと思う。

どう実装されるかじゃなくて、
どう使われるかを表す名前をつければおけー。

97 :デフォルトの名無しさん:01/10/11 19:45
>>95
それはdate.month.ToStringというメソッドにすべきかもね。

言語によるけど。

98 :デフォルトの名無しさん:01/10/11 20:43
常に名が体を表すような名前をつけられるとは思えないんだけど。俺がヘタレだから?

99 :デフォルトの名無しさん:01/10/11 21:12
普通、その場面で可能な限り高い抽象レベルで考えるべさ。
そしたら型が重要なんて場面は少ないと思う。
generic programming なんかだったら型はパラメータだぞ。

100 :デフォルトの名無しさん:01/10/11 21:20
>>98
名前から型を類推できることが重要なんじゃなくて、
抽象化して、型をなるべく意識しなくてもよいように
プログラミングすべし、ってコト。

101 :デフォルトの名無しさん:01/10/12 10:57
>>99
激しく同意だ。
名前が付けるのが難しいっていう意見は良く分かるよ。
俺も昔そうだった。
仕様の全体をあまり把握せずに局所的に組んで試行錯誤するような組み方だと
試験的なコードが多くなって適切な(無駄の無い)名前がでにくくなってしまう
それこそ組む前からテストパターンを上げられる(exprograming?)ぐらい
抽象レベルでの理解を重視すればそういう事態は避けられる。
あとは英語で名前付けるんなら英語のボキャないとつらいかな。
どっちにしてもスタイル変えるのは慣れるまで大変だけど
なれてしまえばなんでも無いよ。

102 :62:01/10/12 11:09
>>100
確かに自分で書くときにはそれを意識すべきだろうね。

でも他人がそれを「常に実行」してくれるとは限らない。
納期の迫った仕事で抽象化して〜云々ての、考える暇ナシってのも有りうる訳だし。
(まあ設計レベルでやっとけば良いんだろうが、納期1週間前で仕様変更なんてザラなんだよね(涙)
このスレは、>>92 で 1 の言ってるとおり、せめて型宣言のガイドラインを設定する事で、
新人でもできる範囲の「見た目効率」を考えてみようよ。(良いの出来たら流用させてもらいたいしー)

>>94 に関しては、構造体のメンバに m_ 付けるのは確かに気持ち悪いし、読みにくいと思う。
ただクラスのパブリックメンバにするんだったら、構造体から派生させたいトコだなあ。
オレの場合は、
typedef struct tagPerson {
  char cName[64];
  long lAge;
} person;
こんな宣言するかなあ…。こっからクラス派生させるのが多い。
ポインタなら pHoge、カウンタはどうせローカルだし i, j 使っちゃうね。
結構 VARIANT の宣言とか参考にしてるかも。

103 :101:01/10/12 12:33
手法の違いなのかも。
抽象的に考えるのはぶっちゃけ、
ボトムアップではなく、トップダウンでやろうって話なのよ。
そのほうが全体が見えて試行錯誤が少ない分効率的で、
変更に対して柔軟に対処できる可能性が高いから。
一見時間がかかりそうな気がするけど
トータルでは時間短縮を目的としてる。
手法の違いだから教育段階で刷り込んでおけばよいのだけれど・・

104 :デフォルトの名無しさん:01/10/12 12:41
>>102
>このスレは、>>92 で 1 の言ってるとおり、せめて型宣言のガイドラインを設定する事で、
>新人でもできる範囲の「見た目効率」を考えてみようよ。(良いの出来たら流用させてもらいたいしー)

でも、変数名に型情報を含めて意味があるかかなり疑問。
たとえば下手な新人が、
int cnt;
という変数を使っているとして、ドグマ主義的にコーディング規則を
適用して、
int int_cnt;
なんてしても、コードの可読性や保守性がマシになるとは、
とうてい思えない。

105 :デフォルトの名無しさん:01/10/12 13:25
>抽象的に考えるのはぶっちゃけ、

抽象的に考えないというのは、常にメモリとレジスタで
考えるってことけ?(藁

>ボトムアップではなく、トップダウンでやろうって話なのよ。

トップダウンかボトムアップかは関係ないと思う。

---
個人的には名前に型をエンコードするのはアフォだと思う。
自分で最初から書くコードではそんなことはしない。

とはいえ、他人の書いたコードに手をいれるときには、
自分のスタイルはあっさりと捨てて、まわりにあわせる。
元コードが大嫌いなハンガリアンなら
そのコードをさわるときには自分もハンガリアンになる。

106 :62:01/10/12 13:27
>>104
うん。オレも型は重視しないタイプなのよね。確かに、
> int int_cnt;
> なんてしても、コードの可読性や保守性がマシになるとは、とうてい思えない。
は納得できるし、無理に英語にして逆に分からなくなる事があるってのも見てきたし。
だから無理に規則として『変数にはスコープと型情報を含めろ!』って言うのは、
無理があるなあと思ってるの。(実際今の社内規約はそうなってる)
その代替案としてなんか良いのあったらいいなあ、というそういう虫のイイ話しをしてるのさ(笑

もちろん変数の名前付け規則にこだわっててもしょうがないし(やっぱ自分のスタイルが一番わかりやすいわけだし)
『可読性』って範囲でコメントの頻度や位置の話しになってもいいんでは。

…ただ最後に一個だけ言わせてくれ。
data って変数名だけはつけんじゃねぇ(笑

107 :デフォルトの名無しさん:01/10/12 13:40
>data って変数名だけはつけんじゃねぇ(笑

おれスコープ狭ければ data ってつけるよ。(笑
ある程度広かったり、意味がかち合うなら 〜data とかするけど。

108 :101:01/10/12 13:46
あら?もしかして俺痛い?
あんまり丁寧に話し(考えて)無いから
アフォなこと言ってるかも。
抽象的に考える・考えない
っていう括りで二元化できるとは思ってないよ。
ただ、プロジェクトの複雑度を内包できうるレベルでの抽象度は
必要だと思ってるし、それは設計だけでなくコードにも反映されるべきだと思う。

ボトムアップ、トップダウンは適切な言葉じゃなかった。
ごり押し、コーディング重視(初心者にやらせると悲惨、達人にやらせると無敵)
慎重に、設計重視(やや初期投資がいるが以降は安定した生産性)
と言い換えよう。

109 :101:01/10/12 13:58
俺なりの結論としては
洗練された設計さえあれば
あまり大袈裟な規約をつけなくとも
シンプルで分かりやすいコードになる確立が高い。
逆に、矛盾した設計ではどんなコードを書こうと分かり難い。

で、既に有るコードに関しては
自分で書き換え>テストができないならそのソースのスタイルに従うしかない。

110 :デフォルトの名無しさん:01/10/12 14:01
そういえば、昔SP-5030(BASIC)で書いてた頃は、
変数って2文字までしか認識してくれなかったんだよね。
英小文字もなかったから、変数名がA〜ZZ、A0〜Z9に限定されてたんだ。
それで消防の頃、ベーマガのリスト入力してデバッグ(打ち間違い探し)してたんだから、
こんなの贅沢な悩みかもしれないねえ…

111 :1:01/10/12 14:27
ちょこっと思った今の流れとは違うこと。

  物事を否定することは簡単だ
  「イヤ」というか「そんなんワカラン」というだけですむ。
 
  「今できてないことをどないしたらできるかな〜」
  を模索しようとしているところへ、
  「今も昔もできてないし、やったことないからワカラン」
  っなこと言われつづけても話の発展にはナーンモつながらナーイ。
 
    ̄ ̄|/ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
 ∧∧
 ( ゚Д゚)
 | っ日~~   イマノホウホウニ コシツシタケリャ
 と_)_)     シガミツイテナサイ
  ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ 

112 :1:01/10/12 14:28
>>91
おいらの場合だけど、
【 構造体 】
typedef struct tbl_****_t
{
  int   int_Start ;  /* コメント   */
  int   int_End  ;  /* コメント   */
  char  chr_Flg  ;  /* コメント   */
} TBL_**** ;
([****]は時々でかわると思っておくれぃ)
(構造体の中身はあくまで事例であって毎回こうではないことをあえて記述しとく)

構造体を「テーブル」って呼んでた文化の中で育ったのでこう↑。
接頭詞で宣言が「tbl_〜_t」(どっちかだけでもええけど)
再定義の時のが「TBL_〜」 (実際に使うのがどっちか悩むやつはいまい)

size_tは〜その性質からソース上はint型なりlong型なりで扱わない?
業務アプリでそんな型宣言してるやつぁいめぇと思うがどぅですよ?

んでFILEの扱いはもともと「fp_」でいいやと思っているのだけど、
最近の仕事であえて「Fp_Log」とかにしてみた。
ファイルポインタのポインタとか使うときに見やすかった
「Fpp_Hogehoge」ってな形。
「fpp_hogehoge」よりも区別つけやすいとオモタ。

113 :1:01/10/12 14:29
>>93
なんでもかんでもつけりゃええってんでなくて、
つけないほうがええこともあることは存じております。
たとえば>>94の例。
少なければ無い方が見やすい。ソース書くときにもいえること。
>>76での方法もその方向かも〜っとも思えたり。
がしかし。
普遍的に無い方が見やすいか?って疑問が湧きあがったときに、
あるほうがちまちましたところでの予防策になっているのよ。
気づかないかもしれないけれど。
無くていいところなど作ってる本人の作業中以外にはない。
っと言いきってもいいと思うほど無いと思うぞ。

>>94
その場合はね〜で同意。
もし「まったく無くても全然問題ない!!」と言いたいなら
>>95のパターンを題材に開発者としての立場で理路整然と述べてくれ。
たぶん「その場合はね〜」に行き着くこととは思われるが。

>>95
上記でいろいろつかわしていただきましたm(_ _)m

114 :1:01/10/12 14:30
>>96
それを考え方も感性も違う他人様と同期取るのが
どれほど大変か〜を思えば・・・・・・・

>>97
ワケワカラン

>>98
名は体をあらわす名前はえてして長くなりがち。
これはこれでまたイヤンという人達がでてくるのです(悩
ちなみにおいらもチャレンジしたことはあれども、
完全に名が体をあらわさなくても、型情報くっつけて、
なんとなく名が体をあらわしているよなのに逃げました。

>>99-101
SEの設計場面のようなお話ですな。
プログラムで実現するなら全部オブジェクトとかいうことで
実現はできますが。
ちまちましたところでの自分の作業効率とプログラムの実行時の
効率などを考慮すると、「型」に限定させることで効率重視する場面は
多々あると思われます。
接頭詞だけのお話なら納得もしますが、実作業場面を想定したときに
どうしても元の木阿弥のようなことに転びそうなのでsage。
っと言いたいところですが、

全体を把握してから組むってのと、
型をなるべく意識させないように組むっていう利点はマンセーにござる。

115 :1:01/10/12 14:31
>>102
うぅ、ありがとう
んで1点話に混ざる。
「m_」のお話で、大文字小文字の混在は使い分けをきっちりやれば
結構可能性がみえそう〜っとおもうおいらは
「m_」は「M」一文字を頭につけるんでええんちゃうかなっと思い。
先の例なら
person.Mstr_Name
person.int_Age
ってなかんじで。(一部自分色追加)

>>103
φ(..)

>>104
例えば0.1点が0.2点になるのを
「マシになった」
とはいいませんか?
そんな程度ですが、今と何も変わらないよりははるかにマシと思います。

116 :1:01/10/12 14:31
>>105
後半の話。個人的には賛成できる姿勢です。

>>106
おいらローカル変数で「str_Data」とよく使ってたり(w

>>107
(w

>>108-109
お題と離れ気味なけつ論ですが、いってることには賛成でおます。

>>110
変数文字数制限があったことは学問の中からちらっと聞いたことはありましたが、
2文字のがあったとは知りませんでした。結構ビクーリでした。

117 :1:01/10/12 14:51
  マターリ独言
 
  接頭詞の話はいつも「やりたくない」という意見がでてくるもんだ。
  けど、そんなもんつけるくらいにどんだけ労力をさくのよ?
  っと問いたい。
  もし。
  さいてしまうと言うならば。
  きみにはこんな言葉をあげよう。
 
    ̄ ̄|/ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
 ∧∧
 ( ゚Д゚)
 | っ日~~  シタヲ ミレ
 と_)_)    
  ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
  ↓
._____________
|                   .|
|  ヘタレに主張する権利無し  |
|_____________|
   ∧,,∧ ||
⊂ミ.,,゚Д゚彡つ ゴルァ


  明らかなる欠点。
  業務側からみたときや、実作業中での明確な不利な点が
  なければ接頭詞はつけて〜っと叫ぶ事をやめない。
  あるのとないのではまず「とりかかろう」と思う
  意志の度合いがかわるから。
 
    ̄ ̄|/ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
 ∧∧
 ( ゚Д゚)
 | っ日~~  ショウガイ メンテナンス タントウ
 と_)_)     トカニナルト チガウリユウモ ツクカモ
  ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ 

118 :101:01/10/12 15:29
タイプ量でいうなら記号的なアプローチのほうが減らせる場合が多いと思う。
strMonth > monthName
ただ、
ソースが見にくくなる場合の多くは見方を忘れたか知らない場合。
だから規約は可能な限り少ないほうが良いと思う。(オッカムの剃刀じゃないが・・)

119 :62:01/10/12 15:28
>>115
>>102 で構造体のメンバにスコープをつけない理由は、
"構造体.メンバ" で必ずセットで使うから、メンバである事を明示する必要が無いと思うからなんだけど、
クラスのメンバである場合、内部的にはスコープ問題を解決しときたいもんだよねえ。
で、それが m_ と M である時の「見た目上の」違いって、変数名(関数名も)の中の大文字を、
単語の始まりと誤認しやすいんじゃないかと思うのだがどーよ。

提案としては person.Name_mStr とかになっちゃうのかなあ。
うーん、自分でも分かりにくいので sage。
一応、先に名前と言う事が分かって、後ろ見たらスコープと型分かるんだが…

120 :デフォルトの名無しさん:01/10/12 15:29
ちょっと聞きたいんだけど、接頭詞つけるヤシは、setter,getterにもつけんの?
class hoge{
public:
int get_int_hage() const;
void set_int_hage( int new_value );
};
とかさ。

121 :デフォルトの名無しさん:01/10/12 15:43
>>120 つけないよ。
つけるとしても
 int getHageInt();
 void setHageInt(int iValue);

MS に毒されてるっちゃあ毒されてるな(笑

122 :デフォルトの名無しさん:01/10/12 15:54
int_start
chr_flag

変数にこういうプレフィックスを付けるメリットって
どういう事があるんでしょうか?
具体的な事例でお願いします。

誤って違った型に代入してしまうのを防げるとか、
オーバーフローを発見しやすくなるとか、
そういう話ですか?

123 :101:01/10/12 15:59
過去、何度かでている話題だが
名前に型を仕込むこと自体は特に問題無いと思う。
接頭だろうが接尾だろうが正確に名前をつけるなら結果は似たようなものだから。
int_x : xPosition
int_y : yPosition
ただ、付ける型の抽象度が問題になると思う。
C++のように組込み型クリソツのクラスが作れるような言語では
組込み型とクラスの区別をする必要性は薄いと思うし、
可能ならばカスタマイズできるべきだと思う。
ベタな型を書くよりは抽象的なインターフェースを用意して
(とりあえずtypedefでもヨイ)
その名前で共通した修飾をするべきだろう。
上の例なら typedef Position int;でもイイ
そしてクラスメンバはあくまでそのクラスに付属的に存在するものなので
クラス名から自明な部分を修飾する必要は無いはず。
(例えばテンプレート)

124 :デフォルトの名無しさん:01/10/12 15:59
変数名の重複を防ぐ、変数の型を識別する、変数名を規格化する
の3点。

125 :デフォルトの名無しさん:01/10/12 16:08
>>124
2,3の事例でいいので、具体的にお願いします。
たとえば、こういう種類のバグを防げたとか。
こういうツールを使うのに、便利だとか。

126 :デフォルトの名無しさん:01/10/12 16:14
他人のコード読むとき、とてつもない長い関数の変数宣言を探すのに手間がかかる。
>>123 が言ったように xPos, yPosとすると、まず名前が重複しない。
このように名前を管理する方法を「名前空間」と呼ぶんだけどね。
Win32 APIの名前空間は省略されたりされなかったりで
完全には統一されていなくて汚いんだけどね。
Sunはそのことを知っていて、Java の名前空間は整然としている。

127 :デフォルトの名無しさん:01/10/12 16:17
数学的な意味で名前空間の正規化とか、機能の正規化という言葉も
聞いたことがあるかもしれない。
こんなことは高度なシステム設計者が考えることなんだが。

128 :デフォルトの名無しさん:01/10/12 16:19
>このように名前を管理する方法を「名前空間」と呼ぶんだけどね。

ホントカヨッ

129 :デフォルトの名無しさん:01/10/12 16:24
xPos, yPos
こういう変数名使っていて、
「名前空間で識別子を管理してる」
なんて言ってるやつを初めて見た。

130 :122,125:01/10/12 16:30
なんか、抽象的な話ばっかりで、具体的な話はちっとも出てこないなぁ。

131 :62:01/10/12 16:32
>>125

スレタイトルを読むと分かるとおり、見た目の効率を上げるにはどうしたら良いかなーって話しなんで、
ソースの保守とかで“人間が”便利なのはどんなんかなーって考えてるんだけど、
実際、VB の保守でダイアログの幅(Twip値)決めるのに Integer 使ってるの見つけた時は、正直殺意を憶えたYO!

バグが無くても、例えば似たような関数を過去に作って、
それチョットいじれば使えそうな時、どこを修正したら良いか一目瞭然だったら、
それだけで時間の節約になる。

オレは1と似たような業務なんで、その手のメンテナンスの容易さって重要なのさー。
逆に多少読みにくかったり、理解しずらかったりしても実行スピード重視って仕事だったら、
寝惚けてんな! と思われるような記述してると思うよ。

132 :デフォルトの名無しさん:01/10/12 16:52
>>94
文字列こそ型情報を変数名に埋め込むことが必須だと思うが。世の中が一つの文字列型で
統一されているならともかく、現状だと

const char *
const wchar_t *
BSTR*
CComBSTR, _bstr_t
CString
std::string
std::basic_string<wchar_t>

と混在してるからねぇ(うんざり)。

133 :デフォルトの名無しさん:01/10/12 17:01
だからそういう抽象レベルで考えてちゃいかんよきみぃ。

134 :1:01/10/12 18:05
>>130

fgetsのソースで具体的なお話の試み
以下の例はみ〜んな同じことを表している。
変数の型も意味も一緒。名前が違うだけという前提で。

  ソースの例:この下
  状況等など:>>135
  ↑その私見:>>136

 ----(例1)--------------------------------------------------------------
  if( fgets( buff , sizeof( buff ) , read ) == NULL )
    return( 99 ) ;  /* 読み込むデータはもうない  */

 ----(例2)--------------------------------------------------------------
  if( fgets( chr_Buff , sizeof( chr_Buff ) , AFpp_GetRead ) == NULL )
    return( DefRTN_NoFileData ) ;  /* 読み込むデータはもうない  */

 ----(例3)--------------------------------------------------------------
  rtn = fgets( buff , sizeof( buff ) , read ) ;
  if( rtn == NULL )
  {
    return( 99 ) ;  /* 読み込むデータはもうない  */
  }

 ----(例4)--------------------------------------------------------------
  chrp_Rtn = fgets( chr_Buff , sizeof( chr_Buff ) , AFpp_GetRead ) ;
  if( chrp_Rtn == NULL )
  {
    return( DefRTN_NoFileData ) ;  /* 読み込むデータはもうない  */
  }
 
※プリフィックス説明はこれだけ「AFpp_GetRead」
 先頭の  A  :この関数へ引数として渡された領域だよ〜を表す
 次にある Fpp :FILE型の「Fp_〜」のポインタ
 アンダーバー以降:変数の名前

例1と2、例3と4がそれぞれ同じ形でおいら色接頭詞をつけてないつけてあるを
区別してあります。

135 :1:01/10/12 18:06
<状況>
バグ発生。どうやら原因はこのへんにありそうだ〜まで突き止めた

 (1):指定されている引数の型は正しいか?(1〜3番目それぞれ)
 (2):戻り値の判定方法は正しいか?(適切な値で判定をしているか)
 (3):ファイルはきっちり開かれているか?
 (4):読み込むデータ量に対して、受け皿の領域は足りているか?

(1)を検証する作業:
 例1&3・・・・・・ buff ってなにもんじゃ?
             → おお、char配列じゃの。
         read ってなにもんじゃ?
             → え?引数なの? [※1]
            
 例2&4・・・・・・ chr_Buff char型か。でもまさか配列でない事はないだろう。
             → 確かにchar配列じゃの。
         AFpp_GetRead 引数で渡されるものに入れるのだな。
             → ほんまに開かれてるのやろか・・・  [※2]

(2)を検証する作業:[※3]
 例1&2・・・・・・ NULLと判定してるな。こんなもんだろ
 例3・・・・・・・・・・ rtn ってなにもんじゃ?
             → charのポインタ型か。
               確かにfgetsの戻り値はあってるな。
 例4・・・・・・・・・・ chrp_Rtn はきっとcharポインタだな。
             → 確かにcharポインタじゃの。

(3)を検証する作業:[※4]
 例1・・・・・・・・・・ んと、確か read やったよな。デバッグ文作っていれて・・・
 例2・・・・・・・・・・ AFpp_GetReadを検証するにゃ、まずここの直前にデバッグ文入れて、
         あかんかったら呼び元でも開かれてるかも調べよう。
 例3・・・・・・・・・・ んと、確か read やったよな。デバッグ文作っていれて、
         fgetsの戻り値も調べよう・・・
 例4・・・・・・・・・・ AFpp_GetReadを検証するにゃ、デバッグ文作っていれて、
         fgetsの戻り値調べて、あかんかったら呼び元でも開かれてるかも調べよう。

(4)を検証する作業:
 例1&3・・・・・・ buff は〜charで容量が・・・フムフム
 例2&4・・・・・・ chr_Buff の配列はなんぼやねん。・・・フムフム

このほかにも、
 例1&3・・・・・・ 99は〜エラーやんな。適当でええのか?
 例2&4・・・・・・ 「DefRTN_NoFileData」ってなんじゃ〜い!
         でもきっとreturnでの返り値ならdefineやんな。
             →たしかにそうだ。[※5]

136 :1:01/10/12 18:07
これは>>135の自己注釈

[※1]
ここで初めて発見してビクーリするようだと、後々まで覚えていそうなのだが、
ほかの個所もやってるうちに3日もすればまた「なんやったっけ?」に戻る。
なぜならほかの個所も往々にしてこんなビクーリする事だらけのはずだから。

[※2]
ここでの[※1]との大きな違いは次の過程を想定できる事にある。
だいたいファイルポインタがらみで発生するエラーは
・オープンミス
・ポインタの値がずれてる
ってなもんで、それが引数になっているなら
・ほんまに引き継がれているのか?
ってのを加味すればたいてい事足りる。
もちろんスパゲッティでないことは大前提なのだが。

[※3]
この時例1&2に差はない。
例3と4が違うのは、
fgetsの戻り値がポインタ型であるってのを覚えているか否かで
理解までの時間が変わるところ。
覚えていたらさして変わらないのだが・・・。

[※4]
文章ではわかりづらいと思うが、実作業で時間のかかるかからないのは
こーゆーところの積み重ねだと今のところ思っている。
「次ぎやるべきこと」
「確実に一つ一つ決着していく事」
が頭に浮かびやすく、実行しようという気分を保ちつづけれる所に
重点を置いた場合、整然としているにこしたことはないというのが
理由。
もっとも、作業レベルでデバッグ文を入れる事には変わりはないのだが。

[※5]
この時defineのほうが作業量が多いのだが、後々の安心につながる事を
思えば、たいした問題ではない。
っと思えるか思えないかなのだろうな・・・・・・・(話ずれ

137 :1:01/10/12 18:12
  暇にあかせて具体例を作ってみました。>>134-136
  おいらの私見なのでつっこみ大歓迎にござる。
 
  っちゅうところで帰るでござる。
 
    ̄ ̄|/ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
 ∧∧    マターリ
 ( ゚Д゚)
 | っ日~~  オハナシスルニハ
 と_)_)    タタキダイ ・・・・・・カノォ
  ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄

138 :デフォルトの名無しさん:01/10/13 12:30
>>134
(例3)と(例4)は一時変数を使うかどうかということに絡んで来るので、話が
違うだろう。あえて韜晦しようとしてるなら別だが。

>>112 構造体を「テーブル」って呼んでた文化の中で育ったのでこう↑。
>>134     return( 99 ) ;  /* 読み込むデータはもうない  */
COBOL文化育ち?

139 :デフォルトの名無しさん:01/10/13 12:54
>>137
俺の場合buffとあったらローカル変数でchar型の配列だって思うけどなぁ。
iやjをみたらローカル変数でint型だと思うのと同じ。
そういう意味で変数名に型情報が埋め込まれているとみなしてる。

あとreadが引数かそうでないのかはあまり関係ないと思う。この時点でreadがきちんと
openされているかいないかが重要であって、もし駄目なら次のステップで実際にオープンしている
場所をチェックするだけだと思う。
readがもともと自分の関数内でオープンしていたとして、汎用性のために引数に
するときにいちいち変数の名前を変えるのは馬鹿らしいと思う。

140 :1:01/10/14 10:28
>>138
例1&2と例3&4の違いは「ソースの見た目」
万人が全部例1&2なわきゃありますめぇ。

そんで
  ∧ ∧  / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
  (,,・д・)< 師ガCOBOL文化ヲ継承シテタデチ
 @uu)  \__________


>>139
あなたが誰かまったく知らない人のソースを触ることがあったとき。
それも、例4のソースと例1を別々な機会で出会ったときに初めて
話が合うかもしれません。

っというのも。
「自分の作成時の楽な書き方>汎用性」
の認識もってると思われる人とは、実行速度でない、
作成速度と保守時の速度(自分のものも含む)を1秒でも
短縮しようという話はできないと思うから。
えてして、「折れがわかるからそんな書き方は余剰だ!」
ってなことになるざんしょ。

そんなん踏まえた上でのはなしやでぇっとこっちは言いたいのに。

141 :デフォルトの名無しさん:01/10/14 10:54
>>140
プログラミング言語には、それぞれ固有のイディオムというか常套句が存在する。

たとえば Perl なら変数 $_ を多用する、それも字面に出さずに暗黙のうちに操作
するのは常套手段だし、C++ や Java なら大域例外は戻り値で処理せずに積極
的に例外オブジェクトを throw するのが一般的。

そういった言語固有の表現力や常套手段を無視して、COBOL 文化圏を C に持
ち込もうとしたり、Java で書いてるのに C と同じコーディングしてるヤツのコード
は、たいていメンテナンスしづらいと思う。

>>134
俺は C のソースで read とあったら、そりゃ UNIX のシステムコールか、それを
エミュレートするライブラリ関数だと思ってしまうな。あと定数はプリフィクスで区
別するより全て大文字というのが一般的と思われ。

このあたりは K&R でみっちりC言語を勉強した人間には、共通認識だと思うが
どうよ?

142 :名無しさん:01/10/15 05:14
他人の書いたソースだと、変数名に型名が入ってても、それは信用しないな。
必ず定義部を探すよ。

143 :デフォルトの名無しさん:01/10/15 05:21
まず最初に ctag 作るね。

144 :デフォルトの名無しさん:01/10/15 06:02
>>143がトドメをさした

145 :デフォルトの名無しさん:01/10/15 09:20
汎用機で動くCtag(CはCOBOLのC)を作ってください。

146 :デフォルトの名無しさん:01/10/15 11:19
>>135
入力用のファイルポインタが「read」ってのは、へたくそすぎると思うが、
それはおいといて、
そこに出てる例なら、型が違っていれば、コンパイラがエラーやら警告を
出してくれるから、ファイル名に型情報を含めると便利な例として出されても
まったく説得力ないよ。

できれば目からうろこが落ちるような、新鮮な例をだしてください。

147 :デフォルトの名無しさん:01/10/15 11:30
正直、>>1のソースは絶対に読みたくないと思ったのは俺だけか。

148 :62:01/10/15 12:17
>>134 に関して言うと、変数名に省略されながら付加されてる引数とか型情報が、
分かりにくさを増してると思う。
特に AFpp_GetRead <- は冗長すぎて何が何だかわからなくなってる。

引数かどうかは、それこそ個々の関数の先頭を見れば分かるんだから、
fpRead で良いんじゃないかなあ。

> if( fgets( chr_Buff , sizeof( chr_Buff ) , AFpp_GetRead ) == NULL )

だったら、

if ( fgets( strBuff, sizeof(char) * BUFF_SIZE, fpRead ) == NULL )

と書き直したいところ。(オレは C 出身だけど K&R 通ってない)
>>141 の言うとおり、定数は全て大文字の方が分かりやすいと思う。
サイズの指定は冗長かとも思うが、strBuff が何のポインタなのか、
どれだけの大きさを持っているかが明示されてる分、デバグには有利と思うぞ。
(文字列のバッファとかオチる原因となりやすいので)

にしても、
> プログラミング言語には、それぞれ固有のイディオムというか常套句が存在する。
を、どうにか共通化出来る部分って変数名とか良い対象じゃないかとも思う。

149 :デフォルトの名無しさん:01/10/15 13:12
>>135-136
read,AFpp_GetRead ←こういう変数を見て思いましたが、
変数、関数に適切な名前を付けるとか、そういう事を
しっかりやってますか?

普段書いてるコードは、ひとつの関数がやたら長いとか、
モジュールの分割が適切で無いとか、そういうことは無いですか?

型情報がどうとか言うより、そういう基本的な事を心がける
ほうが、何倍も見やすくなると思いますよ。

150 :1:01/10/15 14:29
>>141
言いたいことはわかる。
そしてそれには同意する。

んでわしもK&Rで学んだこたぁないけれど、
「C言語で大文字ゆーたら定数じゃ!」くらいの共通認識はある。

<C言語文化圏の民として言葉をだしてみる>
んでも見にくいもんは見にくいとわしはいう。
定数=大文字はその他全てが小文字だからこそ見やすいといえると思うがゆえに。
「その他全てが小文字で記述」だと、大文字部分導入した場合の「区分けした見やすさ」
に及ばない。
見やすさを追求したとき、区分けすべきは定数でなく
よーわからん変数と自作関数とライブラリ関数のはず。
ゆえに、こっちを優先して区別できればそれにこしたことはないと思うゆえ。

が、ソースの見やすさってのはそれが全部でなくて、一部だっとも思うので、
接頭詞問題はそろそろやめよかと思った。

>>142
他人の書いた接頭詞が信用ならないのは同感。
最初は信用せずに調べるも、もし。
ずっと間違っていないならそのうち信用するようになると思うがどぅよ?
その時にまだいちいち見なきゃならんのと、そうでない違いはあると思うじょ。

>>143-145 & >>147
sage

>>146
たたき台の例が(゚д゚)マズーなのは了解した。

>>148
言われて改めて見直して、そういった視点のほうが多いことを受託した。<冗長云々

ポインタ宣言での扱いと、ポインタのポインタ宣言での扱いと、
微妙なところで違うことない?でも微妙だからいいのか?
けどこまかーいどーでもええことのよな気がするのでsage

151 :1:01/10/15 14:31
はてさて。
変数の接頭詞問題からはいったのは、
スパゲッティに対峙したとき、それがあった方がナンボかマシなので〜
とかそんな理由から。あと、認識の程度をはかろ〜とかそんなところ。
「これは絶対にこうでなきゃだめ!」とか思ってはないので誤解なきよう。

んで。
接頭詞云々が小さく見えてくるようなのがソース構成の仕方。
きっちりやれてりゃ追うのも楽だ。
型がわかればなおいいかんじ(ちょっとひっぱってみた)

さてっと思ったところでリロードしてみりゃ>>149がええこと言ってる。
お題からはずれることでもないのでこれにとびついてみよう。

152 :1:01/10/15 14:33
そこで。次に話題にしようと思っていること。

 | ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄|
 | 関数分割はどんなところで行うの? |
 |________________|
    ∧∧ ||
    (,,゚Д゚)||  カタレルノカ?
    /  づ||O
  @(___ノ 

方法論として。
まず2つ(またーしても叩き台)

 (1) できる限り、汎用部品を作るようにして、以外はそれぞれ専用部品で構成する
 (2) 処理の流れを構成するだけの部品、実処理を行う箇所を特化した部品を組み合わせる

実際に構築の仕方はそれこそ>>141がゆーてる言語固有の表現力や常套手段を
ふまえなければ「なんじゃこりゃ?」
になるもんだと思うが、なんだか認識のまちまちの人に聞くときに言葉に迷う。

とりあえず、細かい話はあとにするとして、

   ∧ ∧  / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
  ミ,,・Д・ミ <  (1)と(2)どっちがどぅだと思うよ?
ξミ ,,u且ミ  \______________


わしゃ誤解と語弊をおそれずに極論をいってみることにする。
        ∫
   ∧,,∧ ∬       / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
   ミ,,゚Д゚ノ,っ━~  < 心構えとしては(1)なんざ無視しても(2)だな。
_と~,,,  ~,,,ノ_. ∀  \_________
    .ミ,,,/~),  .| ┷┳━
 ̄ ̄ ̄ .し'J ̄ ̄|... ┃
 ̄ ̄ ̄ ̄ ̄ ̄ ̄   .┻

153 :1:01/10/15 14:41
 |       
 |       ふっと思いだした。
 | ∧     コンパイル時のエラー云々でないところのバグ追うのに
 |Д゚)     ソースの構成もさることながら、
 ⊂|      すんげーしょーもない変数の使い方ミスとかあったことない?
 | `〜    おいらが接頭詞にこだわり始めた原点はそこにあるの思いだし。
 |∪      でも関係ないのsage。
 ̄ ̄ ̄ ̄ ̄ ̄ ̄

154 :デフォルトの名無しさん:01/10/15 14:49
>>152
>  (2) 処理の流れを構成するだけの部品、実処理を行う箇所を特化した部品を組み合わせる
すまんがこれ日本語がよく分からん。

155 :!1:01/10/15 14:52
激しく分かりづらいので、お題を出してみたりする。

項目数3この数値からなるCSVファイルを読み込み、その合計値を標準出力に出すプログラム。

data.csv
123,10,100

% ./sample
% 233

どういう関数構成にする?

156 :デフォルトの名無しさん:01/10/15 15:36
変数のプレフィックスの利点はよく分かった。
じゃあなんで関数も修飾をしないんだい?

関数と分かりやすくするために関数の最初にFをつけよう。
それと、関数の戻り値の型、関数のパラメータにより、関数にもプレフィックス
とサフィックスをつけよう。
たとえば、
int func1(int); の場合、int F_int_func1_int(int);
void func2(void);の場合、void F_void_func2(void);
void *func3(void *);の場合、void *F_voidp_func3_voidp(void *);
などだ。

変数の場合、関数の先頭に行けばいいので比較的楽だが、
関数の場合、ヘッダファイルを漁らなければならないのでその検索時間を
少なくできる。
こんな利点があるのに変数だけにこだわって関数には無頓着な理由が知りたい。

157 :デフォルトの名無しさん:01/10/15 15:47
OOPLだと組み込み型以外のオブジェクトを使うことのほうが多い。
「プレフィックス」はすぐに破綻する。

158 :デフォルトの名無しさん:01/10/15 15:51
>>156
ネタにマジレス。
OOPLだと異なった型のオブジェクトを返すメソッドもある。
故に破綻する。

159 :デフォルトの名無しさん:01/10/15 16:45
>>155
まずは仕様をまとめてみようか。

1.項目数3この数値からなる
2.CSV
3.ファイルを読み込み、
4.その合計値を
5.標準出力に出す

1は限定条件。最適化、あるいは制限を検討すべき点
とりあえずファイルから数値を読み込む部分は独立させたほうがよさそう。
2も限定条件。ファイルの種類は固定か否かは意識されるべき
  とりあえずファイルから数値を読み込む部分は独立させたほうがよさげ。
あとは単純に処理。
とくに設計すべき点も見当たらないので言葉どおり実装していくと

main {
File file = createFile(fileName);
ElementVector elements = getElementsFromCSVFile(file);
Sum sum = getSum(elements);
putSumToSystemOut(sum);
}

160 :1:01/10/15 17:13
>>154
処理には手順があるやんね。
手順の順番を流れと言うもんという前提をおいて。

たとえば仕様書に
「CSVを読み込んで編集して別のファイルに吐き出す」
っと>>155ににたよなことがあったとする。

その際の手順は箇条書きだとこんなかんじなはず
[1].CSVファイル読み込む
[2].編集する
[3].別のファイル作成

+----+ 「処理の流れを構成するだけの部品」のこと +----+
これをこのまんま関数化するの。( >>161 参照のこと)
こうすると、実際にこの1〜3が使われている関数「FncInt_Change_CSVtoOtherFile()」は
処理の流れを表してるだけで、実際には何も実処理してないでしょ。

んで、それ以外で、実際にファイルを読み込んだり、編集したり、別ファイルを作ったりするのが、
「実処理を行う箇所を特化した部品」っちゅうよなことですわん。

161 :1:01/10/15 17:15
>>160 の説明用ソース >>155と若干似てる(!?)

int FncInt_Change_CSVtoOtherFile()
{
  int    int_Rtn ;      // 戻り値取得用
  *****   obj_DataArea ;    // データ取得用の領域と思いねぇ(初期化や解放にはつっこむナ)
 
  /* -------------------------------- */
  /* [1].CSVファイル読み込む    */
  /* -------------------------------- */
  int_Rtn = FncInt_CSVファイル読み込む( &obj_DataArea ) ;
  if( int_Rtn != DefRTN_True )
  {
    return( DefRTN_ReadError ) ;
  }
 
  /* -------------------------------- */
  /* [2].編集する           */
  /* -------------------------------- */
  int_Rtn = FncInt_編集する( &obj_DataArea ) ;
  if( int_Rtn != DefRTN_True )
  {
    return( DefRTN_False ) ;
  }
 
  /* -------------------------------- */
  /* [3].別のファイル作成       */
  /* -------------------------------- */
  int_Rtn = FncInt_別のファイル作成( &obj_DataArea ) ;
  if( int_Rtn != DefRTN_True )
  {
    return( DefRTN_False ) ;
  }
  /* ------------ */
  /* 正常終了   */
  /* ------------ */
  return( DefRTN_True ) ;

}

162 :1:01/10/15 17:17
前もって逝っとくこと。
・接頭詞問題が主ではないので、命名は気にしないように。
  (全角文字はつかえんぞ(゚Д゚)ゴルァ!!とか)
・実際に必要だけどあえてはしょったところとかあるのでつっこまないように。
  (ファイル名はどこでわかるんだ(゚Д゚)オルァ!!とか)
・実行速度とか実務での要求によってはおいらもこんな形で書かないこともあるので、
 あえて指摘したりしないように。
  (そんなん何時如何なる時もいちいちしてられるか(゚Д゚)ボケェ!!とか)
  (メモリなんぼ必要かわかれへんのに全部読み込むんか(゚Д゚)アフォ!!とか)

 ̄ ̄ ̄∨ ̄ ̄ ̄ ̄ ̄
   ∧ ∧    マターリ
   (,, ゚Д゚)∫
   /  つ旦O
 〜(._[ ̄ ̄ ̄.]

>>155
 書きすぎの感はあれども一個前のソースの「ファイルに出力」を「標準出力へ出力」
 にして、編集を合計にかえたらわかるとおもわれるのでそれでどぅよ?
 (ま〜にたよな形とゆーことで。)

>>156
>>26あたりでちらっと触れてはあるが、決してやらない訳じゃない。
変数のんでやいのやいのとやってて、接頭詞よりは構成か?ってな風潮に
したので忘れてたのじゃよ。
ちなみに一個前の書き込みのソースにVBの時に使ってた戻り値のある関数接頭詞を
つけといたので、無頓着じゃなーいっと言う面を一応。。
 (※VB文化での「戻り値のある関数」は「Function」っというのに以来してる)
 (※余談だが、「戻り値のない関数」は「Sub」なので「Sub_」にしてる)
 (  → VBエディタで色を変えてると楽に判別できるのでいい感じでしたわん)

>>157-158
実行時のメモリと速度にあんましこだわらなければラップするっちゅのはどぅよ?
それでもどーしてもこんなんに対処できん〜〜!ってなときには
「生obj_」とか型が不定なのよんってのを表す接頭詞作ってつけるとか。


  ちなみに局所的に破綻するから
  1からつかわないっちゅうのは思考停止だと思うぞ。

    ̄ ̄|/ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
 ∧∧
 ( ゚Д゚)
 | っ日~~   ナンギ ナノハ ワカルガノォ
 と_)_)   
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ 

163 :1:01/10/15 17:19
>161 せっかくソースの縦列それ得れるだけそろえようとしたのに
できんかった。。。鬱打氏脳。。。

164 :デフォルトの名無しさん:01/10/15 17:52
例外処理って・・
らくちんだよね・・・

165 :154:01/10/15 18:11
>>160
(1)ボトムアップで分けるか(2)トップダウンで分けるか、つーこと?

> 処理の流れを表してるだけで、実際には何も実処理してないでしょ。
他の関数へ引数渡したりなんだりってのも、実処理だと思うが。
どうも用語が噛み合わなくて分かりにくいところがあるな。

166 :デフォルトの名無しさん:01/10/15 21:31
>>147
俺は、彼の日本語を読むのが辛い。。。

167 :デフォルトの名無しさん:01/10/16 00:41
>>161-162
まともなC使いはそんな無駄な記述はしない。
書き込みもソースも冗長に過ぎる。

168 :デフォルトの名無しさん:01/10/16 01:32
ageてみるか

169 :1:01/10/16 01:39
>>164
ど、どこからそれが?(脈絡がわからなくてどぎまぎ)

>>165
そんなようなこと。多分イメージせんとするところはまちがっちゃ〜いないと思う。
実際の処理を構築する際の話になると、ズレはでてくるのだが、ワケワカランのでsage。

実処理のんはいいすぎだった。たいした処理もなく〜で言い換えることにします。

>>166
で?意見が無いのはsage

>>167
その冗長のソースをみて、処理内容を勘違いするやつとか、
ソースの内容がわかりにくいってやつがでてきます?
でてくる要素があるならご指摘いただければ新たな視点になりまする。

170 :デフォルトの名無しさん:01/10/16 01:44
マクロと定数以外、全部小文字。
区切りは_

FileNameよりはfilename、またはfn
Rtnよりはresult、またはret
DataAreaよりはdata_area、またはdst

171 :1:01/10/16 01:44
>>168
ありがたう。でもヨパラ-イなので寝。

172 :デフォルトの名無しさん:01/10/16 01:55
>>169
これは頭悪いだろ…
DefRTN_True
DefRTN_False

173 :165:01/10/16 02:10
>>169
> その冗長のソースをみて、処理内容を勘違いするやつとか、
> ソースの内容がわかりにくいってやつがでてきます?
167じゃないが、「たいした処理もなく」というならそれなりに「たいしたこ
としてないように見える」ように書くってなことかな? もちろん暗号みたいな
ソースを推奨するわけじゃないけど。

たぶん>>164は、こういう戻り値のチェック→エラーリターンの繰り返しより
も例外処理を使ったほうが楽だといいたいんじゃないかな。

それと、このコメントと関数名は冗長だと思う。もちろん関数名に日本語を使
うとは思わないが、直訳しただけのコメントならいらないな。
なんとなくCOBOLから入った人間にこの手のコメントが多いような気がするが。
>   /* -------------------------------- */
>   /* [1].CSVファイル読み込む    */
>   /* -------------------------------- */
>   int_Rtn = FncInt_CSVファイル読み込む( &obj_DataArea ) ;

174 :デフォルトの名無しさん:01/10/16 03:51
>>162
> (※VB文化での「戻り値のある関数」は「Function」っというのに以来してる)
> (※余談だが、「戻り値のない関数」は「Sub」なので「Sub_」にしてる)

これはVB発祥ではないよ。
戻り値の無い手続き処理(サブルーチン)と値を返す関数(ファンクション)は
古くから、他の言語でもそうなっていた。
発祥はどの言語かしらない。

それから1の文章は長いし読みづらい。
それぞれの文章の意味も「俺単語」を使ってることもあって、よくわからない
ものがある。

もう少し簡潔にわかりやすく書いてもらうと、読む気力も出るんだが・・・。

175 :デフォルトの名無しさん:01/10/16 04:01
>>159
>main {
>File file = createFile(fileName);
>ElementVector elements = getElementsFromCSVFile(file); //(1)
>Sum sum = getSum(elements);
>putSumToSystemOut(sum);
>}

俺だったらこんなかんじに分割するかな(無理に分割すれば)
main {
File file = createFile(fileName);
String line = getLine(file); //(1)'
ElementVector elements = getElementsFromCSV(line); //(1)''
Sum sum = getSum(elements);
putSumToSystemOut(sum);
}

(1)を(1)'と(1)''に分割したんだけれど、>>1が語りたいのはこういうこと?

176 :デフォルトの名無しさん:01/10/16 04:04
それから>>161のコードは冗長すぎると思う。
藤原某の某診断室を思い出したよ。
はっきり言えば、読む気がしない。

177 :デフォルトの名無しさん:01/10/16 04:32
>>175
同意。
テキストファイルに格納されているデータは、
基本的に行を単位とした構造なので
行指向で処理するのが妥当。
CSVも行単位のデータ構造なので、
getElementsFromCSVFile(file) と全体を処理するなら、
返り値は Vector の Vector にしてほしい。

178 :デフォルトの名無しさん:01/10/16 05:05
>>174
それを言うならプロシージャとファンクションという気もするが・・・

179 :デフォルトの名無しさん:01/10/16 07:28
>>169
> その冗長のソースをみて、処理内容を勘違いするやつとか、
> ソースの内容がわかりにくいってやつがでてきます?
簡潔さは明快さにつながります。冗長な記述は、文章でもプログラミングでも、焦点をぼやけさ
せて読者の注意力を殺いでしまいます。

私は関数分割の仕方は、場合によりますね。CSV ファイルの入出力でも、

- 巨大なファイルを扱う可能性が高いので、進行状況を表示したい

とか

- Excel のように一部でも画面に表示したい(画面が真っ白で止まってしまうのは最悪、ファ
 イルの先頭部分だけでも画面に表示した上で、処理を開始したい)
- 途中で一時停止できるようにしたい/キャンセル可能にしたい
- 数値の足し算だけでなく、ユーザ定義関数呼び出しのようなより高度な機能も実装したい

などの要件があれば、設計はまったく異なってきます。

たとえば一番最後のユーザ定義関数を前提とするなら、私は行単位で処理するのではなく、
シンボル管理テーブルを別につくり、シンボルテーブルを参照しながら入力ストリームから
トークン列を切り出し、それを構文解析ルーチンに渡すような作りにします。

逆に、単に使い捨てのコードなら、

% cat > csvadd.c
#include <stdio.h>

int
main(void)
{
  char buf[256];
  char int n[3];
  fgets(buf, sizeof(buf), stdin);
  sscanf(buf, "%d,%d,%d", &n[0], &n[1], &n[2]);
  printf("%d\n", n[0] + n[1] + n[2]);
  return (0);
}
^C

% cl csvadd.c
%csvadd.exe < input.csv > output.csv

で済ませてしまうでしょう(実際には C 使わずに perl -lne '/(\d+),(\d+),(\d+)/ && print $1 + $2 + $3'
とコマンドラインから入力すると思いますが)。

プログラミングで本当にプログラマの質が問われるのは、アーキテクチャの選択と設計の部
分です。それを「与えられたもの」として関数分割の単位だけ議論しても、瑣末事に目が行っ
てしまい実のある話し合いには難しいかと。

180 :Error401:01/10/16 09:37
>>179
>プログラミングで本当にプログラマの質が問われるのは、アーキテクチャの選択と設計の部
>分です。それを「与えられたもの」として関数分割の単位だけ議論しても、瑣末事に目が行っ
>てしまい実のある話し合いには難しいかと。

1氏の真意は未だによく理解できてないのですが、>>159>>179のコードのような
比較があり、それについてあれこれ議論するのは無駄では無いと思います。

僕は大体適当にやってますけど、人によっては確固たるポリシーがあったり、
「凝集度と結合度」をいつも考えてたりする人がいるかもしれないじゃないですか。

そいう人たちの話を聞きたいとは思いません?

181 :Error401:01/10/16 09:39
s/>>159>>179/>>159>>175/

182 :デフォルトの名無しさん:01/10/16 09:45
>>169=1
>>>166
>で?意見が無いのはsage
別に君宛てに言ってるわけではないんだろうから、「で?」も何も無いでしょ。
「俺の役に立ってねえよ宣言」は、このスレの発言の全てが血肉として君に
捧げられたものでなくてはならない状況下でぶちあげてくれ。
そうではないこの状況においては、スレを私物化してる意識が見えてキショいだけだよ。

183 :デフォルトの名無しさん:01/10/16 10:01
>>179
アーキテクチャって何ですか?

184 :デフォルトの名無しさん:01/10/16 10:15
おふぁようage(あばば)

185 :デフォルトの名無しさん:01/10/16 10:22
ageないで欲しいズラ……。

186 :デフォルトの名無しさん:01/10/16 14:53
>>183
辞書を索け

187 :1:01/10/16 15:39
architecture
【発音】α':(r)kэte`kt∫э(r)
【@】アーキテクチャ、アーキテクチャー
【レベル】3
【大学入試】
【名-1】 建築(術){けんちく(じゅつ)}、建設{けんせつ}、構造{こうぞう}、建築物{けんちくぶつ}
【名-2】 《コ》アーキテクチャ、(ハードウェアまたはソフトウェアの)基本設計概念
◆【語源】昔のコンピュータは、大型であったため、それを設置することは“建築”並みのことであった。

出典はここ
ttp://www.alc.co.jp/

188 :1:01/10/16 15:40
幾人かに指摘されていることを受け止め、文章をわかりやすくする努力をしましょう。
是非があるだろうけど、今回も逐次レス。

>>170
そりは>>169の>167に当てた内容の指摘内容?
であるなら
今まで通りの手法である方がいいのねっと思っとく。

>>172
頭の(・∀・)イイ! 悪いはどっかにおいといて・・・(;´д`)ハァハァ

189 :1:01/10/16 15:40
>>173
>それなりに「たいしたことしてないように見える」ように書くってなことかな?
そうそう。
そして、164の解釈をありがとう。
 けどそれは、言語特性の部類に入りそうなのでsageとこう。

>それと、このコメントと関数名は冗長だと思う。もちろん関数名に日本語を使
>うとは思わないが、直訳しただけのコメントならいらないな。
コメントと関数名を冗長にするのには理由があって。

  〜〜 その1:おいらの個人的な理由 〜〜
   ・自分作成とすぐわかる (コメントも関数も)
     → 直しやすい
       → 1ヶ月2ヶ月や半年たってたとしても1から見直す必要なしという意味で

   ・エディタにVC++使っていて、コメントとソースと背景の色分けしている。
     → コメントがきれいに四角く色分けされるため見分けやすくなる。

   ・ソースを見て先ず目にはいるのは余白に浮かぶ日本語だ!っと思ってる。

   ・英字をみなれてない。

  〜〜 その2:共同作業時での理由 〜〜
   ・コメントが消え去っていても関数の役割がわかる
      自分のものがコピペ元になる可能性がある
         ↓
      コピペで生まれ変わったものは原本より質が落ちることを
      前提に考えるのが安全策と思う
         ↓
      それでもたやすく崩れないものをつくっておかねばと思い実行
         ↓
      もしくは「作り直した方が早ぇな」の決断までの時間を短くする
      手助けのためになればとも思う

   ・自分の勘違いを指摘してもらいやすい
         ↓
     コメントの日本語だけみても何やってるか検討がつきやすい。(のかなぁ)
         ↓
     ひいてはなれない言語でも品質を落とさないことにつながる。はず。

個人的な理由の方はもはや自分のソースに酔いしれているところが多いが、
共同作業時のは未だ試行錯誤中のこと。(悩み中

今回のお題も↑このへんから沸いてること。
でも話がそれてるのでsage

190 :1:01/10/16 15:41
>>174
うぃ。気をつけまふ。

>>175
>(1)を(1)'と(1)''に分割したんだけれど、>>1が語りたいのはこういうこと?
いや違う。
というのも、「何でもかんでも分割すればええっちゅうもんではない」
っと思ってるから。
例題の場合、必然性が見あたらない。
ただ2行に分けただけで、
「○○がしたいから、××には目を瞑る」っというのがない。

おいらの場合、
  「ソースの理解のし易さを追求」がしたいから、
  「プログラムの実行速度とメモリの使用量」には目を瞑る
っという理由をもっておりますです。

<余分かも>
もし、>>159のソースに、おいらの冗長なく手を加えるとしたら、こう

---------------------------------------------------------
main
{
  File file = createFile(fileName);

  ElementVector elements = getElementsFromCSVFile(file);

  Sum sum = getSum(elements);

  putSumToSystemOut(sum);

}
---------------------------------------------------------
ただ余白を設ける。
それだけでいいとも思うこころは持っています。

191 :1:01/10/16 15:43
>>176
極端なものに否定がつけば、きっとその手前で答えが見つかると思う。

冗長すぎるものなら冗長を排除した形が美しい〜っていうのうが
含まれていると思われます(都合良く解釈)
おいらはそれはどの辺かっちゅうのも検証してみたい。
(今までのでてきた同様の意見も含めて)

ちなみにその藤原某の某診断室は存じません〜がこりはsage。

>>177
>基本的に行を単位とした構造なので
>行指向で処理するのが妥当。
>CSVも行単位のデータ構造なので、〜
改めて見直してみたらそうか。そういう意図があるともとれますな。

それなら結構誤解な返答になってるかも。
スマソ >>175

>>178
単語と用語の用い方は各人が吸収&意図を組むっちゅうほうこうで・・・(^^;

(・・・・・・限度はあるにしろ・・・>>特に1・・・Σ(゚д゚lll)ガーン )

192 :1:01/10/16 15:44
>>179
たしかに意識の方向がてんやわんやなうちに局所なところを
語ろうとしても難儀な点、その通りに思います。

そして。

いきなり方向転換してもこれまた混乱を招く原因になりそうだし、
話ネタにできるソースもだしていただいてありますので
その話題へ転向しようかと思っておりまする。
(上のほうでさんざん言いたいこといってきましたが。。。)

その上で。

>>180 (でError氏の言葉より)
「人によっては確固たるポリシーがあったり、「凝集度と結合度」をいつも考えてたりする人」
の意見を拝受頂ければ、また新たな視点が生まれるやもしれないと思います。

ゆえにそっちの道に向かおうと思うので

 | ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄|
 | プログラマならソースで語ろう        |
 |________________|
    ∧∧ ||
    (,,゚Д゚)||
    /  づ||O   ッテェーノヲ メインニ
  @(___ノ

っちゅうので、なんでもかんでも逐次レスは混乱させるばかりに
なりそうな気もするので、一旦やめ。・・・ていい?

193 :Error401:01/10/16 16:11
>>190
>例題の場合、必然性が見あたらない。

>>159
>ElementVector elements = getElementsFromCSVFile(file); //(1)
(1-a)ファイルから一行読み出して文字列を取得する
(1-b)その文字列を','区切りで分解し、Vectorを構築する

>>175
>String line = getLine(file); //(1)'
>ElementVector elements = getElementsFromCSV(line); //(1)''
(1)'ファイルから一行読み出して文字列を取得する
(1)''引数の文字列(CSV)を','区切りで分解し、Vectorを構築する

凝集度と結合度について
http://village.infoweb.ne.jp/~fwgf2942/KeyWords/KW.Coupling.html

によれば、凝集度は、
159はレベル5:通信的凝集(あるデータを処理するまとまり。1関数複数機能)
175はレベル7:機能的凝集(1関数1機能の状態)
という違いがあります(僕の判断では)。

今回の例は処理内容が単純なので、わざわざ分けるほどのことも
ないかもしれませんが、「関数分割をどういう基準でやるのか」を
考えたときには、175の方が良いと考えます。

というわけで、凝集度を高めるが故の必然なんですね。
僕の場合は、野生の感で関数分割しますが、
「get_line()してsplit(',')」
みたいなことはあまりやりません。大抵分割します。

194 :165:01/10/16 16:10
まぁいろいろ考えるけどひとまず一点だけ。

>>190
> ただ余白を設ける。
余白も重要なんだが、この例では単に一行ごとに入れただけで、間延びしてい
るようにしか見えないのが、残念なところ。もっとメリハリというものがある
はず。

195 :Error401:01/10/16 16:17
>>190
>ただ余白を設ける。

変数や関数の命名規約やコーディング規約(スタイル)の方を語りたいのかな?
こっちはあまり興味ないです。

>>191
>ちなみにその藤原某の某診断室は存じません〜がこりはsage。

藤原博文氏の『Cプログラミング診断室』のことでしょう。
2chでは、藤原氏はDQNというレッテルが貼られているような気もしますが、
僕はこの本は好きです。内容がちょっと古いですけど。(あと誤りもあるらしい)

Webで全文が読めます。
http://www.pro.or.jp/~fuji/mybooks/cdiag/

196 :Error401:01/10/16 16:27
ちょい追加説明。

>>193
>(1)'ファイルから一行読み出して文字列を取得する

この「ファイルから」というのがポイントで、抽象度を高めて言えば
「ストリームから」あるいは「永続化オブジェクトから」ですよね。

これって分けといた方がいいと思いません?

197 :159:01/10/16 17:16
>>193
>凝集度のページ
お、こりゃあいい事を知った。ありがとう。

// 関係ない話
>レベル1:偶発的凝集
アヒャヒャ、なんて素晴らしい名前だ。
今年の新人のコード思い出して泣けるよ。

指摘された通り、getElementsFromCSVFileには
複数の機能が内包される。
これは名前からも想像できると思う。
ただ、この関数自体の実装を考えるとすれば
厳密には分けるんだが実際には分けてない状態を想像してた。
というのも大抵の環境ではテキストストリームから
一行ずつとってくるオペレーションは
用意されているから。
また、一行ずつとってきて、それをさらに分解するという流れは
CSVファイルを意識したものなので
対応する一つの関数を作ったほうがmain関数自体の凝集度を低める点から
言っても損はないと思う。
俺はとっさにファイルフォーマットのカスタマイズを意識して
このように分けたが
テキストファイル=一行分割
というパターンが出来上がっている人はたしかに
一行取得を再利用も兼ねて分けると思う。

198 :159:01/10/16 17:18
意見がまとまってないが
忙しいのでとりあえず半端にサラバ

199 :デフォルトの名無しさん:01/10/17 21:15
ただいまプロジェクト中のすべてのクラスの頭に
 DCCN をつけることを強制されております。
さらにその下に2文字の「モジュール識別子」なるものが
つけさせられてしまったりもしています。

const には c をつけ、
ポインタには p をつけ、リファレンスには rf をつけ
オブジェクトには o をつけなければなりませぬ。

つまり、座標のリストから指定のペンで連続直線を引くメソッドは

void DCCNXXxxxx::DrawPolyLine(const DCCNXXxxxx& crfo_Points, const DCCNXXxxxx& crfo_Pen);

200 :同ネタ代表:01/10/18 10:21
DQNかとおもた

201 :1:01/10/18 11:55

   ∧ ∧  / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
  ミ,,・Д・ミ <  昨日の昼かきこまれへんことなかった?
ξミ ,,u且ミ  \__________

>>193
 <雑談気味に>
凝集度と結合の話リンクをありがとう。
こんな言葉があったのね。覚えておいてそのうちつかわしてもらおうφ(.. )
藤原博文氏の『Cプログラミング診断室』は余暇にまた読んでみる。

 <細かいところで>
んでその分割のところで。
>>>ElementVector elements = getElementsFromCSVFile(file); //(1)
>>String line = getLine(file); //(1)'
>>ElementVector elements = getElementsFromCSV(line); //(1)''
>(1)'ファイルから一行読み出して文字列を取得する
>(1)''引数の文字列(CSV)を','区切りで分解し、Vectorを構築する
このとき、(1)を分割し、凝集度をLv5→Lv7にするのも、
「getElementsFromCSVFile」内部で(1)'(1)''っと分割した形で記述しても、
(1)の凝集度はLv7であるっと思った(関数を管理するだけの関数という意味でのLv7)

用語の解釈間違いあったらごめん。

202 :1:01/10/18 11:55
>>197
>main関数自体の凝集度を低める点
Lv1までやってまう?(w

  159のソースの形がLv7だかLv4だかおいらもよ〜わかってないんだけど、
  mainがこの場合再利用性を無視してもええんちゃうんじゃないかな〜とは
  わし思ってみたり。
  きっと、「再利用性をつける」のと「再利用性のことはあえて無視する」
  の区別つけられるのも、プログラマとしての質ってやつになるのかな〜
  っと全然違う方向を妄想してみたり。

    ̄ ̄|/ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
 ∧∧
 ( ゚Д゚)  
 | っ日~~  ズズッ...
 と_)_)  
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄

>>199 は〜ご愁傷様です。(−人−)ナムナム

そんな接頭詞はおいらもいやです。Σ(゚д゚lll)ガーン

203 :1:01/10/18 11:57
余白の話。
間延びの話はよ〜わかる。
わしも間延びソースはいやんってな感性もってたから。
でもね。
戦闘モードでないときにね。
ごちゃっとしたの見たくないの。

 ※戦闘モード:プログラムを作っている真っ最中のこと。
        世の中の雑務や会話など全てが「邪魔だ!」っと思えるほど
        没頭している精神状態にあることを指す。

>>189 の個人理由その1の上から3番目
 ・ソースを見て先ず目にはいるのは余白に浮かぶ日本語だ!っと思ってる
ってのは、非戦闘モードの時に感じたこと。

そんな視点を持ってから、戦闘モードでも
「いちいち細々追うのだるいぞ! もっときっちりまとめとかんかぃ!!」
っと思うようになってもた。
エディタでせめて色分けできればその限りじゃないんだけどね。(←これも言語特性か。)

って〜のを感じてからだ。

「体裁にある一定の意味合いを持たせればソース解析の時間がもっと短くなれるはずだ!」
っと思ったのは。

 ̄ ̄ ̄∨ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
   ∧ ∧    マターリ
   (,, ゚Д゚)∫    閑話休題
   /  つ旦O
 〜(._[ ̄ ̄ ̄.]

204 :デフォルトの名無しさん:01/10/18 12:06
>>202
159はmainじゃなくてgetElementsFromCSVFileの再利用を考えているのでは?
ただ単に凝集度を高めたいだけなのかもしれんが。

205 :デフォルトの名無しさん:01/10/18 12:13
>>199
少なくとも DCCNXX はクラス名ではなく namespace で対処するべきだよなぁ。

206 :デフォルトの名無しさん:01/10/18 12:49
namespace を知らないに 1 Stroustoup

207 :デフォルトの名無しさん:01/10/18 13:40
namespaceというものを後から知ったがリーダーが頑固すぎた
に 3 Wirth

208 :デフォルトの名無しさん:01/10/18 14:28
上から押し付けられてどーしようもない。
に 4 DQN

209 :199:01/10/18 14:30
namespace を知らないに 1 Stroustoup

多分これかと、っていうか「モジュール識別子」ってなによ?
一応 "DM" ってつけてやってるけどさ。

210 :デフォルトの名無しさん:01/10/18 15:15
つーかStroustoupってなに

211 :デフォルトの名無しさん:01/10/18 18:26
>>210
Stroustrup のスペルミスと思われ。

212 :デフォルトの名無しさん:01/10/19 19:27
この本、面白いよ.

Writing Solid Code ISBN4-7561-0364-2
Debugging The Development Process ISBN4-7561-1623-X
Code Complete ISBN4-7561-0210-7

すべて、株アスキー出版。日本語。

213 :デフォルトの名無しさん:01/10/20 15:44
どうでもいいが、なんでこうアンチハンガリーが多いんだ・・・?

214 :デフォルトの名無しさん:01/10/20 15:57
age

215 :デフォルトの名無しさん:01/10/20 15:58
アンチというか、効果がないからだろ

216 :デフォルトの名無しさん:01/10/21 02:32
つーかさ、診断室も知らんかったのか? > 1
プログラミング作法とかフツー読んでるもの読んでからやってくれ、DQNな
議論が続くのは見るに耐えん。

217 :デフォルトの名無しさん:01/10/21 02:33
age忘れた。

218 :デフォルトの名無しさん:01/10/21 02:49
だからageないでくれえ。

219 :デフォルトの名無しさん:01/10/21 02:51
>>213
ハンガリー信者ウザイ
変数名にまで変な名前付けるなよ(w

220 :デフォルトの名無しさん:01/10/21 03:04
ハンガリアンって多態した時点で破綻しないか?

221 :デフォルトの名無しさん:01/10/21 03:08
オブジェクト指向とはびみょーにマッチしない、と俺は思う。

222 :デフォルトの名無しさん:01/10/21 03:09
>>220
抽象化してもダメだろ。

223 :デフォルトの名無しさん:01/10/21 03:17
>>220
そういう時はとりあえずオブジェクトを表す O を頭につければ大丈夫。

224 :デフォルトの名無しさん:01/10/21 03:19
それはんがりアン意味ないヨ!

225 :デフォルトの名無しさん:01/10/21 03:22
>>220-224
激しく外出。

226 :デフォルトの名無しさん:01/10/21 03:24
他人のソースのメンテで変数にハンガリアン使われてるとムカツク
殴りたくなってくる。

227 :>225:01/10/21 03:25
じゃあなんでハンガリアン信者は
いまだに激しく抵抗してんだ?

228 :デフォルトの名無しさん:01/10/21 04:09
Python/Ruby使いでハンガリアンって居そうな気がする。
漏れC++/Javaではアンティ・ハンガリアンだけど、
ruby書いてると変数の型を気にして自分を見失いそうになる。

229 :デフォルトの名無しさん:01/10/21 04:16
自分のソースはまだマシだと思うのだが、
勉強する気が無い人のソースを読むのが辛い。
extern宣言をcppファイルに必死に書いてたりするんだもん。
クラスのメンバ関数の入っているファイル名から、
クラスの宣言のファイル名が推測出来ないんだもん。
だから、この掲示板見てるだけで、まだマシなレベルはあると思われ。

230 :デフォルトの名無しさん:01/10/21 04:37
Ruby に関して言えばスコープ用の $ @ @@ で足りてる
第一変数に型ないし

231 :デフォルトの名無しさん:01/10/21 04:48
$ @ @@
ダサダサ

232 :デフォルトの名無しさん:01/10/21 04:54
最初はそう思うけど意外と悪くないよ。
記号ゆえに目に付きやすくて判別が容易。
さらに、記号を減らしたくなるから余計な変数を使わなくなる(w

233 :デフォルトの名無しさん:01/10/21 05:00
>>230
例えばEnumerable配合の型を入れる変数に、
識別子使いたくなんないスか?
漏れは複数形を使ったりして区別してるんだけど、今一。

234 :デフォルトの名無しさん:01/10/21 21:53
>>233
複数形でいいんじゃないの?
自分の書いたコードをざっと見てみたらそうしてた。

使い捨てる配列のローカル変数は ary で済ますことも多いかな。
例えば文字列を split した結果など、
オブジェクトというよりもデータの加工途中の場合。

どんな型のオブジェクトでもポイントできるのに、
型で変数名に接頭辞をつけるのは意味ない。

235 :デフォルトの名無しさん :01/10/23 00:18
>>219
>>227
ハンガリアンでなくても、自分が各ソースの変数名って自分がわかりやすいように
つけるよね?で自分の中である程度の規則はできるよね?

それとも、まるっきり、規則性無いのかな?

で、その規則って自分のものだけだから、自分が見れば、あこの変数はpointer
だとか、ループ用のインデックスー、ってなるが他人から見たらなんじゃこれ?
になる。その規則をハンガリアンにしていても問題無いジャン。
好き嫌い在るにしても認知されてんだしさ、いきなり他人のソース見てその人
の変数名の傾向を知ること出来ないもん.

と書いているが、ハンガリアンはすべてをハンガリアンできないので、どうかな
とおもうが。。。

236 :デフォルトの名無しさん:01/10/23 00:47
>>235
ハンガリアンが役に立つのは、ユーザ定義型ではなくプリミティブ型だと思うな。特に C だと
char * と char [] を混同できる仕様になっているから、これで混乱しないように (l)psz, sz で
区別するのは、それなりに役に立つ。

オブジェクトに関しては、変数が型を知っているから、わざわざプリフィクスで区別するまで
もないと思う。

237 :へたれぴーじー:01/10/24 11:22
非オブジェクト指向言語とオブジェクト指向言語で同じルールを使おうとするのが間違い、と。
オブジェクト指向言語なら昔のように訳分からん変数名はないだろうし、あまり規約は考える必要ないはず。
で、非オブジェクト指向言語で、一番汎用的な命名規約ははんがりあんじゃないかと思う今日この頃。

>232
同意。何打間だイっても強制的に記号が入れば考える必要ないし。

238 :へたれぴーじー:01/10/24 11:22
agetesimae

239 :デフォルトの名無しさん:01/10/24 11:41
ageるなバカ

240 :デフォルトの名無しさん:01/10/24 17:27
MSの開発者サポートの核は豊富なサンプルコードだし、
それを読むにあたってはハンガリアンは非常に役に立ってる。
誰が書いても見た目が似たソースコードになってるから。
自分で書く分には守っていないが。

ハンガリアンではないけど、グローバル変数はそれとわかる
命名をしてくれないと困るな。
頭にgだのg_だの付けるのは、読む側からは非常にありがたい。

241 :デフォルトの名無しさん:01/10/24 19:28
>>240
ようするに入門書のコメントのようなものということか?

i = 1; /* iに1を代入 */

242 :デフォルトの名無しさん:01/10/24 20:49
>>241
要するな。しかも的を外してるし。

243 :デフォルトの名無しさん:01/10/24 22:03
(゚д゚)<将を射んとすればまず馬を射よ

244 :デフォルトの名無しさん:01/10/24 23:19
釣れました。

245 :デフォルトの名無しさん:01/10/25 02:21
サンプルコード用ってことだろ。

246 :デフォルトの名無しさん:01/10/25 10:00
サンプルコードというか、読ませるためのコードに命名規則は重要。
特にMSのように長年に渡り各方面の多人数が(互いに関係しない
人間が)よってたかって書くようなものは。
ウィンドウハンドルはhwndとかね。
メンバ変数が m_XXなのも、サンプルを読む側からは一番良い。
MSも別にハンガリアンがベストだと考えてるわけでなくて、
ハンガリアンにとって代わる命名規則を開発できないだけでは。

247 :デフォルトの名無しさん:01/10/25 10:48
MSはハンガリアン捨てるっていってるけど……
MSにいたスーパープログラマーがハンガリアンを推し進めてたって聞いた。
いまはカトラーとかヘジとかが主導権握ったから変わったんじゃないの?
カトラーってもういないっけ?

248 :デフォルトの名無しさん:01/10/25 10:59
>>240
g_とかは、「ハンガリアン」じゃねえだろ。
こういう議論をしてると必ず出てくるんだよな。
プレフィックスの類は全部ハンガリアンだとか
言う大雑把なヤツが。
こういうヤツの言うことはまったく信頼性無し。

249 :デフォルトの名無しさん:01/10/25 11:21
ハンガリアンの語源って何なの?

250 :デフォルトの名無しさん:01/10/25 11:22
>>248
自分の読解力の心配が先じゃないの?

251 :デフォルトの名無しさん:01/10/25 11:25
>>249
最初に始めた奴がハンガリー系だったから。
かなり失礼な話のような気もするが。

252 :デフォルトの名無しさん:01/10/25 11:49
「実録 天才プログラマ」(ASCII刊)に、そのハンガリー系のプログラマへの
インタビューが載ってるよ。マイクロソフトに転職したあと、自分の使って
いたその方式が社内に広まったと言っている。

253 :デフォルトの名無しさん:01/10/25 11:50
>ハンガリアンにとって代わる命名規則を開発できないだけでは。
結局これかね。
万能ではないのは誰もが認めつつもこれが一番汎用的ってところで。
各社、各人独自の命名規約が溢れるよりはよっぽどマシだろうし。

254 :デフォルトの名無しさん:01/10/25 13:24
>>253に同意
最近は「オブジェクト指向言語に命名規則は不要」派が幅を
利かしているようだが、自分で書く場合はともかく、
サンプルコードを斜め読みする場合には有った方が読みやすい
ことは確か。

SunのJavaサンプルコードの変数名なんて、命名規則を工夫しよう
という姿勢が全く無くてどうにも気に入らない。
10行程度の関数はともかく、それ以上になると
TextField responseMessageText
ServerSocket listenSocket
のように冗長すぎ。
サンプルだから書く手間は関係なしに理解のし易さだけを考えて
こうなったのはわかるが、頭が悪そうというか画面が文字でビッシ
リで拒否感を覚えるというか、、、

255 :デフォルトの名無しさん:01/10/25 13:39
>>254
>画面が文字でビッシ リで拒否感
改行すればいい。
なんなら1行おきにソース書け

256 :デフォルトの名無しさん:01/10/25 14:14
ん?バリバリ記号的に略したソースなぞそれこそ見たくないな。
タッチタイプする時や読む時に素直に読めない。
少ない規約で自然に理解できるソースが理想。

257 :デフォルトの名無しさん:01/10/25 14:29
>256
略すための共通ルールが欲しいってことでそ。

258 :デフォルトの名無しさん:01/10/25 14:30
>TextField responseMessageText
>ServerSocket listenSocket

あのう、それは立派にJavaの命名規則に従ってるんですけど。
英単語そのまま、可能な限りフルスペルで書くようにってね。
俺的にはこっちのが遥かに読みやすくて好き。
書く手間? エディタでいくらでも補完できるじゃない。

てゆーか、hWndみたいな変数名みると拒絶感覚える。
こんなもんwindowとか、せめてhWindowにしてしまえと何度も試みるんだけど、
すると今度はAPIとの不整合が気持ち悪くなるので駄目なのね。
仕方ないからWindowsのAPIが見える場所では嫌々ハンガリアン使いますけど。

そうそう、C#ではMSはハンガリアンは使うなと明言してますので、
(推奨しないとかではなく、はっきり「使うな」。ドキュメント参照のこと)
ハンガリアン派な皆様、C#移行の際は頼みますよ。
郷に入っては郷ひろみ。

259 :デフォルトの名無しさん:01/10/25 14:34
>>258
hWndからなんで、windowってことになるんかな。
せつめいして。

260 :デフォルトの名無しさん:01/10/25 14:59
>>254
それは英語がわからない人が見たらそうかもしれないけど、
英語がわかる人から見たら、わかりやすいのでは?

261 :デフォルトの名無しさん:01/10/25 15:09
>>258
>TextField responseMessageText
>ServerSocket listenSocket
JAVAを知らなかったら何が何を意味してるのか、
文法的にさっぱり想像もつかん。

262 :デフォルトの名無しさん:01/10/25 15:17
>>261
それは hWnd に言うことだろ、っていう突っ込みきぼんなのか?

263 :デフォルトの名無しさん:01/10/25 15:42
>>261
JAVAを知らない奴だったら、どう書こうがさっぱり想像もつかんだろ・・・

264 :デフォルトの名無しさん:01/10/25 15:47
言語固有で命名規約持つならそれで問題ないだろ。
全ての言語に通用する規約なんかあるわけないんだし。
つーことで、C基準の話でいいと思われ。

265 :デフォルトの名無しさん:01/10/25 15:55
俺はメンバ変数はフルスペル。
ローカル変数は簡略化するけどな。

source,destinationとか一々書くよりsrc,destの方が断然綺麗だし。

266 :261:01/10/25 16:04
>>262-263
いやいや、C++の文法知ってればなんとなくJAVAの文法もわかりそうなものだろ。
っとJAVAのリファレンスみながら思ったのでな。

267 :デフォルトの名無しさん:01/10/25 20:20
>>265
これ、同意。

フルスペルがポリシーの人たちは、ループ用のカウンタや、一時バッファ
にどう言う名前をつけるのでしょうか?

268 :267:01/10/25 20:21
>267
ただし、>265の src, destはやだ。

269 :デフォルトの名無しさん:01/10/25 21:33
>>268
src, dest って、むちゃくちゃありふれてるやん。
ループカウンタの i と同じくらい。

270 :デフォルトの名無しさん:01/10/25 21:52
>>269
個人的には dst の方が好みかな。

私はローカルな一時変数だと、省略した

i (iterator, loop counter)
c (文字型、ただし EOF を受けるときには int)
n (整数)
p (ポインタ)
s (文字列, もしくはソケット)
buf (unsigned char[])
fn (関数ポインタ)
src
dst
tmp

あたりは良く使う。これも、特定用途のローカル変数につける名前ということで、命名規約の
一種なのかな。

271 :デフォルトの名無しさん:01/10/25 22:21
プログラマなら、イテレータは it だろうが!

272 :デフォルトの名無しさん:01/10/25 23:20
>>271
整数イテレータ:i,j,k...
STLのイテレータ:it(足りなくなったらitの後に識別子を追加)
ってやってる

273 :デフォルトの名無しさん:01/10/26 01:09
俺は引数をargにするってのが一番多い。

274 :267:01/10/26 01:53
いまだにフルスペル使いからの意見がないとおもわれ。
とういうか漏れ、ネタにつっこんでしまった!?

漏れの場わい、WIN32、Cで組むこと多いので、なんちゃんってハンガリアン。
src, destは使わず、たとえば bSetBuffer, bOrgBuffer かな。コピー元に
意味があるときは名前を書く.ex) bMessageFromHoehoe とか。

一時領域は bTmpBuffer, nTmpNum, のような感じ.
ループカウンタは ix, iy が多い.

275 :デフォルトの名無しさん:01/10/26 02:02
おれは自称フルスペレラーのはずなんだが、
今ソース見たらローカル変数は省略してた・・・。

276 :デフォルトの名無しさん:01/10/26 02:40
>ループカウンタは ix, iy が多い.
x, y の積分値みたいで気持ち悪い。
なんで i, j にしないの?

277 :デフォルトの名無しさん:01/10/26 10:31
常にフルスペルにはしないな。
forで使うイテレータなんかはよっぽど意味がある場合でない限り
i使うよ。
それで十分意味が伝わるから。

278 :274:01/10/26 12:03
>276
思いもよらなかった。やはり他人の意見は聞くもんだ。
ループがひとつのときは nCounter

ix , iy は 80系アセンブラの名残。

279 :258:01/10/26 12:12
おはよう、諸君。今日はいい天気だな。

>>259
>hWndからなんで、windowってことになるんかな。

そりゃウィンドウのハンドルだから。どうせ実体なんて見えないんだし
単にwindowでよかろうと。何かムンクある?

>>274
>いまだにフルスペル使いからの意見がないとおもわれ。
>とういうか漏れ、ネタにつっこんでしまった!?

わざわざ例外規則について書かなかっただけだ。ひつこくツッコむな。
ていうか>>270が既に答え書いてるし。
i, j, k, pなどは用途の決まったローカル変数として規約に含めとくよ。

280 :_:01/10/26 12:27
好きにしたらええがな・・・

281 :デフォルトの名無しさん:01/10/26 12:29
>>278
その書き方が良いか悪いかはおいといて、
癖の強い書き方であることはたしか。

282 : :01/10/26 12:42
イテレータにはitをつかってますが何か?

283 :デフォルトの名無しさん :01/10/26 13:04
>279
かわいそうなひとだ。

284 :デフォルトの名無しさん:01/10/26 13:17
>>283
どこがかわいそうなのか350字以上400字以内で説明せよ。

285 :デフォルトの名無しさん:01/10/26 13:19
ここが噂のハンガリアン隔離スレですか。

286 :デフォルトの名無しさん:01/10/26 16:42
ここに純粋なハンガリアン使用者はいないと思われ。
MSのサンプルコードのハンガリアンを許容するのは、
自分で使うのとは別の話。

おれは>>270とほぼ同じ、なんちゃってハンガリアン。

287 :デフォルトの名無しさん:01/10/26 18:51
>>270はハンガリアンちゃうやん。

288 :デフォルトの名無しさん:01/10/26 19:51
270 は C の命名イディオムでしょ。

OOP になると変数名よりもメソッド名が適切かどうかがより重要になるね。
合計を求めるメソッドは、
getSum getTotal sum total goukei 合計
のどれがいいか(もちろん言語やコンテキストによって異なる)。

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

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)