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

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

コーディング規約

1 :1:03/06/27 21:18
まじめに議論

2 :デフォルトの名無しさん:03/06/27 21:19
    ,. -──- 、
   /______ヽ
    i ニニ  .ニニ i
  ├{_へ_}{_へ_}┤
    !   ┌‐┐  !
   ヽ、 ヽ_ノ  ノ
       "" ̄
■■■かわいそうな「ゲーム君」を2ちゃんの力でトップにしよう!■■■

HSPプログラムコンテスト2003オンライン投票
http://www.onionsoft.net/hsp/contest2003/entryn1.html
 
HSPプログラムコンテスト2003に一番乗りで出展したものの              
Windowsに標準でついてくるゲームを手軽に起動できるという(というかただのショートカットつめあわせ)
しょーもないプログラムでたたかれまくっているプログラミング暦3年(!)の高校生の
作品、ゲーム君をみんなの力で一位にしよう。
【【【 投票方法 】】】                                 
http://www.onionsoft.net/hsp/contest2003/entryn1.html の一番下、エントリーNo8の「ゲーム君」
評価を「A」で選んでコメントを記入して「送信」(コメントいれるとなおよし)           
http://www.onionsoft.net/hsp/contest2003/eval/eval.cgi?md=cmt&id=8
でいままで送信されたコメントが見えるよ!(けっこう笑える)  

3 : :03/06/27 21:31
C++だといつも話題になるのが大文字小文字まぜまぜ派とアンスコ連結派

ExecelentCodingRule
execelent_coding_rule

前者の方が最初は気に入っていたが、stlやboostが後者なので今は後者が
お気に入り。
後者のほうが読みやすい気もするけど、文字数は多くなる

4 :デフォルトの名無しさん:03/06/27 21:33
excellentだなw

5 :デフォルトの名無しさん:03/06/27 21:33
VB厨必須。

6 :デフォルトの名無しさん:03/06/27 21:36
http://www.30girl.com/top.html
レースクイーンだよ!

7 :_:03/06/27 21:38
http://homepage.mac.com/hiroyuki44/

8 :デフォルトの名無しさん:03/06/27 21:47
インスタンス変数名と引数名が同じ物を現してる場合どうやって区別つけてる?
今まで見たのは、
1)インスタンス変数の先頭か末尾に_をつける。
2)引き数の先頭か末尾に_をつける。
3)同名でインスタンス変数はthis.hogeにする。
という感じなんだけど。
私はC++では1、C#では3にしてる。

9 :デフォルトの名無しさん:03/06/27 21:59
かぶり気味

★★★コーディングマナー★★★
http://pc2.2ch.net/test/read.cgi/tech/1056508692/

10 :デフォルトの名無しさん:03/06/27 23:29
>>8
識別子の先頭にアンダースコアは使えない。

11 :デフォルトの名無しさん:03/06/28 00:48
規約とマナーは違うのでは?

12 :山崎 渉:03/07/15 10:28

 __∧_∧_
 |(  ^^ )| <寝るぽ(^^)
 |\⌒⌒⌒\
 \ |⌒⌒⌒~|         山崎渉
   ~ ̄ ̄ ̄ ̄

13 :山崎 渉:03/07/15 14:15

 __∧_∧_
 |(  ^^ )| <寝るぽ(^^)
 |\⌒⌒⌒\
 \ |⌒⌒⌒~|         山崎渉
   ~ ̄ ̄ ̄ ̄

14 :葦稲磯稲胃斡:03/07/17 14:39
葦稲磯稲胃斡

15 :デフォルトの名無しさん:03/08/01 19:29
クラス Foo
メンバ変数 m_fooBar
メンバ関数 fooBar
ローカル変数 foo_bar
定数 FOO_BAR

16 :デフォルトの名無しさん:03/08/01 20:09
>>15
言語を明記しないか?

17 :デフォルトの名無しさん:03/08/01 20:12
用語から判断すると C++


18 :デフォルトの名無しさん:03/08/01 20:51
ごめん、C++のつもりね

19 :デフォルトの名無しさん:03/08/01 21:03
>>15
>ローカル変数 foo_bar

配列の添え字なんかは foo_index とかやるんだ?
何かイヤダ

20 :デフォルトの名無しさん:03/08/01 21:19
何事にも例外はあるだろ。間に受けすぎ

21 :デフォルトの名無しさん:03/08/01 21:41
コレがいや。
if (expr)
{
/* do something */
}

こっちがいい。
if (expr) {
/* do something */
}

22 :デフォルトの名無しさん:03/08/01 22:11
俺ルール

2項演算子の前後に空白。
単項演算子と被演算子の間は空けない。
左括弧の右に空白をあけない。
右括弧の左に空白をあけない。
予約語と括弧の間をあける。
関数名と括弧の間は空けない。
if文、while文、for文の実行文は必ず複文とする。


23 :デフォルトの名無しさん:03/08/01 23:17
>>22
俺ルールというか、それは一般的なルールやね。

Javaで無限ループってどっちが多いんかな?
while (true) or for (;;)
俺はwhile派だけど。

24 :どっかの176:03/08/01 23:20
# クラス名・変数名に迷ったら書き込むスレ。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 って使いたくなると非常に困ってまわりくどくて長い名前とかになっちゃったりする。


25 :デフォルトの名無しさん:03/08/01 23:27
対抗俺ルール

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


複雑だな俺・・・

26 :デフォルトの名無しさん:03/08/01 23:41
> getHogeとGetHogeは機能が違うんだったら、caseに依存するのは命名がおかしい。
といちゃもんつけた者です。

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

27 :デフォルトの名無しさん:03/08/01 23:43
すまん。
>「クラス名・変数名」と「大文字小文字」は無関係だと思う・・・んだけどどうよ?
このいちゃもんも俺だった罠w

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

28 :デフォルトの名無しさん:03/08/01 23:45
>>22
全て俺と同じだ。

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

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

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

30 :24:03/08/02 00:09
>>22 >>28
よく見たら漏れもまったく同じだ。

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

31 :デフォルトの名無しさん:03/08/02 00:15
>>30
if (hoge == NULL) {
  Foo();
}

だな。

32 :~31/.indent.pro:03/08/02 00:16
-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


33 :デフォルトの名無しさん:03/08/02 00:29
第6条 ちゃんとJavadocコメント入れること!

34 :デフォルトの名無しさん:03/08/02 00:49
if (...) {
    ...
} else {
    ...
}
にしてくれ・・・

35 :デフォルトの名無しさん:03/08/02 00:58
GNU Coding Standardは激しくきもい

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

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


36 :デフォルトの名無しさん:03/08/02 01:01
こっちも貼っとこう。
ttp://www.sra.co.jp/public/sra/product/wingnut/standards/standards-ja_5.html#SEC22


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

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


1.
if (hoge == NULL)
{
 Foo();
}
2.
if (hoge == NULL) {
  Foo();
}

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

