トップページ⇒tech
442コメント192KB

コーディング規約

■ このスレッドは過去ログ倉庫に格納されています
00011NGNG
まじめに議論
0002デフォルトの名無しさんNGNG
    ,. -──- 、
   /______ヽ
    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
でいままで送信されたコメントが見えるよ!(けっこう笑える)  
0003 NGNG
C++だといつも話題になるのが大文字小文字まぜまぜ派とアンスコ連結派

ExecelentCodingRule
execelent_coding_rule

前者の方が最初は気に入っていたが、stlやboostが後者なので今は後者が
お気に入り。
後者のほうが読みやすい気もするけど、文字数は多くなる
0004デフォルトの名無しさんNGNG
excellentだなw
0005デフォルトの名無しさんNGNG
VB厨必須。
0006デフォルトの名無しさんNGNG
http://www.30girl.com/top.html
レースクイーンだよ!
0007_NGNG
http://homepage.mac.com/hiroyuki44/
0008デフォルトの名無しさんNGNG
インスタンス変数名と引数名が同じ物を現してる場合どうやって区別つけてる?
今まで見たのは、
1)インスタンス変数の先頭か末尾に_をつける。
2)引き数の先頭か末尾に_をつける。
3)同名でインスタンス変数はthis.hogeにする。
という感じなんだけど。
私はC++では1、C#では3にしてる。
0009デフォルトの名無しさんNGNG
かぶり気味

★★★コーディングマナー★★★
http://pc2.2ch.net/test/read.cgi/tech/1056508692/
0010デフォルトの名無しさんNGNG
>>8
識別子の先頭にアンダースコアは使えない。
0011デフォルトの名無しさんNGNG
規約とマナーは違うのでは?
0012山崎 渉NGNG

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

 __∧_∧_
 |(  ^^ )| <寝るぽ(^^)
 |\⌒⌒⌒\
 \ |⌒⌒⌒~|         山崎渉
   ~ ̄ ̄ ̄ ̄
0014葦稲磯稲胃斡NGNG
葦稲磯稲胃斡
0015デフォルトの名無しさんNGNG
クラス Foo
メンバ変数 m_fooBar
メンバ関数 fooBar
ローカル変数 foo_bar
定数 FOO_BAR
0016デフォルトの名無しさんNGNG
>>15
言語を明記しないか?
0017デフォルトの名無しさんNGNG
用語から判断すると C++
0018デフォルトの名無しさんNGNG
ごめん、C++のつもりね
0019デフォルトの名無しさんNGNG
>>15
>ローカル変数 foo_bar

配列の添え字なんかは foo_index とかやるんだ?
何かイヤダ
0020デフォルトの名無しさんNGNG
何事にも例外はあるだろ。間に受けすぎ
0021デフォルトの名無しさんNGNG
コレがいや。
if (expr)
{
/* do something */
}

こっちがいい。
if (expr) {
/* do something */
}
0022デフォルトの名無しさんNGNG
俺ルール

2項演算子の前後に空白。
単項演算子と被演算子の間は空けない。
左括弧の右に空白をあけない。
右括弧の左に空白をあけない。
予約語と括弧の間をあける。
関数名と括弧の間は空けない。
if文、while文、for文の実行文は必ず複文とする。
0023デフォルトの名無しさんNGNG
>>22
俺ルールというか、それは一般的なルールやね。

Javaで無限ループってどっちが多いんかな?
while (true) or for (;;)
俺はwhile派だけど。
0024どっかの176NGNG
# クラス名・変数名に迷ったら書き込むスレ。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 って使いたくなると非常に困ってまわりくどくて長い名前とかになっちゃったりする。
0025デフォルトの名無しさんNGNG
対抗俺ルール

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


複雑だな俺・・・
0026デフォルトの名無しさんNGNG
> getHogeとGetHogeは機能が違うんだったら、caseに依存するのは命名がおかしい。
といちゃもんつけた者です。

