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

プログラム作成作業中、割と時間を食っているのが
「ソースを眺める時間」

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

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

ソースを打ちこんでる時間よりもひょとしたらﾅｶﾞｰｲかもしれない
こんな目に見えない作業時間を削るにはどうすればっ！？
を模索するスレ。

一応おいらは業務アプリ作成が主な生業。

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

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

＜言語＞：問わず
＜分野＞：変数宣言のこと

＜内容＞
接頭詞と変数名の間に「_」（半角のアンダーバー）をつける

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

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

人間、区切りは目にとまる
　↓
前半＝接頭詞、後半＝変数名と明確
　↓
あとは「この接頭詞はなんやっけな？」っと、
「この変数名はなんぞいな」くらいの悩みが残るのみ
　↓
微妙に(ﾟдﾟ)ﾗｸｰ

ソースを見ずに仕様書を見る。終わり。

接頭辞: is_, get_, set_以上

ながめている時間だって仕事のうち。
１はプロとしての自覚があるのか？
（趣味プログラマだったらゴメンよー）

とりあえずハンガリアン記法は逝ってよしってことで。
個人的にはグローバルはg_､メンバ変数はm_みたいに
スコープを名前につけるのが好きだな｡

>>6
繰り返し見てるとき、「前も同じ事考えたな」とか感じたこと無い？
１週間に１回や２回ならともかく、３回も４回も５回もそこで詰まったら
鬱になるころあれへん？
自分の作るもんではそんなことならないようにややこいの作らないのも心がけだが。

>>7
Ｃな言語で良く見かけますねぇ。おいらもﾏﾝｾｰざんす。
ところで。
話を発展させて、たとえば関数名にそれを適用したりします？

＜言語＞：C++
＜分野＞：クラスのメソッドのこと

＜内容＞：
private と protected と public に virtual まで区分けたりするか？

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

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

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

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

Borlanderなので、
・基本的に変数の区切りにアンダーバーを使わず、単語の先頭を大文字、後は小文字で記述
・型はTを頭に付加
・クラスのメンバはFを頭に付加
　ただし、公開用のものにはつけない。
・ポインタはpを頭に付加

Ｃ++で・・

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

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

クラス名：名詞
変数名：名詞
関数名：動詞＋名詞（引数があれば）

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

こんなところですな。

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

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

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

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

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

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

>>16
「見た目が汚いは」ちゃんとした意見だと思うが・・・
おれの場合、書くよりも見るほうが疲れる・・・


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

スコープにプレフィックスつけるのは賢いやり方

ほらやっぱり、Rubyは最高じゃん。おまえら（荒らし厨房君のことだよ）
何考えてんの？

なんでRubyなんだよ。おりゃDelとC++だ。アフォな条件反射レスしてないで、
ちっとはそのメリットを考察しろ。

>>20
誤爆と思われ・・・

>>21
つ〜か、狙った誤爆だがな

>>22
そうだったか・・・
逝ってきます・・・

やっぱりソースを見て機能が把握しやすいと言ったら、
オブジェクト指向が有効なのでは？

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

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

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

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

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

>>13
なにも規約なし＜＜＜＜＜＜＜＜＜＜＜＜＜＜＜ハンガリアン
です。ただいまとなってはハンガリアンも微妙にみにくい記述法ですが。

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

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

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

>>19-23
sage

>>24
関係ないとおいらは思う。
クラス名もメソッドも変数も意味を持たせた文字列で定義しないことには
なんのこっちゃｻﾊﾟｰﾘなソースがそりゃもぅ見事に出来上がるはず。
ｽﾊﾟｹﾞﾃｨもﾋﾞｸｰﾘってな感じで。
この辺でソースは作り手によって「眺める時間が違ってくる」現実が
見え隠れしてると思う（強引に話を捻じ曲げ）

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

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

ソースを書いた奴が一生メンテする。

>>29
やつも草葉の陰でそうしたかったと思っていることだろうよ。

i は iterator の i
これ定説です

スレの話題とずれてるけど、global知ってる?
http://wafu.netgate.net/tama/unix/
いまはサイトがおちてるみたい。

なんかあったら責任取るちゅーことでソースに住所氏名メアドその他を書いておく。
ソースはそのまま成果物と一緒に納品。
質のいいコードが書けそうだ（ｗ

>>25
グローバル/ローカルだけでなく
パブリック/プライベートの軸で分けて欲しい。
パブリックな物程色々な人が使うので規約を統一するのは難しい
（その規約がどんなに良くても）

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

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

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

>31
for ループのカウンタに i,j とつける慣習は
Fortran の整数型変数 I,J からきています。

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

＞C++でよさげなクラスライブラリ見つけても、
＞APIに妙なプレフィックスついてると一気に使う気が萎える
OpenGL系のライブラリとかみるとうんざりして使う気萎える？

コード補完を多用しまくってメンバ変数へのアクセス
がすべてthis->〜となってるﾄﾞｷｭがいる。(vc++の話ね。)

>>37
それはOK

>>38
ﾖﾐﾆｸｲYO!

縦に揃える。
　a1　=　 b
　a2　=　 b*2+c
　a3　=　　　　 c


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

みたいな感じ

>>37
ﾍﾀﾚだな。覚えられないような長い名前、多すぎるメンバ作る奴逝ってよし。

>>36
萎える。OpenGL使ってないけど。
Cのツールキットはプレフィックスつけるのは仕方ないと思う。
けどC++のクラスライブラリならnamespace使って欲しい。

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

>>42
>けどC++のクラスライブラリならnamespace使って欲しい。

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

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

俺はnamespace+prefixでも気にならないけどな。
それにprefixあるとコード補完の絞込みがやりやすくなるのが良いね。

>>18-19
微妙にあってる。

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

>>37
C++厨房なんですが、
メンバ変数と引数の名称をとちって被っちゃうと大変なので
this付けまくってます僕。どこか間違ってますかやはり？

>メンバ変数と引数の名称をとちって被っちゃうと大変なので
このあたりが間違ってます。

間違ってません。

間違ってます。
prefixを使えばこの問題は関係できます。

>>46
this->hogeよりもm_hogeかhoge_の方が短いし読みやすいし入力も速いだろ。
メジャーなエディタが大体コード補完備えたらそうでもないかもしれんがな。

m_なんかより
getHoge
の方が何倍も気持ち悪い書き方だ..

>>49-51
prefixで回避できるとして、m_hogeを好まない方々は
どう回避なさっているのでしょう？
このスレで言えば>>34さんとか。（指名しちゃってゴメンナサイ！）

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

thisメンバを優先的に表示するように
IDEのコード補完を修正。

真面目にコードを書いてるときは補完を全く使ってないので
sage

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

俺は classのメンバ m_*
恥ずかしいけどファイルスコープ g_*

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

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

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

intで足りなくなってlongとかになおしたらもちろん変数名はlong_Cntだね！

>>56
int count;でいいじゃん。カウンタごときに型なんぞ付けんぞ。
勿論、ハンガリアンは嫌い。:-p

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

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

スコープ指定は _でつなぐ。
他は版狩りアンでよし。

コンテナみたく、後から型を変更する可能性があるオブジェクトの名前はハンガリアンで付けたくない。
でも、コード補完機能のおかげで普段はハンガリアンの方が便利。
混在させる？ それは最悪。

ちょっとジレンマ。

スコープと型のドッチを重視するかになっちゃう様な…

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

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

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

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

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

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

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

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

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

>>60
半分銅胃

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

おいらも(ﾟдﾟ)ｼﾞﾚﾝﾏｰ

>>56
int linecnt; とか。

カウンタ用なら1関数内だし、iでなんでだめなん？
ひとつの関数が大きくて追っかけづらいなら、それを小さくするように努力させるほうが効果的じゃ？

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

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

> プレフィックスのおかげでコードの量は増えてしまうわけで、
> その分読みにくくなるともいえる。

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

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

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

ObjectPascal以外の言語はどれもソースの見た目が汚いよ

変数の型は名前にエンコードしてまで
あちこち持ち回るようなもんではない
と私は思う。

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

>>６８はＤｅｌ厨（Ｃ勉強中）なので無視しましょう

違います802は今まで各スレをRuby厨という名前で荒らしてきましたが
今度はDel厨として荒らし行為を行っているだけです。

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

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

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

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

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

プリフィックス使う奴に限って変数名が長くてウンザリ

正直、ハンガリアンはあふぉ。

正直、強硬なアンチハンガリアンにはうんざり。

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

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

sage=802だったよなあ。確か…

Delギコスレがagaってきたのも、たった今だったね...
また来たのではない？

Σ（゜д゜lll）ガーン
いつからおれ802になったんだ

http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1001039863&st=071&to=081&nofirst=true
このあたりから。

Σ（゜д゜lll）ガーン ホントダ

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

>>63
>「count」だとﾎﾝﾏにｶｳﾝﾀの型がわかれへん。
>カウンタも複数になったときに「count2」とかが増えてくことが目に見えるよう。

[count2]なんてｱﾌｫな名前は使ったことないな。付けるんなら[xxx_count]だろ。
目に見えるのはあんたが普段そんなコード書いてるからだろ。[flag]とかｸﾞﾚｰﾌﾟ
したらずらっと出たりせんだろね？

ぐれっぷて読むだろ。grepは。

じーれっぷ
いいじーれっぷ

ぐれっぷもｸﾞﾚｰﾌﾟも間違い。
正しくはｸﾞﾚﾌﾟｰ。

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

>>64
いやほら。

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

>>66
１行目は同意。関数構成からクラス構成からｲﾝﾃﾞﾝﾄやらｺﾒﾝﾄやらその他ｲﾊﾟｰｲ要素はあるよ。
だけど、それから下。
＞それは大した手間ではない。
これをなくすにはどしたらええんかいのぉっちゅうのを今模索してるのですよ。

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

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

>>68 >>70-71
sage

>>72
見易さ評価を100段階で表して、
プリフィックスなし：「５」（適当設定）
プリフィックスあり：「７」（これも適当設定）
として、
差分は２しかないから大して変わるもんじゃない！！
っと言いたそうだが、その２でも大事なのだ。
他の誰より引き継がれた人にとって。

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


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

>>74-75
sage

>>76
それもまたｱﾘかなとも思う。
統一された文化に即した形で書いてあり、それが他者にわかり良ければ
おいらはﾏﾝｾｰなので。

>>77-80
sage

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

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

>>83-85
sage