38 :デフォルトの名無しさん:03/08/02 01:09
if(...) // ここに判定についてのコメント
{// ここに真だった場合の処理を総括するコメント

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

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

板違いか。。。


40 :デフォルトの名無しさん:03/08/02 01:18
>>39 http://pc2.2ch.net/test/read.cgi/tech/1030563262/l50

41 :デフォルトの名無しさん:03/08/02 01:29
if(foo){
}
else{
// } と else は別の行に書く
}

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

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

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

43 :山崎 渉:03/08/02 02:04
(^^)

44 :デフォルトの名無しさん:03/08/02 02:32
>>42
> Wait -> wt (許容範囲外。コンテクストがあってかろうじて理解できる最低レベル)

こんなの普通しない。

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

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

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

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

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


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


46 :デフォルトの名無しさん:03/08/02 06:39
> msg_wt
なんか、わかる。
wait → wt なんかは機械系に多いかも…。open → o 、close → c とか。

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

47 :デフォルトの名無しさん:03/08/02 06:41
>>45
> 本当にバージョン管理システム使ってる?
CVS使ってる。

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

48 :デフォルトの名無しさん:03/08/02 10:44
>はじめからみんなが引っ掻き回してるソースならともかく、そうじゃなければ
>いちいちコミット状況調べない(調べてらんない)っしょ。

cvs annotate で一発で分かるよ

49 :デフォルトの名無しさん:03/08/02 10:51
>>48
あ、>>24=45はバージョン管理システム知らないのか。
不思議なこという香具師だと思った。

50 :デフォルトの名無しさん:03/08/02 11:15
使ったこと無いのにコミットという用語は知ってるのか。ややこしい奴だな。
CVSを勉強中なのだろうか。
VSSならC/I、C/Oだろうし。

51 :デフォルトの名無しさん:03/08/02 11:37
他人が作ったソースを見るときは、revision1.1 と HEAD を cvs diff する。
それだけでだいたいの意図はわかる。

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

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

53 :デフォルトの名無しさん:03/08/02 11:57
>>52>>42へのレスね。
あと、
>うまく言葉にはできないんですが、ブロックの明瞭さが断然違うんですよ。
断然というほど違わない。ちゃんとインデントしてあるならどちらも全く変わらない。

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


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

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


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


54 :デフォルトの名無しさん:03/08/02 11:58
if (p) {
  処理A
} else {
  処理B
}
----------------
if (p)
{
  処理A
}
else
{
  処理B
}

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


55 :デフォルトの名無しさん:03/08/02 12:14
IF 条件 THEN BEGIN
  処理A
END ELSE BEGIN
  処理B
END

はOKですか?


56 :デフォルトの名無しさん:03/08/02 12:24
>>29
>get/set -> アクセサ(カプセル化の為に関数の形をとってる)
>それ以外 -> メソッド(動作)
>という事になってる。意味が完全に違うわけっす。

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

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

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

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

57 :デフォルトの名無しさん:03/08/02 13:11
>>55
> END ELSE BEGIN
これは少々ウザいな。

58 :デフォルトの名無しさん:03/08/02 13:28
やっぱ elsif だな

59 :デフォルトの名無しさん:03/08/02 17:02
> 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);
}
こんなかんじ?

60 :デフォルトの名無しさん:03/08/02 17:09
if 条件 then
 ・・・
else
 ・・・
end if

61 :デフォルトの名無しさん:03/08/02 17:16
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);
}
こんな感じ

62 :デフォルトの名無しさん:03/08/02 17:21
>>59
条件式を関数/メソッドに置き換えて、引数は構造体/メンバ変数にできないかを検討。

63 :デフォルトの名無しさん:03/08/02 17:23
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);
}
こんな感じ


64 :デフォルトの名無しさん:03/08/02 17:25
>>59が言いたいのはそういうことではないと思われ。

65 :64:03/08/02 17:26
>>62に対するレスね。

66 :デフォルトの名無しさん:03/08/02 17:28
>>63
微妙にずらすの止めれ。
インデントにタブと半角スペース混ぜるのハンターイ。

67 :デフォルトの名無しさん:03/08/02 17:41
>>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の評価式が複数行になる時だけ中括弧を次の行の頭に置く。
こうすると、評価とその処理がはっきりと分かれて見やすい気がする。

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

69 :24:03/08/02 17:46
で、ここまで読んだあんたは
「だから、そういう時こそログ見て変更を確認するんだろ」
と思ってるはずです、そうですね?そうですね?
しかし、本当にあなたはそれをしますか?

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

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

70 :デフォルトの名無しさん:03/08/02 17:50
>>69
知らない間に他人が更新したらcommitしようとしたときにすぐわかるはずだが。
あと更新通知メール送信も使うと便利

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

72 :デフォルトの名無しさん:03/08/02 17:58
> 自分しかいじらないはずだと思い込んでるソースのログを本当に確認しますか?
そう思ってるソースがupdateで変更されてたらログと差分を完全に確認するべき。
それをしない奴なら、ソースだろうとメールだろうと口頭だろうと、どう伝えても同じこと。

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

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

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

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

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

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


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

75 :デフォルトの名無しさん:03/08/02 18:12
                   / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
        ∧ ∧   < みんな>>1さんにニヤニヤしる。
       (・∀・)      \_____________
      _(つ__つ_∬_  ∧∧
    ∧∧   ∬   目∬\(・∀・) ニヤニヤ
   (・∀・)\ 目    目 \ ヽ  
   ./  |\ \           \ )〜
 〜(__)  \| ̄ ̄ ̄ ̄ ̄ ̄ ̄|
           | ̄| ̄ ̄ ̄ ̄| ̄| 
   ∧        ̄        ̄(・∀・)ニヤニヤ
  /   ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
  |うざいからマ板いけ ニヤニヤ
  \_______________

76 :デフォルトの名無しさん:03/08/02 18:20
>>75
うぜー
凄いうぜー
VBの変数の付け方くらいうぜー

77 :24:03/08/02 18:21

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

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

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



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

78 :72:03/08/02 18:28
> でもその中でいちばんマシなのがソースだと思いませんか?
思いません。
"A source file's primary role is as documentation of the current state of the project."

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

79 :デフォルトの名無しさん:03/08/02 18:38
C言語とかでオブジェクト試行的な考え方をしてるときは、名詞が先に来るんじゃないの?
C++におけるmessage::wait();のかわりに、msg_wt();ということで。

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

80 :デフォルトの名無しさん:03/08/02 18:39
>>74
Get/Setで始まるプロパティでないメソッドって何かあるか?

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


81 :デフォルトの名無しさん:03/08/02 18:39
Messageクラスのメソッドにwait()があるならな。

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


82 :デフォルトの名無しさん:03/08/02 18:41
>>77
ユニットテストな方々というか、テストファーストな者ですが。

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

83 :24:03/08/02 18:58

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

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

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

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

84 :72:03/08/02 19:17
> メールなんて何か特別な事態が起こらなければわざわざ何度も読み返さない。

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

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

85 :デフォルトの名無しさん:03/08/02 19:17
>>24
>>68-69の最初と最後しか読んでないけど、
>「融通の利かない完璧主義者」のやり方だとは思いませんか?
とか言っておきながら、レアケースを持ち出して1つの事に固執する、
>>24の方が融通が利かない人間に思えてしかたない。

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

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

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

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

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

86 :24:03/08/02 19:32
>>84
頼むからちゃんと嫁。
誰が ソースに更新履歴 なんて書いた。

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

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

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

87 :24:03/08/02 19:38
また誤読されるなと思ったんで補足。

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

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



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

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

89 :デフォルトの名無しさん:03/08/02 19:40
>>87
気づかれなさそうか、というのも状況によるし、主観だよなあ。
たとえばそういうコメントが既にとっちらかったソースならば
最早目立たないわけで(笑)

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

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

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


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

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

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

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

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

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

93 :デフォルトの名無しさん:03/08/02 20:28
読点も改行も段落も滅茶苦茶な文を「ちゃんと読め」とは随分偉そうですね。

94 :72:03/08/02 20:35
ほぅ・・・。

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

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

95 :デフォルトの名無しさん:03/08/02 21:02
>>69
>自分しかいじらないはず
なんで他の人がCommitできるようにしてるの?使い方が悪いんじゃないか。

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

97 :デフォルトの名無しさん:03/08/02 21:12
>なんかみんなちゃんと読んでくれてないんだもん。
論理が破綻してるね。
無理やりこじつけて自分の意見を押し通してるから自己中以外何者でもないよ。

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

98 :デフォルトの名無しさん:03/08/02 21:21
24って、本当は「俺のソースに触るな」なんだろ。


99 :24:03/08/02 21:58
>>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 で結論がそれですかおめでてーな

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

100 :デフォルトの名無しさん:03/08/02 22:15
> 関係ない話に持っていって論点ずらさないでくれない?
> レアケースな話すんなよ。
> で結論がそれですかおめでてーな

激しく、 オ マ エ モ ナ ー

101 :デフォルトの名無しさん:03/08/02 22:20
>>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 (許容範囲外。コンテクストがあってかろうじて理解できる最低レベル)
>こんなの普通しない。


102 :デフォルトの名無しさん:03/08/02 22:20

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


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



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

103 :デフォルトの名無しさん:03/08/02 22:21
深く考えすぎなんじゃない。
// ここ変更したの〜っす。
みたいなのは気利かしてくれてていいと思うんだけどね。

