コーディング規約

# クラス名・変数名に迷ったら書き込むスレ。Part2
# http://pc2.2ch.net/test/read.cgi/tech/1058213523/l50 からきました。

>>迷ったら駆け込むスレの185
>「クラス名・変数名」と「大文字小文字」は無関係だと思う・・・んだけどどうよ？
極端な例だと GetFileName と get_file_name なんかは大文字小文字を越えてなんか入っちゃったりするわけじゃん。
っていうか get_file_name って書く人は少なくて file_name_get とか単語の順番まで違っちゃうというか。
単語の順番が変わると使われてくる単語も自動的に変わってくるから、やっぱり命名と命名規約は表裏一体だと思うがどうよ？

> getHogeとGetHogeは機能が違うんだったら、caseに依存するのは命名がおかしい。
これは説明不足っつーか、本当に同じ名前でキャピタライズで解決するわけじゃなくて
アクセサ getFoo アクセサではないメソッド GetBaz みたいな。
というか Get はあまりないかもしれない。アクセサじゃないんだけど SetXXX っていう名前が自然な場合に
何度かぶち当たった事があって(どんな時だったかは覚えてない、スマソ)
それから使い分けてる。職場はアクセサも GetHoge/SetHoge なんで、そういう所でアクセサじゃないメソッドで
SetXXX って使いたくなると非常に困ってまわりくどくて長い名前とかになっちゃったりする。

対抗俺ルール

代入演算子、長い式中の論理・加減算演算子の前後に空白。
単項演算子と被演算子の間は空けない。
_T以外の引数がvoidでも空で無いマクロおよび関数の引数リストの左括弧の右に空白をあける。
同じく右括弧の左に空白をあける。
カンマの右に空白を開ける。
制御構文用予約語と括弧の間をあける。
関数名と括弧の間は空けない。
if文、while文、for文の実行文は条件分も含めて一行で収まる場合は単文とする。


複雑だな俺・・・

＞ getHogeとGetHogeは機能が違うんだったら、caseに依存するのは命名がおかしい。
といちゃもんつけた者です。

>>24
＞これは説明不足っつーか、本当に同じ名前でキャピタライズで解決するわけじゃなくて
＞アクセサ getFoo アクセサではないメソッド GetBaz みたいな。
なるほど。そういう意味ですか。
でもそうなると大文字で始まるメソッドと小文字で始まるメソッドが混在するんですよね？
やっぱりおかしい気がする。
具体的にどういうメソッドなのか示してくれると何か納得する糸口がつかめるかも。

すまん。
＞「クラス名・変数名」と「大文字小文字」は無関係だと思う・・・んだけどどうよ？
このいちゃもんも俺だった罠ｗ

>>24
＞極端な例だと GetFileName と get_file_name なんかは大文字小文字を越えてなんか入っちゃったりするわけじゃん。
＞っていうか get_file_name って書く人は少なくて file_name_get とか単語の順番まで違っちゃうというか。
＞単語の順番が変わると使われてくる単語も自動的に変わってくるから、やっぱり命名と命名規約は表裏一体だと思うがどうよ？
うーん。。。俺が前提としていたのは「GetFileName と get_file_name」じゃなくて「GetFileName と getFileName」なんだが。
それでも同じ理論が展開できるかい？

>>22
全て俺と同じだ。

>>26-27
>でもそうなると大文字で始まるメソッドと小文字で始まるメソッドが混在するんですよね？
漏れの頭ん中では
get/set -> アクセサ(カプセル化の為に関数の形をとってる)
それ以外 -> メソッド(動作)
という事になってる。意味が完全に違うわけっす。

>「GetFileName と get_file_name」じゃなくて「GetFileName と getFileName」なんだが。
純粋にキャピタライズだけの問題だったらいいんだけど、ついこの間 C しかしらん人に
C++ を覚える上でのアドバイスを求められて、その人のソースをみたらさ、
本当に msg_wt(void) (おそらく今風に言うとWaitForMessage()) とかそんな名前のつけかたなわけよ。
ああ、こりゃ本格的に文化が違うなと思った。
語順、単語の選び方、省略すべき単語の基準などなど。

で、C でも C++ でも Java でも C# でも msg_wt っていう関数(メソッド)名は
言語の仕様的には問題ないわけで、やっぱりそういう流派もあるって認めないと
「どの単語がいいですか？」っていう相談は、した方も求めていたものが出てこなくて、
された方もせっかく教えてあげたのに「あわねえ」の一言で無視されちゃって
お互いに不利益だなと思うわけだがどう？

>>22 >>28
よく見たら漏れもまったく同じだ。

で、ここまで同じだと気になるのはカーリーブラケットの位置なんだけど
漏れは
if (hoge == NULL)
{
　Foo();
}
派なんだけど、やっぱり K&R 派の方が多いんだろうか？

>>30
if (hoge == NULL) {
　　Foo();
}

だな。

-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

第6条 ちゃんとJavadocコメント入れること！

if (...) {
    ...
} else {
    ...
}
にしてくれ・・・

GNU Coding Standardは激しくきもい

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

ttp://www.linux.or.jp/JF/JFdocs/kernel-docs-2.2/CodingStyle.html

こっちも貼っとこう。
ttp://www.sra.co.jp/public/sra/product/wingnut/standards/standards-ja_5.html#SEC22

>>29
＞get/set -> アクセサ(カプセル化の為に関数の形をとってる)
＞それ以外 -> メソッド(動作)
OKっす。かなり納得しました。C++にもプロパティ（言語仕様じゃなくてもいいから
広く一般に使われるようなやつ）が欲しいところですね。

＞msg_wt(void)
（wait_msgじゃないのかなあ）
んー。良く分からないのでノーコメントで。


１．
if (hoge == NULL)
{
　Foo();
}
２．
if (hoge == NULL) {
　　Foo();
}

これって１．派の意見ではブロックの開始が分かるからとか良く聞くけど
２．でもインデントがあるんだから開始は分かるんだよなあ。
それなら俺はぱっと１画面を見ても流れが読める２．の方が良いな。