>>24
>これは説明不足っつーか、本当に同じ名前でキャピタライズで解決するわけじゃなくて
>アクセサ getFoo アクセサではないメソッド GetBaz みたいな。
なるほど。そういう意味ですか。
でもそうなると大文字で始まるメソッドと小文字で始まるメソッドが混在するんですよね?
やっぱりおかしい気がする。
具体的にどういうメソッドなのか示してくれると何か納得する糸口がつかめるかも。
0027デフォルトの名無しさんNGNG
すまん。
>「クラス名・変数名」と「大文字小文字」は無関係だと思う・・・んだけどどうよ?
このいちゃもんも俺だった罠w

>>24
>極端な例だと GetFileName と get_file_name なんかは大文字小文字を越えてなんか入っちゃったりするわけじゃん。
>っていうか get_file_name って書く人は少なくて file_name_get とか単語の順番まで違っちゃうというか。
>単語の順番が変わると使われてくる単語も自動的に変わってくるから、やっぱり命名と命名規約は表裏一体だと思うがどうよ?
うーん。。。俺が前提としていたのは「GetFileName と get_file_name」じゃなくて「GetFileName と getFileName」なんだが。
それでも同じ理論が展開できるかい?
0028デフォルトの名無しさんNGNG
>>22
全て俺と同じだ。
002924NGNG
>>26-27
>でもそうなると大文字で始まるメソッドと小文字で始まるメソッドが混在するんですよね?
漏れの頭ん中では
get/set -> アクセサ(カプセル化の為に関数の形をとってる)
それ以外 -> メソッド(動作)
という事になってる。意味が完全に違うわけっす。

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

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

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

だな。
0032~31/.indent.proNGNG
-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
0033デフォルトの名無しさんNGNG
第6条 ちゃんとJavadocコメント入れること!
0034デフォルトの名無しさんNGNG
if (...) {
    ...
} else {
    ...
}
にしてくれ・・・
0035デフォルトの名無しさんNGNG
GNU Coding Standardは激しくきもい

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

ttp://www.linux.or.jp/JF/JFdocs/kernel-docs-2.2/CodingStyle.html
0036デフォルトの名無しさんNGNG
こっちも貼っとこう。
ttp://www.sra.co.jp/public/sra/product/wingnut/standards/standards-ja_5.html#SEC22
0037デフォルトの名無しさんNGNG
>>29
>get/set -> アクセサ(カプセル化の為に関数の形をとってる)
>それ以外 -> メソッド(動作)
OKっす。かなり納得しました。C++にもプロパティ(言語仕様じゃなくてもいいから
広く一般に使われるようなやつ)が欲しいところですね。

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


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