104 :デフォルトの名無しさん:03/08/02 22:23
>>103
それはちょっと話が違うんじゃないかな。
CVSの使い方知らないくせにCVS使えねーとか言ってるから叩かれてるだけなんじゃない。

105 :デフォルトの名無しさん:03/08/02 22:27
>>103
CVS使ってればそれも不要。

106 :デフォルトの名無しさん:03/08/02 22:29
cvs diff したら
10a10,11
> #if
300a302,303
> #endif
みたいだと激しく萎える。

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


107 :デフォルトの名無しさん:03/08/02 22:34
>>106
そこで何消したかってのはログに書いてあるんじゃないの?

108 :CVS使ったときねぇけど:03/08/02 22:43
確かに機械的、無機質的にログが残ってるよりも、
ちょっとコメント入れておいてくれたほうが、コミュニケーション面では良さそうだ。

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

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

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


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

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

111 :デフォルトの名無しさん:03/08/02 22:54
>>109
ってかそれが普通の使い方だろうしな。

112 :デフォルトの名無しさん:03/08/03 11:28
最強のコーディング規約を教えてください。

113 :_:03/08/03 11:31
http://homepage.mac.com/hiroyuki44/

114 :無料動画直リン:03/08/03 11:38
http://homepage.mac.com/miku24/

115 :デフォルトの名無しさん:03/08/03 11:50
>>112
いまんところ、個人的にはこれが最強。
ttp://groups.yahoo.com/group/boost/files/coding_guidelines.html

116 :デフォルトの名無しさん:03/08/03 12:48
>>115
Cで

117 :デフォルトの名無しさん:03/08/03 15:43
>>116
Cを使わない。C++を使う。
これ最強。

118 :デフォルトの名無しさん:03/08/03 18:04
>>117
ありえねー

119 :デフォルトの名無しさん:03/08/03 18:10
コーディングスタイルなんて統一することに意味があるんだよ。
どう統一するかなんて話し合ってる奴はセンスがないと言わざるを得ない。

120 :デフォルトの名無しさん:03/08/03 19:49
ム板まで出張かい?>せんすたん

121 :デフォルトの名無しさん:03/08/03 20:12
どう統一するかなんて話し合ってる奴がどこにいるんだ?


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

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

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

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

123 :デフォルトの名無しさん:03/08/03 23:10
>>122
プロパティかどうか分かります。

ただの自己満足です。

124 :デフォルトの名無しさん:03/08/03 23:44
大文字、小文字といえば.Netのコントロール名がデフォルトで
textBoxとかpictureBoxとかで微妙なんだけど。

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

126 :デフォルトの名無しさん:03/08/04 00:01
>>125
そんな理由が。コード補完がでなくて何回も打ち直してたよ。
ハンガリアンの次はわかりにくい命名規則か

127 :デフォルトの名無しさん:03/08/04 00:12
偉い人にはそれ(命名規約が大事なこと)が分からんのですよ。

128 :デフォルトの名無しさん:03/08/04 01:27
>>125
単に、Javaのフィールド名の規約を流用しただけじゃん。MSDNのC#命名規約嫁。

129 :デフォルトの名無しさん:03/08/04 03:19
>>122
固着観念から抜け出せなくて新しい物を吸収できないタイプ。

130 :デフォルトの名無しさん:03/08/04 03:33
122じゃないけどちょっと。

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

131 :デフォルトの名無しさん:03/08/04 05:27
>>130
じゃ、俺も74じゃないけど。
それはどちらもGetLengthでいいんでは?
getLengthの時はsetLengthも存在するとか、そんなもんじゃないかと。

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

132 :デフォルトの名無しさん:03/08/04 11:35
>>130
動作とプロパティって言っているのだから
bool SetUp() { return this->Initialize(); } と
void setUp(bool up) { this->up = up; } みたいな事なんだろ。


133 :デフォルトの名無しさん:03/08/04 11:37
>132
それだ!


134 :デフォルトの名無しさん:03/08/04 13:33
>>132
なるほど。
でも、こういう命名するのは嫌だよね。

135 :デフォルトの名無しさん:03/08/04 15:36
>>131
>それはどちらもGetLengthでいいんでは?
じゃあ聞くが逆の場合はどうなんだ?
プロパティとして扱うならgetLengthになってるはずだろ。
各クラスによってGetLengthとgetLengthが入り混じってることになる。
それはなんともキモイ。

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

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

137 :デフォルトの名無しさん:03/08/05 02:04
>>136
$ resouce.dat
bash: resouce.dat: command not found
$ hello.exe
Hello, World.

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

138 :デフォルトの名無しさん:03/08/05 02:13
>>137
実装の詳細だから。

139 :デフォルトの名無しさん:03/08/05 02:22
136じゃないが、
>>137
そりゃいいがかりだ。

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


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


141 :デフォルトの名無しさん:03/08/05 08:15
(car '(foo bar)) => foo
(car '(car '(foo bar))) => car
なんで、データとプログラムを区別する必要があるんだ?


142 :デフォルトの名無しさん:03/08/05 14:10
>>138=>>139
実装の詳細の意味間違ってるよ。
名詞と動詞の違いは詳細なんてレベルじゃなく
根本からの違いだ。

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

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

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

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

143 :デフォルトの名無しさん:03/08/05 14:39
>147=137が情報隠蔽というOOの基礎さえ理解することができない爺コボラないし夏廚であることだけはわかった。
それ以外は名詞だ動詞だと理解不能。


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

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

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

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

147 :デフォルトの名無しさん:03/08/05 16:48
>>137=>>142=>>144=>>145=>>146

        必 死 だ な w


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

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

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


149 :デフォルトの名無しさん:03/08/05 17:07
>>148
もう一度スレを読み直した方が良いと思われ。
勘違いしながら熱弁しても無意味。

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

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


151 :144:03/08/05 17:40
>>150
勘違いしていてスレを読み直した方がいいのは君のようだよ。
僕は優しいからどこを勘違いしているのか指摘してあげよう。

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

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



152 :デフォルトの名無しさん:03/08/05 17:49
>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() か?


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


154 :デフォルトの名無しさん:03/08/05 17:59
ほほう。
では、原点に関して対象な点の座標を取得するメソッドだとどうなる?

struct Point {
double x;
double y;

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

これも getSymmetricPoint() でOK?


155 :デフォルトの名無しさん:03/08/05 19:55
144 ◆O1EofOj10A の理論はこれで破綻したな。


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

156 :デフォルトの名無しさん:03/08/05 19:58
何でもかんでも統一すれば良いとは思わんが、
区別できないものに対して区別しようとするのがそもそもの間違い。

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

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

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

158 :144 ◆O1EofOj10A :03/08/05 20:03
>>155
反論?そもそも何に対して反論すればいいのかわからんが。
>154 は僕に質問しているだけであって、何か反論すべき理論を披露したようには思えないが。

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



159 :デフォルトの名無しさん:03/08/05 20:20
>>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; }

};

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

160 :デフォルトの名無しさん:03/08/05 20:21
要するに俺ルールってわけだ。

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

ご立派なルールだ。


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

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


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


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

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

163 :デフォルトの名無しさん:03/08/05 20:37
>>161
うわー。一番やばい回答が返ってきた。

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

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

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


164 :デフォルトの名無しさん:03/08/05 20:38
おっと失礼。

