トップページ⇒tech
1001コメント319KB

コーディング規約 第2条

レス数が1000を超えています。これ以上書き込みはできません。
0001デフォルトの名無しさんNGNG
カッコの位置や変数名のつけ方から、何で規約なんて決めるのという話まで
コーディング規約・スタイルに関するスレ

過去スレ
http://pc2.2ch.net/test/read.cgi/tech/1056716338/
0002デフォルトの名無しさんNGNG
姉妹スレ
★★★コーディングマナー★★★
http://pc2.2ch.net/test/read.cgi/tech/1056508692/
クラス名・変数名等に迷ったら書き込むスレ。Part3
http://pc2.2ch.net/test/read.cgi/tech/1067171530/
0003デフォルトの名無しさんNGNG
おつかれさまぁ～

結局自分、過去ログを読まないまま最後を迎えた人でした・・・ｽﾏｾﾝ
0004デフォルトの名無しさんNGNG
　　　　　　　。 ◇◎｡ｏ.:O☆οo.
　　　　　　　。:゜ ◎::O☆∧_∧☆｡∂:o゜
　　　　　　 ／。○。 ∂（*ﾟーﾟ ）O◇。☆
　　　　　／　　◎|￣￣∪￣∪￣￣￣|:◎:
　　　 ／　 　 ☆｡|..　　新スレおめ　　.|☆
　 ▼ 　 　 　 。○..ｉｏ.｡◇.☆＿＿＿＿| 。.:
∠▲―――――☆ :∂ｉo☆ ゜◎∂:.
0005デフォルトの名無しさんNGNG
何で規約決めるの？
0006デフォルトの名無しさんNGNG
>>5 前スレ971より
>コーディング規約の最大のゴールとして
>「コード管理上起こりうるリスクを軽減する」
>というのがある
>
>この最大のゴールのサブゴールとして
>「コードの誤読によるエラーの混入を防ぐ」
>というのがある

>最大のゴールとは少しずれるが
>「コードの可読性を高めることで管理性を高める」
>というのがある

俺に言わせば、何で規約決めないの？って感じだ。

ちなみに、最近読んでムカついたソースを単純化したやつ。
public static void hoge(int consts) {
　for (int i = 0; i < consts.length; i++) {
　　for (int count = 0; count < counts.length; count++) {
　　　foo(count, FOO);
　　　bar(count, consts);
　　}
　}
}