if(...) // ここに判定についてのコメント
{// ここに真だった場合の処理を総括するコメント

ってかんじで使ってる。（コメント書かない場合が多いけどね）

変更履歴を残すっていう規約はどうよ?
// やら /* */ やら #if 0 で囲われた大昔のコードの残骸の中に
今生きているコードがちょっとだけ。
おまけに、変更したやつの名前と日付、
// ここから修正
// ここまで修正
とか。
そのくせ、なぜ修正したか理由が書いてない。

板違いか。。。

>>39 http://pc2.2ch.net/test/read.cgi/tech/1030563262/l50

if(foo){
}
else{
// } と else は別の行に書く
}

>>37
>＞msg_wt(void)
>（wait_msgじゃないのかなあ）
>んー。良く分からないのでノーコメントで。
なぜ msg_wt なのかは私にも完全には理解できないのですが
Message -> msg (この省略は個人的には許容範囲)
Wait -> wt (許容範囲外。コンテクストがあってかろうじて理解できる最低レベル)
で、名詞 + 動詞 のルールらしく、そこに大文字混ぜない→区切りはアンスコの結果
msg_wt となるみたい。C な人には多いのかも。

>これって１．派の意見ではブロックの開始が分かるからとか良く聞くけど
>２．でもインデントがあるんだから開始は分かるんだよなあ。
うまく言葉にはできないんですが、ブロックの明瞭さが断然違うんですよ。
視界の隅っこの方までブロックの構造を無意識に理解してるというか。
実際、画面上にたくさん情報量があっても、一度に利用できなければ目をキョロキョロさせるしかないわけで、
それなら多少一画面の情報量が減っても、ありったけの情報を把握しておける方が
結果的に利用している情報量多いんではないかと。

>>39
すでに書かれてるけど、やっぱりすでにバージョン管理システムの仕事なので
必要以上にソース汚すなって事で。
でもある人が保守管理バッチリやってるソースのほんの数行を書き換えた時に
「ここ書き換えたの俺っす。」って書くくらいはいいかなとも思う。
コードよりコメントのが多くなったら完全にアカンと思うね。

（＾＾）

>>42
> Wait -> wt (許容範囲外。コンテクストがあってかろうじて理解できる最低レベル)

こんなの普通しない。

> で、名詞 + 動詞 のルールらしく、そこに大文字混ぜない→区切りはアンスコの結果

msg関係の関数群があれば、msg_をprefixとする場合もあるが。

> msg_wt となるみたい。C な人には多いのかも。

ここまで変なのは多くねーよ。

> 「ここ書き換えたの俺っす。」って書くくらいはいいかなとも思う。
バージョン管理システムの仕事。

>> 「ここ書き換えたの俺っす。」って書くくらいはいいかなとも思う。
>バージョン管理システムの仕事。
本当にバージョン管理システム使ってる？
#ある人が保守管理バッチリやってるソースの ほんの数行を書き換えた時に
だよ？
はじめからみんなが引っ掻き回してるソースならともかく、そうじゃなければ
いちいちコミット状況調べない(調べてらんない)っしょ。
そんな状況で他人にミス入りのコードコミットされて、特に目印もなければメイワクセンバンでござるよ？

> msg_wt
なんか、わかる。
wait → wt なんかは機械系に多いかも…。open → o 、close → c とか。

自分は単語の省略は痛い目にあった事があり以後
(元から略語で通用しているものを除き)絶対にやらないと誓った
しかし、面倒故、ローカル変数だけは折れて一文字変数名使いまくってるダメな自分

>>45
> 本当にバージョン管理システム使ってる？
CVS使ってる。

> そんな状況で他人にミス入りのコードコミットされて、特に目印もなければメイワクセンバンでござるよ？
だからこそのCVS。

＞はじめからみんなが引っ掻き回してるソースならともかく、そうじゃなければ
＞いちいちコミット状況調べない(調べてらんない)っしょ。

cvs annotate で一発で分かるよ

>>48
あ、>>24=45はバージョン管理システム知らないのか。
不思議なこという香具師だと思った。

使ったこと無いのにコミットという用語は知ってるのか。ややこしい奴だな。
CVSを勉強中なのだろうか。
VSSならC/I、C/Oだろうし。

他人が作ったソースを見るときは、revision1.1 と HEAD を cvs diff する。
それだけでだいたいの意図はわかる。

結局俺が「クラス名・変数名に迷ったら書き込むスレ。Part2」で言いたかったことは、
例えば「メッセージを待つ関数名はどうすればいいでしょう」と質問があったとして、
それに対する回答が「WaitMessage」だった場合、
Javaな人はwaitMessage
C++/C#な人はWaitMessage
Cな人はwait_message

みたいな感じでアレンジするだろうから、「クラス名・変数名」と「大文字・小文字」とは無関係と言ったのよ。
それをmsg_wtみたいな特殊な例を出すからややこしくなる。

>>52は>>42へのレスね。
あと、
＞うまく言葉にはできないんですが、ブロックの明瞭さが断然違うんですよ。
断然というほど違わない。ちゃんとインデントしてあるならどちらも全く変わらない。

＞視界の隅っこの方までブロックの構造を無意識に理解してるというか。
ﾊｧ?ちゃんとレス嫁。
ブロックの開始を探すのに"{"を見てるわけじゃない。
インデントレベルでブロックの開始が分かると言ってる。


＞実際、画面上にたくさん情報量があっても、一度に利用できなければ目をキョロキョロさせるしかないわけで、
さっぱり意味が分からん。

＞それなら多少一画面の情報量が減っても、ありったけの情報を把握しておける方が
＞結果的に利用している情報量多いんではないかと。
「一画面の情報量が減っ」たら「利用している情報量」は減るだろ。


間を詰めるのが良いと言ってるわけじゃないけども、
無駄に間をあけると流れがつかみにくい。

if (p) {
　　処理A
} else {
　　処理B
}
----------------
if (p)
{
　　処理A
}
else
{
　　処理B
}

この両者だけを比べるとどちらも大して変わらないが、
一画面をぱっと見たときに流れを理解しやすいのは前者。

IF 条件 THEN BEGIN
　　処理A
END ELSE BEGIN
　　処理B
END

はOKですか？

>>29
>get/set -> アクセサ(カプセル化の為に関数の形をとってる)
>それ以外 -> メソッド(動作)
>という事になってる。意味が完全に違うわけっす。

アクセサを特別扱いする意味がわからない。

・getHoge() だと内部で保持されている値を返す
・GetHoge() だとフィールドに関係ない何らかの値を返す

と使い分けてるようだが、外側から見たとき、返ってきた値が
「実際に内部で保持されているかどうか」なんて関係ないだろ？
それがオブジェクト指向でいうカプセル化なんだから。

例えばあるクラスで
int hoge = 1;
int getHoge() { return hoge; }
int GetFuga() { return 2; }
となっていたとして、hoge は内部に実際にあるけど fuga はないということが
外部からわかることがどれだけ重要なのか？

>>55
> END ELSE BEGIN
これは少々ウザいな。

やっぱ elsif だな

> if (p) {
↑このスタイルの人は条件式が複数行に渡るほど長くなったときにどうするんですか？

if (a_long_long_named_predicator(a,b,c,d,e) &&
　　another_long_long_named_predicator(f,g,h,i,j) &&
　　one_more_long_long_named_predicator(k,l,m,n,o)) {
　　a_long_long_named_function(x,y,z);
}
こんなかんじ？

if 条件　then
　・・・
else
　・・・
end if

if (a_long_long_named_predicator(a, b, c, d, e)
    && another_long_long_named_predicator(f, g, h, i, j)
    && one_more_long_long_named_predicator(k, l, m, n, o)) {
    a_long_long_named_function(x,y,z);
}
こんな感じ

>>59
条件式を関数/メソッドに置き換えて、引数は構造体/メンバ変数にできないかを検討。

if (a_long_long_named_predicator(a, b, c, d, e)
　　&& another_long_long_named_predicator(f, g, h, i, j)
　　&& one_more_long_long_named_predicator(k, l, m, n, o)) {
　a_long_long_named_function(x,y,z);
}
こんな感じ

>>59が言いたいのはそういうことではないと思われ。

>>62に対するレスね。

>>63
微妙にずらすの止めれ。
インデントにタブと半角スペース混ぜるのﾊﾝﾀｰｲ。

>>63
if ( a_long_long_named_predicator(a, b, c, d, e)
　　&& another_long_long_named_predicator(f, g, h, i, j)
　　&& one_more_long_long_named_predicator(k, l, m, n, o))
{
　a_long_long_named_function(x,y,z);
}

俺はこう。普段は、

if( hoge) {
;
}
な人だけれども、ifの評価式が複数行になる時だけ中括弧を次の行の頭に置く。
こうすると、評価とその処理がはっきりと分かれて見やすい気がする。

>>48
#ある人が保守管理バッチリやってるソースの ほんの数行を書き換えた時に
って書いてあるの読めない？って書いてもわからなさそうだから例を書いてあげると。
・プロジェクト中には1000を越えるファイルがあります。
・あなた以外の人が滅多にさわらないファイルが40〜50くらいあります。
・ある日、新人のA君が、あなた以外滅多にさわらないファイルに変更を加えました。
・あなたは、ファイルに変更が加えられた事はアップデート時に気づきましたが、
　現在作業中の部分は関係ない部分だったので、大丈夫っぽい事だけ確認してそのままにしておきました。
・数ヵ月後(はい、ここ重要)、別のプログラマ(A君の教育係りでもある)が真っ赤な顔で怒りながらあなたの所へ来ました。
「てめえの担当部分にバグがあるじゃねえか！ふざけんな！」
あなたはとっさにソースを開き、確かに自分の担当部分である為、謝りました。
・修正しながら、「俺、なんでこんな凡ミスしてんだろ…」あなたはとても鬱な気分になりました。
・プロジェクトも無事終了し、打ち上げの２次会は、重大なバグを出して完成を遅らせたあなたがおごる事になりました。
・打ち上げの次の日、やっと余裕のできたあなたは CVS でバージョン間の diff を見ながら、
「いやあ、今回も仕様変更多かったなぁ、それにしてもこんな仕様変更に柔軟に対応できるのは俺の腕っ節の良さだよな」と悦に入っていました。
しかし、そこで見なければ良いものを見てしまったのです。
「あのバグ、俺が仕込んだ物じゃねーじゃねーか！」
そう、打ち上げの２次会をおごらなければいけなかったのは、A君の教育係の彼なのでした。

で、ここまで読んだあんたは
「だから、そういう時こそログ見て変更を確認するんだろ」
と思ってるはずです、そうですね？そうですね？
しかし、本当にあなたはそれをしますか？

#ある人が保守管理バッチリやってるソースの ほんの数行を書き換えた時に

自分しかいじらないはずだと思い込んでるソースのログを本当に確認しますか？
プロジェクト中あなたは忙殺されており、自分しかいじらないソースを
新人君がほんの数行書き換えた事など、数日あれば忘れてしまうのです。
もちろんそれは忘れてしまった人間の責任なのですが、
事実上、だれかが所有権を持っているファイルに気づかない程度の変更を加えたときに
「ここ、書き換えたよ」とすぐにわかるように書いておいてあげる事が
本当に悪だと言い切れるでしょうか？
すべてがすべてバージョン管理システムの仕事としてしまうのは
「融通の利かない完璧主義者」のやり方だとは思いませんか？

>>69
知らない間に他人が更新したらcommitしようとしたときにすぐわかるはずだが。
あと更新通知メール送信も使うと便利

>・あなたは、ファイルに変更が加えられた事はアップデート時に気づきましたが、
>　現在作業中の部分は関係ない部分だったので、大丈夫っぽい事だけ確認してそのままにしておきました。
結局、ここが問題な感じ

> 自分しかいじらないはずだと思い込んでるソースのログを本当に確認しますか？
そう思ってるソースがupdateで変更されてたらログと差分を完全に確認するべき。
それをしない奴なら、ソースだろうとメールだろうと口頭だろうと、どう伝えても同じこと。

長文レスいくつもスマソです。
>>52
そのレベルの話なら、たしかにそう。
ただ漏れが >>24 で書いた
# っていうか get_file_name って書く人は少なくて file_name_get とか単語の順番まで違っちゃうというか。
# 単語の順番が変わると使われてくる単語も自動的に変わってくるから、やっぱり命名と命名規約は表裏一体だと思うがどうよ？
についてはどう考える？

>>53
>＞うまく言葉にはできないんですが、ブロックの明瞭さが断然違うんですよ。
>断然というほど違わない。ちゃんとインデントしてあるならどちらも全く変わらない。
違わないと思ってるのは、 if (...) { スタイルを使っているから。
次の行に書くようにして一ヶ月もすれば違いがわかる。
(仕事でやっていて周りが同じ行に書くスタイルの場合は一ヶ月じゃ無理かも、漏れは学生の頃に
ほとんど自分のソースばっかり見ている時期に同じ行に続けて書くスタイルから次の行に書くスタイルに変更したから
ほんの1, 2週間でもう戻れない体になってしまったけど。)

>＞視界の隅っこの方までブロックの構造を無意識に理解してるというか。
>ﾊｧ?ちゃんとレス嫁。
>ブロックの開始を探すのに"{"を見てるわけじゃない。
>インデントレベルでブロックの開始が分かると言ってる。
優れた図形認識感覚をお持ちのようなのでうらやましい限りなのですが、
単にインデントの深さだけよりも {} の対応の方がずっと強くブロックが明示されているという事です。
もっというと、わかればいいのではなく、わかりやすくなければいけないという事です。
(わかればいいだけなら 「あいまいな else」のような状態でも、規格上はちゃんと一意に決定できるようになっているわけで)

>＞それなら多少一画面の情報量が減っても、ありったけの情報を把握しておける方が
>＞結果的に利用している情報量多いんではないかと。
>「一画面の情報量が減っ」たら「利用している情報量」は減るだろ。
食べきれないほど食べ物があっても、放っておいたら腐らせるだけですよ。

>>56
>>get/set -> アクセサ(カプセル化の為に関数の形をとってる)
>>それ以外 -> メソッド(動作)
>>という事になってる。意味が完全に違うわけっす。
>アクセサを特別扱いする意味がわからない。

アクセサは >>37 さんも書いてるけど、プロパティの代わりなわけです。
関数の形をとってる事自体が本当は意味的にちょっと違うというか。しかたがなくというか。


>・getHoge() だと内部で保持されている値を返す
>・GetHoge() だとフィールドに関係ない何らかの値を返す
>と使い分けてるようだが、
>外側から見たとき、返ってきた値が
>「実際に内部で保持されているかどうか」なんて関係ないだろ？
>それがオブジェクト指向でいうカプセル化なんだから。
ごめん >>24 参照して。GetXXX はあんまりないかも
で、誤読してる。SetXXX っていう「動作(メソッド)」がある場合があるのさ。
それは「値の設定(プロパティアクセス)」っていう意味じゃなくて、「動作」なの。わかってもらえる？

　　　　　 　 　 　 　 　 　 　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　 　∧ ∧　　　＜　みんな>>1さんにﾆﾔﾆﾔしる。
　　　　　　　(・∀・)　 　 　 ＼＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　 　　＿（つ__つ＿∬＿　　∧∧
　　　 ∧∧　　　∬ 　 目∬＼(・∀・)　ﾆﾔﾆﾔ
　　　(・∀・)＼　目　　　　目　＼　ヽ　　
　　　./　　|＼ ＼　 　 　　　 　　 ＼ ）〜
　〜（＿＿）　 ＼|￣￣￣￣￣￣￣|
　　　　　 　 　　　|￣|￣￣￣￣|￣|　
　　　∧　　 　　　 ￣　　　　 　　￣(・∀・)ﾆﾔﾆﾔ
　 ／　 ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　 |うざいからマ板いけ ﾆﾔﾆﾔ
　 ＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

>>75
うぜー
凄いうぜー
VBの変数の付け方くらいうぜー

>>70
もう一度 >>68-69 を穴があくほどよく読んでください。

>>71
確かにそうなんだけど、人間って完璧じゃないじゃん？
バグって例外的状況に潜むでしょ？
にも関わらず普段通りの状況で正しく動くだけで安心しちゃう事は結構多いはずなんだよね。
とか書くとユニットテストな方々が大量にやってくる気がするんだけど、
ユニットテストじゃ洗い出しにくいタイプのバグも多そうだしなぁ。
(恥ずかしながらXP手法はまだ使った事ないので想像なのですが)

>>72
でもその中でいちばんマシなのがソースだと思いませんか？



長かった。なんで２ちゃんのレス付けでこんな頑張ってんだ漏れは。

> でもその中でいちばんマシなのがソースだと思いませんか？
思いません。
"A source file's primary role is as documentation of the current state of the project."

ソースがいちばんマシだと思う理由を挙げてみな。

C言語とかでオブジェクト試行的な考え方をしてるときは、名詞が先に来るんじゃないの？
C++におけるmessage::wait();のかわりに、msg_wt();ということで。

アンダーバーを用いてネームスペースを構築してると考えれば、
むしろ好ましい習慣ではないかと思いますがどうよ

>>74
Get/Setで始まるプロパティでないメソッドって何かあるか？

MFCにはGetNextとか言う列挙メソッドもあるが、これは名前のつけ方を激しく間違ってるだけだし。

Messageクラスのメソッドにwait()があるならな。

おれは、そんな設計はしないが。

>>77
ユニットテストな方々というか、テストファーストな者ですが。

バグの修正のときに対応するテストを追加する手順を
守っていれば、バグの再発は確実に予防できるよ。
予見は確かに難しい場合もあるけど、テストなしに比べれば
遥かにマシ。

>>78
>ソースがいちばんマシだと思う理由を挙げてみな。
・時間を越えて伝達可能(メールや口頭では時間軸中のある１点のみ)
つまり、プログラマが一年中見てるのはソースだから。
口頭で伝えられた事なんて忘れちゃうしメモしてたってメモの存在を忘れちゃうし
メールなんて何か特別な事態が起こらなければわざわざ何度も読み返さない。
ソースは作業が必要な時はいつでも目にするし、何度も目にする。

>>79
このスレでまだ誰も 名詞 + 動詞 で名前を構成する事に対して批難している人はいないと思いますがどうでしょう？
シャドウボクシングが何かですか(^^;

>>80
上の方でもすでに書いてるけど、ゴメン、思い出せない。
でも何度かあったのよ。マジで。

>>82
>ユニットテストな方々というか、テストファーストな者ですが。
ｿﾚﾀﾞ! ちょっと間違った。
スレの趣旨からずれちゃうんであんまり突っ込んだ話はアレなんだけど
単純な関数の引数と戻り値レベルのチェックならともかく
UI とか絡んでて時間軸によって組み合わせ大爆発な場合に無力な気がするんですよね。
って業種上そういう部分が多いので、なかなか踏み出せないんですが。
(って言い訳して新しいもの拒絶するようになってきたって事は漏れももう歳なのか…気をつけなきゃ)

> メールなんて何か特別な事態が起こらなければわざわざ何度も読み返さない。

一年中見てるソース中の更新履歴も、
何か特別な事態が起こらなければわざわざ何度も読み返さない
んじゃないの？
目に入るソース毎回読み返すわけでもないだろ？

CVSで履歴管理してるソースに更新履歴なんて、
手で情報の複製してるのがキモくてやってらんないよ。

>>24
>>68-69の最初と最後しか読んでないけど、
>「融通の利かない完璧主義者」のやり方だとは思いませんか？
とか言っておきながら、レアケースを持ち出して１つの事に固執する、
>>24の方が融通が利かない人間に思えてしかたない。

漏れのスタンスとしては、
ソースに変更履歴を残す事には反対しないし、残さない事にも反対しない。
その時々のプロジェクトの規約に従う。

ただ、ここからは主観的な意見だが
ソースに変更履歴を手書きで残す事、そしてそれに頼る事は賛成しかねる。

何故ならば、人間は機械ではないのでイレギュラーを起こす、
例え「ソースに変更履歴を残さなければならない」という規約が在ったとしても、
テンパってる状況では変更履歴を書き忘れることもある、具体的には二徹中の昼下がり午後１５時３０分だ、
更にそれが、プロジェクトや管理手順の全体像が見えていない新人なら尚更だ。
そう言った不確実なモノのに頼るよりは、（ある程度）自動的且つ確実に実行されるであろう、
ソース管理システムに頼る方が現実的で合理的だと思う。

でだ、
>事実上、だれかが所有権を持っているファイルに気づかない程度の変更を加えたときに
>「ここ、書き換えたよ」とすぐにわかるように書いておいてあげる事が
に関して、ソースの一部分に必要最低限度の更新履歴を残すということについては、
ソース主体で管理する漏れにとっては賛成できる。

だが、それはVSSやCVSの機能に在るキーワード置換でソースの先頭に
ヘッダ情報（更新日・リビジョン・編集者）を書き出すようにしていれば解決される問題ではないのか？
それとも、そう言った事ではなく
修正した個所に口頭語のコメントで「修正しましたよ」と手書きしなければいけないのか？

>>84
頼むからちゃんと嫁。
誰が ソースに更新履歴 なんて書いた。

>>85
>具体的には二徹中の昼下がり午後１５時３０分だ、
概ね同意、だが漏れの場合は14:00と20:00が鬼門なわけだが。

>ヘッダ情報（更新日・リビジョン・編集者）を書き出すようにしていれば解決される問題ではないのか？
これは冗長だと思うんだよね。必要だと思った時は調べればいいんだし。
特にヘッダ。たまにいじってないのに勝手にリビジョン番号だけインクリメントされて山ほど再コンパイルかかったりすんの。
(ってこれはバージョン管理システムのバグなんだろうけど)

>修正した個所に口頭語のコメントで「修正しましたよ」と手書きしなければいけないのか？
口頭語じゃなくてもいいけど、これがあると責任明示してていいでしょ？って話っす。

また誤読されるなと思ったんで補足。

結局漏れが言いたいのは
正規の履歴情報は、必要だと思った時はバージョン管理システムの機能使って調べれ、
気づかれなさそうな所で変更加えたときは注意を喚起させるために、ソース中に埋め込めや！

って事なのさ、なんかみんなちゃんと読んでくれてないんだもん。
(って長文なのがイカンのかもね、スマソ。)

>>86
>(ってこれはバージョン管理システムのバグなんだろうけど)
バグじゃないよ(笑)
もしタイムスタンプを変えないような機能をつけることを考えた場合、
バージョン管理システムは対象ファイルの記述言語に関知しないので
それが本当にビルドに影響しないの変更(コメント)なのか判断できない。

ということで再コンパイルを避けたければ、履歴情報でソースを書き換える機能は
使わないのが基本。

>>87
気づかれなさそうか、というのも状況によるし、主観だよなあ。
たとえばそういうコメントが既にとっちらかったソースならば
最早目立たないわけで(笑)

>>24
いや、ほんとにコメントも White space も絶対何も違わないのに
なぜか変更された事になったりしたのよ。というわけで今は悔しいので使ってません。

>>89
>気づかれなさそうか、というのも状況によるし、主観だよなあ。
それはそうなんだけど、上述の通りですよ。
事実上の所有権がありそうな場合ってのは大抵判断できるわけで…。

で、なんか酷く汚れたソースを想定してる？
行を分断するような巨大なコメントとかで溢れかえったソースとかを。
そんなんじゃなくて、
if (hoge != FOO) // 2003-08-02 >>24 マジックナンバーだったのでenum値にしますた
みたいなさりげないやつの事で、「事実上の所有者」が納得したらサクっと削除しちゃってもかまわない程度のを想定してんだけど。

> 「ここ書き換えたの俺っす。」って書く
> 「ここ、書き換えたよ」とすぐにわかるように書いておいてあげる事
↑これを「ソース中の更新履歴」と書いたんだが、どう違うんだ？

> 気づかれなさそうな所で変更加えたときは注意を喚起させるために、ソース中に埋め込めや！
CVS使ってれば「気づかれなさそうな所」なんて発生しない。
差分取れば全部見れるんだから。
あと、注意を喚起しないといけないような変更は元の管理者の同意を取ってからコミットすべし。

>>91
>> 「ここ書き換えたの俺っす。」って書く
>> 「ここ、書き換えたよ」とすぐにわかるように書いておいてあげる事
>↑これを「ソース中の更新履歴」と書いたんだが、どう違うんだ？

ソースの一番上とかで
// 2002-12-25 TAMURA 種別30の取り扱いを変更
// 2002-12-31 NAKAGAWA 種別30の取り扱いをやっぱり戻す
// 2003-01-01 KITAMURA 種別30は種別16に統合
みたいなのを書くわけではないという意味なんだが。

>> 気づかれなさそうな所で変更加えたときは注意を喚起させるために、ソース中に埋め込めや！
>CVS使ってれば「気づかれなさそうな所」なんて発生しない。
>差分取れば全部見れるんだから。
>あと、注意を喚起しないといけないような変更は元の管理者の同意を取ってからコミットすべし。

君、日本語ちゃんと読めてる？何度も同じ事書かないから、俺の書いたのもう一度ちゃんと嫁や。

読点も改行も段落も滅茶苦茶な文を「ちゃんと読め」とは随分偉そうですね。

ほぅ・・・。

> if (hoge != FOO) // 2003-08-02 >>24 マジックナンバーだったのでenum値にしますた
↑これは更新履歴じゃないってわけか。
漏れはこういうのも含めてソース中に更新履歴って書いたんだよ。
ごめんよ。

> 君、日本語ちゃんと読めてる？何度も同じ事書かないから、俺の書いたのもう一度ちゃんと嫁や。
日本語は読めると思ってるけど、あんたの文章をあんたの思ったとおりに
理解して同意する自信はまったく無いよ。
ごめんよ。

>>69
＞自分しかいじらないはず
なんで他の人がCommitできるようにしてるの？使い方が悪いんじゃないか。

>>73
＞# っていうか get_file_name って書く人は少なくて file_name_get とか単語の順番まで違っちゃうというか。
＞# 単語の順番が変わると使われてくる単語も自動的に変わってくるから、やっぱり命名と命名規約は表裏一体だと思うがどうよ？
＞についてはどう考える？
「Get_File_Name って書く人は少なくて File_Name_Get」
単語の順番が変わるのは小文字の場合だけと確信できるのか？
別に大文字でも変える奴は変えるだろ。
あんまり自分を過信してるといかんぞ。

＞なんかみんなちゃんと読んでくれてないんだもん。
論理が破綻してるね。
無理やりこじつけて自分の意見を押し通してるから自己中以外何者でもないよ。

君の真似をして言わせてもらうと、
>> 「ここ書き換えたの俺っす。」って書く
>> 「ここ、書き換えたよ」とすぐにわかるように書いておいてあげる事
変更箇所が100万箇所あったらどうするんだ？

24って、本当は「俺のソースに触るな」なんだろ。

>>93 そんなにちゃんとした文章が読みたいなら文学でも読んでてくだちい
>>94 ttp://dictionary.goo.ne.jp/search.php?MT=%CD%FA%CE%F2&kind=&mode=0&jn.x=30&jn.y=9
>>95 してません。読み方が悪いんじゃないか？
>>96 関係ない話に持っていって論点ずらさないでくれない？
>>97 レアケースな話すんなよ。
>>98 で結論がそれですかおめでてーな

っていうかもうこねーようわぁぁん。みたいなー。

> 関係ない話に持っていって論点ずらさないでくれない？
> レアケースな話すんなよ。
> で結論がそれですかおめでてーな

激しく、　オ　マ　エ　モ　ナ　ー

>>93 そんなにちゃんとした文章が読みたいなら文学でも読んでてくだちい
ちゃんとした文章が書けないなら小学校からやり直してください。

>>94 ttp://dictionary.goo.ne.jp/search.php?MT=%CD%FA%CE%F2&kind=&mode=0&jn.x=30&jn.y=9
意味不明。
> 「ここ書き換えたの俺っす。」って書く
> 「ここ、書き換えたよ」とすぐにわかるように書いておいてあげる事

>>95 してません。読み方が悪いんじゃないか？
>>68->>69を嫁

>>96 関係ない話に持っていって論点ずらさないでくれない？
>>96は「大文字・小文字」と「省略するかしないか」は関係ないって言ってるんだろ。↓嫁
> 別に大文字でも変える奴は変えるだろ。

>>97 レアケースな話すんなよ。
ふーん。
>>44
>> Wait -> wt (許容範囲外。コンテクストがあってかろうじて理解できる最低レベル)
>こんなの普通しない。

>>85
>>「融通の利かない完璧主義者」のやり方だとは思いませんか？
>とか言っておきながら、レアケースを持ち出して１つの事に固執する、
>>>24の方が融通が利かない人間に思えてしかたない。


>>98 で結論がそれですかおめでてーな
> そんな状況で他人にミス入りのコードコミットされて、特に目印もなければメイワクセンバンでござるよ？
> cvs annotate で一発で分かるよ
他人に教えてもらっといて絶対礼を言わない奴っているよな。
プライドだけは一人前。



> っていうかもうこねーようわぁぁん。みたいなー。
>>100に激しく同意しているので、お前は来なくて良い。
まあ沢山釣れて良かったね。お兄さん釣られちゃったよ。

深く考えすぎなんじゃない。
// ここ変更したの〜っす。
みたいなのは気利かしてくれてていいと思うんだけどね。

>>103
それはちょっと話が違うんじゃないかな。
CVSの使い方知らないくせにCVS使えねーとか言ってるから叩かれてるだけなんじゃない。

>>103
CVS使ってればそれも不要。

cvs diff したら
10a10,11
> #if
300a302,303
> #endif
みたいだと激しく萎える。

消すなら、きちんと消せよ。
何を消したんだかわかんねえよ。

>>106
そこで何消したかってのはログに書いてあるんじゃないの？

確かに機械的、無機質的にログが残ってるよりも、
ちょっとコメント入れておいてくれたほうが、コミュニケーション面では良さそうだ。

そういう意味じゃない。
きちんと削除してコミットしてくれれば、
cvs diff するだけで、削除されたコードが表示される。
cvs diff -r1.10 -r1.12
101,104d100
< if (hoge < 0) {
< foo();
< bar();
< }

削除した理由はコミットログに書いておく。

#if 0 だの #endif をいつまでもコードに残しておくなってこと。

確かに#if 0は、あるいはコメントで囲んだ場合もそうだが
いざ復活させようとするときに浦島太郎コードになってるので(笑)
バージョン管理システム使ってるときはばっさり消したほうが
惑わされなくていいな。

これもまたコーディング規約にあってもいいな。

>>109
ってかそれが普通の使い方だろうしな。

最強のコーディング規約を教えてください。

http://homepage.mac.com/hiroyuki44/

http://homepage.mac.com/miku24/

>>112
いまんところ、個人的にはこれが最強。
ttp://groups.yahoo.com/group/boost/files/coding_guidelines.html

>>115
Cで

>>116
Cを使わない。C++を使う。
これ最強。

>>117
ありえねー

コーディングスタイルなんて統一することに意味があるんだよ。
どう統一するかなんて話し合ってる奴はセンスがないと言わざるを得ない。

ム板まで出張かい？＞せんすたん

どう統一するかなんて話し合ってる奴がどこにいるんだ？

>>74=24
>アクセサは >>37 さんも書いてるけど、プロパティの代わりなわけです。
>関数の形をとってる事自体が本当は意味的にちょっと違うというか。しかたがなくというか。

プロパティとメソッドを意味的に区別する理由がわからない。

>ごめん >>24 参照して。GetXXX はあんまりないかも
>で、誤読してる。SetXXX っていう「動作(メソッド)」がある場合があるのさ。
>それは「値の設定(プロパティアクセス)」っていう意味じゃなくて、「動作」なの。わかってもらえる？

動作であろうが何であろうが、SetXXX というメソッド名ということは
XXX を設定している (ように少なくとも外部からは見える) からそういう名前なんだろ？
オブジェクト指向的には「"実際に" xxx を内部で持っているかいないか」は関係ないから
わざわざ区別する理由がわからない。利点を教えてくれ。

>>122
プロパティかどうか分かります。

ただの自己満足です。

大文字、小文字といえば.Netのコントロール名がデフォルトで
textBoxとかpictureBoxとかで微妙なんだけど。

>>124
わざと命名規則を逸脱することでコントロールであることが
一目で分かるようになってるんだよ。
MSの命名規則はもはや神の領域に達してしまったな。

>>125
そんな理由が。コード補完がでなくて何回も打ち直してたよ。
ハンガリアンの次はわかりにくい命名規則か

偉い人にはそれ（命名規約が大事なこと）が分からんのですよ。

>>125
単に、Javaのフィールド名の規約を流用しただけじゃん。MSDNのC#命名規約嫁。

>>122
固着観念から抜け出せなくて新しい物を吸収できないタイプ。

122じゃないけどちょっと。

例えばリストクラスを作るとして、（細かい部分ははしょってるから突っ込むな）
class list {
　　char* str;
int GetLength() {return strlen(this->str);}
}
ってなるじゃん。
で、しばらくたってからmStrの変更回数が少ないことに気付いたとする。
そしたら長さをキャッシュするじゃん。その時に
class list {
　　char* str;
　　int length;
int getLength() {return this->length;}
}
とメソッドの名前が変わってしまうが、これはいかがなものか。

>>130
じゃ、俺も74じゃないけど。
それはどちらもGetLengthでいいんでは？
getLengthの時はsetLengthも存在するとか、そんなもんじゃないかと。

プロパティのread, writeが必ずしもフィールド(メンバ)を参照している必要は無いし。
それこそキャッシュしているかどうかなんてのを隠すためのプロパティ。

>>130
動作とプロパティって言っているのだから
bool SetUp() { return this->Initialize(); } と
void setUp(bool up) { this->up = up; } みたいな事なんだろ。

>132
それだ！

>>132
なるほど。
でも、こういう命名するのは嫌だよね。

>>131
＞それはどちらもGetLengthでいいんでは？
じゃあ聞くが逆の場合はどうなんだ？
プロパティとして扱うならgetLengthになってるはずだろ。
各クラスによってGetLengthとgetLengthが入り混じってることになる。
それはなんともキモイ。

＞getLengthの時はsetLengthも存在するとか、そんなもんじゃないかと。
readonly property(mutable)を忘れるな。

>>129
新しいものを吸収できないタイプでいいからさ、
プロパティとメソッドを区別する意味なり利点なりを教えてくれよ。
スレ違いなところ申しわけないけどさ。
Java に Generics を云々ていうスレでもプロパティプロパティと喚いてる奴がいたけど
結局利点についてはまったく語ってなかったしな。

>>136
$ resouce.dat
bash: resouce.dat: command not found
$ hello.exe
Hello, World.

データとプログラムを区別しない理由を教えてくれ

>>137
実装の詳細だから。

136じゃないが、
>>137
そりゃいいがかりだ。

実装の詳細は分からないんだぜ（分からないようにするのが隠蔽）
>>130と>>135を見ろよ。

大雑把に言えばパーシステントの対象がプロパティ。
setXXX(a); ->シリアライズ -> デシリアライズ -> getXXX() = a
でも、メソッドは動的な操作なので、それそのもはパーシステントとは結びつかない。
#で、これが特に意味を持つのが、IDEでプロパティエディタを実装する時。

(car '(foo bar)) => foo
(car '(car '(foo bar))) => car
なんで、データとプログラムを区別する必要があるんだ?

>>138=>>139
実装の詳細の意味間違ってるよ。
名詞と動詞の違いは詳細なんてレベルじゃなく
根本からの違いだ。

>>139
> 実装の詳細は分からないんだぜ（分からないようにするのが隠蔽）
そりゃ名詞同士、動詞同士の場合の話だ。

>>141
そーあるね、食べるの事するね。眠ることするね。生きるの事するね。
名詞と動詞区別つかない大変ね。あなた頭悪いのことない、わかるね？>>138=>>139
実装の詳細の意味間違ってるよ。
名詞と動詞の違いは詳細なんてレベルじゃなく
根本からの違いだ。

>>139
> 実装の詳細は分からないんだぜ（分からないようにするのが隠蔽）
そりゃ名詞同士、動詞同士の場合の話だ。

>>141
そーあるね、食べるの事するね。眠ることするね。生きるの事するね。
名詞と動詞区別つかない大変ね。あなた頭悪いのことない、わかるね？

>147=137が情報隠蔽というOOの基礎さえ理解することができない爺コボラないし夏廚であることだけはわかった。
それ以外は名詞だ動詞だと理解不能。

>143が情報隠蔽というOOの基礎さえ誤解しているシッタカ君ないしリアル厨房であることだけはわかった。
それ以外は >>147 などという未来人さんを名指ししちゃうおちゃめサン

>>143
追加で教えてあげる。
君その分だと抽象化もうまく出来ないでしょう？
「なんでもやっちゃえインターフェイス」で失敗してるタイプ。

あらゆる物のリゾンデートルを考えなきゃだめだよ。

>>143
ごめん、難しい言葉使っちゃったね。理解できないよね。
「オブジェクトの責任と役割」についてもう一度ちゃんと勉強しよう！
大丈夫、馬鹿でも理解できるから!!

>>137=>>142=>>144=>>145=>>146

　　　　　　　　必　死　だ　な　ｗ


>>143
知障の言うことはあんまり気にすんなよ。
あと俺は>>137じゃないから。一緒にされたらたまらん。

>>147
あらら、反論すらできなかったのね。
メソッドと値を「混同すること」がカプセル化だなんて
堂々と言っちゃうくらいだから無理もないか。

いい？教えておいてあげる。
メソッドで包む事＝カプセル化じゃないんだよ。
メソッドはあくまで「丁度いい仕組み」だっただけなんだよ。わかるかな？
メソッドで包む事＝目的の為の手段なんだよ。
君は手段と目的を取り違えて覚えちゃってるんだよ。

>>148
もう一度スレを読み直した方が良いと思われ。
勘違いしながら熱弁しても無意味。

なるほど、爺コボラのレゾンデートルとは
内部の実装がフィールドとして実体を持つか持たないかという点を
根拠としてメソッド名の大文字／小文字を書き換えることなのか。

無知で悪かったな。 リゾンデートルなんて聞いたことがない。
哲学科くずれのコボラくずれの夏廚か？かわいそうに。

>>150
勘違いしていてスレを読み直した方がいいのは君のようだよ。
僕は優しいからどこを勘違いしているのか指摘してあげよう。

> 内部の実装がフィールドとして実体を持つか持たないかという点を
> 根拠としてメソッド名の大文字／小文字を書き換えることなのか。

これ君ずっと勘違いしているねえ。何度も指摘を受けているのに読んでもいない(まさか日本語読めない？)
新しいものを吸収できないタイプでいいからさ、人に迷惑かけるのはよそうよ(ry

>151
ひとつ聞かせてくれ。
お前のルールでは
struct Point {
double x;
double y;

double getX() const { return x; }
double getY() const { return y; }
double getR() { return sqrt(x*x + y*y); }
double getA() { return atan2(y, x); }
};
では、
getR() か、それとも GetR() か？

>>152
dobule Point::getR() const; だろうね。
理由は
メンバ変数 x と y から一意に求められる上、
処理の負荷も気にならない
ゆえにこれはプロパティと言える。

ほほう。
では、原点に関して対象な点の座標を取得するメソッドだとどうなる？

struct Point {
double x;
double y;

Point getSymmetricPoint() const { return Point(-x, -y); }
};

これも getSymmetricPoint() でOK?

144 ◆O1EofOj10A の理論はこれで破綻したな。


↓【話をそらさずに】反論をどうぞ。>>144

何でもかんでも統一すれば良いとは思わんが、
区別できないものに対して区別しようとするのがそもそもの間違い。

>>154
条件は前回と一緒(メンバ変数 x と y から一意に求められ且処理の負荷も気にならない)
だが、今回はメソッドと考える。
構造体が「点」を表すものであり、「対称な点」というのを「点」の１属性と考えるのは少々強引だからだ
(これが単純な「点」ではなく、もっと原点とか対称といった概念を意識させる物であれば話は別)

しかし、ここで君が欲していた答えは「GetSymmetricPoint()」なわけだが、
僕はそうは答えない、なぜなら自己内ルールのプロパティへのアクセサと紛らわしくなるからだ。
今回はメソッドであるから
Point CalcSymmetricPoint() const;
とでもしようか。

どうだろう、君の勘違いはそろそろ解けてきただろうか？

>>155
反論？そもそも何に対して反論すればいいのかわからんが。
>154 は僕に質問しているだけであって、何か反論すべき理論を披露したようには思えないが。

>>156
区別できない？
無理矢理混同しておいて区別できないとはね。

>>157-158
しばらく運用していてsymmetricの取得がかなり多いことが分かりました。
はいどうぞ。

struct Point {
double x;
double y;
Point symmetric;

const Point& getSymmetricPoint() const { return symmetric; }
const Point& GetSymmetricPoint() const { return symmetric; }
const Point& CalcSymmetricPoint() const { return symmetric; }

};

本質を見失わないようについて来いよ。

要するに俺ルールってわけだ。

プロパティかそうでないかは、俺様ルールに従って決めるだけで、
客観的な尺度というものがない。
俺がプロパティだと思うものはプロパティだから、getXXX()と名前をつけ、
俺がプロパティでないと思うものは getXXX()とは呼ばずにたとえばCalcXXX()と呼ぶ。

ご立派なルールだ。

> しばらく運用していてsymmetricの取得がかなり多いことが分かりました。
なら SymmetricalPoint 構造体にしたら？
struct SymmetricalPoint {
Point points[2];
};
あと 君のコードがC++ ならコンパイルできないだろう。(循環参照を解決できるスマートポインタを使うかい？)
まあはぐらかしたとか言いかねないからお題の通りに答えてあげよう。
たとえキャッシュされていても、「対称な点」を「点」の１属性と考えるのは少々無理があるだろう
僕の答えは
(戻り値は上述の理由で表記不可能) CalcSymmetricPoint() const;
となるね。

> 本質を見失わないようについて来いよ。
最近は「いろいろ教えてくれてありがとう」の事をこう言うのか？


シャワーを浴びてくるのでしばらくレスしないだろうが、さっきみたいに
逃げただのと騒がないでくれよ。

>>160
面白いね君は。
世界で上から１００人のプログラマを集めたとして
この１００人に同じ問題をプログラムさせたら、全員がほぼ同じコードを書くと？
プログラミングに唯一かつ客観的な正解があるとははじめて知ったよ。

ここまで書いておいて何だが、
> 俺がプロパティだと思うものは〜
もう少し客観的なルールを披露したつもりだったが、伝わらなかったようだね。

>>161
うわー。一番やばい回答が返ってきた。

＞なら SymmetricalPoint 構造体にしたら？
何故！？
ただ速度を速くしただけなのに、何故そんなことをせにゃならん？

＞たとえキャッシュされていても、「対称な点」を「点」の１属性と考えるのは少々無理があるだろう
いや、これはわかってるんだけど、>>152がPointでお題を出したからそれに従ったまでだ。
さあ、大詰めですよ。>>130は君理論だとどうなるのかな？

class ListWithLengthMethod {　　←大爆笑
　　char* str;
　　int length;
　　int getLength() {return this->length;}
}

おっと失礼。

class ListWithLengthProperty {　　←大爆笑

だな。この場合は。

更に失礼。レスし忘れてた。
コンパイル通らないのはすまんかったな。JavaとC++がごっちゃになってた。
まあ特に今回の話には関係ないので勘弁な。

>>161
> 逃げただのと騒がないでくれよ。
いつ誰が騒いだんだろう。妄想癖？

>>166
そんなん、2chを見てれば分かる。
早漏の香具師が多いからな。

世間一般で広く行われているコーディング規約ではは俺様ルールと違って、
愚鈍なプログラマでも名前が決められるように、
メソッド名ならば大文字ではじめるというようにシンプルに決めている。

いちいち、これはプロパティだろうかと 144 ◆O1EofOj10A 様に
お伺いを立ててから、getXXX()にしようかそれともCalcXXX()にしようかと
悩まなくてもすむようになっている。

これは、ある種の福音だね。

>>168
コーディング規約は全て144 ◆O1EofOj10A 様（ｗ の頭の中にあるんだろうよ。
人によって解釈があいまいなものを隠せなきゃ規約じゃない。

まぁ自分だけで使う分なら俺様規約でも全くかまわないのだが…

ところで疑問なんだけど、>>144はその規約でチーム開発したことってある？

頭の良い高校生とみた。

比較的賢い金魚とみた。

なぜ８月に入って急に書き込みが増えた？
７月は山崎渉の２件を入れても３件しかなかったのにｗ

>>163(前半)
> うわー。一番やばい回答が返ってきた。
> ＞なら SymmetricalPoint 構造体にしたら？
> 何故！？
> ただ速度を速くしただけなのに、何故そんなことをせにゃならん？
君は墓穴を掘るという言葉を知っているかな？
君の拙い設計をあえて指摘せずによりよい案を出してあげたのに
そんなに君の設計の拙さを指摘して欲しいのかい？
いや、ある意味君はすばらしい生徒なのかもしれないね。
では模範解答だ。

まず君の発言を引用して広い見地から見ていこう。
>>> しばらく運用していてsymmetricの取得がかなり多いことが分かりました。
しばらく運用した結果というのは、運用によって Point を利用するコードが変わったという事だ
その結果キャッシュしなければいけないほど対称な点の取得が多かった
つまり運用後に見えてきた答えによって初期の設計のミスが現れたという事なのだよ。
これは悪い事ばかりではなく、コードをよりよくする動機になる。
そこで僕の実装だ

struct SymmetricalPoint {
　Point points[2];
};

まず大事なのは、僕の案では Point はなお健在であるという事だ。
「対称」が必要の無い場面では Point は Point のままでいい。
「対称」が頻繁に必要になる時にのみ、SymmetricalPoint を利用するのだ。
対して君の拙い案は極めてプリミティヴに近い Point にキャッシュを導入しようとしている。
Point を使うときはいつでもキャッシュの分、追加のリソースを支払わなければならない。
これは再利用への勇気と決意を失わせるに十分なコストだ。

>>163(後半)
あまりにも僕の考えるリストと違ったものなので驚いたが

class JunkString { //あまりにも哀れなので変えたよ
　　char* str;
　　int length;
　　// int getLength() {return strlen(this->str);}
　　int getLength() {return this->length;} // どちらでも変わらないが答えだ
};

>>165
僕はとても嬉しいよ、君にも正直に謝る事ができるんだね。

>>169
自己レスご苦労様。ここでも >>165 が正直だと実感できる。
君は C++ と Java しか知らないんだろう。
C# も Delphi も君がいつも馬鹿にしている VB ですら
言語レベルでプロパティという機能が備わっている。
それとも全世界の C# ユーザと Delphi ユーザーと VB ユーザと
その他の同様の機能を持つ言語のユーザ達が僕の元に
「これはメソッドですか？プロパティですか？」
とお伺いを立てに来てくれるのかな？

ちょっとイジワルな表現をしてみよう。
知　識　の　程　度　が　一　定　だ　か　ら　多　数　の　常　識　派　を　装　っ　て　も　す　ぐ　バ　レ　る　よ。

Pointを例として出したのは、ここの掲示板ではでかいソースが貼れないからだよ。
なんでその先が想像できないのかねぇ。趣味でやってるか、バカかのどっちか（あるいはどっちも）だな。

>>175
>>169 は自己レスじゃないよ。
周りが全部同一人物に見えてるらしいね。
ピンチになると敵を減らしたいからそう思うんだってさ。

------------------------
おい、ふざけてるのか？それとも本気なのか？
class String { // もともとの実装
　　char* str;
　　int GetLength() {return strlen(this->str);}
};
class JunkString { //あまりにも哀れなので変えたよ
　　char* str;
　　int length;
　　int getLength() {return this->length;} // どちらでも変わらないが答えだ
};

たかがLengthメソッドからLengthプロパティに変更しただけで別のクラスを作るのか？本気であほちゃう？
まあ言葉が足りないんだろうと好意的に解釈して、
　　int GetLength() {return strlen(this->str);}
が、
　　int getLength() {return this->length;} // どちらでも変わらないが答えだ
に変わってしまっているぞ。インターフェイス変わってどーすんねん。

ここらで整理しとこうか。

144 ◆O1EofOj10A の主張
・プロパティかメソッドかでインターフェイスを変えるのは必然
・プロパティかメソッドかの判断は各人が行う
・プロパティは小文字から始める。メソッドは大文字から始める。

その他の主張
・プロパティかメソッドかに根本的に違いは無い
　（クライアントの○○が欲しいという要求を処理できればそれでい）
・プロパティかメソッドかの判断は必要ないので
　大文字で始めるか小文字で始めるかはプロジェクトで決める。


こんな感じか？

とりあえずgetとGetで使い分けるのはマズいと。

>>179
いいえ。使い分けるべきです。理由は>>142ですでに述べています。

とレスが来そうな予感

>>180
あれ？>>157の「紛らわしくなるから・・・」ってのが>>144様の見解じゃない？

言い訳ばっかりになってきたようだね。
ピンチになってまともな反論ができなくなるとそうする弱虫がいるんだってさ。

>>176
小学生じゃないんだから、勝負が終わった後に
ルールが悪かったとかゴネるのはやめたまえ。

>>176
> たかがLengthメソッドからLengthプロパティに変更しただけで別のクラスを作るのか？本気であほちゃう？
そう本気で考えちゃうなら君が阿呆なんだろう。
> インターフェイス変わってどーすんねん。
>>130 の後半と >>163 の両方をみてまだそう思うなら、君は頭だけでなく目も悪いようだ。

で、都合の悪い事は流すのかね？
C# と Delphi と VB を使ってる人は僕のところに来てるのかい？

>>180=181
ナイス連携プレイ！まさしく一人であるかのように息がぴったりだよ。

もう少し >>157 を判りやすくかいてあげよう
(メソッドである CalcSymmetricPoint が)自己内ルールのプロパティへのアクセサと紛らわしくなるからだ。

君はあらさがしをしているつもりかもしれないが、一貫した主張であるが故に崩す事は難しいだろう。

144 ◆O1EofOj10A
って Windows板でよく暴れてる人ですか？

>144 = >24 なのか？

>24 = >29 = >30 = >42 = >45 = ... その他いっぱい

一人で大活躍だな。

まともなバージョン管理システムも使ったことがないようだし、
チーム開発できないタイプなんじゃない。

前の方の議論では、俺のソースに触るなという結論じゃなかったっけ。

>144 擁護派って >144 の他にいるのか?

>>185
> まともなバージョン管理システムも使ったことがないようだし、
> チーム開発できないタイプなんじゃない。

ああ、だから「俺規約」を持ち出してきてるわけか。

>>144 を見るにプロパティとメソッドの使い分けには
(とりあえず使う人には) まあなんらかの使い分けがあるんだろうけどさ、
そもそも「何でプロパティを区別するのか」というのはさっぱりわからんのだけど。

>>175 で VB, Del, C# がプロパティをサポートしてるといってるけど
それはあくまで事実であって、理由ではないわな。

>>177
> まあ言葉が足りないんだろうと好意的に解釈して、
> 　　int GetLength() {return strlen(this->str);}
> が、
> 　　int getLength() {return this->length;} // どちらでも変わらないが答えだ
> に変わってしまっているぞ。インターフェイス変わってどーすんねん。

漏れもそうｵﾓﾀが、>>144が何か勘違いしてる様な気が。

釣れた釣れた。今回は大漁だったな。





って言ってもいいよ。 ＞１４４

>>185
>>144 = >24 なのか？
ご名答。これは事実だ。

しかし複数人で5分間隔でレスをしていたのに、突然 22:50 から 23:20 まで
「誰一人」レスを付けなかったのはすごい偶然だね。
理論的に破綻して関係ない話題で吊るし上げる理由を一生懸命探してたわけだ

> 一人で大活躍だな。
何ていうんだったかな？のしをつけてお返ししますというやつかな？

> チーム開発できないタイプなんじゃない。
君みたいな粘着でも見落とす部分があるんだね。

> 前の方の議論では、俺のソースに触るなという結論じゃなかったっけ。
君が、君一人がそう誤解したままなのだよ。

>>144 擁護派って >144 の他にいるのか?
君の擁護派も君達以外いるのかい？

>>187
君は別人か？イマイチ判りづらくてね。
> VB, Del, C# がプロパティをサポートしてるといってるけど
> それはあくまで事実であって、理由ではないわな。
論点がずれているよ。
全世界の C# ユーザと Delphi ユーザーと VB ユーザとその他の同様の機能を持つ言語のユーザ達が
僕の元に「これはメソッドですか？プロパティですか？」とお伺いを立てに来てくれるのかと聞いている。
違うのはわかるだろう？みんな自分でプロパティかメソッドか判断しているんだ。

>>189
大物だが大漁じゃないんでね。

さて、僕はもう眠るよ。明日も暇だったら君の相手をしてあげよう。

>みんな自分でプロパティかメソッドか判断しているんだ。

いや、187 でも書いたようにみんな自分で判断しているのはそれでいいからさ、
それ以前の疑問の「なぜプロパティを使うのか？」を教えてくれ。

でこればっかりだとスレ違いなんで。以下を追加。

>みんな自分でプロパティかメソッドか判断しているんだ。

各自の判断でプロパティかメソッドが揺れるんだったらさ、
プロパティとメソッドでコーディングスタイルを変えるのは
チーム開発する場合はマズイだろ。

144はWindows板のデフラグスレ、田中スレ、その他の板の多くのスレで
中途半端な知識で暴れまくっています。
こまった人です。

getとsetに関してはアクセッサ専用にしてたほうが
無難だと思うが。

何かメール欄で必死に「負けたくない」って主張してるのってカッコワルイよね。
>>144=>>24って分かったんだし、放置でいいのでは？

>>99
> っていうかもうこねーようわぁぁん。みたいなー。

超笑える（ｗ

>>24=>>144ってのを意識して>>24から読み直してみそ。強情ぶりがかなり笑えるから。

元スレ（クラス名・変数名に迷ったら書き込むスレ。Part2）の時から
口調はえらそうなくせに結局レアケースや自己矛盾な話を持ち出してきて一人でもがいてるだけだしな。
勝手に自演扱いにしてるし（まあ２ちゃんだからいいんだろうだけど）
CVS話の時もせっかく使い方教えてもらったのに結局礼も言ってないし（いや、教えたのは俺じゃないが）

「融通の利かない完璧主義者」で「プライドだけは一人前」。

俺は、VBとC#のプロパティはシンタックスシュガーと捕らえている。

text = Widget.getText(); や
Widget.setText(text);

よりも

text = Widget.Text
Widget.Text = text

の方が「わかりやすい」ような気がするし、きっと「読みやすい」んだと思う。

これには功罪あって、「読みやすい｣がために逆にその奥で行われている
複雑な操作を隠蔽するがために、高価な操作をまるで変数に代入するかの
ような気軽さで行ってしまうおそれがある。

OOであることと言語がプロパティという表現形式をサポートしていることは
無関係であると思う。
現に、VC++は _com_ptr_t<> でCOMに対するプロパティをサポートしている。

Windows板が静かになったと思ったら
プログラム板で暴れてたのか。
もうWindows板に帰ってこなくていいです。>>144

またきたのかよ。成長はしなかったようだな。くるなっつったろ馬鹿が。もうくるなよ。>>144

百歩譲って考えれば、１４４はVBやC#のプロパティを小文字のメソッドで
表現することにより、C++でエミュレートしようとしているのだろう。

無 駄 な こ と だ が 。

そうしたからといって、プロパティにおけるシンタックスのような読みやすさが
手に入るわけではない。

C++と限定した理由だが、
Java使いがメソッド名を小文字以外で始めるとしたら、そいつは議論に値しない。
VB,C#,Delphiなどプロパティがサポートされている言語ではget/Getの使い分けをする
意味がない。
Ruby厨もPython厨もPerl厨もPHP厨もこんなことは考えない。
もちろん、SmallTalk使いやCLOS使いなわけもない。

>>175
> 君は C++ と Java しか知らないんだろう。
> C# も Delphi も君がいつも馬鹿にしている VB ですら
確かにLisp,Prolog,Pascal,C,C++,Java,C#,Perl,PHP,sh(bash,csh),N88BASIC(w)あと変なスクリプト言語やSQLぐらいしか知らん。
ｱｾﾝﾌﾞﾘはPC9801で画像処理に使ったぐらいだし、VBに至っては全然知らん。EXCELで1時間程度使ったぐらい。
OSもSolaris5.7〜、Linux2.0〜(RTLinux2.3pre2〜)、Windows95〜、MSDOS3.3D〜辺りの有名どころしか使ったこと無い。
知ってる言語は君より遥かに少ないし、経験も君に比べたら雲泥の差だと思う。
君のような素晴らしいプログラミング能力と素晴らしい設計力を前にしては全然歯が立たないよ。

と言うわけで俺はもう逃げます。はい負け犬です。やっぱり天才>>24=>>144様には勝てないです。

別に厨ではないが Ruby 使いとして。

Ruby ではメソッド名に xxx= というものが使える＆
メソッド呼び出しの括弧が省略できるおかげで aaa.xxx = yyy という式が書ける
(この場合 xxx と = の間にスペースが入っても構文解析上 xxx= と同じように扱われる)。

get_xxx/set_xxx の代わりに xxx/xxx= というメソッド名にすることで
あなたのいうプロパティにおけるシンタックスのような読みやすさが手に入るのだ。

んでは、Delphi使いとして。
引数の無いメソッド呼び出しに括弧がいらないので、
property XXX : Integer read 〜 と function XXX : Integer; は
使う側では共に VARIABLE := OBJ.XXX;
なので、property/functionで迷ったら、とりあえず実装が都合がいい方にしておく。
最初functionにしておいて、後で代入したくなってpropertyにしても何の問題も無い。

あと、propertyは属性&派生属性へのアクセスと解釈してる。
どこまでが派生属性でどこからメソッドになるかは微妙な点も多いが、
上述の通り使う側の構文は同じなので迷ってOK
C#だと同じようにいかないのがちょっとなあ…って思うが。

おまえまじキショい
何で自演してまで俺なんかに突っかかってくるのかと思ったら
Windows 板で虐められた私怨かよ
悪いが俺は Windows 板なんかにゃ行ったことねぇよ
妄想の中のいじめっこと遊んでろや

>>144
宿題はもう終わったのか?
早めに済ませておかないと後がつらいよ。

自演自演って、Windows版で自分の自作自演が指摘されたのがよっぽど悔しかったんだね。
あれからだもんね。他人を自作自演扱いしだしたのは。

俺はプログラミング超初心者で勉強中だからここの会話の中身は訳わかんないから
自作自演したくてもできない。ごめんね。

>>204 は偽物なわけだが、
>>144 が Windows版で暴れてたのは文体とか必死さを見れば明らか。

誰がどう見ても自演なのばらされてるのにしつこいな
知識の程度が一定(バカは隠し切れないかﾌﾟｯ)なのと
わかりやすいくらい自演そのもののレス時間
妙に Windows 板にこだわる
(マ板ならともかくム板の連中はそんなに Windows 板見てねえよ)

http://homepage.mac.com/hiroyuki44/hankaku02.html

>>206
妄想厨は放置しろよ

・文体には気を使っていたが投稿時間でバレるのは気がつかなかった
・窓板住人
・妄想の友達がいっぱい(藁

そんな事より聞いてください
僕 >>206 さんの心の中に住んでいる妖精さんです。
みんな >>206 さんを虐めないで!!
強がっているけど本当はとても弱い人なんです。
煽りもうまくなったけど、>>206 さんがいつも現実世界で
言われている事を２ちゃんねるで書いてみてるだけなんです。
現実世界では >>206 さん誰も友達いないから
２ちゃんねるのみんなまで >>206 さんを虐めたら本当に一人になっちゃう!!
みんながちょっと優しくしてくれれば >>206 さんはそれで満足なんです。
もう >>206 さんには２ちゃんねるしか居場所がないんです。
どうかみなさんよろしくお願いします(ﾍﾟｺﾘ

★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★
☆★☆★☆★　新商品　ゾク・ゾク　入荷　☆★☆★☆
★☆　　　　　　　　　　　　　　　　　　　　　　　
☆★　送料激安！！　　送料激安！！　　送料激安！！
★☆　　　　　　http://www.get-dvd.com　　　　　　
☆★　　激安アダルトＤＶＤショップ　　　　　　　　
★☆　　　　お買い得！！　1枚500円〜　急げ！　　　
☆★　　　　インターネット初！「きたぐに割引」　　
★☆　　　　北海道・東北の皆様は送料も激安！　　　
☆★　　　　　　http://www.get-dvd.com　　　　　　
★☆　　　　　　　　スピード発送！　　　　　　　　
☆★　　　　　　http://www.get-dvd.com　　　　　　
★☆　　　　　　　　商品が豊富！　　　　　　　　　
☆★　　　　　　http://www.get-dvd.com　　　　　　
★☆　　　　　　　　　　　　　　　　　　　　　　　
☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆

妙に自演にこだわってるね（βακα

>>211
面白いなこれ、
新しいコピペ？

＜＜このスレの90%くらいが二人の夏厨の煽りあいで埋め尽くされています。＞＞

>>211=214
(・∀・)ｶｺﾜﾙｲ!!

ｶｺﾜﾙｲ!!は（・Ａ・）だた
欝氏・・・逝ってきます。

Windows版にこだわるっていうか、
> 悪いが俺は Windows 板なんかにゃ行ったことねぇよ
に対する答えだろ

>>24
多分、君はプロパティと、プロパティ取得用メソッドを混同してる。
プロパティというのは取得・設定できるオブジェクトの属性であって、
取得・設定する方法とは何の関係も無い。

文字列の長さというプロパティがあったとして、それを取得する方法が
l = string.Length;
l = string.getLength();
l = strlen( string );
l = string[-1];
のいずれであってもかまわない、これは構文上の違いでしかない。

getLength()は、
長さプロパティを取得するという動作を行うだけの普通のメソッドに過ぎない、
何も特殊なことは無い。
だからそれ以外のメソッドと違う命名規則を当てはめる必要はまったく無い。

たとえば
長さプロパティを取得しようとするけどやっぱり途中でやめちゃうメソッドなんてのを考えてみてくれ、
長さプロパティを取得するメソッドを特別扱いする意味がまったく無いことがわかる。

>>219
> 何も特殊なことは無い。
彼(>>24?)の主張は動作と値という概念の違いがあるから、
プロパティ操作メソッドとその他のメソッドを区別すべきという事みたいだけど。
あなたの主張は動作と値という概念の違いはないという事なの？
それとも動作と値という概念の違いはメソッドの規約として表現してはならないという事？
メソッドの規約として表現してはいけないとしたらそれにはどんな理由があるの？

>>220
値と動作には明確な違いがあるが、
値を取るという動作とそれ以外の動作には何も違いは無いという主張です。

>>221
なるほど。
メソッドは絶対に動作であってそれ以外の物ではないという主張なのね。
相手の主張は C++ でプロパティを表現する為に
便宜的にメソッドを使っている、つまりプロパティの操作は
動作ではないという事みたいだけど
あなたの意見はそうではない、という事でいいのかな？

>>222
221じゃないけどちょっとわかってきた気がする。
たしかに値の操作はOOでいうオブジェクトへの命令とはちょっと違う気がする。
値の操作にアクセッサーメソッドを使うのはカプセル化の為の手段でしかないですね。

>>222
そう。
たとえばNameというプロパティを設定するメソッドは
24的にsetNameでもいいし、ちょっとオシャレにRenameでもいい。

Renameは誰がどう見ても普通のメソッドと変わりないはず。
ならまったく同じ動作をするsetNameも同じメソッドのはず。

>>223
そういう考え方もできますね。
考え方次第ですね。

>>224
あなたの主張では
単純に名前を設定する事も改名しなさいと指示するのとまったく同じで
どちらを使ってもいいから、プロパティの操作はあなたの中ではメソッドだという事なのかな？
つまり同じ動作をする物はどちらを使っても良くて、どちらを使っても同じ？

つまらん

もとからだろ >>226

>>225
あなたのおかげで目が覚めました。
メソッドとプロパティは全然違うものでした。
ありがとうございました。

データを隠蔽してアクセサ等の操作メソッドを持たせたのがデータ抽象化。
アクセサを隠蔽してプロパティにまとめたのがアクセサ抽象化。
よってプロパティの方が偉いのだよ。

>>228
いえ私はあなたを説得したりするつもりはなかったのです。
ただ相手が何を主張しているのかを理解しようと考えてみてほしかっただけです。
相手の主張に同意できたのならきっと私の意図も伝わったのだと思います。

>>229
はつみみです;)

年齢(Age)とか身長(Height)とかいった属性がプロパティだべ。
どう考えてもメソッドじゃないべ。
なのにgetAgeとかgetHeightとメソッドにするのはどう考えてもおかしいべ。
だからAgeとかHeightにするんだけんど。
年齢にはマイナスが入らないとか200歳以上はだめだとか、
身長には1000mは入れられないとか制限をつけただけで
メソッドにしなきゃならないのもおかしいべ。
プロパティってのはやっぱり自然な機能だべ。

このスレはいつからプロパティの必要性を説くスレになったのですか？

>>232
だなあ。
で、実装方法としてはメソッドと変わりないものになったとしても、
やはりプロパティはプロパティなんだよな・・・

UMLなんか設計時点でメソッドとプロパティが存在するしな。
実装がどうなるかなんて関係なく別物として存在するんだよ。

>>232
> なのにgetAgeとかgetHeightとメソッドにするのはどう考えてもおかしいべ。
C++ にも Java にもプロパティ機能がない以上は
メソッドで代用するしかないじゃん。

>>228 乙

>>234
俺の書き込み以降も勘違いしたままのやつがいるのかよ・・・
実装方法がメソッドになるのはアクセサであってプロパティではない。
たとえばLengthというプロパティに対して
getLength メソッドが値の設定
getLength メソッドが値の取得
length_ フィールドが値の保存
を受け持つ（一例）。
どれか一つだけをとってプロパティと呼ぶことは無い。

>>233
>>24がC++で擬似プロパティメソッドとそれ以外のメソッドを区別しる！と書いて
そんなの区別する必要ないって香具師が出てきて、
じゃあプロパティ機能が備わってる言語はどうなんのさってなって
やっぱりプロパティが言語の機能に備わってないと喧嘩の元だねってなったずら。

>>237==221==224==228
なんでいまさらになってレス番を名前に書いたんですか？

>>239
番号書かなきゃ「俺の」が誰かわからないから

>>237
なにを言いたいのかわからん。プロパティを取得するのに
アクセサ方式(クラスの利用者からget,setでアクセスする)でやるのと
プロパティ方式(クラスの利用者から実際はメソッドだが変数のようにアクセスできる)
があってプロパティ方式の方がより自然な感じで利用できるということか？

確かにfoo.lengthの方がfoo.getLength()よりもプロパティって感じがするものなぁ。

ってちょっと待て
228は違うぞ

>>237
アクセサはプロパティの一部のただのメソッドだから他のメソッドと区別してはいけないってか？
理由になってねーじゃん。
プロパティの一構成要素だから他のメソッドと区別するんだって。

>>242
お前は誰だ。

>>241
違う、俺はプロパティアクセスの構文なんかどうでもいい。
なんかずれてきてるように思うが、論点は
プロパティに対する専用の構文の無い言語で、プロパティを取得するためのアクセサメソッドをそれ以外のメソッドと区別する必要があるかどうか。
だ。

まずは「区別」を定義しないとな。

あの、すいません、よくわからないんですけど、
プロパティーって、メンバ変数とかデータメンバとかいうアレですか？

>>245
あるっつってんの。
プロパティの一構成要素だから他のメソッドと区別するんだよ。
区別しなきゃ他のメソッドと紛らわしくなるだろが。
おまえが >>224 で書いたんだろ
> たとえばNameというプロパティを設定するメソッドは
> 24的にsetNameでもいいし、ちょっとオシャレにRenameでもいい。
> Renameは誰がどう見ても普通のメソッドと変わりないはず。
> ならまったく同じ動作をするsetNameも同じメソッドのはず。
こういう紛らわしい真似をしてくれるヤツがでてくんだよ。

http://homepage.mac.com/hiroyuki44/jaz08.html

>>246
区別の例としては
GetName/SetName/Doingが普通のメソッドで
getName/setNameが擬似プロパティという事みたいよ。

白のパンダをどれでも全部並べる歌手です>>247

GetNameやSetNameなんていらんだろ。つーか作るな。
名前ってのは機能を表す。
言語によっては大文字と小文字は区別されるが
同じ単語なんだよ。

メンバ変数をpublicにしる！

>>243
getLength/setLengthが、Lengthというプロパティにアクセスするためのメソッドだから、他と区別するというのならわかるが。
getLength/setLengthが、プロパティにアクセスするためのメソッドだから、他と区別するというのは理解できない。

1行目、つまりあるプロパティの構成要素として他と区別するというのは
243の言っていることとまったく同意だ、反論する気はさらさら無い。
しかしC++にはアクセサがあるプロパティの構成要素であることを示す構文は無い。
アクセサだから異なる命名規則、というのには同意しかねる。
getLengthとsetNameは同じ仲間なのに
getLengthとRecalcLengthは違う仲間だと言う方がどうかしてる。

設定する、取得する。
という二つの動詞だけを、
計算する、変える、戻す、動かす、などの各種動詞と区別しなければならない理由は無いだろ。

主張が意味不明です。もう一度お書き直しください

>GetNameやSetNameなんていらんだろ。つーか作るな。
>名前ってのは機能を表す。

>言語によっては大文字と小文字は区別されるが
>同じ単語なんだよ。
あなたの顧客のMcDonaldさんが僕の名前の３文字目のDは大文字にしてくれと言っても
大文字でも小文字でも同じ単語だから却下するんですね。

>>253
代入や取得のさいに制限が無い場合はそれでもいいが、
後から追加されたときのことを考えると･･･。

やっぱりプロパティがあった方がいいなぁ。

>>250
本当にそんな規約が存在して実際に使われているのか疑わしい。
学生の脳内ルールだろ。それ

>>255
顧客が言うんなら仕方ないと思われ

McDonaldさんとMcdonaldさんがいたら紛らわしいね。

>>255
主張が意味不明です。

あなたはGetNameとgetNameの二つのメソッドがあったとき
違う機能を与えるというのですか？
「名前を取得する」という同じ単語に別の意味を与えると？

今このスレにMethod Oriented Approachの開祖である>>254様が誕生しました。

Person McDonald = new Person();
McDonald = new Person(); // 別人になりますた(｡Ａ ｡　)

お前ら馬鹿すぎ。
俺がルールを決めてやろう。

class Foo
{
private: string name;
public: string Name() { return name; }
public: void Name(string value) { name = value; }
}

いじょ。しゅうりょ

>>257
そうこのスレに書いてあったから例としてあげただけなんですが。

>>263
それはなんと言う言語のソースですか？
少なくともJavaでもC++でもコンパイルできませんが。

>>262
Person person = new Person("McDonald");
person = new Person("McDonald"); // 別人になりますた(｡Ａ ｡　)

だろ？

補足 同姓同名

>>254
矛盾しまくりですね。

そういえばSTLとかまったく区別してないね。

>>268
STL は OO のライブラリではなくてジェネリクスのライブラリだから
OO 的な事は考慮されてないス。

区別している実例が挙らないのはなんでだろ〜?

>>269
なるほど。

>>270
Java 標準規約ではアクセサは get/set ではじめよとなってた気が

プロパティ専用の構文がない言語で、プロパティを実現するときに
メソッドを利用することになるが、それを概念的にはメソッドの集まりとは
言わずにプロパティと呼ぶのじゃ

>>272
それは他と区別してるわけじゃないと思うぞ。
他も小文字から始めるし、get/setは受け取る/設定するに対応する標準的な英単語だし。

putとか使われると一貫性がなくなって困るからじゃね？

javaのアクセッサは get/is/set ではじめるというのが標準規約。
各種ツール・ライブラリがこの規約に依存している。

アクセサに限らず、その他のメソッドも小文字で始めることになっている。

>>274
＞putとか使われると一貫性がなくなって困るからじゃね？
ﾊｧ?それを区別してるって言うんだろうが。

上のほうで言ってる区別ってさ
メソッドを大文字ではじめる規約の中にJavaのゲッターセッターを持っていっただけだよね
別に悪くないと思うけど

>>276
何と何を区別してるんですか？

>>278
そしたら Set Get Is になるんじゃねスか？

>>280
特別だって事をもっと強調したかった。とか。

>>279
バカかおまえ。アクセサとそれ以外をだ。

282は俺だった。

>>282
putではなくsetをつかうとアクセサとそれ以外を区別できるのか？

>>284
おまえ本当のバカか？
別にsetじゃなくてもいいんだよ。
setteiとshutokuでもいいんだ。
一貫して同じ形式のアクセサを使うことに意味があるんじゃねえか。

>>285
そんなんコーディング規約の一般的な性質だろ。
メソッド名の動詞には原型を使う、とか、イベントには過去形を使用しない、とかと同じ類じゃん。
それじゃこいつらは何と区別してるんだよ。

>>132のような状況も考えられるが、どっちも小文字から始まるJavaじゃどうやって区別するんだ？

区別するってのはaはAだ、って言うだけじゃ不完全で、
bはBだ、AとBはこの点で相違がある、だからaとbは区別される。
まで言わなきゃ完全じゃない。

漏れはget，setはアクセッサ専用にとっとく。

>>286
おまえは>>284なのかよ？こんなバカ他にいないだろうし、>>284以外は
俺につっかかる理由がないからそうだと仮定すんぞ。
＞そんなんコーディング規約の一般的な性質だろ。
アクセサを区別しましょうっていう話な時点でコーディング規約の話なんだからあたりまえ
＞それじゃこいつらは何と区別してるんだよ。
アクセサとそれ以外だろ日本語理解できてますか？
＞>>132のような状況も考えられるが、どっちも小文字から始まるJavaじゃどうやって区別するんだ？
アクセサはget/set/isって決めたらそれ以外の目的に同じつけ方しないのは当然だろ？

おまいら、今夜はトリビアがあるから早く帰れよな

>>289
トリビアスレに(・∀・)ｶｴﾚ

> 区別するってのはaはAだ、って言うだけじゃ不完全で、
> bはBだ、AとBはこの点で相違がある、だからaとbは区別される。
> まで言わなきゃ完全じゃない。
妊婦に産道の通り方とか、生まれた直後の鳴き方とか教えてるのと同じ。

>>288
> そんなんコーディング規約の一般的な性質だろ。
その性質はアクセサに限ったものではなく、一般的なコーディング規約に共通する性質だといったのです。
すべてのコーディング規約が何かと区別するために作られているわけではありません。
区別するためのコーディング規約だけの性質を上げ手もらわないと話にならない。

> メソッド名の動詞には原型を使う、とか、イベントには過去形を使用しない、とかと同じ類じゃん。
> それじゃこいつらは何と区別してるんだよ。
こいつら = メソッド名の動詞には原型を使う、とか、イベントには過去形を使用しない

つけてもいいけどそこは各人の判断に任せる、紛らわしいから普通はつけない、というのは規約とは呼びません。

Javaのアクセサの命名規約はメソッドの命名規約に内包されている。
つまり小文字で始まり、適切な動詞で始まり、オプションで目的語が付く。
だからこれらの規約はメソッドとアクセサを区別し、アクセサを特別扱いしたものではない。
もしアクセサ用の規約がなくても、各人は当たり前のようにget/set/isで始まるアクセサを書く。
ただしまれにputを使うやつもいるだろうから、そのためのガイドラインとして上記の動詞を使うように決めただけだ。

これは作成メソッドにはmakeではなくcreateを使う、とかと同次元の話に過ぎない。

妊婦に？

>>252
> GetNameやSetNameなんていらんだろ。つーか作るな。
> 名前ってのは機能を表す。
> 言語によっては大文字と小文字は区別されるが
> 同じ単語なんだよ。
SetNameやらを「作れ」と言ってるのが、プロパティ/メソッド区別派の意見だ。勝手に違う話に持ってくな。
話を変えるならちゃんと断りを入れてくれ。

>>257
それは>>24=>>144に言ってくれ。っていうかこのスレの24から全部読め。
>>260
それは>>24=>>144に言ってくれ。っていうかこのスレの24から全部読め。
GetNameはあまりないそうだが、SetNameはsetNameと混在し得ると言っている。

>>272
「区別」の意味を勘違いしている。っていうかこのスレの24から全部読め。
「Java 標準規約ではアクセサは get/set ではじめよ」となっているが、
アクセサ以外のメソッドでもget/setを使える。
この議論は「アクセサはget/setを使うとして、その他のメソッドはget/setを使ってはならない」だ。

>>74
> >>56
> >>get/set -> アクセサ(カプセル化の為に関数の形をとってる)
> >>それ以外 -> メソッド(動作)
> >>という事になってる。意味が完全に違うわけっす。
> >アクセサを特別扱いする意味がわからない。
> アクセサは >>37 さんも書いてるけど、プロパティの代わりなわけです。
> 関数の形をとってる事自体が本当は意味的にちょっと違うというか。しかたがなくというか。
> >・getHoge() だと内部で保持されている値を返す
> >・GetHoge() だとフィールドに関係ない何らかの値を返す
> >と使い分けてるようだが、
> >外側から見たとき、返ってきた値が
> >「実際に内部で保持されているかどうか」なんて関係ないだろ？
> >それがオブジェクト指向でいうカプセル化なんだから。
> ごめん >>24 参照して。GetXXX はあんまりないかも
> で、誤読してる。SetXXX っていう「動作(メソッド)」がある場合があるのさ。
> それは「値の設定(プロパティアクセス)」っていう意味じゃなくて、「動作」なの。わかってもらえる？

言語仕様にプロパティがあればすっきりするのに･･･。

大文字小文字で区別するからsetとSetとか紛らわしくなるんであって、
get/setとそれ以外で区別すれば問題無いんじゃない？

>>294
>し得ると言っている。
なんだ脳内か。

>>298
当初誰もが（俺も）そう思っていたが
>>132-134
が実例を出してきやがった

MFCにも
LPTSTR GetBufferSetLength( int nNewLength );
とかある。

>>24

差分をとるまでもなく、cvs annotate って打つだけで、すぐ分かること
なのに、変なコメント入れまくって、ソースを読みにくくする必要ない
でしょ。ちゃんとバージョン管理ツールの使い方を勉強しようぜ。

オブジェクトを抽出したときに、
そのオブジェクトの状態をあらわすものがプロパティ。
オブジェクトに対する操作を表すものがメソッド。
オブジェクトの観測者がいてはじめて成り立つ比較。
言語仕様がどうのというレベルの話ではない。

まああれだ、光は波か粒子かといったことに通じる。

>300
cvs annotate では追加された行はわかるが、削除された行についてはわからない。

>301
オブジェクトはプロパティ以外の状態を持つことはできないのでしょうか？
それとも、オブジェクトの状態をプロパティと呼ぶのでしょうか？

たとえば、アクセサが定義されていないＣ＋＋のメンバ変数はプロパティですか？

>>303

> オブジェクトはプロパティ以外の状態を持つことはできないのでしょうか？
> それとも、オブジェクトの状態をプロパティと呼ぶのでしょうか？

後者のほうが近い。


> たとえば、アクセサが定義されていないＣ＋＋のメンバ変数はプロパティですか？

プロパティであるか否かはアクセサの有無とは関係ない。

>304
あなたが言っているプロパティというのはOOにおける一般的な意味のプロパティですね。
VBやC#のプロパティではなく。

それについては依存ありません。

JavaのフィールドやC++のメンバ変数は、それぞれの言語における
プロパティの実装であると考えていいですか。

意味が通じなくなるので訂正します。
異存ありません。
~~~~

>>305

> JavaのフィールドやC++のメンバ変数は、それぞれの言語における
> プロパティの実装であると考えていいですか。

よいと思う。
さらに言うと、VBやC#のプロパティもVBやC#におけるプロパティの実装ということだろう。
実装と概念が同じ呼び名ということでよいのでは？

>>235前後いくつか

フィールドとプロパティを混同してないかい？

言語仕様の話と概念の話が分離出来てないみたいだね。

>308
どうかな？
オブジェクト指向で、オブジェクトが「状態」と「操作」を持つのは当然のことで、
UMLがそれを表現できなければ困るし、
当然、オブジェクト指向プログラミング言語も「状態」と「操作」を表現・記述できる。

その上で、「状態」をオブジェクトの外に公開するか否かは別の問題だ。

「状態」をどのように公開するかも、また、言語によって異なる。
SmallTalkのようにsetter/getterによってのみアクセス可能な言語もあるし、
メソッドとは別の方法で「状態」にアクセスするための記法を用意している言語もある。

よーするにpropertyのない言語は時代遅れってこった。

プロパティとメソッドは区別すべきだという人たちへ。
コンストラクタとメソッドは区別すべきだとお思いですか？

区別することの利点・欠点はおいといて
Java＝コーディング規約で明確に区別される
C++＝コーディング規約では区別されないが new が頭にあればコンストラクタ
Smalltalk＝そもそもコンストラクタもただのメソッド

C++では素のままのフィールドに対するアクセス制限は
public(自由に) private(触るな) protected(場合によって)
しかない(friendは別バナ)。
また単純なフィールドでは表せない属性もある。
だからもっと便利にする為にメソッドを使ってプロパティを表現しよう。
メソッド本来の意味から外れてるからわかりやすくしておこう。
これに何の問題があるんだ？
メソッドを使ってプロパティを表現していても
それは言語仕様的にはメソッドだから
他のメソッドと区別する事は無意味だとか
その他のメソッドでも同じ値さえ返せば同じ意味だとか言ってるのは
設計と実装に差があること、でもできれば設計時の概念は実装に活かした方が
幸せになれやすい事もわかってないような自称スーパープログラマさんなんじゃないのか？

> C++＝コーディング規約では区別されないが new が頭にあればコンストラクタ
初耳だな。区別しない派が低いレベルで一定だという事実を如実に物語っている。

区別するコーディング規約を二人以上のプロジェクトで適用した例：０件

根拠の無いデータを書いた場合の必死だな度： 120%
さらにその後 また 自演する可能性： 100%

いろいろ勉強になっただろ？事実おまえのレスの中の技術的な理解度は
徐々に上がってきてるよ。いいスジしてんだからこんな所で時間無駄にすんな。

>>24は今夜も来てるのか

>>313
＞メソッド本来の意味から外れてるからわかりやすくしておこう。

その結果、setName()とSetName()が同じクラスの中にあっても構わない。
という主張は大変愚かだと思うんですが。setNameとSetNameって本当に分かりやすいのか？

class Window {
　　bool visible;
　　bool getVisible() {return visible;}
　　void setVisible(bool v) {visible=v;}
　　void SetVisibility(bool visible) {
　　　　setVisible(visible);
　　　　if (visible) NativeWindow->Show();
　　　　else NativeWindow->Hide();
　　}
}

>>302

> cvs annotate では追加された行はわかるが、削除された行についてはわからない。

これは、俺も不満に思うな。
しかし、これも cvs を直すことによって解決する方が建設的だろう。
cvs にその機能がない間は、差分をとることによって回避できる
問題だしな。

少なくとも、俺は
/* some lines were deleted here on 2003/06/26 by foo */
/* some lines were deleted here on 2003/07/20 by bar */
/* some lines were deleted here on 2003/08/01 by baz */
なんて行が山のように残ったソースなんて読みたくないよ。
読みにくくなるだけだろ。

機械にできることは、人手でやるよりも機械にやらせた方がずっと
マシだ。

>>317
烈しくオマエモナー

>>318
bool SetUp() { return this->Initialize(); }
void SetUp(bool up) { this->up = up; }
より
bool SetUp() { return this->Initialize(); }
void setUp(bool up) { this->up = up; }
の方がマシだとおもわないか？

>>322
どっちも同様に嫌だ

>313
>また単純なフィールドでは表せない属性もある。
>だからもっと便利にする為にメソッドを使ってプロパティを表現しよう。

「単純なフィールドでは表せない属性」ってなんだよ。
インスタンスの状態(＝属性)を表現するものがインスタンス変数なんだよ。

「メソッドを使ってプロパティを表現」できるわけないだろバカ。
「操作」で「状態」が表現できるかバカ。

こいつはホントにバカだね。

http://homepage.mac.com/hiroyuki45/hankaku09.html

http://homepage.mac.com/hiroyuki45/

http://www.2ch.net/2ch.html

class Rect{
Point left_top_,right_bottom_;
public:
Point left_top() const { return left_top_; }
Point right_bottom() const { return right_bottom_; }
int width() const { return right_bottom_.x-left_top_.x; }
int height() const { return right_bottom_.y-left_top_.y; }
};

矩形クラスは横幅と縦幅という属性を持つ。
それをインスタンス変数として持つよりも上のような実装の方がよい。

>>322
思わない。どっちもダメ。俺の主張わかってるか？

俺が言いたかったのは
bool SetUp() { return this->Initialize(); }
void SetUp(bool up) { this->up = up; }
そもそも↑のように大文字小文字が異なるだけのメソッドを複数作るべきではないということ。
大文字小文字の違いを利用して区別しようという意見に反対してるだけだ。

>328
きみのいう「属性」と「状態」は違うよね。
オブジェクトのパーシステンシに関係するのは「状態」であって、
「属性」じゃないよね。

プロパティ、プロパティと連呼してるやつは「状態」と「属性」を
あえて混同しようとしているように思える。

>>330
> インスタンスの状態(＝属性)
混同してるのは324です

>bool SetUp() { return this->Initialize(); }
>void setUp(bool up) { this->up = up; }
ここはウンコな命名を挙げるスレですか?

>>329
念のために言うが、お前スレの流れを理解して無いだろ。
SetUpとsetUpは同じクラスに混在するわけじゃない。
大文字か小文字かで区別することを良しとするやつがこのスレに一人でもいるわけ無いだろ。

SetUpとsetUpだからわかりにくいんだよ、SetUpとsetDownにしる。

初期化するときは SetUp と大文字で初めて、
Down プロパティをセットするときは setDown と小文字で始める、という規則を良しとするか否かだ。

セットアップも元をたどれば
setup = set up = 立ち上げる = 立った状態にする = 「立っている」を真にする
プロパティの設定と違いないわけだが

>>333
おいおい、大きな勘違いをしてるのはどう考えてもお前だろ。
＞大文字か小文字かで区別することを良しとするやつがこのスレに一人でもいるわけ無いだろ。
いる（いた？）からこういう議論が続いてんだろ。このスレ最初から読め。

> SetUpとsetUpだからわかりにくいんだよ、SetUpとsetDownにしる。
>
> 初期化するときは SetUp と大文字で初めて、
> Down プロパティをセットするときは setDown と小文字で始める、という規則を良しとするか否かだ。
初期化は init 乃至は initialize、できることならコンストラクタですればいいわけで。
だいいち、「セットアップ」なら setUp でも SetUp でもなく、setup なんちゃうんかと。

もし仮にコーディング規約で getter/setter を setHoge/getHoge にするのが決まっているのなら
初期化に setup という紛らわしい名前を付ける事自体が間違ってる。

とりあえず >>333 はドキュソ。

>>336
そういう話は132に言え
SetUpは単なる例だ

>>337
SetUp以外に現実的で実用的な例はないのかよ。

>>338
今のところ上がってないな
>>24が何度か遭遇したそうだが俺は見たことが無い

メソッドとプロパティを区別するのはいいとして、その判断を
個々人に任すと意味なしだと思うが。

ここで画期的な案

setPropertyXXX()
getPropertyXXX()

を提案する。
紛らわしくないだろ？

>>341
setPropertyNameが激しく紛らわしいな

通はこうする
__setXXX()
__getXXX()

>>342
ちなみにメソッドはこう。

executeMethodXXX()

ちなみにアクセサはこう。

type XXX()
void XXX(type value)

窃盗しつけるﾔｼは氏ね

>>343
__は予約語

>>345=>>263
何度も言わせるな。それは何言語のソースなんだよ。

すいません　こんなレベルのことをコーディング規約って言っていいのかわからんけど
ソースを読みやすくしようと思って、()と引数や式の間にスペース入れたりしちゃうんです。

System.out.println( "Hello, world" ); とか

if ( array.length == n ) とか

int insert( int hoge, String name ); みたいな感じ

どうでしょう？　

頭悪そうに見えるから嫌いです。個人的には。

>>349
他人のスタイルには口を出さない、修正するときは可能な限り合わせることにしてるが、
それは趣味じゃない。

なるほど　僕はどうも目が疲れやすいのか、ゴチャゴチャしたのを見るとすごく疲れるんですが
最近、一般的なコーディングスタイルに合わせることの方がメリットあると思ってまして

スペースを多くとると、自分で書いてる時はいいけど
他人のソースを見たらすごく見ずらく感じるんですよね。。。

>>349
俺も括弧の内側にスペースを入れるが==の左右に入れない。

変数やメソッドの名前はある程度そろえる価値はあると思うが、
スペースの位置や{の位置なんか、どっちだろうと大して変わらんと思う。
自分の好きなやり方でかまわんだろ。
見やすいソースってのは固まるべきところは固まってて離れるべきところは離れてるもんだ。
全部詰まってるのも全部離れてるのも同じくらい読みにくい。
1行毎に空行の入ってるソースの読みにくさと言ったらない。

このスレ頭から読んだけど面白かったよ。
ただひとつお願いがあるんだ。

二度と上げないでください。目障りだから。

>>354
上げるってなんですか？

>>355
ﾜﾗﾀ

>>356はスレが上がってもおかしいお年頃

>>340
> メソッドとプロパティを区別するのはいいとして、その判断を
> 個々人に任すと意味なしだと思うが。
個人以外の何が判断するんだ？
設計も実装も所詮は個人の判断だと思うが。

>>330
あんたの言う状態と属性の違いって何よ？
変数として実装されているかどうかって事？
だとしたらプロパティ区分派は混同しようとしているんじゃなくて
同一視しようとしているわけなんだが。

>>358
誤読。個人と「個々人」ではニュアンス違います。
っていうか、ここはコーディング＊規約＊スレですよ。

Javaでプロパティといったら
java.lang.System.getProperties()とかjava.util.Properties#getProperty(String key)
とかを想像するのだが。

拡張子がpropertiesになっているファイルを
Properties#store(OutputStream out, String header)
を使って取り扱うもの(今ならXMLで管理)とかも想像していたので
なんか読みにくいスレだ。

混同してる香具師よ、フィールドとプロパティの区別くらいつけろ。

UML :; 属性
Java : フィールド
C++ : 面罵変数
C# : 面罵変数

UML : 操作
Java : メソッド
C++ : 面罵関数
C# : 面罵関数


属性もフィールドも面罵変数も決してもプロパティになるとは限らないぞう。

VBとかC#やりすぎているから勝手に「プロパティ」とか思い込んでいる
とちゃうかと。

>>361-362
ハイハイ、わからない事があったときには
煽るんじゃなくて おしえてください って素直にかきましょうね。

前から思ってたがフィールドって何でprotectedにするんだ？
Publicにしれば記述も楽だし機能的にも同じだろ？

class Hoge
{
public:
　Nullpo *nl;

　Hoge() { nl = new Nullpo(); }
　~Hoge() { delete nl; }

　void build(void) { nl->nullpo(); }
}

int main(void)
{
　Hoge hoge;

}

>>364
普通privateでは

>>365
．．．途中で送信しちまった（鬱だ氏のう

int main(void)
{
　Hoge hoge;
　hoge.nl = NULL;
　hoge.build();

　return 0;
}

>>366
俺はいままでPrivateだったんだけど
今の職場はprotectedなんだよね

じゃなくて内部で値を操作しないんなら
プロパティとしてget、setってやらなくても
publicにしればいいじゃん！！って事を言いたいわけよ

＞publicにしればいいじゃん
そんな大局変数みたいなフィールド作るなよ

内部で値を操作するように仕様が変わったときに、
クライアントのコードが変わらないようにするためだよ

>>368
メソッド経由で状態を変更しないようなクラスを作っている時点で
DQNな開発だということになりますが…

大人数で開発する際、オブジェクトの内部の状態に対していちいち
チェックしなくても信頼できるように、各オブジェクトごとのフィ
ールド全体の整合性の取れている状態に保つことは重要ですよ。
そうやって作っておくと、そのオブジェクトのユーザに余計な負担
をかけないで済むのです。
そのためにみんな「メソッド経由でしか操作しない」という、チョ
ットみ面倒くさい方法を一生懸命取るのです。

サブクラスから、スーパークラスのフィールドへ直接アクセスする
ためにProtectedにしているんだろうけど、それもほんとはよくな
いね。スーパークラスのsetter、getter経由でアクセスすべきですな。
スーパークラスのsetter、getterをprotectedにすべき。

>>370
なるほどね、俺的には自分で組んでんだから
それくらい注意して書けよって気にもなるんだが、まあいいや
thx

>>371
最後の４行は宗教戦争になるな。


>>372
カプセル化なんて必要ないとでも言ってるのか？

＞スーパークラスのフィールドへ直接アクセスする
＞ためにProtectedにしているんだろうけど、それもほんとはよくな
＞いね。
設計次第だろ。くだらん。

一行書くごとに、オナニーする

>>352
> スペースを多くとると、自分で書いてる時はいいけど
> 他人のソースを見たらすごく見ずらく感じるんですよね。。。
これ、使っているフォントによって大きく印象が変わるんだよね。

コーディング規約を決めるときには、標準フォントも決めた方が
幸せなんだろうか。面倒なんでさすがにやってないけど。

>>375

Eclipse>>ウインドウ>>設定>>コードフォーマッタ
>>オナニスト専用>>できるだけ早めに処理にチェック

コードの記述スタイルなんか気にしてないな。
納品直前に、共通のコードフォーマッタに一回通して終わり。
自動化できる作業で、開発者に無駄に頭使わせるのは無駄で
しょう。

>>378
開発中、他人のコードをいっさい見ない・変更しないという前提なら
それも可能だけど。さすがに非現実的だよな。

俺のところは、変数名・関数名のおおざっぱな命名規約だけ決めて、
括弧の付け方やインデントの付け方は各自勝手にやってもらうことに
してる。ただし他人のソースをいじることはママあるから、タブ幅と
インデント幅をソースに書いておく。

ちょっと高機能なエディタを使ってる場合、ソースファイル単位でそのあたり
の設定を変えられるし。

// vim: sw=4: ts=4

仕様設計の段階で決まった関数名はそれに従う。
それ以外は必ず先頭に「_」(半角アンダーバー)をつけること。

ウチの会社、ヘンかも。

>>380
C も C++ も使えなくなりますがいいですか？大丈夫ですか？
X_Hoge くらいにしておいた方がいいYOと上司し進言してみては？

(´-`).｡oO(…_[a-z0-9]+ なら別に OK じゃないのかなぁ…)

最初が _ から始まる名前は処理系が予約してるってだけの話でしょ。
たとえば GNU binutils を使ってると _start, _end というシンボルは
静的データ配置のための絶対アドレスシンボルとしてリンカが参照するの
で、同名の変数・関数を作ると謎の挙動で悩むことになる。

ま、分かっててやる分には構わんと思うけど。メンバ変数・関数として
使う場合には、処理系が使う内部シンボル名と被る可能性も少ないし。

接頭詞は糞

>>384
そんな品詞はない！

>>364
> 前から思ってたがフィールドって何でprotectedにするんだ？
> Publicにしれば記述も楽だし機能的にも同じだろ？
> 前から思ってたがフィールドって何でprotectedにするんだ？
> Publicにしれば記述も楽だし機能的にも同じだろ？
> 前から思ってたがフィールドって何でprotectedにするんだ？
> Publicにしれば記述も楽だし機能的にも同じだろ？
> 前から思ってたがフィールドって何でprotectedにするんだ？
> Publicにしれば記述も楽だし機能的にも同じだろ？
> 前から思ってたがフィールドって何でprotectedにするんだ？
> Publicにしれば記述も楽だし機能的にも同じだろ？
> 前から思ってたがフィールドって何でprotectedにするんだ？
> Publicにしれば記述も楽だし機能的にも同じだろ？
> 前から思ってたがフィールドって何でprotectedにするんだ？
> Publicにしれば記述も楽だし機能的にも同じだろ？
> 前から思ってたがフィールドって何でprotectedにするんだ？
> Publicにしれば記述も楽だし機能的にも同じだろ？
> 前から思ってたがフィールドって何でprotectedにするんだ？
> Publicにしれば記述も楽だし機能的にも同じだろ？
> 前から思ってたがフィールドって何でprotectedにするんだ？
> Publicにしれば記述も楽だし機能的にも同じだろ？
> 前から思ってたがフィールドって何でprotectedにするんだ？
> Publicにしれば記述も楽だし機能的にも同じだろ？
> 前から思ってたがフィールドって何でprotectedにするんだ？
> Publicにしれば記述も楽だし機能的にも同じだろ？
> 前から思ってたがフィールドって何でprotectedにするんだ？
> Publicにしれば記述も楽だし機能的にも同じだろ？
> 前から思ってたがフィールドって何でprotectedにするんだ？
> Publicにしれば記述も楽だし機能的にも同じだろ？
> 前から思ってたがフィールドって何でprotectedにするんだ？
> Publicにしれば記述も楽だし機能的にも同じだろ？

フィールドをpublicにしたがる奴はカプセル化も知らないVB厨

publicにしたらスレッドセーフじゃなくなる恐怖があるわな。
その辺は>>363も>>364も理解していないどうだな。

不変クラスというものがどういうものか理解してから発言しような。

規約に変な制限入れたがる奴はSM好き

なんでもPrivateにする奴のせいで苦労したことがある_|￣|○

なんでももpublicにする奴のせいで苦労することのほうが
莫大に量が多いのだが。

お前らマルチスレッドプログラミングしたことがないんだろ。
だから平気でなんでもpublicにすることができるんだろうな。
スレッドを理解できない馬鹿はウザイからいっぺん死んでくれ。

無駄にthreadを使わないのも一つのやり方だがね

★☆　夏休みは　ＧＥＴＤＶＤ　で満喫・満喫！！　★☆★
★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★
☆★　送料激安！　　スピード発送！　　商品豊富！　　　
★☆　　　　　　http://www.get-dvd.com　　　　　　　　
☆★　激安ＤＶＤショップ　「ＧＥＴＤＶＤドットコム」　
★☆　　　　　　http://www.get-dvd.com　　　　　　　　
☆★　今すぐアクセス　Ｌｅｔ’ｓ　Ｇｏ・Ｇｏ！！　　　
★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★

>>392
> 無駄にthreadを使わないのも一つのやり方だがね
> 無駄にthreadを使わないのも一つのやり方だがね
> 無駄にthreadを使わないのも一つのやり方だがね
> 無駄にthreadを使わないのも一つのやり方だがね
> 無駄にthreadを使わないのも一つのやり方だがね
> 無駄にthreadを使わないのも一つのやり方だがね
> 無駄にthreadを使わないのも一つのやり方だがね
↑アホがいます

thread以前の問題だろ・・・
どうしてこう無駄に脱線したがるかね。

なぜ結合度の話にならないのかが不思議だ。。

>>392
やばいよお前。GUIとかサーバサイトプログラミングしたことがあんの？
だったらフィールドをpublicにするのは問題だよ。

間違ってstaticにするなよw
間違ってもsetterを付け加えるなよw
間違ってもクラスを継承できるようにするなよw

>>397
>>392 はマルチスレッドの必要のないプログラムには
むやみにマルチスレッド化するなということを言っているのでは？

>>396 がいいこと言った！

ウザいから安置OOスレでやれや

>>398
マルチスレッドにする必要の無いプログラムを好き好んでマルチスレッドにするやつは稀だと思う

>>401
Javaの世界には、そういうボケナスがイッパイいるぞ。
new Thead().start()でスレッド動いちゃうからな。

作るのは簡単だが、そっから先は偉い面倒くさいということを
理解していない人たちがいるんだよね。

今担当のプロジェクトをgrepしたら、間抜けなThread生成が
あちこちに…ひぃぃ、ｵｿﾛｼﾔ。

すんませんが教えてくだせえ
JavaでCBuilderのいうところの
Application->ProcessMessages()
をやるにはどうすればいいんでしょうか

>>403 スレ違いっす

規約 第i条
スレッドは、「Javaで学ぶデザインパターン マルチスレッド編(結城本)」を
熟読した上でこれを使用すること。

public abstract class AbstractEmployee implements Employee {
public String name;
public String id;
...
}

ｳﾜｧｧｧｧｰﾝ

>>406

サ　イ　ア　ク

タブ幅4で書かれたソースをタブ幅8に直したいんでつが、
何かいいツールありますかねぇ・・・ 言語は C, C++ で。
文字列の中まで変換されたりしないやつ。

expand / unexpand

indent

>>408
Eclipseで「ふぉーまっと」

もまえら、１行の長さどこまでなら許せる？
漏れは７９だが最近はウインドウ横に伸ばせば
いいじゃんってハナで笑われまつ。

>412
自分は80と決心しているが、85とか86とかになっちゃうと浮気。

80がうぇるのうん

72だな。
FORTRAN野郎としては。

http://homepage.mac.com/miku24/

最近はプロポーショナルフォントにしてるし、印刷もしないので
1行の文字数はまったく意識しなくなってるな。
まあ100文字ぐらいにはなってるかとは思うが。

大体100くらいかな
数えて改行することはない。

1024くらいまでは気にしないかな。
意味の切れ目じゃない部分で改行する方が気持ち悪い。

もっとも普通に書いてりゃいいとこ200カラムだろうが、
WindowsAPI なんか使うとな、どうしても。わかるだろ？

横スクロールバーがあると途端に可読性が下がることがある。
最大は80~90がベターかと。

どうせ納品前には整形ツール通すので、好きにしろ、がルールだなあ。

>>421
バージョン管理ツール使わないの?
差分の表示が出鱈目になってしまうんだが。

たぶん整形したものはコミットしないんだろ。exportしてから整形。

>>422
そんな奴は、バージョン管理なんて知らないに決まっています。
ちょっと前にいたプロジェクトでも、大手なんだが。ソースのマージとか管理とか
人力でやっていた。そんで、バージョン管理しても自分のローカルをコミット
してしまう。。。。ばか

>>424
> そんな奴は、

って誰のこと？

>>424文盲？
>>421みたいな「納品前には整形ツール通すので、好きにし」ているやつだろ

桁数なんぞに足引っ張られんのもナンセンスだよな〜
整形ツールとかじゃなくてもっと根本的にどうにかならんか

>>427
> 根本的にどうにか
気にしない→根本的に解決

　　　 (⌒V⌒)
　　　│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン

俺はちゃんとif(a==true)とかif(a==false)とかって明示的に書くんだぜ。
この方がちゃんと意図が伝わりやすいだろ？ベイベ〜

C厨の私にとってはif(a)の方が分かりやすいですね

if (((((a==true)==true)==true)==true)==true)

>>430
bool 型のときは if(a) でいいと思う。
int とかでは if(a) とかやめて欲しい。

C に bool 型ってあるろ？

_Bool型が有りまふ

>>434
ない。
_BoolならC99にあるけど

>>430は間違い

>>433>>437 おもいっきり釣られてるやん。（ﾜﾗ

>>438
？

bool型でも変数名によっては (a == true) って書きたい時はあるよね。

#include <stdlib.h>
#define die() exit(1)

if (dreams_come == true) {
...;
} else {
die();
}

class Patlabor
{
private bool al = false;
}

class PairedAnimal
{
public bool kameAnd = true;
}

c++ 社内向けにこんなん考えましたが、御意見賜りたく。


非 static メンバ(インスタンス)変数／関数名は _?[a-z][0-9A-Za-z]* とする。
->先頭以外のアンダースコアは原則禁止。

先頭アンダースコアは通常付ける。外部からの直接アクセスの多い
メンバ(Ｃ互換構造体でありがち)では、付けなくても良い。付けない場合、
自クラスのメソッドにおいては this-> 参照推奨とする。

メンバ変数／関数以外で先頭アンダースコアを持つシンボルは全て禁止
(スコープによってはコンパイラ、ライブラリ予約となっていますので普通は使わないです)

getter/setter は get/set に続けて変数名をそのまま書く。通常(アンダースコアありなら)
get_xyzXyz () とかになる。

static メンバ変数／関数名は [A-Z][0-9A-Za-z]* とする。

インスタンス変数／関数はthis付けるようにしときゃ、
アンスコいらないんじゃね？
アクセサメソッドは通常getValue, setXとかじゃね？

識別子の先頭にアンダースコート？

>>444
this-> を必須にするのは気が進まないんです。面積(文字数)食いすぎって気がして。
なので「逃げ道を用意した」という恰好です。
アクセサの命名規則自体は getValue setX と変えるわけではなく
先頭が _ である為に get_xyzXyz とかになるという事です。
アクセサに内包される名称がフィールド名と変わる(大文字小文字が)
のも好きじゃないんで、それも丁度いいかなぁと思ったり。

やっぱり普通は「this-> 必須」とかなんですかね？

>>446
アンダーバー、大文字、と続く識別子は
予約されているから使ったらだめなのだが


_Foo //どの名前空間でも駄目
_foo //グローバルな名前空間じゃないならまーOKだけど、安全側に立つなら使わないほうがよい

>>447
その辺含めて 443 に書いてありますが、
クラスメンバ限定且つ_?[a-z] 始まりでつ。

>>448
ゴメソ
よく読んで中った

まぁ、thisなんたらって書いとけば、それはローカル変数でもなければ、
（通常）クラス変数でもないわな。

ある本の規約ではアンダーバーを接尾に付けてる例はある。
その場合でもアクセサ名にアンダーバーは付いていない。

>>443
いいんじゃないの。 規約なんだから。

俺は、あんたんとこじゃ働きたくないけど。

アンスコ？？

>>451
そう言われちゃうと、このスレで聞いた意味が．．．

☆this-> 付けるの当り前
☆アクセサの名称がフィールドと完全一致しないのは全然気にならない

という御意見という解釈でよろしいか？

>外部からの直接アクセスの多い
え?

>>454
そこは確かに突っ込み所なんですけど、凄く低レベルな所で
どう転んでも struct のままである事が確定しているクラスもあるので。

また、アクセサもそれに該当するかと。

おれはアンダースコアで始まる名前を使うのを強いられるのが苦痛だ。
アンダースコアで始まる名前は、すべて処理系用と考えるほうが楽だ。

こういうことやってる人いないの?
void MyValue(int value){ myValue = value; }
int MyValue(void){ return myValue; }

>>456
良かった。話が進みます。「強いられる」という部分は、
☆ _ で始めた物に関しては、クラスメソッド内で this-> 無しで取り扱って「も良い」
と規約を変更すれば回避出来ます。ただ、これで _ が頭に付くソースが
出来ちゃうと、

>アンダースコアで始まる名前は、すべて処理系用と考えるほうが楽だ。

こうは考えられなくなっちゃいますね。どうすっかなぁ。

ちなみに、451 さん的に this-> 強制は問題無いんですよね？

皆さんは、命名規則ってはっきり決めてます？
俺は、かなり優柔不断です。
vector<T> の変数が 語尾にs つけたり、Vectorつけたり
カウント変数も nCount だったり iCount だったり
クラス名は、Cで始まるけど、構造体等は、あやふや
ハンガリアンだけじゃ生きていけない。

会社でも、個人でもいいから命名規則おしえてください。

とりあえず、template
■型
クラス　 　 　 　 　 　 　 ：
インターフェースクラス ：
クラステンプレート　 　 ：
構造体　 　 　 　 　 　　 ：
１行のマクロ 　 　 　　 ：
複数行(関数)マクロ　 ：
関数テンプレート 　 　 　：
名前空間　 　 　 　 　 　：
メソッド名 　 　 　 　 ：
std::list 使った型名 ：
std::vector使った型名：

■変数名
数値(個数)　 　 　：
文字列 　 　 　 　 ：
文字列クラス　 　：
std::vectorの変数名 　 ：
std::listの変数名 　 　：

>>443
まあ、そりゃ、上からそれでやれっていうお達しなら、それでやれないことはないですが。
# こんな規則なら会社辞めちゃるとキレるほどではないという意味で

メンバ変数は _valよりもm_valの方が慣れてるのでそっちのがいいが、
まあ、やれといわれればやる。大した問題じゃない。
でも>>456にはなんとなく同意したい気分。
m_valの方を採用した場合でも、getter/setterの関数命名規則は
そのままで問題なかろ。mがget/setに変わる感じ。

けど、メンバ関数を _ からはじめろ、というのはかなり苦痛。
private/protectedなメンバ関数なら外部からアクセスは出来ないので
名前の問題は少ないし、だいたい
CMyClass a;
a._Func();
これは格好悪すぎると思うがどうか。
aのメンバ関数だっていうことはどう見ても明らか。
アンダースコアの必要性不明。
staticなメンバ関数は
CMyClass::StaticFunc()
で呼べば明らかなので、むしろ
a.StaticFunc()
を禁止したほうがいいと思う。
スタティックメンバ変数は隠してsetter/getter使い、
上記規則を当てるべき。

クラス内部でアクセスするのにどうこうというのなら
むしろs_valを当てるべきかな？

まあ、俺規則バリバリに展開しちゃっててなんですが、
一個人の意見として参考までにどうぞ。

例：
■型
クラス　 　 　 　 　 　 　 ：先頭に C (CClass)
インターフェースクラス ：先頭に I (IClass)
クラステンプレート　 　 ：小文字？
構造体　 　 　 　 　 　　 ：先頭にST_ (ST_Struct)
１行のマクロ 　 　 　　 ：
複数行(関数)マクロ　 ：
関数テンプレート 　 　 　：普通に
名前空間　 　 　 　 　 　：
メソッド名 　 　 　 　 ：最初大文字 obj.GetHandle()
std::list 使った型名 ：
std::vector使った型名：

■変数名
数値(個数)　 　 　：nCount
文字列 　 　 　 　 ：sz
文字列クラス　 　：sz
std::vectorの変数名 　 ：後ろにs
std::listの変数名 　 　：後ろに_list

お。書いてる間に良いテンプレ発見。
なおすべてにおいてMyは規則じゃないです。例ね。
とりあえずわかってもらえると信じて…

■型
クラス　 　 　 　 　 　 　 ： CMyClass
インターフェースクラス ： IMyInterface
クラステンプレート　 　 ： CMyClass< >
構造体　 　 　 　 　 　　 ： MYSTRUCT
１行のマクロ 　 　 　　 ： MACRO / MACRO()
複数行(関数)マクロ　 ： inline関数で代用
関数テンプレート 　 　 　： MyFunction< >
名前空間　 　 　 　 　 　： Namespace / NameSpace
メソッド名 　 　 　 　 ： MyMethod()
std::list 使った型名 ： MyXxxList // めちゃいい加減。
std::vector使った型名： MyXxxVec // めちゃいい加減。

■変数名
数値(個数)　 　 　： nNum
文字列 　 　 　 　 ： szString
文字列クラス　 　： strValue
std::vectorの変数名 　 ： vecValue
std::listの変数名 　 　： listValue
------テンプレにはないけど-------
クラスメンバ変数　： m_Value
クラスメンバ関数　： Method()
setter/getter　　　 ： GetValue() / SetValue()
グローバル変数　 ： g_Value // 普通使わないけど、まあ


まー、見てのとおりかなーりいい加減です。
他の人の見ていいのあったら乗り換えるかも…

Σ
テンプレにはないけどって奴、メソッド被ってる…＿|￣|○

俺は、バカみたいに略しまくってるやつが大嫌い。
そんなやつは今でもチョベリバとかチョベリグとか言ってるやつに違いないって感じ〜？

>>462
素敵です。
かまいません。どんどんテンプレート追加してください。

はっきり決まってなくて
モヤモヤしたもの吹き飛ばしたいです。

>>460
ありがとうございます。参考にします。

>CMyClass a;
>a._Func();
>これは格好悪すぎると思うがどうか。
"public な物は「外部から多用される」ので _ 付けない" で逃げようかと．．．

a.StaticFunc () は禁止に同意です。

m_ 派の割合ってどの位なんでしょうね？

テンプレ修正案
■型
クラス　 　 　 　 　 　 　 ：
インターフェースクラス ：
クラステンプレート　 　 ：
構造体　 　 　 　 　 　　 ：
１行のマクロ 　 　 　　　 ：
複数行(関数)マクロ　　 ： // つーかinlineで代用しる!! 使えないCの人はどうぞ
関数テンプレート 　 　 ：
名前空間　 　 　 　 　 　 ：
メソッド名 　 　 　　　 　 ：
getter/setter　　　　　　 ：
std::list 使った型名　　 ：
std::vector使った型名　：
std::map使った型名　　 ：

■変数名
定数(const/#define)　　：
クラスメンバ変数　　　　 ：
グローバル変数　　　　　：
クラススタティック変数　：
数値(個数)　 　 　　　　　：
文字列 　 　 　 　　　 　 ：
文字列クラス　　　 　　 ：
std::vectorの変数名 　 ：
std::listの変数名 　　 　：
std::mapの変数名　　　 ：

連カキスマソ。忘れてた。変数名追加
// ：揃えるの難しいね…

■型
クラス　 　 　 　 　 　 　 ：
インターフェースクラス ：
クラステンプレート　 　 ：
構造体　 　 　 　 　 　　 ：
１行のマクロ 　 　 　　　：
複数行(関数)マクロ　　： // つーかinlineで代用しる!! 使えないCの人はどうぞ
関数テンプレート 　 　　：
名前空間　 　 　 　 　 　：
メソッド名 　 　 　　　 　 ：
getter/setter　　　　　　 ：
std::list 使った型名　　 ：
std::vector使った型名 ：
std::map使った型名　　 ：

■変数名
定数(const/#define)　　 ：
クラスメンバ変数　　　　 ：
グローバル変数　　　　　：
ローカル変数　　　　　　 ：
関数仮引数　　　　　　　 ：
クラススタティック変数　：
数値(個数)　 　 　　　　　：
文字列 　 　 　 　　　　　 ：
文字列クラス　　　　 　　：
std::vectorの変数名 　　：
std::listの変数名 　　 　 ：
std::mapの変数名　　　 ：

思いつきで独自規約をばら撒くんじゃない。
ちょっとは検索しろ。

>>469
ハンガリアンしか知らない。
他にあったら教えてくれ。

Cって何？

>>469
そういうこと言う人はこんなところの独自規約を真に受けてないで
えらい人が確立したとっても素敵な規約を使ってればいいじゃん。

>>466
それなら言語仕様に乗った方がいいと思うな。
「外部から多用される」とかあいまいな基準では担当プログラマ困ると思うよ。
これは多用されるんだろうか？　されないんだろうか？　今は使われなくても将来的には？　ってな。
はっきりと「private/protectedな変数/関数は〜」「publicな〜」にすべき。

まあ、それでも先頭 _ は気分悪い気はするけど…
C#だとそんな感じだったっけ？　詳しくは知らないが。

____hoge____

>>443
なにかとクラスの実装内部で自分のメンバ関数を他と区別したいみたいだけど、
クラスの実装内部で何のの名前解決も行わず関数呼び出しをしたらそりゃ普通
API/ライブラリ関数か、自分のメンバ関数くらいでしょう。
クラスメンバ関数の命名規則をXxxXxxx()系に限定すれば、
ライブラリ関数は大抵全部小文字(fopen, printf etc..)だから区別がつくし、
WindowsAPIならグローバル名前解決（::CreateWindow())してやればいい。

先頭に _ だとやっぱ>>456に同意したいし、
だからってわざわざthis->参照するくらいなら
APIやライブラリ関数の方を :: で解決してやった方がスマートだと思う。

>>475
すいません、私としては焦点はメソッドじゃなくて、オブジェクト
だったのですが、両方に同じ規則を当てはめようとしたのが間違いの
始まりでした。前言撤回、メソッドに関しては _ 始まり無しの方がいいです。

それでも、メンバオブジェクトの _ 始まり案は捨てがたいかも．．．

自クラスのメンバオブジェクトにプレフィクス無しでアクセス出来る
(メソッドローカルと混同「出来る」)という言語仕様がまず引っかかって
まして、かといって this-> 強制だと、メンバオブジェクトを叩くのに
this->member->func () とかなっていやーんですし、m_ というのも
クラス定義にずらずら並んでますと「クラス定義してんだから、メンバ
なのは解り切ってるわい」って気がします。それより 460 さんのテンプレ
でいう所の str とか vec を際だたせたい。

だから本当は、自クラス内オクジェクトの参照が .obj とか $obj とか @obj とか
いう仕様だったら良かったのにと思ってるんですが、代替案として
目立たない _ をオブジェクト参照プレフィクスに(命名規約として)
してみたらどうか．．． という感じで考えたのが 443 だったわけです。
「メソッドも同じ規則で行ければ、覚える事少なくていいかも」
なんて思ったのは大間違いでした。はい。

> 自クラス内のオブジェクト参照が .obj とか $obj とか @obj とか

$obj はできるだろ? とりあえず g++3.2 だとできるぞ

おい藻前ら
メソッド名(関数名)には動詞をつかうもんだろ。

isNaN() Not a Numberかどうか
isNull() // nullかどうか
equals(Object obj) //等値かどうか
compareTo(Complex complex) //現在のオブジェクトをcomplexと比較する
combineWith(Object obj) //現在のオブジェクトをobjと結合する

_で「終わる｣変数名を多用しているクラスライブラリがあったな。
InterViewsだっけか。
class Window {
int width, height;
public Window(int width_, int height_) : width(width_), height(height_) {}
};
みたいな感じ。

結局TPO

>>479
Exceptional C++でも提案されてた方式だしな。

変数名は使用目的によって命名してください。

>>479は変数名じゃなくパラメータに見えるが、どうなの？

>>476
なにかと一人で突っ込んでる気がしてならないこの頃。いいのかなァ。

メンバ変数とローカル変数の混同が不味い、というのは納得するけど、
それは要するに m_Value なのか _Valueなのかという違いかな。
それなら既に460で言ってるけど、
少なくとも私はそれでやれといわれればやれると思います。
ただC系列の人は先頭 _ は処理系予約と叩き込まれてる人が少なからず居るので、
m_にするのかmを省略するのかは一度現地の担当プログラマに
直接お伺いを立てた方がいいと思います。
m_で慣れてますって人が多いなら無理に省略させる必要性は感じないかと。

まあなんにせよ、その辺は現地で仕事するプログラマ優先したってください。
慣れてるもの変えろって言われるのは少なからず苦労するので。

>>477
目的からすると、出来たとしても、必須になってないとあまり意味が無いかなぁ。

尚、一応試しましたが(gcc3.3)出来ませんでした。

>>484
参考になってます、感謝です。

えーと、仰せの通り m_value と _value の違いです(インスタンス変数は小文字で始めるつもり)。
大文字で始めるのはクラス変数で、ローカルとぶつかる事が無い
(ローカルを小文字で始めるのはＣ時代から論外としてます)ので
_ を省略します。

doxygen とかでの自動ドキュメント化を考慮すると、メンバ索引の見やすさから
>>479 みたいに「後ろに _」もいいかなぁ、と思います。
ただこの場合、オブジェクトへのアクセスが obj_.func ()とか
obj_->func () とかになるので、それもなぁ。

ローカルの方を別の規則で縛るというのも有りなんですが、
Ｃも並行して扱うのでそれはちょっとやりにくい．．．

あと、厳し過ぎたり、変過ぎる規則だと結局守られなく
なっていくと思うので、担当者の意見は尊重します。

俺は、コード補完が効きやすいという理由でprefixよりsuffix派。
だから_objじゃなくてobj_に1票。
コード補完機能のあるエディタが使えるという前提だがナー

>>487
入力効率の良さも大事な点ですね。だいぶ気持傾きました。

. -> [] 演算子が１キャラクタとは言えオブジェクト名と
離れちゃうのがコードを読む上でどうなのか、というのがありますが、
前に置く場合は、単項演算子が離れちゃう事になりますし、
++ -- の前置推奨をする上でも _ 後付けの方が有利ですね。

おい、もまいら2ちゃん統一ルール作ろうぜ

class A{
struct{
int data;
} m;
public:
A(){
m.data=0;
}
};

メンバ変数は構造体に纏めて持つ

>490
また、ずいぶんとアグレッシブなのを持ち出してきたな。
不思議と積極的に否定する理由が見つからない。(w

>>491
prefix方式と記述の上での使い勝手大して変わらんし、確かに悪くなさげ。
派生クラスで親クラスのメンバを区別して扱ったりもしやすそうだ。

>>490
内部状態をファイルに書き出す時も、
write(file, &m, sizeof(m));
できるな。便利かも。

>490
const メンバの初期化ができない？

class A {
struct {
const int data;
} m;
A(int data) : m.data(data) {
}
};

>>494
ちょっと面倒だけどできなくもない
class A {
struct A_m {
const int data;
A_m(int d) :data(d) {}
} m;
A(int data) : m(data) {
}
};

ローカル変数の m と衝突するじゃん。

>>496
ローカル変数名m禁止の方向で

(m_m)

マイクロソフトに逆らうのか

さあ折り返し地点です。

>>490
おんなじような事考えてる人がいるもんだなぁ。
ちょっと別版。

struct RawHoge {
int member1;
int member2;
int Method(int arg);
};

class CHoge : private RawHoge {
public: int Method(int arg) { return RawHoge::Method(arg);
};

VISITOR なんかでいちいち friend 指定して居られない時には
RawHoge への参照を渡しちゃうと良い。
後は関数内ローカルクラスのメンバ関数にも RawHoge への参照を渡しちゃうとよい。
(僕は実際g++で関数内ローカルが親クラス(？)に無制限にアクセスできちゃうのを前提で
書いてしまったコードをこの方法で他のコンパイラでもコンパイルできるように修正したりしました。)
問題は CHoge から本当の(public)継承したい時とかにややこしくなる。
C++もJavaもC#も インターフェイス と 実装 と それをあわせるクラス っていう
三位一体の仕組みになってないのが辛い。
次世代言語では是非なんとかしてほしい。

補足 考え方的には pimpl にちょっと似てるかもしれない。

>>501
何の意味があるのか理解できません。
"RawHoge::" ってつけたいだけ？

class CHoge : public IHoge, private RawHoge {};
なら実装継承をしたいとわかるんだが。

>>503
＞class CHoge : public IHoge, private RawHoge {};
＞なら実装継承をしたいとわかるんだが。
ポリモーフィックな型ならそう書くでしょう。って >>501 の後半の長文も読んでくださいよ。

ファーストクラス(プリミティブ)な振る舞いのクラスで
関係ないクラスには適切なアクセス制御をしたまま、身内(っていうか自分の構成要素のクラス)には
実装をさらけ出す為に private 継承を使ってるわけです。

>>504
後半は、VISITORでfriendとか、三位一体とか、全然関係ないpimplとか
さらに意味不明になるので無視してた。

そもそも >>490 は、メンバ変数につける prefix, suffix の議論の中で出てきたわけで、
"m." と prefix っぽく書けることが主題だったはず。
実装や設計は関係ない。

>>505
規約を作るのは単に字面の統一の為ではないでしょう？
よりよいやり方を標準にするという事のはずです。
その為には規約の背景にある意図や利便がわかっていないといけない。
現にメンバ変数にプリフィクス m_ やサフィックス _ をつける方式は
実践している人たちにとっては無くてはならないほど便利で重要な物だけど、
その意図や利便を理解していない一部の人たちは頑なに否定しようとして
使いたがらない。
だから規約には「それに至った背景、どんな利便があるか」が伴わないといけない。
それがなければ >>490 の案はヘンテコな書き方と一蹴されてしまう可能性も高いのです。

すいません、煽りじゃないというのは分かってほしいですが、
RawHoge:: を付けたいという以上のことが読み取れません。

>>490の書き方は理解できるけど、>>501は果たして何をやりたいのか
文を読んでも分かりません。

507ではないですが。

>>501
> VISITOR なんかでいちいち friend 指定して居られない時
これがわかりません。
「VISITORではいちいちfriend指定しなければならない」というのが伝わってきますが、
それはどんな理由でそんなことになるんでしょうか？
たぶん「VISITOR」という言葉の意味を明らかにしてもらわないと分からないと思います。

> 関数内ローカルクラスのメンバ関数にも RawHoge への参照を渡しちゃう
最初からこんなことができるように設計しておくのは賛同できません。

>>506によると、そのメンバの切り方を規約にまで持っていきそうな勢いですが、
RawHogeが既に存在しているとか、gccへのワークアラウンドの手法という
ならまだわかりますが、規約として、CHogeの設計の過程で
わざわざRawHogeを作る利点がさっぱりわかりません。

>>501
もう一度読み直し、自分なりに意訳してみた。こういう意図であってる？

ローカルクラスから親クラスのメンバにアクセスしたいことがある場合に、
アクセス制限を外すために friend を指定するのが面倒。
そのため、クラスの定義を、
「アクセス制限の無い実装に便利なレイヤ」
「アクセス制限を掛けた論理的に正しいレイヤ」
に分けると便利である。

確かに、ファンクタなどを使う場合には当てはまるように思う。
ただ、やっぱり「規約」に関する話ではないんじゃないかな。

話の腰を折って悪いが、日本語のローマ字もどき表記の
変数名とか関数名とかって、どうよ?

俺は我慢ならねえ。

あと、EUCのソースに半角カナでコメント書くとか、実害はありますでしょうか。
俺は我慢ならねえが。

ごめんね。愚痴ってみた。

＞EUCのソースに半角カナでコメント書くとか
何でEUC限定？3ﾊﾞｲﾄいるからもったいないとか？

>>511
いや、実例を挙げただけです。
感覚的に、2バイト使ってるくせに文字幅は1バイトなのが気持ち悪いです。
そんなのソースに混じらせたくないな、と。
実害があるのならはっきり禁止できるのになあ。

>>512
＞2バイト使ってるくせに文字幅は1バイト
3ﾊﾞｲﾄのtypoですね。

まあﾊﾞｲﾄ数と見た目の文字幅が違うのがｷﾓｲってのは分からなくも無いが、
そうするとUNICODE系は全滅よ？

失礼。EUC半角ｶﾅは2ﾊﾞｲﾄです。ﾎﾞｹﾎﾞｹすまそ。

>>513
今まで半角カナのEUCでの表現は2バイトだと思ってました。3バイトだったのか。
指摘ありがとうございます。となると余計に気持ち悪いなあ。

>>そうするとUNICODE系は全滅よ？
ぶるぶる。

>>514
正して頂いて助かりました。3バイトで記憶しなおすとこだった。
それにしても、やっぱし美しくないなあ。半角カナ。

ﾏｧｵｵﾑﾈﾊﾝｶｸｶﾅﾊﾖﾐﾂﾞﾗｲｶﾞﾅｰ｡

そもそもコメント書かないし

　　　　　　　{
}

なんでズレてんの？新でくれない？

>>519
長い引数リストでは
int func(int aaa,
　　　　　...
　　　　　int zzz)
ではなくて
int func (int aaa,
　　　　　...
　　　　　int zzz
　　　　　)
もしくは
int func (
　　　　　int aaa,
　　　　　...
　　　　　int zzz
　　　　　)
とするタイプですか？(ずれてるかもしれないが意図はくんでくれ)

もし　>>519 が下二つのどちらのタイプでもなく一番上のタイプなんだったら
自分の好みを押し付けてるだけのお前こそ死んでくれない？

519じゃない「そろえる派」の者ですが。

>>520
引数リストでは改行しません。えぇ80カラムとか糞喰らえですよ。
お前VT-100って言いたいだけちゃうんかと小一時間。

int f(aaa,...zzz)
　　int aaa;
　　...
　　int zzz;
{

>>523
爺さんは来なくていいよ

C由来の ｛ ｝ って、こうして必ず宗教論争になるからイヤなんだよなぁ
C++にしてもJavaにしてもなんで後継言語はこれ真似しちゃったんだろう（鬱

ｺﾞﾒｿ。C++出したのは不適切だった

>>526
まあC++の場合Cのプログラムがそのまま動くというのが要求にあったからなぁ

>>525
{}を使わないようなものはCの後継言語と呼べないし
{}が使われてない言語を嫌う人もいるし

CはBCPLの後継言語だが、BCPLは{}使わないはず。

揃ってないと、画面に思いっきり掌打浴びせてから業務に入るよね

揃わないとイヤ派はヒアドキュメントはどうすんのかね

一体何のヒアドキュメントの話なのかわからない(Perlやシェルじゃないよね？)けど
TCLとヒアドキュメントは使用禁止になりますた。

いやperlやシェルの話。
あれはどうやっても揃わないっしょ？

{}じゃねーし

じゃあ何で {} だけは揃ってないとイヤなんだ？
主張が一貫してないだろ。

> 主張が一貫してないだろ。
あれは主張してどうなるもんでもない仕様じゃないのか？

>>535
揃わないとイヤ派の主張って何よ。
主張内容が {}の位置を揃えたい なら一貫してるんじゃない？
もう少し抽象的にしても ブロックを形成する記号を揃えたい とかでも。

VB厨です。
メンバ変数のプレ(サ)フィックスにはなに使ってましゅ？
ここのとこケツにアンダスコアつけて使ってたんだけど、
激しく見づらいのね(->VBEの関数セパレータの罫線と重なる)。
でも m_ はヤなの。いやぁぁ〜
どしたらいいの！？

m_ しかない。
大文字小文字区別できないVBでは
m_ メンバ
v_ ByVal 引数
r_ ByRef 引数
みたいにして名前が重複するの避けてたな俺は。

C/C++のswitch文で意図的にfall throughするときは、何かしらコメントを入れる
というのは割と普通の規約だよね？

switch (foo) {
case 1:
　...　/* FALLTHRU */
case 2:
　...　/* FALLTHRU */
case 3:
　...
　break;
default:
　...
}

普通はfall throughなんてしないと思います。

>>540
うん。

fall throughなしという規約もありだと思うが、
べつにあっても普通じゃないということはない

できる、できないという状態をboolで返す関数を作るとしたら

bool canHoge();

でいいんだろうか？
ていうか、can以外、何かもっといいよーな言葉あったような気がするんだ思い当たらんです。

isHogableとか

hogeOrNot

・・・読みにく

enable disable

>>525
おれは{}の変わりに begin とかendとかで囲むのはもっと嫌だ。
VBとかPascalとかDelphiとか嫌い

単なる好き嫌いか。
論理的な裏付けが無いなら無視できるな

そうそう無視して下さい

if test $hoge eq $hige ; then
　hoge
else
　hoge
fi
よりも
if test $hoge eq $hige
then
　hoge
else
　hoge
fi

一般的なもんは able 系か。いわれてみれば良く使ってますね。
どもありがとうございますた。

{}を揃える揃えないで議論するおまいらは馬鹿ですか？

慣れているからという以外の理由のない揃えない派は馬鹿ヴァッカ

正直、どっちもしっくり来ん。
{
}
だとスカスカで気持ち悪いし、
　　　{
}
だと窮屈で気持ち悪い。普段は後者使ってるけどな。

この２つの中間はないのか、中間派。

void function() {

　　/*some code*/

　　　　　　　　　}
中間

ほれ、おめえさんがた忘れてますよ。
某有名どころのコーディング規則が中間派があるじゃないっすか。
これよ。これ。

if ( condition )
　　{
　　　　statement;
　　　　for ( ; ; )
　　　　　　{
　　　　　　　　break;
　　　　　　}
　　}

…俺これだけはなじめねえよ。

/* てかよく考えたら>>555の言によるとこいつはスカスカの方に含まれそうだな… */

// ところでこれ採用してるのどっかの有名どころだと思ったんだが、
// すっかり忘れちまった。GNUだっけか？

>>557
気持ち悪いなぁ・・・

GNUなら、
カッコのすぐ内側にスペースは置かない
インデントは2桁。

if (condition)
　{
　　statement;
　　for (;;)
　　　{
　　　　break;
　　　}
　}

>>559
bash使いだから
if [ $hoge -eq $bar ]
の関係で，括弧のあとにスペースを入れてします

>>559
ありがとう。やっぱGNUだったか。
いや、括弧内のスペースとかはすっかり忘れてたんだが、{ }の位置が
酷く印象に残っててな…なんにしろ個人的には勘弁して欲しいが。

あとインデント幅が大きいのは、ここプロポーショナルフォントなもんで
見づらいかなと思ったんす。余計なことしてスマソ。訂正thanks。



ってよく見たら>35付近で既出な罠＿|￣|○

まあ，インデントの幅くらいは，あとから一括して変えればいいわけだし。
インデント4桁は読みにくいかも根。

いやインデントはTABで、TABは４桁のスペースってのが
業界標準だと思ってましたが何か？


まあ別にTABが２文字でも８文字でもいいけどスペースとタブを混在させるのは
止めてほしい。

GNUのインデントスタイルの由来が知りたい。
どっからあんな変態的なインデントを思いついたんだろう。
しかもそれを薦める感覚がさっぱり。。

GPL でないアプリにソースがパクられたときにすぐわかるようにとか。

ｿﾚｶﾓ!!

ってか冗談抜きでありえそうで嫌だ

おもしろい

C-x h M-x indent-region

C-M-\

＞どっからあんな変態的なインデントを思いついたんだろう。
リチャード=ストールマンの顔をみればわかる。
あきらかに変態だ。

>>569
ｳﾎｯ…ｼﾗﾅｶｯﾀ。ｱﾘｶﾞﾄｳ

>>563
TABは8桁のスペースってのがVT100標準ですが何か？

> まあ別にTABが２文字でも８文字でもいいけどスペースとタブを混在させるのは
> 止めてほしい。
これはやや同意。

まあ、インデント幅は簡単に修正できるから、別にいいと言えばいいんだが。

>スペースとタブを混在させるのは止めてほしい。
禿同。

団お年気Kン資！
132桁表示ならまだしも、窓を沢山開ける可変長ではやってらんない。
いいかげんに色変えにして欲しい。
ネスティングが増すとどんどん白に近づくんだよ。いいだろ！

>>549






















誰にレスしているか明確にせよ！

見易さが異なる！

>>576
適度な空白は見易さのために重要だが、
空白を入れすぎると逆に見づらくなる。注意した方がいい。

この前switchのdefaultを一番初めに書くという人と一緒に仕事をしたんですが
イマイチ利点や理由がわかりませんでした。
規約でswitch文内のdefaultの位置を強制している所とかあるのでしょうか？
あるとすればどんな優位性がありますか？

C系のswitchだけでなく構造化BASICのSELECTやCOBOLのEVALUATEでもいいです。
皆さんのご意見をおねがいします。

defaultは考慮し忘れることがあるから、忘れないように最初に書くだけでは？

defaultという名前からすると「一番ありがち」な飛び先の感じがするから
最初にするのもまあうなづけるような気もする。

>>580
漏れは逆だなぁ。case 1, case 2とかきちんと書いていって
defaultは殆どは一番下になってる
寧ろ例外的な処理のイメージが強い。
ただ、「一番可能性がでかい」というときは一番上にしてるかな。

default は一番下かなぁ
if else で書くと、最後の else に相当するものだから、
例え可能性が大きくとも一番下にあるのが自然な気がする。

>>581-582
自分で書くときは一番最後にしてるが
580はプログラミングから外れた「デフォルト」の語感の話。

例えばてんやでは天丼と野菜丼を頼むと
「一丁、野菜丼一丁」と厨房内にコールするけど
これは天丼が一番数が出るからデフォルトになってるわけで。

俺はdefault以外の奴は「hook」っていうイメージだから、defaultより前に書く。
switch(value) の valueが下へ順番に飛んでいって途中のcaseで引っ掛ける感じ。

規約 13-2. switchのdefault: は必ず書くこと。

switch文で文字列比較したい！

なーんて考えたこと、ある？

>>586
もうやってる。

＃このスレ、言語非依存だよね？

C#中途半端すぎ。
どうせやるならあらゆる種類のオブジェクトをswitchできるようにすべきだったと思う。

>>586
たま〜にあるね。でも、出来ないから
swtich(str.charAt(0))とかやってる。
これだと可読性が極端に下がるんだよね。
仕方ないからコメント入れてるけど。

#define strswitch(str) switch(str.hash())

>>590
で、そのあとcase文どうするよ。

お忘れですか？
こんばんわ馬鹿避けの隔離スレですよ？

こんばん「わ」ですか・・・、確かに馬鹿のスレのようだ。

真のオブジェクト指向プログラマはswitch文を使わない！
すべてポリモーフィズムで解決する！

>>593
こんにちは
こんばんわ

こんばんは
の方が圧倒的に多かった…

1行が長すぎるとき、どのようインデントしますか？

BufferedReader in = new BufferedReader(new InputStreamReader(new URL("http://www.yahoo.co.jp/").openStream(), "euc-jp"));

BufferedReader in = new BufferedReader(
　　new InputStreamReader(new URL("http://www.yahoo.co.jp/").openStream(), "euc-jp"));

BufferedReader in = new BufferedReader(
　　　　　　　　　　　　　　　new InputStreamReader(
　　　　　　　　　　　　　　　　　new URL("http://www.yahoo.co.jp/").openStream(), "euc-jp"));

など。

あとTABとスペースの使い分けもありそう。

>>597
改行しない。

>597
eclipseに任せる。

>>599
Eclipse使ったことないんだけど自動で整形してくれるの？

理想の規約その 001:
1行が長すぎるときは新しいディスプレイとビデオカードを上司に要求する。要求された上司はこれを正当な理由なしに断る事は許されない。

>>601
恋愛同盟規約ですか？

BufferedReader in = new BufferedReader(
　　new InputStreamReader(
　　　　new URL(
　　　　　　"http://www.yahoo.co.jp/"
　　　　).openStream(
　　　　), "euc-jp"
　　)
);

BufferedReader in = new BufferedReader
(
　　new InputStreamReader
　　(
　　　　new URL
　　　　(
　　　　　　"http://www.yahoo.co.jp/"
　　　　).openStream
　　　　(
　　　　), "euc-jp"
　　)
);

BufferedReader in = new BufferedReader
　　(
　　　　new InputStreamReader
　　　　　　(
　　　　　　　　new URL
　　　　　　　　　　(
　　　　　　　　　　　　"http://www.yahoo.co.jp/"
　　　　　　　　　　).openStream
　　　　　　　　　　　　(
　　　　　　　　　　　　), "euc-jp"
　　　　　　)
　　);

コーディング規約を決めるとしたら、
return( exp ); // ←この括弧
は禁止しますか？
禁止するとしたら、どんな根拠を挙げますか？

いくつか知ってはいるのですが、
・Cでtypoしてもコンパイルエラーにならない。
　（でも、C++か、最近のコンパイラなら特に痛くない）
・コードを読んだ初心者が関数と混同してしまうのを避ける。
　（でも、混同しててもたいした実害は無かったりする）
括弧つけるのに慣れた人に強制するほどの強い根拠が思い浮かびません。

>>605
その括弧は単に式中の括弧でしかないので
returnに限ってどうこうっていうルールを決めるのは馬鹿げている。

>>577
> >>576
> 適度な空白は見易さのために重要だが、
> 空白を入れすぎると逆に見づらくなる。注意した方がいい。
多分、>>549を皮肉って空白をつけたと

>>605
予約語と「（」の間には空白を一文字入れるって規約にすれば？
if (
とか
return (
とかね。>>606が言うように、括弧禁止は馬鹿げてる。

>>605
> 禁止するとしたら、どんな根拠を挙げますか？

returnは関数ではない。

return ( (double)method() + ((Double)clone()).doubleValue().method2() ) / 2;

ならどっちみち()がいる。
読みやすさのため

return ( ( (double)method() + ((Double)clone()).doubleValue().method2() ) / 2 );
とすることも。
けど、インデントしたり変数を新たに用意してもっと読みやすくするのが普通か。

>>609
if も whileも forも関数じゃないのですが、括弧を禁止しますか？

>>610
そもそも、その書き方を禁止する場合もありかと。
関数の戻り値をreturnにしたり、条件文にしたり。

goto (test);

>>602
('A`)ﾉｼ http://pc.2ch.net/test/read.cgi/prog/1058283090/

>>605
　　>>608に同じ。
ところで、sizeof は後に括弧付ける？　付けない？

>>614
対象が型名なら付けるが、値なら基本的に付けてない
(というか、文法上前者は括弧必須というだけだし)

必要のない括弧は、式の優先順位を制御するか誤読を防止する目的以外では
付けない、とかいうルールになるならいいな。

>>614
トン

>>594
それでもファクトリメソッド内のswitchだけはどうにもならん。

Loki::Factoryに任せるヨロシ
なんでBoostにないんだろう?

sizeofは、括弧が必要な場合と不要な場合があるわけだが、
いちいち覚えてられないので、常に括弧をつける。
ただし、sizeofの出番は、あまり多くない。

> sizeofは、括弧が必要な場合と不要な場合があるわけだが、
> いちいち覚えてられないので、

だめだこりゃ。

>>620
そういうキミは演算子の優先順位を全部覚えて
増長な括弧は全て省いてるのかね

sizeof(型名)ではなくsizeofキャスト演算子だと聞いてそのときは納得したのだが
なにか違う気がする

式中の括弧であれば、みなさんおっしゃるとおり何も問題ないんですが、
「returnに限って必ず括弧をつける」というスタイルで書いてる人がいるんです。

int a = exp; // ←ここに括弧はない
return( exp ); // ←同じ式でもここなら括弧がつく

馬鹿げていると思うので早目にやめてほしいんですけど、
やめるように説得できるほどの根拠がないのです。

いちおう「returnは文ですか？関数ですか？」と聞いたら
「文、でしょう？」と返ってきたので関数だと思ってつけてるのではないのです。

>>621
演算子の優先順位はともかく、sizeofの判別は
「型か、値か」であって、それぐらいは判断できるだろうに。

return(exp);派はK&Rまで遡るだろうから直すのはつらいんでないか

>>624
abs(x)で済むところを if(x<0) x=-x; と書くような人ですか？

>>626
どういう論理でそういう結論になるの?(笑)

>>626
abs(x)とif(x<0) x=-x; は全く違う処理だが

ごめん、abs(x)なら((x<0):-x:x)だね。

>>624
判断が不要な場合でも明示的な判断を好む人ですか？

むわぁ..ごめんよ。
もう寝るよ

>629

違ったらすいません。知的障害者の方ですか？

>>629
そのほうが簡潔になるなら。
だからabsをわざわざ展開したりしないし、すでにあるものは可能な限り利用するが。

>((x<0):-x:x)

アメリカ風顔文字の一種ですかコレは？

「すべての関数に関数ヘッダを付ける」がうざいです

>>633
ということにしたいのですね((x<0):-x:x)

sizeof は括弧を付いてるのと付いてないのが混ざってると何となく気持ち悪いので
変数の場合でもあえて括弧をつける。

>>634
関数ヘッダってコメントのこと? プロトタイプ宣言のこと?
コメントかな。まあDoxygenとかを必須としてる所でならいいけど
そうでない手動モノならうざいねー。特に無意味に線並べたり装飾しろってやつ。

Cスタイルキャストとかsizeof値とかはぱっと見、適応範囲が見づらいので、
C++キャスト群にしたり、()を補ったりする。

>>638
C++ style castは括弧が必須なので論争の余地がなくていいね。

>>623
return って昔は関数として実装してる処理系もあったんじゃなかったっけ？
まあ、生きた化石には違いないが＜returnに括弧つける人。

>640
どうやったらreturnを関数として実装できるんだよ、ヴォケ。

y = (x + 2); が規約上OKならば return (x + 2); もOK。
z = (x) が規約上OKならば、 return (x); もOK。

if ((x < 2)) が規約上OKならば、 return (x < 2); もOK。

式全体を不必要な括弧で囲むことを禁止すれば、
return (式); も当然禁止される。

ちょっと違うな。

× y = (x + 2); が規約上OKならば return (x + 2); もOK。
× z = (x) が規約上OKならば、 return (x); もOK。

○ (y = x + 2); が規約上OKならば return (x + 2); もOK。
○ (z = x) が規約上OKならば、 return (x); もOK。
○ (++i); が規約上OKならば、 return (++i) もOK。

return(戻り値);は、retrun(戻り値);とか間違えたときに鬱陶しい。

右手と左手を交互の打つ単語は入れ替わりやすいな
俺の場合、
　　　　printf 30%
　　　　prtinf 30%
　　　　pritnf 40%
ぐらいの割合で間違えるよ

間違えるほうが多いのかよ。

>>644
異常に間違えすぎ

関数の最後に書いた式の値が戻り値になるとかそういうの？　＜関数でreturn実装
でもCだと無理じゃないの？

スタックフレームを辿って戻りアドレスを得てジャンプするだけだから不可能ではない
戻りアドレス用の独自スタックを持ってもいいし

意味無いが

よく間違えるのは
itn
flaot
だな。

>>641
戻り値の格納場所に値を入れて、関数呼び出し元にジャンプするインライン関数みたいなもの。

perl だと return 関数っていうし。
sub から抜けるための関数。

>>650
perl の return を関数と呼ぶなら、 perl では do も goto も last も next も sub も
関数なわけで、Ｃの「関数」とは概念がまったく違うだろう。

man perlfunc に書いてあるものが全部“関数”だと考える場合の話だが。

function を関数と訳した数学馬鹿に全ての語弊の責任がある。

function -> 機能

だろ？

>>652
じゃあ，「function -> 機能」に対応する procedure の訳語は何よ？

蒙古の寝た秋田よ

敗北宣言ｷﾀｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰ!!!!!!!!

perlの場合functionは機能でいいんじゃないかな
関数に相当するのはsub routine

関数値があるものは関数
副作用しか及ぼさないものは手続き

邦訳せんでも良いじゃないか

>>657
return value(result value)があるものは function.
副作用しか及ぼさないものは procedure.

はおかしいだろ。
ところでこの場合の副作用の訳は harmful aftereffect か side effect なのか？
変な意訳はこういう時困るよな

>>659
> ところでこの場合の副作用の訳は harmful aftereffect か side effect なのか？
side effect

副作用って普通に使われる言葉なわけだが。

>>651
まるでSmalltalk

びっくりするほどSmalltalk!!
びっくりするほどSmalltalk!!

コーディング規約からどんどん離れてるな。

>>660
お前はパスカラーだな

RESULTIS i

グローバル変数のprefixはglobalScopedVariable_でいいですか？

>>667
bakaAhoShine
動詞は頭に来る
メソッド名にしか使わない。

>>668
動詞に見えましたか？

>>667
普通に g_ でいいじゃん。

>>669
668 は 667 を「グローバルがバリアブルをスコープした」って読んだんだろ。

Golgo Scoped >>671

>>668
動詞が頭なら shineBakaAho ではないのか？

>>671
まて、死に急ぐな。

>>667
>>670
グローバル変数は使用禁止。

>>764
状況によると思うぞ。
必要もないのにグローバルにするのは俺も反対だけど。

>>675
どういうとき必要？
これは難しい質問だと思うぞ。

>>676
組込み DSP とかで RAM にマッピングするときとか。

>>677
ああ、そうきたか・・・・。
ま、本来の変数とは、ちと意味が違うような気もするが、確かに形式はそうだな。

なんか助っ人みたいな感じの仕事貰って
さっそくソースコードが届いたんだけど，
ほとんどコーディング規約に沿ってないのな。

ﾓﾚは別にどんなコーディングスタイルでもいいんだけど，
これ，このまま出したって「コーディング規約に沿ってないよ」って
突き返されるんだよな(ﾉд`)やる気出ねー

ただただ、黙々と、明記されている規約に忠実になるしかないねぇ。

規約自体が自己矛盾してないことを祈ります。

仕事だとつらいとこだね…
まず規約どおりに書き直すことからはじめないとな。
間違っても変なとこ直して妙なバグ紛れ込ませたりしないようにな。
特に一括置換は注意だ。ちゃんと確認しような。

>>679
どういう命令系統になってるかしらないけど、事前にどうすればよいか確認すりゃいいんじゃねーの？
別に作業が終わるまでそいつと音信不通ってわけじゃないんだろ？

>>679
そのコーディング規約に則ってないソース渡しておきながら、
コーディング規約に従ってないって突っ返してくるクライアント
って、何考えてるんだろ？　と何時も思う。

白痴なのかな？

>>682
同意。

確認も取れないんじゃ
コーディング規約の問題なんて瑣末に思えることが
すぐに起きるぞぉ。

>>682 >>684
そのあたりは部長がやかましい程なんで，大丈夫かと (苦笑
そもそも，前回の仕事で，コーディング規約に沿っていない部分に気づかずに
そのまま提出してたら突っ返されて来た，つー経緯があるんで
確認とるまでもなかったんだけど・・・

つーか，突っ返して来るのは，もうわかった。仕事だ。やるとも。
でもね，突っ返して来る時にね，

改悪してるのは何故よ。

A`;)ﾉ すいませんﾓﾚ今日もう帰ります

グローバル否定派もここまできた。

ついにグローバル定数まで否定するツワモノ現る。
http://pc2.2ch.net/test/read.cgi/tech/1011026963/425-

Javaライブラリのクラス名、関数名が一番美しいと思うが、もっと良い例はあるか？

>>687
ドトネトのライブラリ。

.netはいいね。

>>686
いや、別に強者じゃないし、const staticな定数はnamespaceに包むのが普通だろ。
Cじゃないんだから。

>>690
> それでも定数はクラス内に書く。大抵の場合は一番関係が深いクラスが存在するからな。
> つまり名前空間の中にあるクラスの中に、だ。

モーニング疑惑

唐突ですみませんが、コーディング規約に
沿っているかどうかを自動判別するツールって
あるんですか？

ない

有名どころのコーディング規約に関してチェックしてくれるやつだったらある。
各項目について on/off できるが
自分で決めたコーディング規約を設定できるものは知らない。

ソースコードのハンガリアン度を判定するソフトとか作ったら面白そうだな。

>693
Checkstyle Home Page
http://checkstyle.sourceforge.net/

Checkstyle ホームページ 日本語訳
http://www003.upp.so-net.ne.jp/kaz-taka/checkstyle/

>693
codewizard C/C++対応ソースコード分析ツール
http://www.techmatrix.co.jp/asq/codewizard/

コーディング規約を強制することって
メリットよりデメリットの法が大きい気がするよ
ストレスたまるしさぁ
万人に共通のスタイルなんて無いのだし

>>699
守るべき規則とそうでないものを分けるのが重要なのであって、
規則を強制すること自体が悪いのではない。

法は悪だ

>>699
言葉が抜けているぞ

× コーディング規約を
○ アフォの作ったコーディング規約を

ちゃんと出来たコーディング規約は生産性も保守性も
上がる良いものでつ。

>>702
どんな要件を満たせば、「ちゃんと」なの？
てか、これに答えられない人は「ちゃんと出来たコーディング規約」を
作れない事になっちゃうのかな？

>>703
そんなもん技術レベルによって変わるだろ。そんなこともわかんねーのか？
STL使用禁止等はその典型。
だいたい「ちゃんと出来たコーディング規約」が定義できるんなら論争など起こらない。

>>704
技術レベルに見合っている事も要件の一つだろうな。それくらい分からないかな。
で、この要件も技術レベルによって変わるのか？

「少なくとも、同一プロジェクト内では
　一定のコーディング規約を守ってもらわないと困る」

ここまではOK？

変数名や関数名には必ず人名を冠する。

tanaka_makiko_num
suzuki_muneo_str

これで責任の所在もはっきりし、ボーナスや懲戒の査定もバッチリ。

STLうんぬんって・・・
ライブラリの選定をコーディング規約に含めちゃう人達って何なんだろう・・・

言語の標準ライブラリをライブラリの選定に（以下略）

>>708
書けない人がいると困るから、規約はチームで
一番能力の低い人に合わせて決めます（藁

「俺が使えないもんはお前らも使うな」とも言う。

>>710
以前一緒に仕事をした上司をチームに入れ、それを適用したら悪夢だべ。
ポインタや構造体すら禁止だぞ…

うちなんて変数使用禁止だYO!(^o^;)

コーディング規約は効率をアップさせるためのものであって
ダウンさせるためのものではないってことかな。

雨が降ろうが槍が降ろうが厳密に守らせるのはどうかと思う次第。

開発スタイルに拠るだろ。

受け継がれながらいろいろな人が触るソースもあれば、
(特にパッケージ物だと)一定期間がたったら御役御免になるソースもある。

一定期間の間にプロジェクトメンバの複数人が触るソースもあれば、
特定の1人しか触らないソースもある。

それぞれの後者の場合は、外に向けてのインターフェイスがしっかりしていれば、
内側でコーディング規約が守られていなくてもどうという事はない。

つまり、「当たらなければ(他人が読まないなら)どうという事は無い。」

>>713
ごもっとも。

プログラム知らない奴が規約作るからえらいことになる。

>>714
将来、他人が読む可能性があるか無いか誰が判断するの？
おまえ？

とりあえずアホなコーディング規約として
ソースを消すなとかはやめてほしい

バージョン管理とかしてるのに
あ、行数から算出するアホな品質会計とかあったか

>>716
この月光、生来目が見えぬ

if文にはかならず{}を使うこと、そして処理が無くてもelseは必ず記述すること。
もう、アフォかバ(ry

if (hoge)
{
　　hoge;
}
else
{
}

{} は分かるが
else はやりすぎだと思うな

Cは冗長性を嫌う言語。
これでええやん！

if (hoge)
　　hoge;

>>720
ｳﾞｧｶPGでもぶら下がりelseの罠に掛からないように、かな。
その罠をすら知らないPGなぞ即刻首にしたいところだが。

曖昧な else が変なインデントされていて PG が誤解したり
if の取る命令が 1文ではなくなったときに {} 増やすのが面倒
などの理由が考えられるな

必ず{}で囲めばぶら下がりelse問題は起きないっしょ。

必ずelseの規約なんかあったらブチ切れるね

>>724
そういう規約って

else
{
　　/* 処理なし */
}

とか書かないと逝けないことになってる。ｗ

必ず{}は自主的にやってるが、elseもか。なんというか、壮絶だな。

そういう規約なら書きゃいいじゃん。きみたちプロなんでしょ？

元々、「elseの場合はどうなるのかちゃんと考えろ！」つーことだったが
何も考えずに無条件にelseを記述するようになってしまったので

意　味　ね　ー　じ　ゃ　ん　！

つーこと。ｗ

>>728
本末転倒を通り越して逆効果じゃん。

まぁ過剰ネストを抑止するくらいの効果はあるかもな。

なるほど

>>719はまだ可愛い方だよ。
↓みたいな命名規約を強制される事に比べれば。

　株式 → KBS02
　会社 → KSY01
　株式会社 → KBSKSY00

更に仕事の内容は

　if( 価格 > 希望小売価格 )

とかいう形で設計担当チームから送られてくるコードを、
前述の規約に従い人力で変換し、入力&コンパイルする事。
しかもロジックが間違ってても、勝手に修正するのは厳禁。

>>732
価格　⇒ KKU01
希望　⇒ KBU02
小売　⇒ KUR03

希望小売価格 ⇒ KKUKBUKUR00

if (KKU01 > KKUKBUKUR00)

あひゃひゃひゃひゃ。ｗ

間違えたw

希望小売価格 ⇒ KBUKURKKU00

あひゃひゃひゃ。こりゃたまらん！

KBKRKKK

コボラな人が命名したんだろ？
あるシステムのI/Fで出会ったことがある。
RDBなのになんでも６文字規制。
わかりにくいったらありゃしない。

コードを修正するときは、
元のコードをコメントアウトして
修正開始箇所と終了箇所のコメントを入れて
修正日時と名前を入れるように指示されています。

ありふれた規約だな
間違ってるのは言うまでもないが

if(flag){　　　　　　　　　　//flagがtrueの場合
　 printf("true\n");　　　//true表示
}else{
　 printf("false\n");　　 //false表示
}

自分、上みたいにコメント揃える癖があるんですが
こんな風に揃える人いますか？ 不揃いだとコードが見難くないですか？
自分はコメント揃えるマクロまで作ってます。

右出しコメントはTabで揃えてる。
ただ、Tabは環境や設定によって文字数がどうにでも可変するから
滅多に使わない。普通は下出しコメントにしてる。

if(flag){ //flagがtrueの場合
　 printf("true\n");//true表示
}else{
　 printf("false\n");//false表示
}

>>740
上みたいに書く人が居るんですけど、こういうのがイヤなんですよね。
なんというか、プログラムコード自体とコメントはなるべく分離したいんですよ。
だから僕の場合は殆どが右出しコメントで揃えてますね。

ちょっと話題が違うんですが
>>459にインターフェースクラスってありますが
あれはCOMのインターフェースのような事を言うのでしょうか？

>>741
見た目気持ち悪いというのは分かる

>>741
まあ気持ち悪いってのは慣れだげどな。
私は逆に右揃えのほうが気持ち悪い。
まあ大きな理由は>>740だが。そもそも揃わないので汚い。

//flagのチェック
if(flag){
　　//true表示
　　printf("true\n");
}else{
　　//false表示
　　printf("false\n");
}

こんなコードの内容をそのまま書くようなコメントは書かなけどな。
一行ごとにコメントなんかかかないし。
右に書くのは変数宣言のときぐらい。

そもそもやってることが一目でわからないようなコードは
コメントではなく関数に切り出して名前で説明しる

漏れは左端にしかTabは使わん。
それでいてコメントや変数宣言は右側そろえる。もちろんスペースで

void CheckHogeHageForDebug()
{
　<tab>　int 　　　 hogeAndBokeCnt　= 　 　 20; // デスマでホゲ/ボケてしまった人数
　<tab>　long　int hageCnt 　　　　　　=　10030; // デスマでハゲてしまった人数
}

ネタですか？　すごく托いソースですね。

ひぇ〜やめてくれぇ〜

>>747
僕もこの書き方と同じです。
見やすい方が良いですよね。

ネタですか？　すごくキモいソースですね。

見やすいか見やすくないかは個人の自由ではあるが、こんな手間のかかることを普通はしないから
他人のソース読むときイライラしてそうだね。

あと

void CheckHogeHageForDebug()
{
　<tab>　int 　　　 hogeAndBokeCnt　= 　 　 20; // デスマでホゲ/ボケてしまった人数
　<tab>　long　int hageCnt 　　　　　　=　10030; // デスマでハゲてしまった人数
　
　<tab>　long_long_type_name long_long_variable_name = 100;//
}

こんな変数名を追加する必要が出て周りをまたそろえ直してるときイライラしてそうだね

>>752
自分で書いたマクロで揃えます。

void CheckHogeHageForDebug()
{
　<tab>　int 　　　　　　　　　　　hogeAndBokeCnt　　　　　= 　 　 20; // デスマでホゲ/ボケてしまった人数
　<tab>　long　int 　　　　　　　 hageCnt 　　　　　　　　　　=　10030; // デスマでハゲてしまった人数
　
　<tab>　long_long_type_name long_long_variable_name = 　　100;//
}

マジで読みやすいか？

つーかそもそも関数の先頭でローカル変数宣言するってとこがもう托いよ

>>つーかそもそも関数の先頭でローカル変数宣言するってとこがもう托いよ
Cだとブロックの先頭でしか宣言出来ません。

んなこたぁ知ってるけど、マジでC使ってんの？

>>756
すみません。僕は>>754さんじゃないので分かりませんが
まぁこれは単なるサンプルコードですので。

>>747
某有名ページで「ダメな書き方」とされている

>>758
具体的に何がダメなのか聞きたいね。

>>759
>>758のページに書かれてるかどうかは知らないが、その書き方だと編集するときに
既存のフォーマットにあわせる労力が必要になる。特に他人が書いたコードを編集する
ときはそれがすごく苦痛。

>>759
diff とかしたときに悲しくなる。

>>760
確かにそういう場合は大変かもしれませんね。
コメントだけは自分はマクロで揃えますが。

自分が見やすい書き方が一番かと。

>>760より>>761の方が重要だろ。
>>760はコーディング規約全般が該当する。

>>763
それじゃだめだから規則とか規約とかがあるんだしょ
他人のｺｰﾄﾞ自体見るの嫌だけどな＿|￣|○

>>759
一番長いのにそろえるせいで変数の型と、名前と、値が離れがちになって、しかもそれぞれの頭がそろってるから途中で行ズレしたりして激しく読みづらい。
MSのソースとか見てると良く思う。

ということを以前にも書いたような気がする。。。。

>>764
えええ！
今までよりももっと長い変数を追加するときは、全部修正するってことか。その発想は無かったよ。
それならdiffで問題が出るな。

おまいら未だに生のdiffコマンドでソース検索してんの？
正規表現くらいサポートしてるの使えよ。

>>750
なんか圧倒的に形勢不利な所で一人でも仲間がいてくれて嬉しいっす。

>>754
＞757も書いてくれてるけど、あれはサンプルっす。
通常はブロック途中で。それでも2行以上続く場合の話です。

>>758
有名サイト == 優れたサイトじゃないのは某猫ワカとかを見る限りは確実ですよね。
特にこういうスタイル論は超一流の人の意見でも常人には受け入れがたいものだったりします。
それでもあえて聞きたいのですが、その有名サイトって？

>>メンテめんどいって書いてる香具師ら全て
選択範囲に対して整列かけるマクロ組むといいよ。
この用途以外にも色々使えるから。

>>747
控えめに言って、ﾊｧ?

>>766　さんの意見は無視ですか？

>>768
diffではファイルの検索はしませんが。

>>768
diffはファイルの差分を取るプログラムだよ。知ったかぶりは恥ずかし過ぎるｗ

盛んにマクロマクロと主張してるが
diff (さらには patch や cvs もだろう) も使ってないとは。
そんなアホなことに労力使うくらいなら
もっと別のところに使えよ。

何か話が違う方向に行ってる気がしますが…
僕はただ単にコメントを揃えるって事が言いたかったのですが…
でも確かに>>747さんみたいに変数とかも揃える癖は確かにありますね。

まぁそれでも、他人が違うコーディングスタイルで書いている場合には
その慣習に従って書いたりもしますし、そのへんは柔軟に対応してますね。
>>752にみたいに長い名前の変数を追加する必要があった場合でも
あまり意固地になって揃え直す事はしませんね(あんまりバラバラだと揃えますが)。

>>773
確かにそう思う所もありますが
見やすいコーディングスタイルを追求するのも大切な事だと思いますけどねぇ…

>>774
わざわざ揃え直すと、本来変更されていないはずの行が変更されたことになってしまう。
バージョン間の差分を取ったりした時にすごく変。

変数はスコープを出来るだけ短くするために
使用する直前から直後までを{}で囲んで使うから
そんな何個も連続して宣言することなんてめったに無いけどなぁ。

>>776
そういう問題がある場合は無理に揃える事はしません。
でも、自分なりのコードの書き方を追求していくと
やはり揃えたいという所がありますね…

>>777
変数宣言というか、代入文が続いたりする場合もあると思いますよ。

hogeAndBokeCnt　　　　　 = 20;　　 // デスマでホゲ/ボケてしまった人数
hageCnt　　　　　　　　　=　10030; // デスマでハゲてしまった人数
long_long_variable_name = 100;　　//長い変数名

ここでは上手く揃わないのがくやしいですが…

もしかしたら「みんなも揃えたいんだけど色々な理由で我慢してるんだ」と思ってるかも知れないけど、
変に揃える方が余計汚く見える（要するに空白の数が揃ってない）って思ってるやつもいる。俺だけかも。

>>779
書いてる本人は自己満足してていいかもしれないけど、
読む人間にとってはどの変数にどの値を代入しているのか分かりにくくなるんです。

>>780
その辺は、人それぞれの性格にもよりますしね。どうなんでしょうかね？

>>779
コンストラクタはどうすんの？
class Hoge hogeAndBokeCnt　 　　(2,0);
class Hoge hageCnt　　　　　　　　　(2,0);
class Hoge long_long_variable_name(2,0);

？

>>781
人それぞれ性格が違いますからね… 難しい問題です。

>>783
う〜ん、僕の場合はコンストラクタまでは揃えないですね。
でも、

if(hageCnt < 200){ hageCnt++; 　}
else　　　　　　　{ hageCnt = 0; }

はしますね。

>>779
> long_long_variable_name = 100;　　//長い変数名
この行を削除したとき、ほかの行はどうするの？

>>784
ﾏｼﾞかよｗ

>>785
上二つは揃ってますので、そのままにしておくと思います。
う〜ん、なんだか色々突っ込まれてますね…

>>784
＞う〜ん、僕の場合はコンストラクタまでは揃えないですね。
一貫性が無いな。
プリミティブ変数は揃えてクラス変数は揃えないってのは結局「揃ってない」じゃん。

クラス変数とプリミティブ変数が混じった時はどうすんの？
意味的にグループA、グループBと分けられる時、
プリミティブ変数は揃えてクラス変数は揃えない場合

// グループAの変数
class Hoge hogeAndBokeCnt(2,0);
class Hoge hageCnt(2,0);
hogeAndBokeCnt　　　　　 = 20;　　 // デスマでホゲ/ボケてしまった人数

// グループBの変数
class Hoge long_long_variable_name(2,0);
hageCnt　　　　　 　　　　=　10030; // デスマでハゲてしまった人数
long_long_variable_name = 100;　　//長い変数名

ってなるけど、これ、ほんとに揃ってるの？

>>787
そうすると、
> hogeAndBokeCnt　　　　　 = 20;　　 // デスマでホゲ/ボケてしまった人数
> hageCnt　　　　　　　　　=　10030; // デスマでハゲてしまった人数
と、間抜けな状態になってしまいますが。

>>784
コンストラクタは揃えないとすると、こういう場合は揃えるわけ？
class Hoge hogeAndBokeCnt　= Hoge(2,0);
class Hoge hageCnt　　　　　　 = Hoge(2,0);
long_long_variable_name 　　　　= 100;　　//長い変数名

>>786
確かにここまでやるかって気はしますね… 自分の事ながら。
でも揃えたいなぁ…

っていうか、揃えないことにしたほうがいいんじゃないの？
精神的にも肉体的にも（ｗ

俺も以前はそろえてたこともある、メンバ関数と変数だけど。
だけど型名がやたら長いやつだけ食い込んで結局見にくくなるのであきらめた。
もともとC系の 型名 識別名 の書き方は見にくいように出来てるので開き直った。

レスいっぱい来ましたね…

>>788
確かに788さんが記述されている状態に近い形式になると思いますね。
グループAの場合の「hogeAndBokeCnt」の「=」は離さないと思いますが。

>>789
確かにその通りです… 少しばかり変ですが…

>>790
その場合は揃えると思います。
そもそもクラス変数がどうとか、コンストラクタがどうとかいう事ではなく
その時その時で見難ければ揃える感じですね。

なんだかまた突っ込まれそうですが…

メンバのたくさんある構造体を初期化するときとか、
そろえないと激しく見にくいこともある。

確かに788さんが言われている通り、一貫性がないのかもしれませんが
あまり意固地になりすぎると、793さんの様になった場合
自分の中で破綻しそうなので、ケースバイケースと言いますか、もう少し柔軟に考える様にしてます。

>>794
根本的な問題は、
int abc = 10;
int def = 20;
とあったときに、int ghijklmn = 30を追加する必要が出て、それを追加するために
abc、defの行まで修正してしまったらdiffで差分が出てしまうということ。
オプションで複数のホワイトスペースをひとつとみなすdiffもあるだろうが（gnu diff
がそうかどうかは知らない）、デフォルトでは違いがあるとみなされてしまうだろう。

だから他人のコードを変更する必要があったときに、すでにあるコードはさわっちゃ
いけないんだ。

もちろんdiffを必要としないような開発環境であれば、やり放題だが。

>>797
なるほど、確かにそういう場合だと触らない方が良いですね。
というか、そういう場合無理に自分流で書いてしまうと
他から反感食らうでしょうから、さすがにその場合はいじりませんが。

>>798
一人でやる分には自由にやるのがいいと思う。
しかしここは2chなので自分の主張を傲慢に他人に押し付けあう方が面白いｗ

うむ！diffとgrepを勘違いした事は認めるぞ！
しかしそれ以外は…！時間が無いのでまた今夜！

>>800
このタイミングで謝れないってのはどういう神経してるんだろうね？

>オプションで複数のホワイトスペースをひとつとみなすdiffもあるだろうが（gnu diff
>がそうかどうかは知らない）、デフォルトでは違いがあるとみなされてしまうだろう。

手元のdiffでは-bオプションがそうだった。

>だから他人のコードを変更する必要があったときに、すでにあるコードはさわっちゃ
>いけないんだ。

正確には、「意味が変わっていないコードは変更しない。」ってことだな。

long_long_variable_nameを削除した場合、本来なら

- long_long_variable_name = 100;　　//長い変数名

というパッチであるはずが、

- hogeAndBokeCnt　　　　= 20;　　 // デスマでホゲ/ボケてしまった人数
- hageCnt　　　　　　　　 　= 10030; // デスマでハゲてしまった人数
- long_long_variable_name = 100;　　//長い変数名
+ hogeAndBokeCnt = 20;　　 // デスマでホゲ/ボケてしまった人数
+ hageCnt　　　　　　= 10030; // デスマでハゲてしまった人数

になってしまうのは何とも思わないんだろうか。
パッチを当てる対象でhageCntがなかったらパッチが当たらなくなってしまう。
long_long_variable_nameを消したいだけなのにどうしてhageCntに依存する必要があるのか。いやない。