class ListWithLengthProperty {  ←大爆笑

だな。この場合は。

165 :デフォルトの名無しさん:03/08/05 20:41
更に失礼。レスし忘れてた。
コンパイル通らないのはすまんかったな。JavaとC++がごっちゃになってた。
まあ特に今回の話には関係ないので勘弁な。

166 :デフォルトの名無しさん:03/08/05 21:05
>>161
> 逃げただのと騒がないでくれよ。
いつ誰が騒いだんだろう。妄想癖?

167 :デフォルトの名無しさん:03/08/05 21:16
>>166
そんなん、2chを見てれば分かる。
早漏の香具師が多いからな。

168 :デフォルトの名無しさん:03/08/05 21:19
世間一般で広く行われているコーディング規約ではは俺様ルールと違って、
愚鈍なプログラマでも名前が決められるように、
メソッド名ならば大文字ではじめるというようにシンプルに決めている。

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

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


169 :デフォルトの名無しさん:03/08/05 21:37
>>168
コーディング規約は全て144 ◆O1EofOj10A 様(w の頭の中にあるんだろうよ。
人によって解釈があいまいなものを隠せなきゃ規約じゃない。

170 :デフォルトの名無しさん:03/08/05 22:04
まぁ自分だけで使う分なら俺様規約でも全くかまわないのだが…

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

171 :デフォルトの名無しさん:03/08/05 22:09
頭の良い高校生とみた。

172 :デフォルトの名無しさん:03/08/05 22:12
比較的賢い金魚とみた。

173 :デフォルトの名無しさん:03/08/05 22:16
なぜ8月に入って急に書き込みが増えた?
7月は山崎渉の2件を入れても3件しかなかったのにw

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

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

struct SymmetricalPoint {
 Point points[2];
};

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

175 :144 ◆O1EofOj10A :03/08/05 22:17
>>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 ユーザと
その他の同様の機能を持つ言語のユーザ達が僕の元に
「これはメソッドですか?プロパティですか?」
とお伺いを立てに来てくれるのかな?

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


176 :デフォルトの名無しさん:03/08/05 22:21
Pointを例として出したのは、ここの掲示板ではでかいソースが貼れないからだよ。
なんでその先が想像できないのかねぇ。趣味でやってるか、バカかのどっちか(あるいはどっちも)だな。

177 :デフォルトの名無しさん:03/08/05 22:32
>>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;} // どちらでも変わらないが答えだ
に変わってしまっているぞ。インターフェイス変わってどーすんねん。


178 :デフォルトの名無しさん:03/08/05 22:36
ここらで整理しとこうか。

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

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


こんな感じか?

179 :デフォルトの名無しさん:03/08/05 22:36
とりあえずgetとGetで使い分けるのはマズいと。

180 :デフォルトの名無しさん:03/08/05 22:41
>>179
いいえ。使い分けるべきです。理由は>>142ですでに述べています。

とレスが来そうな予感

181 :デフォルトの名無しさん:03/08/05 22:46
>>180
あれ?>>157の「紛らわしくなるから・・・」ってのが>>144様の見解じゃない?

182 :144 ◆O1EofOj10A :03/08/05 22:47
言い訳ばっかりになってきたようだね。
ピンチになってまともな反論ができなくなるとそうする弱虫がいるんだってさ。

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

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

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

183 :144 ◆O1EofOj10A :03/08/05 22:53
>>180=181
ナイス連携プレイ!まさしく一人であるかのように息がぴったりだよ。

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

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


184 :デフォルトの名無しさん:03/08/05 22:55
144 ◆O1EofOj10A
って Windows板でよく暴れてる人ですか?

185 :デフォルトの名無しさん:03/08/05 23:21
>144 = >24 なのか?

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

一人で大活躍だな。

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

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

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


186 :デフォルトの名無しさん:03/08/05 23:24
>>185
> まともなバージョン管理システムも使ったことがないようだし、
> チーム開発できないタイプなんじゃない。

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

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

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

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

漏れもそうオモタが、>>144が何か勘違いしてる様な気が。

189 :デフォルトの名無しさん:03/08/05 23:39
釣れた釣れた。今回は大漁だったな。





って言ってもいいよ。 >144


190 :144 ◆O1EofOj10A :03/08/05 23:42
>>185
>>144 = >24 なのか?
ご名答。これは事実だ。

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

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

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

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

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

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


191 :144 ◆O1EofOj10A :03/08/05 23:46
>>189
大物だが大漁じゃないんでね。

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

192 :187:03/08/05 23:50
>みんな自分でプロパティかメソッドか判断しているんだ。

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

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

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

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

193 :デフォルトの名無しさん:03/08/05 23:51
144はWindows板のデフラグスレ、田中スレ、その他の板の多くのスレで
中途半端な知識で暴れまくっています。
こまった人です。

194 :デフォルトの名無しさん:03/08/05 23:52
getとsetに関してはアクセッサ専用にしてたほうが
無難だと思うが。

195 :デフォルトの名無しさん:03/08/05 23:55
何かメール欄で必死に「負けたくない」って主張してるのってカッコワルイよね。
>>144=>>24って分かったんだし、放置でいいのでは?

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

超笑える(w

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

196 :デフォルトの名無しさん:03/08/06 00:05
元スレ(クラス名・変数名に迷ったら書き込むスレ。Part2)の時から
口調はえらそうなくせに結局レアケースや自己矛盾な話を持ち出してきて一人でもがいてるだけだしな。
勝手に自演扱いにしてるし(まあ2ちゃんだからいいんだろうだけど)
CVS話の時もせっかく使い方教えてもらったのに結局礼も言ってないし(いや、教えたのは俺じゃないが)

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

197 :デフォルトの名無しさん:03/08/06 00:16
俺は、VBとC#のプロパティはシンタックスシュガーと捕らえている。

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

よりも

text = Widget.Text
Widget.Text = text

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

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

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


198 :デフォルトの名無しさん:03/08/06 00:20
Windows板が静かになったと思ったら
プログラム板で暴れてたのか。
もうWindows板に帰ってこなくていいです。>>144


199 :デフォルトの名無しさん:03/08/06 00:21
またきたのかよ。成長はしなかったようだな。くるなっつったろ馬鹿が。もうくるなよ。>>144

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

無 駄 な こ と だ が 。

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

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




201 :デフォルトの名無しさん:03/08/06 00:52
>>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様には勝てないです。

202 :デフォルトの名無しさん:03/08/06 01:12
別に厨ではないが Ruby 使いとして。

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

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

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

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

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

205 :デフォルトの名無しさん:03/08/06 09:02
>>144
宿題はもう終わったのか?
早めに済ませておかないと後がつらいよ。

206 :デフォルトの名無しさん:03/08/06 09:26
自演自演って、Windows版で自分の自作自演が指摘されたのがよっぽど悔しかったんだね。
あれからだもんね。他人を自作自演扱いしだしたのは。

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

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

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

208 :_:03/08/06 09:44
http://homepage.mac.com/hiroyuki44/hankaku02.html

209 :デフォルトの名無しさん:03/08/06 09:48
>>206
妄想厨は放置しろよ

210 :デフォルトの名無しさん:03/08/06 10:02
・文体には気を使っていたが投稿時間でバレるのは気がつかなかった
・窓板住人
・妄想の友達がいっぱい(藁

211 :デフォルトの名無しさん:03/08/06 10:29
そんな事より聞いてください
>>206 さんの心の中に住んでいる妖精さんです。
みんな >>206 さんを虐めないで!!
強がっているけど本当はとても弱い人なんです。
煽りもうまくなったけど、>>206 さんがいつも現実世界で
言われている事を2ちゃんねるで書いてみてるだけなんです。
現実世界では >>206 さん誰も友達いないから
2ちゃんねるのみんなまで >>206 さんを虐めたら本当に一人になっちゃう!!
みんながちょっと優しくしてくれれば >>206 さんはそれで満足なんです。
もう >>206 さんには2ちゃんねるしか居場所がないんです。
どうかみなさんよろしくお願いします(ペコリ

212 :デフォルトの名無しさん:03/08/06 10:33
★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★
☆★☆★☆★ 新商品 ゾク・ゾク 入荷 ☆★☆★☆
★☆                       
☆★ 送料激安!!  送料激安!!  送料激安!!
★☆      http://www.get-dvd.com      
☆★  激安アダルトDVDショップ        
★☆    お買い得!! 1枚500円〜 急げ!   
☆★    インターネット初!「きたぐに割引」  
★☆    北海道・東北の皆様は送料も激安!   
☆★      http://www.get-dvd.com      
★☆        スピード発送!        
☆★      http://www.get-dvd.com      
★☆        商品が豊富!         
☆★      http://www.get-dvd.com      
★☆                       
☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆

213 :デフォルトの名無しさん:03/08/06 10:38
妙に自演にこだわってるね(βακα

214 :デフォルトの名無しさん:03/08/06 10:39
>>211
面白いなこれ、
新しいコピペ?


215 :デフォルトの名無しさん:03/08/06 10:44
<<このスレの90%くらいが二人の夏厨の煽りあいで埋め尽くされています。>>

216 :デフォルトの名無しさん:03/08/06 10:48
>>211=214
(・∀・)カコワルイ!!

217 :216:03/08/06 10:52
カコワルイ!!は(・A・)だた
欝氏・・・逝ってきます。

218 :デフォルトの名無しさん:03/08/06 10:59
Windows版にこだわるっていうか、
> 悪いが俺は Windows 板なんかにゃ行ったことねぇよ
に対する答えだろ


219 :デフォルトの名無しさん:03/08/06 11:19
>>24
多分、君はプロパティと、プロパティ取得用メソッドを混同してる。
プロパティというのは取得・設定できるオブジェクトの属性であって、
取得・設定する方法とは何の関係も無い。

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

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

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


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

221 :デフォルトの名無しさん:03/08/06 12:57
>>220
値と動作には明確な違いがあるが、
値を取るという動作とそれ以外の動作には何も違いは無いという主張です。

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

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


224 :デフォルトの名無しさん:03/08/06 13:45
>>222
そう。
たとえばNameというプロパティを設定するメソッドは
24的にsetNameでもいいし、ちょっとオシャレにRenameでもいい。

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


225 :220:03/08/06 14:06
>>223
そういう考え方もできますね。
考え方次第ですね。

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


226 :デフォルトの名無しさん:03/08/06 15:13
つまらん

227 :デフォルトの名無しさん:03/08/06 15:16
もとからだろ >>226

228 :デフォルトの名無しさん:03/08/06 15:21
>>225
あなたのおかげで目が覚めました。
メソッドとプロパティは全然違うものでした。
ありがとうございました。

229 :デフォルトの名無しさん:03/08/06 15:26
データを隠蔽してアクセサ等の操作メソッドを持たせたのがデータ抽象化。
アクセサを隠蔽してプロパティにまとめたのがアクセサ抽象化。
よってプロパティの方が偉いのだよ。

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


231 :デフォルトの名無しさん:03/08/06 15:29
>>229
はつみみです;)

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

233 :デフォルトの名無しさん:03/08/06 15:48
このスレはいつからプロパティの必要性を説くスレになったのですか?

234 :デフォルトの名無しさん:03/08/06 15:52
>>232
だなあ。
で、実装方法としてはメソッドと変わりないものになったとしても、
やはりプロパティはプロパティなんだよな・・・

235 :デフォルトの名無しさん:03/08/06 15:57
UMLなんか設計時点でメソッドとプロパティが存在するしな。
実装がどうなるかなんて関係なく別物として存在するんだよ。

236 :デフォルトの名無しさん:03/08/06 16:00
>>232
> なのにgetAgeとかgetHeightとメソッドにするのはどう考えてもおかしいべ。
C++ にも Java にもプロパティ機能がない以上は
メソッドで代用するしかないじゃん。


237 :219:03/08/06 16:02
>>228

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

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

239 :デフォルトの名無しさん:03/08/06 16:07
>>237==221==224==228
なんでいまさらになってレス番を名前に書いたんですか?

240 :デフォルトの名無しさん:03/08/06 16:08
>>239
番号書かなきゃ「俺の」が誰かわからないから

241 :デフォルトの名無しさん:03/08/06 16:09
>>237
なにを言いたいのかわからん。プロパティを取得するのに
アクセサ方式(クラスの利用者からget,setでアクセスする)でやるのと
プロパティ方式(クラスの利用者から実際はメソッドだが変数のようにアクセスできる)
があってプロパティ方式の方がより自然な感じで利用できるということか?

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

242 :デフォルトの名無しさん:03/08/06 16:09
ってちょっと待て
228は違うぞ

243 :デフォルトの名無しさん:03/08/06 16:11
>>237
アクセサはプロパティの一部のただのメソッドだから他のメソッドと区別してはいけないってか?
理由になってねーじゃん。
プロパティの一構成要素だから他のメソッドと区別するんだって。

244 :228:03/08/06 16:13
>>242
お前は誰だ。

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


246 :デフォルトの名無しさん:03/08/06 16:17
まずは「区別」を定義しないとな。

247 :デフォルトの名無しさん:03/08/06 16:17
あの、すいません、よくわからないんですけど、
プロパティーって、メンバ変数とかデータメンバとかいうアレですか?


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

249 :_:03/08/06 16:22
http://homepage.mac.com/hiroyuki44/jaz08.html

250 :デフォルトの名無しさん:03/08/06 16:22
>>246
区別の例としては
GetName/SetName/Doingが普通のメソッドで
getName/setNameが擬似プロパティという事みたいよ。

251 :デフォルトの名無しさん:03/08/06 16:26
白のパンダをどれでも全部並べる歌手です>>247

252 :デフォルトの名無しさん:03/08/06 16:27
GetNameやSetNameなんていらんだろ。つーか作るな。
名前ってのは機能を表す。
言語によっては大文字と小文字は区別されるが
同じ単語なんだよ。

253 :デフォルトの名無しさん:03/08/06 16:29
メンバ変数をpublicにしる!

254 :デフォルトの名無しさん:03/08/06 16:29
>>243
getLength/setLengthが、Lengthというプロパティにアクセスするためのメソッドだから、他と区別するというのならわかるが。
getLength/setLengthが、プロパティにアクセスするためのメソッドだから、他と区別するというのは理解できない。

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

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


255 :デフォルトの名無しさん:03/08/06 16:31
主張が意味不明です。もう一度お書き直しください

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

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

256 :デフォルトの名無しさん:03/08/06 16:32
>>253
代入や取得のさいに制限が無い場合はそれでもいいが、
後から追加されたときのことを考えると・・・。

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

257 :デフォルトの名無しさん:03/08/06 16:32
>>250
本当にそんな規約が存在して実際に使われているのか疑わしい。
学生の脳内ルールだろ。それ

258 :デフォルトの名無しさん:03/08/06 16:33
>>255
顧客が言うんなら仕方ないと思われ

259 :デフォルトの名無しさん:03/08/06 16:34
McDonaldさんとMcdonaldさんがいたら紛らわしいね。

260 :デフォルトの名無しさん:03/08/06 16:34
>>255
主張が意味不明です。

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

261 :デフォルトの名無しさん:03/08/06 16:35
今このスレにMethod Oriented Approachの開祖である>>254様が誕生しました。


262 :デフォルトの名無しさん:03/08/06 16:35
Person McDonald = new Person();
McDonald = new Person(); // 別人になりますた(。A 。 )

263 :デフォルトの名無しさん:03/08/06 16:36
お前ら馬鹿すぎ。
俺がルールを決めてやろう。

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

いじょ。しゅうりょ

264 :250:03/08/06 16:38
>>257
そうこのスレに書いてあったから例としてあげただけなんですが。

265 :デフォルトの名無しさん:03/08/06 16:38
>>263
それはなんと言う言語のソースですか?
少なくともJavaでもC++でもコンパイルできませんが。

266 :ネタニマジレス:03/08/06 16:39
>>262
Person person = new Person("McDonald");
person = new Person("McDonald"); // 別人になりますた(。A 。 )

だろ?

補足 同姓同名


267 :デフォルトの名無しさん:03/08/06 16:40
>>254
矛盾しまくりですね。

268 :デフォルトの名無しさん:03/08/06 16:41
そういえばSTLとかまったく区別してないね。

269 :デフォルトの名無しさん:03/08/06 16:43
>>268
STL は OO のライブラリではなくてジェネリクスのライブラリだから
OO 的な事は考慮されてないス。

270 :デフォルトの名無しさん:03/08/06 16:48
区別している実例が挙らないのはなんでだろ〜?

271 :268:03/08/06 16:49
>>269
なるほど。

272 :デフォルトの名無しさん:03/08/06 16:50
>>270
Java 標準規約ではアクセサは get/set ではじめよとなってた気が

273 :デフォルトの名無しさん:03/08/06 16:52
プロパティ専用の構文がない言語で、プロパティを実現するときに
メソッドを利用することになるが、それを概念的にはメソッドの集まりとは
言わずにプロパティと呼ぶのじゃ

274 :デフォルトの名無しさん:03/08/06 16:54
>>272
それは他と区別してるわけじゃないと思うぞ。
他も小文字から始めるし、get/setは受け取る/設定するに対応する標準的な英単語だし。

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

275 :デフォルトの名無しさん:03/08/06 16:57
javaのアクセッサは get/is/set ではじめるというのが標準規約。
各種ツール・ライブラリがこの規約に依存している。

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


276 :デフォルトの名無しさん:03/08/06 16:57
>>274
>putとか使われると一貫性がなくなって困るからじゃね?
ハァ?それを区別してるって言うんだろうが。

277 :デフォルトの名無しさん:03/08/06 16:59


278 :デフォルトの名無しさん:03/08/06 17:00
上のほうで言ってる区別ってさ
メソッドを大文字ではじめる規約の中にJavaのゲッターセッターを持っていっただけだよね
別に悪くないと思うけど

279 :デフォルトの名無しさん:03/08/06 17:00
>>276
何と何を区別してるんですか?

280 :デフォルトの名無しさん:03/08/06 17:01
>>278
そしたら Set Get Is になるんじゃねスか?

281 :デフォルトの名無しさん:03/08/06 17:02
>>280
特別だって事をもっと強調したかった。とか。

282 :デフォルトの名無しさん:03/08/06 17:03
>>279
バカかおまえ。アクセサとそれ以外をだ。

283 :276:03/08/06 17:04
282は俺だった。

284 :デフォルトの名無しさん:03/08/06 17:06
>>282
putではなくsetをつかうとアクセサとそれ以外を区別できるのか?

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

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

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

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

287 :デフォルトの名無しさん:03/08/06 17:21
漏れはget,setはアクセッサ専用にとっとく。

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


289 :デフォルトの名無しさん:03/08/06 17:33
おまいら、今夜はトリビアがあるから早く帰れよな

290 :デフォルトの名無しさん:03/08/06 17:35
>>289
トリビアスレに(・∀・)カエレ

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

292 :デフォルトの名無しさん:03/08/06 17:43
>>288
> そんなんコーディング規約の一般的な性質だろ。
その性質はアクセサに限ったものではなく、一般的なコーディング規約に共通する性質だといったのです。
すべてのコーディング規約が何かと区別するために作られているわけではありません。
区別するためのコーディング規約だけの性質を上げ手もらわないと話にならない。

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

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

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

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

293 :デフォルトの名無しさん:03/08/06 17:43
妊婦に?

294 :デフォルトの名無しさん:03/08/06 17:44
>>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を使ってはならない」だ。


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


296 :デフォルトの名無しさん:03/08/06 17:52
言語仕様にプロパティがあればすっきりするのに・・・。

297 :デフォルトの名無しさん:03/08/06 18:02
大文字小文字で区別するからsetとSetとか紛らわしくなるんであって、
get/setとそれ以外で区別すれば問題無いんじゃない?

298 :デフォルトの名無しさん:03/08/06 18:02
>>294
>し得ると言っている。
なんだ脳内か。

299 :デフォルトの名無しさん:03/08/06 18:06
>>298
当初誰もが(俺も)そう思っていたが
>>132-134
が実例を出してきやがった

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

300 :デフォルトの名無しさん:03/08/06 22:59
>>24

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


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

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

302 :デフォルトの名無しさん:03/08/06 23:33
>300
cvs annotate では追加された行はわかるが、削除された行についてはわからない。


303 :デフォルトの名無しさん:03/08/06 23:35
>301
オブジェクトはプロパティ以外の状態を持つことはできないのでしょうか?
それとも、オブジェクトの状態をプロパティと呼ぶのでしょうか?

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


304 :デフォルトの名無しさん:03/08/06 23:39
>>303

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

後者のほうが近い。


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

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

305 :デフォルトの名無しさん:03/08/06 23:46
>304
あなたが言っているプロパティというのはOOにおける一般的な意味のプロパティですね。
VBやC#のプロパティではなく。

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

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


306 :デフォルトの名無しさん:03/08/06 23:47
意味が通じなくなるので訂正します。
異存ありません。
~~~~


307 :デフォルトの名無しさん:03/08/06 23:53
>>305

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

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

308 :デフォルトの名無しさん:03/08/06 23:58
>>235前後いくつか

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

309 :デフォルトの名無しさん:03/08/07 00:03
言語仕様の話と概念の話が分離出来てないみたいだね。

310 :デフォルトの名無しさん:03/08/07 00:09
>308
どうかな?
オブジェクト指向で、オブジェクトが「状態」と「操作」を持つのは当然のことで、
UMLがそれを表現できなければ困るし、
当然、オブジェクト指向プログラミング言語も「状態」と「操作」を表現・記述できる。

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

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


311 :デフォルトの名無しさん:03/08/07 01:35
よーするにpropertyのない言語は時代遅れってこった。

312 :デフォルトの名無しさん:03/08/07 01:48
プロパティとメソッドは区別すべきだという人たちへ。
コンストラクタとメソッドは区別すべきだとお思いですか?

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

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



314 :デフォルトの名無しさん:03/08/07 02:05
> C++=コーディング規約では区別されないが new が頭にあればコンストラクタ
初耳だな。区別しない派が低いレベルで一定だという事実を如実に物語っている。

315 :デフォルトの名無しさん:03/08/07 02:13
区別するコーディング規約を二人以上のプロジェクトで適用した例:0件

316 :デフォルトの名無しさん:03/08/07 02:23
根拠の無いデータを書いた場合の必死だな度: 120%
さらにその後 また 自演する可能性: 100%

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

317 :デフォルトの名無しさん:03/08/07 02:30
>>24は今夜も来てるのか

318 :デフォルトの名無しさん:03/08/07 02:46
>>313
>メソッド本来の意味から外れてるからわかりやすくしておこう。

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

319 :デフォルトの名無しさん:03/08/07 03:05
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();
  }
}


320 :デフォルトの名無しさん:03/08/07 03:26
>>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 */
なんて行が山のように残ったソースなんて読みたくないよ。
読みにくくなるだけだろ。

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


321 :デフォルトの名無しさん:03/08/07 07:08
>>317
烈しくオマエモナー

322 :デフォルトの名無しさん:03/08/07 07:50
>>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; }
の方がマシだとおもわないか?

323 :デフォルトの名無しさん:03/08/07 08:01
>>322
どっちも同様に嫌だ



324 :デフォルトの名無しさん:03/08/07 08:06
>313
>また単純なフィールドでは表せない属性もある。
>だからもっと便利にする為にメソッドを使ってプロパティを表現しよう。

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

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

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


325 :_:03/08/07 08:10
http://homepage.mac.com/hiroyuki45/hankaku09.html

326 :_:03/08/07 08:12
http://homepage.mac.com/hiroyuki45/

327 : :03/08/07 08:24
http://www.2ch.net/2ch.html

328 :デフォルトの名無しさん:03/08/07 08:28
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; }
};

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