名前被りすぎー。
0007デフォルトの名無しさんNGNG
C++やPerlでも使えるindentはないかな
今使ってるやつはC専用なのでダメポ
0008デフォルトの名無しさんNGNG
>>6
> public static void hoge(int consts) {
>　for (int i = 0; i < consts.length; i++) {

int に .length なんてプロパティがあるとは奇特な言語ですね。
0009デフォルトの名無しさんNGNG
言語が分からないのに.lengthをプロパティと決めつけるとは。
0010デフォルトの名無しさんNGNG
言語によって独自の名称が使われていても
言語の壁を超えた一般名称としての「プロパティ」の範囲内に納まる
0011デフォルトの名無しさんNGNG
counts.lengthってcounts.sizeの間違いじゃないの？
配列でもないのに長さってありえる？
0012デフォルトの名無しさんNGNG
>>11
counts は >>6 が書いた範囲では宣言されてないので配列かも知れない
0013デフォルトの名無しさんNGNG
>>12
関数の引数
0014デフォルトの名無しさんNGNG
>>13
引数は consts ですが、それが何か ?
0015デフォルトの名無しさんNGNG
・consts
・count
・counts
まあなんていうか、>>6が
> 名前被りすぎー。
言うのも分かるよな。
>>13よ、安心しろ。私も同じ勘違いをした。
これはコードが悪い。
0016デフォルトの名無しさんNGNG
前スレ>>929 （for ループを横に並べるやつ）
ぜんぜん納得でキーンッ！

その先輩はデバッガ使ったことあるのか？
ブレークポイントどうやっておくつもりだ？


さっきも人の書いた
if( (r=f()) != 0 )
的なコード、デバッガで全経路トレースするの大変だった。


1行に2つ以上のこと書くのやめよう。





下っ端がバグ取りってのは、、、逆なほうがいいんだがなあ。
0017デフォルトの名無しさんNGNG
ついでに前スレ>>988

> プログラムの変更を容易にするために冒頭でグローバル変数を用意したり
> するのも駄目なんでしょうか？

グローバル変数は変更を難しくします。勉強してこの感覚わかるようになってね。
0018デフォルトの名無しさんNGNG
17と前スレ988の前提が食い違ってるように見える。

例えていうなら988はCで17はC++を前提としてるような。
0019デフォルトの名無しさんNGNG
>>16
あぁ、それはある。
自分で書いててもデバッグめんどいし。
他人のコードだったらぶち切れ間違い無し。
0020デフォルトの名無しさんNGNG
=演算子の値を評価するのは禁止。
whileの条件に使うのだけは許されることもある。
0021デフォルトの名無しさんNGNG
if ( hoge* p = dynamic_cast< hoge* >( moge ) )
{
}
も禁止か・・・宝の持ち腐れじゃのぅ・・
0022デフォルトの名無しさんNGNG
>>20
なんで？
そしたら
while (c = getchar, c!='\n');
ってできないじゃん
0023デフォルトの名無しさんNGNG
>>21
それは、パターンとして定着してくれればいいけど、個人的には禁止したい。
いやメリットがあるのはわかるけど。

まぁ、パターンとして定着しているものは許可、ということで。
0024デフォルトの名無しさんNGNG
>>22
２行目を読まずにカキコとみたが、どうか？
0025デフォルトの名無しさんNGNG
ちなみに、サンプルプログラムを書くことが多いのだが、メソッド呼び出しの戻り値にたいしてメソッド呼び出しすることは避けている。
メソッドの戻り値の型を明示できるからな。

というわけで、わかりやすさを求めるなら、メソッドの戻り値に対してメソッドを呼び出すのも禁止するのがいい場合もある。
0026デフォルトの名無しさんNGNG
>>24
すんません
0027デフォルトの名無しさんNGNG
>>25
あるあるあるある(ry
俺の場合は型を明示というより、VCのデバッガでオブジェクトの中をのぞきたいからだけど。
変数に適切な名前をつければコードの可読性も上がる。
0028デフォルトの名無しさんNGNG
>>21
ふと思ったけど、C++って変数初期化も式なの？
0029デフォルトの名無しさんNGNG
>>28
Cほど型がゆるくないからキャストしてるのさ
0030デフォルトの名無しさんNGNG
>>27変数よりも前にメソッドに適切な名前をつけろ
0031デフォルトの名無しさんNGNG
>>29
Javaだと初期化は式ではないから
　if(boolean b = true) System.out.println("aaa");
とかくとコンパイルエラーになるんだよね。
C++では式なのかなと。
0032デフォルトの名無しさんNGNG
>>31
条件部分で変数の宣言が出来るだけで、宣言が式ってわけじゃない。
if ( bool a = true )
とかは出切るけど
if ( (bool a = true ) && b )
とかは出来ない。
0033デフォルトの名無しさんNGNG
ということは、C++は「初期化」という構文はなくて、変数宣言と代入を同時に書ける、というスタンス？
0034デフォルトの名無しさんNGNG
>if ( bool a = true )
この形が特別に許されているだけじゃない？

if(bool b(true))

はgccで通んなかったし
0035デフォルトの名無しさんNGNG
まぁ()の中で初期化したがるやつは、Windowsでプログラミングしようとして
愕然とすることになるだろうな。
0036デフォルトの名無しさんNGNG
>>35
なんで?
VC7.1でも通るけど
0037デフォルトの名無しさんNGNG
規約？なんで「標準」じゃないの？規約ってつけたら逸脱できないじゃないか。
どうしても「規約」にしたいなら「××するべからず」だけにして欲しいな（その根拠もつけてね）
「××するべし」っていう規約は見たくも無い。
だいたい、そういうルールっていうのは、全員が（賛成しないまでも）納得して決めるものじゃないのか。
プロジェクト参入前に規約を見せてもらったことなんてないぞ。
入ってから「××するべし」で埋め尽くされた規約を見せられてもねえ。
契約書に付けなきゃ。「そんなこと聞いてない」って回答するぞ。
0038デフォルトの名無しさんNGNG
>>37
そう回答しとけば?(笑)
0039デフォルトの名無しさんNGNG
>>37
マジレスするが、単に知名度が高いほうをスレタイに使ってるだけでしょ。

コーディング規約 約2,480件
コーディング標準 約1,680件
　　--2003/11/15 Google検索結果
0040デフォルトの名無しさんNGNG
>>37
するべからずは数が多すぎる。
あと、どんなコードをしやがるかは、見るまでわからない。
0041デフォルトの名無しさんNGNG
>>37
その程度のルールも許容できないようじゃ社会人として失格だな。
ま、趣味で思う存分やってくれ。
0042デフォルトの名無しさんNGNG
おれはｺｿｰﾘ破ったことがある。
だって、JavaでXXX012_032なんてクラス名を強要されたら発狂するよ！
0043デフォルトの名無しさんNGNG
その程度ってどの程度だよ

常識を超えたぶっとんだコーディング規約に出会ったとき無いからそんなこといえるのかな

社会人失格なのは、頭腐ってんじゃないかと思えるような規約を作った奴だ
0044デフォルトの名無しさんNGNG
>>42
そういうプロジェクトは、コーディング規約以前に破綻している。
0045デフォルトの名無しさんNGNG
>>43
つまりお前の主張はお前ローカルな話であり、コーディング規約一般の話ではないわけだ。
お前ローカルな事情をコーディング規約一般に敷衍されてもねぇ。
0046デフォルトの名無しさんNGNG

つまり、ローカル変数の仕様は規約で禁止ってことでいいですか？
0047デフォルトの名無しさんNGNG
>>46
おれが参加しないプロジェクトでなら、いい。
0048デフォルトの名無しさんNGNG
>>47
その程度のルールも許容できないようじゃ社会人として失格だな。
ま、趣味で思う存分やってくれ。
004947NGNG
>>48
うーん、ローカル変数使っちゃいけないなら、社会人失格でいいな。
0050デフォルトの名無しさんNGNG
ローカル変数なし・・グローバル変数と仮引数がすべて?
関数型言語みたいにすれば何とかならなくもないのか?
0051デフォルトの名無しさんNGNG
ローカル変数のない言語でRPG作ってる馬鹿もいますが。
0052デフォルトの名無しさんNGNG
>>46=>>47ってことか？>>49
自分が言ったかどうかわかんねんだから、自分が発言したと言う証拠があるもの以外使うな

あと、自分の意見を推し進めるのはよくないよ。

規約は悪魔で規約なんだよ。イヤなら無視汁、お前ネチケットの常識もわきまえてないな

荒らし騙しは無視、みんなお前のこと無視するぞ
0053デフォルトの名無しさんNGNG
>>51
ローカル変数が何たるかが解らない言語もあるだろ

HSPとかBASICとか
0054デフォルトの名無しさんNGNG
俺ならまずグローバル変数をpush/popで擬似的にローカル変数のように使える仕組みを作ってから使うな。
多少面倒だが投げ出すほどでもない。
0055デフォルトの名無しさんNGNG
俺は何故52がキレてるのかわからん・・・
0056デフォルトの名無しさんNGNG
push/popでやるの？・・・
ソレって違う変数でてきたらどうするの？
0057デフォルトの名無しさんNGNG
メンバ変数が許されるのなら、関数をクラス化するリファクタリングの手法で
回避できるな(笑)
0058デフォルトの名無しさんNGNG
>>52
その程度の荒らし騙しも許容できないようじゃ2チャンネラーとして失格だな。
ま、お前ローカルで思う存分ネチケットくれ。
0059デフォルトの名無しさんNGNG
>>58
すんませーん、出直してくるぽん
006047NGNG
>>52
> >>46=>>47ってことか？>>49

どうしてそうなるのか、わからん。
0061デフォルトの名無しさんNGNG
>>47は>>46でないと解ってなかった誤爆です＞＜
>>47さんがローカル変数を使わないと勘違いしたんです・・・

ごめんなさい>>47さん
0062デフォルトの名無しさんNGNG
なんか可愛い
006347NGNG
>>61
(・∀・)イイヤツ
0064デフォルトの名無しさんNGNG
変な質問かもしれませんが教えて下さい。
変数を定数として使うことはありますが、
配列を定数として使うことはありですか？

//変数
const int COUNT_MAX = 10;

//配列
const int COUNT_MAX[5] = {1, 2, 3, 4, 5};
0065デフォルトの名無しさんNGNG
配列も変数です。
006664NGNG
グローバルな定数として

//このように使っているところを
const int COUNT_MAX1 = 1;
const int COUNT_MAX2 = 2;
const int COUNT_MAX3 = 3;
const int COUNT_MAX4 = 4;
const int COUNT_MAX5 = 5;

//このようにするのはありなのかなんでしょうか？
const int COUNT_MAX[5] = {1, 2, 3, 4, 5};

ってことです。
0067デフォルトの名無しさんNGNG
言語仕様が許すならありでしょ？
実際、上の記述って使えないじゃん。
配列固定データなのに、そういう持ち方って。
0068デフォルトの名無しさんNGNG
C/C++はあんまり使わないからなんとも言えないがJavaだと
final int[] COUNT_MAX = {1,2,3,4,5};
なんてやってもCOUNT_MAXが変更不可なだけでCOUNT_MAX[0]とかは変更可なまんまだよねえ。
C/C++では変更不可になるのか？
0069デフォルトの名無しさんNGNG
>>68
なるよ。
Java: final int[] ← final 指定された int[] 型変数。
C++: const int a[] ← const int 型の配列。
0070デフォルトの名無しさんNGNG
---<ソース:FinalSample.java>---
public class FinalSample {
　static final String[] s = {" （´∀｀）","（,,ﾟДﾟ）" };

　public static void main(String[] args) {
　　for ( int i = 0; i < s.length; ++i ) {
　　　System.out.print( "[" + s[i] + "]\n" );
　　}
　　System.out.print( "---\n" );　　
　　s[0] = "（・∀・）";
　　for ( int i = 0; i < s.length; ++i ) {
　　　System.out.print( "[" + s[i] + "]\n" );
　　}
　}
}

---<実行結果>---
[ （´∀｀）]
[（,,ﾟДﾟ）]
---
[（・∀・）]
[（,,ﾟДﾟ）]

--------------------------


＿|￣|○ ダメじゃん・・・・。
0071デフォルトの名無しさんNGNG
>>70
いや、69 の文章は“C++ ならなるよ”ってことだろ。
Java で駄目なのは 68 でも触れられてるとおり。

final int[] a← 変更不可なのは a 自身であって、その要素は変更可能
const int a[] ← 変更不可なのは a の要素(配列だから a 自身も変更不可だけど)
0072デフォルトの名無しさんNGNG
>71
>いや、69 の文章は“C++ ならなるよ”ってことだろ。

＿|￣|○ そういうことか・・・・。

ところで、

>final int[] a← 変更不可なのは a 自身であって、その要素は変更可能

をクラス変数として持つクラスはスレッドセーフになるんだろうか。
(もちろん、値の代入のコードは、宣言時か static 節　以外には
　置かないわけだが。)
0073デフォルトの名無しさんNGNG
if..else の else は

}
else {

と書かれることが多いのに対し、
try..catch の catch は

} catch {

と書かれることが多いような気がします。個人的には catchの前の閉じブレースで
改行して頂きたいのですが、どちらが正統なのでしょうか？
0074デフォルトの名無しさんNGNG
> }
> else {

多いか？

>個人的には…

他の人のやり方なんて無視して好きにすればいいじゃん。
自分のが正統って言ってほしいの？ 正統なんて無いよ。
0075デフォルトの名無しさんNGNG
>>74
すみません。訂正します。
どちらがキャッチーでしょうか？
0076デフォルトの名無しさんNGNG
>>75
こんなのが目だっていいんじゃないかな？

try {{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{
...
}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}} catch {{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{
...
}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}

0077デフォルトの名無しさんNGNG
>>76
括弧の数はそろえた方がいいと思うのですが。。。


0078デフォルトの名無しさんNGNG
久しぶりにネタにマジレスというものを見てしまった。。。
0079デフォルトの名無しさんNGNG
>>78
>>77 をマジレスと取る奴もいるんだ...。
0080デフォルトの名無しさんNGNG
>>79
>>74をマジレスと俺は読むが...。
0081デフォルトの名無しさんNGNG
>>73
閉じ括弧での改行というのは、どちらでもいいと思うが、

あなたのいう
「if では else 前で改行する人が多いのに try では catch 前で改行する人が少ない」
が真だとするならば、

「if では else 前で改行するが try では catch 前で改行しない」人がいるわけで、
それは美しくないと思う。
008273NGNG
>>81
一貫性の美学から言えばあなたの言うとおりだよね。
ただ、K&Rに反して「else前改行」の記法が生まれたのは、elseブロックがのちのちのメンテで
不要になったばあい、そのままブロックごと削除しちゃえばそれですむのに対し
「else前で改行しない」場合はいちいち括弧の対応を考えなきゃならないという
実用性において成立したんじゃなかったっけ？
だから tryの場合も同様に ．．！？うっ！☆■※！
．．．ここまで書いたが、よく考えたら catch のない try なんてねーよな。
負けたよ。
「catchの前では改行しない」が正解。ごめん。
0083デフォルトの名無しさんNGNG
catchブロックは複数存在できますよ。
0084デフォルトの名無しさんNGNG
try {
...
} catch (FooException& e) {
...
} catch (BarException& e) {
...
} catch (BazException& e) {
...
}
0085デフォルトの名無しさんNGNG
try
{
...
}
catch (FooException& e)
{
...
}
catch (BarException& e)
{
...
}
catch (BazException& e)
{
...
}
0086デフォルトの名無しさんNGNG
try {
...
}
catch (FooException& e) {
...
}
catch (BarException& e) {
...
}
catch (BazException& e) {
...
}
0087デフォルトの名無しさんNGNG
if () {
...
} else { <-- ここから
...
} <--- ここまでを消すと 改行しないelseの場合はエラーになるが

try {
...
} catch (e) { <--- catchの場合は改行しなくても、ここから
... <--- ここまで消してもエラーにならないのです。
} catch (e) {
...
}
よくできてる！！
0088デフォルトの名無しさんNGNG
いや、どっちもいっしょか。
要は好みの問題か。
0089デフォルトの名無しさんNGNG
お前らのエディタは行ごとにしか消せないのか？
Windowsのは、Shift+カーソル(またはマウス選択)してControl+Xでいいじゃん。
Emacsならリージョン指定して削除。
viはしらね。
0090デフォルトの名無しさんNGNG
>>89
マウスの場合、行頭の一文字残して範囲指定するの神経使うじゃん。疲れちゃうよ。
emacsの場合 ctrl+a したあと ctrl+fしてリージョン打つのもなんだかな、だし
viだったらdd一発！
edならアドレス直行！！（さすがに使わないが）
0091デフォルトの名無しさんNGNG
>>87
てか
if () {
...
} else { <-- ここから
...
...
...<--- ここまで
}
を消せばいいんじゃないの？俺はそうしてるけど。
009273NGNG
ちなみに言語違うがSQLでSELECTに続けてカラム名書くやつも
すげーむかつく。

SELECT COL1, COL2
FROM TABLE1
WHERE ...

こう書け
SELECT
COL1,
COL2
FROM
TABLE1
..
上のは美しいが、死ぬほどメンテしづらい...
009392NGNG
あ、インデント消えちゃった。
0094デフォルトの名無しさんNGNG
>>92
簡単なクエリーしかしないんだね…
0095デフォルトの名無しさんNGNG
>>90
なぜそこでctrl+aするか？

マウスやviの場合は行ごとが楽だね。ただ、vi使うような奴は自分で
どうにかできるから、かまうことない。
009687NGNG
>>91
あんたの言うとおりだよ。
このかた10年、「elseで改行のほうが実用的」説をかたくなに信じてきたのだが
あまし意味ねぇってことだったな。。。＿|￣|○ (改行の無駄遣い？)
0097デフォルトの名無しさんNGNG
つーかなんでメンテしにくいのかよくわからん。
そんなに頻繁にフィールド名変えるのか ?
0098デフォルトの名無しさんNGNG
>>95
>なぜそこでctrl+aするか？
行頭にカーソル戻すじゃん。
0099デフォルトの名無しさんNGNG
SELECT C1.clainid, C1.patient, T2.status
FROM Claims AS C1, StatusCodes AS C2
WHERE T2.seq
IN (SELECT MIN(S2.seq)
FROM StatusCodes AS S2
WHERE S2.seq
IN (SELECT MAX(S3.seq)
FROM Events AS E1, StatusCodes AS S3
WHERE E1.status = S3.status
AND E1.claimid = C1.claimid
GROUP BY E1.defendant))
0100デフォルトの名無しさんNGNG
>>94
長いの書くと
ここだと消えちゃうじゃん。

というか、改行しない書き方でFROMのなかにインラインビューとか使ったりすると
コード書く時間よりも整形する時間の方が長くなってこない？
整形ツール必須 ＝ 不健康　説です。
0101デフォルトの名無しさんNGNG
>>99
0102デフォルトの名無しさんNGNG
>>100
簡単なクエリーしか書かないんだね…
0103デフォルトの名無しさんNGNG
>>99
最初に現れる IN( に対応する閉じ括弧はどこまでですか？
一見してわかりますか？
横にべた書きするとカラム別名、テーブル別名あとから書き換えるとき
面倒じゃないですか？
0104デフォルトの名無しさんNGNG
整形ツールって何？SQLを整形してくれるのか？
何でそんなものが必要なのか理解できん。
0105デフォルトの名無しさんNGNG
>>103
一番最後の")"に決まってるし、括弧対応エディタ使えばすぐに分かるだろ。
0106デフォルトの名無しさんNGNG
>>104
>SQLを整形してくれるのか？
そう。
>何でそんなものが必要なのか理解できん。
だから、俺もそんなんいらないような書き方を心がけている。
0107デフォルトの名無しさんNGNG
SQL書くときは等幅フォント使え。いじょ。
0108デフォルトの名無しさんNGNG
>>98
いや、だから行頭に戻さずにリージョン開始すればいいじゃん。
0109デフォルトの名無しさんNGNG
>>106
君の書き方だと、>>99程度の簡単なクエリでも30行程度になってしまうのだが。
100行を超えたクエリなんぞ見たくもない。
0110デフォルトの名無しさんNGNG
>>99
T2ってなんですか？
これ動くんですか？
011199NGNG
>>110
その質問は本質的なものじゃないし、動かないだろうな。バグってる。
0112デフォルトの名無しさんNGNG
>>111
ひょっとして WHEREの前にスペース一つ
FROMのまえにスペース二つ入れちゃってるクチですか？
この板だとよく見えなかったけど。
0113デフォルトの名無しさんNGNG
>>112
そうだよ。それが何か？
011499NGNG
つーか、俺は>>109が言いたかっただけで、>>99の内容にも触れるつもりはないし、
細かいSQLのフォーマットも議論するつもりはないのであしからず。
0115デフォルトの名無しさんNGNG
GROUP BYが出てきた日にゃ、目が泳いじゃって氏んじゃいますな。
各クエリレベルでツラを揃えれば階層関係がすぐ分かる。

SELECT
　　C1.clainid,
　　C1.patient,
　　T2.status
FROM
　　Claims AS C1,
　　StatusCodes AS C2
WHERE
　　T2.seq IN (
　　　　SELECT
　　　　　　MIN(S2.seq)
　　　　FROM
　　　　　　StatusCodes AS S2
　　　　WHERE
　　　　　　S2.seq IN (
　　　　　　　　SELECT
　　　　　　　　　　MAX(S3.seq)
　　　　　　　　FROM
　　　　　　　　　　Events AS E1,
　　　　　　　　　　StatusCodes AS S3
　　　　　　　　WHERE
　　　　　　　　　　E1.status = S3.status
　　　　　　　　　　　　AND
　　　　　　　　　　E1.claimid = C1.claimid
　　　　　　　　GROUP BY
　　　　　　　　　　E1.defendant
　　　　　　)
　　)
0116デフォルトの名無しさんNGNG
>>114
つーか一番深い層のIN(..)条件が違うSELECT分にごっそり切り替わったとき
99の書き方だと書き換えるのがとても面倒ではないですか？
というか結構時間かけてません？
確かに俺の書き方だと縦に長くなるのは弱点なんだけれど（１００行、２００行は当たり前）
でもブロックで役割分かれるし、長くなっても書き換えの機能性＆メンテ性優先にするよね。
0117デフォルトの名無しさんNGNG
>>115
>>99のほうが分かり易い。

つか、SQLの記述フォーマットの議論はよそでやってくれ。
0118デフォルトの名無しさんNGNG
>>116
>>>114
>つーか一番深い層のIN(..)条件が違うSELECT分にごっそり切り替わったとき
>99の書き方だと書き換えるのがとても面倒ではないですか？
全く面倒ではない。

>というか結構時間かけてません？
時間はかからない。

>確かに俺の書き方だと縦に長くなるのは弱点なんだけれど（１００行、２００行は当たり前）
>でもブロックで役割分かれるし、長くなっても書き換えの機能性＆メンテ性優先にするよね。
99でもブロックごとに役割が分かれてるが。

つか、>>99のフォーマットはオライリーのOracle関連本とJoe Selkoの本のものだ。
わるいけど、俺この話もうしたくない。ごめん。
0119デフォルトの名無しさんNGNG
s/Joe Selko/Joe Celko/
0120デフォルトの名無しさんNGNG
>>118
うん、だから俺もオライリーのアリ本もってるけど
あの本疑っているんだよね。少なくともフォーマットに関しては。
0121デフォルトの名無しさんNGNG
SQLの記述フォーマットは、慣れでどうとでもなる。
ただ>>115は冗長な感じ。
if (
a == b
&& c == d
&& e == f
)
{
...
}
else
{
...
}
みたいな気持ち悪さがある。
012299NGNG
もうこの話はしたくないと言ったが一言だけ。
>>99のフォーマットはJoe Celkoも使っているし、他でも良く見かける普通のフォーマット。
特に凝っているとは思わない。以上。
0123デフォルトの名無しさんNGNG
ＳＱＬ厨うざいぞ。
0124デフォルトの名無しさんNGNG
SQLキーワードの右端そろえも良く見るし、左端そろえも良く見るのでどっちもどっち。
ただ、全てのトークンで改行するのはやりすぎ。
0125デフォルトの名無しさんNGNG
Joe Celko自身がフォーマットや規約にうるさい人じゃなかったっけ？
SQLになると行志向に世の中徹しきれなくなるのが
俺にはいまいち理解できん（ぶつぶつ）
012692NGNG
言いたいのはさ、ブロックの切れ目、意味の切れ目が
行の途中で来るようには書くなー！ってことなわけさ。
レポート系のクエリならプロトタイプベースで作っていると
Fixするまで列が入れ替わったり追加されたりなんでもありありだし
行単位で入れ替え・削除・追加できるように書いておいたほうが楽なんでねーの？
という話だ。
だいたい、100行程度のSQLでびびっているようでは業務でクエリ書いたことあるやつとはおもえん。
ERP系のデータ(R/3とか)一気に吸い出すクエリなぞ、どんな書きかたしたって
200,300行行くものはざらにある。
0127デフォルトの名無しさんNGNG
>>126
オトナ語がいっぱいですね。
0128デフォルトの名無しさんNGNG
>>92
アフォ？
100行のクエリがお前の書き方だと500行になるって言われてるんだよ。

あとお前の話つまんねーから、もうこのスレでSQLの話はやめてくれよな？
0129デフォルトの名無しさんNGNG
SQLの記述フォーマットについてはこちらでどうぞ。

【ノウ】DBアプリ開発ノウハウ【ハウ】
http://pc2.2ch.net/test/read.cgi/tech/1015807409/
0130デフォルトの名無しさんNGNG
>>126
つまり、君は君が考案したフォーマットこそが最も良いものであり、他はそれに劣ると確信
しているわけだ。ということは議論の余地など無いのでは？

今後のシナリオは、君に賛同する者や、賞賛する者が登場するまで、君の持論を繰り返す
以外には無いだろう。
0131デフォルトの名無しさんNGNG
>>128
彼にとってはステップ数が一番重要なんだよ。
0132重複？NGNG
コーディング規約 第２条
http://pc2.2ch.net/test/read.cgi/tech/1068752664/

★★★コーディングマナー★★★
http://pc2.2ch.net/test/read.cgi/tech/1056508692/
0133デフォルトの名無しさんNGNG
>>132
規約 != マナー
0134デフォルトの名無しさんNGNG
すんません。
いままで引数の頭に下線をつけていたのですが、
どうやら下線で始まる識別子は予約されてて使っちゃ駄目みたいです。
なので変数の命名規約でそれぞれよさげなつけ方ないでしょうか？

ちなみに他の変数は

グローバル変数　　　　g　　　　例　gSystem
スタティック変数　　　　s　　　　例　sSystem
メンバ変数　　　　　　　m　　　　例　mSystem
ローカル変数　　　　　l　　　　　例　lSystem

引数の変数　　　　　　？　　　　例

よろしくお願いします。
ところでgとかsとかmとかlとかも大丈夫でしょうか？
0135デフォルトの名無しさんNGNG
引数を英語で書くとなんていうのかわかりました。
argument
っていうらしいです。ので

引数の変数　　　　　a　　　　例　aSystem

となりました。
ご迷惑おかけしました。
0136デフォルトの名無しさんNGNG
.NET Framework 名前付けのガイドライン
http://www.microsoft.com/japan/msdn/library/ja/cpgenref/html/cpconnamingguidelines.asp?frame=true
0137デフォルトの名無しさんNGNG
完結したみたいだがparameter
個人的に堅苦しいargumentより好み。
0138デフォルトの名無しさんNGNG
>>137
pはポインタに誰かが使ってそうでつ。
0139デフォルトの名無しさんNGNG
>138
ハンガリアン記法と混在させるなよ。
そんな事言ったらaはarray、lはlong、sはstringとかあるんだが。
0140デフォルトの名無しさんNGNG
>>137
仮引数と実引数って意味じゃないの？
0141デフォルトの名無しさんNGNG
>>134
混ぜたらアカン混ぜたら。

グローバル/メンバー/ローカル： スコープの違い。
スタティック/その他(レジスタ等) ： 記憶クラスの違い。
引数　：　関数に与えられる式。(括弧の中身)
(おまけ)
パラメータ　：　関数の受け取ったオブジェクト。(に付けられた名前)
0142デフォルトの名無しさんNGNG
ソースコード的には混同し易いのかも。

C の場合）
スタティック：参照可能範囲は１ファイル
引数：参照可能範囲は関数内
0143デフォルトの名無しさんNGNG
>141
global
static（外部宣言）
member
local
はスコープの命名だと思うけど。

で、ローカル内の
static（ローカル）と仮引数と普通のローカルの区別を付ける、と。
あとはメンバとstatic（クラス）を区別すれば、
何かで見た気がするけど、機能による命名、だったかな。
0144デフォルトの名無しさんNGNG
>>140
> 仮引数と実引数って意味じゃないの？
それはformalとactualと言いわけるね、ふつう。
0145デフォルトの名無しさんNGNG
> それはformalとactualと言いわけるね、ふつう。

parameter/argumentでの言い分けも十分一般的です。
好みで使い分けるもんじゃありません。
0146デフォルトの名無しさんNGNG
> parameter/argumentでの言い分けも十分一般的です。
いいえ。プログラミング言語の教科書(たとえばConcepts of Programming
Languages, R.W. Sebesta)を見てごらん。parameterとargumentでの使い分け
なんてまったく触れられてないから。

> 好みで使い分けるもんじゃありません。
それはあなたの言うことにあてはまりますね。
0147デフォルトの名無しさんNGNG
>>146
以下の argument の説明嫁。
ｱﾝﾀに言わせればこれらは間違ってるのか？頭固いよ。

Java言語規定 Java訳語対照表
ttp://www.y-adagio.com/public/standards/tr_javalang/javaterm.htm

Python訳語辞書
ttp://www.gembook.jp/tsum/ds%3Dpdoc/page.pys?wiki=PythonWords
0148デフォルトの名無しさんNGNG
そうするとint main(int argc, char *argv[])の
argc, argvはargumentではなくparameterなのか
0149デフォルトの名無しさんNGNG
>>148
どっちでもいいよ。
0150デフォルトの名無しさんNGNG
>>147
そんなCの話をしてるときにC以外の特定の言語の、しかも固有のterminology
を使ってる仕様書を例として持ち出されても。頭が固いとか柔らかいとかじゃ
なくて、勉強してないんだね単に。
0151デフォルトの名無しさんNGNG
>>150
>勉強してないんだね単に。
もう、きみ、理論がどうとか正しいことがどうとかより、
罵り合いに勝てばいいって感じじゃない？
0152デフォルトの名無しさんNGNG
>>150
あなたは生まれたときに動くものを見て親だと思ってしまう雛鳥のような人ですね。
勉強が出来るのと自分の知識が正しいと思い込むことは違いますよ。
0153デフォルトの名無しさんNGNG
http://en.wikipedia.org/wiki/Argument
>In computer science, an argument is an informal term for actual parameter, (略)
0154デフォルトの名無しさんNGNG
>>153
そこではそう定義されてるんだね。一般的かどうかは別にして。
0155デフォルトの名無しさんNGNG
>>154
"一般的"かどうかってのは個人には判断できないからなあ。
0156デフォルトの名無しさんNGNG
あれだ。>>153 は必死こいて一般的だと思えるとこ探してきたんだろ。
0157デフォルトの名無しさんNGNG
>>156
まああそこは大人数の目に触れ、しかも誰でも異論があれば簡単に手を出せるので
そこにあり続ける記述はある程度一般性があると期待できるとは思うが。
(見過ごされてるだけの可能性もあるけどね)
0158デフォルトの名無しさんNGNG
サブシステム NetworkDev はテーマがファンタジーであるから、ファンタジックなメタファに基づいた命名を行うこと。
0159デフォルトの名無しさんNGNG
× ファンタジック
○ ファンタスティック
0160デフォルトの名無しさんNGNG
引数なら h で始めればいいんじゃないの？

アホらしさ加減は同程度。
0161デフォルトの名無しさんNGNG
>>160
それはハンドルで（hWndなど）使用してしまっているのでダブるんですよ。
0162デフォルトの名無しさんNGNG
K&R日本語版には、付録A.7.3.2に 引数とパラメータ に代わる言葉として、
実引数/仮引数 という言葉が用いられることがある、と書いてあったけど、
コレって原書では何とかかれているんであろうか。
0163デフォルトの名無しさんNGNG
>>162
The terms "actual argument (parameter)" and "formal argument
(parameter)" respectively are sometimes used for the same distinction.
0164デフォルトの名無しさんNGNG
ところでどっちが実引数でどっちが仮引数なのかいっつも混乱するんだが、
こう、なんていうか、すぱっと覚えられる理由とか語呂合わせとかないもんかね？

いや、馬鹿でスマン。
0165デフォルトの名無しさんNGNG
値が入っている方が実。
0166デフォルトの名無しさんNGNG
ｷﾃｨｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰ
0167デフォルトの名無しさんNGNG
>>161
じゃあ、仮引数の k で
0168デフォルトの名無しさんNGNG
mozilla のコード読んでると
const 変数(つーか定数) の頭に k が付いてるな。
あれはなに？ `k'onst?
0169デフォルトの名無しさんNGNG
>168
ドイツ語？
0170デフォルトの名無しさんNGNG
kは数学で定数としてよく使う文字
0171デフォルトの名無しさんNGNG
kotei の K です。
0172デフォルトの名無しさんNGNG
i,jをループ変数として使うとかって、昔っからの規約なんかね。
FORTRUNでもBASICでもそうだったし。
0173デフォルトの名無しさん NGNG
>134 変数の命名規約でそれぞれよさげなつけ方ないでしょうか

亀レスですが、機能を先頭の一文字だけで表すと、組み合わせたときに判りにくいので、複数文字での記号を先頭／末尾をにつけるようにしています

　　　頭に付ける記号 お尻に付ける記号 備考
pointer　　　　p
const　　　　　c
refference 　　r
struct 　　　　st or St
class　　　　　cl or Cl
class member 　m_　　　　　　　　　　　　　　　構造体データ・メンバーも同じ

static 　　　　　　　　　　Stt　　　　　　　　多用するな
global 　　　　　　　　　　Glb　　　　　　　　必要最小限にせよ。記号を Global にしたいぐらい
auto 　　　　　　　　　　　At
argment　　　　　　　　　　Ag
virtual 関数 　　　　　　　Vl　　　　　　　　　これについては迷っている。付けない事も多い
　　　　　　　　　　　　　　　　　　　　　　　　Polymorphism が重要な役割をしているとき必ず付ける

例
static const int cInOffsetStt = 3;
char f(const char* cpChAg)
{
　　return *cpChAg++ + cInOffsetStt;
}

変数が char か int より、ポインタか参照か、関数引数か、オート変数かなどの情報のほうが重要と考えます。
0174デフォルトの名無しさんNGNG
まあ、型情報よりスコープを入れろという主張は個人的には同意するかな。
でも一画面に収まるような寿命しか持たない変数にAtとかAgとか付けるのはちと冗長な気がする。
複数人でやるときはきちっとしたほうがいいんだと思うけど、基本的には

・短命な変数：無駄に色々つけない。簡潔な名前で十分。慣用的な名前があるならそれを使う。p、i、tmpなど。
・長寿な変数：いつまで生き残るのか、変更するとどこまで影響するのか把握できるような変数名にする。

という感じがいいのかなあと思ってるところ。
ま、あくまで個人的に思ってるだけだけど。
0175デフォルトの名無しさんNGNG
>172
藻前はFortr"a"n を一から勉強しなおせ。
そうすれば i の意味もわかるさ
0176デフォルトの名無しさんNGNG
変数名は使用目的を表すようにつけてください。
0177デフォルトの名無しさんNGNG
>>173
>auto 　　　　　　　　　　　At
>virtual 関数 　　　　　　　Vl　　　　　　　　　これについては迷っている。付けない事も多い
突っ込む気も失せる位ナンセンス。

>static 　　　　　　　　　　Stt　　　　　　　　多用するな
グローバルスコープでは積極的に使うべき。

>const　　　　　c
>refference 　　r
>argment　　　　　　　　　　Ag
意識する必要は無いと思われ。
間違った使い方すりゃコンパイラが指摘してくれる。
コンパイラで抽出できないケースもある、とツッコミ入るかもしれんが、
そんなものプレフィクスでは防止できないし。
0178デフォルトの名無しさんNGNG
173 です。

>177
>const　　　　　c
>refference 　　r
>argment　　　　　　　　　　Ag
>意識する必要は無いと思われ。

　const char * cpChAt
　char const * pchAt

の意味の違いを明示すべきと考えます。

参照については、pointer の p と同じです。参照引数のとき変数のスコープ
が関数の呼び出し側にまで及びます。参照引数の操作はオート変数以上に注意
を払うべきです。とくに const でないとき。

Arg, At については冗長との説については、半分は理解できます。Stt により
static 変数を明示するとき、他の変数は Stt の付け忘れではないことを明
示する意味が半分です。また temp のような変数名を付けるより chAt のよう
な変数名を使ったほうがましだと考えます。Stt や Glb を設けた結果、
Ag,At を追加したほうが良くなると考えています。
0179デフォルトの名無しさんNGNG
>>178
> const char * cpChAt
> char const * pchAt
どっちも同じじゃん。
> struct 　　　　st or St
> class　　　　　cl or Cl
これもC++では字面上の違いにしか過ぎない。

その割に、ポインタと配列を区別していないし、本質から外れた命名規約だと感じるがなぁ。
0180デフォルトの名無しさんNGNG
>>175
そういう意地悪言わないで教えてやれよ。









ていうか俺も聞きたいです。
0181デフォルトの名無しさんNGNG
これでどよ？
http://www.google.co.jp/search?q=fortran+%E5%A4%89%E6%95%B0+%E6%95%B4%E6%95%B0+%E6%96%87%E5%AD%97&ie=UTF-8&oe=UTF-8&hl=ja&lr=lang_ja
0182デフォルトの名無しさんNGNG
ここに書いてあることは真実ですか?
うそだといってほしい･･･
0183デフォルトの名無しさんNGNG
>>179
無知が語ってます
0184デフォルトの名無しさんNGNG
>>173
こういうコーディング時に手間をかければ、丁寧にやってるって
勘違いしてるやつ多いな。
0185デフォルトの名無しさんNGNG
>>173
中途半端はよくない
どうせならここまでやれ
foo.cpp:
void bar(int x)
{
const char *auto_const_char_ptr_func_void_bar_arg_int_x_file_foo_cpp = 0;
}
0186デフォルトの名無しさんNGNG
変数名にこだわってる時間があるなら、コメントをもっと書けと小一時間
0187デフォルトの名無しさんNGNG
>>186
コメントを書くより、名前でひとめでわかるほうが良い。
コメントは保守忘れても気づきにくいからな。
0188デフォルトの名無しさんNGNG
コメントつけろと言っても、「なぜそうする？」に答えるコメントを
残してくれるヤツなんてほとんどいないのな。

オウム返しのコメントは可か否か・・・これはけっこう微妙な問題。
0189デフォルトの名無しさんNGNG
>>188
理由や経緯、想定範囲などのコードに残ってない情報はコメントの価値高いね。
そうでない情報は極力コード自体を読みやすくすることで対応したいな。
0190デフォルトの名無しさんNGNG
>>179
>> const char * cpChAt
>> char const * pchAt
>どっちも同じじゃん。

違うぞ。

…と思ったが良く見たら同じだ。騙された。
違うのは
const char *　と
char * const　だな。
たのむぜ>>178
0191デフォルトの名無しさんNGNG
Writing Robust Java Code (v17.01d) の翻訳
ttp://www.alles.or.jp/~torutk/oojava/codingStandard/

参考になった。
0192177NGNG
>>178
>参照引数の操作はオート変数以上に注意
>を払うべきです。とくに const でないとき。

考え方が根本的に間違っとる。
引数が非const参照であることに注意を払うべきなのは、
関数を使う側だけであり、実装者が気にすることでは無い。

「変更するぞ」と言ってるのに、変更したらマズイものを渡され、
変更した責任を問われたらかなわん罠。
0193デフォルトの名無しさんNGNG
なるほど
0194デフォルトの名無しさんNGNG
179 さん、190 さん、173 です。const pointer は御指摘どうりです。馬鹿を書いてしまいました。

>179 ポインタと配列を区別していないし

これも御指摘どうりです。下の prefix を追加させてください

　　　　　　　　頭に付ける記号
　　array　　　ar/Ar
　　Union　　　un/Un
　　vector<.> vct/Vct
　　list<.> 　　lst/Lst
　　valarray<.> vlr/Vlr
　　map<.>　　　map/Map
　　set<.>　　　set/Set
　　string　　　str/Str
　　template 関数 tf
　　template class tc/Tc

>192 「変更するぞ」と言ってるのに、変更したらマズイものを渡され、変更した責任を問われたらかなわん罠。

御意。

本来ならば const refference 引数を渡すことで済ますべき。でも少し複雑な
クラスになると、奇麗事ですまなくなるのも事実。相手が保証してくれても、
現実に保証されるものでもない。
0195デフォルトの名無しさんNGNG
<html><!-- 2ch_X:cookie --><head><title>■ 書き込み確認 ■</title><META http-equiv
0196デフォルトの名無しさんNGNG
んが、変なもん書き込んじまった。
ｺﾞﾒｿ
0197デフォルトの名無しさんNGNG
> これも御指摘どうりです。下の prefix を追加させてください

却下。

> 本来ならば const refference 引数を渡すことで済ますべき。でも少し複雑な
> クラスになると、奇麗事ですまなくなるのも事実。相手が保証してくれても、
> 現実に保証されるものでもない。

それは、普通に間違ってるだけ。
プリフィックスとか、そんなのとは次元の違う問題。


型でプリフィックスつける人は、
template<typename T> void f( T x );
とかいう場合はどうするんだろう？
0198デフォルトの名無しさんNGNG
Javaのライブラリとかに汚染されてる人間に
型でプリフィックスとか言っても
死ぬまで理解出来ないと思う
0199デフォルトの名無しさんNGNG
>>197
その場合に限って言えばPrefixは必要ない。
いつつけているか人のソース見てみるといいと思う。
0200デフォルトの名無しさんNGNG
>>198 Java使いの私はサフィックス派です。
　Map actionMap = new HashMap();
ただし、メソッドが単純だったりして、変数の用途が自明の時は、
　Map map = new HashMap();
とかやってます。でも、
　Map actions = new HashMap();
とはあまり書きません。そして、
　Map mapActions = new HashMap();
なんていう奇怪な変数名は、たぶん一生書かないと思います。

キモイです。
0201デフォルトの名無しさんNGNG
> Map map = new HashMap();
> Map actions = new HashMap();

後者の方が情報が多くていいんじゃないですか？
前者はクドイと思います。
0202デフォルトの名無しさんNGNG
そんなお前らに新しい書き方を提案しよう。
Map a = new HashMap();
0203デフォルトの名無しさんNGNG
>>201
Javaの世界では>>200が正統派。
Map map = new HashMap();
これが正しい。
0204200NGNG
例外はプリミティブ型ですね。
致命的に型が重要な場合以外、型サフィックスは付けない。
　int rows = 0;
　String message = "Hoge";
それでも、英語の意味から簡単に型を推測できる変数名を心がけています。
0205デフォルトの名無しさんNGNG
Javaって言うのは宗教ですから。
正しい書き方を常に心がけないと、人に見せられないソースになっちゃいます。
0206デフォルトの名無しさんNGNG
>>203
型だけの名前で、用途・目的は名前に入れないのか。キモイ・・
0207デフォルトの名無しさんNGNG
>>206
それが受け入れられないなら、Java使う資格ないですね。
0208デフォルトの名無しさんNGNG
Mapが2個も3個もあったら、map2, map3 ？
0209デフォルトの名無しさんNGNG
>>206
>>208
一画面程度のプライベートメソッドで
一個しか出てこないテンポラリ的な使い方のときにやるんだよ。
複数必要なシチュエーションで、その書き方はやらん。
0210デフォルトの名無しさんNGNG
(´-`).｡ｏＯ(ほんとに宗教だな… 傍にいなくて良かった)
0211デフォルトの名無しさんNGNG
>>210
10年後にはJava以外の言語はほとんど使われなくなっていますから、
いやでも入信していますよ。
0212デフォルトの名無しさんNGNG
>>211
オウムがハルマゲドンを唱えて入信を誘ってるみたいだな。ｗ
0213デフォルトの名無しさんNGNG
>>203
Sun の奴にはそんな事は書いてないけどね。

> Map map = new HashMap();
は int i; とか char c; とかと同レベルで
一時的な変数なら許されるって程度で
推奨される書き方では無いと思われ。
0214デフォルトの名無しさんNGNG
>>213
もう一度読み直せ。
0215デフォルトの名無しさんNGNG
>>214
ほれ。

Code Conventions for the JavaTM Programming Language
http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html

9 - Naming Conventions 内の Variables
http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html#15436
0216デフォルトの名無しさんNGNG
>>215
javaのソース見てみ。
0217デフォルトの名無しさんNGNG
>>216
Map map ってのはローカル変数とかには良く使われてるけど、
インスタンス変数とかクラス変数にはあんまり使われて無いぞ。
0218デフォルトの名無しさんNGNG
>>217
ログ嫁。
0219デフォルトの名無しさんNGNG
>>218
Map map は正しいけど Map actions が間違っている
って部分はウソだろって話なんだけど。

J2SE のコアクラスライブラリにだって
Sunのコード規約を守ってない箇所なんかいっぱいあるし、
J2SE のコアクラスライブラリで使ってないからといって
即座に間違いというのも短絡的だと思うぞ。
0220デフォルトの名無しさんNGNG
Map mapを使うのはmapが一つしかない場合のみ（コメントつけるけど）で、
２つ以上だったら
Map hitMap; // 当たり判定用
Map baseMap; // 地形表示用
とかつけて、何に使うのか分かるようにするのが普通のJava使いだと思う。
0221デフォルトの名無しさんNGNG
>>220
Map が一つしかない場合に Map actions は正統派でない、正しくない、
ってな風に >>203 が書いてるんだよ。

int i は良いけど int val はダメって言ってるのに近いように見えるんだが。
0222デフォルトの名無しさんNGNG
>>221
ログ嫁。
0223デフォルトの名無しさんNGNG
int j
0224デフォルトの名無しさんNGNG
LotLot（昔のゲーム）とかライクライク（ゼルダ）の話か？
0225デフォルトの名無しさんNGNG
>>215
そんなもん、もうメンテナンスもされてないしSunじゃ誰も使ってないぞ。
0226デフォルトの名無しさんNGNG
最近ケリをつけた。
長年悩んできた

「引数のエラーチェックを外でやるか中でやるか」

と言う問題に。
俺的な結論は「中でやる」ということになった。
理由は、その関数を１０００箇所以上で使っていたときに
外でチェックをかけるとすると１０００箇所でチェックをしなければならない。
ということに今更気が付いたからｗ（おせーよｗ）

さらにこれと同じような問題で、戻り値でエラーコードを返すってのも、
個人的には没にしたくなってきた。
失敗する可能性のある関数の戻り値はすべてboolでやってtrueかfalseのみを
返すようにしてエラー後の詳細な処理はできるだけ関数の中でケリをつけるようにする。
ってのがいいと思えてきた。
外にエラー内容を伝える必要があるときはもっと別の方法でやるべきだと思っては
いるんだが、いい方法が思いつかないのが現状だったりするｗ
ちなみに現行ではトラブったとき関数を用意しておいて、
戻り値にfalseが返ったらトラブったとき関数を読ぶと直前のエラー内容を取得できるような作りにしてある。（へぼっｗ）
0227デフォルトの名無しさんNGNG
>>226
エラーコードの代替はC++/Javaとかの例外が使えるんじゃないの？
0228デフォルトの名無しさんNGNG
throw new IllegalArgumentException("腐った引数渡すな");
throw std::runtime_exception("アフォか？");
0229デフォルトの名無しさんNGNG
>>227
ところがＣ言語あがりのＣ＋＋プログラマなので
例外処理なんてどうやって使ったらいいのかってところの前の
存在から知らんのですよｗ
0230デフォルトの名無しさんNGNG
>>229
その食わず嫌い、5年前の俺を見てるようだな。
226みたいな悩みは例外使えばきれいに解決できるんだが。
0231デフォルトの名無しさんNGNG
>>226
関数の引数としてエラー処理関数を渡す
0232デフォルトの名無しさんNGNG
>>230
具体的に何を使えばいいですか？

>>231
よくわからないです。
0233デフォルトの名無しさんNGNG
>>232
自分で例外クラス作って、例外投げる時はthrow、例外を受け取って
エラー処理する時はtry～catch、だけだけど。イメージ沸かないなら
C++で書かれてるソース拾ってきて眺めてれば大体分かるでしょ。
0234デフォルトの名無しさんNGNG
>>233
ところがこれがまたわからないんですよ。
ネスト多くなって見難くくなるのでtryとか嫌いなんですよ。
例外を飛ばすってのもまたわからないですね。
エラーが出たら出たところでチェックするのが一番ですよね。
そんな長い関数なんて書きませんし。
0235デフォルトの名無しさんNGNG
>>234
>ネスト多くなって見難くなるので

まとめられる/まとめるべき try-catch を全部バラバラに書いてないか？
まあそうでないにしろお前にはセンスがなさそうだ。
0236デフォルトの名無しさんNGNG
>>234

errno = ～;
return false;
が
throw new ～Exception();
ですむということではなかろうか

ret = func1();
if ( ! ret ) { // エラー1 }
ret = func2();
if ( ! ret ) { // エラー2 }
が
try {
　func1();
　func2();
} catch ( ～Exception1 e ) {
　// エラー1
} catch ( ～Exception2 e ) {
　// エラー2
}
となるということではなかろうか
0237デフォルトの名無しさんNGNG
>>234

errno = ～;
return false;
が
throw new ～Exception();
ですむということではなかろうか

ret = func1();
if ( ! ret ) { // エラー1 }
ret = func2();
if ( ! ret ) { // エラー2 }
が
try {
　func1();
　func2();
} catch ( ～Exception1 e ) {
　// エラー1
} catch ( ～Exception2 e ) {
　// エラー2
}
となるということではなかろうか
0238236NGNG
try 節の方がいいというのは，
正常時の処理である
func1();
func2();
func3();
という流れがそのまま書けるということ

もし，各関数の直後にエラー処理の分岐があると，この流れが断ち切られて可読性が大幅に下がる
try {
　func1();
　func2();
　func3();
} catch～
と
ret = func1();
if ( ! ret ) { // エラー1 }
ret = func2();
if ( ! ret ) { // エラー2 }
ret = func3();
if ( ! ret ) { // エラー3 }
で正常時の処理の流れが分かりやすいコードはどちらか？
0239デフォルトの名無しさんNGNG
例外処理の最良の実例はデータベース操作だな。
try {
　selectFoo();
　selectBar();
　updateHoge();
　commit();
} catch (SQLException e) {
　rollback(); 　log(e);
}
例外に慣れたら他の書き方など考えられんよ。
0240デフォルトの名無しさんNGNG
>238
>if ( ! ret ) { // エラー1 }
俺なら逆だな
んで、

if((ret = func1())!=0){ // エラー1 }
if((ret = func2())!=0){ // エラー2 }
if((ret = func3())!=0){ // エラー3 }

で正常時の処理の流れが分かりやすい
0241（〃▽〃）＜ヒミコミコミコヒミコミコ♪NGNG
>>240
boolean expressionにfunction入れるのは読みづらいのだ。
0242デフォルトの名無しさんNGNG
garbage in, garbage out

事前条件を満たすのは呼び出し側の責務。
0243デフォルトの名無しさんNGNG
>>240
肝心のエラー処理部分がコメントになって１行で書けているから読みやすいだけで
普通は複数行のエラー処理になるはず
それに１つの関数から発生するエラーが１種類だけとは限らない

すると１つの関数呼び出しが無駄に間延びして読みにくくなる
0244デフォルトの名無しさんNGNG
>>243
> すると１つの関数呼び出しが無駄に間延びして読みにくくなる
じゃあ読みにくくならないようにするにはどうしたらいいの？
0245デフォルトの名無しさんNGNG
エラーライブラリがあったらなぁ　と思う。<error.h>や、errorモジュール。

全てのエラーをVBでいうならば、Goto Err_xxxxx のようになにがしかの
エラーが出たらエラーダイアログを出す行へ飛び、エラーを表示。

そのエラー表示も訳のわからない内容ではなくてエラーモジュールやら
error.hのようなものから呼び出し、表示する。

errorモジュールが読み出す元はIMEやATOKのように辞書を用意しそこ
から紡ぎ出すようにする。
であるから、辞書の内容をそれぞれの分野やアプリに付属したり、その
辞書を公開したりすることでより辞書は充実してゆく。

そんなエラーをモジュールを各コンパイラ向けにオープンソースモデル
で出ないかなぁ。辞書なのだから独自のライブラリやocxを流用したアプ
リ向けに作り込んでゆく。
0246デフォルトの名無しさんNGNG
>>244
今までの話の流れで行くと
例外処理機構を使って正常時の処理と異常時の処理を別々に書く
0247デフォルトの名無しさんNGNG
>>246
例外使わずにコンパクトに書ける方法はないの？
0248デフォルトの名無しさんNGNG
>>247
それがないから例外が発明されたんじゃないかのう
0249デフォルトの名無しさんNGNG
この板はたまーにいい感じのおっさんが出て来るんだよなぁ･･･
厨も出てくるけど･･･
0250デフォルトの名無しさんNGNG
>>248
あんまり役に立ってねぇよな＞例外
try～catchを使って飛ばすほど長い処理ってかかねぇし、
やっぱりエラーはその都度その場で処理したほうが
複雑にはならない。
0251デフォルトの名無しさんNGNG
>>250
役に立ってますよ。
処理の長さは関係ないですし、
エラーを「検出したその場」で処理するのは「不可能」なケースのほうが多いです。
エラー処理がexitだけなら可能かもしれないですが。
0252デフォルトの名無しさんNGNG
>>251
>エラーを「検出したその場」で処理するのは「不可能」なケースのほうが多いです。
多くねー。
0253デフォルトの名無しさんNGNG
非例外ベースでのエラー処理の問題は

・下位で発生したエラーを上位に伝達するのがﾏﾝﾄﾞｸｾ(ステータスだけ
　なら戻り値でいいが、詳細なエラー情報を返すシンプルな方法は無い)

・かと言って下位でエラー検出したその都度ダイアログ表示とかやって
　しまうと、後でエラー処理方法を変更したい場合に困る(こっちから呼んだ
　時はダイアログ表示しないでログに吐くだけにしてくれとか)。

・エラーが発生しても、それをどう扱うかは上位次第(ファイルがオープン
　できなくても別の方法で処理続行するようなケースもあるし、その場合
　ダイアログ表示なんてして欲しくない)。下位側でエラー処理方法が決め
　打ちされてるのは、上位側から見ると汎用性が薄くて使いにくい。

・呼び出しがネストしてる時に、一気に最上位まで戻れない(ステータス
　返して1段1段戻って行くしかない)

辺りで、こういうのは例外使えば解決できる。
(というか例外が無ければすっきりとは行かない)
0254デフォルトの名無しさんNGNG
>>253
これ例外（ここではtry～catchってことで話すけど）使った程度じゃ解決しねぇよ。
0255デフォルトの名無しさんNGNG
>>254
例えばどんなケースがある？
0256デフォルトの名無しさんNGNG
>>255
どんなケースがあるとかじゃなくて
例外使ったからってどうなるものでもないでしょう。
0257デフォルトの名無しさんNGNG
>>256
254のように言い切るって事は「例外使ってもどうにもならなかった」という
ケースがあったんだろ？ならそれを書いてみてくれ、と言ってるんだが。
0258デフォルトの名無しさんNGNG
>>257
つか俺が例外使うとことごとく上手くいかないｗ
ネストネストネストネストになるか。
try～catchばかり増えて非常に見難い感じ。
0259デフォルトの名無しさんNGNG
>>258
それは例外の使い方がいまいち、というか戻り値ベースのエラー処理の
やり方を単純にtry～catchに書き直しただけで、例外処理機構の「おいしい」
所を使ってない状態だと思う。

例外の使いどころが分かってないとそう書いてしまいがちだし、それだと
「なんだよ糞面倒くせえ。これなら戻り値チェックした方がマシじゃねーか」
と思うだろうね。かつては俺もそう思ってたし。

例えばだけど、続行不可能な致命的エラーと続行可能なエラーに2分して、
最上位では致命的エラーのtry～catchをまとめて引き受け、下位側では
続行可能なエラーのみをtry～catchする、みたいにすれば、致命的エラー
をいちいち捕まえてその都度エラー表示する、みたいなコードは書かなくて
済むはず。

リソース解放が絡んでcatchせざるを得ない場合でも、リソース解放したら
そのまま上位にthrowしちまえばいいし、C++だったらauto_ptr使ったりクラス
化してデストラクタで自動解放させるようにすると、下位側は全くcatchしな
くて済む事もあるので、そこまで来るとすんげー楽できる。
0260デフォルトの名無しさんNGNG
ただ、
いちいち例外クラスをつくらにゃならん、例外仕様は使えねぇ。
ってのがなぁ。
0261デフォルトの名無しさんNGNG
例外処理についての分かりやすい例題が載ってるページを教えてくれるか、
例題を作って解説してくれるｴﾛｲ人ｷﾎﾞﾝ。

と思ったけど、ここで大体理解できたからいいや。
ttp://msugai.fc2web.com/java/error.html
0262デフォルトの名無しさんNGNG
>>258
例外は catch しない限りどんどん上位の階層の関数呼び出しに伝達する
ってことは理解しているよね？
0263デフォルトの名無しさんNGNG
>>258

>253はまさに「例外処理を使えばこんなに便利」なことを示すための
「うまくいく」例なんだが、、、

失敗した具体例を示してくれれば
「こうすればスマートにできたのに」て
解決策を見せてあげられる可能性が高いんだけど。
0264デフォルトの名無しさんNGNG
>>258
つーかメソッド宣言の後ろにつけるthrows(sついてる)を
知らないんじゃ、、、、
0265デフォルトの名無しさんNGNG
for 使うとき　i, j　をよく使うのはなぜ？
0266デフォルトの名無しさんNGNG
ほーとらんで暗黙の整数型だったから。ダイクストラの名前から、という説もあり。
0267デフォルトの名無しさんNGNG
Algolでもi,j,kを使ってたな。
0268デフォルトの名無しさんNGNG
>266
＞ダイクストラの名前から、という説もあり
そんな説聞いた事ないぞ。
0269デフォルトの名無しさんNGNG
>>268
> そんな説聞いた事ないぞ。
知らないの？結構有名なジョークなのにｗ
0270デフォルトの名無しさんNGNG
Dr. Edsger Wybe Dijkstra
ttp://www.cs.utexas.edu/users/UTCS/notices/dijkstra/ewdobit.html

i, j, k の次は s か？
0271デフォルトの名無しさんNGNG
>>242
呼び出し側を書くのがお前みたいな厨じゃないと保証されるなら、俺も同意するよ。
0272デフォルトの名無しさんNGNG
>>247
continuation.
ttp://www.sra.co.jp/people/aoki/SmalltalkTextbookJ/textbook27.html
0273デフォルトの名無しさんNGNG
int i,j,k,l,n,m,a,b,c,d,val,val2;
double f,d;
0274デフォルトの名無しさんNGNG
>>265
どっかのスレでかいてあったぞ。
Fortran以来の古い慣習だ。
ネットでFortranの文法ググってみ。
0275デフォルトの名無しさんNGNG
>>265
最古の高級言語フォートランから続く慣習

フォートランはまた数学表記の慣習からきている。
行列やベクトルの要素をあらわすときＡi Ａij　とか高校の教科書に
あったろ？
(ijは下付文字で）
0276デフォルトの名無しさんNGNG
何年か前に1関数1ファイル、関数名とファイル名はXXX999みたいな管理番号
つーのをやらされた。みんなヤッテランネーつーことで
1プロセス1関数1ファイルなんつーのが数百も、、、
発注元に抗議してもウチの会社のナンタラカンタラ
クライアントとのナンタラカンタラ
規約決めたやつは早々にブッ倒れて入院しちゃうし、
代わりに来たヤツはなんで関数が番号なんだとか1関数がこんな長いんだとか
テメーんトコで飼ってるヴァカのせいだっつーの。
ＦＦ○潰れろ。潰れちまえ。
0277デフォルトの名無しさんNGNG
>>276
管理するソフトがあれば悪くないかもしれんぞそれ
0278デフォルトの名無しさんNGNG
基幹系で働いてたことあったけど、関数（というかプロセスごとのプログラム）は
全部XXX9999X形式だったな。3桁が使用箇所の識別で9999が管理コード、Xが
コンソールかオンラインかの識別子。

もっとも、何が何を表すか知らないとサッパリだけどな。仕様書の検索は楽だけど。
0279デフォルトの名無しさんNGNG
>>278
関数やモジュール名にコード番号をつけるのは
手書きドキュメントに索引つけて更新管理する手間を
省くための知恵。

PDFとかワードとかjavadocのHTMLとか検索可能な
電子テキストが標準となった今では無用の長物だな。

コードや番号のみってのは論外。
0280265NGNG
50へぇ

みなさん詳しいというか、雑学強いですね。
どこで身に付けるのやら。

int i　じゃないと気分悪かったりするので不思議です。
0281デフォルトの名無しさんNGNG
>>265
お前が物知らずなだけだ
0282デフォルトの名無しさんNGNG
>279
ワードは勘弁しろ
HTMLも自動生成は楽だが手では弄りづらい
PDFはもっての外

・・・何がいいんだろう。プレーンテキスト?
0283デフォルトの名無しさんNGNG
普通にコード書いて、納品するときに置換すりゃいいじゃん。
脳みそ無いの？
0284デフォルトの名無しさんNGNG
確かに、どうせ「納品したソース」は誰も見ないわな（ｗ

ただ、全ての現場でそういう事ができるとは限らないが。
(アフォな上司とかアフォな品質管理Ｇとかがゴリ押ししてきたり)
2～3人でやる小さなプロジェクトまでだったらどうにでもなるけどねぇ。
0285デフォルトの名無しさんNGNG
>>284
あ、脳みそないみたいね、君。
0286デフォルトの名無しさんNGNG
>279
お願いだから EXCEL をドキュメントに使うのは止めてくれ
0287デフォルトの名無しさんNGNG
プロセスが数百って、すごいでかいシステムだな。
0288デフォルトの名無しさんNGNG
でかいはでかいけど、すごくでかいってほどでもない。
0289rNGNG
>>283
１プロセス分のコードを一つの関数にまとめたりするような置換用の
スクリプト？とか、書くの大変だと思う。
置換したら、また最初っから試験しなきゃだしね。

0290デフォルトの名無しさんNGNG
>>287
実行プロセスが数百個並んで走ってるシステムを想定してませんか？

ぶっちゃけありえない。
0291デフォルトの名無しさんNGNG
お前が知らんだけ。
0292rNGNG
#define HOGE bool a = true
#define HUGA a = a &&
#define HAGE if( ! a )
としておいて、
int foo() {
HOGE;
HUGA func1() == 0;
HUGA func2() == 0;
HUGA func3();
HAGE errorHandle();
}
としてはどうだろうか。
0293デフォルトの名無しさんNGNG
>>290
俺はあんまり多分野やらんけど、車屋の工場管制なんかは
余裕で数百走るよ？
0294デフォルトの名無しさんNGNG
まぁ数百起動してても、全てが一斉に動くわけじゃないっしょ。
リクエストがあってからプロセス起こすとオーバーヘッドでかいから
とりあえず上げるだけ上げとくみたいな。

数百のプロセスが(プロセス間の)同期も取らずに一斉に動いたら
流石にまともには動かん。
0295デフォルトの名無しさんNGNG
子プロセスも勘定に入れてるのか
0296デフォルトの名無しさんNGNG
>>295
子プロセスはプロセスではない？
0297デフォルトの名無しさんNGNG
>>295
Unix とかなら、みんな init の子孫だと思うが。
0298デフォルトの名無しさんNGNG

新人PGだが仕事でVBやってんだけど、プロシージャの
前にコメント付けてくれという要望が来た。関数名とソース
を読めばだいたい分かるように書いてたんだけど、
それじゃ不満なんかな。無論分かりにくいと判断した
部分にはきちんとコメントを入れている。

プロなんだから、cmdSearch_Click が何を意味しているか
くらい分かるだろうと思うんだが。ただでさえ3次請けで開発
期間が短いんだから時間がもったいない。残業はサービスだし。

0299デフォルトの名無しさんNGNG
> cmdSearch_Click

わからん。
0300デフォルトの名無しさんNGNG
>>298
そういう奴は「プロではない」から仕方ない。
0301デフォルトの名無しさんNGNG
cmd がコマンドで
Search がサーチで
Click がクリックなのは推測できるが
それの関連については cmdSearch_Click だけでは

さ っ ぱ り わ か り ま せ ん
0302デフォルトの名無しさんNGNG
>>301
VBやってる人？
0303デフォルトの名無しさんNGNG
cmdSearch_Clickじゃ「ナニをされたとき」かは分かっても
「ナニをするか」は分からんもんな。
そもそもその検索ボタンを押すと何を検索するのかすら
どこにも書いてないんじゃない？
0304デフォルトの名無しさんNGNG
コマンドをサーチしてクリックする関数なんだろう。（なげやり）
0305デフォルトの名無しさんNGNG
クリックするサーチして関数コマンドをなんだろう。（やげりな）
0306デフォルトの名無しさんNGNG
サーチする関数をコマンドでクリックするんだろう。(やりなげ)
0307デフォルトの名無しさんNGNG
プロはコメント書くよ。






……馬鹿にでも分かるように。
0308デフォルトの名無しさんNGNG
>>307
馬鹿にでもわかるコメントなんか書けるんか ?

未来の自分にわかればそれで充分だろ。
0309デフォルトの名無しさんNGNG
未来の自分のためってのは正論だな。FA。
0310デフォルトの名無しさんNGNG
>>308
いや、馬鹿にでも分かるようにコメントを書いておかないと
未来の自分にも分からなくなっている可能性大。
0311デフォルトの名無しさんNGNG
３ヶ月前の自分は他人だからなぁ
0312デフォルトの名無しさんNGNG
ぶっちゃけ、俺が馬鹿なので、馬鹿でも分かるように書きます。
0313rNGNG
結局cmdSearch_Clickって関数は、何をする事になったのん？
0314デフォルトの名無しさんNGNG
>>313
>>304-306
0315デフォルトの名無しさんNGNG
俺は馬鹿に分からせるほど立派なコメントは書けないけど
保守担が関数の実装コードを読まなくて済む程度にはコメントしてるつもりだよ。
正直、コード読んでくれってのは最終手段だよな。
0316デフォルトの名無しさんNGNG
やふ
0317デフォルトの名無しさんNGNG
>>315
> 正直、コード読んでくれってのは最終手段だよな。

反対だろ ?
コードではちょっと伝えきらないところをコメントで補うんじゃないのか ?
0318デフォルトの名無しさんNGNG
どっちでもいいんじゃない？
コード自体をコメントとみなせば。
0319デフォルトの名無しさんNGNG
コメントを書かずに済むのなら、それに越したことはない。
コメントはコードの繰り返しであり、極力避けるべきであるから。
0320デフォルトの名無しさんNGNG
>コメントはコードの繰り返し

ダウト。そんなコメントは存在する意味がない
0321デフォルトの名無しさんNGNG
>>320
> そんなコメントは存在する意味がない

ダウト。存在が｢有害｣である。

修正する時、余計な手間がかかるからな。
0322デフォルトの名無しさんNGNG
>>315
return FALSE /* 戻り値 異常 */

とかやってそうで嫌
0323デフォルトの名無しさんNGNG
> コードではちょっと伝えきらないところをコメントで補うんじゃないのか ?
そういう場合はコメントが不要なようにコードを書き直すべきでないかい？

> コメントはコードの繰り返しであり、極力避けるべきであるから。
これはコメントの仕方が悪いだけでないかい？
「コードの繰り返しとなるようなコメントは避けるべき」であって
「コメントがコードの繰り返し」であるわけじゃない。

で、俺は今 >>298 の言う「プロシージャの前のコメント」について話してるつもりなんだが、
ふつうプロシージャの前のコメントってのは他のプログラマとも共有している既に決定された仕様が書かれているわけで
他のプログラマはプロシージャが実装される前からコメントに書かれた仕様を読んでスタブを使っているわけだ。
だからもしコメントとコードが一致しなくなったら変更すべきは可能な限りコードの方であってコメントではないと思うんだが、
そこらへんどうよ。
0324デフォルトの名無しさんNGNG
>コメントとコードが一致しなくなったら変更すべきは可能な限りコードの方

ダウト。間違ってる方を直せ(w
0325315==323NGNG
> return FALSE /* 戻り値 異常 */
それ、コード読んでる。
コード読ませないってのは、関数の実装部を全く読ませないってこと。

/* 普段は読むのココだけ */
hogehoge()
{
/* ココは読まない */
}
0326デフォルトの名無しさんNGNG
> >コメントとコードが一致しなくなったら変更すべきは可能な限りコードの方
> ダウト。間違ってる方を直せ(w
サンクス。その通りだ。
でも希に「下位互換として前の版のバグもエミューレートしてくれ」って指示があることもあるので
あくまで一般的な優先順位を
　降ってきた仕様 > 共有しているコメント > 担当しているコード
と考えてるってコトで。
0327デフォルトの名無しさんNGNG
>>323
＞ふつうプロシージャの前のコメントってのは他のプログラマとも共有している
＞既に決定された仕様が書かれているわけで

この辺って普通、紙の書類あるじゃん。
それじゃダメなのかな？
0328デフォルトの名無しさんNGNG
>>326
> でも希に「下位互換として前の版のバグもエミューレートしてくれ」って指示があることもあるので

それは、｢前の版のバグ」が｢正しい仕様 (=今回のコードが間違っている)」となってるだけのこと。
0329319NGNG
ちょっと言い方がまずかった。

i = 1 // i に 1 を代入する
みたいなのが問題外なのはもちろんだが、
そうでないものでもコードのやっていることを要約してコメントとして表している以上、
コメントがコードの繰り返しであることにはかわりはない。

もちろん、複雑な処理には適切なコメントをつけたほうが理解に役立つが、
コメントをつけずに済むのならそれに越したことはないってことを言いたかった。
0330デフォルトの名無しさんNGNG
俺も言い方が悪かったかな。
そもそも実装部のコードは読ませないんだからコードにコメントなんて滅多に書かない。
コメント書くのは関数の説明と、何か異常があったところ。
「実装コードを読まなくて済む程度のコメント」ってのは、そういう意味。

「コメント＝コードの繰り返し」については、
イメージしてるコメントが微妙に違うような気がする。

// 関数 xxx は使うな。
// 無駄に思えるが関数 yyy の返値から自前で計算しなければならない。
// [BUGxxxxx.txt] より
// xxx 以前の古いドライバは関数 xxx に誤った値を返す。

// ここでは要求された x の値として y を利用しなければならない。
// [BUGxxxxx.txt] より
// 関数 xxx のバグのため x と y の値は逆になって返ってくる。
// このバグは現在も互換性のために残されている。

みたいのはコードからは読みとりづらいし
コメント書いとかないとだれかが間違いだと思って直しちゃうぞ。
0331デフォルトの名無しさんNGNG
/**
　* お菓子を置いて帰っても良い。小人さんは喜んで、またやって来るだろう。
　* お菓子以外を置いて帰ってはいけない。小人さんは怒って、あなたのもとを去るだろう。
　* 　　　　　　　　　　　　　　　　　　　　　　　民明書房「ブラウニー伝承における嘘と真実」
　*/
0332デフォルトの名無しさんNGNG
>コメント書いとかないとだれかが間違いだと思って直しちゃうぞ

つーか直せよ(w
0333デフォルトの名無しさんNGNG
>つーか直せよ(w
直すなよ(w
0334デフォルトの名無しさんNGNG
>コードのやっていることを要約してコメントとして表し
違う
やっていること(How)をコメントするだけなら意味が無いと言っている

なぜ(why)とか何の目的があって(what)を書け
0335デフォルトの名無しさんNGNG
>>334
そうそう。why/what書かない奴多いんだよね。
それこそがコメントとして一番書いておいて欲しいところなのに。
仕様書にちゃんと明記してあるならいいけど、why/whatコメント
書かない奴はまず仕様書にも書いてないし。

で、後を引き継いだ奴が「なんでこんな処理が必要なんだ？」と
悩んだり、新規で作った部分でその処理が抜けてて「以前対策
したじゃないか」なんて責められたりする。
そんなんどっかに書いといてくれなきゃ分からんがな…
0336デフォルトの名無しさんNGNG
どーでもいいけど、ダウトってなんか元ネタあんの？
doubtなら用法がおかしいと思うんだが。
0337デフォルトの名無しさんNGNG
知らねーけどトランプのダウトじゃないの？
相手が嘘をついてると思った時に「ダウト！（そいつは信じられないねぇ）」って叫ぶやつ。
0338「なぜ」と「何の目的」って一緒やろ。NGNG
>>336
> doubtなら用法がおかしいと思うんだが。

どうおかしいか書いてみてや。

つーか、そんなもん指摘する暇あったら「何の目的があって(what)を書け」の方を指摘した方がええんとちゃうか ?
0339デフォルトの名無しさんNGNG
なぜ: むしゃくしゃしてたから
何の目的で: 遊ぶ金を奪うため

バールのようなもので処理する関数。
0340デフォルトの名無しさんNGNG
慣例句で I doubt it. とか (There is) no doubt. とかは聞くけど
doubt一語で済ませるのは聞かん気がする。
トランプのダウトも、英語では"Bullshit"または"I doubt it"のようだ。
0341デフォルトの名無しさんNGNG
誰が広めたのか心当たりがあるような気がするが、
まあ、相手の言ってることにケチつけるときの掛け言葉みたいなもんだろ。深く考えないほうが吉。
0342デフォルトの名無しさんNGNG
とにかく気違いみたいに「ダウト」といきなり叫ぶやつってすぐ馬鹿だとわか
るんだから、結構便利な目印だよ。
0343デフォルトの名無しさんNGNG
>342 ダウト
0344デフォルトの名無しさんNGNG
昔のクイズ番組で、VTRを見て間違ったところを見つけたら「ダウト！」って
叫んでから間違いを指摘するってのがあったけど、それからな気がする…。

…もしかして年がばれる？
0345デフォルトの名無しさんNGNG
>>343 ダウト ダウト
0346デフォルトの名無しさんNGNG
なぁ？
俺等は「ダウト！」なんていわないで「まんこ！」って叫ぼうぜ。
0347デフォルトの名無しさんNGNG
>>346
「バカ！バカ！まんこ！！」
0348デフォルトの名無しさんNGNG
＞344
あれから10年ぐらいはたったかな？
いずれにしろそんなに年、逝ってるって訳じゃないな。
0349デフォルトの名無しさんNGNG
幼い頃、親戚のうちへ遊びに行ったときに「ざぶとん」というトランプゲームをよくやった。
中学生になった頃、それが一般には「ダウト」と呼ばれていることを知った。
0350デフォルトの名無しさんNGNG
>349
もしかして、お前みっちゃんか？
0351デフォルトの名無しさんNGNG
>344
あの頃のマイ○ル富岡は面白かった。
0352デフォルトの名無しさんNGNG
>>349
ハウスルール(地域差含む）でたまたま一緒になっただけじゃないの
九州だがざぶとんとダウトは違う
0353デフォルトの名無しさんNGNG
いつみまさたかだっけ？
0354デフォルトの名無しさんNGNG
てす
0355デフォルトの名無しさんNGNG
定数にはkをつける
ポインタにはpかな？
0356デフォルトの名無しさんNGNG
破壊的な時は ! をつける
述語には?
0357デフォルトの名無しさんNGNG
>>356
FORTHか？
0358デフォルトの名無しさんNGNG
Scheme ちゃうのん？
0359デフォルトの名無しさんNGNG
CommonLispだな
0360デフォルトの名無しさんNGNG
>>359
setf
0361デフォルトの名無しさんNGNG
>>323
＞そういう場合はコメントが不要なようにコードを書き直すべきでないかい？

それ大事。
'データチェック
'もしもデータが正しければ
If DataCheck(Data) = False Then

とか書かれると、 DataCheckの中を見ないと安心できない。どうしても
「正しいときにFalseなのか？」と思ってしまう。場合によりけりだからなおさら。
ここは
If IsValid(Data) Then

みたいに書いてもらえれば（これだとFalseの意味が逆転してるが）
コメントがいらなくなる。
よく考えるとコメントって、コンパイラがチェックしてくれないから
ある意味バグの温床というか可読性を下げかねない諸刃の剣なんだよな。

あと、いわゆる関数ヘッダなんかをコピペで量産することがあるけど
なぜか「'プロシージャ名: IsVarid」とか「戻り値: Boolean型」とか
おまえヘッダでコードの繰り返し書いてどうするよ、このフォーマット
考えた馬鹿はドイツだよ、っていうヘッダをよく見ませんか？
こういうコピペコメントは本人のコメント作成能力を量的に超えている
ことがあるから、そうなると簡単に放置によるコードとの食い違いが
起こるんだよな。
0362デフォルトの名無しさんNGNG
>>361
>If IsValid(Data) Then

'データチェック
のコメントぐらいは欲しいな。
DataCheck(Data)みたいな、わかりやすい関数名ならいいけど。
関数名だけで処理がわからない場合は、
結局、中をみないと安心できない。

関数ヘッダの無意味なコピペは同意だな。
時間が無くなって来ると、ヘッダの中身を直さなくなるから、
後から見たとき支離滅裂。

ただ、関数ヘッダ自体はラベルの機能もあるから、
あった方が助かるんだけど。
誤解を生むようなコメントなら無理して付けるより
削除してくれたほうがいいな。
0363デフォルトの名無しさんNGNG
>>362
If (this) is valid data then ～
ってそのまま
「(この)データが正しければ～」
だし、「データチェック」なんつうコメントは余計だと思う。
個人的にだが。
0364デフォルトの名無しさんNGNG
>>363
同感。どうしてもそこでコメントつけるなら、むしろIsValid(Data)の中で特
に何を検査するのか、どうしてそれを検査すればvalidだと言えるのかを書い
ておくやり方のほうが好き。
0365デフォルトの名無しさんNGNG
>364
それはIsValid()の定義の側にかくべきコメントだろ。
使う側でいちいちIsValidの中身書いていたら、チェック内容が変わった時に
使っている側全部変更してまわらなければいけなくなって大変だし、
昔のコメントが残っていたらそれはそれで害になる。
0366デフォルトの名無しさんNGNG
>>365
> それはIsValid()の定義の側にかくべきコメントだろ。
だから「どうしてもそこでコメントつけるなら」って書いてあるんだろ。
IsValid()が自分で編集できるファイル内にあるとは限らんし。
0367デフォルトの名無しさんNGNG
>366
自分で編集できないファイルっていうのはライブラリのことか？
それはライブラリリファレンスを用意するからソースへのコメントはいらないだろ。
0368デフォルトの名無しさんNGNG
>>367
ソースのコメントを原本として、ライブラリリファレンスを生成するメカニズムがあるのが理想だね
0369デフォルトの名無しさんNGNG
うちではjavadoc使っている。
納品用ドキュメントはソースと別にjavadocで作るので一粒で二度おいしいです。
0370362NGNG
>>363,364
ごめんな。漏れが頭悪いだけなのかもしれんが、
IsValidって名前で、エラーチェック関数だと推測はできないわ。
こんな頭悪い香具師もいるんだから、
'エラーチェック
のコメントは欲しい。
コーディング規約とかで、エラーチェック関数の名前を統一してるなら、
無くてもいいけど。

>>364の言うようなコメントも、漏れ的には書いてあるほうが嬉しい。
後からソースを修正するときに、情報は少しでも多いほうが助かる。
もちろん、無意味なコメントや、誤ったコメントは問題外だけど。
0371デフォルトの名無しさんNGNG
>>370
げげ
0372デフォルトの名無しさんNGNG
>>370
> IsValidって名前で、エラーチェック関数だと推測はできないわ。

お前が頭悪いだけ。間違いない。
0373デフォルトの名無しさんNGNG
IsValidだと値の有効・無効判定だと思う。
エラーとは思わない。エラーだったら素直にIsErrorにするだろうから。
0374デフォルトの名無しさんNGNG
無効ならエラーにする、という処理ならわかるけど。
0375デフォルトの名無しさんNGNG
>>373
もともと361ではデータチェックの話をしてるんだからIsValidで問題ない。
0376デフォルトの名無しさんNGNG
>>375
>>370で 'データチェック から 'エラーチェック に化けたのか…
0377デフォルトの名無しさんNGNG
>>370 の先走りか。

windowsの矩形無効化の　Invalid() なんてのは、無効化ではあるがエラーではない。
0378デフォルトの名無しさんNGNG
invalidate verb
invalid adjective
0379デフォルトの名無しさんNGNG
gnuコーディングスタイルのインデントと{ }の付け方が気持ち悪いんですが。

このスタイルに何か合理的な理由があるんですか？
0380デフォルトの名無しさんNGNG
いや、漏れもGNUのコーティングスタイルのうちインデントと{ }に関してははかなり病的だと思う…
別にGNUそのものをどうこうとは言わないが、アレだけはなんとかしろと言いたい。
どういった経緯でああなったのかは、確かに疑問ではあるな…
0381デフォルトの名無しさんNGNG
GNUライセンスにしたがっているコードかどうか
はっきり区別できるようするためとか。

もちろん冗談だけど。
0382デフォルトの名無しさんNGNG
GNU Coding Standardには「こう書くと見やすいYO!」と書いてあって
思わず天を仰いだな。
0383 ◆SweetH.1rE NGNG
Windows 2000 のコードも、Half Life 2 のコードも

if (...){
　...
}

とかじゃなくて、

if (...)
{
　...
}

らしいよ
0384デフォルトの名無しさんNGNG
その方が見やすい。という人間が権限を持っているため。おれもそう書かないと
ダメな体になってしまった。
インデントの高さとカッコの高さを合わせた方が間違い少ないと思うが。
0385補足NGNG
違う方式で慣れた人間が無理に使うと間違うだろうがね。
0386デフォルトの名無しさんNGNG
説得できないなら従うしかないな
0387デフォルトの名無しさんNGNG
俺としては括弧は下の書き方の方がわかりやすくてすき
0388デフォルトの名無しさんNGNG
統一スタイルを決めようとすると、結局は宗教論争みたいになるんだよね。
良いか悪いか、わかりやすいか否かに合理的な説明がつかないし。
つきつめると結局は慣れているか否かだし。

そういうときは、権威主義でK&Rにした。
権威のせいにすればみんな納得(w

JAVAならsunか ?
0389デフォルトの名無しさんNGNG
この程度のことなら
後でgrepして直せばいいと思うんだが...
0390デフォルトの名無しさんNGNG
「中括弧をコードブロックに使わない言語」を使えば解決w
Pythonなんか悩む余地無いぞ
0391デフォルトの名無しさんNGNG
C に限定すれば、だが
cb 通せば統一出来る程度のスタイルの違いは
問題にする時間が惜しい。
0392デフォルトの名無しさんNGNG
>>390
括弧の位置は悩まなくていいが、SPACEインデント派とHTABインデント派
の争いは避けられないような（ｗ
0393デフォルトの名無しさんNGNG
インデントいらないってやつはいないよな？　中カッコも高さ合わせた方が間違いにくいと思う。
0394デフォルトの名無しさんNGNG

if() {

}
と
if()
{

}

前者は、ifのブロックであることを強調し、
後者はブロックの対応性を強調する。

0395デフォルトの名無しさんNGNG
Ａ宗：
　if () {
　　...
　}

Ｂ宗：
　if ()
　{
　　...
　}

と置いてみるテスト

今までＡ宗だったけど、Windowsでしばらくやってみて、Win32の複雑なAPIだと
条件式が長くなりがちだから、Ｂ宗のほうがいいような気がしてきた今日この頃。

プログラミング言語C第２版、プログラミング言語C++第３版、Effective C++がＡ宗なので
こっちにあわせてたんだけど。
0396デフォルトの名無しさんNGNG
自分はAだな。
Bだと縦に間延びしてしまって、一画面に入るソースコードの量が少なくなる…
画面小さいんだよヽ(｀Д´)ノ

書籍系でAってのも実はそれが理由かもなー。
紙面無題に使いたくないだろうし。

でも条件式が長くなる場合はBで書くこともある。
0397デフォルトの名無しさんNGNG
ifのブロックであることを強調した上にブロックの対応性をも強調するC宗


if(){

     }
0398デフォルトの名無しさんNGNG
>>397
それ、本気でやったらGNUよりもキツイぞ(笑)
0399デフォルトの名無しさんNGNG
短いとき
if(){

}

長いとき
if(xxxxxxx
0400デフォルトの名無しさんNGNG
長いとき
if(xxxxx
　xxxxx
　xxxxx
){




}
0401デフォルトの名無しさんNGNG
長いとき・・・はない。
foo = xxxxx 　xxxxx　xxxxx ;
if( foo ){
}
と書くからね。
0402デフォルトの名無しさんNGNG
俺流
if (foo)
{
　xx
}
>>401のソフトの改造は嫌だ。
0403デフォルトの名無しさんNGNG
>>402
なんで？
0404デフォルトの名無しさんNGNG
基本的にFreeBSDのstyle(9)に従ってる。
>>395だとA宗だな。

>>396
昔の会社で「ステップ数稼げるからB！」とか言ってる奴がいた(;´Д｀)
0405デフォルトの名無しさんNGNG
if (foo) {

} else if(bar) {

} else {

}
0406デフォルトの名無しさんNGNG
if (foo)
{

}

/*
こめんと
*/

else if (bar)
{

}

/*
コメント
*/

else
{

}
0407デフォルトの名無しさんNGNG
#define ef if else

if(hoge){

}
ef(foo){


}
ef(bar){

}
0408デフォルトの名無しさんNGNG
#define ef else if
だろ
0409デフォルトの名無しさんNGNG
>>397
コロンブスの卵だな。そっちに転びたくなってきた。
0410デフォルトの名無しさんNGNG
>409
正気か?
条件式の長さによって、中括弧の位置が変わるんだぞ。

　if( hogemoge ==0 ){
　　if( foo==0 ){
　　　　　　　　　}
　　　　　　　　　　　　　}
　ｉｆ( bar!=0 ){
　　　　　　　　}

こんなソースあったら、漏れは燃えないゴミに出すね!
0411デフォルトの名無しさんNGNG
ソースって燃えないゴミだったのか。
ていうか、Ｃ宗はやっぱあれじゃん？ GNUの。
0412デフォルトの名無しさんNGNG
gnuコーディング規約はカスすぎ
0413デフォルトの名無しさんNGNG
敢えて言わなくてもカスって感じですかね。
0414デフォルトの名無しさんNGNG
しかし、敢えて言おう！カスであると！
0415デフォルトの名無しさんNGNG
>>412
どういう点がカスなのかな？
0416デフォルトの名無しさんNGNG
カスっつーか、読みづらいし書きづらいよな。
0417デフォルトの名無しさんNGNG
読みづらいのはともかく、書きづらいのが何とも。
整形すればいいだけというわけにはいかないし。
0418410NGNG
>411
どう見たって燃えない(萎える)ソースじゃないか。

しょーもない事だけ書き込むのは何なので、GNUスタイルの参考リンク。
ttp://www.sra.co.jp/wingnut/standards/standards-ja.html#SEC_Top

#漏れ的にはコレも燃えない
0419デフォルトの名無しさんNGNG
書き方なんて全部統一しちゃえばいいのにな
言語ごとの癖に合わせるのがいい加減面倒臭い
0420デフォルトの名無しさんNGNG
というわけで、parserには柔軟性を持たせないようにしましょう（ｗ
0421デフォルトの名無しさんNGNG
全員、コボラーになれと？
0422デフォルトの名無しさんNGNG
>421
全員SQLerになってもらいます。
0423デフォルトの名無しさんNGNG
↓の話、スレ違いにつき移転。
http://pc5.2ch.net/test/read.cgi/tech/1087209526/106-121
> 106 名前：デフォルトの名無しさん[] 投稿日：04/07/29 23:43
> ところで値を返す関数の名前は名詞にしたほうがいいと思うが、getってつける人が多いな。
> 式の途中にget（動詞）があると読んでてキモくない？
0424デフォルトの名無しさんNGNG
>>ttp://pc5.2ch.net/test/read.cgi/tech/1087209526/121
> だからプロパティという概念を軸に発想しろっての
プロパティという概念を軸に発想したからって、
読み取り操作に常にgetが現れるのは必然にはならないだろ。

> お前はあらゆるプロパティのsetterに適切な動詞が存在するとでも思ってるのか？
プロパティの設定についてはこの話と直接関係は無いが、
適切な動詞が存在するものはそっちを優先したほうが
抽象度が上がって良いような気がする。

> (set/get, 名詞/動詞のルールの)一貫性が損なわれているのは間違いないだろ。
一貫性が既にできあがってるところに一つ混ぜるって話じゃなくて、
一貫性を保つための妥協の是非について話をしたい。

> いつまでも馬鹿なこといってないでプロパティのある言語で10万行くらいコード書いてみろ。
プロパティのある言語なら、
値を取得する箇所にはプロパティ名（おそらく名詞）しか現れないので
こんな物議を醸すこともない。
0425デフォルトの名無しさんNGNG
JAVAにプロパティがつけば即解決
0426デフォルトの名無しさんNGNG
クラスを使わなければ即解決
0427デフォルトの名無しさんNGNG
object.size = xxx;
yyy = object.size;
0428デフォルトの名無しさんNGNG
class Hoge{
　private int pr_hensuu;
　int getHensuu(){return hensuu;}
　int hensuu(){return getHensuu();}
}

両方使えれば解決、、、、　じゃねーよな
0429デフォルトの名無しさんNGNG
age、そして愚痴。

もーね。今日も嫌だと話したんだが、CとかJavaとかシェルに対して、

「　１　～　８　０　桁　ま　で　に　コ　ー　デ　ィ　ン　グ　す　る　事　」

なんてな糞規約なんぞ設けるなって。いやマジで。

COBOLは言語仕様としてそう書かねばならない(フリー除く)から規約
にするまでもないのだが、CやJavaやシェルにまでそんな制限も設け
てたら、かえって読みにくいってば。

そのまんま書くとまずいんで、さらっと紹介するが、規約によって以下
を達成する事を目標としているそうな。この規約。

１：作成および保守の向上と信頼性
２：環境のリプレイスに耐えうる互換性

その割にはコンパイラに依存するような関数(ex.stricmp等)の利用を
禁ずるなどとは書いてない。
括弧は左右に１文字分のスペースを空けろと言うくせに、１行は80桁
までと規定する。そしてその弊害はネストにおよび、３ネスト以降は禁
止ｗ

制御文の括弧中に関数呼び出しを書くなとさ。たとえば、

if ( atoi ( getenv ( TODAY_DATE ) ) == 20040819 ) {
hoge ( ... );
}

は駄目だとさ。
0430429NGNG
極めつけは　「　コ　メ　ン　ト　は　４　０　カ　ラ　ム　か　ら　」　だとよ。

つまりだな。


if ( TodayDate == 20040819 ) {
/* DBから対象となるデータを読み込む */
hoge ( a , b , c , d , e , f , g , h );
}

は駄目で、

if ( TodayDate == 20040819 ) {
hoge ( a , b , c , d , e , f , g , h ); /* DBから対象となるデータを読み込む */
}

だとよ。こう書くと「変じゃねぇYO!」という香具師もいるかも知れないが、
コメントの開始位置が４０桁目という事は、如何にコーディングする範囲
が狭いか分かるだろう。
0431429NGNG
また「文中にはコメント入れちゃ駄目」ってんだから、要注意な引数の解
説なんかで

if ( TodayDate == 20040819 ) {
hoge ( a , /* あれ */
b , /* これ */
c , /* それ */
d /* どれ */
);
}

もやっちゃいかんとかいう。大コメント(俺はよく関数内の区切りとして書く
のだが)ソレも駄目ー。

そういうよく分からない誰かの美的センスとしか受け取れない脇で、プレ
フィックスなんかには一切触れないｗ

禿しくウザーですよ。

ｵﾚﾓﾅｰ
0432デフォルトの名無しさんNGNG
>制御文の括弧中に関数呼び出しを書くなとさ
これは確かに萎えるが、
>if ( atoi ( getenv ( TODAY_DATE ) ) == 20040819 ) {
ありえねー。
0433デフォルトの名無しさんNGNG
>極めつけは　「　コ　メ　ン　ト　は　４　０　カ　ラ　ム　か　ら　」　だとよ。

萎え。そんなこと言われたら二度とコメント書かないね

inline void ReadTargetDataFromDatabase ( DatabaseName, TargetData, ReadOption, ... ) {
hoge ( DatabaseName, TargetData, ReadOption, ... )
}

みたいなバカなラッパ関数作っちゃうよ？


>要注意な引数の解説なんかで

that_data_to_treat_data = a;
this_data_from_object = b;
it_data = c;
what_data = d;
hoge ( that_data_to_treat_data , this_data_from_object, it_data, what_data )

とかやっちゃえば？
0434デフォルトの名無しさんNGNG
>>433
大抵その手のあふぉ規約には、ローカル変数の命名規約とかあったり
するんだよな。

１関数１ファイルだとか、関数名＝ファイル名（８文字まで）だとか、
腐ったプロジェクトに放り込まれたら泣くしかない。。。
0435デフォルトの名無しさんNGNG
1関数1ファイルどころか
ヘッダにinclude書くなですよ。
コメントはアホドキュメントツールがフロー書けるように、コメントの形式ガチガチですよ。
関数の数がナゼか最初から決まってるから、重複コードテンコ盛りですよ。
仕様書のデータ定義は、なぜかCOBOL用語バシバシですよ。
デバッグアサーションは1行毎に1個記述ですよ。

誰かCわかるマネージャ呼んで来いや！

…なんでこのPJにいるんだ、俺はorz
0436デフォルトの名無しさんNGNG
> ヘッダにinclude書くなですよ。

ど，どーやってコード書けばいいのですか(　・ω・)ﾓﾆｭ?
漏れには想像がつきませんです・・・
0437デフォルトの名無しさんNGNG
> ヘッダにinclude書くなですよ。
別に愚痴を垂れるほど酷い規約とは思わないが…
ヘッダにincludeを書くのは、極力避けるべきだし。
（例外はプリコンパイルの効果を狙う時）

その他は激しく同情。

>436
例えば hoge.h の中に moge.h を書かなくても、
hoge.h を includeする時は、必ず先に moge.h を include するようにすれば良い。
0438デフォルトの名無しさんNGNG
> hoge.h を includeする時は、必ず先に moge.h を include するようにすれば良い。

コーディングは可能だが、断じて良くない。
0439デフォルトの名無しさんNGNG
ヘッダに書くincludeは、ヘッダ内で使用している構造体等の必要に応じて書く。
本体に書くincludeは、本体で使用している関数等の必要に応じて書く。
勿論、2重読込み防止策は必ずやっておく。
極力書くなってのは、そういう事だ。

ヘッダに本体で使うincludeを延々と書いたり
本体にヘッダのinclude順序を気にしながら延々と書いたり
なんてアホ行為は、下衆以外の何者でもない。

基本の基本なハズなんだが…orz
ちなみに、C++だったらもっとキレイにモジュールを独立化できるやね。
0440デフォルトの名無しさんNGNG
> ヘッダに書くincludeは、ヘッダ内で使用している構造体等の必要に応じて書く。
っていうのと

> hoge.h を includeする時は、必ず先に moge.h を include するようにすれば良い。
っていうのとは天と地くらいの差があるけどね(そりゃいくらなんでもおおげさだ!)。
後者は単品じゃコンパイルが通らないインクルードファイルを量産することになるわけで。

> ヘッダにincludeを書くのは、極力避けるべきだし。
> （例外はプリコンパイルの効果を狙う時）
だけから両者の違いを読み取れっつーほうが無理だろうな。
0441デフォルトの名無しさんNGNG
極力書くな、と、絶対書くな、は天と地ほどの違いがあります。
0442デフォルトの名無しさんNGNG
>>441
「ヘッダ内で使用している構造体等の必要に応じて書く」と「プリコンパイルの効果を狙う」
も天と地ほどの…
0443デフォルトの名無しさんNGNG
>>441-442
まとめると、「『ヘッダでインクルードするな』はうんこ」と言うことでよろしいか？
0444デフォルトの名無しさんNGNG
>439
>ヘッダに書くincludeは、ヘッダ内で使用している構造体等の必要に応じて書く。
（C++はともかく）Cでは余程のこと（極端に肥大化するとか）がない限り、
型定義と関数宣言の依存関係は1つのヘッダ内で収まると思うのだが。

C++は苦しいだろうが無理ではない。継承やinlineを避け、クラスメンバはポインタで持たせる等すれば
相互依存を避けられるし、そうすることのメリットもある。
（詳しくはEffectiveC++を見ると良い）
0445デフォルトの名無しさんNGNG
>>444
> （C++はともかく）Cでは余程のこと（極端に肥大化するとか）がない限り、
> 型定義と関数宣言の依存関係は1つのヘッダ内で収まると思うのだが。
たとえばさ、自分で作ったモジュールの中にFILE*を引数としてとる関数があ
るとそのモジュールのインターフェイス用のヘッダには"<stdio.h>"が必要に
なるでしょ。FILE*じゃなくても、time_t(time.h)とか、size_t(stddef.h)と
かも同様。もちろん自分で作ったデータ型を利用する場合は、そのモジュール
用のヘッダをインクルードすることになる。

ひとつのヘッダで収まるかどうか、というのは肥大化とかと関係ないんだよ。
0446デフォルトの名無しさんNGNG
>>445
どうでもいいけどtime_tやsize_tはともかく、FILE*はstruct FILE;の一行で済むだろ。
0447デフォルトの名無しさんNGNG
本気で言ってるのかな
0448デフォルトの名無しさんNGNG
>>446 は >>435 のマネージャー
0449デフォルトの名無しさんNGNG
>445
例えば FILE* を受け取る関数を作ったとして、その関数を使うソースでは stdio.h もincludeする必要があるのは自明。
（stdio.hをincludeせずに、どうやってその関数に渡すファイルを開くの?）
この場合、暗黙にincludeしてしまう方が気持ち悪いと思うのだが…
0450デフォルトの名無しさんNGNG
>>449
「このヘッダをインクルードするときは必ず先にstdio.hをインクルードしてください」ってか？
includeの順番なんて気にしたくねぇだろ。
0451デフォルトの名無しさんNGNG
.hに暗黙でincludeさていたとしても、
明示的にもう一度.c/.cc/.cppでincludeすればいいだけで。

でもまあ、
「単体でコンパイルできないヘッダがイヤ」つまり
「このヘッダをインクルードするときは先にstdio.hをインクルードする必要があるのがイヤ」
というだけの話なので、struct FILE;の先行宣言だけでちゃんと.h単体のコンパイルが通るなら
それはそれで別にいいと思うけど。

ま、この辺はレガシーなしがらみだよな。ヘッダが必要とかどうとかは。
事実Java/C#なんかはヘッダファイルという概念はないし、
こんなものはコンパイラがやるべき仕事だというのは確かだろうと思う。
0452デフォルトの名無しさんNGNG
> struct FILE;の先行宣言だけでちゃんと.h単体のコンパイルが通るなら
> それはそれで別にいいと思うけど。

いや、ダメだろ。
0453デフォルトの名無しさんNGNG
> struct FILE;の先行宣言だけでちゃんと.h単体のコンパイルが通るなら

通んないっしょ
0454デフォルトの名無しさんNGNG
VCでのFILEの定義を見てみよう

struct _iobuf {
char *_ptr;
int _cnt;
char *_base;
int _flag;
int _file;
int _charbuf;
int _bufsiz;
char *_tmpfname;
};
typedef struct _iobuf FILE;

ほら、これじゃstruct FILEとしても通らないっしょ
0455デフォルトの名無しさんNGNG
>450
includeの順番なんざ気にしたくない、という気持ちは分からんでもないが、
使いにくさとのトレードオフで手に入るメリットがあるのだよ。
>435のマネージャがそれを狙っているかは疑問だけど、あーいう風に愚痴るのはどうかと。
自分の勉強不足晒すようなモンだよ。

>454
ついでに標準Cライブラリのヘッダも見ておく事をお勧めする。
中でincludeしているヘッダはほとんど無いよ。
WinAPI とか C++のヘッダはincludeしまくりだけど…
あと記憶が定かじゃないが、準標準ライブラリでincludeの順番を指定してるのが
あった気もする。
0456デフォルトの名無しさんNGNG
>>455
>使いにくさとのトレードオフで手に入るメリットがあるのだよ。
さっさとメリットを言えよ。

>ついでに標準Cライブラリのヘッダも見ておく事をお勧めする。
>中でincludeしているヘッダはほとんど無いよ。
糞低能だな。

ほとんどない、だからなんだよボケ。
0457451NGNG
>>453-454
すまん。手元で確認したら確かにコンパイル通らなかった。
ためしもせずに言うものじゃないな。申し訳ない。

>>452
が、やっぱり「先行宣言だけでちゃんと.h単体のコンパイルが通るなら」
別に良いと思う。
いや、まあ、今回の場合はその仮定が成り立たなかったわけだが・・・
その点はすまんかった。
0458デフォルトの名無しさんNGNG
そうえいば、FILE型って別に構造体である必要が無かったような気がする。
0459デフォルトの名無しさんNGNG
>456
>メリット
・例えばあるヘッダに含まれる関数が不要になったため、関数と一緒にヘッダも削除した所、
　今まで正常にコンパイルが通っていた場所でコンパイルエラーが多発するようになった。
　…という経験は無いかい?
　まぁ賢い皆さんなら何故エラーが起きたかすぐ分かるだろうが、
　アフォPGはこれで何時間も悩んだりする。それを防止する。

・再コンパイル効率が上がる。（詳しい話はEffectiveC++とか見れ）
　ただ>437で書いてるような、ソースに追い出す手法では上がらんけど。

・ソースが依存しているヘッダが一目で分かる。
　ツール使えばいいだろ、というのはその通り。
　>435のマネージャが狙ってそーなのはこの辺。

>だからなんなんだ
Cではヘッダ内includeがほとんど必要ないという証明。
0460デフォルトの名無しさんNGNG
>>459
> 例えばあるヘッダに含まれる関数が不要になったため、関数と一緒にヘッダも削除した所、
> 今まで正常にコンパイルが通っていた場所でコンパイルエラーが多発するようになった。

例えばあるヘッダに含まれる関数が必要になったため、ヘッダのインクルードを追加したところ、
そのヘッダ内部でコンパイルエラーが多発するようになった。
目くそ鼻くそだな。

> 再コンパイル効率が上がる。（詳しい話はEffectiveC++とか見れ）

構造体の前方宣言で済ませる手法を使わないと変わらない。
それ以外のFILE*やsize_tなんかでは、結局インクルードする必要がある。

> ソースが依存しているヘッダが一目で分かる。
> ツール使えばいいだろ、というのはその通り。

依存関係を調べたければツールを使う必要がある。
ソースを一目見て依存するヘッダを全部分かった気になるのはアフォとしか思えん。

> Cではヘッダ内includeがほとんど必要ないという証明。

そんなのは証明と言わない。ただの例。
0461デフォルトの名無しさんNGNG
>>455
> ついでに標準Cライブラリのヘッダも見ておく事をお勧めする。
> 中でincludeしているヘッダはほとんど無いよ。
どういう意味？gccだと

complex.h:#include <features.h>
err.h:#include <stdarg.h>
errno.h:#include <bits/errno.h>
malloc.h:#include <features.h>
math.h:#include <bits/huge_val.h>
math.h:#include <bits/mathcalls.h>
math.h:#include <bits/mathdef.h>
math.h:#include <features.h>
setjmp.h:#include <bits/setjmp.h>
setjmp.h:#include <bits/sigset.h>
setjmp.h:#include <features.h>
signal.h:#include <bits/signum.h>
signal.h:#include <bits/sigset.h>
signal.h:#include <bits/types.h>
signal.h:#include <features.h>
stdint.h:#include <bits/wchar.h>
stdint.h:#include <bits/wordsize.h>
stdint.h:#include <features.h>
stdio.h:#include <bits/stdio_lim.h>
stdio.h:#include <bits/sys_errlist.h>
stdio.h:#include <libio.h>
stdlib.h:#include <features.h>
stdlib.h:#include <stddef.h>

いくらでもあるけど。
0462デフォルトの名無しさんNGNG
C++Builderの include 直下だけでも，2600以上ヒットするなw
こいつ，どのソース見ていってるんだ?
0463デフォルトの名無しさんNGNG
オロナミンC/C++かな。
0464デフォルトの名無しさんNGNG
あ，わかった
C(OBOL) だ
0465429NGNG
>>464
素晴らしいオチだｗ
0466元気はつらつ～。NGNG
>>463
オフコース !!
0467デフォルトの名無しさんNGNG
オロナミンC++を使いたいのですが，どこで買えるのでしょうか？
ご教示よろしくお願いします。 >> マネージャさん
0468デフォルトの名無しさんNGNG
>>467
大塚製薬 オロナミン C++ を発表
http://www.horobi.com/jokes/oronamin-C++.html
0469デフォルトの名無しさんNGNG
Turbo C の話題がでてないことが悲しいです…
0470デフォルトの名無しさんNGNG
>>468
ありがとうございます。これで今後ヘッダに #include 書かなくて
済みそうです。感謝です。
0471デフォルトの名無しさんNGNG
>>459 の降臨まだー？
0472デフォルトの名無しさんNGNG
age
0473459NGNG
471のリクエストに答えて再降臨ですよ。

>460
>そのヘッダ内部でコンパイルエラーが多発するようになった。

それってインクルードガードかけて無いだけでは?

>構造体の前方宣言で済ませる手法を使わないと変わらない。

ちゃんと>459で>437みたいなやり方じゃ駄目って書いたじゃん。
きちんと書かなかったのは漏れのミスだけど。

>そんなのは証明と言わない。ただの例。
そいつはうっかりしてた。すまんかった。

>461,462
「C標準ライブラリ」以外のヘッダが混じってますよと。
ちなみに漏れが見たのは、>454へのレスである事を考慮すれば分かると思うがVC++。
他のはノーチェックだった。その点はすまんかった。
0474デフォルトの名無しさんNGNG
>>473
> 「C標準ライブラリ」以外のヘッダが混じってますよと。
それがどうかしたの？
標準ライブラリのヘッダ内でインクルードしてるのは沢山あるわけで、
「中でincludeしているヘッダはほとんど無いよ」ってのが嘘であることに変わりはない。
0475デフォルトの名無しさんNGNG
>それってインクルードガードかけて無いだけでは?
文脈からinclude足りてないってぐらいは読めって、つっこまれるぞ。
0476デフォルトの名無しさんNGNG
>>473
混乱してきたんではっきりさせてくれ。

まず、ヘッダA内で使用しているものの宣言を含むヘッダBがある場合、
１．ヘッダA内でヘッダBをインクルードする
２．ヘッダAを使うソース側でヘッダBを先にインクルードさせる
というふたつの選択肢があるとして、２をコーディング規約にされた>>435がキレている、と。

>>450の「includeの順番なんて気にしたくねぇだろ」に対して、
>>455で「使いにくさとのトレードオフで手に入るメリットがある」と言って、
提示したメリットが>>459なんだから、
>>459は上のふたつのうち、２を選んだ場合のメリットなんだよな？
0477デフォルトの名無しさんNGNG
>>473
つまり
　includeの順番に気をつけさせることで手に入るメリットなんか無かった
ってことでいいのか？
そこをはっきり言ってくれ。

まだメリットがあると主張するなら、>>459を反省して
隙の無いレスでまとめてもらえるとありがたい。
0478デフォルトの名無しさんNGNG
期待age
0479デフォルトの名無しさんNGNG
　　　　∧＿∧
　　　 （　・∀・）　ﾜｸﾜｸ
　　oノ∧つ⊂）
　　(　（　・∀・）　ﾄﾞｷﾄﾞｷ
　　∪（　∪ ∪
　　 　と＿_）__）
0480デフォルトの名無しさんNGNG
遁走の予感・・・
0481459NGNG
>477
んじゃ次は…手抜きでコレ。
　ttp://lagendra.s.kanazawa-u.ac.jp/ogurisu/manuals/c/C-faq/C-faq-10.html#10.7
0482デフォルトの名無しさんNGNG
>>481
どう読んでみても，

>入れ子の#includeは止めたほうがいい

としか書いていないが。しかも，#includeをヘッダに書かないメリットなんか書いていない。

>ヘッダファイルをモジュールを組み上げるように使うことができる
>(使い手はいちいち#includeしてまわらなくてすむ。)
>grep(やタグファイルのようなツール)があれば、定義がどこにあるのか見つけるのを楽になる。

と，メリットしか書いていないが。
0483デフォルトの名無しさんNGNG
引用が足りなかった。

>有名なトリック
>#ifndef HEADER_FILE_NAME
>#define HEADER_FILE_NAME
>…ヘッダファイルの中身…
>#endif
>
>こうすれば何回#includeしても問題ない。

と，普段使っている方法を使えば問題ないとしか書かれていない。
メリットばかりじゃん。
0484デフォルトの名無しさんNGNG
>>481
あんた日本語読めないのか？
0485デフォルトの名無しさんNGNG
ｺﾎﾞﾗｰの予感
0486デフォルトの名無しさんNGNG
>> 例えばあるヘッダに含まれる関数が不要になったため、関数と一緒にヘッダも削除した所、
>> 今まで正常にコンパイルが通っていた場所でコンパイルエラーが多発するようになった。
> 例えばあるヘッダに含まれる関数が必要になったため、ヘッダのインクルードを追加したところ、
> そのヘッダ内部でコンパイルエラーが多発するようになった。
> 目くそ鼻くそだな。
目くそ鼻くそどころか悪化してると思うぞ。
見つからないヘッダを「このファイルが見つからないから開けない」って指摘してくれるツールは知ってるが、
へッダに手を加えず「お前はこのヘッダを include していない」って教えてくれるツールは見たこと無いぞ。
0487デフォルトの名無しさんNGNG
>>486
どっちの場合でも「このファイルが見つからないから開けない」とはならないだろ。
0488デフォルトの名無しさんNGNG
前者はなる
後者はならない
0489デフォルトの名無しさんNGNG
ああ、どっちもならないかも。

そもそも
> 例えばあるヘッダに含まれる関数が不要になったため、関数と一緒にヘッダも削除した所、
> 今まで正常にコンパイルが通っていた場所でコンパイルエラーが多発するようになった。
ってのがまず起きないな。
0490デフォルトの名無しさんNGNG
>>489
いや、起きるだろ。
0491459NGNG
>482
(入れ子にすると)makefileの保守が面倒になるって所とか。
逆に入れ子にしない事で、makefileの保守が容易になるという意味である事はわかるね?
分かりやすく例えると、grep一発で任意のヘッダに依存しているファイルの一覧を作成できるって事。

…もしかして「grepでできる」のメリットが理解できないとか?
0492デフォルトの名無しさんNGNG
>>491 ｷﾀｰ
> 分かりやすく例えると、grep一発で任意のヘッダに依存しているファイルの一覧を作成できるって事。
おい、Makefileの保守といきなり関係なくなってるぞ。
Makefileの保守にはもちろん gcc -M や makedepend などを使うわけで、ヘッダの入れ子は関係ないな。

しかし「grep一発で任意のヘッダに依存しているファイルの一覧を作成できる」というのは、
今までの中では一番「メリット」と言えるかも知れない。

ただ、その一覧が欲しくなること自体があまりなさそうなので
「grepでできる」のメリットが薄まってしまっていると思う。
総じて、「使いにくさとのトレードオフで手に入るメリット」としては受け入れ難い。
0493デフォルトの名無しさんNGNG
>>491
> (入れ子にすると)makefileの保守が面倒になるって所とか。
オイオイ、「とか」って言ってるが、これまでさんざん要求されてるにもかかわらず
いまだに他に何も利点が挙げられてないってわかってんのかよ。
そもそも手書きで「makefileの保守」なんて言ってること自体どうしようもないけど。

> 逆に入れ子にしない事で、makefileの保守が容易になるという意味である事はわかるね?
ちっちゃいmakefileを手で書いてる場合だけだね、「保守が容易になる」のは。

> 分かりやすく例えると、grep一発で
そんなのたとえになってないって。

どうも459はCがわからないだけじゃなく日本語も不自由なようだな。
0494459NGNG
>492
>Makefileの保守といきなり関係なくなってるぞ。
はい、間違えました。grep云々は、修正の影響範囲を調べる手法。
makefileの保守ならsedやawkでincludeを抜き出して、依存関係を生成、が例としては適切ですかね。
またご指摘の通り(>481でも示唆されてるが)今はより良いツールがあるんで、
散々言われてる通り大したメリットは無いのも認めます。

>493
>そもそも手書きで「makefileの保守」なんて言ってること自体どうしようもないけど。
ごめん、最近物忘れが酷いんだ。
どこで言ってたか教えてクレ。
0495デフォルトの名無しさんNGNG
モ(ﾟ∀ﾟ)━ウ( ﾟ∀)━( ゜)━( )━(` )━ダ(Д` )━メ(´Д`)━ポ(;´Д`)━━━!!!
0496デフォルトの名無しさんNGNG
お前らよくこんなつまらん議論を延々と続けられるな。
「includeの入れ子を避ける」と、例えばヘッダAを修正した結果、ヘッダBが必要になったら、
Aを使ってる全てのソースを修正しなきゃならんのだぞ?
少し考えりゃ、百害あって一利無しだと分かるだろ。
0497デフォルトの名無しさんNGNG
組み込みで、あるCPUボードでの開発をした時に
標準ヘッダを入れ子にしていたのだけど
再利用で、別の処理系で使ったところ
こちらの標準ヘッダでは一部のルーチンがライブラリになく
ユーザが作成することになっていたため
入れ子をやめるか、ダミーの関数を作成するか
の判断に迫られたことがあったように思います。
それ以来、入れ子はやめて、ヘッダのファイルヘッダにコメントで
「事前に、～を使用するため～のヘッダをincludeするように」などと
使用条件を書くようにしました。
0498デフォルトの名無しさんNGNG
組み込みで、32bitのCPUなのに、未だに lp　と付けてしまう漏れは orz
だって見やすいんだもん。。。。
0499デフォルトの名無しさんNGNG
>>497
> こちらの標準ヘッダでは一部のルーチンがライブラリになく
> ユーザが作成することになっていたため
その処理系がヘボなだけ。
0500デフォルトの名無しさんNGNG
> こちらの標準ヘッダでは一部のルーチンがライブラリになく
> ユーザが作成することになっていたため
> 入れ子をやめるか、ダミーの関数を作成するか
どっちにしろ使ってる関数なら作る必要があるんでね？
宣言してるだけで使ってない関数ならダミーの関数すらいらない。
0501デフォルトの名無しさんNGNG
そもそもヘッダでincludeしないのなら、
インクルードガードとか言うテクニックが広がる分けない。
0502デフォルトの名無しさんNGNG
>>ヘッダAを修正した結果、ヘッダBが必要になったら、 Aを使ってる全てのソースを修正

??
あと、ここで議論されていたのは、「ヘッダでは絶対includeしてはいけない」は有効か、なんだけど？
0503502NGNG
すまん、今意味がわかった。
…ﾏﾀﾞｱﾀﾏｶﾞﾈﾃﾙﾖorz
0504デフォルトの名無しさんNGNG
>>499
そういうレスは想像してたけど
ヘボなのはわかってるけど、元受の指定なので。
ヘボだろうとなんだろうとどうしようもない。
やらざるを得ないので。

>>500
そういやそうだ。あれ、なんでだったけな。。orz
0505デフォルトの名無しさんNGNG
>>504
> やらざるを得ないので。
愚痴はよそで垂れて。
0506デフォルトの名無しさんNGNG
この話題の結論は、
「ヘッダの入れ子include禁止、というコーディング規約は糞」
で、もう異論はないかね？
0507デフォルトの名無しさんNGNG
「ヘッダ内で不要なヘッダをincludeするな」ならまだしも
「ヘッダの入れ子include禁止」だもんなあ。
糞規約だな。
0508デフォルトの名無しさんNGNG
↓ 糞コーディング規約に関する次の愚痴，どうぞ
0509デフォルトの名無しさんNGNG
保守age
0510デフォルトの名無しさんNGNG
ポインタ禁止とかprivate禁止とかって実在するのかね
0511デフォルトの名無しさんNGNG
>510
ポインタ禁止は（C言語だと）流石に仕事にならんだろう…
でもprivate禁止は以前ネタで挙がってた気が。
0512デフォルトの名無しさんNGNG
alloc禁止ならやりかねない所もありそうな気が…
0513デフォルトの名無しさんNGNG
>>510
C++だと、ポインタ禁止にするとアホが駆逐されるからやりやすいよ。
0514デフォルトの名無しさんNGNG
>>513
それはそうかもしれんが、正直あんまりやりたくはないな。
自分の手足（＝ポインタ）が縛られてでも馬鹿に邪魔されないことがどれだけ重要かにかかってるな。
手足縛られるよりも酷いことになる馬鹿が居るんだとすると禁止でもいいかもしらん。
ところで参照は使ってもいいですか？

ただ、一部プラットフォームはそのAPI呼び出しにポインタ必須だからなぁ。
WindowsとかWindowsとかWindowsとか。例外処置？
0515デフォルトの名無しさんNGNG
はぁ？API呼び出しに、ポインタ必須じゃないプラットフォームを逆に聞かせろや

お前はWindowsしか知らんくせに、Windowsバカにしたい年頃なだけだろがボケ
0516デフォルトの名無しさんNGNG
嗚呼　Windows無くなったらおまんま食い上げだわ俺　鬱
0517デフォルトの名無しさんNGNG
>>515
周りの所為で自分に悲劇が降って来た嘆きながら
その実自分が回りに悲劇を振りまいた張本人だったというパターンだな
0518デフォルトの名無しさんNGNG
完全にC++のインターフェイスを用意してるプラットフォームの方が珍しいだろうなぁ。
C系のインターフェイス呼び出しにはどう頑張ってもポインタが付きまとうし。
そういう意味ではポインタ禁止はかなり厳しいのは確かだろうな。
0519511NGNG
ポインタ禁止と抜かしつつ、マクロで隠蔽したポインタを強制するプロジェクトなら実在するかも。
某診断室みたいなサイトにサンプル転がってないかな。
0520デフォルトの名無しさんNGNG
>>519
もう診断室はいいよぉ。いまさらだよぉ。
0521デフォルトの名無しさんNGNG
ポインタ禁止と言う事は、文字列使えないし、動的なメモリ確保も行えない。
関数のコールバックも使えないから、UIからの入力も受け取れない。
かといってコンソールからの入力もFILE*が必要だから出来ない。

何も出来なくない？
0522デフォルトの名無しさんNGNG
>>521
だから、C++だってば。
（もちろん完全に排除ってのは難しいと思うけど。）
0523デフォルトの名無しさんNGNG
C++はよくわからんのですが、
ポインタ使わずに、レジスタとか絶対アドレスをたたけるんですか？
0524デフォルトの名無しさんNGNG
>>523
C++にはポインタ演算のできないポインタのような参照がある。
ただ絶対アドレスは叩くのはたぶん無理。
0525523NGNG
>>524
ありがとうございます。
じゃあ組み込みには使えない規約ですね。
0526デフォルトの名無しさんNGNG
>>525
そりゃそうだ。
けどあえてむちゃくちゃを言わせてもらおう。

アドレスにマップされているレジスタとか絶対アドレスだったら、
アドレスをリテラルで用意しておけばポインタを使うことにはならないよね？（ｗ
（ポインタへのキャストは必要だけど）
0527デフォルトの名無しさんNGNG
asm使えよ。
0528デフォルトの名無しさんNGNG
で、結局リファレンスとポインタ共存は仕方ないとして(いいんだよね？)
どういう住み分けが一番いいのかな？
0529デフォルトの名無しさんNGNG
readに参照、writeにポインタだろ。
0530デフォルトの名無しさんNGNG
>>529
それらの区別は基本的にconstの役目。
0531デフォルトの名無しさんNGNG
つまり、参照は const でしか使わないということ。
0532デフォルトの名無しさんNGNG
配列ならポインタ、配列でなければ参照、などと適当な事を言ってみるﾃｽﾂ。
0533デフォルトの名無しさんNGNG
>>529
設計思想に無い意味を与えるのはよくない。しかも代替がある。
その住み分けがよいとは思えない。
0534デフォルトの名無しさんNGNG
ポインタは極力リファレンスに置き換えるべきだ

と書いてある本があるけど、端的な話？
それともほんとにそれが理想？
0535デフォルトの名無しさんNGNG
>>534
ポインタはオブジェクトを単に指し示すだけでなく、
配列演算やヌルポインタなどの意味ももれなく併せ持ってしまう。

参照であれば、単一のオブジェクトを指し示すだけの意味に絞れる。
意味が絞れれば、コードから意図を汲み取りやすい。
0536デフォルトの名無しさんNGNG
納得できる理由まで㌧x

このスレ結構勉強になるんで、前スレも欲しいんだけど
誰かうｐしてくれませんか？専ブラの生データでもいいんで
0537デフォルトの名無しさんNGNG
>>535
int &func(){
int *ip=NULL;
return *ip;
}
参照型でヌルポインタが出てきたときの解りづらさときたら(ry
0538デフォルトの名無しさんNGNG
>537
∧＿∧
(　´∀｀)ぬるり
0539デフォルトの名無しさんNGNG
>537
まあこんなのは悪意があるか、よほどのうっかりさんでもない限り作られないからな。
0540デフォルトの名無しさんNGNG
>>539
以前、失敗したらNULLを返す関数の戻りが返される参照型の関数があって
外側で
int &hoge=func();
if(&hoge==NULL){
…
}
って書く羽目になった orz
0541デフォルトの名無しさんNGNG
1行80文字制限は無視してるヤツが多いのか。
オレもいい加減止めようかな。あんまり意味ないっぽいし。

制限すると今度は改行したあと、どこまでインデントするかで悩むんだよね。
メソッド呼び出しの引数が分割されたとき、
Method()の(で合わせるか、普通にインデントするだけにするか、とか。
0542デフォルトの名無しさんNGNG
>>541
> 1行80文字制限は無視してるヤツが多いのか。
オレはその制限で縛ってるよ。オマケに1インデント8文字分だし。
長過ぎる名前や、ネスト深くなり過ぎるとすぐに気づく。

引数の分割は普通にインデントしてる。
0543デフォルトの名無しさんNGNG
80制限はちとキツイな。
インデントは4スペース、横は120くらいかなぁ。
インデント8で80制限だと、Javaなんかメソッド内部の時点で残り64文字。
forのなかにifでも入れようもんなら残り48文字なわけで、さすがにちょっと窮屈かなと…

関数呼び出しでの折り返しは

font = CreateFont(-11, 0, 0, 0, FW_DONTCARE, FALSE, FALSE, FALSE,
　　DEFAULT_CHARSET, OUT_DEFAULT_PRECIS, CLIP_DEFAULT_PRECIS, DEFAULT_QUALITY,
　　FIXED_PITCH | FF_SWISS, "Arial");

か、

font = CreateFont(
　　-11, 0, 0, 0, FW_DONTCARE, FALSE, FALSE, FALSE,
　　DEFAULT_CHARSET, OUT_DEFAULT_PRECIS, CLIP_DEFAULT_PRECIS, DEFAULT_QUALITY,
　　FIXED_PITCH | FF_SWISS, "Arial"
);

だな。
0544デフォルトの名無しさんNGNG
タブ縛りはやめてくれ。
0545541NGNG
>>542
インデント8文字は辛そう。

>>543
プロポーショナルフォントで綺麗に揃うか分からないけど、

font = CreateFont(-11, 0, 0, 0, FW_DONTCARE, FALSE, FALSE, FALSE,
　　　　　　　　　　　　DEFAULT_CHARSET, OUT_DEFAULT_PRECIS,
　　　　　　　　　　　　CLIP_DEFAULT_PRECIS, DEFAULT_QUALITY,
　　　　　　　　　　　　FIXED_PITCH | FF_SWISS, "Arial");

このパターンはダメかな。
これに統一すると、関数内でさらに関数呼び出すと右に偏っちゃうのが難点なんだよね。
あらかじめ変数に入れといておけば良いんだけど、無駄に名前使いたくないし。


単純な値でもちょっと悩む。

addTest = 1 + 2 + 3 + 4 + 5 +6 + 7 + 8 + 9
　　+10;

addTest = 1 + 2 + 3 + 4 + 5 +6 + 7 + 8 + 9
　 　　　　　 + 10;

addTest = 1 + 2 + 3 + 4 + 5 +6 + 7 + 8 + 9
　　 　　　+ 10;
0546デフォルトの名無しさんNGNG
>>545
そのCreateFontの例、俺もやってたことあるけど、
関数名を置換したときにインデントまでいじる必要が
出てくるのが面倒だった。
今は>>543の後者にしてる。
0547デフォルトの名無しさんNGNG
>>546
たしかにインデントし直すのはめんどいな。
0548デフォルトの名無しさんNGNG
インデントは半角「２文字」だの「４文字」だの言う割には
「秀丸のタブ設定変えるだけでいいよ」と言う。
でも正直4000円払っているか否かは多いに疑問…
0549デフォルトの名無しさんNGNG
関数名が長くなるとどんどん右へ寄ってってしまうのが嫌
Windowsの関数名ってやたらに長いし
0550デフォルトの名無しさんNGNG
漏れは xyzyy の c++mode を一部変更して使ってます。
(インデントにタブ使用禁止してスペース数を設定くらい)
普段は何も考えずにインデントされていくし、
[Tab]キーを押せば自動整形されるから超楽チン。
もう秀丸なんて使えないね。

xyzzy まんせー！！
0551デフォルトの名無しさんNGNG
↓IDE(ryと書く奴
0552デフォルトの名無しさんNGNG
vim最強伝説
0553デフォルトの名無しさんNGNG
すいません、質問です。
うちの大学の教授が、実習にて
｢プログラムのコメントは一行ごとに書くこと。
自分の書くプログラムすべてにコメントを入れるのはプロなら常識｣
「会社では、構造体のメンバを一個追加するためにも上司の書類が必要｣
とのことですが、プロの皆さんとしてこれはどうなんでしょうか？
プログラムの可読性を重視するという点についてはまったく異存はありませんが、
｢コメントが少ない｣と言う理由でレポートを突っ返された日には……
0554デフォルトの名無しさんNGNG
一行ごとに書くわけねーだろｗ
有名オプソコードでも提出してやれ。
0555デフォルトの名無しさんNGNG
つーか、むしろコメントは最低限じゃないとだめだろ。
まともに書いてあるコードならそれだけで何やってるか分かるはずだし。
必要なのは「なぜこの方法にするか」とかコードから読み取れない
メタ情報じゃないのか？

むしろ、無駄なコメントはかえって可読性を落とすよ。
コメントがあるとついついそっちで理解しようとしちゃうから、
コードだけ修正してコメント直し忘れたりすると、
バグが混じったとき永遠に気が付かなかったりするし。
0556デフォルトの名無しさんNGNG
// クラス something のインスタンスを制作
instance = new Something();

みれば分かるよ・・・・・・('A`;)
0557デフォルトの名無しさんNGNG
見りゃ分かるコードにコメント入ってると激しくウザイな。

もっともCでいうところの構造体のメンバに関しては簡単に増減できないと思う。
C++でいうところのメンバ変数がすべてpublicのclassなわけだから、
その構造体使ってるところ全部コード見直す必要が出てくる。
書類どうこうはまぁともかくとしても、勝手に弄って欲しくはないかな。
増やすくらいならどってことない気もするか…？
0558デフォルトの名無しさんNGNG
>>557
構造体でもファイルにそのまま保存したりとかあったりすると勝手な追加はやめて欲しい
0559デフォルトの名無しさんNGNG
>>553
大きく間違ってはいないと思う
要するに、行き当たりばったりで作るなということ
コメントも、書けないのと書かないのでは違う
コメントを入れたからといって効率おちるものではないし
学生のうちは書いておいて損ではない
0560デフォルトの名無しさんNGNG
あーなるほどな。
まあ、必要なコメントと不要なコメントの区別がつくようになるまでは
なんでもかんでもコメント入れるのは（訓練として）悪いことじゃないかもしれん。
ここで愚痴ってるってことは多分そのくらいのことは分かる自信があるくらいには
やれると思ってるってことなんだろうと思うが、大抵先生ってのは頭固いのが多いから折れとけ。
どうせ会社入ったって頭の固い上司ってのは居るもんだし、
そういう意味でも悪いことじゃないかもしれん。
0561デフォルトの名無しさんNGNG
ま、「プロなら常識」ってのは一体何年前のプロだよ？　って感じなのは確かだが、
上司（ここでは教授）の顔を立てておくのは世渡術として身に着けておくと良いかも知らん。

それとも、「そこは間違ってる」と教授に対して主張できるのは学生の特権かねぇ？
0562デフォルトの名無しさんNGNG
学校名と学部さらしとけ。
いまどきそんなアフォが居るとは･･･
0563デフォルトの名無しさんNGNG
アフォとは思わん。
ろくに書けないうちに中途半端な技術で、出来ると気になってこの業界に来られても困る
>>553 が反抗したいだけなのか、まんどくさいのを正当化したいだけなのか
いずれにせよ、言う事聞いとけ。間違っちゃいない。
0564デフォルトの名無しさんNGNG
>>563
アフォだな。
0565デフォルトの名無しさんNGNG
　　　　　　　　　　　　　　　　　　　　　　　　 ,､ｧ
　　　　　　　　　　　　　　 　 　 　 　 　 ,､ '";ｨ'
_＿_＿＿___　　　　　　　　　　　　　 ／::::::/l:l
─- ､::::;;;;;;;;;｀ﾞﾞ''‐ ､　 　 __,,,,......,,,,_／:::::::::/: !|
　　. : : : : : : ｀ﾞ'ヽ､:::ﾞヾ´::::::::::::::::::::::｀ﾞﾞﾞ'''‐'､. l|
､､ . : : : : : : : : r'":::::::::::::::::::::::::,r':ぃ::::ヽ::::::::ヽ!　　　　　　　　　　　　　　　　　,､- ､
.ヽ:ﾞヽ; : : : : : :ノ:::::::::::::::::::::;;､-､､ﾞ::: 　 　 rｰ-:'､　　　　　　　　　　　　　 　 ／　　 }￢､
.　＼::ﾞ､: : : :./::::::::::::::;､-''"::::::::::　　　,...,:::,::.,　:::':､　　　　　　　　　　　　_,,/,,　 ,､.,/ 　 }
　　　ヽ:ヽ､ /:::::::::::::::::::::::::　 　 　_　　｀ﾞ''‐''"　 __,,',,,,___　　　　　　　／~　　 ヾ::::ﾂ,､-/
　　　　 ｀ヽ､:::::::::;;;､､--‐‐'''''',,iﾆ-　　　 _|　　､-l､,},,　 ￣""'''￢-, '　 ''‐-､ .,ﾉ'ﾞ,i';;;;ﾂ
　　　_,,,､-‐l'''"´:::::::'　　,､-'" ,.X,_,,､-v'"''ﾞ''yr-ヽ / ﾞﾞ'ヽ､,　　　 ,.'　　　 　 jﾞ,,, ´　>>564またまた～ご冗談を
,､-''"　　 　.l:::::::::::;､-''"　 ,.-'　　ﾞ､""ヾ'r-;;:l　　冫、 　 　 ヽ､ /　 　 __,,.ノ:::::ヽ. /
　　　　　　　l;､-'ﾞ:　　 ,／　　　 　 ゞ=‐'"~ﾞﾞ')　./.　＼　　　　/　　'''"/::::;:::;r-''‐ヽ
　　　　　,､‐ﾞ ヽ:::::..,.r'ﾞ　　　　　　　　 ,,. ,r／ ./　　　 ヽ.　　 ,'　　 　 '､ノ''"　　　ﾉ
　　 ,､‐'ﾞ　　 　 ﾝ;"::::::.　　　　　　　"´ 'ﾞ ´　/　　　　　 ﾞ､　,'　　　 　 　 　 　 ／
　　'　　　　　／/:::::::::　　　　　　　　　　　　{.　　　　　 　 V　　 　 　 　 　 ／
　 　 　 　 ／ ./:::::::::::::　　　　　　　　　　　　',　　　　　　 /　　　　　　 　 /
.　　　　／　 /:::::::::::::::::.　　　　　　　　　　　　',.　　　 　 /　　 ,.､　　　　 /
0566553NGNG
いや、可読性の高いプログラムを書くことに関してはなんら異存はない……
それに必修授業の担当教官にケンカ売ったって仕方ないし……

だがな、お前ら自分の書いたプログラムの一行ごとにコメント入れたいか？
無駄なコメントを入れるのは嫌だやりたくない……重要なのは可読性であってコメントじゃないはずなのに……
こういう非生産的な作業は本当に気が滅入る……
0567デフォルトの名無しさんNGNG
>>563
なんで高級言語が出来たと思ってるんだ？（ﾌﾟｹﾞﾗ
0568デフォルトの名無しさんNGNG
>>566
完全におまえは正しい。
ただし本当のプロなら、非生産的でも、理不尽でも、クライアントの要求は実現するものだ。
0569デフォルトの名無しさんNGNG
大は小を兼ねる
個人的には不満も出るだろうが、
生徒全体に教えるという意味では、最初はそういうもんでいいんでない？
生産的どうのこうの言ってたら何も出来んよ

まぁ漏れは>>568の意見に賛成だな
0570デフォルトの名無しさんNGNG
>>569
兼ねないだろ。
意味の無いコメント増えたら見づらいし、
意味があるとしてもコンパイラにチェックされない分、保守性も著しく下がる。
0571デフォルトの名無しさんNGNG
コメント書く癖が付いてなけりゃ、コメント書くのめんどくさいとしか思わないだろうが
コメントを非常識に多く書かされてりゃ、コメント書く癖は付く
その上で、どのぐらいが適度・適切なコメントなのか判断が付くようになる

↑にも書いたが、最初はそういうもんでいいんでない？　と。

見づらい、保守性下がる、などは言うまでもないこと
ただ、教育というものを考えればそういうのもアリだと思うが
0572デフォルトの名無しさんNGNG
>>571
根拠は？
0573デフォルトの名無しさんNGNG
アセンブラでｽｹﾞｰトリッキーな最適化コード書くときは１行ごとに説明入れたりしたが、
高級言語ではソースそのものが処理を説明していないとな。
0574デフォルトの名無しさんNGNG
>>571
禿同
まだ、なにが必要でなにが必要でないか判断もつかないのに生意気言うなというところ
とにかく書けよ、書けばわかるさ
反論してる奴は、たぶん（ry
0575デフォルトの名無しさんNGNG
>>574
根拠は？
0576デフォルトの名無しさんNGNG
つか、
>自分の書くプログラムすべてにコメントを入れるのはプロなら常識｣
だの
>「会社では、構造体のメンバを一個追加するためにも上司の書類が必要｣
だのは素人の妄言にしか聞こえない。
0577デフォルトの名無しさんNGNG
>>576
>「会社では、構造体のメンバを一個追加するためにも上司の書類が必要｣
これはあるが。
0578デフォルトの名無しさんNGNG
大げさに表現して、学生に言い聞かせようとしたか
真性なのか、どちらかだろうな
0579553NGNG
>>568
なんか腑に落ちた。
彼には皮肉のひとつやふたつ言ってやりたいけど、そんなことせずに
淡々と糞レポートを仕上げるべきなんだよな。

とは言えやっぱりやりたくない……
こんなことで時間を浪費するくらいならもっと生産的なこと(わいせつ画像収集等)をしていたほうがましだ……うう
0580デフォルトの名無しさんNGNG
コード見りゃわかる、といってろくにコメント書いてない奴が
あとで自分で見てパニクってたな
結局やめていって残された奴がひどいめにあったが
そうかと思えば、若い奴で　やっとコメント書いたかと思ったら
i=100; // i に100を代入する
みたいなコメント書きやがって（ｒｙ

おっと、ここは愚痴を書くスレじゃなかった
0581デフォルトの名無しさんNGNG
>>579
まー教授も学生が理解できてるか採点しなきゃいかんから
そんなこと言ってるんだと思っておくのが一番いいんじゃないか。
0582デフォルトの名無しさんNGNG
いや、実は教授はコードが読めなくて、コメントを見て判断してるに違いない。
0583デフォルトの名無しさんNGNG
i++;　　　　　　　//教授から評価を増加
0584デフォルトの名無しさんNGNG
過ぎたるは及ばざるが如しってな
0585デフォルトの名無しさんNGNG
>>579
ソースに見たまんまのコメントを追加するプログラムを作るんだよ
  i=100; // i に100を代入する
とかのレベルなら可能だ
0586デフォルトの名無しさんNGNG
それ面白い。
誰か作ってJOKEソフトとして(コメント入りのソース付きで)公開してくれ。
0587デフォルトの名無しさんNGNG
それいいな！
はじめにひとつ作っておけば後々の課題すべてに対応可能だな。
0588デフォルトの名無しさんNGNG
>553
その教授は授業でサンプルコード書いたりしないのか?
サンプルコードに1行毎のコメントが書いてなかったら、プロじゃないのかと小一時間問い詰めてやれ。
0589デフォルトの名無しさんNGNG
教授は別にプログラマとしてはプロじゃないよな。
0590デフォルトの名無しさんNGNG
もちろん学生もな。
0591デフォルトの名無しさんNGNG
大学ってアマチュアの溜まり場ですよね。ﾌﾟﾌﾟﾌﾟ
0592デフォルトの名無しさんNGNG
と、入社１年目のやつが語る。ﾌﾟﾌﾟﾌﾟ
0593588NGNG
>589
そう返されたら
「プロでもないのに知ったかぶってるんじゃね-YO!」
でトドメ。
0594デフォルトの名無しさんNGNG
単位もらえなさそうだなｗ

まぁ、必修じゃなければそれでもいいが。
俺も先生が気に入らなくて切った選択講義がひとつだけあるな。
プログラミング関係というかソフトウェア開発関係の講義だったかな…
0595デフォルトの名無しさんNGNG
マッキントッシュのことをマッキンと呼ぶのはやめて欲しかった。
0596デフォルトの名無しさんNGNG
パッキンフォッシュとかアホっぽいのがいいな
0597デフォルトの名無しさんNGNG
マクドナルドをマクドと呼ぶのなら
マッキントッシュをマッキンと呼ぶのが普通。

マクドナルドがマックなら
マッキントッシュもマックで良いが。
0598デフォルトの名無しさんNGNG
いーや

マクドナルドはマクド
マッキントッシュはマックだ
0599デフォルトの名無しさんNGNG
マクドナルドのフライドポテトの事をなんて呼ぶんだよ。
関西人が幾らあほな事を喚いたところで、マクドナルド自身がマックと呼んでいる事実は覆らない。
0600デフォルトの名無しさんNGNG
ネタにそんなムキになって突っ込まれてもな…(；´Д｀)

つーか略し方はお上が定めたものをそのまま受け入れるよりも
顧客側が呼びやすいものを選ぶものだろ？
0601デフォルトの名無しさんNGNG
顧客「マッキーでお願いします。」
0602デフォルトの名無しさんNGNG
マクドはマクドや！
マッキントッシュはMacやからマックって言うんや！

何か文句あるんか！？
0603デフォルトの名無しさんNGNG
ある。
0604デフォルトの名無しさんNGNG
ロッテリアはロッテって言うのか？言わんだろ
マクドはマック、マックはマックだ
0605デフォルトの名無しさんNGNG
ってことは、malloc は「マロ」でいいっすか。
0606デフォルトの名無しさんNGNG
分かってないな。
名称の頭を取るのが関西方式という訳やないねん。
マクドは結果的に頭だけ取った言い方やけど、そこから法則を決めつけるのは頭悪すぎやねん。

とりあえず貴様らを同化する。
0607デフォルトの名無しさんNGNG
まいどに語呂が似てるからマクドなんだろ
普段使ってるリズムだから使い易いわな
さわりは弱く、語尾を強くというイントネーションに合わせたらマクドになると

でもマックはマックだ。
0608デフォルトの名無しさんNGNG
>>605
ｴﾑｱﾛｸ
0609デフォルトの名無しさんNGNG
マクドシャイク
マクドフライ
てりやきマクド
ビッグマクド
0610デフォルトの名無しさんNGNG
>>608
callocはｼｰｱﾛｸ？

そうそう、こないだ「すてゅっどいん、すてゅっどいん」ってコードレビュー中に連呼する人がいて、
何のことかと思ったらstdinのことだったみたい。
「とぅくぴっぷ」思い出しちゃって、笑いこらえるの大変だった。
0611デフォルトの名無しさんNGNG
そろそろ言ってもいいかな

どこが「コーディング規約」よ？
0612595NGNG
すまん、まさかかような流れになるとは。
0613429NGNG
コーディング全体から見て、俺のは３割がコメントになる。
普通に書いていれば、そのくらいの割合。
Cだろうが、COBOLだろうが。大体においてそのくらいになる。

これが多いかどうかはさておくとしても、コメント書かない人って
マジで１割みたいないって時が多いように思う。


みんなのコードはどうよ？
0614デフォルトの名無しさんNGNG
どうでもいい
0615デフォルトの名無しさんNGNG
日本語が意味不明
0616デフォルトの名無しさんNGNG
http://flex.ee.uec.ac.jp/www/japanese/riron/rule/source.html
> 変数名の長さは、プログラムの中の10 行以内で独立に使うものを、 1 文字 (i,j,...),
> 20 行以内で独立に使うものを 2 文字 (i1, i2, etc) プログラム全体に渡って使うが非常に
> 頻繁に使うものを 3 文字, common 変数は 6 文字、というように文字の長さがその性質を示すように設定する。

……どうなのかと。
0617デフォルトの名無しさんNGNG
>>616
そういうルールならそう書くだけです。
0618デフォルトの名無しさんNGNG
0619デフォルトの名無しさんNGNG
コメントを書くまでもない慣用句の多い言語を使えばよい。
言語の不備をコメントで補うのは本末転倒。
0620デフォルトの名無しさんNGNG
自分では可読性の高いコードが、他人にとっては可読性が高いとは限らない。
三ヶ月後の自分が、自分のままであり続けるかどうかも保証されていない。
0621デフォルトの名無しさんNGNG
そういうのを思考停止と言います
0622デフォルトの名無しさんNGNG
三ヶ月後の自分で作ったライブラリって妙にメソッド名が厨臭く感じて拒絶反応が出る
0623デフォルトの名無しさんNGNG
漏れ式。
・ローカル変数は極力短く。
略語を使い、プレフィクスはなるべく付けない。（ポインタを表すp程度に留める）
・メンバ変数はなるべく意味を詳細に。
略語は使わず、型プレフィクスもメンテに支障が出ない程度に使用する。(※)
・グローバル変数には上記に加えg_を付ける

※ハンガリアンの弊害として知られる「型変更時の名前の変更」を避けるため、
暗黙の型変換が可能なものには、なるべく個別のプレフィクスを付けない。
例えば int、float、double 等は「n (number)」でまとめてしまうとか。

こんなんで良いのだろうか。批判よろ。
0624デフォルトの名無しさんNGNG
途中で型を変えるなんて設計が悪い
0625デフォルトの名無しさんNGNG
>623
あっしは型とかスコープじゃなくて、ポインタとか宣言とかの形態で
プレフィックスを付けとります。
ポインタ: p_somethingとかauto_ptr at_somethingとか。

オブジェクト、ポインタ、型(宣言)は、結局同じものの別の側面を
表しているだけのような気がしますな。
0626デフォルトの名無しさんNGNG
キャスト問題は割り算とかでは避けられないからあんま気にしない
0627デフォルトの名無しさんNGNG
>>625
auto_ptrや他のスマートポインタはポインタのセマンティックスで
動作することを念頭に置いているわけだし、たとえばスマートポインタの
場合、仕様変更やリファクタリングの結果、他のスマートポインタに
変更する可能性も十分あることから、at_somethingなどという
プレフィックスよりはp_somethingの方が優れているのでは、
とは思うな。まあ、俺はポインタでもプレフィックスは付けないけど。
0628デフォルトの名無しさんNGNG
ちょっとまて、auto_ptrに対応するプリフィックスが at_ なのか？
どっちにしても型を反映するプリフィックスは総じて嫌だが。
0629デフォルトの名無しさんNGNG
型なんてコンパイラの警告である程度(気休め)
0630デフォルトの名無しさんNGNG
変数の型をあらわすのってプレフィックスより
サフィックスの方が良いような気がする。
0631デフォルトの名無しさんNGNG
私はハンガリアンはまったく使わないな。必要性を感じない。
たまにポインタの p をつけるぐらいだ。
0632デフォルトの名無しさんNGNG
思わん
0633625NGNG
>627
shared_ptr weak_ptr 生ポインタあたりを混在させることが多いからね
それぞれに名前考えるのも面倒だし


>仕様変更やリファクタリングの結果、
>他のスマートポインタに変更する可能性も十分あることから

確かにshared_ptr <-> auto_ptr あたりはありそうだけど、
リファクタリングして名前変更すれば良いんじゃない？
0634デフォルトの名無しさんNGNG
> リファクタリングして名前変更すれば良いんじゃない？
それが嫌だってんだよクソッタレが。
0635625NGNG
>634
でも、smart pointerの種類を変更すると所有権の扱いが変わるから、
何も変更せずに済むとも思えんけど。
0636デフォルトの名無しさんNGNG
>>635
それは「所有権の扱いが変わった」ことを反映した変更だ。
型が変わったから名前を変えるんじゃない。
0637デフォルトの名無しさんNGNG
うちのコーディング規約
グローバル変数は
m_
をつける事ってあるのだが、
クラスモジュール内の変数はどう名前つければいいんだろうか・・・
標準的なm_だと被るし
0638デフォルトの名無しさんNGNG
もう変数の頭に型名完全明記でいいじゃん
int int_i, int_j;
型変わったらリファクタリングブラウザで一括変換。そんだけ。
0639デフォルトの名無しさんNGNG
>>637
FValue;
なんてclass fieldのfをつける流儀もある(Borland Delphi)。
0640625NGNG
>636
>それは「所有権の扱いが変わった」ことを反映した変更だ。 
もちろん、名前が「所有権の扱い」のはっきりわかるものだったら
問題ないけど……

smart pointerを扱う上で、所有権がどのような状況なのかを
知るのは非常に重要なことだと思いますです。

#local scope内の話なら別にどうでもいいけどね。
0641デフォルトの名無しさんNGNG
>>640
所有権の扱いが重要な場所でそれを名前に表すのは問題ない。
その方法として型名を名前に付けるのは安直で脆い。
0642625NGNG
>641
重要じゃない場所はそんなにないと思うけどね。
まあ、全部shared_ptrにしちまえば問題ないか。
＃効率はともかく
0643627NGNG
>>640
それも一理あるね。

でもま、俺は型によるプレフィックスは総じて不必要だと
思ってる。識別子というのは名前のとおり抽象された
各オブジェクトを識別するためにあるのであって、言語
レベルの制約によってその識別子の命名法が左右されるのは
抽象化の意味がないと思う。そんなのは宣言している箇所を
確認すればいい話であって。

データメンバの場合はgetter、setterなどのメンバ関数と
名前がかぶりやすいのでなんらかのプレフィックスなり
サフィックスを付けるのはしかたないとは思うけどね。
0644デフォルトの名無しさんNGNG
>>642(625)
型名を名前に反映させるなんて、まったくナンセンスなんだよ。

template<typename Pointer> void do_something(Pointer p);

こんな形になってたら、その考え方でどうやって名前を付けるのかね？
0645625NGNG
>643
>各オブジェクトを識別するためにあるのであって、言語 
>レベルの制約によってその識別子の命名法が左右されるのは 
>抽象化の意味がないと思う。

ごめん、C++前提で話してた。
確かに上の例はC++の不恰好さを取り繕うためのルールだからね。
＃同じオブジェクトでも、型(class)/インスタンス/参照/ポインタ/smart_ptr
＃のように何通りもの側面があって、それぞれを使い分ける必要がある

>そんなのは宣言している箇所を確認すればいい話であって。 

確かにそうだけど、smart pointerは取り扱いを間違えると
ひどい目にあうからね。
まあ、これは私がタコだと公言しているようなもんだけど……
0646625NGNG
>644
いや、関数は使い分ける必要無い（別の側面が無い）から
そのまま命名してもいいんじゃない？

所有権の微妙な問題も無いし。
0647デフォルトの名無しさんNGNG
>>646 関数の名前じゃないだろ。アフォか。
0648デフォルトの名無しさんNGNG
>>646
>>644は、仮引数のpのことを言ってるんだと思われ

まあ、所有権が明らかでないポインタを渡すのは
好ましくないとか言いそうだな、君は。
0649625NGNG
>647
スマン、テンプレート引数のことか。
使い分ける必要無い（所有権を気にしなくていい）としたら何でもいいし、
特定のpointerに限られるとしたらそのpointerを示す名前にしたら
いいんじゃない？

……shared_ptr & 生ポインタのみつうのはどうしようかね？
0650デフォルトの名無しさんNGNG
スマートポインタで痛い目に遭ったのかもしれないが、
そろそろその傷の痛みを忘れる時期じゃないかね。
0651625NGNG
うお、仮引数pか……
これもテンプレート引数と同様に、何を想定しているかによって
変えますな。

0652デフォルトの名無しさんNGNG
>>651
templateでPointer受け取るようにしといて、
「おれは生ポインタを想定している」という理由で p～ にするのか？

templateの意味無いじゃん。ほんとでちゃんと考えてしゃべってる？
0653625NGNG
>templateの意味無いじゃん
なんで？
0654デフォルトの名無しさんNGNG
たぶんおそらくスレ違い
0655デフォルトの名無しさんNGNG
>>653
特定の型を想定しているなら、型をtemplate引数にする意味が無いだろ。

templateを知らないんならともかく、こんなこと説明しないとわからないの？
嫌な言い方になるが、自論に反する情報はわざと目を背けてるように見えるな。
0656625NGNG
>特定の型を想定しているなら、型をtemplate引数にする意味が無いだろ。 
別にsmart pointerの種類を特定しても、templateのメリットが無くなるわけじゃ
ないと思うけど……自由度は減るけどね。

確かにスレ違いだな……
0657デフォルトの名無しさんNGNG
遅レスだが、サフィックスならFlashのActionScriptでやってるな
エディタと連携させるアルゴリズムが単純で面白い
0658625 NGNG
反応無くなったね、656……
スレ違いだけど自己フォロー。
smart pointerの種類を限定している例として有名なのにSTLコンテナが
あるよ（悪名高いCOAPのこと）
また逆に引数に指定されたオブジェクトの所有権を譲り受ける場合は、
auto_ptrで明示した方がいいわけで……
smart pointerの種類を特定することが悪いわけじゃないですな。
0659デフォルトの名無しさんNGNG
>>658
おぉ。言葉の意味は良くわからんが、とにかくすげー必死だな。

えーと、STLコンテナがsmart pointerの種類を限定しているって？
意味がわからないし、聞いたことも無いな。
会話がしたいのなら、エスパー以外にもわかるように説明してね。
0660625NGNG
>659
毒吐くだけなら自己フォローに反応することないのに…… 
auto_ptr使うな、つうことですな。生ポインタやboost::shared_ptrはOK。

オブジェクトの所有権を譲り受ける場合の例はこんな感じ？
template<class T>
class holder {
public:
　void setValue( std::auto_ptr<T> t )
　　{ h = t; };
private:
　std::auto_ptr<T> h;
}

あと、>655 なんだけど、もしかして普通のポインタとvoid*を混同してない？
void f(int*) に double*突っ込めるなんて考えてないよね？
0661デフォルトの名無しさんNGNG
>>659
俺は625じゃないが、言いたいことはわかるけど、STLコンテナには
auto_ptrを入れてはいけないというのは規格で定められているよ。
COAP(Container of the auto pointer)は駄目って。
0662デフォルトの名無しさんNGNG
>>660
STLコンテナに auto_ptr を入れることができないのは、
要素の型に Assignable Concept が要求されていて
auto_ptr はその要求を満たさないから。
STLコンテナが auto_ptr を格納しないように設計されているのではない。

その例は template定義側が auto_ptr を使うことを「自分で決めている」のであって、
template引数Tに対して何かを「想定」しているわけではない。
644からの話については、何の例にも説明にもならない。

話を趣旨に戻すが、
型名を名前に反映させるなんて、まったくナンセンスなんだよ。
0663625NGNG
お、話が戻ったかな？
>662
>型名を名前に反映させるなんて、まったくナンセンスなんだよ。 
確かにポインタは型なんだけど、ただの型じゃなくて、元の型に依存した
派生型・ある型の別の側面といえる特性を持っていると思う。
ポインタなんて、元の型を操作することを想定しているわけだしね。
なので、「ある型のポインタ型」として使うような場合は、元の型との
関連性を示す上でも、元の型の名前にポインタを示すprefix,postfixを
付けるのが適当な命名方法かと思う。
＃もちろん、よりふさわしい名前があれば別だけどね

……というか、ポインタごとに名前考えるの面倒臭くない？
0664625NGNG
>662
>STLコンテナが auto_ptr を格納しないように設計されているのではない。 
いや、>661も指摘してるけど、C++標準はSTLコンテナにauto_ptrを格納しない
ように設計されている（=COAPを禁止している）よ……


0665デフォルトの名無しさんNGNG
>>663
順番が逆。
まず、ふさわしい名前を考える。
ただ、最悪の場合として、型情報を複製したような変数名で済ませてしまうこともあるだろう。

// たとえば625のような考え方だとこうなってしまうものを、
FILE* pfile; // 入力ファイル

// こうしてほしいってこと。
FILE* input;

前者でコメントに入っていた情報が
後者ではコードに現れる点が重要な意味を持つ。
前者では、変数の宣言位置では意味がわかるが、
その後、その名前を使用したコードではほとんど意味がわからない。
そのため、くだらないコメントを複製する羽目になる。

fclose(pfile); // 入力ファイルを閉じる

fclose(input);
0666デフォルトの名無しさんNGNG
>>664
規格で決められてるってんなら、セクション番号で示してもらえる？
それができないなら、何を根拠に「規格で」とか「標準で」とか言ってるわけ？

ちなみに、↓を検索しても auto_ptr はひとつもヒットしないよ。
ttp://www.kuzbass.ru/docs/isocpp/lib-containers.html
0667625NGNG
>665
オレはこうだけど……

//離れた場所で使用する場合
FILE* p_input_file

//local scopeのみ
FILE* ipt

……まあ、ファイルポインタは普通ポインタしか使わないから
プリフィックスはどうでもいいけど。
0668デフォルトの名無しさんNGNG
fclose(ipt);
どうにも、糞コード確定のような・・・。
0669625NGNG
>667
つながらん……
ちなみに根拠は「C++標準ライブラリ チュートリアル＆リファレンス」
と「Effective STL」ね。
ANSIはどっかに行っちまったので確認できないや
0670デフォルトの名無しさんNGNG
>>659
エスパーじゃないから、お前の糞具合もわからないって寸法だ。

>>667
FILE*はfpだろうが。えっ、違う？
0671デフォルトの名無しさんNGNG
俺だったらfpInputかpInputFileだな。
0672デフォルトの名無しさんNGNG
俺だったら
infp
outfp
0673デフォルトの名無しさんNGNG
625はウンコだな
0674625NGNG
>666
自己フォロー。
COAPについて記載されているのは20.4.5の注釈のようですな。
ANSIがみつかっていないので正確かわからないけど

auto_ptr does not meet the CopyConstructible and
Assignable requirements for Standard Library container
elements and thus instantiating a Standard Library
container with an auto_ptr results in undefined behavior.

"禁止"じゃなくて"未定義"か……確かに字面だけなら662の内容の
方が近いかな？

ただ、C++の"未定義"は"禁止"とほぼ同じだと思うけどね。
＃単に安全装置が付いてないだけ。
0675デフォルトの名無しさんNGNG
ウンコは放置しよう。
0676デフォルトの名無しさんNGNG
>>674
ハゲしくスレちがい。>>666みたいなウンコは放置してくれ。
0677デフォルトの名無しさんNGNG
↑うんこはお前だ
0678デフォルトの名無しさんNGNG
>>553 への化石レス

今やってる仕事、ソースの１行に対してコメントは１行「以上」が規約なので
あなたの大学の教授が言ってる事は常識的ではありませんね。

ちなみに、例えばソース 3500行。うち、空行とコメント行 2300行。
書いてる自分で言うのも何だが、こんな読みづらいソースは初めてだよ orz


関数を呼び出すたびに「関数名、引数、戻り値」を全部コメントつけなきゃならんから、
引数が３つある関数を呼ぶだけで、既にコメントは５行になるからな・・・
0679デフォルトの名無しさんNGNG
>>678
常識的でないというより、生産的ではない
でも、学生にはそのくらいでいい。
それと、
いろいろあって、今の君の会社で今のルールがあるんだと思う
無駄だと思うなら、君が上司になった時とりやめてしまえばいい。

0680デフォルトの名無しさんNGNG
http://pc.2ch.net/tech/kako/1012/10127/1012715148.html
0681678NGNG
派遣の漏れにそんな権限はねーよ
0682r05/02/10 01:17:11
「strncpyする前に、コピー先のメモリブロックを
　memsetで'\0'で埋める必要は無い。」
という規則を作りたい。本当に作りたい。
0683デフォルトの名無しさん05/02/10 01:24:59
>>682
もっと広く「意味のない memset をするな」のほうがいいだろう。
0684デフォルトの名無しさん05/02/10 02:39:16
>682,683
strncpyは '\0' を付けてくれない事があるから、全くの無意味ではない。
無駄ではあるけどさ。
0685デフォルトの名無しさん05/02/10 22:43:44
If the string pointed to by SRC is shorter
than LENGTH characters, null characters are appended to the destina-
tion array until a total of LENGTH characters have been written.
だよ。
0686デフォルトの名無しさん2005/05/21(土) 09:42:44
longerな場合に付けてくれないだろ
0687デフォルトの名無しさん2005/06/26(日) 01:37:42
列挙値などの定数をすべて大文字のスタイルにすることの是非を教えてください。
+ ソース中で定数であることがわかると読みやすい（値について文脈を無視できる）
- 名前空間（クラス名）の修辞と組み合わせると汚い（例： File::READ_ONLY ）
- マクロと区別できない（「全て大文字はマクロのみ」というルールと比較した場合）

是非を確定するまで行かなくても、↑で挙げた +/- についての突っ込みや
+/- の追加でもあれば、お願いします。
0688デフォルトの名無しさん2005/06/26(日) 14:20:35
>>687
非。大文字だと
-入力しづらい
0689デフォルトの名無しさん2005/06/26(日) 16:22:02
>>688
わはは。じゃぁ定数に限らず全部大文字にしたほうがいいな。
06906882005/06/26(日) 16:52:40
>>689
日本語は読めていますか？ﾏｼﾞﾚｽのつもりだったんだけど。

>>687
各識別子が定数定義マクロであるか否かの判別に全部大文字を使うのはenumのなかったころのCの慣習だ
全部大文字の識別子なら定数定義マクロであるとすぐにわかったのだ。
だからと言って列挙値定数も全部大文字にしてしまうと、
全部大文字の識別子が列挙値定数か定数定義マクロかの判別が、すぐにはつかなくなる。
定数であることをすぐにわかるようにするための方法としては識別子の命名工夫のほうがbetterだろう

非。大文字だと
-読み辛い
0691デフォルトの名無しさん2005/06/26(日) 20:41:57
> 全部大文字の識別子が列挙値定数か定数定義マクロかの判別が、すぐにはつかなくなる。
判別する意味があるのか？
> 定数であることをすぐにわかるようにするための方法としては識別子の命名工夫のほうがbetterだろう
では何故定数定義マクロの時にこうしなかったのか？
06926882005/06/26(日) 21:02:10
>>691
まともな反論を、ありがとう
>> 全部大文字の識別子が列挙値定数か定数定義マクロかの判別が、すぐにはつかなくなる。
>判別する意味があるのか？
意味があるのか無いかは、わからない。ただ「無い」と断言するだけの背景もない。
>> 定数であることをすぐにわかるようにするための方法としては識別子の命名工夫のほうがbetterだろう
>では何故定数定義マクロの時にこうしなかったのか？
知りません。単に慣習だと思いますが。
列挙型というものは本来のCには無かったということを考えてみて下さい

「ありそうだな」と考えていた反論が来て面白い。
貴方は全大文字にすべきだと考えているの？
0693デフォルトの名無しさん2005/06/26(日) 22:01:28
Cにenumすら無かったことがあるのか。知らなかった。
0694デフォルトの名無しさん2005/06/26(日) 22:03:23
だから今でもenumはいまいち多用されていない感がある。
0695デフォルトの名無しさん2005/06/26(日) 22:47:04
プロトタイプ宣言も無かったが多用されてるよ。
enumが多用されてないのはそれほど使いどころが無いか、明らかな利点がないか
じゃない？
0696デフォルトの名無しさん2005/06/26(日) 23:24:23
>>692
> 知りません。単に慣習だと思いますが。
> 列挙型というものは本来のCには無かったということを考えてみて下さい
「列挙型」が無いとしても「定数定義マクロ」で「命名工夫」はできるだろ。
「慣習」で大文字だけになったんだろ？
「列挙型があるかないか」と「命名工夫をしなかったこと」には何の因果関係も無い。
君プログラマに向いてないよ。
0697デフォルトの名無しさん2005/06/26(日) 23:34:14
ただ今の決まり手：秘技「君プログラマに向いてないよ。」切り
0698デフォルトの名無しさん2005/06/26(日) 23:37:46
enumが多用されてない理由を考えてみた。
- int型と同じサイズになってしまう。(c++では改善されてるが)
- constにした方がｳﾏｰ
- ソースの外部で定義できない。
- マクロの条件式で使えない
- grepで検索できない。
0699デフォルトの名無しさん2005/06/26(日) 23:39:27
>>696
「マクロを作ったけどコード上では変数か定数かすぐにはわかんないな」
「シンプルな言語仕様にしたのに言語仕様の追加なんぞしたく無いぞ」
「じゃあ変数は今までのとおり全部小文字、定数は全部大文字という習慣にしよう」
「いい考えだ。俺たちがこれから全部そうすれば、みんな真似するだろう」
0700デフォルトの名無しさん2005/06/26(日) 23:41:33
Cではconstは定数として使えないからenumの方がこの点では勝ると俺は思うのだがなぜか使われていない。
Windowsのウィンドウメッセージも#defineが使われている。連番になっているのだからenumのはまり役だと思うのだが。
07016882005/06/27(月) 00:08:21
>>696
>「列挙型があるかないか」と「命名工夫をしなかったこと」には何の因果関係も無い。
因果関係なんぞはもちろんありませんよ。
当然の事ながら命名工夫というのはコーディング規約レベルの話です。
そして「定数定義マクロを全部大文字にする」というのは命名工夫の一種ではあるのですが、
また慣習であってこれはコーディング規約に優先します。
私は「後から出来た列挙型定数における命名工夫として、
既存の定数定義マクロと同一の命名工夫を使用するのは反対です」
と言っているだけ。
貴方の主張が読み取れません
「定数定義マクロを全部大文字にするというのが気に入らない」では無いですよね？
ご自分の主張を>>687に対してレスしてみたらいかがですか。

>君プログラマに向いてないよ。
もう手遅れですが
0702デフォルトの名無しさん2005/06/27(月) 01:08:58
列挙型が最初からあったとしたら全大文字にはならなかったとでも？
0703デフォルトの名無しさん2005/06/27(月) 01:29:48
>700
ウィンドウメッセージの値は複数のヘッダに分散して定義されてるから、
enumは向いてないような。
0704デフォルトの名無しさん2005/06/27(月) 01:45:28
>>701
>私は「後から出来た列挙型定数における命名工夫として、
>既存の定数定義マクロと同一の命名工夫を使用するのは反対です」

俺は「変数と区別しやすい」という方を優先したいな。
逆に定数マクロと列挙型の区別がしにくいとしてもさほど不便を感じない。
定数マクロと区別したいケースってのを例示してもらえばわかりやすいのだが。
0705デフォルトの名無しさん2005/06/27(月) 01:48:04
>>704
>俺は「変数と区別しやすい」という方を優先したいな。
俺漏れも
07067012005/06/29(水) 11:31:48
>>704
レスをありがとう
>俺は「変数と区別しやすい」という方を優先したいな。
>逆に定数マクロと列挙型の区別がしにくいとしてもさほど不便を感じない。
>定数マクロと区別したいケースってのを例示してもらえばわかりやすいのだが。
はい。それはそれで一つの見識だと思います。ただ
「マクロで定義できるのは整定数だけではない」という問題がありますね。
列挙型の場合は整定数ですが。
これについてはどうでしょうか
0707デフォルトの名無しさん2005/06/29(水) 21:17:19
静定数以外のマクロを許したら、どんな立派なコーディング規約を
作っても台無しだと思うが。

>>701のコーディング規約がどんなものか、一度見てみたいな。
＃マクロの名称規則ひとつに静的/動的の別、影響範囲とか、
＃事細かに規定しているんだろうか。
0708デフォルトの名無しさん2005/06/29(水) 23:41:06
>>707
整定数って、整数型の定数ってことだろ。
整定数以外のマクロって許すも何も、
FLT_MAX とか NULL とか offsetof とか標準にも山ほどあるんじゃないの？
0709デフォルトの名無しさん2005/06/30(木) 00:18:58
>>706
> 「マクロで定義できるのは整定数だけではない」という問題がありますね。
それからどうやって「整定数を全大文字で書くべきではない」に繋がるのかが分からない。
0710デフォルトの名無しさん2005/06/30(木) 00:30:18
>>708
おお、読み間違えていた。
でもそれだとますます意味がわからんな。
int型の値を持つマクロとfloat型の値を持つマクロがあるからといって
どうだというんだろう？
0711デフォルトの名無しさん2005/06/30(木) 00:35:32
>>709
定数を区別するために全大文字の名前を使うということは、
全大文字の名前を見たらそれは定数であると期待できる、
ということになるだろう。

その環境で、定数ではないマクロが全大文字で定義されていたら、
読み手に誤解を与える可能性が、、、、、あるかなぁ？
0712デフォルトの名無しさん2005/06/30(木) 21:24:19
>>711
> >>709
> 定数を区別するために全大文字の名前を使うということは、
> 全大文字の名前を見たらそれは定数であると期待できる、
> ということになるだろう。
そう。それが全大文字で書かれている理由じゃないのかね。

だから>>690にあるように
> 定数であることをすぐにわかるようにするための方法としては識別子の命名工夫のほうがbetterだろう
とすると↓のようはコードになるんだろうが、これが読みやすいとは到底思えないのだ。

int row = 3;
if (row > const_max_row) {
　　// error
}
0713デフォルトの名無しさん2005/06/30(木) 21:25:00
-↓のようは
+↓のような
0714デフォルトの名無しさん2005/07/03(日) 17:15:26
要は#defineであろうがなんであろうが
・定数は全大文字
ってことだろ。
逆に、#defineであっても
・定数でなければ全大文字にしない
だろ。
errnoグローバル変数なんて#defineだったりするんだが、
それでも明らかに定数では無く変数として扱っているから
全大文字にしない。
0715デフォルトの名無しさん2005/07/03(日) 17:24:30
>>714
関数型マクロはどうする？
C++ で Class::CONSTANT や Namespace::CONSTANT はOK？
0716デフォルトの名無しさん2005/07/03(日) 18:29:43
>関数型マクロはどうする？

普通は使わんな。
どうしても使う必要がある場合は、完全に関数として振舞うマクロとして作成し、
関数の名称規則に従う。要は定数か変数か関数か、その振る舞いに対して
名称規則を適用するということ。
マクロのような変幻自在のものをひとくくりにした名称規則を作っても意味がない。
0717デフォルトの名無しさん2005/07/03(日) 21:48:50
>>715
716も言ってるように、関数として扱うのだから関数の命名規約に沿うべき。
マクロかどうかを区別できないとか言ってる香具師はこれが分かってない。
0718デフォルトの名無しさん2005/07/03(日) 22:42:06
「引数付きマクロを関数として扱う」って
本当には関数に出来ない理由があるからじゃないの？
0719デフォルトの名無しさん2005/07/03(日) 23:22:53
型チェックとか引数の評価の違いとか、見かけ上構文は関数と同じでも
マクロだと気をつけなきゃいけない点があるから、関数型マクロといっても
むしろ関数の命名規則より、それが関数じゃなくてマクロだとわかる規則に
従った方がいいと思う。
0720デフォルトの名無しさん2005/07/04(月) 00:11:48
#include <ctype.h>のisXXXX(c)なんてマクロなんだが。
errnoもグローバル変数に見えて実は関数だったりする。

普通は使わんな、てなことは無い。
0721デフォルトの名無しさん2005/07/04(月) 00:40:01
>>719
> マクロだと気をつけなきゃいけない点があるから
getc, getchar, putc, putcharを使う時に何に気を付けてる？マジレスキボン
0722デフォルトの名無しさん2005/07/04(月) 00:58:10
> getc, getchar, putc, putcharを使う時に何に気を付けてる？
たとえばgetcなら、引数に副作用のある式を渡すときは気をつかうよね。
fgetcだとそんなこと気にしなくていい。
0723デフォルトの名無しさん2005/07/04(月) 01:43:54
>>719
その通り。何も考えずにマクロを使うと「一見関数のように見えるけど実は...」
というケースが頻出して管理しきれなくなる。
そういう事態を避けるために多少コーディングの自由度を制限してでも
管理性/保守性を上げようというのがコーディング規約だろう。

マクロの自由度を生かしながらきちんとした規約を定めようとしたら、相当
複雑なものになると思うが。俺はそこまでして定数マクロ以外のマクロを
使用するメリットってのはわからないから、さくっと禁止だね。

>>719の規約では、有名なBEGINマクロみたいなのは許されるの？
許されないとしたら、使っていいマクロとそうでないマクロを切り分ける
基準は何？
0724デフォルトの名無しさん2005/07/04(月) 02:18:23
>>723
保守性はまだしも。管理性ってなんですか？
「管理性」の一般的な語義として「把握する」というのがありますが。
「管理する対象」と「管理する目的」が全くわからない。
ｽﾚﾀｲそのものの存在理由に関わる問題だと思うので回答請う
0725デフォルトの名無しさん2005/07/04(月) 03:18:42
> 保守性はまだしも。管理性ってなんですか？
723じゃないけど、manageabilityってことでは？
0726デフォルトの名無しさん2005/07/04(月) 11:45:49
アレだよ
関数いっこ、変数いっこ作るのに
上に申請して
受理されて
振番してもらって
やっと使えるヤツ
07277242005/07/04(月) 11:56:24
>>725
manageabilityですか。なおさらわからなくなります。
その言葉はOS運用、ﾕｰｻﾞ、電源、ｾｷｭﾘﾃｨなどに使用されますが、この場合は管理対象が曖昧です。
ソフト生産について沢山の開発組織体がそれぞれの取り組みを行なっている現状下において、
ソースコードの管理単位として「いわゆる関数」という粒度にとどまらず、さらに細粒度の管理を行なう傾向があります。
ファイル名／関数／関数名にとどまらず、インクルードファイル／マクロ／マクロ名／変数／変数名
なども（多くの場合DB化して）管理するのです。管理の粒度についての私見は差し控えますが、
「ｺｰﾃﾞｨﾝｸﾞ規約の目的として管理性を付加するのは、
その種の取り組みを行なっている組織だけでの事ではないのか」と思う次第。
ｺｰﾃﾞｨﾝｸﾞ規約の存在目的自体の認識がずれていると議論も混乱すると思うので、
あえて>>724で質問／確認してみたのです。

>>726
そういう運用をしているところもあるでしょうねｗ
0728デフォルトの名無しさん2005/07/05(火) 01:26:01
>>722
> たとえばgetcなら、引数に副作用のある式を渡すときは気をつかうよね。
どういうこと？具体的に副作用が出る式を書いて見てくれない？
07297232005/07/05(火) 01:42:45
>>727
「『管理性』という言葉」に対する認識はずれているようだな。そういう大仕掛けで
仰々しいものだけが「管理」だという思い込みがあるのかな？
>>723に書いたのは保守性とほぼ同義だと思ってもらっていいよ。目的が保守に
限定されるわけじゃないからああ書いただけで。
07307242005/07/05(火) 10:44:23
>>729
了解しました。ありがとう御座いました。
決してイチャモンをつけるつもりで質問したわけではない事をご理解下さい
0731デフォルトの名無しさん2005/07/05(火) 22:14:09
>>728
*p++
0732デフォルトの名無しさん2005/07/06(水) 00:41:14
そんなのgetcの引数で使うか? putcならまだしも
0733デフォルトの名無しさん2005/07/06(水) 01:04:06
FILE *f[10]
とか？
0734デフォルトの名無しさん2005/07/06(水) 02:09:48
>>731
それでホントに副作用出るのか？
0735デフォルトの名無しさん2005/07/06(水) 07:17:17
*pの値が変わる、というのは副作用だよ
0736デフォルトの名無しさん2005/07/06(水) 08:32:18
関数呼び出しも副作用だよ。
例えば
FILE *getdatafile() {
　static FILE *datafile = fopen(...); //C++だけど
　return datafile;
}
で、getc(getdatafile()); とか。

まあ、実際にこんな使われ方されることはまず無いとは思うけど
絶対にないという程ではないんじゃないかな。
0737デフォルトの名無しさん2005/07/06(水) 22:42:58
>>735
getcが関数だと変わらないの？
0738デフォルトの名無しさん2005/07/07(木) 00:04:09
>>737

.....まず「副作用」の意味から調べてきな。
薬の副作用とは違うから。
0739デフォルトの名無しさん2005/07/07(木) 00:44:29
>>738
...まず規格によってマクロで実装されているとされているものについて調べてきな。
0740デフォルトの名無しさん2005/07/07(木) 00:45:13
誤：実装されていると
正：実装すると
0741デフォルトの名無しさん2005/07/07(木) 04:14:41
>>739
たとえばglibcのmanだと
getc() is equivalent to fgetc() except that it may be implemented as a
macro which evaluates stream more than once.
となってる。手元にあるどっかから拾ってきた規格のドラフトだと
The getc function is equivalent to fgetc, except that if it is
implemented as a macro, it may evaluate stream more than once, so
the argument should never be an expression with side effects.
とまで明記されてる。
0742デフォルトの名無しさん2005/07/09(土) 13:45:28
「全部大文字」で思い出したけどマイクロソフトっていろんなものを
全部大文字にしてるよね。あれを不愉快に思うのは俺だけ？
0743デフォルトの名無しさん2005/07/09(土) 23:10:56
たとえば？
0744デフォルトの名無しさん2005/07/09(土) 23:30:19
たぶんVOIDとかのことだろう
0745デフォルトの名無しさん2005/07/11(月) 01:04:33
BOOLとかUINTとか
あれ何でなんだろうね
0746デフォルトの名無しさん2005/07/11(月) 08:15:19
>>745
マクロだからだろ。
0747デフォルトの名無しさん2005/07/11(月) 16:56:39
>>745-746
ちゃんとtypedefを使っている。
0748デフォルトの名無しさん2005/07/12(火) 22:45:12
もとはマクロだったとか
0749デフォルトの名無しさん2005/07/13(水) 01:42:25
Java方式の関数名の最初に小文字を使うメリットって何かありますか？
0750デフォルトの名無しさん2005/07/13(水) 06:47:54
>>749
Javaなら、Java方式であるということ自体がメリットになるんだろうな。
C++とかの他の言語でやるメリットはわかんね。
0751デフォルトの名無しさん2005/07/13(水) 08:10:07
C++でもコードの見た目が柔和になる気がする。主観だけど。
0752デフォルトの名無しさん2005/07/22(金) 23:41:11
｢prefix｣って
　｢プレフィックス｣なのか｢プリフィックス｣なのか気になったので
gooで調べてみた。
　俺には｢プリセックス｣としか聞えなかった。orz
0753デフォルトの名無しさん2005/07/23(土) 04:08:15
Winアプリ作ってきた俺でもハンガリアンだけは受付ねー。
命名規則に言語依存の意味をくっつけるな。
pDataとかもいらん。ポインタのvectorとかだとdata[0]->xとか結局
pとか付いてないのに->アクセスになるし。
だったら変数名はGNUの規則でいいや。
0754デフォルトの名無しさん2005/07/23(土) 04:23:41
変数名はおいといてGNUの{}のつけ方はいただけない。
0755デフォルトの名無しさん2005/07/23(土) 04:43:23
BOOL GetQueuedCompletionStatus（
　HANDLE CompletionPort,　// I/O 完了ポート
　LPDWORD lpNumberOfBytesTransferred,
　　　　　// I/O 操作中に転送されたバイト数を
　　　　　// 受け取る
　LPDWORD lpCompletionKey,　　// ファイルの完了キーを受け取る
　LPOVERLAPPED *lpOverlapped,　// OVERLAPPED 構造体への
　　　　　// ポインタを受け取る
　DWORD dwMilliseconds　　　// オプションのタイムアウト値
);

なんだよこのLPOVERLAPPED *lpOverlappedという表記は。
0756デフォルトの名無しさん2005/07/25(月) 22:35:37
BOOLを大文字にするな！
なんでCompletionPortはハンガリアンじゃないんだ？
もうね、pとかlpとか付けなくていいよ、ウザイから。
0757デフォルトの名無しさん2005/07/26(火) 20:55:16
もともとのNTの命名規約はハンガリアンじゃないんだよな
Win16の亡霊がこんなことろにも
0758デフォルトの名無しさん2005/10/20(木) 09:10:44
>>752
プリンセスとｾｸｰｽ!!
0759デフォルトの名無しさん2005/12/20(火) 07:21:55
http://www.possibility.com/Cpp/CppCodingStandard.html
0760デフォルトの名無しさん2005/12/29(木) 01:18:48
int aSex[10];
vector<int> vSox;

void Test(int x,int y)
{
　　int i,j,k;
　　if(j)
　　{
　　　　int six[100];
　　　　int* p = &x;;
　　}
}

0761笹井奈琴2006/01/07(土) 07:17:42
たとえば if とかの書き方を

if (0<a) {

って、()の外側に空白を置くように決めてる規約が結構あるよね。
これって見やすいのかなー？
()の内側の方がずーっと見やすいと思うな。

if( 0<a ) {

だって、関数呼び出しとかは、

foo (a,b) ;

って書かないでそ？
0762デフォルトの名無しさん2006/01/07(土) 09:56:15
>>761
括弧の内側に空白を置かないのは一般的な英文がそうなっているから。
ifと(の間に括弧をあけるのは関数呼び出しと違いを際立たせるため。
0763デフォルトの名無しさん2006/01/07(土) 11:04:03
といっても、関数呼び出しと勘違いするようなアホはたまにしかいないから面倒だなと思う。
たまにいるからやむを得ないんだろうけど。
0764デフォルトの名無しさん2006/01/07(土) 13:33:04
ずっと if(0 < a) だったんだけど、
Visual C# 2005 のエディタが
if (0 < a) に訂正しやがるから、最近は自分のこれになってきた。
0765デフォルトの名無しさん2006/01/09(月) 22:57:14
キーワードの後ろの ( はスペースを1個、関数呼び出しは詰める、だね。
理由は>>763らしいけど。

問題はキーワードでも関数呼び出しでもない sizeof 演算子をどうするかだ。
括弧つけない？
0766デフォルトの名無しさん2006/01/10(火) 15:06:01
つける必要がある場合はつけて、つける必要がない場合はつけない
0767デフォルトの名無しさん2006/01/10(火) 21:19:47
>>766
話題はsizeofと括弧の間にスペースを入れるか入れないか、ではないのか？
0768デフォルトの名無しさん2006/01/12(木) 00:34:05
括弧がある場合は付けなくて
ない場合は付ける(というか付けないとコンパイルエラーになるから
スタイルの問題ではないか)
0769デフォルトの名無しさん2006/01/15(日) 23:07:10
>>765
sizeofはキーワードだろ。
俺はsizeofの後には空白を開ける。
0770デフォルトの名無しさん2006/01/21(土) 23:45:10
演算子であり、キーワードである
0771デフォルトの名無しさん2006/01/22(日) 16:35:45
sizeofは括弧を詰めて記述していた俺は間違っていたのくぁっ！
0772デフォルトの名無しさん2006/01/22(日) 17:34:11
好きに汁
0773デフォルトの名無しさん2006/02/05(日) 03:01:07
ほｓｙ
0774デフォルトの名無しさん2006/02/05(日) 16:13:12
array→ary 、manager→mgr など、3文字の英語で表す際の
規約みたいなものが書いてあるサイトってありますか？
ググっても見つからなくて。。
manage→mng なのに manager→mgr とか理解不能です（汗
0775デフォルトの名無しさん2006/02/05(日) 16:32:02
>>774
そんな化石のようなルールが本当に今必要なのか？
たいした理由も無ければ array, manager とフルで綴れ。
0776デフォルトの名無しさん2006/02/05(日) 16:48:09
>>775
Webアプリ開発でURLを短くしたいので、知りたかったのです。
例えば、コーディング規約は遵守しているのに
master→mtr とか間違えて命名してたら格好悪いなぁと思いまして。。
0777デフォルトの名無しさん2006/02/05(日) 17:19:01
>>776
Web アプリの URL はユーザーが使うんだから、
コーディングの規約じゃなくてアプリの仕様として考えるべきじゃないの？
0778デフォルトの名無しさん2006/02/05(日) 17:28:53
言葉の綾でしょうが、ソース内の変数名でも間違えたら恥ずかしい、
URLについては色んな意味（GETメソッドは255バイトまでなので短くしたい等）
で調べたい、それだけです。
0779デフォルトの名無しさん2006/02/05(日) 17:56:47
>>778
> GETメソッドは255バイトまでなので短くしたい
これ、本当？何の仕様？
フルで綴れよ。間違えようも無いし。
0780デフォルトの名無しさん2006/02/05(日) 18:18:57
IE6だと498バイトだな
07817742006/02/05(日) 18:32:54
>>780
IE6に限定しないなら255が一般的かと。

>>775-779(780に対してではないです)
貴方も分からないのであれば変に突っ掛ってこないで下さいね。
他で尋ねます。では。
0782デフォルトの名無しさん2006/02/05(日) 20:23:13
個人的には変数名はフルで綴るより短い方がいいかな
長いとエディタを横スクロールさせないといけないことが多くなるし
たまにある20文字以上の変数名(クラス名)とか勘弁して欲しい
0783デフォルトの名無しさん2006/02/05(日) 20:46:51
短い名前は大いに結構だが、短くした名前は混乱の元。
0784デフォルトの名無しさん2006/02/05(日) 21:09:54
きちんとコメント入れとけば混乱することは無い
0785デフォルトの名無しさん2006/02/05(日) 21:53:23
manager が mng になったり mgr になったり man になったり
そういう混乱はきちんとコメントを入れても避けられない。
0786デフォルトの名無しさん2006/02/05(日) 21:56:57
そのためのコーディング規約だろう。
規約が守られなかったらってのはまた別の話。
0787デフォルトの名無しさん2006/02/05(日) 22:02:01
きちんとした命名規約があるなら
短くした方がいいよ
規約があるのか知らんが
0788デフォルトの名無しさん2006/02/05(日) 22:11:09
規約ウザイからなるべく増やしたくないんだ。
だいたい省略のルールなんて文書に起こそうと思ったら大変だろ？
（大げさな話、チェックもできるようにしようと思ったらもっと大変だろ？）

フルスペルのがいいと思うんだけどなぁ。
短くしたメリットや、古スペルにしたときのデメリットなんて、
ほんとのところ深刻な奴は無いんじゃないか？
0789デフォルトの名無しさん2006/02/05(日) 22:12:44
>>782
20 文字程度で長いですか？
VGA で開発してます？
0790デフォルトの名無しさん2006/02/05(日) 22:17:37
２０文字っていうと lexicographical_compare() とかでもアウトか。
C++ 使うのは辛そうだな。
07917822006/02/05(日) 22:23:35
ミスです 20文字じゃなくて30文字です
20文字なら超えてること結構ある(´ρ｀)
0792デフォルトの名無しさん2006/02/10(金) 22:39:59
俺がつけた一番長い関数名は、55文字
ちなみに趣味じゃなくて、仕事で、ちゃんと出荷もした
コーディング規約もコードレビューも無かったからな
0793デフォルトの名無しさん2006/02/16(木) 15:46:12
COBOLは文字制限あったな。
名前空間がないと結構つらいかも。
0794デフォルトの名無しさん2006/03/07(火) 00:12:13
前カンマ派なんだけど、
みんなはカンマどっちにつける？

こーゆーの
select id, name

select
    id
    ,name
0795デフォルトの名無しさん2006/03/07(火) 00:17:03
二項演算子で行を区切るときは、式の継続が目立つように行頭に演算子が来るようにしている。
その流れで、カンマで行を区切るときも行頭に来るようにしている。
0796デフォルトの名無しさん2006/03/07(火) 09:59:24
頭を揃えたいがために演算子は行末にぶら下げてた
0797デフォルトの名無しさん2006/03/07(火) 20:39:30
カンマは前派だなあ。
行末だと、なんか目がちらつく感じがする。

#SQLのインデントは結構迷う。
0798デフォルトの名無しさん2006/03/08(水) 08:52:35
俺も今日から行頭にしよう
0799デフォルトの名無しさん2006/03/10(金) 01:04:18
詳細設計書作るときに気をつけてることある？
こんなん気をつけてるけど、
・書式、文言の統一
・同一処理は参照で
0800デフォルトの名無しさん2006/03/10(金) 11:47:25
具体的かつすぐに理解できるように気をつけてる
0801デフォルトの名無しさん2006/03/12(日) 23:17:13
コメントいっぱい埋め込んでツール一発OK
0802デフォルトの名無しさん2006/03/12(日) 23:19:31
>>801
それは、情報量だけ多くて本質的なところが見えない悪い仕様書の例。
doxygenで何でもかんでもYESにしてドキュメント吐かせるとよくわかる。
0803デフォルトの名無しさん2006/03/12(日) 23:27:54
詳細設計がどのレベルをさしているのかマチマチだけど
コードに近いものなら、そんなドキュメントいらんよ。
その上の機能設計がしっかりしていれば、それでいい。
0804デフォルトの名無しさん2006/03/18(土) 20:20:19
1年前くらいにやった仕事の命名規則

関数名： u1g_PRODN_MOD_SMOD_GetCnt_pstu2

u1g … 戻り値=unsigned char, グローバル関数
PRODN … 製品名
MOD … モジュール名
SMOD … サブモジュール名
GetCnt … 本当の関数名 (各単語は3文字略称で)
pstu2 … 引数が (構造体へのポインタ, unsigned short)
関数名は31文字以内死守

もちろんどんな関数名も30文字近くになるし
同一ファイル中に出てくる関数名は同じ文字列が含まれる
限界近くになると真っ先に本当の関数名の部分をなんとか短くして我慢

pu1とかpstu1とかの型情報は、化石と思われているようだけど
Cでは型の間違いとか暗黙の変換とかがバグを引き起こすからね
読みづらくはなるが、潜在バグを減らすためには不可欠

これが日本の組み込みソフトの品質を保つ……本当か？
0805http://www.vector.co.jp/soft/win95/util/se072729.html2006/03/18(土) 21:06:42
TextSS　のWindowsXP(Professional)64bit化おながいします

もしくは64bitにネイティブ対応したテキスト置換ソフトありますか？

そういや64bitにネイティブ対応している２ｃｈブラウザてありましたっけ？

0806デフォルトの名無しさん2006/03/18(土) 21:51:48
>804
名前のマングリングを人が、人のためにやってるのか…
0807デフォルトの名無しさん2006/03/19(日) 01:10:36
>806
( ･∀･)つ〃∩ へぇーへぇーへぇー
マングリング
コンパイラは関数に装飾された名前（以下、装飾名）を作成します。
リンカは装飾名を使って、別ファイルにある関数や変数を参照します。
関数を正しく呼び出すのに、関数名だけでは不十分な場合があり、
名前を装飾することをマングリング（mangling）と呼びます。
0808デフォルトの名無しさん2006/03/19(日) 01:21:45
"static"使うときってどんなとき？
今まで"static"って複数ユーザで
使いまわすモノだと思ってた...

こーゆー時は"static"使うと便利だよとか、
ここは使うしかないっしょ！！ってのある？

今はsingletonパターン使うときくらいしか使ってない
こーゆーの
private static singleton;

if (singleton == null) {
this.singleton = new Class();
return this.singleton;
}

return this.singleton;
0809デフォルトの名無しさん2006/03/19(日) 01:23:23
>>808
意味がわかっていればそんな疑問も湧かないはずなんだが。
0810デフォルトの名無しさん2006/03/19(日) 16:17:57
>>809
同意。

>>808
singleton なクラスにだけ使っとけ。
0811デフォルトの名無しさん2006/03/19(日) 17:25:49
そもそもコーディング規約と関係ねぇ
0812デフォルトの名無しさん2006/03/19(日) 22:11:48
>>774
亀だが、
http://www.thefreedictionary.com/
の、Acronym に色々あるべ。

↑スペルミスがあると思うけど気にするな。
0813デフォルトの名無しさん2006/03/20(月) 02:14:05
Javaでいう”インスタンスメソッド／変数”と”クラスメソッド／変数”の区別は、
C++ ではstatic宣言の有無で区別するので強力ですよ。
Singleton用途でGlobalスコープにおく意図だけでstaticをつかっててはMOTTAINAI。
あ、Javaでも同じですか.... へんなことかいてたらすみません。
0814デフォルトの名無しさん2006/03/20(月) 07:06:36
>>808
意味的に 型で共有されるべき操作な時とか
Utilityクラス
あるクラスを定義したとき、そのNullオブジェクトとか定数とか
0815デフォルトの名無しさん2006/03/20(月) 12:47:06
>>811
いやいや、そういう使い方を定義する規約ってのも存在する。
0816デフォルトの名無しさん2006/03/21(火) 01:23:19
>>815
ちょ、「static就職子はSingletonパターンを実装する際にしか使用してはいけない」
とかいうコーディング規約あったらマジキレるぞ俺。C++にしろJavaにしろだ。
0817デフォルトの名無しさん2006/03/21(火) 01:24:21
ちょ、就職子てｗｗｗ
修飾子な
0818デフォルトの名無しさん2006/03/21(火) 04:24:28
>>817
>>816 は、「static 就職子は Singleton パターンを実装する際にしか使用してはいけない」の「就職子」の誤字にキレちゃうんじゃない？w
0819デフォルトの名無しさん2006/03/21(火) 18:00:35
>818
816と817は同一人物だろ。
0820デフォルトの名無しさん2006/03/29(水) 03:19:26
ヒロシです。dummy を dumy と略すのはやめて欲しいとです。
0821デフォルトの名無しさん2006/03/29(水) 10:27:04
ヒロシです。
getUserNameを、getUNとかに略すのやめてほしいとです。
メソッドの目的がさっぱりわかりません・・・('A`)
0822デフォルトの名無しさん2006/03/29(水) 17:43:11
>>821
国連をゲットするんでしょ。
0823デフォルトの名無しさん2006/04/07(金) 15:55:22
getUcchanNanchan
0824デフォルトの名無しさん2006/04/11(火) 23:50:34
将来、使われなくなると予想される　変数　Maxは
asMax とする
0825デフォルトの名無しさん2006/04/12(水) 09:19:22
東MAX！
0826デフォルトの名無しさん2006/04/12(水) 10:35:23
C++で、ストリーム演算子をクラスのfriendにする必要が無い場合、
ストリーム演算子の宣言はクラス定義の外に置くべきでしょうか。

外に置くと、クラスの利用者がヘッダを見た時に見落としそうな気がしています。
と言って、friendをつけたままだと、演算子のソースコードを見た時に違和感があります。
0827デフォルトの名無しさん2006/04/12(水) 10:48:20
Javaでコーディングしてるんだけど、
クラス変数や引数の宣言にこんなことやってる。
目的は、ソースの可読性を自分なりに向上させたいってところ。

クラス変数： mClassObject
　　　　　　　（先頭にmを付ける）

メソッドの引数：　stringArg_
　　　　　　　（末尾にアンダースコアを付ける）

他に、どんなやりかたあるのかな？
0828デフォルトの名無しさん2006/04/12(水) 11:11:35
>>826
外だな。別ファイルでもいいが。
もはやオブジェクト指向とはアンチパターンである
クラスをいかに使わないかだ
0829デフォルトの名無しさん2006/04/12(水) 11:14:55
>827
私は
クラス変数・インスタンス変数：Arg_
ローカル変数：arg
引数：Arg
です
あ，C++でした
0830デフォルトの名無しさん2006/04/12(水) 11:25:17
>>829
argの意味わかってる？
0831デフォルトの名無しさん2006/04/12(水) 11:56:45
>>829
なるほど。
javaだと変数名の先頭に大文字は推奨されないんで、
アンスコとかをうまく使おうかと思ってます。
0832デフォルトの名無しさん2006/04/12(水) 18:48:04
('A`)
0833デフォルトの名無しさん2006/04/12(水) 23:17:15
class
{
コンストラクタ
変数１
ゲタセタ
メソッド（）
メソッド（）
}
って、変ですか？
0834デフォルトの名無しさん2006/04/13(木) 00:41:37
>>833
はい、恋です
0835デフォルトの名無しさん2006/04/13(木) 03:43:51
>>833
・種類より public/private の区別を優先して並べて欲しい。
・「ゲタセタ」と「メソッド」を区別するのも意味なさげ。
　オブジェクトへの副作用有りと無しで分けてあると助かる。
0836デフォルトの名無しさん2006/04/13(木) 12:33:45
>830
ごめん，なんも考えずに書き込んだ
ﾊｽﾞｶｼｽ
0837デフォルトの名無しさん2006/04/15(土) 22:28:40
>>827
Javaのコーディング規約でいいんじゃない？
シンプルで利にかなっている。
0838デフォルトの名無しさん2006/04/16(日) 22:11:46
コーディング規約とは言えないかもしんないけど、
描画オブジェクトに表示プライオリティを付ける場合、
値の大きいほうと小さいほう、どちらを手前に表示させるべきですか？
0839デフォルトの名無しさん2006/04/16(日) 23:21:01
>>838
何が目的か、による。
例えば、WindowsのウィンドウのZオーダーは、0が最前面。
これは、ウィンドウを、ほかのウィンドウの後ろに持って行くよりは、
手前に持って行くことの方が多いだろうということから、
とりあえず、0を設定しておけば目的を達成できるだろうという考えだな。
08408382006/04/17(月) 00:19:12
特に定番があるわけじゃないんですね。
ゲームでのオブジェクトなのですが、
WindowsのZオーダーを踏襲しときます。ありがとうございました。
0841デフォルトの名無しさん2006/04/17(月) 14:05:56
>828 遅くなってすみません。ありがとうございます。
別ファイルでがんばってみます。
0842デフォルトの名無しさん2006/08/21(月) 23:39:10
不要になったコードをコメントアウトしていつまでも残しておくな
と主張している本があったと思うのですが、
何の本だったかわかる方いませんか？
プログラミング作法かコードコンプリートのような、けっこう
定番のものだったと思うのですが。
0843デフォルトの名無しさん2006/08/24(木) 11:07:10
>>842
CVSとか使ってコード管理していると、
その手のコメントアウトがどれだけ残す意味のないものか良くわかる。
0844デフォルトの名無しさん2006/08/24(木) 17:07:25
>>842
一例: MISRA
なぜか#if 0は禁止していない。
0845デフォルトの名無しさん2006/08/25(金) 01:00:53
関数のヘッダや関数内部に更新履歴を残すのってどうよ？
これも美的感覚としては受け入れたくないけど、
ちゃんと書いてあればけっこう助かる気がする。
いったん「どう変更されたんだ？」と疑問に思ってから
csv logやannotateする手間が省けるから。
0846デフォルトの名無しさん2006/08/25(金) 01:19:41
その更新履歴が絶対正しいならそれもありだろう。
だが、更新忘れたり、めんどくさくてやらなくなったりして放置されたコメントならHDDの肥やしに過ぎない。
0847デフォルトの名無しさん2006/08/25(金) 09:41:08
履歴はワードの履歴機能使うのはどうかね？ｗ
コンパイルの際はちょっと工夫がいるが
0848デフォルトの名無しさん2006/08/26(土) 15:12:48
ワードの履歴はコミットしたら消えちゃうし
コミットしないと変更した場所をまた変更すると履歴が残らないので不可。
0849デフォルトの名無しさん2006/08/27(日) 01:32:00
>848
「ファイル」→「版の管理」→「文書を閉じる時に新しい版を自動的に保存する」
0850デフォルトの名無しさん2006/08/28(月) 17:09:09
だったらSVNでも使ったほうがずっとラクというオチに
0851デフォルトの名無しさん2006/09/02(土) 09:45:25
C/C++言語の関数の引数の順序についてのコーディング規約ってあるのかな

void foo( 出力、入力、入力 )と
void bar( 入力、入力、出力)の
どっちがいいんだろう。

memcpy()はfooのほうだけど、boostライブラリはbarみたいだ（あまりよく知らん）
0852デフォルトの名無しさん2006/09/02(土) 12:54:03
>>851
<algorithm>の関数も出力が後。
0853デフォルトの名無しさん2006/09/02(土) 20:08:08
>>852

STLのAlgorithm? copy関数は出力が後ろだね。
0854デフォルトの名無しさん2006/09/03(日) 09:37:34
ベル研のインデアン・ヒル・コーディング規則では前がよいということになっている。
http://www.gfd-dennou.org/arch/comptech/cstyle/cstyle-ja.htm
ちょっと古いかね。
0855デフォルトの名無しさん2006/09/10(日) 23:35:52
C++ の namespace の命名規則でお勧めありますか? 衝突しにくくする
工夫とか、気をつけたほうがよいところとか。疑似 URL で表現しろとか。
または、これはダメ、という例でも良いです。よろしくお願いします。
0856デフォルトの名無しさん2006/09/11(月) 08:41:16
>>855
ソースファイルのディレクトリ構造と一致させる。
0857デフォルトの名無しさん2006/09/11(月) 18:12:27
>>856
例えばこんな感じですか?
namespace fuga::include::MultiMethod
namespace fuga::src::TriState

ただ、ここまで深い階層をつける予定はないので、どちらかと言うと、
最上位の名前空間(↑で言うところの fuga)を定義する時のポイント、
すべきこと、すべきではないこと、工夫といったあたりでアドバイスが
頂けると嬉しいです。
0858デフォルトの名無しさん2006/09/11(月) 23:12:30
>>857
#include "fuga/include/MultiMethod.hpp"
とか書いてるならそうなる。
別件になるんだろうけど、ヘッダのパスに "include" が現れるのはクドイね。

単体での付け方に「名前空間だから」という手法は無いと思うよ。

あ、検証方法として、名前空間内の名前をグローバルから
全部読み上げてみて違和感がなければ OK とか。
0859デフォルトの名無しさん2006/09/11(月) 23:17:26
かぶらないことが目的だから
くどすぎるくらい長い方が安全かとも思う。
0860デフォルトの名無しさん2006/09/11(月) 23:55:19
>>858
include パスはコンパイラオプションで指定するので、実際には
#include "MutiMethod.h"
ですね。ライブラリを置く場所はユーザーの都合で変えられてしまう
こともあるから、あんまり物理的な位置に依存しないほうがいいのかな。
例えば、/usr/local/include にインストールされるヘッダなどは、この
手が使えないわけですよね。
0861デフォルトの名無しさん2006/09/12(火) 00:13:46
>>860
どこにインストールされるとしても、 #include で指定するパスと
namespace を対応させるってのが >>856 のルール。

namespace hoge で包んでるライブラリのヘッダを /usr/local/include に
インストールするとすれば、ヘッダはすべて /usr/local/include/hoge という
ディレクトリ以下に収める。
0862デフォルトの名無しさん2006/09/12(火) 01:44:31
>857
boost
0863デフォルトの名無しさん2006/09/13(水) 21:17:24
>>955
ググっても出てこないような言葉で
0864デフォルトの名無しさん2006/09/14(木) 14:17:01
期待してるぞ >>955
0865デフォルトの名無しさん2006/09/14(木) 14:39:49
>>955があまりの人気で失禁
0866デフォルトの名無しさん2006/10/13(金) 22:25:42
早く>>955さん来ないかなぁ。勃起しちゃいそう
0867デフォルトの名無しさん2006/10/30(月) 01:19:10
なにかデータを取得する関数のとき、
readHoge() にするか、 getHoge() にするかよく悩む。

誰か、「新感覚☆キーワードで英会話」みたいな感じで
readとgetのコアイメージを俺に教えてくれ
0868デフォルトの名無しさん2006/10/30(月) 01:20:26
getの反対語もよく悩む。 putがいいのかsetがいいのか
0869デフォルトの名無しさん2006/10/30(月) 02:01:18
>867,868
述語を何にすべきかは、主語で決まる。
迷ったらとりあえず意味の広いget/setが無難だと思われ。

…と英語が得意でもないのに答えてみる。
何か間違ってたら指摘よろ>ｴﾛｲ人
0870デフォルトの名無しさん2006/10/30(月) 06:21:33
Check、Count、Getも悩んでしまうな。
0871デフォルトの名無しさん2006/10/30(月) 11:21:14
java的な規約がなんとなく使いやすいんで、java式に合わせてるんだが
readはFileなりStreamなり、プログラム外からの読み込みに使ってる。
それ以外は、基本的にget/set。 値を保持するListとかMapだと、setの変わりにadd・putを使う。
つーても全部コレに合わせてるワケでもないが。
判定系は、booleanを返す物なら is で、判定して内部状態が変化する物だとcheckかな。
countなんかは get***Count() って感じ。
チラシ裏だな。
0872デフォルトの名無しさん2006/10/30(月) 16:30:18
checkはなんか意味が曖昧なんで使わないのだが、
あえて使うなら、副作用のみで真偽は返さないかな。
0873デフォルトの名無しさん2006/10/30(月) 18:29:41
なるべく、標準ライブラリの記法にあわせている。
iostream や、コンテナに習って、プロパティのように使うなら、get/set はつけない。

retval = obj.value(); // get
obj.value( newval ); // set
if( obj.empty() ) // check

それ以外は、get* / set* / put* / is* を使い分ける。
0874デフォルトの名無しさん2006/10/30(月) 23:07:13
>>873
iostream の value(T&) や、標準コンテナの empty() は失敗だろ。真似しないほうがいい。
0875デフォルトの名無しさん2006/10/30(月) 23:24:35
俺はget/setを書かなくていいその書き方は好きだけどな。
0876デフォルトの名無しさん2006/10/31(火) 03:01:57
構文から明らかなんだし、失敗と言うほど失敗でもないと思うけどな。
まあ、自分で書くとしたら明示的にget/set/isを付ける派ではあるけども。

checkに関しては明確にこうと決めているものが思い当たらなかったので
自分が書いたソースコードにgrepをかけてみたら、

if (checkMD5()) /* ... */;

みたいなコードが出てきた。
今にして思えば isValidMD5() の方が良いのかも？
0877デフォルトの名無しさん2006/10/31(火) 03:04:01
あーでもisXxxが使われるのは、obj.is の形式になって英語的だからか。
とするとむしろ obj.hasValidMD5(validhash) とかの方が…？　悩む
0878デフォルトの名無しさん2006/10/31(火) 11:06:47
俺ならisだな
0879デフォルトの名無しさん2006/10/31(火) 12:53:30
何が valid でなにが invalid なのかわかるような名前がいいよ。
あと、invalid な MD5 値を何かに使う予定がないなら、
単にhasMD5、getMD5 でいいと思う。
08808672006/10/31(火) 13:48:03
結局、readとgetの使い分けは難しいから get一本でいくわ
0881デフォルトの名無しさん2006/10/31(火) 22:50:31
俺なら validateHoge の中で checkHogeMD5 する感じだな。
0882デフォルトの名無しさん2006/11/01(水) 11:45:47
template< typename T >
md5hash_t md5of( T const & t ) { ... }

if( md5of( obj ) == validhash ) {
　// valid
} else {
　// invalid
}

とかは？ 見た目に分かりやすい。
0883デフォルトの名無しさん2006/11/24(金) 12:09:45
おまいら構造体のプレフィックスってどうしてる？

クラスなら C
メンバ変数なら m_
ポインタなら P
文字列なら状況により str

って付けてるけど、構造体は S だと文字列みたいだから、
とりあえず全て大文字にしているけど、おもいらどうしてる？
0884デフォルトの名無しさん2006/11/24(金) 12:32:44
>>883
言語による。
てか、その言語のライブラリの規約にそろえる。
俺はMS信者なんで、C++の場合には MFC の規約にそろえてた。
0885デフォルトの名無しさん2006/11/24(金) 12:55:21
構造体とクラスには特につけてないな自由につける
namespaceで名前空間を切れば名前衝突しないし
0886デフォルトの名無しさん2006/11/24(金) 19:32:45
値セマンティクスな型は *_t
ポインタ型は *_ptr
クラススコープの外部参照可能な型は *_type
テンプレート引数型は タイトルケース(最初の文字だけ大文字)
それ以外の型は適当な名前
なお基本的に全て小文字

ってとこかな。
0887デフォルトの名無しさん2006/11/24(金) 20:38:18
俺は使ってるフレームワークとなじませたい場合は合わせて、
いかにも自作クラスですって雰囲気にしたい場合はずらす。
0888デフォルトの名無しさん2006/11/24(金) 22:27:52
this-> しない奴は泣かす
0889デフォルトの名無しさん2006/11/24(金) 23:11:36
C++だとスコープと参照方法で区別してる。
こんな感じ

グローバルスコープ
TFoo　　型
Foo　　変数
PFoo　ポインタ

ローカルスコープ
t_foo　型
foo_　　メンバ変数
foo　　 ローカル変数
p_foo　ポインタ
0890デフォルトの名無しさん2006/11/25(土) 12:49:48
>>884
>>886

gcc だと、*_t ってのを使うけど、自分で型定義したのと区別したい
時って無い？　自分で定義したのも *_t としちゃうとまぎらわしくないかい？
0891デフォルトの名無しさん2006/11/25(土) 14:50:39
つーか *_t って言語仕様で予約されてなかったっけ?
0892デフォルトの名無しさん2006/11/25(土) 16:19:10
size_t は予約されてるが、unko_t とか manko_t は予約されてないだろう
0893デフォルトの名無しさん2006/11/25(土) 16:30:47
size_tとptrdiff_tは言語仕様だったかな……
time_tとかの構造体型名は言語仕様じゃなく標準ライブラリ仕様のような気もする。
0894デフォルトの名無しさん2006/11/25(土) 16:43:41
time_tは構造体じゃねえぞ
たいていはlongの別名
0895デフォルトの名無しさん2006/11/25(土) 17:07:21
>>893
全部ライブラリだよ。言語で *_t なのは、 wchar_t ぐらいかな。
0896デフォルトの名無しさん2006/11/25(土) 21:46:16
>>895
ptrdiff_tは、C++の仕様に盛り込まれてる
size_tは覚えてない
0897デフォルトの名無しさん2006/11/26(日) 00:02:04
時間関係の構造体はstruct tmか。
0898デフォルトの名無しさん2006/11/26(日) 00:41:42
ワイルドカードで予約されてるのは u?int*_t だけか
0899デフォルトの名無しさん2006/11/26(日) 00:59:47
意味は伝わったがワイルドカードと正規表現のチャンポンだな。
0900デフォルトの名無しさん2006/11/26(日) 01:00:51
>>896
どこからそんなデマを？
0901デフォルトの名無しさん2006/11/26(日) 08:53:34
>>900
そう思っとけ、馬鹿
0902デフォルトの名無しさん2006/11/26(日) 09:19:19
ptrdiff_t x = 0;

:1: error: `ptrdiff_t' does not name a type
0903デフォルトの名無しさん2006/11/26(日) 09:21:19
>>899
どこに正規表現が出てきた？
0904デフォルトの名無しさん2006/11/26(日) 09:36:20
>>902
誰がコンパイラ定義だと言ったよ（藁
0905デフォルトの名無しさん2006/11/26(日) 09:48:45
>>904
「コンパイラ定義」ってなぁに？
0906デフォルトの名無しさん2006/11/26(日) 13:22:37
uがあってもなくてもいいという意味の?てワイルドカードじゃないよな?
0907デフォルトの名無しさん2006/11/26(日) 13:30:53
ワイルドカードの?は任意の1文字だな
正規表現の.と同じような感じだ
0908デフォルトの名無しさん2007/01/02(火) 13:36:48
俺がつけてるプリフィックスは二つだけだな

メンバ変数のm_Foo　->　thisを付け忘れるから
グローバル変数の　Grobal_FooFooFooFooFoo(Grobal_　+　最低20文字以上)　->　それぐらいの覚悟がない限り使うなということで　

後はいらね
0909デフォルトの名無しさん2007/01/02(火) 14:05:51
> Grobal_
さすがにスペルミスで恥をかく覚悟まではしたくない
確かに誰も使わなくなるな
0910デフォルトの名無しさん2007/01/04(木) 17:26:09
＞メンバ変数のm_Foo　->　thisを付け忘れるから
気持ちは分かる。
言語仕様で this を強制して欲しいと思う。
0911デフォルトの名無しさん2007/01/04(木) 19:03:04
警告出すオプションだけでもあるといいのにな＞this
0912デフォルトの名無しさん2007/01/04(木) 21:35:13
Eclipseにはあったな。JDTだけかもしれんが。
0913デフォルトの名無しさん2007/01/04(木) 23:11:18
import hoge.*;
とか、smart な IDE を前提にすると
嫌がらせとしか思えないような構文糖(と言う名の罠)も
そろそろなかったことにして欲しい。

Ruby の名前見ただけでインスタンス変数なのかローカル変数なのか分かる、
ってのはシンプルで良いアイデアだと思った。
0914デフォルトの名無しさん2007/01/06(土) 17:25:09
FORTRANの名前見ただけで整数型かどうかわかるというアイデアはいかがですか
0915デフォルトの名無しさん2007/01/06(土) 17:41:15
俺は好きじゃないけど研究室の先生は分かりやすくて良いだろと言ってた。＞i,jk,...は integer

6桁開けてから書き始めるとか、今日的に許される文法じゃないよな。
0916デフォルトの名無しさん2007/01/06(土) 17:55:31
>>914
時代遅れ。

名前でそういうの判断しないといけなくなってる時点で悪いコーディングスタイル。

>>915
先生と呼ばれるような人は基本的に生きる化石。
0917デフォルトの名無しさん2007/01/06(土) 18:22:36
> 名前でそういうの判断しないといけなくなってる時点で悪いコーディングスタイル。
だってさ。>>913
0918デフォルトの名無しさん2007/01/06(土) 18:42:58
>>911
どうでもいいが、そのオプション
標準ヘッダファイルのコンパイルで、死ぬほど警告が出るから
全く役に立たんだろうよｗ
0919デフォルトの名無しさん2007/01/06(土) 19:13:57
俺は913だけど、その部分も否定されちゃってるの？
this-> って書く代わりに @ ってつくよとか、その程度なのに。
(this-> は省略できるが @ は出来ない。)
0920デフォルトの名無しさん2007/01/07(日) 18:01:53
本質的にFORTRANの規則やハンガリアンとかと大差ないと思われるから、
914みないなレスがつくわけなんだが
0921デフォルトの名無しさん2007/01/07(日) 21:35:35
さすがに言語仕様で強制されているのとハンガリアンを一緒にするのはどうかと
0922デフォルトの名無しさん2007/01/08(月) 19:53:52
仕様なんて飾りです
0923デフォルトの名無しさん2007/01/11(木) 21:59:37
それじゃあ仕様がないね。
0924デフォルトの名無しさん2007/01/11(木) 22:22:52
仕様こりもなくまたそんなダジャレを
0925デフォルトの名無しさん2007/01/13(土) 00:28:20
くだらない洒落はこれで終わりに仕様ぜ
0926デフォルトの名無しさん2007/01/15(月) 13:40:33
またそんな仕様も無い事を言う･･･
0927デフォルトの名無しさん2007/01/16(火) 19:35:49
くだらないことを仕様知の上で書いてるんだよな。
0928デフォルトの名無しさん2007/01/18(木) 00:33:13
Before
>　int i, j, k;

After
>　int i;　/* ループカウンターその1 */
>　int j;　/* ループカウンターその2 */
>　int k;　/* ループカウンターその3 */
0929デフォルトの名無しさん2007/01/18(木) 01:01:52
一時変数全てにコメントさせる前に、
一行コメントは // で始める
を規約に加えたら良かったのに。
0930デフォルトの名無しさん2007/01/18(木) 14:28:28
>>928
ご愁傷様。その規約最悪だね。
0931デフォルトの名無しさん2007/01/19(金) 20:51:16
>>928
デスマーチprojectに放り込まれたか？
まあ死なない程度に頑張れ…
ちゃんと死ぬ前に病院行ってドクターストップもらうんだぞ。
0932デフォルトの名無しさん2007/01/20(土) 08:52:33
いやネタ切れ気味だから、一例としてなんとなく書いただけ
締め切りは昨日だけど、早々に終わったし

しかも、昨日までやってた仕事は、コーディング規約なし
規約全くなしだから、コメントもほぼ無いんで
人によっては憤慨してるんだが、個人的にはコメントないほうが読みやすいし

経験的に規約は少ないほうが（無いほうが）快適だな
逆に規約でがちがちのプロジェクトも程々の規約のプロジェクトも経験はあるけど
0933デフォルトの名無しさん2007/01/20(土) 08:56:23
ちなみにほとんどのソースは、Beforeみたいな感じで書かれてんだが
自主的に、Afterみたいな感じで書く人もいるのが笑えた

そいつの書いたソースだけ、読みにくいんだけどｗ
２行で書ける処理を、２０行で書くなよって感じで
0934デフォルトの名無しさん2007/01/20(土) 09:13:34
Before
> if ( func(foo1, foo2, foo3, foo4) != OK )
> 　return ERROR;

After
> /**************************************************************/
> /* コメント */
> /**************************************************************/
> rc = func( foo1,　　/* 素敵コメント */
>.　　　　　　　foo2,　　/* 素敵コメント */
>.　　　　　　　foo3,　　/* 素敵コメント */
>.　　　　　　　foo4 ) ; /* 素敵コメント */
>
> /**************************************************************/
> /* コメント */
> /**************************************************************/
> if ( rc == OK )
> {
> 　/* 何もしない */
> }
>
> /**************************************************************/
> /* ここにコメント書くなよｗ みづれーっての */
> /**************************************************************/
> else
> {
> 　status = ERROR ;
> 　return( status ) ;
> }
0935デフォルトの名無しさん2007/01/20(土) 10:11:00
>>932
少人数で意思疎通がしっかりしてるプロジェクトでは規約なんて全く必要ない。
言語・開発環境の一般的な命名規則に従うだけなのでわざわざ文章化する必要も無いし、
知らないやつ・調べる気のないやつは、そもそも使い物にならんし邪魔なだけなのでプロジェクトから外す。

大人数で意思疎通がグダグダでスキルレベルもバラバラで
かつコード書けないオッサンが管理者(と言う名の置物)やってると、
プロジェクト管理の一環として、素敵規約満載の資料が配られる。
関数名や変数名が記号的になり、使用してる関数・変数の一覧を
管理台帳に記載しろとか言い出す。
管理台帳のサイズが何故か管理者の評価につながるので
管理者は規約に従わないやつを見つけると激怒する。
0936デフォルトの名無しさん2007/01/24(水) 23:24:09
>>935
おまえはさすがにかわいそうな子だな
0937デフォルトの名無しさん2007/01/25(木) 00:19:55
>>934
おもしろすぎる。
0938デフォルトの名無しさん2007/01/25(木) 01:54:51
ハ　ン　ガ　リ　ア　ン　記　法
0939デフォルトの名無しさん2007/01/25(木) 03:23:49
・名前は全て先頭を大文字にする・プレフィックスは付けない
・必ず改行してから中括弧・継承は混乱の元なので内包

ソースが格段に見やすくなります。長年の試行錯誤のうえの最終形態です。

class Test
{
　　　static const MaxValue = 1000;
　　　BaseTest Base;
　　　int　　　　　Value;
　　　bool　　　　IsCreate;
public:
　　　bool Create()
　　　{
　　　　　　Value = MaxValue;
　　　　　　if(IsCreate)
　　　　　　{
　　　　　　　　　return false;
　　　　　　}
　　　　　　else
　　　　　　{
　　　　　　　　　IsCreate = true;
　　　　　　　　　return true;
　　　　　　}
　　　}
　　　void Set(int Data1, int Data2)
　　　{
　　　　　　Value = Data1 + Data2;
　　　}
};
かなり見やすいでしょ！
0940デフォルトの名無しさん2007/01/25(木) 06:28:22
宗教戦争起こしたいの？
0941デフォルトの名無しさん2007/01/25(木) 08:16:51
キャメルとパスカルは使い分けたい。
0942デフォルトの名無しさん2007/01/25(木) 21:41:16
くそなコーディング規約が生まれる瞬間とはどんなものか
今、疑似体験した気がしたｗ
0943９３９2007/01/26(金) 00:00:01
糞かな？変数とか識別子のとこに矢印もってくれば型がとかわかるだろ
0944デフォルトの名無しさん2007/01/26(金) 00:02:04
名前に型を含めようなんて誰も言ってないから。
0945デフォルトの名無しさん2007/01/26(金) 00:09:14
継承ごときで混乱するようなら、現在のC++は猫に小判だと思う。
0946デフォルトの名無しさん2007/01/26(金) 00:17:01
>>939
C#風だね
0947デフォルトの名無しさん2007/01/26(金) 02:05:45
>939
「見やすさ」より「分かりやすさ」にもっと気をつけろ。
例えば
　MaxValue→DefaultValue
　Create→Initialize
　Set→StoreSum
とした方が、実際の動作・役割が分かりやすいはずだ。
0948デフォルトの名無しさん2007/01/26(金) 02:14:17
２１世紀のこのご時世に１行８０カラム以内なんてコーディング規約あるかよ？ｗ

なんて、先日まで考えておりました orz
0949デフォルトの名無しさん2007/01/26(金) 04:57:29
そんなものこのご時世にあるわけないだろ
0950デフォルトの名無しさん2007/01/26(金) 08:14:35
>>946
C#ともちょっと違う。
0951デフォルトの名無しさん2007/01/26(金) 08:16:12
>>948
Linuxとか有名ソフトでも、80桁以内になってるのはちょくちょくあるね。
0952デフォルトの名無しさん2007/01/26(金) 08:20:24
>>948
桁数については、決めないとみんなバラバラの環境で適当に判断するから
不統一になっちゃうね。どこかに決めるとしたら、やっぱり 80 桁が適当かな。

っていうか決めないと 200 桁とか書かれた時に指摘しづらくて困る。
150 ならいいのか？ 100 ならいいのか？とか。
0953デフォルトの名無しさん2007/01/26(金) 08:23:57
JavaとかC#なら100くらいにしてほしいね。
80だとちょっとつらい。
0954デフォルトの名無しさん2007/01/26(金) 20:15:15
ここにもPCSという過去の亡霊の影響が
0955デフォルトの名無しさん2007/01/26(金) 21:32:59
>>948
君は未だマシな方じゃないか？
>>429-431を見よ
似たようなのを俺も経験してる
0956デフォルトの名無しさん2007/01/26(金) 21:36:46
>>945
継承を捨てるとレイトバインディング出来ないけど、それはいいのかねえ？
まあ、他人様のやることなんで、どうでもいいけど
0957デフォルトの名無しさん2007/01/26(金) 21:40:18
>>939
継承と内包は、用途によってどっちを使うか決まる性質のものだと思うのだが。
0958デフォルトの名無しさん2007/01/27(土) 03:45:08
>956
レイトバインディング（のマネ）は継承を使わずともできる。
ただし継承による実装より、面倒かつ理解しがたくなると思うが。
しかし面倒な手法を選択するのも>945の自由だ。
0959デフォルトの名無しさん2007/01/27(土) 13:05:40
うーんレスを、字面どおりに、とらえなくても・・・

　「お前レイトバインディングなんて使ったこと無いし、
　　そもそも、レイトバインディングなんて知らないんだろ？」

っていうのを、ソフトに言い換えただけなんだか
0960デフォルトの名無しさん2007/01/27(土) 21:47:53
変数名に使う英単語のスペルくらい調べろや！
senser って何やねん？ゴッツイ違和感感じるわ！！！
0961デフォルトの名無しさん2007/01/27(土) 21:50:25
sendに対応するのがrecieveになってたりすると気づかない人もいるんだぜ。
0962デフォルトの名無しさん2007/01/27(土) 22:27:25
receive を間違えたのは一度や二度じゃないぜ。
0963デフォルトの名無しさん2007/01/27(土) 23:23:39
職場がインターネット禁止だから容易にスペルチェック出来ないんだぜ？
0964デフォルトの名無しさん2007/01/27(土) 23:27:23
電子辞書の一つくらい買いやがれなんだぜ。
0965デフォルトの名無しさん2007/01/29(月) 01:10:57
>963
窓+IME使ってるなら、IMEのプロパティ開いて
「カタカナ英語辞書」をONにすれ。
「レシーブ」→「receive」と変換できる。
0966デフォルトの名無しさん2007/01/29(月) 01:41:47
>>929
>一時変数全てにコメントさせる前に、

遅レスですまんが、フツー、一時変数ってキャストの結果や関数の戻り値なんかの
名前すらない変数のことを言うんじゃないのか？
0967デフォルトの名無しさん2007/01/29(月) 04:12:28
>>966
それはどこの世界での「フツー」なの？
09689662007/01/29(月) 05:20:35
俺、なんか変なこと言ったか？　と思ってググってみたらC++界隈以外じゃ、
どうもローカル変数と同義使われることが多々あるみたいだな。
0969デフォルトの名無しさん2007/01/29(月) 06:51:37
一時オブジェクトは値であって変数ではないんじゃないか？
0970デフォルトの名無しさん2007/01/29(月) 07:14:36
即値
0971デフォルトの名無しさん2007/01/29(月) 08:36:19
C++界隈でも一時変数は同じ意味で使われると思う。
0972デフォルトの名無しさん2007/01/29(月) 20:58:10
またまたご冗談をw
0973デフォルトの名無しさん2007/01/31(水) 00:58:31
＞名前すらない変数
これが変なのではあるまいか

僕は一時変数はテンポラリ変数って意味で使うなあ
まんまかｗ
0974デフォルトの名無しさん2007/01/31(水) 01:16:31
変数と言っている時点で名前がないってのが変だよ。
たぶん暗黙のコンストラクタで作られるよーなやつのことを指してる気がする。
0975デフォルトの名無しさん2007/01/31(水) 23:30:55
カンスーオブジェクトが
0976デフォルトの名無しさん2007/02/01(木) 01:00:02
>>966 が言ってるのは機械語で見たらレジストリに格納されてるような値のことだろうね
まあ、それを一時変数とは呼ばんとおもうが
0977デフォルトの名無しさん2007/02/01(木) 01:20:34
レジスタとレジストリの区別がついてないのよりはマシだろ
09789762007/02/01(木) 01:25:51
おおｗ
もうアンセブラのプログラム１０年くらい組んでないせいか
手が勝手にレジストリとか打ってたｗ
0979デフォルトの名無しさん2007/02/01(木) 01:33:10
一瞬アセンブリ言語でWindowsのレジストリにアクセスするコードをどうやって書くかと悩んだ。
0980デフォルトの名無しさん2007/02/01(木) 20:35:03
レジスタのことをレジストリという奴にリアルで心当たりがあるんだが・・・
0981デフォルトの名無しさん2007/02/04(日) 14:40:49
インデント幅って4か8どっちが好み？
リーナスの意見の、

・長時間のプログラミングで目が疲れた時には幅8の方が見易い
・多重ネストで右の方へ寄っていくようなプログラムは見直すべき

は同意かなと。BSDとLinuxは8だね。
GNUのような幅2というのは論外として、世間一般では4か8の
どちらが多数派なのかなー？
0982デフォルトの名無しさん2007/02/04(日) 14:52:10
個人レベルだと宗教論争になるが(漏れは1レベル1タブで表示幅は4スペース分)、
仕事上の規約としてはどうだろうな。8スペースが多い気がするけど。


0983デフォルトの名無しさん2007/02/04(日) 14:56:06
インデントの話をするときは、スペースとタブの混在を許すかどうかもポイント
になるな。
0984デフォルトの名無しさん2007/02/04(日) 15:16:13
C言語だとまあ8でもいいかなって気はするけどね.
Java だと クラス + メソッド + try でネスト3 がスタートなので8はちょっとつらい.
0985デフォルトの名無しさん2007/02/04(日) 15:52:48
C++でnamespaceを多用すると、3-4ぐらいがちょうどいいね。8だと多い。

タブの混在は許さない方が無難ですな。
結局タブ幅指定を強制することになり、タブを使用する意味が小さくなる。
0986デフォルトの名無しさん2007/02/04(日) 16:17:29
>>981
ちなみにお前はソフトタブ派？　それともハードタブ派？
議論すべきはまずそこからだろ。
0987デフォルトの名無しさん2007/02/04(日) 16:23:10
ハードタブ: TAB文字でインデント
ソフトタブ: スペースでインデント

という意味らしいのだが、なぜこれをソフト/ハードタブという言い方で
区別するのだろう。後者はTABじゃないのに。

0988デフォルトの名無しさん2007/02/04(日) 16:36:28
>>987
入力時にはTABキーで入力するからじゃね？
0989デフォルトの名無しさん2007/02/04(日) 16:48:03
ソフトタブ派だな。

ハードタブ8タブ派に、おれの好みのインデントを押し付けるため。
はっはっは苦しめい！
0990デフォルトの名無しさん2007/02/04(日) 19:04:25
ハードタブ4文字派だが、時と場合によって空白4文字も使う。
2chへの書き込みには空白2文字。

>989
それくらいエディタで置き換えればどうにでもなる。
0991デフォルトの名無しさん2007/02/04(日) 19:19:38
>>990
全角空白使えや
0992デフォルトの名無しさん2007/02/04(日) 19:37:16
ソフトタブ2文字。
理由は視線の移動が少なくて読むのに楽だから。
たとえ視界に入っていても、ものをはっきり認識できる領域ってのは限られてる。
そのためタブが大きいと視線の移動も大きくなり、目の負担が増大する。
8文字派の気が知れんよ。
せいぜい眼球を無駄に動かして疲れてください。
0993デフォルトの名無しさん2007/02/04(日) 21:33:32
Delphi使いの俺はソフトタブ２に一票
今やってるC言語の仕事は８タブで横８０カラムのコーディング規約なんだが、冗談はよせと思ってる
識別子の長さが最大６文字の時代ならそれでもいいがｗ
0994デフォルトの名無しさん2007/02/04(日) 21:35:41
ここで

「インデント幅なぞどれでも良い」と判断出来るような
関数／メソッドにするべきでは？

と言ったら嵐になってしまう？
0995デフォルトの名無しさん2007/02/04(日) 23:29:17
次スレ

コーディング規約 第3条
http://pc10.2ch.net/test/read.cgi/tech/1170599322/
0996デフォルトの名無しさん2007/02/05(月) 00:16:04
>>994
すまんが、なにを言っているのかわからない
0997デフォルトの名無しさん2007/02/05(月) 03:27:16
多くてタブを2段ぐらいまでの使用に留めれるように
きれいなソースにするという事では
0998デフォルトの名無しさん2007/02/05(月) 08:47:33
ネストは2段までってこと？
0999デフォルトの名無しさん2007/02/05(月) 11:32:10
　 　 　 ＼∧＿ﾍ　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣ 
　,,､,､,,,　/ ＼〇ノゝ∩ ＜　 1000取り合戦、いくぞｺﾞﾙｧ！！　　　　　　　,,､,､,,, 
　　　　/三√ ﾟДﾟ)　/　　 ＼＿＿＿＿＿＿＿＿＿＿＿＿　　,,､,､,,, 
　　 　　/三/| ﾟＵﾟ|＼　　　　　　,,､,､,,,　　　　　　　　　　　　　　　　　　　　　　　,,､,､,,, 
　,,､,､,,,　Ｕ （:::::::::::）　　,,､,､,,,　　　　　　　　　＼オーーーーーーーッ！！／ 
　　 　 　//三/|三|＼　　　　　∧＿∧∧＿∧ ∧＿∧∧＿∧∧＿∧∧＿∧ 
　　　　　　∪　 ∪　　　　　　 （　　　　）　　　 （　　　　 ）　　　（　　　　）　　　 ） 
　,,､,､,,,　　　　　　　,,､,､,,,　　∧＿∧∧＿∧∧＿∧ ∧＿∧∧＿∧∧＿∧∧＿∧ 
　　　　　　,,､,､,,,　　　　　　 （　　　　）　　　 （　　　　）　　　 （　　　　）　　　 （　　　　） 
1000デフォルトの名無しさん2007/02/05(月) 11:34:20
わっしょい
1001１００１Over 1000Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。