これって1.派の意見ではブロックの開始が分かるからとか良く聞くけど
2.でもインデントがあるんだから開始は分かるんだよなあ。
それなら俺はぱっと1画面を見ても流れが読める2.の方が良いな。
0038デフォルトの名無しさんNGNG
if(...) // ここに判定についてのコメント
{// ここに真だった場合の処理を総括するコメント

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

板違いか。。。
0040デフォルトの名無しさんNGNG
>>39 http://pc2.2ch.net/test/read.cgi/tech/1030563262/l50
0041デフォルトの名無しさんNGNG
if(foo){
}
else{
// } と else は別の行に書く
}
004224NGNG
>>37
>>msg_wt(void)
>(wait_msgじゃないのかなあ)
>んー。良く分からないのでノーコメントで。
なぜ msg_wt なのかは私にも完全には理解できないのですが
Message -> msg (この省略は個人的には許容範囲)
Wait -> wt (許容範囲外。コンテクストがあってかろうじて理解できる最低レベル)
で、名詞 + 動詞 のルールらしく、そこに大文字混ぜない→区切りはアンスコの結果
msg_wt となるみたい。C な人には多いのかも。

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

>>39
すでに書かれてるけど、やっぱりすでにバージョン管理システムの仕事なので
必要以上にソース汚すなって事で。
でもある人が保守管理バッチリやってるソースのほんの数行を書き換えた時に
「ここ書き換えたの俺っす。」って書くくらいはいいかなとも思う。
コードよりコメントのが多くなったら完全にアカンと思うね。
0043山崎 渉NGNG
(^^)
0044デフォルトの名無しさんNGNG
>>42
> Wait -> wt (許容範囲外。コンテクストがあってかろうじて理解できる最低レベル)

こんなの普通しない。

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

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

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

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

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

自分は単語の省略は痛い目にあった事があり以後
(元から略語で通用しているものを除き)絶対にやらないと誓った
しかし、面倒故、ローカル変数だけは折れて一文字変数名使いまくってるダメな自分
0047デフォルトの名無しさんNGNG
>>45
> 本当にバージョン管理システム使ってる?
CVS使ってる。

> そんな状況で他人にミス入りのコードコミットされて、特に目印もなければメイワクセンバンでござるよ?
だからこそのCVS。
0048デフォルトの名無しさんNGNG
>はじめからみんなが引っ掻き回してるソースならともかく、そうじゃなければ
>いちいちコミット状況調べない(調べてらんない)っしょ。

cvs annotate で一発で分かるよ
0049デフォルトの名無しさんNGNG
>>48
あ、>>24=45はバージョン管理システム知らないのか。
不思議なこという香具師だと思った。
0050デフォルトの名無しさんNGNG
使ったこと無いのにコミットという用語は知ってるのか。ややこしい奴だな。
CVSを勉強中なのだろうか。
VSSならC/I、C/Oだろうし。
0051デフォルトの名無しさんNGNG
他人が作ったソースを見るときは、revision1.1 と HEAD を cvs diff する。
それだけでだいたいの意図はわかる。
0052デフォルトの名無しさんNGNG
結局俺が「クラス名・変数名に迷ったら書き込むスレ。Part2」で言いたかったことは、
例えば「メッセージを待つ関数名はどうすればいいでしょう」と質問があったとして、
それに対する回答が「WaitMessage」だった場合、
Javaな人はwaitMessage
C++/C#な人はWaitMessage
Cな人はwait_message

みたいな感じでアレンジするだろうから、「クラス名・変数名」と「大文字・小文字」とは無関係と言ったのよ。
それをmsg_wtみたいな特殊な例を出すからややこしくなる。
0053デフォルトの名無しさんNGNG
>>52は>>42へのレスね。
あと、
>うまく言葉にはできないんですが、ブロックの明瞭さが断然違うんですよ。
断然というほど違わない。ちゃんとインデントしてあるならどちらも全く変わらない。

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


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

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


間を詰めるのが良いと言ってるわけじゃないけども、
無駄に間をあけると流れがつかみにくい。
0054デフォルトの名無しさんNGNG
if (p) {
  処理A
} else {
  処理B
}
----------------
if (p)
{
  処理A
}
else
{
  処理B
}

この両者だけを比べるとどちらも大して変わらないが、
一画面をぱっと見たときに流れを理解しやすいのは前者。
0055デフォルトの名無しさんNGNG
IF 条件 THEN BEGIN
  処理A
END ELSE BEGIN
  処理B
END

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

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

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

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

例えばあるクラスで
int hoge = 1;
int getHoge() { return hoge; }
int GetFuga() { return 2; }
となっていたとして、hoge は内部に実際にあるけど fuga はないということが
外部からわかることがどれだけ重要なのか?
0057デフォルトの名無しさんNGNG
>>55
> END ELSE BEGIN
これは少々ウザいな。
0058デフォルトの名無しさんNGNG
やっぱ elsif だな
0059デフォルトの名無しさんNGNG
> 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);
}
こんなかんじ?
0060デフォルトの名無しさんNGNG
if 条件 then
 ・・・
else
 ・・・