329 :デフォルトの名無しさん:03/08/07 09:27
>>322
思わない。どっちもダメ。俺の主張わかってるか?

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


330 :デフォルトの名無しさん:03/08/07 10:08
>328
きみのいう「属性」と「状態」は違うよね。
オブジェクトのパーシステンシに関係するのは「状態」であって、
「属性」じゃないよね。

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


331 :デフォルトの名無しさん:03/08/07 10:21
>>330
> インスタンスの状態(=属性)
混同してるのは324です

332 :デフォルトの名無しさん:03/08/07 10:36
>bool SetUp() { return this->Initialize(); }
>void setUp(bool up) { this->up = up; }
ここはウンコな命名を挙げるスレですか?

333 :デフォルトの名無しさん:03/08/07 10:42
>>329
念のために言うが、お前スレの流れを理解して無いだろ。
SetUpとsetUpは同じクラスに混在するわけじゃない。
大文字か小文字かで区別することを良しとするやつがこのスレに一人でもいるわけ無いだろ。

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

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


334 :デフォルトの名無しさん:03/08/07 10:51
セットアップも元をたどれば
setup = set up = 立ち上げる = 立った状態にする = 「立っている」を真にする
プロパティの設定と違いないわけだが

335 :デフォルトの名無しさん:03/08/07 11:11
>>333
おいおい、大きな勘違いをしてるのはどう考えてもお前だろ。
>大文字か小文字かで区別することを良しとするやつがこのスレに一人でもいるわけ無いだろ。
いる(いた?)からこういう議論が続いてんだろ。このスレ最初から読め。

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

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

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

