コーディング規約
■ このスレッドは過去ログ倉庫に格納されています
00011
NGNG0002デフォルトの名無しさん
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
NGNGExecelentCodingRule
execelent_coding_rule
前者の方が最初は気に入っていたが、stlやboostが後者なので今は後者が
お気に入り。
後者のほうが読みやすい気もするけど、文字数は多くなる
0004デフォルトの名無しさん
NGNG0005デフォルトの名無しさん
NGNG0006デフォルトの名無しさん
NGNGレースクイーンだよ!
0007_
NGNG0008デフォルトの名無しさん
NGNG今まで見たのは、
1)インスタンス変数の先頭か末尾に_をつける。
2)引き数の先頭か末尾に_をつける。
3)同名でインスタンス変数はthis.hogeにする。
という感じなんだけど。
私はC++では1、C#では3にしてる。
0009デフォルトの名無しさん
NGNG★★★コーディングマナー★★★
http://pc2.2ch.net/test/read.cgi/tech/1056508692/
0010デフォルトの名無しさん
NGNG識別子の先頭にアンダースコアは使えない。
0011デフォルトの名無しさん
NGNG0012山崎 渉
NGNG__∧_∧_
|( ^^ )| <寝るぽ(^^)
|\⌒⌒⌒\
\ |⌒⌒⌒~| 山崎渉
~ ̄ ̄ ̄ ̄
0013山崎 渉
NGNG__∧_∧_
|( ^^ )| <寝るぽ(^^)
|\⌒⌒⌒\
\ |⌒⌒⌒~| 山崎渉
~ ̄ ̄ ̄ ̄
0014葦稲磯稲胃斡
NGNG0015デフォルトの名無しさん
NGNGメンバ変数 m_fooBar
メンバ関数 fooBar
ローカル変数 foo_bar
定数 FOO_BAR
0016デフォルトの名無しさん
NGNG言語を明記しないか?
0017デフォルトの名無しさん
NGNG0018デフォルトの名無しさん
NGNG0019デフォルトの名無しさん
NGNG>ローカル変数 foo_bar
配列の添え字なんかは foo_index とかやるんだ?
何かイヤダ
0020デフォルトの名無しさん
NGNG0021デフォルトの名無しさん
NGNGif (expr)
{
/* do something */
}
こっちがいい。
if (expr) {
/* do something */
}
0022デフォルトの名無しさん
NGNG2項演算子の前後に空白。
単項演算子と被演算子の間は空けない。
左括弧の右に空白をあけない。
右括弧の左に空白をあけない。
予約語と括弧の間をあける。
関数名と括弧の間は空けない。
if文、while文、for文の実行文は必ず複文とする。
0023デフォルトの名無しさん
NGNG俺ルールというか、それは一般的なルールやね。
Javaで無限ループってどっちが多いんかな?
while (true) or for (;;)
俺はwhile派だけど。
0024どっかの176
NGNG# 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といちゃもんつけた者です。
>>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全て俺と同じだ。
002924
NGNG>でもそうなると大文字で始まるメソッドと小文字で始まるメソッドが混在するんですよね?
漏れの頭ん中では
get/set -> アクセサ(カプセル化の為に関数の形をとってる)
それ以外 -> メソッド(動作)
という事になってる。意味が完全に違うわけっす。
>「GetFileName と get_file_name」じゃなくて「GetFileName と getFileName」なんだが。
純粋にキャピタライズだけの問題だったらいいんだけど、ついこの間 C しかしらん人に
C++ を覚える上でのアドバイスを求められて、その人のソースをみたらさ、
本当に msg_wt(void) (おそらく今風に言うとWaitForMessage()) とかそんな名前のつけかたなわけよ。
ああ、こりゃ本格的に文化が違うなと思った。
語順、単語の選び方、省略すべき単語の基準などなど。
で、C でも C++ でも Java でも C# でも msg_wt っていう関数(メソッド)名は
言語の仕様的には問題ないわけで、やっぱりそういう流派もあるって認めないと
「どの単語がいいですか?」っていう相談は、した方も求めていたものが出てこなくて、
された方もせっかく教えてあげたのに「あわねえ」の一言で無視されちゃって
お互いに不利益だなと思うわけだがどう?
003024
NGNGよく見たら漏れもまったく同じだ。
で、ここまで同じだと気になるのはカーリーブラケットの位置なんだけど
漏れは
if (hoge == NULL)
{
Foo();
}
派なんだけど、やっぱり K&R 派の方が多いんだろうか?
0031デフォルトの名無しさん
NGNGif (hoge == NULL) {
Foo();
}
だな。
0032~31/.indent.pro
NGNG--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デフォルトの名無しさん
NGNG0034デフォルトの名無しさん
NGNG...
} else {
...
}
にしてくれ・・・
0035デフォルトの名無しさん
NGNGif (...)
{
...
}
else
{
...
}
ttp://www.linux.or.jp/JF/JFdocs/kernel-docs-2.2/CodingStyle.html
0036デフォルトの名無しさん
NGNGttp://www.sra.co.jp/public/sra/product/wingnut/standards/standards-ja_5.html#SEC22
0037デフォルトの名無しさん
NGNG>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{// ここに真だった場合の処理を総括するコメント
ってかんじで使ってる。(コメント書かない場合が多いけどね)
0039デフォルトの名無しさん
NGNG// やら /* */ やら #if 0 で囲われた大昔のコードの残骸の中に
今生きているコードがちょっとだけ。
おまけに、変更したやつの名前と日付、
// ここから修正
// ここまで修正
とか。
そのくせ、なぜ修正したか理由が書いてない。
板違いか。。。
0041デフォルトの名無しさん
NGNG}
else{
// } と else は別の行に書く
}
004224
NGNG>>msg_wt(void)
>(wait_msgじゃないのかなあ)
>んー。良く分からないのでノーコメントで。
なぜ msg_wt なのかは私にも完全には理解できないのですが
Message -> msg (この省略は個人的には許容範囲)
Wait -> wt (許容範囲外。コンテクストがあってかろうじて理解できる最低レベル)
で、名詞 + 動詞 のルールらしく、そこに大文字混ぜない→区切りはアンスコの結果
msg_wt となるみたい。C な人には多いのかも。
>これって1.派の意見ではブロックの開始が分かるからとか良く聞くけど
>2.でもインデントがあるんだから開始は分かるんだよなあ。
うまく言葉にはできないんですが、ブロックの明瞭さが断然違うんですよ。
視界の隅っこの方までブロックの構造を無意識に理解してるというか。
実際、画面上にたくさん情報量があっても、一度に利用できなければ目をキョロキョロさせるしかないわけで、
それなら多少一画面の情報量が減っても、ありったけの情報を把握しておける方が
結果的に利用している情報量多いんではないかと。
>>39
すでに書かれてるけど、やっぱりすでにバージョン管理システムの仕事なので
必要以上にソース汚すなって事で。
でもある人が保守管理バッチリやってるソースのほんの数行を書き換えた時に
「ここ書き換えたの俺っす。」って書くくらいはいいかなとも思う。
コードよりコメントのが多くなったら完全にアカンと思うね。
0043山崎 渉
NGNG0044デフォルトの名無しさん
NGNG> Wait -> wt (許容範囲外。コンテクストがあってかろうじて理解できる最低レベル)
こんなの普通しない。
> で、名詞 + 動詞 のルールらしく、そこに大文字混ぜない→区切りはアンスコの結果
msg関係の関数群があれば、msg_をprefixとする場合もあるが。
> msg_wt となるみたい。C な人には多いのかも。
ここまで変なのは多くねーよ。
> 「ここ書き換えたの俺っす。」って書くくらいはいいかなとも思う。
バージョン管理システムの仕事。
004524
NGNG>バージョン管理システムの仕事。
本当にバージョン管理システム使ってる?
#ある人が保守管理バッチリやってるソースの ほんの数行を書き換えた時に
だよ?
はじめからみんなが引っ掻き回してるソースならともかく、そうじゃなければ
いちいちコミット状況調べない(調べてらんない)っしょ。
そんな状況で他人にミス入りのコードコミットされて、特に目印もなければメイワクセンバンでござるよ?
0046デフォルトの名無しさん
NGNGなんか、わかる。
wait → wt なんかは機械系に多いかも…。open → o 、close → c とか。
自分は単語の省略は痛い目にあった事があり以後
(元から略語で通用しているものを除き)絶対にやらないと誓った
しかし、面倒故、ローカル変数だけは折れて一文字変数名使いまくってるダメな自分
0047デフォルトの名無しさん
NGNG> 本当にバージョン管理システム使ってる?
CVS使ってる。
> そんな状況で他人にミス入りのコードコミットされて、特に目印もなければメイワクセンバンでござるよ?
だからこそのCVS。
0048デフォルトの名無しさん
NGNG>いちいちコミット状況調べない(調べてらんない)っしょ。
cvs annotate で一発で分かるよ
0049デフォルトの名無しさん
NGNGあ、>>24=45はバージョン管理システム知らないのか。
不思議なこという香具師だと思った。
0050デフォルトの名無しさん
NGNGCVSを勉強中なのだろうか。
VSSならC/I、C/Oだろうし。
0051デフォルトの名無しさん
NGNGそれだけでだいたいの意図はわかる。
0052デフォルトの名無しさん
NGNG例えば「メッセージを待つ関数名はどうすればいいでしょう」と質問があったとして、
それに対する回答が「WaitMessage」だった場合、
Javaな人はwaitMessage
C++/C#な人はWaitMessage
Cな人はwait_message
みたいな感じでアレンジするだろうから、「クラス名・変数名」と「大文字・小文字」とは無関係と言ったのよ。
それをmsg_wtみたいな特殊な例を出すからややこしくなる。
0053デフォルトの名無しさん
NGNGあと、
>うまく言葉にはできないんですが、ブロックの明瞭さが断然違うんですよ。
断然というほど違わない。ちゃんとインデントしてあるならどちらも全く変わらない。
>視界の隅っこの方までブロックの構造を無意識に理解してるというか。
ハァ?ちゃんとレス嫁。
ブロックの開始を探すのに"{"を見てるわけじゃない。
インデントレベルでブロックの開始が分かると言ってる。
>実際、画面上にたくさん情報量があっても、一度に利用できなければ目をキョロキョロさせるしかないわけで、
さっぱり意味が分からん。
>それなら多少一画面の情報量が減っても、ありったけの情報を把握しておける方が
>結果的に利用している情報量多いんではないかと。
「一画面の情報量が減っ」たら「利用している情報量」は減るだろ。
間を詰めるのが良いと言ってるわけじゃないけども、
無駄に間をあけると流れがつかみにくい。
0054デフォルトの名無しさん
NGNG処理A
} else {
処理B
}
----------------
if (p)
{
処理A
}
else
{
処理B
}
この両者だけを比べるとどちらも大して変わらないが、
一画面をぱっと見たときに流れを理解しやすいのは前者。
0055デフォルトの名無しさん
NGNG処理A
END ELSE BEGIN
処理B
END
はOKですか?
0056デフォルトの名無しさん
NGNG>get/set -> アクセサ(カプセル化の為に関数の形をとってる)
>それ以外 -> メソッド(動作)
>という事になってる。意味が完全に違うわけっす。
アクセサを特別扱いする意味がわからない。
・getHoge() だと内部で保持されている値を返す
・GetHoge() だとフィールドに関係ない何らかの値を返す
と使い分けてるようだが、外側から見たとき、返ってきた値が
「実際に内部で保持されているかどうか」なんて関係ないだろ?
それがオブジェクト指向でいうカプセル化なんだから。
例えばあるクラスで
int hoge = 1;
int getHoge() { return hoge; }
int GetFuga() { return 2; }
となっていたとして、hoge は内部に実際にあるけど fuga はないということが
外部からわかることがどれだけ重要なのか?
0057デフォルトの名無しさん
NGNG> END ELSE BEGIN
これは少々ウザいな。
0058デフォルトの名無しさん
NGNG0059デフォルトの名無しさん
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);
}
こんなかんじ?
0060デフォルトの名無しさん
NGNG・・・
else
・・・
end if
0061デフォルトの名無しさん
NGNG&& 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条件式を関数/メソッドに置き換えて、引数は構造体/メンバ変数にできないかを検討。
0063デフォルトの名無しさん
NGNG&& 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デフォルトの名無しさん
NGNG0066デフォルトの名無しさん
NGNG微妙にずらすの止めれ。
インデントにタブと半角スペース混ぜるのハンターイ。
0067デフォルトの名無しさん
NGNGif ( 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の評価式が複数行になる時だけ中括弧を次の行の頭に置く。
こうすると、評価とその処理がはっきりと分かれて見やすい気がする。
006824
NGNG#ある人が保守管理バッチリやってるソースの ほんの数行を書き換えた時に
って書いてあるの読めない?って書いてもわからなさそうだから例を書いてあげると。
・プロジェクト中には1000を越えるファイルがあります。
・あなた以外の人が滅多にさわらないファイルが40〜50くらいあります。
・ある日、新人のA君が、あなた以外滅多にさわらないファイルに変更を加えました。
・あなたは、ファイルに変更が加えられた事はアップデート時に気づきましたが、
現在作業中の部分は関係ない部分だったので、大丈夫っぽい事だけ確認してそのままにしておきました。
・数ヵ月後(はい、ここ重要)、別のプログラマ(A君の教育係りでもある)が真っ赤な顔で怒りながらあなたの所へ来ました。
「てめえの担当部分にバグがあるじゃねえか!ふざけんな!」
あなたはとっさにソースを開き、確かに自分の担当部分である為、謝りました。
・修正しながら、「俺、なんでこんな凡ミスしてんだろ…」あなたはとても鬱な気分になりました。
・プロジェクトも無事終了し、打ち上げの2次会は、重大なバグを出して完成を遅らせたあなたがおごる事になりました。
・打ち上げの次の日、やっと余裕のできたあなたは CVS でバージョン間の diff を見ながら、
「いやあ、今回も仕様変更多かったなぁ、それにしてもこんな仕様変更に柔軟に対応できるのは俺の腕っ節の良さだよな」と悦に入っていました。
しかし、そこで見なければ良いものを見てしまったのです。
「あのバグ、俺が仕込んだ物じゃねーじゃねーか!」
そう、打ち上げの2次会をおごらなければいけなかったのは、A君の教育係の彼なのでした。
006924
NGNG「だから、そういう時こそログ見て変更を確認するんだろ」
と思ってるはずです、そうですね?そうですね?
しかし、本当にあなたはそれをしますか?
#ある人が保守管理バッチリやってるソースの ほんの数行を書き換えた時に
自分しかいじらないはずだと思い込んでるソースのログを本当に確認しますか?
プロジェクト中あなたは忙殺されており、自分しかいじらないソースを
新人君がほんの数行書き換えた事など、数日あれば忘れてしまうのです。
もちろんそれは忘れてしまった人間の責任なのですが、
事実上、だれかが所有権を持っているファイルに気づかない程度の変更を加えたときに
「ここ、書き換えたよ」とすぐにわかるように書いておいてあげる事が
本当に悪だと言い切れるでしょうか?
すべてがすべてバージョン管理システムの仕事としてしまうのは
「融通の利かない完璧主義者」のやり方だとは思いませんか?
0070デフォルトの名無しさん
NGNG知らない間に他人が更新したらcommitしようとしたときにすぐわかるはずだが。
あと更新通知メール送信も使うと便利
007170
NGNG> 現在作業中の部分は関係ない部分だったので、大丈夫っぽい事だけ確認してそのままにしておきました。
結局、ここが問題な感じ
0072デフォルトの名無しさん
NGNGそう思ってるソースがupdateで変更されてたらログと差分を完全に確認するべき。
それをしない奴なら、ソースだろうとメールだろうと口頭だろうと、どう伝えても同じこと。
007324
NGNG>>52
そのレベルの話なら、たしかにそう。
ただ漏れが >>24 で書いた
# っていうか get_file_name って書く人は少なくて file_name_get とか単語の順番まで違っちゃうというか。
# 単語の順番が変わると使われてくる単語も自動的に変わってくるから、やっぱり命名と命名規約は表裏一体だと思うがどうよ?
についてはどう考える?
>>53
>>うまく言葉にはできないんですが、ブロックの明瞭さが断然違うんですよ。
>断然というほど違わない。ちゃんとインデントしてあるならどちらも全く変わらない。
違わないと思ってるのは、 if (...) { スタイルを使っているから。
次の行に書くようにして一ヶ月もすれば違いがわかる。
(仕事でやっていて周りが同じ行に書くスタイルの場合は一ヶ月じゃ無理かも、漏れは学生の頃に
ほとんど自分のソースばっかり見ている時期に同じ行に続けて書くスタイルから次の行に書くスタイルに変更したから
ほんの1, 2週間でもう戻れない体になってしまったけど。)
>>視界の隅っこの方までブロックの構造を無意識に理解してるというか。
>ハァ?ちゃんとレス嫁。
>ブロックの開始を探すのに"{"を見てるわけじゃない。
>インデントレベルでブロックの開始が分かると言ってる。
優れた図形認識感覚をお持ちのようなのでうらやましい限りなのですが、
単にインデントの深さだけよりも {} の対応の方がずっと強くブロックが明示されているという事です。
もっというと、わかればいいのではなく、わかりやすくなければいけないという事です。
(わかればいいだけなら 「あいまいな else」のような状態でも、規格上はちゃんと一意に決定できるようになっているわけで)
>>それなら多少一画面の情報量が減っても、ありったけの情報を把握しておける方が
>>結果的に利用している情報量多いんではないかと。
>「一画面の情報量が減っ」たら「利用している情報量」は減るだろ。
食べきれないほど食べ物があっても、放っておいたら腐らせるだけですよ。
007424
NGNG>>get/set -> アクセサ(カプセル化の為に関数の形をとってる)
>>それ以外 -> メソッド(動作)
>>という事になってる。意味が完全に違うわけっす。
>アクセサを特別扱いする意味がわからない。
アクセサは >>37 さんも書いてるけど、プロパティの代わりなわけです。
関数の形をとってる事自体が本当は意味的にちょっと違うというか。しかたがなくというか。
>・getHoge() だと内部で保持されている値を返す
>・GetHoge() だとフィールドに関係ない何らかの値を返す
>と使い分けてるようだが、
>外側から見たとき、返ってきた値が
>「実際に内部で保持されているかどうか」なんて関係ないだろ?
>それがオブジェクト指向でいうカプセル化なんだから。
ごめん >>24 参照して。GetXXX はあんまりないかも
で、誤読してる。SetXXX っていう「動作(メソッド)」がある場合があるのさ。
それは「値の設定(プロパティアクセス)」っていう意味じゃなくて、「動作」なの。わかってもらえる?
0075デフォルトの名無しさん
NGNG∧ ∧ < みんな>>1さんにニヤニヤしる。
(・∀・) \_____________
_(つ__つ_∬_ ∧∧
∧∧ ∬ 目∬\(・∀・) ニヤニヤ
(・∀・)\ 目 目 \ ヽ
./ |\ \ \ )〜
〜(__) \| ̄ ̄ ̄ ̄ ̄ ̄ ̄|
| ̄| ̄ ̄ ̄ ̄| ̄|
∧  ̄  ̄(・∀・)ニヤニヤ
/  ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
|うざいからマ板いけ ニヤニヤ
\_______________
0076デフォルトの名無しさん
NGNGうぜー
凄いうぜー
VBの変数の付け方くらいうぜー
007724
NGNG>>70
もう一度 >>68-69 を穴があくほどよく読んでください。
>>71
確かにそうなんだけど、人間って完璧じゃないじゃん?
バグって例外的状況に潜むでしょ?
にも関わらず普段通りの状況で正しく動くだけで安心しちゃう事は結構多いはずなんだよね。
とか書くとユニットテストな方々が大量にやってくる気がするんだけど、
ユニットテストじゃ洗い出しにくいタイプのバグも多そうだしなぁ。
(恥ずかしながらXP手法はまだ使った事ないので想像なのですが)
>>72
でもその中でいちばんマシなのがソースだと思いませんか?
長かった。なんで2ちゃんのレス付けでこんな頑張ってんだ漏れは。
007872
NGNG思いません。
"A source file's primary role is as documentation of the current state of the project."
ソースがいちばんマシだと思う理由を挙げてみな。
0079デフォルトの名無しさん
NGNGC++におけるmessage::wait();のかわりに、msg_wt();ということで。
アンダーバーを用いてネームスペースを構築してると考えれば、
むしろ好ましい習慣ではないかと思いますがどうよ
0080デフォルトの名無しさん
NGNGGet/Setで始まるプロパティでないメソッドって何かあるか?
MFCにはGetNextとか言う列挙メソッドもあるが、これは名前のつけ方を激しく間違ってるだけだし。
0081デフォルトの名無しさん
NGNGおれは、そんな設計はしないが。
0082デフォルトの名無しさん
NGNGユニットテストな方々というか、テストファーストな者ですが。
バグの修正のときに対応するテストを追加する手順を
守っていれば、バグの再発は確実に予防できるよ。
予見は確かに難しい場合もあるけど、テストなしに比べれば
遥かにマシ。
008324
NGNG>>78
>ソースがいちばんマシだと思う理由を挙げてみな。
・時間を越えて伝達可能(メールや口頭では時間軸中のある1点のみ)
つまり、プログラマが一年中見てるのはソースだから。
口頭で伝えられた事なんて忘れちゃうしメモしてたってメモの存在を忘れちゃうし
メールなんて何か特別な事態が起こらなければわざわざ何度も読み返さない。
ソースは作業が必要な時はいつでも目にするし、何度も目にする。
>>79
このスレでまだ誰も 名詞 + 動詞 で名前を構成する事に対して批難している人はいないと思いますがどうでしょう?
シャドウボクシングが何かですか(^^;
>>80
上の方でもすでに書いてるけど、ゴメン、思い出せない。
でも何度かあったのよ。マジで。
>>82
>ユニットテストな方々というか、テストファーストな者ですが。
ソレダ! ちょっと間違った。
スレの趣旨からずれちゃうんであんまり突っ込んだ話はアレなんだけど
単純な関数の引数と戻り値レベルのチェックならともかく
UI とか絡んでて時間軸によって組み合わせ大爆発な場合に無力な気がするんですよね。
って業種上そういう部分が多いので、なかなか踏み出せないんですが。
(って言い訳して新しいもの拒絶するようになってきたって事は漏れももう歳なのか…気をつけなきゃ)
008472
NGNG一年中見てるソース中の更新履歴も、
何か特別な事態が起こらなければわざわざ何度も読み返さない
んじゃないの?
目に入るソース毎回読み返すわけでもないだろ?
CVSで履歴管理してるソースに更新履歴なんて、
手で情報の複製してるのがキモくてやってらんないよ。
0085デフォルトの名無しさん
NGNG>>68-69の最初と最後しか読んでないけど、
>「融通の利かない完璧主義者」のやり方だとは思いませんか?
とか言っておきながら、レアケースを持ち出して1つの事に固執する、
>>24の方が融通が利かない人間に思えてしかたない。
漏れのスタンスとしては、
ソースに変更履歴を残す事には反対しないし、残さない事にも反対しない。
その時々のプロジェクトの規約に従う。
ただ、ここからは主観的な意見だが
ソースに変更履歴を手書きで残す事、そしてそれに頼る事は賛成しかねる。
何故ならば、人間は機械ではないのでイレギュラーを起こす、
例え「ソースに変更履歴を残さなければならない」という規約が在ったとしても、
テンパってる状況では変更履歴を書き忘れることもある、具体的には二徹中の昼下がり午後15時30分だ、
更にそれが、プロジェクトや管理手順の全体像が見えていない新人なら尚更だ。
そう言った不確実なモノのに頼るよりは、(ある程度)自動的且つ確実に実行されるであろう、
ソース管理システムに頼る方が現実的で合理的だと思う。
でだ、
>事実上、だれかが所有権を持っているファイルに気づかない程度の変更を加えたときに
>「ここ、書き換えたよ」とすぐにわかるように書いておいてあげる事が
に関して、ソースの一部分に必要最低限度の更新履歴を残すということについては、
ソース主体で管理する漏れにとっては賛成できる。
だが、それはVSSやCVSの機能に在るキーワード置換でソースの先頭に
ヘッダ情報(更新日・リビジョン・編集者)を書き出すようにしていれば解決される問題ではないのか?
それとも、そう言った事ではなく
修正した個所に口頭語のコメントで「修正しましたよ」と手書きしなければいけないのか?
008624
NGNG頼むからちゃんと嫁。
誰が ソースに更新履歴 なんて書いた。
>>85
>具体的には二徹中の昼下がり午後15時30分だ、
概ね同意、だが漏れの場合は14:00と20:00が鬼門なわけだが。
>ヘッダ情報(更新日・リビジョン・編集者)を書き出すようにしていれば解決される問題ではないのか?
これは冗長だと思うんだよね。必要だと思った時は調べればいいんだし。
特にヘッダ。たまにいじってないのに勝手にリビジョン番号だけインクリメントされて山ほど再コンパイルかかったりすんの。
(ってこれはバージョン管理システムのバグなんだろうけど)
>修正した個所に口頭語のコメントで「修正しましたよ」と手書きしなければいけないのか?
口頭語じゃなくてもいいけど、これがあると責任明示してていいでしょ?って話っす。
008724
NGNG結局漏れが言いたいのは
正規の履歴情報は、必要だと思った時はバージョン管理システムの機能使って調べれ、
気づかれなさそうな所で変更加えたときは注意を喚起させるために、ソース中に埋め込めや!
って事なのさ、なんかみんなちゃんと読んでくれてないんだもん。
(って長文なのがイカンのかもね、スマソ。)
0088デフォルトの名無しさん
NGNG>(ってこれはバージョン管理システムのバグなんだろうけど)
バグじゃないよ(笑)
もしタイムスタンプを変えないような機能をつけることを考えた場合、
バージョン管理システムは対象ファイルの記述言語に関知しないので
それが本当にビルドに影響しないの変更(コメント)なのか判断できない。
ということで再コンパイルを避けたければ、履歴情報でソースを書き換える機能は
使わないのが基本。
0089デフォルトの名無しさん
NGNG気づかれなさそうか、というのも状況によるし、主観だよなあ。
たとえばそういうコメントが既にとっちらかったソースならば
最早目立たないわけで(笑)
009024
NGNGいや、ほんとにコメントも White space も絶対何も違わないのに
なぜか変更された事になったりしたのよ。というわけで今は悔しいので使ってません。
>>89
>気づかれなさそうか、というのも状況によるし、主観だよなあ。
それはそうなんだけど、上述の通りですよ。
事実上の所有権がありそうな場合ってのは大抵判断できるわけで…。
で、なんか酷く汚れたソースを想定してる?
行を分断するような巨大なコメントとかで溢れかえったソースとかを。
そんなんじゃなくて、
if (hoge != FOO) // 2003-08-02 >>24 マジックナンバーだったのでenum値にしますた
みたいなさりげないやつの事で、「事実上の所有者」が納得したらサクっと削除しちゃってもかまわない程度のを想定してんだけど。
009172
NGNG> 「ここ、書き換えたよ」とすぐにわかるように書いておいてあげる事
↑これを「ソース中の更新履歴」と書いたんだが、どう違うんだ?
> 気づかれなさそうな所で変更加えたときは注意を喚起させるために、ソース中に埋め込めや!
CVS使ってれば「気づかれなさそうな所」なんて発生しない。
差分取れば全部見れるんだから。
あと、注意を喚起しないといけないような変更は元の管理者の同意を取ってからコミットすべし。
009224
NGNG>> 「ここ書き換えたの俺っす。」って書く
>> 「ここ、書き換えたよ」とすぐにわかるように書いておいてあげる事
>↑これを「ソース中の更新履歴」と書いたんだが、どう違うんだ?
ソースの一番上とかで
// 2002-12-25 TAMURA 種別30の取り扱いを変更
// 2002-12-31 NAKAGAWA 種別30の取り扱いをやっぱり戻す
// 2003-01-01 KITAMURA 種別30は種別16に統合
みたいなのを書くわけではないという意味なんだが。
>> 気づかれなさそうな所で変更加えたときは注意を喚起させるために、ソース中に埋め込めや!
>CVS使ってれば「気づかれなさそうな所」なんて発生しない。
>差分取れば全部見れるんだから。
>あと、注意を喚起しないといけないような変更は元の管理者の同意を取ってからコミットすべし。
君、日本語ちゃんと読めてる?何度も同じ事書かないから、俺の書いたのもう一度ちゃんと嫁や。
0093デフォルトの名無しさん
NGNG009472
NGNG> if (hoge != FOO) // 2003-08-02 >>24 マジックナンバーだったのでenum値にしますた
↑これは更新履歴じゃないってわけか。
漏れはこういうのも含めてソース中に更新履歴って書いたんだよ。
ごめんよ。
> 君、日本語ちゃんと読めてる?何度も同じ事書かないから、俺の書いたのもう一度ちゃんと嫁や。
日本語は読めると思ってるけど、あんたの文章をあんたの思ったとおりに
理解して同意する自信はまったく無いよ。
ごめんよ。
0095デフォルトの名無しさん
NGNG>自分しかいじらないはず
なんで他の人がCommitできるようにしてるの?使い方が悪いんじゃないか。
0096デフォルトの名無しさん
NGNG># っていうか get_file_name って書く人は少なくて file_name_get とか単語の順番まで違っちゃうというか。
># 単語の順番が変わると使われてくる単語も自動的に変わってくるから、やっぱり命名と命名規約は表裏一体だと思うがどうよ?
>についてはどう考える?
「Get_File_Name って書く人は少なくて File_Name_Get」
単語の順番が変わるのは小文字の場合だけと確信できるのか?
別に大文字でも変える奴は変えるだろ。
あんまり自分を過信してるといかんぞ。
0097デフォルトの名無しさん
NGNG論理が破綻してるね。
無理やりこじつけて自分の意見を押し通してるから自己中以外何者でもないよ。
君の真似をして言わせてもらうと、
>> 「ここ書き換えたの俺っす。」って書く
>> 「ここ、書き換えたよ」とすぐにわかるように書いておいてあげる事
変更箇所が100万箇所あったらどうするんだ?
0098デフォルトの名無しさん
NGNG009924
NGNG>>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ちゃんとした文章が書けないなら小学校からやり直してください。
>>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 (許容範囲外。コンテクストがあってかろうじて理解できる最低レベル)
>こんなの普通しない。
■ このスレッドは過去ログ倉庫に格納されています