end if
0061デフォルトの名無しさんNGNG
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);
}
こんな感じ
0062デフォルトの名無しさんNGNG
>>59
条件式を関数/メソッドに置き換えて、引数は構造体/メンバ変数にできないかを検討。
0063デフォルトの名無しさんNGNG
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);
}
こんな感じ
0064デフォルトの名無しさんNGNG
>>59が言いたいのはそういうことではないと思われ。
006564NGNG
>>62に対するレスね。
0066デフォルトの名無しさんNGNG
>>63
微妙にずらすの止めれ。
インデントにタブと半角スペース混ぜるのハンターイ。
0067デフォルトの名無しさんNGNG
>>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の評価式が複数行になる時だけ中括弧を次の行の頭に置く。
こうすると、評価とその処理がはっきりと分かれて見やすい気がする。
006824NGNG
>>48
#ある人が保守管理バッチリやってるソースの ほんの数行を書き換えた時に
って書いてあるの読めない?って書いてもわからなさそうだから例を書いてあげると。
・プロジェクト中には1000を越えるファイルがあります。
・あなた以外の人が滅多にさわらないファイルが40〜50くらいあります。
・ある日、新人のA君が、あなた以外滅多にさわらないファイルに変更を加えました。
・あなたは、ファイルに変更が加えられた事はアップデート時に気づきましたが、
 現在作業中の部分は関係ない部分だったので、大丈夫っぽい事だけ確認してそのままにしておきました。
・数ヵ月後(はい、ここ重要)、別のプログラマ(A君の教育係りでもある)が真っ赤な顔で怒りながらあなたの所へ来ました。
「てめえの担当部分にバグがあるじゃねえか!ふざけんな!」
あなたはとっさにソースを開き、確かに自分の担当部分である為、謝りました。
・修正しながら、「俺、なんでこんな凡ミスしてんだろ…」あなたはとても鬱な気分になりました。
・プロジェクトも無事終了し、打ち上げの2次会は、重大なバグを出して完成を遅らせたあなたがおごる事になりました。
・打ち上げの次の日、やっと余裕のできたあなたは CVS でバージョン間の diff を見ながら、
「いやあ、今回も仕様変更多かったなぁ、それにしてもこんな仕様変更に柔軟に対応できるのは俺の腕っ節の良さだよな」と悦に入っていました。
しかし、そこで見なければ良いものを見てしまったのです。
「あのバグ、俺が仕込んだ物じゃねーじゃねーか!」
そう、打ち上げの2次会をおごらなければいけなかったのは、A君の教育係の彼なのでした。
006924NGNG
で、ここまで読んだあんたは
「だから、そういう時こそログ見て変更を確認するんだろ」
と思ってるはずです、そうですね?そうですね?
しかし、本当にあなたはそれをしますか?

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

自分しかいじらないはずだと思い込んでるソースのログを本当に確認しますか?
プロジェクト中あなたは忙殺されており、自分しかいじらないソースを
新人君がほんの数行書き換えた事など、数日あれば忘れてしまうのです。
もちろんそれは忘れてしまった人間の責任なのですが、
事実上、だれかが所有権を持っているファイルに気づかない程度の変更を加えたときに
「ここ、書き換えたよ」とすぐにわかるように書いておいてあげる事が
本当に悪だと言い切れるでしょうか?
すべてがすべてバージョン管理システムの仕事としてしまうのは
「融通の利かない完璧主義者」のやり方だとは思いませんか?
0070デフォルトの名無しさんNGNG
>>69
知らない間に他人が更新したらcommitしようとしたときにすぐわかるはずだが。
あと更新通知メール送信も使うと便利
007170NGNG
>・あなたは、ファイルに変更が加えられた事はアップデート時に気づきましたが、
> 現在作業中の部分は関係ない部分だったので、大丈夫っぽい事だけ確認してそのままにしておきました。
結局、ここが問題な感じ
0072デフォルトの名無しさんNGNG
> 自分しかいじらないはずだと思い込んでるソースのログを本当に確認しますか?
そう思ってるソースがupdateで変更されてたらログと差分を完全に確認するべき。
それをしない奴なら、ソースだろうとメールだろうと口頭だろうと、どう伝えても同じこと。
007324NGNG
長文レスいくつもスマソです。
>>52
そのレベルの話なら、たしかにそう。
ただ漏れが >>24 で書いた
# っていうか get_file_name って書く人は少なくて file_name_get とか単語の順番まで違っちゃうというか。
# 単語の順番が変わると使われてくる単語も自動的に変わってくるから、やっぱり命名と命名規約は表裏一体だと思うがどうよ?
についてはどう考える?

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

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