337 :333:03/08/07 12:22
>>336
そういう話は132に言え
SetUpは単なる例だ

338 :デフォルトの名無しさん:03/08/07 12:38
>>337
SetUp以外に現実的で実用的な例はないのかよ。

339 :デフォルトの名無しさん:03/08/07 12:40
>>338
今のところ上がってないな
>>24が何度か遭遇したそうだが俺は見たことが無い

340 :デフォルトの名無しさん:03/08/07 13:05
メソッドとプロパティを区別するのはいいとして、その判断を
個々人に任すと意味なしだと思うが。

341 :デフォルトの名無しさん:03/08/07 16:47
ここで画期的な案

setPropertyXXX()
getPropertyXXX()

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

342 :デフォルトの名無しさん:03/08/07 16:49
>>341
setPropertyNameが激しく紛らわしいな

343 :デフォルトの名無しさん:03/08/07 16:56
通はこうする
__setXXX()
__getXXX()

344 :デフォルトの名無しさん:03/08/07 17:21
>>342
ちなみにメソッドはこう。

executeMethodXXX()

345 :デフォルトの名無しさん:03/08/07 17:53
ちなみにアクセサはこう。

type XXX()
void XXX(type value)

346 :デフォルトの名無しさん:03/08/07 21:40
窃盗しつけるヤシは氏ね