／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
|　行数圧縮しとるだけやないかｺﾞﾙｧ!!
＼
　 ￣￣￣|／￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　ΛΛ 　 ||::::::::::||　ｱﾎｶｰ
　　　　 (#ﾟДﾟ)―||::::::::::||―――
　　　　 /　　 つ二二ｌニｌ　　 　　　　＿＿＿＿＿＿＿
　　　|￣￣|__）―――ΛΛ―　　／
　　　`ー┬‐''　　　　 （　　　)　＜　　先輩。同です折れ流美しｿｰｽの見た目は
　　　　　┴　　　　　　|　　ヽ　　　＼＿＿＿＿＿＿＿
　　　　　　　　　　　　 し＿__）〜　　　
　　　　　　　　　　　

　 ∧ ∧　　／￣￣￣￣￣￣￣￣￣￣
　 (,,・д･)＜　ｯﾃﾕｰﾉｶﾞ　ｲﾁﾊﾞﾝ　ｲﾔ
　＠uu）　　＼＿＿＿＿＿＿＿＿＿＿
　　　

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

型でプレフィックスを付けるのってMS文化圏の連中だけでしょ。

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

>>1
構造体とか、オブジェクトはどうするの？typedefは？

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

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

>>90
で？

>>86
> >>64
> いやほら。
まぁこんなのはどーでもいいんだが。

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

変数名に型情報をもたせて意味があるかどうか疑問。

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


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

date.str_month
は役に立ちそうだ(09とか)
常に型が分かるような変数名をつけられるというなら、型情報付ける必要ないってのは同意。

型がわかんなきゃ読めないつーのは、
単に名前の付け方が適切じゃないという話だと思う。

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

>>95
それはdate.month.ToStringというメソッドにすべきかもね。

言語によるけど。

常に名が体を表すような名前をつけられるとは思えないんだけど。俺がヘタレだから？

普通、その場面で可能な限り高い抽象レベルで考えるべさ。
そしたら型が重要なんて場面は少ないと思う。
generic programming なんかだったら型はパラメータだぞ。

>>98
名前から型を類推できることが重要なんじゃなくて、
抽象化して、型をなるべく意識しなくてもよいように
プログラミングすべし、ってコト。

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

>>100
確かに自分で書くときにはそれを意識すべきだろうね。

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

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

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

>>102
>このスレは、>>92 で 1 の言ってるとおり、せめて型宣言のガイドラインを設定する事で、
>新人でもできる範囲の「見た目効率」を考えてみようよ。（良いの出来たら流用させてもらいたいしー）

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

＞抽象的に考えるのはぶっちゃけ、

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

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

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

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

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

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

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

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

＞data って変数名だけはつけんじゃねぇ（笑

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

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

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

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

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

そういえば、昔SP-5030(BASIC)で書いてた頃は、
変数って２文字までしか認識してくれなかったんだよね。
英小文字もなかったから、変数名がA〜ZZ、A0〜Z9に限定されてたんだ。
それで消防の頃、ﾍﾞｰﾏｶﾞのリスト入力してﾃﾞﾊﾞｯｸﾞ（打ち間違い探し）してたんだから、
こんなの贅沢な悩みかもしれないねえ…

ちょこっと思った今の流れとは違うこと。

　　物事を否定することは簡単だ
　　「イヤ」というか「そんなんﾜｶﾗﾝ」というだけですむ。
　
　　「今できてないことをどないしたらできるかな〜」
　　を模索しようとしているところへ、
　　「今も昔もできてないし、やったことないからワカラン」
　　っなこと言われつづけても話の発展にはﾅｰﾝﾓつながらﾅｰｲ。
　
　　 ￣￣|／￣￣￣￣￣￣￣￣￣￣￣￣￣
　∧∧
　( ﾟДﾟ)
　| っ日~~　　 ｲﾏﾉﾎｳﾎｳﾆ　ｺｼﾂｼﾀｹﾘｬ
　と_）_）　　　　　ｼｶﾞﾐﾂｲﾃﾅｻｲ
　￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣　

>>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」よりも区別つけやすいとオモタ。

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

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

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

>>96
それを考え方も感性も違う他人様と同期取るのが
どれほど大変か〜を思えば･･･････

>>97
ワケワカラン

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

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

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

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

>>103
φ(..)

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

>>105
後半の話。個人的には賛成できる姿勢です。

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

>>107
（ｗ

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

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

　　ﾏﾀｰﾘ独言
　
　　接頭詞の話はいつも「やりたくない」という意見がでてくるもんだ。
　　けど、そんなもんつけるくらいにどんだけ労力をさくのよ？
　　っと問いたい。
　　もし。
　　さいてしまうと言うならば。
　　きみにはこんな言葉をあげよう。
　
　　 ￣￣|／￣￣￣￣￣￣￣￣￣￣￣￣￣
　∧∧
　( ﾟДﾟ)
　| っ日~~　　ｼﾀｦ　ﾐﾚ
　と_）_）　　　　
　￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　↓
.＿＿＿＿＿＿＿＿＿＿＿＿＿
|　　　　　　　　　　　　　　　　　　 .|
|　　ﾍﾀﾚに主張する権利無し 　｜
|＿＿＿＿＿＿＿＿＿＿＿＿＿|
　　 ∧,,∧　||
⊂ミ.,,ﾟДﾟ彡つ ｺﾞﾙｧ


　　明らかなる欠点。
　　業務側からみたときや、実作業中での明確な不利な点が
　　なければ接頭詞はつけて〜っと叫ぶ事をやめない。
　　あるのとないのではまず「とりかかろう」と思う
　　意志の度合いがかわるから。
　
　　 ￣￣|／￣￣￣￣￣￣￣￣￣￣￣￣￣
　∧∧
　( ﾟДﾟ)
　| っ日~~　　ｼｮｳｶﾞｲ ﾒﾝﾃﾅﾝｽ ﾀﾝﾄｳ
　と_）_）　　　　　ﾄｶﾆﾅﾙﾄ　ﾁｶﾞｳﾘﾕｳﾓ ﾂｸｶﾓ
　￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣　

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

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

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

ちょっと聞きたいんだけど、接頭詞つけるﾔｼは、setter,getterにもつけんの？
class hoge{
public:
int get_int_hage() const;
void set_int_hage( int new_value );
};
とかさ。

>>120 つけないよ。
つけるとしても
　int　getHageInt();
　void setHageInt(int iValue);

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

int_start
chr_flag

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

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

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

変数名の重複を防ぐ、変数の型を識別する、変数名を規格化する
の３点。

>>124
2,3の事例でいいので、具体的にお願いします。
たとえば、こういう種類のバグを防げたとか。
こういうツールを使うのに、便利だとか。

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

数学的な意味で名前空間の正規化とか、機能の正規化という言葉も
聞いたことがあるかもしれない。
こんなことは高度なシステム設計者が考えることなんだが。

＞このように名前を管理する方法を「名前空間」と呼ぶんだけどね。

ホントカヨッ

xPos, yPos
こういう変数名使っていて、
「名前空間で識別子を管理してる」
なんて言ってるやつを初めて見た。

なんか、抽象的な話ばっかりで、具体的な話はちっとも出てこないなぁ。

>>125

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

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

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

>>94
文字列こそ型情報を変数名に埋め込むことが必須だと思うが。世の中が一つの文字列型で
統一されているならともかく、現状だと

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

と混在してるからねぇ（うんざり）。

だからそういう抽象レベルで考えてちゃいかんよきみぃ。

>>130

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

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

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

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

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

　----(例４)--------------------------------------------------------------
　　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):読み込むデータ量に対して、受け皿の領域は足りているか？

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

(2)を検証する作業：[※3]
　例１＆２･･････　NULLと判定してるな。こんなもんだろ
　例３･･････････　rtn　ってなにもんじゃ？
　　　　　　　　　　　　　→　charのポインタ型か。
　　　　　　　　　　　　　　　確かにfgetsの戻り値はあってるな。
　例４･･････････　chrp_Rtn　はきっとcharポインタだな。
　　　　　　　　　　　　　→　確かにcharポインタじゃの。

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

(4)を検証する作業：
　例１＆３･･････　buff　は〜charで容量が･･･フムフム
　例２＆４･･････　chr_Buff　の配列はなんぼやねん。･･･フムフム

このほかにも、
　例１＆３･･････　99は〜エラーやんな。適当でええのか？
　例２＆４･･････　「DefRTN_NoFileData」ってなんじゃ〜い！
　　　　　　　　　でもきっとreturnでの返り値ならdefineやんな。
　　　　　　　　　　　　　→たしかにそうだ。[※5]

これは>>135の自己注釈

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

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

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

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

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

　　暇にあかせて具体例を作ってみました。>>134-136
　　おいらの私見なのでつっこみ大歓迎にござる。
　
　　っちゅうところで帰るでござる。
　
　　 ￣￣|／￣￣￣￣￣￣￣￣￣￣￣￣￣
　∧∧ 　　　ﾏﾀｰﾘ
　( ﾟДﾟ)
　| っ日~~　　ｵﾊﾅｼｽﾙﾆﾊ
　と_）_）　　　　ﾀﾀｷﾀﾞｲ ･･････ｶﾉｫ
　￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣

>>134
(例３)と(例４)は一時変数を使うかどうかということに絡んで来るので、話が
違うだろう。あえて韜晦しようとしてるなら別だが。

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

>>137
俺の場合buffとあったらローカル変数でchar型の配列だって思うけどなぁ。
iやjをみたらローカル変数でint型だと思うのと同じ。
そういう意味で変数名に型情報が埋め込まれているとみなしてる。

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

>>138
例１＆２と例３＆４の違いは「ソースの見た目」
万人が全部例１＆２なわきゃありますめぇ。

そんで
　 ∧ ∧　　／￣￣￣￣￣￣￣￣￣￣
　 (,,・д･)＜　師ｶﾞCOBOL文化ｦ継承ｼﾃﾀﾃﾞﾁ
　＠uu）　　＼＿＿＿＿＿＿＿＿＿＿


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

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

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

>>140
プログラミング言語には、それぞれ固有のイディオムというか常套句が存在する。

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

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

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

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

他人の書いたソースだと、変数名に型名が入ってても、それは信用しないな。
必ず定義部を探すよ。

まず最初に ctag 作るね。

>>143がトドメをさした

汎用機で動くCtag(CはCOBOLのC)を作ってください。

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

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

正直、>>1のソースは絶対に読みたくないと思ったのは俺だけか。

>>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 が何のポインタなのか、
どれだけの大きさを持っているかが明示されてる分、デバグには有利と思うぞ。
（文字列のバッファとかオチる原因となりやすいので）

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

>>135-136
read,AFpp_GetRead ←こういう変数を見て思いましたが、
変数、関数に適切な名前を付けるとか、そういう事を
しっかりやってますか？

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

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

>>141
言いたいことはわかる。
そしてそれには同意する。

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

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

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

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

>>143-145 & >>147
sage

>>146
たたき台の例が(ﾟдﾟ)ﾏｽﾞｰなのは了解した。

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

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

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

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

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

そこで。次に話題にしようと思っていること。

　|￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣|
　|　関数分割はどんなところで行うの？　|
　|＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿|
　　　 ∧∧　||
　　　 (,,ﾟДﾟ)|| 　ｶﾀﾚﾙﾉｶ?
　　　 /　 づ||O
　 ＠（＿__ﾉ　

方法論として。
まず２つ（またーしても叩き台）

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

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

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

　　 ∧ ∧　　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　 ﾐ,,･Д･ﾐ ＜　 (1)と(2)どっちがどぅだと思うよ？
ξﾐ ,,ｕ且ﾐ　 ＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿


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

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

>>152
> 　(2) 処理の流れを構成するだけの部品、実処理を行う箇所を特化した部品を組み合わせる
すまんがこれ日本語がよく分からん。

激しく分かりづらいので、お題を出してみたりする。

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

data.csv
123,10,100

% ./sample
% 233

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

変数のプレフィックスの利点はよく分かった。
じゃあなんで関数も修飾をしないんだい？

関数と分かりやすくするために関数の最初に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 *);
などだ。

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

OOPLだと組み込み型以外のオブジェクトを使うことのほうが多い。
「プレフィックス」はすぐに破綻する。

>>156
ネタにマジレス。
OOPLだと異なった型のオブジェクトを返すメソッドもある。
故に破綻する。

>>155
まずは仕様をまとめてみようか。

１．項目数３この数値からなる
２．CSV
３．ファイルを読み込み、
４．その合計値を
５．標準出力に出す

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

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

>>154
処理には手順があるやんね。
手順の順番を流れと言うもんという前提をおいて。

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

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

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

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

>>160 の説明用ソース　>>155と若干似てる(!?)

int FncInt_Change_CSVtoOtherFile()
{
　　int　　　　int_Rtn ;　　　　　　// 戻り値取得用
　　*****　　　obj_DataArea ; 　　　// データ取得用の領域と思いねぇ（初期化や解放にはつっこむナ）
　
　　/* -------------------------------- */
　　/* [1].ＣＳＶファイル読み込む　　　 */
　　/* -------------------------------- */
　　int_Rtn = FncInt_ＣＳＶファイル読み込む( &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 ) ;

}

前もって逝っとくこと。
・接頭詞問題が主ではないので、命名は気にしないように。
　　（全角文字はつかえんぞ(ﾟДﾟ)ｺﾞﾙｧ!!とか）
・実際に必要だけどあえてはしょったところとかあるのでつっこまないように。
　　（ファイル名はどこでわかるんだ(ﾟДﾟ)ｵﾙｧ!!とか）
・実行速度とか実務での要求によってはおいらもこんな形で書かないこともあるので、
　あえて指摘したりしないように。
　　（そんなん何時如何なる時もいちいちしてられるか(ﾟДﾟ)ﾎﾞｹｪ!!とか）
　　（メモリなんぼ必要かわかれへんのに全部読み込むんか(ﾟДﾟ)ｱﾌｫ!!とか）

￣￣￣∨￣￣￣￣￣
　　　∧ ∧ 　　　ﾏﾀｰﾘ
　　　(,, ﾟДﾟ)∫
　　　/　 つ旦O
　〜(._［￣￣￣.］

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

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

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


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

　　 ￣￣|／￣￣￣￣￣￣￣￣￣￣￣￣￣
　∧∧
　( ﾟДﾟ)
　| っ日~~　　 ﾅﾝｷﾞ　ﾅﾉﾊ　ﾜｶﾙｶﾞﾉｫ
　と_）_）　　　
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣　

>161 せっかくソースの縦列それ得れるだけそろえようとしたのに
できんかった。。。鬱打氏脳。。。

例外処理って・・
らくちんだよね・・・

>>160
(1)ボトムアップで分けるか(2)トップダウンで分けるか、つーこと?

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

>>147
俺は、彼の日本語を読むのが辛い。。。

>>161-162
まともなC使いはそんな無駄な記述はしない。
書き込みもソースも冗長に過ぎる。

ageてみるか

>>164
ど、どこからそれが？(脈絡がわからなくてどぎまぎ）

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

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

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

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

マクロと定数以外、全部小文字。
区切りは_

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

>>168
ありがたう。でもﾖﾊﾟﾗ-ｲなので寝。

>>169
これは頭悪いだろ…
DefRTN_True
DefRTN_False

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

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

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

>>162
>　（※ＶＢ文化での「戻り値のある関数」は「Function」っというのに以来してる）
>　（※余談だが、「戻り値のない関数」は「Sub」なので「Sub_」にしてる）

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

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

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

>>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が語りたいのはこういうこと？

それから>>161のコードは冗長すぎると思う。
藤原某の某診断室を思い出したよ。
はっきり言えば、読む気がしない。

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

>>174
それを言うならプロシージャとファンクションという気もするが・・・

>>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'
とコマンドラインから入力すると思いますが）。

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

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

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

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

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

s/>>159と>>179/>>159と>>175/

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

>>179
アーキテクチャって何ですか？

おふぁようage（あばば）

ageないで欲しいｽﾞﾗ……。

>>183
辞書を索け

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

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

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

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

>>172
頭の(・∀・)ｲｲ！ 悪いはどっかにおいといて・・・(;´д｀)ﾊｧﾊｧ

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

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

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

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

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

　　　・英字をみなれてない。

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

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

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

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

>>174
うぃ。気をつけまふ。

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

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

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

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

　　ElementVector elements = getElementsFromCSVFile(file);

　　Sum sum = getSum(elements);

　　putSumToSystemOut(sum);

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

>>176
極端なものに否定がつけば、きっとその手前で答えが見つかると思う。

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

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

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

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

>>178
単語と用語の用い方は各人が吸収＆意図を組むっちゅうほうこうで・・・（＾＾；

（・・・・・・限度はあるにしろ・・・>>特に1・・・Σ（ﾟдﾟlll)ｶﾞｰﾝ ）

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

そして。

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

その上で。

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

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

　|￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣|
　|　ﾌﾟﾛｸﾞﾗﾏならｿｰｽで語ろう　　　　　　　 |
　|＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿|
　　　 ∧∧　||
　　　 (,,ﾟДﾟ)||
　　　 /　 づ||O 　　ｯﾃｪｰﾉｦ　ﾒｲﾝﾆ
　 ＠（＿__ﾉ

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

>>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はレベル５：通信的凝集（あるデータを処理するまとまり。１関数複数機能）
175はレベル７：機能的凝集（１関数１機能の状態）
という違いがあります（僕の判断では）。

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

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

まぁいろいろ考えるけどひとまず一点だけ。

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

>>190
>ただ余白を設ける。

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

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

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

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

ちょい追加説明。

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

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

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

>>193
>凝集度のページ
お、こりゃあいい事を知った。ありがとう。

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

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

意見がまとまってないが
忙しいのでとりあえず半端にサラバ

ただいまプロジェクト中のすべてのクラスの頭に
　DCCN　をつけることを強制されております。
さらにその下に２文字の「モジュール識別子」なるものが
つけさせられてしまったりもしています。

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

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

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

DQNかとおもた

　　 ∧ ∧　　／￣￣￣￣￣￣￣￣￣￣
　 ﾐ,,･Д･ﾐ ＜　 昨日の昼かきこまれへんことなかった？
ξﾐ ,,ｕ且ﾐ　 ＼＿＿＿＿＿＿＿＿＿＿

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

　＜細かいところで＞
んでその分割のところで。
>>>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）

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

>>197
＞main関数自体の凝集度を低める点
Lv1までやってまう？（ｗ

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

　　 ￣￣|／￣￣￣￣￣￣￣￣￣￣￣￣￣
　∧∧
　( ﾟДﾟ) 　
　| っ日~~　　ｽﾞｽﾞｯ...
　と_）_）　　
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣

>>199 は〜ご愁傷様です。（−人−）ﾅﾑﾅﾑ

そんな接頭詞はおいらもいやです。Σ（ﾟдﾟlll)ｶﾞｰﾝ

余白の話。
間延びの話はよ〜わかる。
わしも間延びｿｰｽはいやんってな感性もってたから。
でもね。
戦闘モードでないときにね。
ごちゃっとしたの見たくないの。

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

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

そんな視点を持ってから、戦闘モードでも
「いちいち細々追うのだるいぞ！　もっときっちりまとめとかんかぃ！！」
っと思うようになってもた。
ｴﾃﾞｨﾀでせめて色分けできればその限りじゃないんだけどね。（←これも言語特性か。）

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

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

￣￣￣∨￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　∧ ∧ 　　　ﾏﾀｰﾘ
　　　(,, ﾟДﾟ)∫ 　　　閑話休題
　　　/　 つ旦O
　〜(._［￣￣￣.］

>>202
159はmainじゃなくてgetElementsFromCSVFileの再利用を考えているのでは？
ただ単に凝集度を高めたいだけなのかもしれんが。

>>199
少なくとも DCCNXX はクラス名ではなく namespace で対処するべきだよなぁ。

namespace を知らないに 1 Stroustoup

namespaceというものを後から知ったがリーダーが頑固すぎた
に 3 Wirth

上から押し付けられてどーしようもない。
に ４ DQN

namespace を知らないに 1 Stroustoup

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

つーかStroustoupってなに

>>210
Stroustrup のスペルミスと思われ。

この本、面白いよ．

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

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

どうでもいいが、なんでこうアンチハンガリーが多いんだ・・・？

age

アンチというか、効果がないからだろ

つーかさ、診断室も知らんかったのか？ > 1
プログラミング作法とかフツー読んでるもの読んでからやってくれ、ＤＱＮな
議論が続くのは見るに耐えん。

age忘れた。

だからageないでくれえ。

>>213
ハンガリー信者ウザイ
変数名にまで変な名前付けるなよ(w

ハンガリアンって多態した時点で破綻しないか？

オブジェクト指向とはびみょーにマッチしない、と俺は思う。

>>220
抽象化してもダメだろ。

>>220
そういう時はとりあえずオブジェクトを表す O を頭につければ大丈夫。

それはんがりアン意味ないヨ！

>>220-224
激しく外出。

他人のソースのメンテで変数にハンガリアン使われてるとムカツク
殴りたくなってくる。

じゃあなんでハンガリアン信者は
いまだに激しく抵抗してんだ？

Python/Ruby使いでハンガリアンって居そうな気がする。
漏れC++/Javaではアンティ・ハンガリアンだけど、
ruby書いてると変数の型を気にして自分を見失いそうになる。

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

Ruby に関して言えばスコープ用の $ @ @@ で足りてる
第一変数に型ないし

$ @ @@
ﾀﾞｻﾀﾞｻ

最初はそう思うけど意外と悪くないよ。
記号ゆえに目に付きやすくて判別が容易。
さらに、記号を減らしたくなるから余計な変数を使わなくなる（ｗ

>>230
例えばEnumerable配合の型を入れる変数に、
識別子使いたくなんないｽか？
漏れは複数形を使ったりして区別してるんだけど、今一。

>>233
複数形でいいんじゃないの？
自分の書いたコードをざっと見てみたらそうしてた。

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

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

>>219
>>227
ハンガリアンでなくても、自分が各ソースの変数名って自分がわかりやすいように
つけるよね？で自分の中である程度の規則はできるよね？

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

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

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

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

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

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

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

agetesimae

ageるなバカ

MSの開発者サポートの核は豊富なサンプルコードだし、
それを読むにあたってはハンガリアンは非常に役に立ってる。
誰が書いても見た目が似たソースコードになってるから。
自分で書く分には守っていないが。

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

>>240
ようするに入門書のコメントのようなものということか?

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

>>241
要するな。しかも的を外してるし。

(ﾟдﾟ)＜将を射んとすればまず馬を射よ

釣れました。

サンプルコード用ってことだろ。

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

MSはハンガリアン捨てるっていってるけど……
MSにいたスーパープログラマーがハンガリアンを推し進めてたって聞いた。
いまはカトラーとかヘジとかが主導権握ったから変わったんじゃないの？
カトラーってもういないっけ？

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

ハンガリアンの語源って何なの？

>>248
自分の読解力の心配が先じゃないの？

>>249
最初に始めた奴がハンガリー系だったから。
かなり失礼な話のような気もするが。

「実録 天才プログラマ」(ASCII刊)に、そのハンガリー系のプログラマへの
インタビューが載ってるよ。マイクロソフトに転職したあと、自分の使って
いたその方式が社内に広まったと言っている。

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

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

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

>>254
>画面が文字でビッシ リで拒否感
改行すればいい。
なんなら１行おきにソース書け

ん？バリバリ記号的に略したソースなぞそれこそ見たくないな。
タッチタイプする時や読む時に素直に読めない。
少ない規約で自然に理解できるソースが理想。

>256
略すための共通ルールが欲しいってことでそ。

>TextField responseMessageText
>ServerSocket listenSocket

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

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

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

>>258
hWndからなんで、windowってことになるんかな。
せつめいして。

>>254
それは英語がわからない人が見たらそうかもしれないけど、
英語がわかる人から見たら、わかりやすいのでは？

>>258
>TextField responseMessageText
>ServerSocket listenSocket
JAVAを知らなかったら何が何を意味してるのか、
文法的にさっぱり想像もつかん。

>>261
それは hWnd に言うことだろ、っていう突っ込みきぼんなのか？

>>261
JAVAを知らない奴だったら、どう書こうがさっぱり想像もつかんだろ･･･

言語固有で命名規約持つならそれで問題ないだろ。
全ての言語に通用する規約なんかあるわけないんだし。
つーことで、C基準の話でいいと思われ。

俺はメンバ変数はフルスペル。
ローカル変数は簡略化するけどな。

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

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

>>265
これ、同意。

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

>267
ただし、>265の src, destはやだ。

>>268
src, dest って、むちゃくちゃありふれてるやん。
ループカウンタの i と同じくらい。

>>269
個人的には dst の方が好みかな。

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

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

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

プログラマなら、イテレータは it だろうが！

>>271
整数イテレータ:i,j,k...
STLのイテレータ:it(足りなくなったらitの後に識別子を追加)
ってやってる

俺は引数をargにするってのが一番多い。

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

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

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

おれは自称フルスペレラーのはずなんだが、
今ソース見たらローカル変数は省略してた・・・。

＞ループカウンタは ix, iy が多い．
x, y の積分値みたいで気持ち悪い。
なんで i, j にしないの？

常にフルスペルにはしないな。
forで使うイテレータなんかはよっぽど意味がある場合でない限り
i使うよ。
それで十分意味が伝わるから。

>276
思いもよらなかった。やはり他人の意見は聞くもんだ。
ループがひとつのときは nCounter

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

おはよう、諸君。今日はいい天気だな。

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

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

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

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

好きにしたらええがな・・・

>>278
その書き方が良いか悪いかはおいといて、
癖の強い書き方であることはたしか。

イテレータにはitをつかってますが何か？

>279
かわいそうなひとだ。

>>283
どこがかわいそうなのか350字以上400字以内で説明せよ。

ここが噂のハンガリアン隔離スレですか。

ここに純粋なハンガリアン使用者はいないと思われ。
MSのサンプルコードのハンガリアンを許容するのは、
自分で使うのとは別の話。

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

>>270はハンガリアンちゃうやん。

270 は C の命名イディオムでしょ。

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

さがりすぎage

まず名詞と動詞って区切りで分類すべきだと思うわけよ。
で、固有名詞が大文字で始まるのは自然だと思うわけよ。

>>290
固有名詞ってなんだ？
定数？グローバル変数？クラス変数？

ところで名詞を全部キャピタライズする奴イヤン。
ドイツ人かっつーの

>>288
名前が重要なのは OO に限らないと思う。

うまい人間が書いたコードは、関数の詳細を追わなくてもざっと関数名を追っただけで
処理の流れが分かる。

>292
このスレの主旨としてはうまくない人間に読みやすいコードを吐かせる方法を出すべきだと思うがどうか。

>>287
自分で使っていて、>>270はなんちゃってハンガリアン
（ハンガリアンではない）だな〜と思ってたけど、
他人からはそうは見えない？
ハンガリアンから使う気の無い物を削ぎ落としていくと
こんな感じになるのだけど。

>>294
270 に書いたのは、プリフィクスではなくて変数名そのもの。たとえば i は一文字変数。

ハンガリアンと言うと

TCHAR[] -> szName
POINT -> ptPlayerSprite
HANDE -> hBitmap

などのプリフィクスを指すと思われ。

私はハンガリアンも、ちょっと使ってます。特に文字列 (char[], TCHAR[], BSTR[]) と対応するポイン
タ、それから文字列クラスは変数名で区別できるようにしてます。hDC, hBitmap, hFont あたりはハン
ガリアンなのか、用途の決まったローカル変数なのかは微妙なトコロでしょうか。

>>293
逆説的だが、先週レビューしたコードでダメダメだと思ったものをいくつか。

CheckValue()
　何をチェックするのか、どうチェックするのか分からん。結局は URL として正当な文字列かどうかを
　チェックしていたんだが、それなら IsValidUrl() とかにして欲しかった。

GetData()
　これは ASP のコードで使ってたんだが、ユーザが Form で入力したデータを受け取るのに使ってた。

value, data
　何の値が入ってるのか謎の変数。場所によっていろいろ、ループ中で使いまわしていたりして用途は
　特定できず。（最終的に、用途別に変数を分割して書き直した）

汎用的過ぎる変数名、関数名を使わんのが基本か。適切な名前が思い浮かばなかったら、それは変
数、関数の用途が漠然としすぎている兆候として考え直す、と。

>>294
>>270はハンガリアンというか、省略名だろ
あれはprefixじゃなくてそのまま使うのでは？

なるほど、>>270を見てハンガリアンのプリフィックスだと思ったわけか。
ちょっと重症やな。

ちなみにSunのコーディング規約はこうなってた。
>Common names for temporary variables are i, j, k, m, and n for integers; c, d, and e for characters.

Ｃよりはこういうのは少なくて済むか。

>>299
dはdoubleを連想させるね。
Javaってdoubleは無いのか？

>なるほど、>>270を見てハンガリアンのプリフィックスだと思ったわけか。
>ちょっと重症やな。
ぴんぽん。鬱氏。

>汎用的過ぎる変数名、関数名を使わんのが基本か。適切な名前が思い浮かばなかったら、それは変
>数、関数の用途が漠然としすぎている兆候として考え直す、と。

全くその通りだけど、ローカル変数名や、自明な関数の引数名は
見逃してくれヨ。dat,val,str…

>>302
いや、私は見逃しますけど。

スコープの広さと名前の詳細度は反比例、と思ってます。グローバルな変数やメンバ関数は詳しく、
ローカルな一時変数はイディオム的な名前でシンプルに、とね。

プログラムの初心者でなく、言語の初心者に
「この言語はこんな風に処理をかくんだよ〜」っと
見せることのできるソースを書くってぇ試みはどぅだろう。

同じことやるソースなのにやたら見難いとか見やすいとかの差は
どこからくるんだろうとふと疑問が沸いた。

変数age

翻訳サイトを知って以来、私の関数名はどんどん英文化しています。
結局そのほうがわかりやすい。

>>306
>翻訳サイトを知って以来、私の関数名はどんどん英文化しています。
その手がありましたね。
その翻訳サイトってどこですか？

結局、美しいコードを書くためにも英語は勉強しろということか。

>>306
おれも。そのかわりどんどん変数名が長くなっていった。

すいません、たまにtmpとか使っちゃいます。
流石にローカル以外で使う度胸はないですが。

ZPerspectiveProjectionMatrix()とか平気で作るナリよ。

グローバルにtmpって変数があったら怖いぞ。
310は使いたいと思ったことが有るのか？

HTMLから、タグを除去してテキスト部分だけを抜き出す関数を
作ろうと思うのですが、どんな関数名にすればわかりやすいですか？

>>313
lynx()

>>313
HtmlToText()は？

>>315
関数名は先頭を動詞にしたくならない？
ConvertHtmlToText()のように。適当に略すけど。

>>313
RemoveHtmlTag() とか？

html2txt

>>313
eliminate_html_tags @ c
eliminateHtmlTags @ Java

char* remove_markup()

gat

HtmlDocument::asString()

>>322
（・∀・）イイ！

>>323
そうか？
激しく勘違いされそうだが。

322は違うだろ。
>テキスト部分だけを抜き出す関数を
~~~~~

メソッドだったら、
xxxHTMLDoc::GetPlaneText()
かなぁ

void Foo::ExtractText(string& text) const;

>>326
XML の DOM でいうところの Text って感じだな。

いきなり名スレになりましたな。

>>307
翻訳サイトなんて検索すりゃすぐ見つかるよ。
私は、有名どころのExcite。
和英翻訳はまあよさげ。英和はキビシイ。

>>307
Exiciteとgooの辞典でほとんど事足りるが、
このサイトが便利

翻訳のためのインターネットリソース
http://www.kotoba.ne.jp/

英辞郎（http://member.nifty.ne.jp/eijiro/）は
有志がポコポコと単語追加しまくってるだけあって、
マイナーな技術用語やスラングまで大量に入ってて便利です。

>>マイナーな技術用語やスラングまで大量に入ってて便利です。

そんな識別子満載のソースコードって見てみたいかも。
読みたくはないが（藁

単語変換しかできないけど、英辞郎使ってるんでココとか使ってる。
http://www.alc.co.jp/
重いのが難点だけどね。

iterator が３つぐらい欲しいときってどんな変数名をつけるのが良いんでしょう？
私は
　list<int>::iterator it;
　list<int>::iterator jt;
　list<int>::iterator kt;
とかやってるんですけど、なんか変ですよね。

it1
it2
it3

数字は適当に意味のあるのにしてくれ。

i,j,kにしてるYO

>>336
ぱっと見た目カウンタか！？っと思われると思われ。

>>337
ループに使うiteratorなら、intで回すのと意義が変わらんので
名前も一緒ってことで。
といっても整数ループカウンタと混在するときはまぎらわしいけど、
まぎらわしくなりそうなときは、少なくとも外側のループカウンタから
意味のある名前をつけてるよ。

>>338
名前間違えた。335じゃなてく336

漏れは itr
たくさんあるときは
itrAbc か itr_abc

list<list<int>::iterator>::iterator intitit;

とやったことがあるが、なにか？

intitit age!

単体でループをまわすとき it
複数を使用するとき、objprefix_iter
こんな感じかなぁ

いてれーたはもういいage

ふむ、ふむ。

大文字小文字が混在するシンボル名を見ると
激しく萎えるのだが、時代についていけなくなってるのだらうか。

うん。

上げ

>>346
_区切り派?

つーか、ソースつらつらながめて参考にするとしたら何すすめる?

えーと、GPLのやつとか、自由にソースげっとできるやつね。

>349
m_pMainWnd
は、どの派閥に属するのですか？

>>351
うーんと、大文字小文字混在、ハンガリアンでスコーププリフィックス派?

>>351
参考までに開発環境教えて。

C++で
operator + (
operator +(
operator+ (
operator+(
どの書き方にしてる？
+がintとかに変わった時は？

>>354
operator + (
だね、+ が埋もれると見難い気がする。

自分ではやってないけど、
#define AddOperator +
みたいにして
operator AddOperator (
っていうのもいいかもって今思った。

>>355
やったら死刑

>>354
> operator +(
カッコの外側には空白を置かない。これ最強。
そんかわり顔文字と間違えられるという危険も伴う。

>>357
やってみたんだけどoperator =( が顔文字に見えるね。

>+(
漫画的にへこたれてるサイクロプス？

すいません、とりあえずこんなところでしょうか？
c(C99)/c++/javaで、...
変数編
ブレス内の超ローカル変数：何もつけない、好きなようにつけよ。
長さに気を使え。
メソッド／関数内の変数：何もつけない、好きなようにつけよ。
長さに気を使え。
場合によってはスコープが関数内であることを示す文字列
接頭辞をつけよ。
クラスメンバ変数：何もつけない、好きなようにつけよ。
長さに気を使え。
場合によってはメンバであることを示す文字列をつけよ。

あとは？
間違っていたらご指摘お願いします。

>>360
読んでみたのだが、何も決まっていないように思うのだが(w

コンストラクタと初期化リストの間のコロンはスペース空ける？
スコープ解決演算子（って言うのか？）の後ろは？

ちなみに俺はこんなかんじ、スペース空けてない
Hoge::Hoge( void):A( 0)
{

どっちかっつーと(の後のスペースが激しく気になる

うむ、奴はどう書こうか毎回悩むが
いろいろやってたら俺はこんなかんじになってしまったぞ。

Foo::Foo():
　　m_Hoge("Hoge"),
　　m_Hoge(1)
{
　　// ｺﾝｽﾄﾗｸｰﾀ

うオウ、m_Hogeが２つあるんか？鬱だ。

>>364
初期化指定が増えてくるとどうせ一行には収まらんし、
そんなとこだろうな。

elseとかcatchって

} else {

と

}
else {

のどっちがいいのか悩む。

diffとの相性を考えると別の行の方がよさそうだけども。

} else
{
はさすがにいないだろうが
}
else
{
もいるんじゃないの？

漏れは大体

}else{

慣れってのがおおきいけど、elseはifブロックの終わりに連なるからブロック
の終端の } となるべくくっつけたい。
感覚としてはdo{...}while()に近いかな。
でも特にメリットは無い。

そういえば条件分岐につけるコメントってどこに書く？
漏れは大抵

if(...){ //もし...ならば

}else{　　// それ以外

}

ってかんじだけど、時々ブロック内に判定文の説明書いてることに抵抗を
感じることがある。どうでもいっちゃどうでもいいことだが。

場合によっては
if (...)
{
}
else
{
}
にしてるよ
というのもこういうことし易そうだから
#ifdef DEBUG
#define DBGIF(a) a
#else
#define DBGIF(a) /* a */
#endif
//どっちでもいいんだけどさ↑

DBGIF(if (...) )
{
}
DBGIF(else)
{
}

>>370
そのDBGIFマクロはどうかと思うな。

>>371
マクロ自体はともかく、>>370の使い方はどうかと思う。
それに、なぜそれがこうするほうがよいという理由になるのか分からん。

if (...)
{
}
else
{
}

そう漏れが言いたいのもそういうこと。
そのマクロの用法は、どういうときに役に立つのか聞きたい。

>372
K&Rだから。

>>374
だから、なんでマクロが理由になるかわからんつってるんらろ。

俺は

/* もし...ならば */
if (...) {
}
/* それ以外 */
else {
}

だな。ifの条件部が長くなって一行におさまらなそうだと:

/* もし...ならば */
if (...,
　　...,
　　...)
{
}
/* それ以外 */
else {
}

ってやる。

>>374
理由になってない

経験的に
DBGIF(if (...) )
{
}
を必要とする頻度は
組込み系かそうでないか、
ＯＯＰじゃないかそうでないかでも
違ってくるとおもう。
ハードコーディングしてる場合は必要なんだと思う。
DBGIFじゃなくてVER01とかバージョンで名前きめてさ。
またエラーログまでエビデンスとして提出しなければ
ならないところでは、作業簡略化のために使うことがある。

まったく関係ないと思う。
デバッグ時は条件次第で飛ばすようなコードって何?

漏れの場合if文は
　　// if文じゃ(ﾟДﾟ)ｺﾞﾙｧ!!
　　if(...)
　　{
　　　　// まっとうな道
　　　　hoge();
　　}
　　else
　　{
　　　　// 人生裏街道
　　　　hogehoge();
　　}
のほうがカッコが上下でそろってて(･∀･)ｲｲ!と思うが。
>>370のマクロはどぅかと思う。
バージョンやハード対応はもっと単純な方法で見やすく区切れるし。ソース行数は増えるｶﾞﾅｰ。

漏れはこのパターンです

if(.....) {
flg=-1
}
else {
flg=0
}

書籍関係ではこのパターンが多いことから、このパターンを使ってます。
後は、周りの先輩達がこのパターンを使っていたのでそれに合わせて
書いていたので、今の形になりました。
なので、それほどフォーマットにはこだわっておらず、しいていうなら
ゴチャゴチャしない様にはしています。

個人的に今まで色々な人のコード見てきましたが、見やすいコードを書く
人は理路整然とした無駄のないコードを書いていてコメントも少ない
印象を持っております。

コメントがあるとわかりやすいとはいうけどね
わかりづらいコードにはコメントが必要になる
ともいうしね

ifの後のかっこの周りのスペースも個性が出そう。

条件を複数行にするときに && や || をどっちの行に
入れるかというのも。

if(...) {
//a
}　←
else if(...) {
//c
}　←
else {
//b
}

私はこのパターン。「}」だけの行があることで各ブロックの切れ目が
見やすく、かつ、行数もわりとコンパクトで見通しが聞き易いって感じで使ってます。

if(..){
　　func1();
}else
if(..){
　　func2();
}

>>385
エディタによってはこんな風にされちゃわない?

if (..) {
　　func1();
} else
　　if (..) {
　　　　func2();
　　}

>386
なるね。
オープンソースなコードに使われてて、
読みやすかったから転載してみただけなんだけどね。

>>385
２つめのifが評価されない可能性があるifだってのが、
パッと見、分かり難くいかも。

ageてみちゃったりしてﾄﾞｷﾄﾞｷ
テンポラリ変数はtempですか、tmpですか。

http://music.2ch.net/test/read.cgi/beatles/1003793185/l73

基本的にtemp使うけど、他の変数と長さを合わせたいときはtmpも使うかな。

//******************************
//
//******************************

//------------------------------
//
//------------------------------

//----< >

//コメント

//yyyy.mm.dd何か一言

他にこんなかっこいいコメント記号（オレ流）あったら教えて

>>392
yyyymmddのほうが検索しやすいっしょ？

（；´Д`）　if の書き方みんなと違う・・・

if (...)
{
}

else
if (...)
{
}

else
{
}

こんなのやだ？

ﾔﾀﾞ

（；´Д`）　やっぱり・・・

if[tab](...){
}
elseif[tab](..){
}
else{
}

for[tab](...){
}

while[tab](...){
}

type function(...)
{
}

これを厳守して作ってます。

どれもこれも、一寸異常。

if(){
　fuck_you();
}else if(){
　fuck_off();
}else{
　normal();
}

今だ！４００と高校生のけつの穴げっとぉー

漏れも、１画面２５行（−ステータス行）の時についたクセで、いまだに>>399にしてる。
{　の前に改行すると、一度に見られるソースの量が減るから。

if () {
　;
} else if () {
　;
} else {
　;
}

だよな、ふつー。
制御構文のカッコはスペースを空けるべき

（；´Д`）　>>394は条件文が揃っていて見やすいと思うんだけどなぁ・・・

>>394はelse if ()が変態だ。
ひとつのブロックとして捕らえづらい

} else{

閉じ括弧とelse等を同一行に書く神経がわからん。

if(hoge){
　age();
}
else{
　sage();
}

だなぁ。俺は。

>>394
みづらー

if(hoge){
　age();
}
else if(mona){
　giko();
}
else{
　sage();
}

肝心のelse ifが抜けてた（；´Д｀）鬱。

（；´Д`）　一人でプログラム作ってて良かった・・・。
　　　　　　仲間がいたら変態扱いされてたんだ・・・。

>>409
ｵﾓｼﾛｲから3点ｱｹﾞﾙ

if(hoge)
{
　age();
}else if(mona)
{
　giko();
}else
{
　sage();
}
ですが、何か？

（；´Д`）　>>411　変態です

えー！？だってC++の場合、ifやswitch無しで
{
}
を使う事も珍しくないYO
if(hoge)
{
　age();
}
else if(mona)
{
　giko();
}
else
{
　sage();
}
だと、ぱっと見で、条件分岐が他のブロックに、
影響してるかどうかがわからないYO

( ;´Д`)俺も一人でﾌﾟﾛｸﾞﾗﾑ書いててよかった。
でもこれじゃﾌﾟﾙﾌﾞﾙﾏで飯食えそうもないな

（；´Д`）　>>413　仲間が欲しかったんです・・・。

>>376
兄弟だーーーーーーーーー。
ifの条件式が長くなったらpascalみたいにやるのもいっしょ。

>ALL
つーかインデントなぞどうでもいい。
lispを見ろ。ほぼpretty-printがデフォだぞ

>>417
おいおい、インデントがどうでもいいわけないだろって（別にPython
つかってるわけじゃないけど）。

>>418
元々コードは論理構造なんだから、
インデントなんか機械的に出力しろって事でしょ。
自分好みのインデント情報を設定して清書プログラムで一気に変換すると。

おれもこのスレの話題って、アホかと思うけど。

あ、pythonや行指向言語は除く

if(hoge){

}
else if(foo){

}
else{

}

かな。何となく。

PEUGEOT

if(...){
　　......;
} else{
　　......;
}

↑これ嫌い。elseの前で改行して。

elseの前の開業やめて・・・
連なりがすぐわかるように
if() {

} else if () {

} else {

}
ってやってよ・・

最近読んだソースの書き方に影響されて

void function()
　{
　if()
　　{
　　function();
　　}
　else
　　{
　　}
　}
になりました。python好きなら結構イケると思います。
if()の条件式が複数行になっても綺麗です。

>>423
俺は、むしろそれが好き。
try {
　　...
} catch {
　　...
}

とか、でも↓は正直ムカツク。

if ()
　　{
　　　　...
　　}
else
　　{
　　　　...
　　}

おれも>>424, >>426の書き方。

断然、

if(...){
    ...
}else{
    ...
}

ですなあ。

}else{

↓

} else {

なんかの半角スペース入れるのって意味あったりする？

意味はないな。なんせスペースだし

>>428
}else{ だと、なんか窮屈な感じがする。まあ、感じ方の問題だけどね。

俺はなるべく改行派だな
if()
{
}
else if()
{
}

ちなみにifのあと処理が一行でも{}使いたくなる
if()
{
　　int x=0;
}
とか、・・・

でも()はどんなに長くなってもなるべく同じ行に書いています
object.addMouseListener(new MouseAdapter(){public void mousePressed(MouseEvent e){}});

object.addMouseListener(
　new MouseAdapter(){
　　public void mousePressed(MouseEvent e){}
　}
);
だな、おれなら。

K&Rｼﾞｭﾝｷｮﾃﾞｲｲﾁﾞｬﾝ

>>432
どうしても改行するなら
object.addMouseListener
(
　new MouseAdapter()
　{
　　public void mousePressed(MouseEvent e)
　　{
　　}
　}
);
にしたくなる
とにかく「(」「{」は行末に置きたくない

if()
{
hoge
}
else if()
{
hoge
}
else
{
hoge
}
空白はtabです。else ifは普通の空白だが。
こうしないと、どこで開いたのか閉じたのか、
分からなくなる私は426にむかつかれている人種ですが、
逝った方が良いですか？

if()
　{
　　hoge
　}
ごめん

俺もいにしえのK&R派。

object.addMouseListener(new MouseAdapter(){
    public void mousePressed(MouseEvent e){
        ...
    }
});

これはいねぇけ？

>>435 >>436
逝かなくてよし。
だが、その理由をもっと詳しく俺にも教えれ。

俺は、Linusに感化されShellスクリプト書くときでさえ
if [hogehoge]; then
　　　　...
←8tab→
fi

なんか行間がスカスカしてて、気持ちいい。

TABは4にしる！

>>439
GNU coding standards はもちろん焼いたよね ;-)

>>439
ifと{の高さを変えるのは気分的な問題だと思う。
void　main()
{
　hoge
}
って書くし(ｗ
ifの後ろに{を続けないのは、確認するのに
同じ高さに{}があった方が見やすいから。

読んでる本には
if(){
　　hoge
}　else　if()　{
　　hoge
}　else　{
　　hoge
}
と書いてある。
行数が減らせるから、慣れたら上記のように書くかも。
とどのつまり、慣れてないだけと思われ(涙)

>>442
その議論は昔からあるね。行数が減らせるって言う。
確かに間延びして全体の構造が把握しにくくはなるかもしれないけど
Javaみたいなヘッダーとソースが混じったようなのは
逆にインデントの始まりが目立つ方がいい気がする。

みなさんswitchはどうしてます？私は

switch(var)
　　{
　　case 0:
　　　　printf("0");
　　　　break;
　　}

前は
switch(var) {
case 0:
　　printf("0");
　　break;
case 1:
　　printf("1");
　　break;
}
でした。

switch(var) {
　　case 0: {
　　　　printf("0");
　　　　break;
　　}
　　case 1: {
　　　　printf("1");
　　　　break;
　　}
}

444の書き方良いな。caseの中の構造がわかりやすい。
俺は下みたいなのだった。
switch(var)
case 0:
// hoge
break;
case 1:
// hogehoge
break;
}

445さん、"{"が抜けていますよ。
switch(var){
と
switch(var)
{
のどちらでせうか？

Visual Studio .NETのヘルプのコーディング技法のとこ、
めちゃめちゃ普通だ。どうしたMS。
これなら全面的に従ってもいいぞ。

if (n > 0)

if (0 < n)

上は「変数が、定数値と比べてどうなのか」という思考を重視した場合。
下は線分図（数直線）を意識して、右に大きい値がくるようにした場合。

これ、どっちにしようかと悩んだりしないか？
こんなので悩むのはオレだけかね？

変数と定数なら、フツー変数が左だろ

if( n = 0 )
で不毛な時間を消費した経験から
if( 0 == n )
とするようにしています。

いや、おれは「右に大きい値が来る」派だ。(だから、'>' や '>=' って
めったに使わん。
'==' や '!=' なら、変数が左だけど。

>>450
10年近くCやってて if (x=0) なんて意図したとき以外は書いた事ねーぞ？

>>452
いくら「自分は絶対間違えない」と思ってても
450の方法ならコンパイラが万が一の間違いも見つけてくれるのだから
それに越したことはないと考えるけど

>>450
if (a = b) は阻止できないのでいかにも中途半端。
んな小技使うよりも、大人しくコンパイラの警告レベルを上げよう。

本当はif(x=0)と書けてしまうCに問題があると思うけどね

while(*p++ = *q++)
　　;
↑これ最悪

if(0 == func1(func2(func3(func4(func5())))))
みたいにやたら長い場合には左におくけどね

>>448
if (n > 0)
if (0 < n && n < 10)

if (0 < n)
if (n > 0 && n < 10)

上２つは使うが下２つは使わんな。

>>451
おお、仲間がいた。オレも　'>='　はめったに使わんから、
たまに使おうとするときに、 「'>=' だったか '=>' だったか…」
なんて悩んで、結局配置を換えていつもどおりの '<=' に
逃げたりする（笑）。

>>458
if (0 < n && n < 10)

から、条件がゆるくなって

if (0 < n)

って削ったときは？　そういう場面に出くわすかどうかは
ともかくとして。配置換えするのか？

俺if(0 < n < 10)派

>>456
それが最悪という理由は、見にくい、意味がつかみにくい
という事からでしょうか？
それとも何か他に落とし穴が？

>>461
実行してミソ・・・俺はいやだ

>>462
は？イディオムじゃん。
スタイルとしてはほめられたものじゃないかもしれないが、
慣用句としてとらえるべき。

>>460
マジ？

>>461
C++限定の回答になるけど、pとqがiteratorで
オブジェクトをさしているのなら、
・無限ループの可能性が大きい
・効率が悪い（コンパイラの最適化次第だけど）
・例外安全が保障できない
かな。たぶん。

>>463
イディオムなのはこっちだろ
while(*p++ == *q++)
　　;
代入の結果で比較したいんなら
while((*p++ = *q++)!=0)
　　;
って書くのがイディオムだ。

>>466 while((*p++ = *q++)!=0) ;

ハァ？
while(*p++=*q++);
ふつうはこっちだろーがよ。

こーゆー省タイプ至上主義者が
ソース全体に警告ばら撒いてくんだよな
こまったもんだ

>>466
いや、while(*p++ = *q++) ってのもイディオムだよ。
VC++ の、strcpy() のコメントにもちゃんと...
;　Algorithm:
;　char * strcpy (char * dst, char * src)
;　{
;　　char * cp = dst;
;
;　　while( *cp++ = *src++ )
;　　　;　　/* Copy src over dst */
;　　return( dst );
;　}
とか、載ってるし (実際のコードは、アセンブラだけど...)。
ただし、私もお勧めはしない。

>>465
> ・無限ループの可能性が大きい
そりゃ仕様だよ。よくわからん文字列をコピーする時は、strncpy() 使えって
言うのは、わかるけどね。(そもそも、C++ なら CString 使えや。)

> ・効率が悪い（コンパイラの最適化次第だけど）
そうか ? M68010 なんかの時代は...
while(*p++ = *q++);
を...
lea.l a0,p
lea.l a1,q
Loop:
move.b (a0)+,(a1)+
beq.w Loop
のようにコンパイルして、さらに M68010 は、この命令の組み合わせを認識して
ループモードと言うモードで命令フェッチせずにループを実行すると言うことま
でやってたよ。つーか、それが普通なぐらい良くあるパターンなんだよ。(まあ、
今時のプロセッサなら、命令キャッシュがあるからなんてことないんだけどね。)

> ・例外安全が保障できない
よくわからん。具体的には ?

>>452
>10年近くCやってて if (x=0) なんて意図したとき以外は書いた事ねーぞ？
意図して、if(x = 0) なんて書く時ってどういう時だよ ?

fopenとかのことでしょ。
いずれにしても年季の入ったCコーダのコードは汚いよ。

>>471
> 年季の入ったCコーダのコードは汚いよ
単なる偏見と思われ。イディオムを多用しているので (慣れないと) 見づらいと
言うのには同意するけど、年季入ってても整然としたコード書く人はいるよ。

>>454
同感

>>471
Ｃが最適化がほとんど無くてコードが実行効率に
直結していて文字通り（高級アセンブラ）だったころの
ソースはどれも今見るとカナリ汚い。

つーか黎明期はイディオムとか定石とかがしっかり確立してなかったしね。

イディオムは極力使わないように、本当に最適化したかったら
アセンブラを持ち出すようにしてますです。

FILE *fp;
fp = fopen(filename, "r");
if (fp == NULL){
    printf("file cannot open");
    return 1;
}
/* 処理 */

>>469
あー、無理やり考えたんだから、あんまりまじめにレスせんでも。
最初に「pとqがiteratorでオブジェクトをさしているのなら」って、
むちゃくちゃな前提で話をしてるでしょ？

＞・無限ループ
まあ、深く考える話題でもない。

＞・効率が悪い
「オブジェクト」つったやん。後置インクリメントのほうが効率が悪いのは
常識っしょ。

＞・例外安全が保証できない
すまん、これは間違いだらけだ。
最初に言いたかったのは、「例外安全の強い保証ができない」だった。
(*p++ = *q++)　の形を変えると、

operator=((*p).operator++(int),(*q).operator++(int));

こうなるだろ。iterator p,qの後置インクリメント呼び出しの後に
代入演算子がくるから、代入演算子で例外が出ると、pとqは
すでにインクリメントされているから状態が変わってしまっている。
だから「例外安全の強い保証ができない」んじゃないかと思ったわけだ。
しかしまあ、よく考えてみると後置インクリメントの戻り値は
constなテンポラリオブジェクトを返すのが定石だから、そもそも
こういう記述はありえないんだよな。
ま、さらっと流してくれ。

注意深く調べて大丈夫だと確認するくないなら、調べるまでも無く安全なコードかきませう。

>>477同意。

>477はげしくドーイ

最近のPCの性能を考えれば
最適化による僅かな性能向上を求めるよりも
分かりやすいコードを書くように努めるべきだね

古びたCのテクニックは捨ててよし

>>475
「イデオム」の意味わかって使ってる?

idiom
【＠】イディオム、イデオム、【変化】《複》idioms、
【名】イディオム、熟語、成句、慣用語法、慣用法

方言とか、その言語独特の言いまわし、みたいなニュアンスもあるね。

>>480
その考えはスクリプト言語にも当てはまるんでしょうか？

初期化（更新）；
while (条件チェック＝＝継続){
　作業；
　初期化（更新）;
}

ってなとき、どうしてる？　俺は、

while (true){
　初期化（更新）；
　if (条件チェック＝＝終了) break;
　作業；
}

こういう風にして、初期化（更新）の２度書きが無いように
してるけど。whileの中で条件を書いてないと気持ち悪いって
人もいるかな？

>>485
俺も、そうすることある。初期化が一行ぐらいだと、２回書くこともあるけ
どね。

VB だと...

Do
　初期化(更新)
　If 条件チェック = 終了 Then Exit Do
　作業
Loop

と書けるので、ちょっと気持ちがいい。

>>485
for(初期化;条件;){
なんか
}

違う。こうだ。でもｶｺﾜﾙｲな。
for(初期化;条件;初期化){
なんか
}

>>488
初期化してしまうのですか？

whileの中に直接まとめてみたりするのはトリッキーだが:

while( 初期化(更新), 条件チェック==継続 ) {
　作業;
}

リファクタリングで、

bool 続けるべきか()
{
　初期化(更新);
　return 条件チェック==継続;
}

というふうに分離した上で

while( 続けるべきか() ) {
　作業;
}

という形にしたいところかな。

続けないときに無駄な初期化が入るだろ。
bool 続けるべきか()
{
　if (条件==継続) {
　　初期化(更新);
　　return true;
　}
　else
　　return false;
}

今日､こんなソースを見ました。

while (1) {
if () {
・・・・
break;
　}
・・・・
if () {
・・・・
break;
　}
break
}

ループ、回りません。goto教えた方がいいのでしょうか。（−−；

>>492
これ、定石だろ。
漏れはdo{ }while(0)が好きだが。

例外処理一箇所に集めるコードですか？
gotoのほうがかえってわかりやすいと思うのは漏れだけ？

え！？＜定石
おいおい。

俺もdo{break;}while(0);使うならgoto使うかな。
do〜while(0)ってgoto問答無用で使用禁止とか言う糞プロジェクトで使う抜け道じゃねーの？

>>485
普通に
do{
　初期化（更新）；
　作業；
}while(条件チェック＝＝継続);
じゃ、ダメ？

いや、言いたいのは、そもそもgoto自体、そんなに必要になるとも
思えないのですがと言う話で・・・。

ちなみにうちのプロジェクト、goto禁止なんて制約もないんです。

>>498
do {
} while (0)がそんなに必要とも思えないけど。

gotoは絶対使ってはいけないという習慣が広がっているおかげで、
逆に少量のgotoが使ってあるソースの方が信頼おける気がする

>>497
ダメ。
>>485がやりたいのは、　初期化（更新）；　のあと、条件によって　作業；　を飛ばすの。

漏れは485の2つ目でいいと思うが、
あえて言うならwhile(true){}より、do{}while(true)だな。
こっちのほうが、初期化は問答無用でやれって感じが伝わってくる。
どこまでがループなのかも比較的わかりやすいし。

普通にif重ねて書いちゃダメなの？

いいよ。goto使うけど

>>485
do{}while()は？

作業する前にbreakしたいんでしょ

魔法のｉらんどでつくったHP不正に改ざんされてパスワード変えられた
｡誰か不正アクセスの仕方とか教えてください｡
お願いします｡

goto禁止のところってgotoでgrepして見つかると怒られるとか
そういう感じですか

>>508
ウチはgrepしないが、レビューの時にバレると怒られるぞ。
ifで階段作るのも文句言われるんで、フラグ用意するしかない（藁

何でそんな腐った環境が存在するんだ？
優れたプログラムの何たるかを小一時間問い詰めてやれ。

if ()
{
}
のスタイルだと
do
{
}
while ();
になるのでしょうか ?

>511
if()
{
}
のスタイルでも

do
{
} while();
が普通ではないでしょうか。

他にも
class A
{
}
a;
とはやらず
class A
{
} a;
だったりします。

>>0x0100
for(;;){
}
do{
} while();
でよくない？
MSのコードでも大概。

もれは
do
{
}
while()
だな。
こうすると
ループ内のコードとループ条件を意識せずに分けられて美しい（と思う）。

do
{
　　hehehe = huhuhu; // またはこの下を一行空ける
}while(hoho<hahaha);
より
do
{
　　hehehe = huhuhu;
}
while(hoho<hahaha);

これは
while(huhehe)
{ //←ここの括弧を改行するのと同じ理由
}

それだとwhileをみたときに、do-whileのwhileなのかただのwhileなのかぱっと区別がつきづらい

0x100です。
>>515
私もその理由で>>0x102のようにはしていません。

16進うざ。

>>515
そういう考え方もある。
（do{}while()の次は通常空行なので現実に混同することは無いんだけどね）

>>516
漏れは0x202

>>518
>>513に惑わされました。ｽﾏｿ。

俺もスタイルは >>513 に同意だけど、そもそも do〜while() なんかめったに
使わんぞ。みんな結構使ってんのかなぁ...。

>>490
状況によるけど、初期化と作業の関連が深そうだったら分離するとわかりにくく
なるのでまずいかも。

>>491
続けない時も初期化が必要なんだよ。>>485 見れ。
こんなとこでバグ作りこむなよ、バカ。

do〜while()使うよりwhile()での無限ループ＆breakだな...。

いろいろ、ご意見ありがとうございました。

ぐりぐりとリファクタリングしてたら、最終的に、こういう風になりました。

Hoge 初期化・更新(void);// 戻り値のHogeが、ループ条件のためのキー
bool 条件チェック(const Hoge&);// 戻り値のboolが、更新すべきかどうかのフラグ

while (条件チェック(初期化・更新()){
　作業
}

・>>521で指摘された初期化と作業との分離の問題点
・初期化・更新の二度手間
・無限ループをbreakで抜けるいやらしさ

の全部を回避して、エレガントに収まってくれました。

>>523
どこがエレガントなんじゃ！と小一時間・・・
条件チェックが初期化関数を受け取るのがbreakするよりいやらしいが。

>>523
どっちかというと >>485のほうがいいよ。
あと関数名に漢字を使うと説明文と紛らわしい。

もうネタ切れ？

x = a ? b ? c ? d : e : f ? g : h ? i : j : k;

for(int i = 0; i < n; i++){
    try{
        values[i] = Integer.parseInt(str[i]);
    }catch(NumberFormmatException ne){
        return;
}
}

↑と↓どっちの書き方が賢いですか？（スレ違いですが

try{
    for(int i = 0; i < n; i++){
        values[i] = Integer.parseInt(str[i]);
    }
}catch(NumberFormmatException ne){
    return;
}

こんな小さいプログラムではどっちも一緒。>>528

>>528
あえて言うなら下が好み。

>>529
別人で済まんが、forループの回転数を大きくした場合とforループの中身を大きくした場合で違うと言うことか？

いや、ケースで使い分けるべきだという意味。
こんな小さいサンプルでは、見た目上も効率上も測りうるものは無いと思う。

1箇所でいいなら前者。
同じ try - catch を何箇所も書く必要があるなら後者。

tryブロックに入るごとにコストを支払うことになるから、下の書き方を
するもんじゃないの？　上の書きかただと、tryのコストをループ回数だけ
支払わなきゃならないっしょ？
529は小さいプログラムだからつってるけど、nの大きさがわかんない以上、
影響でっかいかもしれないじゃん。

>>534
tryブロックの出入りそのものにコストがあるというより、
try〜catchの範囲にコストがあるんとちがうの？
いや、俺が誤解してたらマジで教えてほしいのだけど。

>527
ﾜﾗﾀ

OracleのSQLスクリプトでDECODE()使ってそうなってるところ多い。
素直にストアドファンクションにしろといったら、
PLのCOBOLerに「いや、俺PL/SQLよく判らないから」と言われて却下されたYO!

関係なくてスマム。


そういや、3項演算子も絶対禁止なプロジェクトもあるなー。

>>527
x = a ? (b ? (c ? d : e) : (f ? g : (h ? i : j))) : k;
という意味だから、結局こういうことになるのかな？

if( a ){
　if( b ){
　　if( c ){
　　　x=d;
　　}
　　else{
　　　x=e;
　　}
　}
　else{
　　if( f ){
　　　x=g;
　　}
　　else{
　　　if( h ){
　　　　x=i;
　　　}
　　　else{
　　　　x=j;
　　　}
　　}
　}
}
else{
　x=k
}

っと、こう書けばいいのか（最後のif( !a )は不要だが）。

if( a && b && c )
　x=d;
else if( a && b && !c )
　x=e;
else if( a && !b && f )
　x=g;
else if( a && !b && !f && h )
　x=i;
else if( a && !b && !f && !h )
　x=j;
else if( !a )
　x=k;

>>535
　まあ、俺も自信はないんだけど、せっかくだから確認しておきたいので
書いておくか。例外処理の実装がどうなっているかを想像してみたんだけどさ。

　例外は、関数単位とはまったく別に、最も内側のtry〜catchブロックに
引っかかるわけでしょ。だから、例外のジャンプ先の情報を保存したグローバルな
スタックがあるだろう、と。グローバルなスタックには、tryがくるごとに、
対応するcatch節の場所をpushされて、try〜catchブロックを
ひとつ抜けるごとに、popされる。んで、例外が発生したら、topにある
catch節の場所に行ってみて、処理されればOKだけど、処理されなければ、
popして、次のtop位置に飛ぶ。そんな感じでジャンプしてるんじゃないかと
思ったわけだ。
　もちろん、単に飛ぶだけじゃなくて、関数で使われたオブジェクトの
デストラクタを適切に呼ぶため（アンワインド）の情報もどっかで必要では
あるけど、それは今は考えない。そっちはどうなっとんのか、よくわからん。
　少なくとも、「例外が出たときのジャンプ先」の情報は、try〜catchに入ったときに
pushして、抜けたときにpopする、となってると思うんよ。

　そういった想像を踏まえてMore Effective C++,Exceptional C++などを
読んでも、矛盾はなさそうだったし。ついでに、VC6のデバッグモードで
try〜catchを書いてみたら、想像どおり、try〜catchの入り口・出口で
コストがかかってたからね。

>>528のコードを単純化したものも書いてみたけど、やっぱループの内側で
何回もコストを払ってるコードになってたよ。

……想像部分が多いんで、よくわかってる人に、ぜひツッコミが欲しいな。

528はジャヴァでは？
try〜catchのコストは言語(と実装系)によりマチマチかと。
ジャヴァだとスタックポインタの書き換え以外のアンワインドは
必要ありませんよね。

前半の考察は言語に依存してないと思います。
tryブロックに入るたびに、例外が起こったときのジャンプ先を保持する
必要があるから、その分のオーバーヘッドはあるはず。

例外が発生したときにスタックフレームをたどって、実行していたアドレスを
リンカが生成したテーブルを引いて…という実装もありうる。
というのを「C++の進化」で読んだ。これならtry自体のコストはない。throw
のオーバーヘッドは大きいけど。

にゃるほろ。概ね理解した。サンクス＞ＡＬＬ

>>541
う、全然わからん。「C++の進化」をぐぐっても出てこないし。
も少し解説キボン。

岩谷宏の訳だった気がする

たとえばこんな↓問題で、見やすさを追求するとどうなる？

---------------------------
data.txt を fopen() と fgets() で読み込み
7,10,14行目の先頭文字がそれぞれ'a','b','c'であったら、
20行目を1行表示するプログラムを書け。
ただしバッファは char buff[ BUFF_MAX ] ; とし、
data.txtの1行はBUFF_MAXを超えないものとする。

>>545
data.txt を
　fopen() と
　fgets() で
読み込み
　7,10,14行目の先頭文字がそれぞれ
　'a','b','c'であったら、
　20行目を1行表示する
プログラムを書け。

ただしバッファは
　char buff[ BUFF_MAX ] ; とし、
data.txtの1行はBUFF_MAXを超えないものとする。

>>545
data.txt を 先頭文字がただし7,10,14行目のdata.txtの20行目を 読み込み
それぞれ'a','b','c'であったら、
1行表示する1行はプログラムを BUFF_MAXを書け。
char buff[ BUFF_MAX ] ; とし、
バッファはfopen() と fgets() で超えないものとする。

本がどっかに埋もれてしまってて記憶に頼って書く。間違ってたらスマソ。

tryブロックの開始・終了アドレスとcatchハンドラのアドレスのテーブルをリ
ンカが生成、例外発生したらスタックからリターンアドレスを探し、テーブル
の範囲に入っているものがあったら該当するハンドラに跳ぶ。

Cで適当に書いてみるとこんな風かも。__builtin_*はgccには実際にある関数
だが、rewind_jump()はlongjmp()のような何か。

struct exception_info;
struct exception_block {
　　void (*start)(), (*end)(), (*handler)(struct exception_info *);
};

const struct exception_block exception_blocks[] = {
　　...
};

static int search_exception_block(const void *key, const void *elem)
{
　　const struct exception_block *block = elem;
　　if (key < elem->start) return -1;
　　if (key >= elem->end) return 1;
　　return 0;
}

void _throw_(struct exception_info *exc)
{
　　void (*ret)();
　　int i;
　　for (i = 1; (ret = __builtin_return_address(i)); ++i) {
　　　　const struct exception_block *block;
　　　　block = bsearch(ret, exception_blocks,
　　　　　　　　　　　　sizeof(exception_blocks) / sizeof(struct exception_block),
　　　　　　　　　　　　sizeof(struct exception_block), search_exception_block);
　　　　if (block) {
　　　　　　rewind_jump(ret, __builtin_frame_address(i), exc);
　　　　}
　　}
}

つーかやっぱりg++はそういう実装になってるな。

void bar();
void foo()
{
　　try {
bar();
　　}
　　catch (...) {
　　}
}

gcc2_compiled.:
.globl __rethrow
.text
　　　　.align 16
.globl foo__Fv
　　　　.type　　foo__Fv,@function
foo__Fv:
.LFB1:
.LEHB3:
　　　　pushl　 %ebp
.LCFI0:
　　　　movl　　%esp, %ebp
.LCFI1:
　　　　call　　bar__Fv
.LEHE3:
　　　　jmp　　 .L9
　　　　.p2align 4,,7
.L5:
　　　　pushl　 $.LRTH3
.LCFI2:
　　　　call　　__rethrow
　　　　.p2align 4,,7
.L3:
.LEHB5:
.LCFI3:
　　　　call　　__start_cp_handler
　　　　pushl　 %eax
.LCFI4:
　　　　call　　__cp_pop_exception
　　　　popl　　%eax
.L9:
　　　　movl　　%ebp, %esp
　　　　popl　　%ebp
　　　　ret
.LEHE5:
　　　　.section　　　　.gcc_except_table,"aw",@progbits
　　　　.align 4
__EXCEPTION_TABLE__:
　　　　.long　 -2
　　　　.value　4
　　　　.value　1
.LRTH0:
.LRTH3:
　　　　.long　 .LEHB3
　　　　.long　 .LEHE3
　　　　.long　 .L3
　　　　.long　 0

>>528
断然下。
forループの処理後に何か処理が必要になったとき
;　for () {
;　}
;　aaa = AAA();　（１）
（１）の処理の例外をとりたいとき、
なんかで修正範囲が違う。

>>548
なるほど。大体の感じはつかめたよ。ありがと。
ところで、その本のちゃんとしたタイトルが知りたいというか、
アマゾンでのページを教えてくれるとありがたいんだけど。

こんなとこ？>>545
それとも、switch〜caseを使った方がいいかな。

int i;
FILE *file_pointer;
char buff[ BUFF_MAX ];

file_pointer = fopen( "data.txt","r" );
if( file_pointer == NULL )
{
　return false;
}

for( i=1; i<=20; i++ )
{
　fgets( buff, BUFF_MAX, file_pointer );

　if( i == 7 && buff[0] != 'a' )
　{
　　fclose( file_pointer );
　　return false;
　}

　if( i == 10 && buff[0] != 'b' )
　{
　　fclose( file_pointer );
　　return false;
　}

　if( i == 14 && buff[0] != 'c' )
　{
　　fclose( file_pointer );
　　return false;
　}

　if( i == 20 )
　{
　　printf( "%s", buff );
　　fclose( file_pointer );
　　return true;
　}
}

って、きっと突っ込みどころ満載だろうからsage(w

>545
#include <stdio.h>
#define BUFF_MAX 100
int main()
{
　　int n;
　　char buff[BUFF_MAX];
　　char head[21];

　　FILE* pFile;
　　pFile = fopen("data.txt", "r");

　　for(n = 1; n <= 20 && fgets(buff, BUFF_MAX, pFile); ++n){
　　　　head[n] = buff[0];
　　　　if(n == 20 && head[7] == 'a' && head[10] == 'b' && head[14] == 'c')
　　　　　　printf("%s", buff);
}

　　fclose(pFile);

　　return 0;
}

宿題に答えていただきありがとうございまっす(^д^)uma〜

引数を

foo( int _in ) { ...

って、前にアンダーバー付けるのって、流行っているの？
楽そうだから今度から使ってみようかな。
あと、メンバ変数を

int m_member ;

じゃなくて、

int member_ ;

って、後ろにアンダーバーを付けるとか。
何処から流行り始めたのかな？
ちなみに 前後にアンダーバーを付けるのも

　_xxxx_

見たことあるけど、意味がわからねー。
誰か詳しく教えてくれ！

>>555
もしC/C++なら _ で初まる名前を付けていいのは処理系(コンパイラ)提供者だけ。
後ろに _ 付けるのはHerb Sutter 周辺が使って書籍で紹介したりした関係?

>>555
えぴのMLで見た記憶があるかも

どうでもいいと思ってたけど、
ふと思いついたから書いてみると、

どれだけ多くの構造体の種類があるかじゃない？
つまり、構造体をたくさん定義してるプログラムは複雑。

どうかな？

構造体がないプログラムの方が複雑なケースは多いが

>>558
全然関係ないとは言わないけど、そうでもないケースも多いと思うよ。
むしろ変な構造体をいっぱい定義して、それで複雑になっているプログラム
もあるしね。

>構造体がないプログラムの方が複雑なケースは多いが
構造体のないプログラムが複雑だとは思わないけど。
それってOOでいうクラスが一つみたいな事なわけだし。

>むしろ変な構造体をいっぱい定義して、それで複雑になっているプログラム
>もあるしね。
じゃあ
構造体の数/PGのレベル
ってとこかな

>>561
> 構造体のないプログラムが複雑だとは思わないけど。
なんで ? 配列がないと作れないプログラムはあるけど、構造体がなくて
もプログラムは作れるよ。

> 構造体の数/PGのレベル
何を言いたいのか意味不明。

>なんで ? 配列がないと作れないプログラムはあるけど、構造体がなくて
>もプログラムは作れるよ。
配列を構造体代わりに利用するの？（ｗ
適材適所ということで。

>何を言いたいのか意味不明。
構造体の数に比例して、PGのレベルに反比例する

構造体はデータ間の関連性を意味する。
構造体の種類が多いということは、データが相互作用しあう
複雑なプログラムと言える。

コメントが一つも無いってもはや悲しくなってくる。

>>564
最近はむしろコード本体にはコメントを残さない方が良いんじゃないの？

>>563
言いたいことがここまで伝わらないとは...。
> 配列を構造体代わりに利用するの？（ｗ
構造体って言うのは、単に複数の変数をまとめたもんだからなくても何と
かなる。(=なくても、複雑なプログラムはいくらでも作れる。)
と言うことだよ。わかった ?

> 構造体の数に比例して、PGのレベルに反比例する
だから主語を書いてよ。プログラムの複雑さか ?

> 構造体の種類が多いということは、データが相互作用しあう
> 複雑なプログラムと言える。

構造体が一種類しかないけど、複雑に絡み合ったリンクリストを処理する
プログラムなんてぇのはどう考えるんだ ?

C++で、
class Object;
があるとして、「Objectのインスタンスを作るクラス」っていったら、
class ObjectCreator;
class Object::Creator; // ネストされたクラス
どっちがいいですか？

ageわすれました。

前者に決まってる。

>>567
ObjectFactoryはだめ？

>>567
Objectにstaticなメソッドを持たせるのは？

>構造体って言うのは、単に複数の変数をまとめたもんだからなくても何と
>かなる
何とかなるけど、見やすい構造体を使うでしょ？

>だから主語を書いてよ。プログラムの複雑さか ?
わかってるじゃん（ｗ

>構造体が一種類しかないけど、複雑に絡み合ったリンクリストを処理する
>プログラムなんてぇのはどう考えるんだ ?
それを作った奴はｸﾋﾞと考えるのが一般的だろうねぇ。

まあ､ﾏｼﾞﾚｽすると
線形リストは文字通り線形だけど

>>567
>Objectにstaticなメソッドを持たせるのは？
それの設計はセンスがない

>>569
うぉ、早ぇ。
一目瞭然で上ってことですな。
うーん、混乱の元凶はこれのような予感がふつふつと確信へと
変わりつつあるのを感じる気がするですよ。
ありがとうございます。

>>570
Creatorのインスタンス一個からObjectのインスタンスが一個つくられますので、
Factoryじゃないです。

>>571
ぜんぜんちがうです。

>>571
マジでわかってないのか、俺が遊ばれてるだけなのか...。
> 何とかなるけど、見やすい構造体を使うでしょ？
ねぇ、>>566 の５行目の ( ) の中は読んでくれたの ?

> それを作った奴はｸﾋﾞと考えるのが一般的だろうねぇ。
はぁ ? そう言うプログラム組んだことないの ?

> 線形リストは文字通り線形だけど
線形リストしか思いつかないのか...。あんたの理論によると、あんたの
作るプログラムは、複雑そうだねぇ。

>それの設計はセンスがない
なぜ？
シングルトンだってそうするのが普通でしょ？
ファクトリーメソッドだってそうだし。
オブジェクトプーリングする時もそうしてるし。
クラスをスターティックにするのも、
クラスの中にスターティックメンバを作るのもそれほど変わらないから、
スターティックメンバを作った方が、クラス間の関係がすっきりすると思うけど。

>ねぇ、>>566 の５行目の ( ) の中は読んでくれたの ?
構造体を使えば､複雑にならないならそれでいい。
構造体を使わないけど、複雑なプログラムって例えば何？
クソプログラマーが作ったプログラムじゃなくて？

>はぁ ? そう言うプログラム組んだことないの ?
具体的な物が想像できないので、なんともいえないけど、
構造体（クラス）を使わない、複雑なプログラムなんて作った事ない。
クラスへの参照を持つクラスが40個くらいになってくると、
ちょっと複雑な気がしてくるような・・・
コマンドラインからの入力を解析するパーサーなんかは、長いけど
複雑だとは思わないしなぁ。

>線形リストしか思いつかないのか...。
グラフ＝線形リスト|木|その他
他にあるのか？

>複雑に絡み合ったリンクリストを処理する
ちなみにリンクドリストと言えば、単方向リストをイメージするが
これが双方向リストでも、インターフェースは変わらないからさほど問題はない。

>>575
> グラフ＝線形リスト|木| ((その他))
> 他にあるのか？
そりゃ他には、ないわな。真性の粘着ヴァカか ?

レスの見た目効率を語るスレはありませんか？

>>576
その他のグラフという意味での「その他」だよ

じゃあなんて書けばいいんだよ？

なぜ「構造体」というものがあるのか知っていれば、
そんな思いつきはまちがいだと、すぐわかるのにね。

・・・真性の粘着ヴァカか？

">>558" でしたょ。ｳﾂﾀﾞｼﾉｩ

役に立たんすれだ

>>582

御意。fjのReﾈﾀを彷彿とさせる

そう言えば、fjは最近ｻﾊﾟｰﾘ書き込みないね。ある意味寂しい。

>>575
>スターティックメンバを作った方が、クラス間の関係がすっきりすると思うけど。
本当のｱﾌｫなのか？すっきりすねぇよﾊﾞｸｧ。

C/C++ の enum のタグ名って、なんか慣習みたいなの、ない？

>なぜ「構造体」というものがあるのか知っていれば
なぜ？

>>586
とくにないような。

>>586
せいぜい最後の行にも , を付けるとかかな。
enum {
　hoge= 0,
　piyo,
　foo
　bar, /*←これね*/
};

fooの後に , 忘れた。

あげるんじゃごるぁ

>>589
いや、タグ名の話をしてるんだろ?

>>586
ちょっと調べてみたら普通は小文字が多いみたい。でも私は

enum eKind { kHoge, kPiyo, kFoo, kBar, kKindMax };
struct sData { eKind mKind; };
class cObject { public: char* ToStr(); private: int to_int(int var=0); };
const int kMax;
extern int gGlobalVar;

ってやってます。ハンガリアンみたいで、みんな嫌いだと思うけど(w;
置き換えが楽だったり一目で種類が分かるのが便利かも。

C++ でポインタや参照を表す * や & ってどこにつけてる？

int *hoge;//1
int* hoge;//2

主にこの2パターンだとおもうんだけど。
1行に複数の変数を宣言することを考えると1なんだけど、
hoge は「intのポインタ」という型であることを考えると、
2のほうがすっきりしてる気もする。

ちなみに俺はポインタは1で参照は2。

>>594
Effective C++ がそうなってるね。俺もしばらくはそうやってたけど、
ポインタと参照で記号位置が違うのが気になったんで、全部２の方で
統一してる。１の場合だと、

char *Hoge(const char *moe);

こういうのが気になるんよね。

ちなみに、『1行に複数の変数を宣言』なんてことは、そもそもしない。
変数宣言したときは、ほぼ必ず初期化もいっしょにするしね。

両方２かな

>>595,596

やっぱ両方２にしたほうがいいのかな。
位置がそろってないとなんとなくやな感じなんだよね。
おかげですっきりしたよ。さんく。

ただそうすると、次は配列が気になってくるんだよね。
「intのポインタだから」「intの参照だから」で

int hoge =3;
int* moge = &hoge;
int& sage = hoge;

っていう理屈で行くなら、「intの配列だから」で

int[50] hage;

って書きたくなっちゃう。俺だけかね？

>>594 - >>598
おい、その int に const つけるときはどうするのかも語ってください。

>>599
「語れ」っていうんなら、自分はどうするかを先に言えよ。

俺の場合は、

const int age = 5;
const int* hage = &age;
const int& piyo = age;

だな。

int const* puni = NULL;

とする人って、どれぐらいいるんだろ。あんまり見ない気もするけど。

>>595
はげどう。それができないから素CとかPascalするのが苦痛。
初期化し忘れたり、関数の一部を修正したり消したりする時
関連してるローカル変数が分かりにくかったりするし。

>>598
確かに。でもint[30]とint[50]が別の型になってしまうような・・・
ん？それでいいのかも。。。

>>600
いままさにごちゃごちゃになってしまってます。
const int * const pint_table[] = { ...
・・・イライラするんだよ、こんなコード書いてるとよ。

> int const* puni = NULL;
このスタイルにすることもやぶさかではなし・・・・。
NULLはつかわねーけどな。

>>600

int const * puni = NULL;

だと、ぱっと見で

int* const puni = NULL;

のことかと勘違いしてしまいそう。
* が型(この場合int)と位置的に離れてるのも嫌。

>>603
つまり const 位置の一貫性をあきらめたほうが、
見た目効率がいい、ということですね。

>int const * puni = NULL;
人じゃないけど、 gcc がこのスタイルで出力してくる。

604は漏れです。ageで騙ってしまいましたｽﾏｿ。

>>589
enumで最後のカンマはまずいだろ...

最後のカンマの意味って何？
#ifdef DEBUGとかそういうのですか？

>>606
> enumで最後のカンマはまずいだろ...
C99ならOK

> 最後のカンマの意味って何？
Cの言語仕様のバグ

>>604
ん？　一貫性をあきらめるって、どのへんで？　具体的な記述キボン。

>>607
とりあえず、行単位のカット＆ペーストで入れ替えをしたとき、
『最後の要素だからカンマを削って……』ってことをしなくて
よくなる、という利点があるよ。

>>608
あれ、これバグだったんだ。知らんかったわ。でもC99でOKってことは、
標準の連中が『コレ何気に便利だから採用』って考えたってこと？

>>609
「 const は常に直前の型にかかる」という一貫性のことです。
最近 int const X = ...; って書くことが増えてます。
「ポインタ以外の型に対しては直前に const を置く」っていうのが多いみたいだけど、
それだとポインタに対して const をつけるのをつい忘れがちになってしまう。

「constは可能な限り左側に書く」という一貫性でいいじゃん

なにそれ
constを左に置くことが出来るのは1例だけだから、
むしろそっちの方が例外じゃん

順序を変えても意味がかわらない部分でconstを一番左に書くと
言いたかったんだけど。
結局のところ行の先頭と*の直後にしかconstを書かないという事になる。

うーん。俺は「const int」派なんだけど、「int const」の方が、
たしかに一貫性という点では一歩先んじてるねぇ。
ただ問題は、

char const* const hoge = "ほげ";

ってとき、

[char const][* const] hoge = "ほげ";

って意味で書いてるのに、スペースのせいで

char [const*] const hoge = "ほげ";

っぽく見えちゃう、と。それだけが難点。

char const * const hoge="ほげ";
でいいじゃん。

char const って、char unsigned って書くのと同じくらい
気持ち悪いじゃん。

別に。

>>615
だから、そうすると記述上の一貫性が保てないって事が問題なの。
レス、ちゃんと読んでる？

>>616
そんな書き方ができるなんで初めて知った。
使わないけど。

ほしゅage

　pretty-print一発ですが。

#define isConst const
char(isConst)*(isConst)　a;

はダメ?
脳内で const を isConst と読み替えても良いけど。

括弧のくくりかた間違えた…
これじゃコンパイル通らねーYO!

…首くくってきます…

>>622
激しくダメ。
" * is const." って意味和漢ネーよ

char const * const a;
では、
" 'a' is a constant pointer to constant char. "
と a から遡ってみればよし。小細工は必要ない。

>>624
Eiffel マンセーとか言ってみるテスト。
ところで　"* is const" ってそのまま読めるぢゃねーのさ。
>>622みたく、くっつけると意味不明だけどさ。

constなのは*じゃなくてa。

いままさにごちゃごちゃになってしまってます。
const int * const pint_table[] = { ...
・・・イライラするんだよ、こんなコード書いてるとよ。

> int const* puni = NULL;
このスタイルにすることもやぶさかではなし・・・・。
NULLはつかわねーけどな。

int* a, b; とやってしまい、aとbの意味が違うのに気づかず半日を
潰したことがある。

>>627-628
たぶん MS の人間もハマったに違いない。

winnt.h から。
> typedef CHAR *LPSTR, *PSTR;
> typedef CONST CHAR *LPCSTR, *PCSTR;

>>629
たまにconstにすべきところがなってないのがその証。(ﾜﾗ
もっとも使う者としては(ﾜﾗなんて言ってられんが…

見た目が良くなれば作業効率が上がる可能性があると思われる罠と言いたいテスト

>>631
Xのwindow-managerは見た目が良いものが多いけど
作業効率が上がる見込みは薄いですが。

Xのwindow-managerは使い勝手はともかく見た目が良かったが
Windows XPで追いつかれた。使い勝手は言うまでもなく。

頼むからコメント書けやｳﾞｫｹ!

Lunaって見た目いいか?

Javaでのメソッド呼び出しに対する良い方法は、ない？

>>635
いたい。悪い意味でWin98の部分が出た。
とてもじゃないけどクラシックスタイルじゃないと無理。

おいおまえら縦に長いコードと横に長いコードはどっちが好きですか。
同程度にきれいなコードだとして。漏れは横長好き。

>638
横長になてる程度と同程度なｿｰｽは、そもそもｷﾚｰなｿｰｽとはいえないとおもわれ。

横長は悪だってば。環境にも拠るが。

それに、横長にすると（微妙に）タイプ数が増えるからだるい。

インデント深めにして、横が画面からはみでるくらいネストしたら、関数に分割すべき。
って Linus が書いてた。

インデントの量にもよるし、画面幅にもよるな。
インデント2,幅120で表示している俺はいつまでたっても関数作れない

>>642
GNU style?

>>643
Borland スタイル

姉妹スレ相互リンク

◆(){}[]カッコの付け方(){}[]◆
http://pc3.2ch.net/test/read.cgi/tech/1035379065/

いいよ。goto使うけど

Unicode が最強です

>>645
姉妹スレというか、重複スレだろ

むしろ派生スレだな。

C++のテンプレート。

list<vector<int> >
が格好悪いので、曖昧でなくても<>とテンプレート引数リストおよびパラメータリストの間には
常にスペースを一個入れるようにしている。
template< T > ←こんな感じ。
しかし他で見かけないし、笑われそうで心配になる。

そもそも曖昧性除去規則で、テンプレート名による限定的な構文解釈が適用されるのだから、
listもvectorもテンプレート名、従って>>は入れ子になったtemplate-idの閉じ括弧と解釈すれば
いいのに、なぜここで>>演算子を優先するんだろうね？

ま、見た目効率とはあまり関係ないが、コーディング時のストレスを左右すると言うことで。

上げてみる

>>650
漏れも常にスペースいれる。で、それに激しくtypedef。

閉じ括弧として解釈したら、
template< int I > struct X {};
こんなテンプレートの X< 0x1000 >> 3 > とか、エラーになったりしない？

プログラムを作る為にはどう処理してるか頭でしっかり理解してないとだめ！
だからコメント必須！

>>652
遅レスすまぬ。

> こんなテンプレートの X< 0x1000 >> 3 > とか、エラーになったりしない？

それいったら、X< n > 0xff >が現状でエラーになるんだけど．．．。
X< (n > 0xff) >という記述を要求するなら、
X< (0x1000 >> 3) >って書くべきな気がする。

もっとも整数テンプレート引数にはconstが要求されるから、比較演算にあまり意味はなさそうだけど．．．。
だから比較演算子はテンプレート閉じ括弧より弱いのに、シフト演算子は強いんでしょうかね？

> それいったら、X< n > 0xff >が現状でエラーになるんだけど．．．。
ほんとだー。

コンパイラ実装側の立場の話、
">>"を連続した閉じカッコとして認識する規格であったなら、
構文解析部の状態によって字句解析部の動作を変える必要がでてくるわけで、
構文解析部と字句解析部に相互依存の関係が発生してしまう。

・・・とおもったんだけど、どうかな？

template< foo > bar operator > ( ... )

スペースと括弧・コンマ・セミコロン・関数・変数の関係はどう？

int i , j ;
for ( i = 1 ; i <= 10 ; i++ ) {
　j += i ;
}
printf( "%d" , j ) ;

int i, j;
for( i = 1; i <= 10; i++ )
{
    j += i;
}
printf("%d", j);

jが不貞

660と同じ

ついでに職業も聞いてみたいものだ。学生ほど（略

>>659
間延びしてていやん。

>>660
forは()の内側を空けるけど、関数は空けないわけ?

自分は ++i と書きたい。
int i, j;
for(i=1; i<=10; ++i){
  j += i;
}
printf("%d", j);

-kr
--no-blank-lines-after-declarations
--blank-lines-after-procedures
--no-space-after-function-call-names
--brace-indent0
--braces-on-if-line
--dont-cuddle-else
--case-indentation2
--case-brace-indentation2
--declaration-indentation0
--else-endif-column0
--continue-at-parentheses
--parameter-indentation4
--procnames-start-lines

>>666
indent が使えりゃ他人のコードも少しは見易くなるんだけど。
Winじゃなぁ。MacOSXなら使えるんだが。

Winだと使えなくなったのか？
言語それともC/C++じゃないとかか？

indentのC++対応版で、「こいつで決まり」って感じのやつある？

VisualStudio

>>667
コンパイルすりゃいいだけじゃん。
あるいはttp://gnuwin32.sf.net

むしろ派生スレだな。

>>455
(･∀･)ﾆﾔﾆﾔ

IP記録実験
http://qb.2ch.net/test/read.cgi/accuse/1042013605/

1 名前：ひろゆき ◆3SHRUNYAXA ＠どうやら管理人 ★ 投稿日：03/01/08 17:13 ID:???
そんなわけで、qbサーバでIPの記録実験をはじめましたー。

27 名前：心得をよく読みましょう 投稿日：03/01/08 17:20 ID:yL/kYdMc
SETTING.TXT管轄でないということは全鯖導入を視野に、か？

38 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/08 17:22 ID:rLfxQ17l
>>27
鋭いです。

73 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/08 17:27 ID:rLfxQ17l
＞ところで、IPが抜かれて何か今までと変わることってあるのでしょうか？
・今までより、サーバが重くなる。
・裁判所や警察からの照会があった場合にはIPを提出することがある。

ひろゆき粕汁食うか？

ぴよこがいいぴょ。
ひろゆき居なくなったからニュー速板に帰ります。
ばいばいぴょー！

これも宮崎の圧力な訳だが

Winny掲示板がP2Pだと思ってる香具師はどれくらいいるのだろう？

>>136
かなり無駄な抵抗だけどね。。。

弱虫と優しさの協奏曲。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。





















ガンバレオマエラ

歌広で童貞捨てたのか、、

ワン切りしてみた！！

2chが2chでは無くなるときが来ましたね。
遊び方の解らない馬鹿が増えたから、しかたないのかもしれません。
もう転載しませんので、以後は該当のスレ追っかけてください



27 名前：心得をよく読みましょう 投稿日：03/01/08 17:20 ID:yL/kYdMc
SETTING.TXT管轄でないということは全鯖導入を視野に、か？

38 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/08 17:22 ID:rLfxQ17l
>>27
鋭いです。

73 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/08 17:27 ID:rLfxQ17l
＞ところで、IPが抜かれて何か今までと変わることってあるのでしょうか？
・今までより、サーバが重くなる。
・裁判所や警察からの照会があった場合にはIPを提出することがある。

こんなところでしょうか。

>>944 本音を公に開陳した人間に対する風当たりの強さも、
日本人ならではのものがありますよね。

２ｃｈに書き込んだときのＩＰがわかったとして、そのときそのＩＰを使っていたのは誰かというのは
プロバじゃないとわからないよね

ここは★付きできつねさんを罵倒しろとおっしゃる方が棲む所ですね

復帰作業ほぼ自動化したのにあと５０年復帰人やるのかと小（以下略

役に立たんすれだ

２ちゃんねるは本当に匿名なの？
http://www.2ch.net/guide/faq.html#A4

直しておかないと。。

２ｃｈ運営スタッフはどういうつもりなのかは知らないが、
ＩＰ抜き取りって、不正アクセスにならないのか？

場所によるよね。


匿名重視の板では厨房どころか普通の客まで帰っちゃうという罠。
実況なんかだと逆に非常に便利(荒らしの特定)だろうけど。

新しいテーマをだして書き込み募集したいんですけどどうしたらいいの？

>>688
そんなわけないでしょ。IPアドレスを取らない方が異常。

だいたいIPアドレスを「抜き取」るわけじゃない。
掲示板の利用者は自ら情報を撒き散らしている。
それは、名刺を配り歩いているようなものだ。IPアドレス記録というのはつまり、
いままでは名刺を破り捨てていましたが、これからは保管しますよということだ。

そこらじゅうにコピペしてる香具師は何者？激しくウザいのだが

人の推測が入っても良いなら可能だね。100%ではないけど。
計算ですべて逆算するのは不可能。

======2==C==H======================================================

　　　　　　　　　２ちゃんねるのお勧めな話題と
　　　　　ネットでの面白い出来事を配送したいと思ってます。。。

===============================読者数： 139038人　発行日：2003/1/10

なにやら、連日メルマガだしてるひろゆきです。

そんなわけで、ログ記録実験ですが、いちいちサーバ指定するのが面倒なので、
全部のサーバに入れてみました。

重くなって落ちたりしてもご愛嬌ってことで。。。

んじゃ！

────────────────────────Age2ch─
■この書き込みは、Age2chを使って配信されています。
────────────────────────────
Keep your thread alive !
http://pc3.2ch.net/test/read.cgi/software/1041952901/l50
────────────────────────────

IPってなに？

どうしたらこいつのキャップ取ることができるのですか？
こいつにキャップ授受した糞も一緒に解雇してください。

はいはい　そうね　IP取得始まると得意そうにこう言う輩が増える
だから嫌なんだよな　はぁ　ひろゆきよこんなんでいいのか？

(^^)

Yahoo! JAPAN コンピュータニュース - 1月9日(木)19時43分
　2chでIP記録実験が始まる
　　http://headlines.yahoo.co.jp/hl?a=20030109-00000021-zdn-sci

ZDNet News - 2chでIP記録実験が始まる
　http://www.zdnet.co.jp/news/0301/09/njbt_07.html

　ネット掲示板「2ちゃんねる」管理人のひろゆき氏は1月9日、掲示板に書き込んだ
ユーザーのIPを記録する実験を始めたことを明らかにした。
　ひろゆき氏が発行するメールマガジンで明らかにした。各掲示板の最下部の日付が
「2ちゃんねる20030107」以降のものはアクセスログの記録を実験しているという。
　ひろゆき氏は2002年末、都内の動物病院が同掲示板への発言の削除を求めた裁判の
控訴審で敗訴したのを受け、IP記録の開始を示唆していた。（ZDNet）

（笑）つっかかりますね。
だから、少しでもお安く済むかもしれない方法を
ない知恵を絞って進言申し上げました。

おれのｲｽﾞﾋﾟﾝ記録すんなや

メロパンナというのは気合いはいってるな！！IPとることにしたのにソンゴクウと同じことしてやがる。俺なんかマンコとかくだけで全エネルギー使い果たすほど緊張してるつてのによ

遅いよ…

の通りなら２個までは個人攻撃、誹謗中傷の安全圏なわけだ


バスケかよ

それは単に業者への制裁措置じゃ？

通ることもあるわな。

「見なかった」といわれて終わるのは証明の問題であって実体の問題ではない。

あった

（＾＾）

（＾＾）

色分けも激しく重要だと思う。

unsigned int の int を省略して、 unsigned と書くのは、
見た目効率的にイイ？イクナイ？

最初に自分がわかりやすいマクロ定義をしたヘッダファイルをつくってしまうことだよ。

#define interface struct
#define DECLARE_INTERFACE_(iface,baseiface) interface iface:public baseiface

みたいにね。
こうするととても読みやすくなってまごつくことがなくなるよ。ヌヒよ。

>>713
おひさしぶひです、沢村さん( ´∀｀)

>>712
俺は気にしないが。

ただビット幅を明示したい時には uint32_t とか使うけど。

数行のコメントは

/*------コメント----
------------------
-----------------*/

じゃ無くて、

/*-----コメント-----*/
/*-----コメント-----*/
/*-----コメント-----*/

こうすれば分かりやすいからこう書いてる。

>>716
エディタで色づけしてれば前者でも見落とす可能性ゼロだと思うが、どうだろう？
俺は後者だと編集しづらい (書き換えた時に右の */ の位置を合わせるのが面倒)
だから

/*
*
*/

形式を使ってる。

>>716ﾚｽｻﾝｸｽ。
ああ、そういう書き方もあるなぁ。
俺、昔っから>>716の書き方一筋だから気付かなかった。
やっぱり慣れだなぁ。

色分け機能がなけりゃ俺はそのエディタはエディタじゃないと思う。