>>それなら多少一画面の情報量が減っても、ありったけの情報を把握しておける方が
>>結果的に利用している情報量多いんではないかと。
>「一画面の情報量が減っ」たら「利用している情報量」は減るだろ。
食べきれないほど食べ物があっても、放っておいたら腐らせるだけですよ。
007424NGNG
>>56
>>get/set -> アクセサ(カプセル化の為に関数の形をとってる)
>>それ以外 -> メソッド(動作)
>>という事になってる。意味が完全に違うわけっす。
>アクセサを特別扱いする意味がわからない。

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


>・getHoge() だと内部で保持されている値を返す
>・GetHoge() だとフィールドに関係ない何らかの値を返す
>と使い分けてるようだが、
>外側から見たとき、返ってきた値が
>「実際に内部で保持されているかどうか」なんて関係ないだろ?
>それがオブジェクト指向でいうカプセル化なんだから。
ごめん >>24 参照して。GetXXX はあんまりないかも
で、誤読してる。SetXXX っていう「動作(メソッド)」がある場合があるのさ。
それは「値の設定(プロパティアクセス)」っていう意味じゃなくて、「動作」なの。わかってもらえる?
0075デフォルトの名無しさんNGNG
                   / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
        ∧ ∧   < みんな>>1さんにニヤニヤしる。
       (・∀・)      \_____________
      _(つ__つ_∬_  ∧∧
    ∧∧   ∬   目∬\(・∀・) ニヤニヤ
   (・∀・)\ 目    目 \ ヽ  
   ./  |\ \           \ )〜
 〜(__)  \| ̄ ̄ ̄ ̄ ̄ ̄ ̄|
           | ̄| ̄ ̄ ̄ ̄| ̄| 
   ∧        ̄        ̄(・∀・)ニヤニヤ
  /   ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
  |うざいからマ板いけ ニヤニヤ
  \_______________
0076デフォルトの名無しさんNGNG
>>75
うぜー
凄いうぜー
VBの変数の付け方くらいうぜー
007724NGNG

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

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

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



長かった。なんで2ちゃんのレス付けでこんな頑張ってんだ漏れは。
007872NGNG
> でもその中でいちばんマシなのがソースだと思いませんか?
思いません。
"A source file's primary role is as documentation of the current state of the project."

ソースがいちばんマシだと思う理由を挙げてみな。
0079デフォルトの名無しさんNGNG
C言語とかでオブジェクト試行的な考え方をしてるときは、名詞が先に来るんじゃないの?
C++におけるmessage::wait();のかわりに、msg_wt();ということで。

アンダーバーを用いてネームスペースを構築してると考えれば、
むしろ好ましい習慣ではないかと思いますがどうよ
0080デフォルトの名無しさんNGNG
>>74
Get/Setで始まるプロパティでないメソッドって何かあるか?

MFCにはGetNextとか言う列挙メソッドもあるが、これは名前のつけ方を激しく間違ってるだけだし。
0081デフォルトの名無しさんNGNG
Messageクラスのメソッドにwait()があるならな。

おれは、そんな設計はしないが。
0082デフォルトの名無しさんNGNG
>>77
ユニットテストな方々というか、テストファーストな者ですが。

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

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

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

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

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

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