347 :デフォルトの名無しさん:03/08/07 21:54
>>343
__は予約語


348 :265:03/08/07 22:04
>>345=>>263
何度も言わせるな。それは何言語のソースなんだよ。


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

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

if ( array.length == n ) とか

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

どうでしょう? 

350 :デフォルトの名無しさん:03/08/07 22:11
頭悪そうに見えるから嫌いです。個人的には。

351 :デフォルトの名無しさん:03/08/07 22:20
>>349
他人のスタイルには口を出さない、修正するときは可能な限り合わせることにしてるが、
それは趣味じゃない。

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

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

353 :デフォルトの名無しさん:03/08/07 22:35
>>349
俺も括弧の内側にスペースを入れるが==の左右に入れない。

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

354 :デフォルトの名無しさん:03/08/07 23:50
このスレ頭から読んだけど面白かったよ。
ただひとつお願いがあるんだ。

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

355 :デフォルトの名無しさん:03/08/08 00:23
>>354
上げるってなんですか?

356 :デフォルトの名無しさん:03/08/08 00:30
>>355
ワラタ

357 :デフォルトの名無しさん:03/08/08 07:06
>>356はスレが上がってもおかしいお年頃

358 :デフォルトの名無しさん:03/08/08 08:05
>>340
> メソッドとプロパティを区別するのはいいとして、その判断を
> 個々人に任すと意味なしだと思うが。
個人以外の何が判断するんだ?
設計も実装も所詮は個人の判断だと思うが。

359 :デフォルトの名無しさん:03/08/08 08:10
>>330
あんたの言う状態と属性の違いって何よ?
変数として実装されているかどうかって事?
だとしたらプロパティ区分派は混同しようとしているんじゃなくて
同一視しようとしているわけなんだが。

360 :デフォルトの名無しさん:03/08/08 08:11
>>358
誤読。個人と「個々人」ではニュアンス違います。
っていうか、ここはコーディング*規約*スレですよ。

361 :デフォルトの名無しさん:03/08/09 09:27
Javaでプロパティといったら
java.lang.System.getProperties()とかjava.util.Properties#getProperty(String key)
とかを想像するのだが。

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

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

362 :デフォルトの名無しさん:03/08/09 09:31
UML :; 属性
Java : フィールド
C++ : 面罵変数
C# : 面罵変数

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


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

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

363 :デフォルトの名無しさん:03/08/09 13:17
>>361-362
ハイハイ、わからない事があったときには
煽るんじゃなくて おしえてください って素直にかきましょうね。


364 :デフォルトの名無しさん:03/08/09 14:04
前から思ってたがフィールドって何でprotectedにするんだ?
Publicにしれば記述も楽だし機能的にも同じだろ?

365 :デフォルトの名無しさん:03/08/09 14:18
class Hoge
{
public:
 Nullpo *nl;

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

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

int main(void)
{
 Hoge hoge;

}

366 :デフォルトの名無しさん:03/08/09 14:20
>>364
普通privateでは

367 :365:03/08/09 14:20
>>365
...途中で送信しちまった(鬱だ氏のう

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

 return 0;
}

368 :デフォルトの名無しさん:03/08/09 14:28
>>366
俺はいままでPrivateだったんだけど
今の職場はprotectedなんだよね

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

369 :デフォルトの名無しさん:03/08/09 14:35
>publicにしればいいじゃん
そんな大局変数みたいなフィールド作るなよ

370 :デフォルトの名無しさん:03/08/09 14:41
内部で値を操作するように仕様が変わったときに、
クライアントのコードが変わらないようにするためだよ

371 :デフォルトの名無しさん:03/08/09 14:42
>>368
メソッド経由で状態を変更しないようなクラスを作っている時点で
DQNな開発だということになりますが…

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

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

372 :デフォルトの名無しさん:03/08/09 14:43
>>370
なるほどね、俺的には自分で組んでんだから
それくらい注意して書けよって気にもなるんだが、まあいいや
thx

373 :デフォルトの名無しさん:03/08/09 14:51
>>371
最後の4行は宗教戦争になるな。


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


374 :デフォルトの名無しさん:03/08/09 14:54
>スーパークラスのフィールドへ直接アクセスする
>ためにProtectedにしているんだろうけど、それもほんとはよくな
>いね。
設計次第だろ。くだらん。

375 :デフォルトの名無しさん:03/08/09 15:24


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

376 :デフォルトの名無しさん:03/08/09 15:29
>>352
> スペースを多くとると、自分で書いてる時はいいけど
> 他人のソースを見たらすごく見ずらく感じるんですよね。。。
これ、使っているフォントによって大きく印象が変わるんだよね。

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

377 :デフォルトの名無しさん:03/08/09 15:33

>>375

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

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

379 :デフォルトの名無しさん:03/08/09 15:44
>>378
開発中、他人のコードをいっさい見ない・変更しないという前提なら
それも可能だけど。さすがに非現実的だよな。

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

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

// vim: sw=4: ts=4

380 :デフォルトの名無しさん:03/08/09 17:00
仕様設計の段階で決まった関数名はそれに従う。
それ以外は必ず先頭に「_」(半角アンダーバー)をつけること。

ウチの会社、ヘンかも。

381 :デフォルトの名無しさん:03/08/09 17:11
>>380
C も C++ も使えなくなりますがいいですか?大丈夫ですか?
X_Hoge くらいにしておいた方がいいYOと上司し進言してみては?

382 :ヽ(´ー`)ノ:03/08/09 18:59
(´-`).。oO(…_[a-z0-9]+ なら別に OK じゃないのかなぁ…)


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

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

384 :デフォルトの名無しさん:03/08/10 14:17
接頭詞は糞

385 :デフォルトの名無しさん:03/08/11 00:53
>>384
そんな品詞はない!

386 :デフォルトの名無しさん:03/08/11 01:00
>>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にしれば記述も楽だし機能的にも同じだろ?


387 :デフォルトの名無しさん:03/08/11 01:02
フィールドをpublicにしたがる奴はカプセル化も知らないVB厨

388 :デフォルトの名無しさん:03/08/11 01:04
publicにしたらスレッドセーフじゃなくなる恐怖があるわな。
その辺は>>363>>364も理解していないどうだな。

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

389 :デフォルトの名無しさん:03/08/11 01:05
規約に変な制限入れたがる奴はSM好き

390 :デフォルトの名無しさん:03/08/11 01:06
なんでもPrivateにする奴のせいで苦労したことがある_| ̄|○

391 :デフォルトの名無しさん:03/08/11 01:28
なんでももpublicにする奴のせいで苦労することのほうが
莫大に量が多いのだが。

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


392 :デフォルトの名無しさん:03/08/11 01:31
無駄にthreadを使わないのも一つのやり方だがね

393 :デフォルトの名無しさん:03/08/11 01:35
★☆ 夏休みは GETDVD で満喫・満喫!! ★☆★
★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★
☆★ 送料激安!  スピード発送!  商品豊富!   
★☆      http://www.get-dvd.com        
☆★ 激安DVDショップ 「GETDVDドットコム」 
★☆      http://www.get-dvd.com        
☆★ 今すぐアクセス Let’s Go・Go!!   
★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★


394 :デフォルトの名無しさん:03/08/11 01:35
>>392
> 無駄にthreadを使わないのも一つのやり方だがね
> 無駄にthreadを使わないのも一つのやり方だがね
> 無駄にthreadを使わないのも一つのやり方だがね
> 無駄にthreadを使わないのも一つのやり方だがね
> 無駄にthreadを使わないのも一つのやり方だがね
> 無駄にthreadを使わないのも一つのやり方だがね
> 無駄にthreadを使わないのも一つのやり方だがね
↑アホがいます

395 :デフォルトの名無しさん:03/08/11 01:36
thread以前の問題だろ・・・
どうしてこう無駄に脱線したがるかね。

396 :デフォルトの名無しさん:03/08/11 01:40
なぜ結合度の話にならないのかが不思議だ。。

397 :デフォルトの名無しさん:03/08/11 01:53
>>392
やばいよお前。GUIとかサーバサイトプログラミングしたことがあんの?
だったらフィールドをpublicにするのは問題だよ。

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

398 :デフォルトの名無しさん:03/08/11 01:58
>>397
>>392 はマルチスレッドの必要のないプログラムには
むやみにマルチスレッド化するなということを言っているのでは?

399 :デフォルトの名無しさん:03/08/11 02:03
>>396 がいいこと言った!

400 :デフォルトの名無しさん:03/08/11 02:05
ウザいから安置OOスレでやれや

401 :デフォルトの名無しさん:03/08/11 02:06
>>398
マルチスレッドにする必要の無いプログラムを好き好んでマルチスレッドにするやつは稀だと思う

402 :デフォルトの名無しさん:03/08/11 02:28
>>401
Javaの世界には、そういうボケナスがイッパイいるぞ。
new Thead().start()でスレッド動いちゃうからな。

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

今担当のプロジェクトをgrepしたら、間抜けなThread生成が
あちこちに…ひぃぃ、オソロシヤ。

403 :デフォルトの名無しさん:03/08/11 07:09
すんませんが教えてくだせえ
JavaでCBuilderのいうところの
Application->ProcessMessages()
をやるにはどうすればいいんでしょうか

404 :デフォルトの名無しさん:03/08/11 09:18
>>403 スレ違いっす

405 :デフォルトの名無しさん:03/08/11 09:24
規約 第i条
スレッドは、「Javaで学ぶデザインパターン マルチスレッド編(結城本)」を
熟読した上でこれを使用すること。

406 :デフォルトの名無しさん:03/08/11 09:25
public abstract class AbstractEmployee implements Employee {
public String name;
public String id;
...
}

ウワァァァァーン

407 :デフォルトの名無しさん:03/08/11 18:17
>>406

サ イ ア ク

408 :デフォルトの名無しさん:03/08/11 21:03
タブ幅4で書かれたソースをタブ幅8に直したいんでつが、
何かいいツールありますかねぇ・・・ 言語は C, C++ で。
文字列の中まで変換されたりしないやつ。

409 :デフォルトの名無しさん:03/08/12 00:35
expand / unexpand

410 :デフォルトの名無しさん:03/08/12 01:46
indent

411 :デフォルトの名無しさん:03/08/12 10:52
>>408
Eclipseで「ふぉーまっと」

412 :デフォルトの名無しさん:03/08/12 23:52
もまえら、1行の長さどこまでなら許せる?
漏れは79だが最近はウインドウ横に伸ばせば
いいじゃんってハナで笑われまつ。

413 :デフォルトの名無しさん:03/08/12 23:53
>412
自分は80と決心しているが、85とか86とかになっちゃうと浮気。

414 :デフォルトの名無しさん:03/08/12 23:56
80がうぇるのうん

415 :デフォルトの名無しさん:03/08/13 00:28
72だな。
FORTRAN野郎としては。

416 :無料動画直リン:03/08/13 00:29
http://homepage.mac.com/miku24/

417 :デフォルトの名無しさん:03/08/13 00:30
最近はプロポーショナルフォントにしてるし、印刷もしないので
1行の文字数はまったく意識しなくなってるな。
まあ100文字ぐらいにはなってるかとは思うが。

418 :デフォルトの名無しさん:03/08/13 00:39
大体100くらいかな
数えて改行することはない。

419 :デフォルトの名無しさん:03/08/13 00:41
1024くらいまでは気にしないかな。
意味の切れ目じゃない部分で改行する方が気持ち悪い。

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

420 :デフォルトの名無しさん:03/08/13 01:18
横スクロールバーがあると途端に可読性が下がることがある。
最大は80~90がベターかと。

421 :デフォルトの名無しさん:03/08/13 01:29
どうせ納品前には整形ツール通すので、好きにしろ、がルールだなあ。

422 :デフォルトの名無しさん:03/08/13 06:18
>>421
バージョン管理ツール使わないの?
差分の表示が出鱈目になってしまうんだが。

423 :デフォルトの名無しさん:03/08/13 11:37
たぶん整形したものはコミットしないんだろ。exportしてから整形。

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

425 :デフォルトの名無しさん:03/08/14 00:40
>>424
> そんな奴は、

って誰のこと?


426 :デフォルトの名無しさん:03/08/14 00:45
>>424文盲?
>>421みたいな「納品前には整形ツール通すので、好きにし」ているやつだろ

427 :デフォルトの名無しさん:03/08/14 22:16
桁数なんぞに足引っ張られんのもナンセンスだよな〜
整形ツールとかじゃなくてもっと根本的にどうにかならんか

428 :デフォルトの名無しさん:03/08/15 00:46
>>427
> 根本的にどうにか
気にしない→根本的に解決

429 :山崎 渉:03/08/15 15:36
    (⌒V⌒)
   │ ^ ^ │<これからも僕を応援して下さいね(^^)。
  ⊂|    |つ
   (_)(_)                      山崎パン

430 :デフォルトの名無しさん:03/08/15 20:07
俺はちゃんとif(a==true)とかif(a==false)とかって明示的に書くんだぜ。
この方がちゃんと意図が伝わりやすいだろ?ベイベ〜


431 :デフォルトの名無しさん:03/08/15 20:08
C厨の私にとってはif(a)の方が分かりやすいですね

432 :デフォルトの名無しさん:03/08/15 20:17
if (((((a==true)==true)==true)==true)==true)


433 :デフォルトの名無しさん:03/08/15 20:35
>>430
bool 型のときは if(a) でいいと思う。
int とかでは if(a) とかやめて欲しい。


434 :デフォルトの名無しさん:03/08/15 20:42
C に bool 型ってあるろ?

435 :デフォルトの名無しさん:03/08/15 20:43
_Bool型が有りまふ

436 :デフォルトの名無しさん:03/08/15 20:51
>>434
ない。
_BoolならC99にあるけど

437 :デフォルトの名無しさん:03/08/18 19:10
>>430は間違い

438 :デフォルトの名無しさん:03/08/18 19:22
>>433>>437 おもいっきり釣られてるやん。(ワラ

439 :デフォルトの名無しさん:03/08/18 20:31
>>438


440 :デフォルトの名無しさん:03/08/19 08:13
bool型でも変数名によっては (a == true) って書きたい時はあるよね。

441 :ヽ(´ー`)ノ:03/08/19 14:09
#include <stdlib.h>
#define die() exit(1)

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


442 :デフォルトの名無しさん:03/08/20 00:19
class Patlabor
{
private bool al = false;
}

class PairedAnimal
{
public bool kameAnd = true;
}

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

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

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)