CVSで履歴管理してるソースに更新履歴なんて、
手で情報の複製してるのがキモくてやってらんないよ。
0085デフォルトの名無しさんNGNG
>>24
>>68-69の最初と最後しか読んでないけど、
>「融通の利かない完璧主義者」のやり方だとは思いませんか?
とか言っておきながら、レアケースを持ち出して1つの事に固執する、
>>24の方が融通が利かない人間に思えてしかたない。

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

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

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

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

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

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

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

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

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

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

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

ということで再コンパイルを避けたければ、履歴情報でソースを書き換える機能は
使わないのが基本。
0089デフォルトの名無しさんNGNG
>>87
気づかれなさそうか、というのも状況によるし、主観だよなあ。
たとえばそういうコメントが既にとっちらかったソースならば
最早目立たないわけで(笑)
009024NGNG
>>24
いや、ほんとにコメントも White space も絶対何も違わないのに
なぜか変更された事になったりしたのよ。というわけで今は悔しいので使ってません。

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

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

> 気づかれなさそうな所で変更加えたときは注意を喚起させるために、ソース中に埋め込めや!
CVS使ってれば「気づかれなさそうな所」なんて発生しない。
差分取れば全部見れるんだから。
あと、注意を喚起しないといけないような変更は元の管理者の同意を取ってからコミットすべし。
009224NGNG
>>91
>> 「ここ書き換えたの俺っす。」って書く
>> 「ここ、書き換えたよ」とすぐにわかるように書いておいてあげる事
>↑これを「ソース中の更新履歴」と書いたんだが、どう違うんだ?

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

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

君、日本語ちゃんと読めてる?何度も同じ事書かないから、俺の書いたのもう一度ちゃんと嫁や。
0093デフォルトの名無しさんNGNG
読点も改行も段落も滅茶苦茶な文を「ちゃんと読め」とは随分偉そうですね。
009472NGNG
ほぅ・・・。

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

> 君、日本語ちゃんと読めてる?何度も同じ事書かないから、俺の書いたのもう一度ちゃんと嫁や。
日本語は読めると思ってるけど、あんたの文章をあんたの思ったとおりに
理解して同意する自信はまったく無いよ。
ごめんよ。
0095デフォルトの名無しさんNGNG
>>69
>自分しかいじらないはず
なんで他の人がCommitできるようにしてるの?使い方が悪いんじゃないか。
0096デフォルトの名無しさんNGNG
>>73
># っていうか get_file_name って書く人は少なくて file_name_get とか単語の順番まで違っちゃうというか。
># 単語の順番が変わると使われてくる単語も自動的に変わってくるから、やっぱり命名と命名規約は表裏一体だと思うがどうよ?
>についてはどう考える?
「Get_File_Name って書く人は少なくて File_Name_Get」
単語の順番が変わるのは小文字の場合だけと確信できるのか?
別に大文字でも変える奴は変えるだろ。
あんまり自分を過信してるといかんぞ。
0097デフォルトの名無しさんNGNG
>なんかみんなちゃんと読んでくれてないんだもん。
論理が破綻してるね。
無理やりこじつけて自分の意見を押し通してるから自己中以外何者でもないよ。

君の真似をして言わせてもらうと、
>> 「ここ書き換えたの俺っす。」って書く
>> 「ここ、書き換えたよ」とすぐにわかるように書いておいてあげる事
変更箇所が100万箇所あったらどうするんだ?
0098デフォルトの名無しさんNGNG
24って、本当は「俺のソースに触るな」なんだろ。
009924NGNG
>>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 で結論がそれですかおめでてーな

っていうかもうこねーようわぁぁん。みたいなー。
0100デフォルトの名無しさんNGNG
> 関係ない話に持っていって論点ずらさないでくれない?
> レアケースな話すんなよ。
> で結論がそれですかおめでてーな

激しく、 オ マ エ モ ナ ー
0101デフォルトの名無しさんNGNG
>>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 (許容範囲外。コンテクストがあってかろうじて理解できる最低レベル)
>こんなの普通しない。
■ このスレッドは過去ログ倉庫に格納されています