コーディング規約 第2条

カッコの位置や変数名のつけ方から、何で規約なんて決めるのという話まで
コーディング規約・スタイルに関するスレ

過去スレ
http://pc2.2ch.net/test/read.cgi/tech/1056716338/

姉妹スレ
★★★コーディングマナー★★★
http://pc2.2ch.net/test/read.cgi/tech/1056508692/
クラス名・変数名等に迷ったら書き込むスレ。Part3
http://pc2.2ch.net/test/read.cgi/tech/1067171530/

おつかれさまぁ〜

結局自分、過去ログを読まないまま最後を迎えた人でした・・・ｽﾏｾﾝ

　　　　　　　。 ◇◎｡ｏ.:O☆οo.
　　　　　　　。:゜ ◎::O☆∧_∧☆｡∂:o゜
　　　　　　 ／。○。 ∂（*ﾟーﾟ ）O◇。☆
　　　　　／　　◎|￣￣∪￣∪￣￣￣|:◎:
　　　 ／　 　 ☆｡|..　　新スレおめ　　.|☆
　 ▼ 　 　 　 。○..ｉｏ.｡◇.☆＿＿＿＿| 。.:
∠▲―――――☆ :∂ｉo☆ ゜◎∂:.

何で規約決めるの？

>>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);
　　}
　}
}

名前被りすぎー。

C++やPerlでも使えるindentはないかな
今使ってるやつはC専用なのでダメポ

>>6
> public static void hoge(int consts) {
>　for (int i = 0; i < consts.length; i++) {

int に .length なんてプロパティがあるとは奇特な言語ですね。

言語が分からないのに.lengthをプロパティと決めつけるとは。

言語によって独自の名称が使われていても
言語の壁を超えた一般名称としての「プロパティ」の範囲内に納まる

counts.lengthってcounts.sizeの間違いじゃないの？
配列でもないのに長さってありえる？

>>11
counts は >>6 が書いた範囲では宣言されてないので配列かも知れない

>>12
関数の引数

>>13
引数は consts ですが、それが何か ?

・consts
・count
・counts
まあなんていうか、>>6が
> 名前被りすぎー。
言うのも分かるよな。
>>13よ、安心しろ。私も同じ勘違いをした。
これはコードが悪い。

前スレ>>929 （for ループを横に並べるやつ）
ぜんぜん納得でキーンッ！

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


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


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





下っ端がバグ取りってのは、、、逆なほうがいいんだがなあ。

ついでに前スレ>>988

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

グローバル変数は変更を難しくします。勉強してこの感覚わかるようになってね。

17と前スレ988の前提が食い違ってるように見える。

例えていうなら988はCで17はC++を前提としてるような。

>>16
あぁ、それはある。
自分で書いててもデバッグめんどいし。
他人のコードだったらぶち切れ間違い無し。

=演算子の値を評価するのは禁止。
whileの条件に使うのだけは許されることもある。

if ( hoge* p = dynamic_cast< hoge* >( moge ) )
{
}
も禁止か・・・宝の持ち腐れじゃのぅ・・

>>20
なんで？
そしたら
while (c = getchar, c!='\n');
ってできないじゃん

>>21
それは、パターンとして定着してくれればいいけど、個人的には禁止したい。
いやメリットがあるのはわかるけど。

まぁ、パターンとして定着しているものは許可、ということで。

>>22
２行目を読まずにカキコとみたが、どうか？

ちなみに、サンプルプログラムを書くことが多いのだが、メソッド呼び出しの戻り値にたいしてメソッド呼び出しすることは避けている。
メソッドの戻り値の型を明示できるからな。

というわけで、わかりやすさを求めるなら、メソッドの戻り値に対してメソッドを呼び出すのも禁止するのがいい場合もある。

>>24
すんません

>>25
あるあるあるある(ry
俺の場合は型を明示というより、VCのデバッガでオブジェクトの中をのぞきたいからだけど。
変数に適切な名前をつければコードの可読性も上がる。

>>21
ふと思ったけど、C++って変数初期化も式なの？

>>28
Cほど型がゆるくないからキャストしてるのさ

>>27変数よりも前にメソッドに適切な名前をつけろ

>>29
Javaだと初期化は式ではないから
　if(boolean b = true) System.out.println("aaa");
とかくとコンパイルエラーになるんだよね。
C++では式なのかなと。

>>31
条件部分で変数の宣言が出来るだけで、宣言が式ってわけじゃない。
if ( bool a = true )
とかは出切るけど
if ( (bool a = true ) && b )
とかは出来ない。

ということは、C++は「初期化」という構文はなくて、変数宣言と代入を同時に書ける、というスタンス？

>if ( bool a = true )
この形が特別に許されているだけじゃない？

if(bool b(true))

はgccで通んなかったし

まぁ()の中で初期化したがるやつは、Windowsでプログラミングしようとして
愕然とすることになるだろうな。

>>35
なんで?
VC7.1でも通るけど

規約？なんで「標準」じゃないの？規約ってつけたら逸脱できないじゃないか。
どうしても「規約」にしたいなら「××するべからず」だけにして欲しいな（その根拠もつけてね）
「××するべし」っていう規約は見たくも無い。
だいたい、そういうルールっていうのは、全員が（賛成しないまでも）納得して決めるものじゃないのか。
プロジェクト参入前に規約を見せてもらったことなんてないぞ。
入ってから「××するべし」で埋め尽くされた規約を見せられてもねえ。
契約書に付けなきゃ。「そんなこと聞いてない」って回答するぞ。

>>37
そう回答しとけば?(笑)

>>37
マジレスするが、単に知名度が高いほうをスレタイに使ってるだけでしょ。

コーディング規約 約2,480件
コーディング標準 約1,680件
　　--2003/11/15 Google検索結果

>>37
するべからずは数が多すぎる。
あと、どんなコードをしやがるかは、見るまでわからない。

>>37
その程度のルールも許容できないようじゃ社会人として失格だな。
ま、趣味で思う存分やってくれ。

おれはｺｿｰﾘ破ったことがある。
だって、JavaでXXX012_032なんてクラス名を強要されたら発狂するよ！

その程度ってどの程度だよ

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

社会人失格なのは、頭腐ってんじゃないかと思えるような規約を作った奴だ

>>42
そういうプロジェクトは、コーディング規約以前に破綻している。

>>43
つまりお前の主張はお前ローカルな話であり、コーディング規約一般の話ではないわけだ。
お前ローカルな事情をコーディング規約一般に敷衍されてもねぇ。

つまり、ローカル変数の仕様は規約で禁止ってことでいいですか？

>>46
おれが参加しないプロジェクトでなら、いい。

>>47
その程度のルールも許容できないようじゃ社会人として失格だな。
ま、趣味で思う存分やってくれ。

>>48
うーん、ローカル変数使っちゃいけないなら、社会人失格でいいな。

ローカル変数なし・・グローバル変数と仮引数がすべて?
関数型言語みたいにすれば何とかならなくもないのか?

ローカル変数のない言語でRPG作ってる馬鹿もいますが。

>>46=>>47ってことか？>>49
自分が言ったかどうかわかんねんだから、自分が発言したと言う証拠があるもの以外使うな

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

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

荒らし騙しは無視、みんなお前のこと無視するぞ

>>51
ローカル変数が何たるかが解らない言語もあるだろ

HSPとかBASICとか

俺ならまずグローバル変数をpush/popで擬似的にローカル変数のように使える仕組みを作ってから使うな。
多少面倒だが投げ出すほどでもない。

俺は何故52がキレてるのかわからん・・・

push/popでやるの？・・・
ソレって違う変数でてきたらどうするの？

メンバ変数が許されるのなら、関数をクラス化するリファクタリングの手法で
回避できるな(笑)

>>52
その程度の荒らし騙しも許容できないようじゃ2チャンネラーとして失格だな。
ま、お前ローカルで思う存分ネチケットくれ。

>>58
すんませーん、出直してくるぽん

>>52
> >>46=>>47ってことか？>>49

どうしてそうなるのか、わからん。

>>47は>>46でないと解ってなかった誤爆です＞＜
>>47さんがローカル変数を使わないと勘違いしたんです・・・

ごめんなさい>>47さん

なんか可愛い

>>61
(・∀・)イイヤツ

変な質問かもしれませんが教えて下さい。
変数を定数として使うことはありますが、
配列を定数として使うことはありですか？

//変数
const int COUNT_MAX = 10;

//配列
const int COUNT_MAX[5] = {1, 2, 3, 4, 5};

配列も変数です。

グローバルな定数として

//このように使っているところを
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};

ってことです。

言語仕様が許すならありでしょ？
実際、上の記述って使えないじゃん。
配列固定データなのに、そういう持ち方って。

C/C++はあんまり使わないからなんとも言えないがJavaだと
final int[] COUNT_MAX = {1,2,3,4,5};
なんてやってもCOUNT_MAXが変更不可なだけでCOUNT_MAX[0]とかは変更可なまんまだよねえ。
C/C++では変更不可になるのか？

>>68
なるよ。
Java: final int[] ← final 指定された int[] 型変数。
C++: const int a[] ← const int 型の配列。

---<ソース: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" );
　　}
　}
}

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

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


＿|￣|○ ダメじゃん・・・・。

>>70
いや、69 の文章は“C++ ならなるよ”ってことだろ。
Java で駄目なのは 68 でも触れられてるとおり。

final int[] a← 変更不可なのは a 自身であって、その要素は変更可能
const int a[] ← 変更不可なのは a の要素(配列だから a 自身も変更不可だけど)

>71
>いや、69 の文章は“C++ ならなるよ”ってことだろ。

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

ところで、

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

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

if..else の else は

}
else {

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

} catch {

と書かれることが多いような気がします。個人的には catchの前の閉じブレースで
改行して頂きたいのですが、どちらが正統なのでしょうか？

> }
> else {

多いか？

>個人的には…

他の人のやり方なんて無視して好きにすればいいじゃん。
自分のが正統って言ってほしいの？ 正統なんて無いよ。

>>74
すみません。訂正します。
どちらがキャッチーでしょうか？

>>75
こんなのが目だっていいんじゃないかな？

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

>>76
括弧の数はそろえた方がいいと思うのですが。。。

久しぶりにネタにマジレスというものを見てしまった。。。

>>78
>>77 をマジレスと取る奴もいるんだ...。

>>79
>>74をマジレスと俺は読むが...。

>>73
閉じ括弧での改行というのは、どちらでもいいと思うが、

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

「if では else 前で改行するが try では catch 前で改行しない」人がいるわけで、
それは美しくないと思う。

>>81
一貫性の美学から言えばあなたの言うとおりだよね。
ただ、K&Rに反して「else前改行」の記法が生まれたのは、elseブロックがのちのちのメンテで
不要になったばあい、そのままブロックごと削除しちゃえばそれですむのに対し
「else前で改行しない」場合はいちいち括弧の対応を考えなきゃならないという
実用性において成立したんじゃなかったっけ？
だから tryの場合も同様に ．．！？うっ！☆■※！
．．．ここまで書いたが、よく考えたら catch のない try なんてねーよな。
負けたよ。
「catchの前では改行しない」が正解。ごめん。

catchブロックは複数存在できますよ。

try {
...
} catch (FooException& e) {
...
} catch (BarException& e) {
...
} catch (BazException& e) {
...
}

try
{
...
}
catch (FooException& e)
{
...
}
catch (BarException& e)
{
...
}
catch (BazException& e)
{
...
}

try {
...
}
catch (FooException& e) {
...
}
catch (BarException& e) {
...
}
catch (BazException& e) {
...
}

if () {
...
} else { <-- ここから
...
} <--- ここまでを消すと 改行しないelseの場合はエラーになるが

try {
...
} catch (e) { <--- catchの場合は改行しなくても、ここから
... <--- ここまで消してもエラーにならないのです。
} catch (e) {
...
}
よくできてる！！

いや、どっちもいっしょか。
要は好みの問題か。

お前らのエディタは行ごとにしか消せないのか？
Windowsのは、Shift+カーソル(またはマウス選択)してControl+Xでいいじゃん。
Emacsならリージョン指定して削除。
viはしらね。

>>89
マウスの場合、行頭の一文字残して範囲指定するの神経使うじゃん。疲れちゃうよ。
emacsの場合 ctrl+a したあと ctrl+fしてリージョン打つのもなんだかな、だし
viだったらdd一発！
edならアドレス直行！！（さすがに使わないが）

>>87
てか
if () {
...
} else { <-- ここから
...
...
...<--- ここまで
}
を消せばいいんじゃないの？俺はそうしてるけど。

ちなみに言語違うがSQLでSELECTに続けてカラム名書くやつも
すげーむかつく。

SELECT COL1, COL2
FROM TABLE1
WHERE ...

こう書け
SELECT
COL1,
COL2
FROM
TABLE1
..
上のは美しいが、死ぬほどメンテしづらい...

あ、インデント消えちゃった。

>>92
簡単なクエリーしかしないんだね…

>>90
なぜそこでctrl+aするか？

マウスやviの場合は行ごとが楽だね。ただ、vi使うような奴は自分で
どうにかできるから、かまうことない。

>>91
あんたの言うとおりだよ。
このかた10年、「elseで改行のほうが実用的」説をかたくなに信じてきたのだが
あまし意味ねぇってことだったな。。。＿|￣|○ (改行の無駄遣い？)

つーかなんでメンテしにくいのかよくわからん。
そんなに頻繁にフィールド名変えるのか ?

>>95
>なぜそこでctrl+aするか？
行頭にカーソル戻すじゃん。

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))

>>94
長いの書くと
ここだと消えちゃうじゃん。

というか、改行しない書き方でFROMのなかにインラインビューとか使ったりすると
コード書く時間よりも整形する時間の方が長くなってこない？
整形ツール必須 ＝ 不健康　説です。

>>99

>>100
簡単なクエリーしか書かないんだね…

>>99
最初に現れる IN( に対応する閉じ括弧はどこまでですか？
一見してわかりますか？
横にべた書きするとカラム別名、テーブル別名あとから書き換えるとき
面倒じゃないですか？

整形ツールって何？SQLを整形してくれるのか？
何でそんなものが必要なのか理解できん。

>>103
一番最後の")"に決まってるし、括弧対応エディタ使えばすぐに分かるだろ。

>>104
>SQLを整形してくれるのか？
そう。
>何でそんなものが必要なのか理解できん。
だから、俺もそんなんいらないような書き方を心がけている。

SQL書くときは等幅フォント使え。いじょ。

>>98
いや、だから行頭に戻さずにリージョン開始すればいいじゃん。

>>106
君の書き方だと、>>99程度の簡単なクエリでも30行程度になってしまうのだが。
100行を超えたクエリなんぞ見たくもない。

>>99
T2ってなんですか？
これ動くんですか？

>>110
その質問は本質的なものじゃないし、動かないだろうな。バグってる。

>>111
ひょっとして WHEREの前にスペース一つ
FROMのまえにスペース二つ入れちゃってるクチですか？
この板だとよく見えなかったけど。

>>112
そうだよ。それが何か？

つーか、俺は>>109が言いたかっただけで、>>99の内容にも触れるつもりはないし、
細かいSQLのフォーマットも議論するつもりはないのであしからず。

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
　　　　　　)
　　)

>>114
つーか一番深い層のIN(..)条件が違うSELECT分にごっそり切り替わったとき
99の書き方だと書き換えるのがとても面倒ではないですか？
というか結構時間かけてません？
確かに俺の書き方だと縦に長くなるのは弱点なんだけれど（１００行、２００行は当たり前）
でもブロックで役割分かれるし、長くなっても書き換えの機能性＆メンテ性優先にするよね。

>>115
>>99のほうが分かり易い。

つか、SQLの記述フォーマットの議論はよそでやってくれ。

>>116
>>>114
>つーか一番深い層のIN(..)条件が違うSELECT分にごっそり切り替わったとき
>99の書き方だと書き換えるのがとても面倒ではないですか？
全く面倒ではない。

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

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

つか、>>99のフォーマットはオライリーのOracle関連本とJoe Selkoの本のものだ。
わるいけど、俺この話もうしたくない。ごめん。

s/Joe Selko/Joe Celko/

>>118
うん、だから俺もオライリーのアリ本もってるけど
あの本疑っているんだよね。少なくともフォーマットに関しては。

SQLの記述フォーマットは、慣れでどうとでもなる。
ただ>>115は冗長な感じ。
if (
a == b
&& c == d
&& e == f
)
{
...
}
else
{
...
}
みたいな気持ち悪さがある。

もうこの話はしたくないと言ったが一言だけ。
>>99のフォーマットはJoe Celkoも使っているし、他でも良く見かける普通のフォーマット。
特に凝っているとは思わない。以上。

ＳＱＬ厨うざいぞ。

SQLキーワードの右端そろえも良く見るし、左端そろえも良く見るのでどっちもどっち。
ただ、全てのトークンで改行するのはやりすぎ。

Joe Celko自身がフォーマットや規約にうるさい人じゃなかったっけ？
SQLになると行志向に世の中徹しきれなくなるのが
俺にはいまいち理解できん（ぶつぶつ）

言いたいのはさ、ブロックの切れ目、意味の切れ目が
行の途中で来るようには書くなー！ってことなわけさ。
レポート系のクエリならプロトタイプベースで作っていると
Fixするまで列が入れ替わったり追加されたりなんでもありありだし
行単位で入れ替え・削除・追加できるように書いておいたほうが楽なんでねーの？
という話だ。
だいたい、100行程度のSQLでびびっているようでは業務でクエリ書いたことあるやつとはおもえん。
ERP系のデータ(R/3とか)一気に吸い出すクエリなぞ、どんな書きかたしたって
200,300行行くものはざらにある。

>>126
オトナ語がいっぱいですね。

>>92
アフォ？
100行のクエリがお前の書き方だと500行になるって言われてるんだよ。

あとお前の話つまんねーから、もうこのスレでSQLの話はやめてくれよな？

SQLの記述フォーマットについてはこちらでどうぞ。

【ノウ】DBアプリ開発ノウハウ【ハウ】
http://pc2.2ch.net/test/read.cgi/tech/1015807409/

>>126
つまり、君は君が考案したフォーマットこそが最も良いものであり、他はそれに劣ると確信
しているわけだ。ということは議論の余地など無いのでは？

今後のシナリオは、君に賛同する者や、賞賛する者が登場するまで、君の持論を繰り返す
以外には無いだろう。

>>128
彼にとってはステップ数が一番重要なんだよ。

コーディング規約 第２条
http://pc2.2ch.net/test/read.cgi/tech/1068752664/

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

>>132
規約 != マナー

すんません。
いままで引数の頭に下線をつけていたのですが、
どうやら下線で始まる識別子は予約されてて使っちゃ駄目みたいです。
なので変数の命名規約でそれぞれよさげなつけ方ないでしょうか？

ちなみに他の変数は

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

引数の変数　　　　　　？　　　　例

よろしくお願いします。
ところでgとかsとかmとかlとかも大丈夫でしょうか？

引数を英語で書くとなんていうのかわかりました。
argument
っていうらしいです。ので

引数の変数　　　　　a　　　　例　aSystem

となりました。
ご迷惑おかけしました。

.NET Framework 名前付けのガイドライン
http://www.microsoft.com/japan/msdn/library/ja/cpgenref/html/cpconnamingguidelines.asp?frame=true

完結したみたいだがparameter
個人的に堅苦しいargumentより好み。

>>137
pはポインタに誰かが使ってそうでつ。

>138
ハンガリアン記法と混在させるなよ。
そんな事言ったらaはarray、lはlong、sはstringとかあるんだが。

>>137
仮引数と実引数って意味じゃないの？

>>134
混ぜたらアカン混ぜたら。

グローバル/メンバー/ローカル： スコープの違い。
スタティック/その他(レジスタ等) ： 記憶クラスの違い。
引数　：　関数に与えられる式。(括弧の中身)
(おまけ)
パラメータ　：　関数の受け取ったオブジェクト。(に付けられた名前)

ソースコード的には混同し易いのかも。

C の場合）
スタティック：参照可能範囲は１ファイル
引数：参照可能範囲は関数内

>141
global
static（外部宣言）
member
local
はスコープの命名だと思うけど。

で、ローカル内の
static（ローカル）と仮引数と普通のローカルの区別を付ける、と。
あとはメンバとstatic（クラス）を区別すれば、
何かで見た気がするけど、機能による命名、だったかな。

>>140
> 仮引数と実引数って意味じゃないの？
それはformalとactualと言いわけるね、ふつう。

> それはformalとactualと言いわけるね、ふつう。

parameter/argumentでの言い分けも十分一般的です。
好みで使い分けるもんじゃありません。

> parameter/argumentでの言い分けも十分一般的です。
いいえ。プログラミング言語の教科書(たとえばConcepts of Programming
Languages, R.W. Sebesta)を見てごらん。parameterとargumentでの使い分け
なんてまったく触れられてないから。

> 好みで使い分けるもんじゃありません。
それはあなたの言うことにあてはまりますね。

>>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

そうするとint main(int argc, char *argv[])の
argc, argvはargumentではなくparameterなのか

>>148
どっちでもいいよ。

>>147
そんなCの話をしてるときにC以外の特定の言語の、しかも固有のterminology
を使ってる仕様書を例として持ち出されても。頭が固いとか柔らかいとかじゃ
なくて、勉強してないんだね単に。

>>150
>勉強してないんだね単に。
もう、きみ、理論がどうとか正しいことがどうとかより、
罵り合いに勝てばいいって感じじゃない？

>>150
あなたは生まれたときに動くものを見て親だと思ってしまう雛鳥のような人ですね。
勉強が出来るのと自分の知識が正しいと思い込むことは違いますよ。

http://en.wikipedia.org/wiki/Argument
>In computer science, an argument is an informal term for actual parameter, (略)

>>153
そこではそう定義されてるんだね。一般的かどうかは別にして。

>>154
"一般的"かどうかってのは個人には判断できないからなあ。

あれだ。>>153 は必死こいて一般的だと思えるとこ探してきたんだろ。

>>156
まああそこは大人数の目に触れ、しかも誰でも異論があれば簡単に手を出せるので
そこにあり続ける記述はある程度一般性があると期待できるとは思うが。
(見過ごされてるだけの可能性もあるけどね)

サブシステム NetworkDev はテーマがファンタジーであるから、ファンタジックなメタファに基づいた命名を行うこと。

× ファンタジック
○ ファンタスティック

引数なら h で始めればいいんじゃないの？

アホらしさ加減は同程度。

>>160
それはハンドルで（hWndなど）使用してしまっているのでダブるんですよ。

K&R日本語版には、付録A.7.3.2に 引数とパラメータ に代わる言葉として、
実引数/仮引数 という言葉が用いられることがある、と書いてあったけど、
コレって原書では何とかかれているんであろうか。

>>162
The terms "actual argument (parameter)" and "formal argument
(parameter)" respectively are sometimes used for the same distinction.

ところでどっちが実引数でどっちが仮引数なのかいっつも混乱するんだが、
こう、なんていうか、すぱっと覚えられる理由とか語呂合わせとかないもんかね？

いや、馬鹿でスマン。

値が入っている方が実。

ｷﾃｨｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰ

>>161
じゃあ、仮引数の k で

mozilla のコード読んでると
const 変数(つーか定数) の頭に k が付いてるな。
あれはなに？ `k'onst?

>168
ドイツ語？

kは数学で定数としてよく使う文字

kotei の K です。

i,jをループ変数として使うとかって、昔っからの規約なんかね。
FORTRUNでもBASICでもそうだったし。

>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 より、ポインタか参照か、関数引数か、オート変数かなどの情報のほうが重要と考えます。

まあ、型情報よりスコープを入れろという主張は個人的には同意するかな。
でも一画面に収まるような寿命しか持たない変数にAtとかAgとか付けるのはちと冗長な気がする。
複数人でやるときはきちっとしたほうがいいんだと思うけど、基本的には

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

という感じがいいのかなあと思ってるところ。
ま、あくまで個人的に思ってるだけだけど。

>172
藻前はFortr"a"n を一から勉強しなおせ。
そうすれば i の意味もわかるさ

変数名は使用目的を表すようにつけてください。

>>173
>auto 　　　　　　　　　　　At
>virtual 関数 　　　　　　　Vl　　　　　　　　　これについては迷っている。付けない事も多い
突っ込む気も失せる位ナンセンス。

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

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

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 を追加したほうが良くなると考えています。

>>178
> const char * cpChAt
> char const * pchAt
どっちも同じじゃん。
> struct 　　　　st or St
> class　　　　　cl or Cl
これもC++では字面上の違いにしか過ぎない。

その割に、ポインタと配列を区別していないし、本質から外れた命名規約だと感じるがなぁ。

>>175
そういう意地悪言わないで教えてやれよ。









ていうか俺も聞きたいです。

これでどよ？
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

ここに書いてあることは真実ですか?
うそだといってほしい･･･

>>179
無知が語ってます

>>173
こういうコーディング時に手間をかければ、丁寧にやってるって
勘違いしてるやつ多いな。

>>173
中途半端はよくない
どうせならここまでやれ
foo.cpp:
void bar(int x)
{
const char *auto_const_char_ptr_func_void_bar_arg_int_x_file_foo_cpp = 0;
}

変数名にこだわってる時間があるなら、コメントをもっと書けと小一時間

>>186
コメントを書くより、名前でひとめでわかるほうが良い。
コメントは保守忘れても気づきにくいからな。

コメントつけろと言っても、「なぜそうする？」に答えるコメントを
残してくれるヤツなんてほとんどいないのな。

オウム返しのコメントは可か否か・・・これはけっこう微妙な問題。

>>188
理由や経緯、想定範囲などのコードに残ってない情報はコメントの価値高いね。
そうでない情報は極力コード自体を読みやすくすることで対応したいな。

>>179
>> const char * cpChAt
>> char const * pchAt
>どっちも同じじゃん。

違うぞ。

…と思ったが良く見たら同じだ。騙された。
違うのは
const char *　と
char * const　だな。
たのむぜ>>178

Writing Robust Java Code (v17.01d) の翻訳
ttp://www.alles.or.jp/~torutk/oojava/codingStandard/

参考になった。

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

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

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

なるほど

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 引数を渡すことで済ますべき。でも少し複雑な
クラスになると、奇麗事ですまなくなるのも事実。相手が保証してくれても、
現実に保証されるものでもない。

<html><!-- 2ch_X:cookie --><head><title>■ 書き込み確認 ■</title><META http-equiv

んが、変なもん書き込んじまった。
ｺﾞﾒｿ

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

却下。

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

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


型でプリフィックスつける人は、
template<typename T> void f( T x );
とかいう場合はどうするんだろう？

Javaのライブラリとかに汚染されてる人間に
型でプリフィックスとか言っても
死ぬまで理解出来ないと思う

>>197
その場合に限って言えばPrefixは必要ない。
いつつけているか人のソース見てみるといいと思う。

>>198 Java使いの私はサフィックス派です。
　Map actionMap = new HashMap();
ただし、メソッドが単純だったりして、変数の用途が自明の時は、
　Map map = new HashMap();
とかやってます。でも、
　Map actions = new HashMap();
とはあまり書きません。そして、
　Map mapActions = new HashMap();
なんていう奇怪な変数名は、たぶん一生書かないと思います。

キモイです。

> Map map = new HashMap();
> Map actions = new HashMap();

後者の方が情報が多くていいんじゃないですか？
前者はクドイと思います。

そんなお前らに新しい書き方を提案しよう。
Map a = new HashMap();

>>201
Javaの世界では>>200が正統派。
Map map = new HashMap();
これが正しい。

例外はプリミティブ型ですね。
致命的に型が重要な場合以外、型サフィックスは付けない。
　int rows = 0;
　String message = "Hoge";
それでも、英語の意味から簡単に型を推測できる変数名を心がけています。

Javaって言うのは宗教ですから。
正しい書き方を常に心がけないと、人に見せられないソースになっちゃいます。

>>203
型だけの名前で、用途・目的は名前に入れないのか。キモイ・・

>>206
それが受け入れられないなら、Java使う資格ないですね。

Mapが2個も3個もあったら、map2, map3 ？

>>206
>>208
一画面程度のプライベートメソッドで
一個しか出てこないテンポラリ的な使い方のときにやるんだよ。
複数必要なシチュエーションで、その書き方はやらん。

(´-`).｡ｏＯ(ほんとに宗教だな… 傍にいなくて良かった)

>>210
10年後にはJava以外の言語はほとんど使われなくなっていますから、
いやでも入信していますよ。

>>211
オウムがハルマゲドンを唱えて入信を誘ってるみたいだな。ｗ

>>203
Sun の奴にはそんな事は書いてないけどね。

> Map map = new HashMap();
は int i; とか char c; とかと同レベルで
一時的な変数なら許されるって程度で
推奨される書き方では無いと思われ。

>>213
もう一度読み直せ。

>>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

>>215
javaのソース見てみ。

>>216
Map map ってのはローカル変数とかには良く使われてるけど、
インスタンス変数とかクラス変数にはあんまり使われて無いぞ。

>>217
ログ嫁。

>>218
Map map は正しいけど Map actions が間違っている
って部分はウソだろって話なんだけど。

J2SE のコアクラスライブラリにだって
Sunのコード規約を守ってない箇所なんかいっぱいあるし、
J2SE のコアクラスライブラリで使ってないからといって
即座に間違いというのも短絡的だと思うぞ。

Map mapを使うのはmapが一つしかない場合のみ（コメントつけるけど）で、
２つ以上だったら
Map hitMap; // 当たり判定用
Map baseMap; // 地形表示用
とかつけて、何に使うのか分かるようにするのが普通のJava使いだと思う。

>>220
Map が一つしかない場合に Map actions は正統派でない、正しくない、
ってな風に >>203 が書いてるんだよ。

int i は良いけど int val はダメって言ってるのに近いように見えるんだが。

>>221
ログ嫁。

int j

LotLot（昔のゲーム）とかライクライク（ゼルダ）の話か？

>>215
そんなもん、もうメンテナンスもされてないしSunじゃ誰も使ってないぞ。

最近ケリをつけた。
長年悩んできた

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

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

さらにこれと同じような問題で、戻り値でエラーコードを返すってのも、
個人的には没にしたくなってきた。
失敗する可能性のある関数の戻り値はすべてboolでやってtrueかfalseのみを
返すようにしてエラー後の詳細な処理はできるだけ関数の中でケリをつけるようにする。
ってのがいいと思えてきた。
外にエラー内容を伝える必要があるときはもっと別の方法でやるべきだと思っては
いるんだが、いい方法が思いつかないのが現状だったりするｗ
ちなみに現行ではトラブったとき関数を用意しておいて、
戻り値にfalseが返ったらトラブったとき関数を読ぶと直前のエラー内容を取得できるような作りにしてある。（へぼっｗ）

>>226
エラーコードの代替はC++/Javaとかの例外が使えるんじゃないの？

throw new IllegalArgumentException("腐った引数渡すな");
throw std::runtime_exception("アフォか？");

>>227
ところがＣ言語あがりのＣ＋＋プログラマなので
例外処理なんてどうやって使ったらいいのかってところの前の
存在から知らんのですよｗ

>>229
その食わず嫌い、5年前の俺を見てるようだな。
226みたいな悩みは例外使えばきれいに解決できるんだが。

>>226
関数の引数としてエラー処理関数を渡す

>>230
具体的に何を使えばいいですか？

>>231
よくわからないです。

>>232
自分で例外クラス作って、例外投げる時はthrow、例外を受け取って
エラー処理する時はtry〜catch、だけだけど。イメージ沸かないなら
C++で書かれてるソース拾ってきて眺めてれば大体分かるでしょ。

>>233
ところがこれがまたわからないんですよ。
ネスト多くなって見難くくなるのでtryとか嫌いなんですよ。
例外を飛ばすってのもまたわからないですね。
エラーが出たら出たところでチェックするのが一番ですよね。
そんな長い関数なんて書きませんし。

>>234
>ネスト多くなって見難くなるので

まとめられる/まとめるべき try-catch を全部バラバラに書いてないか？
まあそうでないにしろお前にはセンスがなさそうだ。

>>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
}
となるということではなかろうか

>>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
}
となるということではなかろうか

try 節の方がいいというのは，
正常時の処理である
func1();
func2();
func3();
という流れがそのまま書けるということ

もし，各関数の直後にエラー処理の分岐があると，この流れが断ち切られて可読性が大幅に下がる
try {
　func1();
　func2();
　func3();
} catch〜
と
ret = func1();
if ( ! ret ) { // エラー1 }
ret = func2();
if ( ! ret ) { // エラー2 }
ret = func3();
if ( ! ret ) { // エラー3 }
で正常時の処理の流れが分かりやすいコードはどちらか？

例外処理の最良の実例はデータベース操作だな。
try {
　selectFoo();
　selectBar();
　updateHoge();
　commit();
} catch (SQLException e) {
　rollback(); 　log(e);
}
例外に慣れたら他の書き方など考えられんよ。

>238
>if ( ! ret ) { // エラー1 }
俺なら逆だな
んで、

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

で正常時の処理の流れが分かりやすい

>>240
boolean expressionにfunction入れるのは読みづらいのだ。

garbage in, garbage out

事前条件を満たすのは呼び出し側の責務。

>>240
肝心のエラー処理部分がコメントになって１行で書けているから読みやすいだけで
普通は複数行のエラー処理になるはず
それに１つの関数から発生するエラーが１種類だけとは限らない

すると１つの関数呼び出しが無駄に間延びして読みにくくなる

>>243
> すると１つの関数呼び出しが無駄に間延びして読みにくくなる
じゃあ読みにくくならないようにするにはどうしたらいいの？

エラーライブラリがあったらなぁ　と思う。<error.h>や、errorモジュール。

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

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

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

そんなエラーをモジュールを各コンパイラ向けにオープンソースモデル
で出ないかなぁ。辞書なのだから独自のライブラリやocxを流用したアプ
リ向けに作り込んでゆく。

>>244
今までの話の流れで行くと
例外処理機構を使って正常時の処理と異常時の処理を別々に書く

>>246
例外使わずにコンパクトに書ける方法はないの？

>>247
それがないから例外が発明されたんじゃないかのう

この板はたまーにいい感じのおっさんが出て来るんだよなぁ･･･
厨も出てくるけど･･･

>>248
あんまり役に立ってねぇよな＞例外
try〜catchを使って飛ばすほど長い処理ってかかねぇし、
やっぱりエラーはその都度その場で処理したほうが
複雑にはならない。

>>250
役に立ってますよ。
処理の長さは関係ないですし、
エラーを「検出したその場」で処理するのは「不可能」なケースのほうが多いです。
エラー処理がexitだけなら可能かもしれないですが。

>>251
>エラーを「検出したその場」で処理するのは「不可能」なケースのほうが多いです。
多くねー。

非例外ベースでのエラー処理の問題は

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

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

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

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

辺りで、こういうのは例外使えば解決できる。
(というか例外が無ければすっきりとは行かない)

>>253
これ例外（ここではtry〜catchってことで話すけど）使った程度じゃ解決しねぇよ。

>>254
例えばどんなケースがある？

>>255
どんなケースがあるとかじゃなくて
例外使ったからってどうなるものでもないでしょう。

>>256
254のように言い切るって事は「例外使ってもどうにもならなかった」という
ケースがあったんだろ？ならそれを書いてみてくれ、と言ってるんだが。

>>257
つか俺が例外使うとことごとく上手くいかないｗ
ネストネストネストネストになるか。
try〜catchばかり増えて非常に見難い感じ。

>>258
それは例外の使い方がいまいち、というか戻り値ベースのエラー処理の
やり方を単純にtry〜catchに書き直しただけで、例外処理機構の「おいしい」
所を使ってない状態だと思う。

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

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

リソース解放が絡んでcatchせざるを得ない場合でも、リソース解放したら
そのまま上位にthrowしちまえばいいし、C++だったらauto_ptr使ったりクラス
化してデストラクタで自動解放させるようにすると、下位側は全くcatchしな
くて済む事もあるので、そこまで来るとすんげー楽できる。

ただ、
いちいち例外クラスをつくらにゃならん、例外仕様は使えねぇ。
ってのがなぁ。

例外処理についての分かりやすい例題が載ってるページを教えてくれるか、
例題を作って解説してくれるｴﾛｲ人ｷﾎﾞﾝ。

と思ったけど、ここで大体理解できたからいいや。
ttp://msugai.fc2web.com/java/error.html

>>258
例外は catch しない限りどんどん上位の階層の関数呼び出しに伝達する
ってことは理解しているよね？

>>258

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

失敗した具体例を示してくれれば
「こうすればスマートにできたのに」て
解決策を見せてあげられる可能性が高いんだけど。

>>258
つーかメソッド宣言の後ろにつけるthrows(sついてる)を
知らないんじゃ、、、、

for 使うとき　i, j　をよく使うのはなぜ？

ほーとらんで暗黙の整数型だったから。ダイクストラの名前から、という説もあり。

Algolでもi,j,kを使ってたな。

>266
＞ダイクストラの名前から、という説もあり
そんな説聞いた事ないぞ。

>>268
> そんな説聞いた事ないぞ。
知らないの？結構有名なジョークなのにｗ

Dr. Edsger Wybe Dijkstra
ttp://www.cs.utexas.edu/users/UTCS/notices/dijkstra/ewdobit.html

i, j, k の次は s か？

>>242
呼び出し側を書くのがお前みたいな厨じゃないと保証されるなら、俺も同意するよ。

>>247
continuation.
ttp://www.sra.co.jp/people/aoki/SmalltalkTextbookJ/textbook27.html

int i,j,k,l,n,m,a,b,c,d,val,val2;
double f,d;

>>265
どっかのスレでかいてあったぞ。
Fortran以来の古い慣習だ。
ネットでFortranの文法ググってみ。

>>265
最古の高級言語フォートランから続く慣習

フォートランはまた数学表記の慣習からきている。
行列やベクトルの要素をあらわすときＡi Ａij　とか高校の教科書に
あったろ？
(ijは下付文字で）

何年か前に1関数1ファイル、関数名とファイル名はXXX999みたいな管理番号
つーのをやらされた。みんなヤッテランネーつーことで
1プロセス1関数1ファイルなんつーのが数百も、、、
発注元に抗議してもウチの会社のナンタラカンタラ
クライアントとのナンタラカンタラ
規約決めたやつは早々にブッ倒れて入院しちゃうし、
代わりに来たヤツはなんで関数が番号なんだとか1関数がこんな長いんだとか
テメーんトコで飼ってるヴァカのせいだっつーの。
ＦＦ○潰れろ。潰れちまえ。

>>276
管理するソフトがあれば悪くないかもしれんぞそれ

基幹系で働いてたことあったけど、関数（というかプロセスごとのプログラム）は
全部XXX9999X形式だったな。3桁が使用箇所の識別で9999が管理コード、Xが
コンソールかオンラインかの識別子。

もっとも、何が何を表すか知らないとサッパリだけどな。仕様書の検索は楽だけど。

>>278
関数やモジュール名にコード番号をつけるのは
手書きドキュメントに索引つけて更新管理する手間を
省くための知恵。

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

コードや番号のみってのは論外。

50へぇ

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

int i　じゃないと気分悪かったりするので不思議です。

>>265
お前が物知らずなだけだ

>279
ワードは勘弁しろ
HTMLも自動生成は楽だが手では弄りづらい
PDFはもっての外

・・・何がいいんだろう。プレーンテキスト?

普通にコード書いて、納品するときに置換すりゃいいじゃん。
脳みそ無いの？

確かに、どうせ「納品したソース」は誰も見ないわな（ｗ

ただ、全ての現場でそういう事ができるとは限らないが。
(アフォな上司とかアフォな品質管理Ｇとかがゴリ押ししてきたり)
2〜3人でやる小さなプロジェクトまでだったらどうにでもなるけどねぇ。

>>284
あ、脳みそないみたいね、君。

>279
お願いだから EXCEL をドキュメントに使うのは止めてくれ

プロセスが数百って、すごいでかいシステムだな。

でかいはでかいけど、すごくでかいってほどでもない。

>>283
１プロセス分のコードを一つの関数にまとめたりするような置換用の
スクリプト？とか、書くの大変だと思う。
置換したら、また最初っから試験しなきゃだしね。

>>287
実行プロセスが数百個並んで走ってるシステムを想定してませんか？

ぶっちゃけありえない。

お前が知らんだけ。

#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();
}
としてはどうだろうか。

>>290
俺はあんまり多分野やらんけど、車屋の工場管制なんかは
余裕で数百走るよ？

まぁ数百起動してても、全てが一斉に動くわけじゃないっしょ。
リクエストがあってからプロセス起こすとオーバーヘッドでかいから
とりあえず上げるだけ上げとくみたいな。

数百のプロセスが(プロセス間の)同期も取らずに一斉に動いたら
流石にまともには動かん。

子プロセスも勘定に入れてるのか

>>295
子プロセスはプロセスではない？

>>295
Unix とかなら、みんな init の子孫だと思うが。

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

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

> cmdSearch_Click

わからん。

>>298
そういう奴は「プロではない」から仕方ない。

cmd がコマンドで
Search がサーチで
Click がクリックなのは推測できるが
それの関連については cmdSearch_Click だけでは

さ っ ぱ り わ か り ま せ ん

>>301
VBやってる人？

cmdSearch_Clickじゃ「ナニをされたとき」かは分かっても
「ナニをするか」は分からんもんな。
そもそもその検索ボタンを押すと何を検索するのかすら
どこにも書いてないんじゃない？

コマンドをサーチしてクリックする関数なんだろう。（なげやり）

クリックするサーチして関数コマンドをなんだろう。（やげりな）

サーチする関数をコマンドでクリックするんだろう。(やりなげ)

プロはコメント書くよ。






……馬鹿にでも分かるように。

>>307
馬鹿にでもわかるコメントなんか書けるんか ?

未来の自分にわかればそれで充分だろ。

未来の自分のためってのは正論だな。FA。

>>308
いや、馬鹿にでも分かるようにコメントを書いておかないと
未来の自分にも分からなくなっている可能性大。

３ヶ月前の自分は他人だからなぁ

ぶっちゃけ、俺が馬鹿なので、馬鹿でも分かるように書きます。

結局cmdSearch_Clickって関数は、何をする事になったのん？

>>313
>>304-306

俺は馬鹿に分からせるほど立派なコメントは書けないけど
保守担が関数の実装コードを読まなくて済む程度にはコメントしてるつもりだよ。
正直、コード読んでくれってのは最終手段だよな。

やふ

>>315
> 正直、コード読んでくれってのは最終手段だよな。

反対だろ ?
コードではちょっと伝えきらないところをコメントで補うんじゃないのか ?

どっちでもいいんじゃない？
コード自体をコメントとみなせば。

コメントを書かずに済むのなら、それに越したことはない。
コメントはコードの繰り返しであり、極力避けるべきであるから。

>コメントはコードの繰り返し

ダウト。そんなコメントは存在する意味がない

>>320
> そんなコメントは存在する意味がない

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

修正する時、余計な手間がかかるからな。

>>315
return FALSE /* 戻り値 異常 */

とかやってそうで嫌

> コードではちょっと伝えきらないところをコメントで補うんじゃないのか ?
そういう場合はコメントが不要なようにコードを書き直すべきでないかい？

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

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

>コメントとコードが一致しなくなったら変更すべきは可能な限りコードの方

ダウト。間違ってる方を直せ(w

> return FALSE /* 戻り値 異常 */
それ、コード読んでる。
コード読ませないってのは、関数の実装部を全く読ませないってこと。

/* 普段は読むのココだけ */
hogehoge()
{
/* ココは読まない */
}

> >コメントとコードが一致しなくなったら変更すべきは可能な限りコードの方
> ダウト。間違ってる方を直せ(w
サンクス。その通りだ。
でも希に「下位互換として前の版のバグもエミューレートしてくれ」って指示があることもあるので
あくまで一般的な優先順位を
　降ってきた仕様 > 共有しているコメント > 担当しているコード
と考えてるってコトで。

>>323
＞ふつうプロシージャの前のコメントってのは他のプログラマとも共有している
＞既に決定された仕様が書かれているわけで

この辺って普通、紙の書類あるじゃん。
それじゃダメなのかな？

>>326
> でも希に「下位互換として前の版のバグもエミューレートしてくれ」って指示があることもあるので

それは、｢前の版のバグ」が｢正しい仕様 (=今回のコードが間違っている)」となってるだけのこと。

ちょっと言い方がまずかった。

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

もちろん、複雑な処理には適切なコメントをつけたほうが理解に役立つが、
コメントをつけずに済むのならそれに越したことはないってことを言いたかった。

俺も言い方が悪かったかな。
そもそも実装部のコードは読ませないんだからコードにコメントなんて滅多に書かない。
コメント書くのは関数の説明と、何か異常があったところ。
「実装コードを読まなくて済む程度のコメント」ってのは、そういう意味。

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

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

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

みたいのはコードからは読みとりづらいし
コメント書いとかないとだれかが間違いだと思って直しちゃうぞ。

/**
　* お菓子を置いて帰っても良い。小人さんは喜んで、またやって来るだろう。
　* お菓子以外を置いて帰ってはいけない。小人さんは怒って、あなたのもとを去るだろう。
　* 　　　　　　　　　　　　　　　　　　　　　　　民明書房「ブラウニー伝承における嘘と真実」
　*/

>コメント書いとかないとだれかが間違いだと思って直しちゃうぞ

つーか直せよ(w

>つーか直せよ(w
直すなよ(w

>コードのやっていることを要約してコメントとして表し
違う
やっていること(How)をコメントするだけなら意味が無いと言っている

なぜ(why)とか何の目的があって(what)を書け

>>334
そうそう。why/what書かない奴多いんだよね。
それこそがコメントとして一番書いておいて欲しいところなのに。
仕様書にちゃんと明記してあるならいいけど、why/whatコメント
書かない奴はまず仕様書にも書いてないし。

で、後を引き継いだ奴が「なんでこんな処理が必要なんだ？」と
悩んだり、新規で作った部分でその処理が抜けてて「以前対策
したじゃないか」なんて責められたりする。
そんなんどっかに書いといてくれなきゃ分からんがな…

どーでもいいけど、ダウトってなんか元ネタあんの？
doubtなら用法がおかしいと思うんだが。

知らねーけどトランプのダウトじゃないの？
相手が嘘をついてると思った時に「ダウト！（そいつは信じられないねぇ）」って叫ぶやつ。

>>336
> doubtなら用法がおかしいと思うんだが。

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

つーか、そんなもん指摘する暇あったら「何の目的があって(what)を書け」の方を指摘した方がええんとちゃうか ?

なぜ: むしゃくしゃしてたから
何の目的で: 遊ぶ金を奪うため

バールのようなもので処理する関数。

慣例句で I doubt it. とか (There is) no doubt. とかは聞くけど
doubt一語で済ませるのは聞かん気がする。
トランプのダウトも、英語では"Bullshit"または"I doubt it"のようだ。

誰が広めたのか心当たりがあるような気がするが、
まあ、相手の言ってることにケチつけるときの掛け言葉みたいなもんだろ。深く考えないほうが吉。

とにかく気違いみたいに「ダウト」といきなり叫ぶやつってすぐ馬鹿だとわか
るんだから、結構便利な目印だよ。

>342 ダウト

昔のクイズ番組で、VTRを見て間違ったところを見つけたら「ダウト！」って
叫んでから間違いを指摘するってのがあったけど、それからな気がする…。

…もしかして年がばれる？

>>343 ダウト ダウト

なぁ？
俺等は「ダウト！」なんていわないで「まんこ！」って叫ぼうぜ。

>>346
「バカ！バカ！まんこ！！」

＞344
あれから10年ぐらいはたったかな？
いずれにしろそんなに年、逝ってるって訳じゃないな。

幼い頃、親戚のうちへ遊びに行ったときに「ざぶとん」というトランプゲームをよくやった。
中学生になった頃、それが一般には「ダウト」と呼ばれていることを知った。

>349
もしかして、お前みっちゃんか？

>344
あの頃のマイ○ル富岡は面白かった。

>>349
ハウスルール(地域差含む）でたまたま一緒になっただけじゃないの
九州だがざぶとんとダウトは違う

いつみまさたかだっけ？

てす

定数にはkをつける
ポインタにはpかな？

破壊的な時は ! をつける
述語には?

>>356
FORTHか？

Scheme ちゃうのん？

CommonLispだな

>>359
setf

>>323
＞そういう場合はコメントが不要なようにコードを書き直すべきでないかい？

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

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

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

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

>>361
>If IsValid(Data) Then

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

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

ただ、関数ヘッダ自体はラベルの機能もあるから、
あった方が助かるんだけど。
誤解を生むようなコメントなら無理して付けるより
削除してくれたほうがいいな。

>>362
If (this) is valid data then 〜
ってそのまま
「(この)データが正しければ〜」
だし、「データチェック」なんつうコメントは余計だと思う。
個人的にだが。

>>363
同感。どうしてもそこでコメントつけるなら、むしろIsValid(Data)の中で特
に何を検査するのか、どうしてそれを検査すればvalidだと言えるのかを書い
ておくやり方のほうが好き。

>364
それはIsValid()の定義の側にかくべきコメントだろ。
使う側でいちいちIsValidの中身書いていたら、チェック内容が変わった時に
使っている側全部変更してまわらなければいけなくなって大変だし、
昔のコメントが残っていたらそれはそれで害になる。

>>365
> それはIsValid()の定義の側にかくべきコメントだろ。
だから「どうしてもそこでコメントつけるなら」って書いてあるんだろ。
IsValid()が自分で編集できるファイル内にあるとは限らんし。

>366
自分で編集できないファイルっていうのはライブラリのことか？
それはライブラリリファレンスを用意するからソースへのコメントはいらないだろ。

>>367
ソースのコメントを原本として、ライブラリリファレンスを生成するメカニズムがあるのが理想だね

うちではjavadoc使っている。
納品用ドキュメントはソースと別にjavadocで作るので一粒で二度おいしいです。

>>363,364
ごめんな。漏れが頭悪いだけなのかもしれんが、
IsValidって名前で、エラーチェック関数だと推測はできないわ。
こんな頭悪い香具師もいるんだから、
'エラーチェック
のコメントは欲しい。
コーディング規約とかで、エラーチェック関数の名前を統一してるなら、
無くてもいいけど。

>>364の言うようなコメントも、漏れ的には書いてあるほうが嬉しい。
後からソースを修正するときに、情報は少しでも多いほうが助かる。
もちろん、無意味なコメントや、誤ったコメントは問題外だけど。

>>370
げげ

>>370
> IsValidって名前で、エラーチェック関数だと推測はできないわ。

お前が頭悪いだけ。間違いない。

IsValidだと値の有効・無効判定だと思う。
エラーとは思わない。エラーだったら素直にIsErrorにするだろうから。

無効ならエラーにする、という処理ならわかるけど。

>>373
もともと361ではデータチェックの話をしてるんだからIsValidで問題ない。

>>375
>>370で 'データチェック から 'エラーチェック に化けたのか…

>>370 の先走りか。

windowsの矩形無効化の　Invalid() なんてのは、無効化ではあるがエラーではない。

invalidate verb
invalid adjective

gnuコーディングスタイルのインデントと{ }の付け方が気持ち悪いんですが。

このスタイルに何か合理的な理由があるんですか？

いや、漏れもGNUのコーティングスタイルのうちインデントと{ }に関してははかなり病的だと思う…
別にGNUそのものをどうこうとは言わないが、アレだけはなんとかしろと言いたい。
どういった経緯でああなったのかは、確かに疑問ではあるな…

GNUライセンスにしたがっているコードかどうか
はっきり区別できるようするためとか。

もちろん冗談だけど。

GNU Coding Standardには「こう書くと見やすいYO!」と書いてあって
思わず天を仰いだな。

Windows 2000 のコードも、Half Life 2 のコードも

if (...){
　...
}

とかじゃなくて、

if (...)
{
　...
}

らしいよ

その方が見やすい。という人間が権限を持っているため。おれもそう書かないと
ダメな体になってしまった。
インデントの高さとカッコの高さを合わせた方が間違い少ないと思うが。

違う方式で慣れた人間が無理に使うと間違うだろうがね。

説得できないなら従うしかないな

俺としては括弧は下の書き方の方がわかりやすくてすき

統一スタイルを決めようとすると、結局は宗教論争みたいになるんだよね。
良いか悪いか、わかりやすいか否かに合理的な説明がつかないし。
つきつめると結局は慣れているか否かだし。

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

JAVAならsunか ?

この程度のことなら
後でgrepして直せばいいと思うんだが...

「中括弧をコードブロックに使わない言語」を使えば解決w
Pythonなんか悩む余地無いぞ

C に限定すれば、だが
cb 通せば統一出来る程度のスタイルの違いは
問題にする時間が惜しい。

>>390
括弧の位置は悩まなくていいが、SPACEインデント派とHTABインデント派
の争いは避けられないような（ｗ

インデントいらないってやつはいないよな？　中カッコも高さ合わせた方が間違いにくいと思う。

if() {

}
と
if()
{

}

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

Ａ宗：
　if () {
　　...
　}

Ｂ宗：
　if ()
　{
　　...
　}

と置いてみるテスト

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

プログラミング言語C第２版、プログラミング言語C++第３版、Effective C++がＡ宗なので
こっちにあわせてたんだけど。

自分はAだな。
Bだと縦に間延びしてしまって、一画面に入るソースコードの量が少なくなる…
画面小さいんだよヽ(｀Д´)ノ

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

でも条件式が長くなる場合はBで書くこともある。

ifのブロックであることを強調した上にブロックの対応性をも強調するC宗


if(){

     }

>>397
それ、本気でやったらGNUよりもキツイぞ(笑)

短いとき
if(){

}

長いとき
if(xxxxxxx

長いとき
if(xxxxx
　xxxxx
　xxxxx
){




}

長いとき・・・はない。
foo = xxxxx 　xxxxx　xxxxx ;
if( foo ){
}
と書くからね。

俺流
if (foo)
{
　xx
}
>>401のソフトの改造は嫌だ。

>>402
なんで？

基本的にFreeBSDのstyle(9)に従ってる。
>>395だとA宗だな。

>>396
昔の会社で「ステップ数稼げるからB！」とか言ってる奴がいた(;´Д｀)

if (foo) {

} else if(bar) {

} else {

}

if (foo)
{

}

/*
こめんと
*/

else if (bar)
{

}

/*
コメント
*/

else
{

}

#define ef if else

if(hoge){

}
ef(foo){


}
ef(bar){

}

#define ef else if
だろ

>>397
コロンブスの卵だな。そっちに転びたくなってきた。

>409
正気か?
条件式の長さによって、中括弧の位置が変わるんだぞ。

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

こんなソースあったら、漏れは燃えないゴミに出すね!

ソースって燃えないゴミだったのか。
ていうか、Ｃ宗はやっぱあれじゃん？ GNUの。

gnuコーディング規約はカスすぎ

敢えて言わなくてもカスって感じですかね。

しかし、敢えて言おう！カスであると！

>>412
どういう点がカスなのかな？

カスっつーか、読みづらいし書きづらいよな。

読みづらいのはともかく、書きづらいのが何とも。
整形すればいいだけというわけにはいかないし。

>411
どう見たって燃えない(萎える)ソースじゃないか。

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

#漏れ的にはコレも燃えない

書き方なんて全部統一しちゃえばいいのにな
言語ごとの癖に合わせるのがいい加減面倒臭い

というわけで、parserには柔軟性を持たせないようにしましょう（ｗ

全員、コボラーになれと？

>421
全員SQLerになってもらいます。

↓の話、スレ違いにつき移転。
http://pc5.2ch.net/test/read.cgi/tech/1087209526/106-121
> 106 名前：デフォルトの名無しさん[] 投稿日：04/07/29 23:43
> ところで値を返す関数の名前は名詞にしたほうがいいと思うが、getってつける人が多いな。
> 式の途中にget（動詞）があると読んでてキモくない？

>>ttp://pc5.2ch.net/test/read.cgi/tech/1087209526/121
> だからプロパティという概念を軸に発想しろっての
プロパティという概念を軸に発想したからって、
読み取り操作に常にgetが現れるのは必然にはならないだろ。

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

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

> いつまでも馬鹿なこといってないでプロパティのある言語で10万行くらいコード書いてみろ。
プロパティのある言語なら、
値を取得する箇所にはプロパティ名（おそらく名詞）しか現れないので
こんな物議を醸すこともない。

JAVAにプロパティがつけば即解決

クラスを使わなければ即解決

object.size = xxx;
yyy = object.size;

class Hoge{
　private int pr_hensuu;
　int getHensuu(){return hensuu;}
　int hensuu(){return getHensuu();}
}

両方使えれば解決、、、、　じゃねーよな

age、そして愚痴。

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

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

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

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

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

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

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

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

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

は駄目だとさ。

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

つまりだな。


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!」という香具師もいるかも知れないが、
コメントの開始位置が４０桁目という事は、如何にコーディングする範囲
が狭いか分かるだろう。

また「文中にはコメント入れちゃ駄目」ってんだから、要注意な引数の解
説なんかで

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

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

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

禿しくウザーですよ。

ｵﾚﾓﾅｰ

>制御文の括弧中に関数呼び出しを書くなとさ
これは確かに萎えるが、
>if ( atoi ( getenv ( TODAY_DATE ) ) == 20040819 ) {
ありえねー。

>極めつけは　「　コ　メ　ン　ト　は　４　０　カ　ラ　ム　か　ら　」　だとよ。

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

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 )

とかやっちゃえば？

>>433
大抵その手のあふぉ規約には、ローカル変数の命名規約とかあったり
するんだよな。

１関数１ファイルだとか、関数名＝ファイル名（８文字まで）だとか、
腐ったプロジェクトに放り込まれたら泣くしかない。。。

1関数1ファイルどころか
ヘッダにinclude書くなですよ。
コメントはアホドキュメントツールがフロー書けるように、コメントの形式ガチガチですよ。
関数の数がナゼか最初から決まってるから、重複コードテンコ盛りですよ。
仕様書のデータ定義は、なぜかCOBOL用語バシバシですよ。
デバッグアサーションは1行毎に1個記述ですよ。

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

…なんでこのPJにいるんだ、俺はorz

> ヘッダにinclude書くなですよ。

ど，どーやってコード書けばいいのですか(　・ω・)ﾓﾆｭ?
漏れには想像がつきませんです・・・

> ヘッダにinclude書くなですよ。
別に愚痴を垂れるほど酷い規約とは思わないが…
ヘッダにincludeを書くのは、極力避けるべきだし。
（例外はプリコンパイルの効果を狙う時）

その他は激しく同情。

>436
例えば hoge.h の中に moge.h を書かなくても、
hoge.h を includeする時は、必ず先に moge.h を include するようにすれば良い。

> hoge.h を includeする時は、必ず先に moge.h を include するようにすれば良い。

コーディングは可能だが、断じて良くない。

ヘッダに書くincludeは、ヘッダ内で使用している構造体等の必要に応じて書く。
本体に書くincludeは、本体で使用している関数等の必要に応じて書く。
勿論、2重読込み防止策は必ずやっておく。
極力書くなってのは、そういう事だ。

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

基本の基本なハズなんだが…orz
ちなみに、C++だったらもっとキレイにモジュールを独立化できるやね。

> ヘッダに書くincludeは、ヘッダ内で使用している構造体等の必要に応じて書く。
っていうのと

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

> ヘッダにincludeを書くのは、極力避けるべきだし。
> （例外はプリコンパイルの効果を狙う時）
だけから両者の違いを読み取れっつーほうが無理だろうな。

極力書くな、と、絶対書くな、は天と地ほどの違いがあります。

>>441
「ヘッダ内で使用している構造体等の必要に応じて書く」と「プリコンパイルの効果を狙う」
も天と地ほどの…

>>441-442
まとめると、「『ヘッダでインクルードするな』はうんこ」と言うことでよろしいか？

>439
>ヘッダに書くincludeは、ヘッダ内で使用している構造体等の必要に応じて書く。
（C++はともかく）Cでは余程のこと（極端に肥大化するとか）がない限り、
型定義と関数宣言の依存関係は1つのヘッダ内で収まると思うのだが。

C++は苦しいだろうが無理ではない。継承やinlineを避け、クラスメンバはポインタで持たせる等すれば
相互依存を避けられるし、そうすることのメリットもある。
（詳しくはEffectiveC++を見ると良い）

>>444
> （C++はともかく）Cでは余程のこと（極端に肥大化するとか）がない限り、
> 型定義と関数宣言の依存関係は1つのヘッダ内で収まると思うのだが。
たとえばさ、自分で作ったモジュールの中にFILE*を引数としてとる関数があ
るとそのモジュールのインターフェイス用のヘッダには"<stdio.h>"が必要に
なるでしょ。FILE*じゃなくても、time_t(time.h)とか、size_t(stddef.h)と
かも同様。もちろん自分で作ったデータ型を利用する場合は、そのモジュール
用のヘッダをインクルードすることになる。

ひとつのヘッダで収まるかどうか、というのは肥大化とかと関係ないんだよ。

>>445
どうでもいいけどtime_tやsize_tはともかく、FILE*はstruct FILE;の一行で済むだろ。

本気で言ってるのかな

>>446 は >>435 のマネージャー

>445
例えば FILE* を受け取る関数を作ったとして、その関数を使うソースでは stdio.h もincludeする必要があるのは自明。
（stdio.hをincludeせずに、どうやってその関数に渡すファイルを開くの?）
この場合、暗黙にincludeしてしまう方が気持ち悪いと思うのだが…

>>449
「このヘッダをインクルードするときは必ず先にstdio.hをインクルードしてください」ってか？
includeの順番なんて気にしたくねぇだろ。

.hに暗黙でincludeさていたとしても、
明示的にもう一度.c/.cc/.cppでincludeすればいいだけで。

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

ま、この辺はレガシーなしがらみだよな。ヘッダが必要とかどうとかは。
事実Java/C#なんかはヘッダファイルという概念はないし、
こんなものはコンパイラがやるべき仕事だというのは確かだろうと思う。

> struct FILE;の先行宣言だけでちゃんと.h単体のコンパイルが通るなら
> それはそれで別にいいと思うけど。

いや、ダメだろ。

> struct FILE;の先行宣言だけでちゃんと.h単体のコンパイルが通るなら

通んないっしょ

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としても通らないっしょ

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

>454
ついでに標準Cライブラリのヘッダも見ておく事をお勧めする。
中でincludeしているヘッダはほとんど無いよ。
WinAPI とか C++のヘッダはincludeしまくりだけど…
あと記憶が定かじゃないが、準標準ライブラリでincludeの順番を指定してるのが
あった気もする。

>>455
>使いにくさとのトレードオフで手に入るメリットがあるのだよ。
さっさとメリットを言えよ。

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

ほとんどない、だからなんだよボケ。

>>453-454
すまん。手元で確認したら確かにコンパイル通らなかった。
ためしもせずに言うものじゃないな。申し訳ない。

>>452
が、やっぱり「先行宣言だけでちゃんと.h単体のコンパイルが通るなら」
別に良いと思う。
いや、まあ、今回の場合はその仮定が成り立たなかったわけだが・・・
その点はすまんかった。

そうえいば、FILE型って別に構造体である必要が無かったような気がする。

>456
>メリット
・例えばあるヘッダに含まれる関数が不要になったため、関数と一緒にヘッダも削除した所、
　今まで正常にコンパイルが通っていた場所でコンパイルエラーが多発するようになった。
　…という経験は無いかい?
　まぁ賢い皆さんなら何故エラーが起きたかすぐ分かるだろうが、
　アフォPGはこれで何時間も悩んだりする。それを防止する。

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

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

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

>>459
> 例えばあるヘッダに含まれる関数が不要になったため、関数と一緒にヘッダも削除した所、
> 今まで正常にコンパイルが通っていた場所でコンパイルエラーが多発するようになった。

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

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

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

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

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

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

そんなのは証明と言わない。ただの例。

>>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>

いくらでもあるけど。

C++Builderの include 直下だけでも，2600以上ヒットするなw
こいつ，どのソース見ていってるんだ?

オロナミンC/C++かな。

あ，わかった
C(OBOL) だ

>>464
素晴らしいオチだｗ

>>463
オフコース !!

オロナミンC++を使いたいのですが，どこで買えるのでしょうか？
ご教示よろしくお願いします。 >> マネージャさん

>>467
大塚製薬 オロナミン C++ を発表
http://www.horobi.com/jokes/oronamin-C++.html

Turbo C の話題がでてないことが悲しいです…

>>468
ありがとうございます。これで今後ヘッダに #include 書かなくて
済みそうです。感謝です。

>>459 の降臨まだー？

age

471のリクエストに答えて再降臨ですよ。

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

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

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

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

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

>461,462
「C標準ライブラリ」以外のヘッダが混じってますよと。
ちなみに漏れが見たのは、>454へのレスである事を考慮すれば分かると思うがVC++。
他のはノーチェックだった。その点はすまんかった。

>>473
> 「C標準ライブラリ」以外のヘッダが混じってますよと。
それがどうかしたの？
標準ライブラリのヘッダ内でインクルードしてるのは沢山あるわけで、
「中でincludeしているヘッダはほとんど無いよ」ってのが嘘であることに変わりはない。

>それってインクルードガードかけて無いだけでは?
文脈からinclude足りてないってぐらいは読めって、つっこまれるぞ。

>>473
混乱してきたんではっきりさせてくれ。

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

>>450の「includeの順番なんて気にしたくねぇだろ」に対して、
>>455で「使いにくさとのトレードオフで手に入るメリットがある」と言って、
提示したメリットが>>459なんだから、
>>459は上のふたつのうち、２を選んだ場合のメリットなんだよな？

>>473
つまり
　includeの順番に気をつけさせることで手に入るメリットなんか無かった
ってことでいいのか？
そこをはっきり言ってくれ。

まだメリットがあると主張するなら、>>459を反省して
隙の無いレスでまとめてもらえるとありがたい。

期待age

　　　　∧＿∧
　　　 （　・∀・）　ﾜｸﾜｸ
　　oノ∧つ⊂）
　　(　（　・∀・）　ﾄﾞｷﾄﾞｷ
　　∪（　∪ ∪
　　 　と＿_）__）

遁走の予感・・・

>477
んじゃ次は…手抜きでコレ。
　ttp://lagendra.s.kanazawa-u.ac.jp/ogurisu/manuals/c/C-faq/C-faq-10.html#10.7

>>481
どう読んでみても，

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

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

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

と，メリットしか書いていないが。

引用が足りなかった。

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

と，普段使っている方法を使えば問題ないとしか書かれていない。
メリットばかりじゃん。

>>481
あんた日本語読めないのか？

ｺﾎﾞﾗｰの予感

>> 例えばあるヘッダに含まれる関数が不要になったため、関数と一緒にヘッダも削除した所、
>> 今まで正常にコンパイルが通っていた場所でコンパイルエラーが多発するようになった。
> 例えばあるヘッダに含まれる関数が必要になったため、ヘッダのインクルードを追加したところ、
> そのヘッダ内部でコンパイルエラーが多発するようになった。
> 目くそ鼻くそだな。
目くそ鼻くそどころか悪化してると思うぞ。
見つからないヘッダを「このファイルが見つからないから開けない」って指摘してくれるツールは知ってるが、
へッダに手を加えず「お前はこのヘッダを include していない」って教えてくれるツールは見たこと無いぞ。

>>486
どっちの場合でも「このファイルが見つからないから開けない」とはならないだろ。

前者はなる
後者はならない

ああ、どっちもならないかも。

そもそも
> 例えばあるヘッダに含まれる関数が不要になったため、関数と一緒にヘッダも削除した所、
> 今まで正常にコンパイルが通っていた場所でコンパイルエラーが多発するようになった。
ってのがまず起きないな。

>>489
いや、起きるだろ。

>482
(入れ子にすると)makefileの保守が面倒になるって所とか。
逆に入れ子にしない事で、makefileの保守が容易になるという意味である事はわかるね?
分かりやすく例えると、grep一発で任意のヘッダに依存しているファイルの一覧を作成できるって事。

…もしかして「grepでできる」のメリットが理解できないとか?

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

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

ただ、その一覧が欲しくなること自体があまりなさそうなので
「grepでできる」のメリットが薄まってしまっていると思う。
総じて、「使いにくさとのトレードオフで手に入るメリット」としては受け入れ難い。

>>491
> (入れ子にすると)makefileの保守が面倒になるって所とか。
オイオイ、「とか」って言ってるが、これまでさんざん要求されてるにもかかわらず
いまだに他に何も利点が挙げられてないってわかってんのかよ。
そもそも手書きで「makefileの保守」なんて言ってること自体どうしようもないけど。

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

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

どうも459はCがわからないだけじゃなく日本語も不自由なようだな。

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

>493
>そもそも手書きで「makefileの保守」なんて言ってること自体どうしようもないけど。
ごめん、最近物忘れが酷いんだ。
どこで言ってたか教えてクレ。

モ(ﾟ∀ﾟ)━ウ( ﾟ∀)━( ゜)━( )━(` )━ダ(Д` )━メ(´Д`)━ポ(;´Д`)━━━!!!

お前らよくこんなつまらん議論を延々と続けられるな。
「includeの入れ子を避ける」と、例えばヘッダAを修正した結果、ヘッダBが必要になったら、
Aを使ってる全てのソースを修正しなきゃならんのだぞ?
少し考えりゃ、百害あって一利無しだと分かるだろ。

組み込みで、あるCPUボードでの開発をした時に
標準ヘッダを入れ子にしていたのだけど
再利用で、別の処理系で使ったところ
こちらの標準ヘッダでは一部のルーチンがライブラリになく
ユーザが作成することになっていたため
入れ子をやめるか、ダミーの関数を作成するか
の判断に迫られたことがあったように思います。
それ以来、入れ子はやめて、ヘッダのファイルヘッダにコメントで
「事前に、〜を使用するため〜のヘッダをincludeするように」などと
使用条件を書くようにしました。

組み込みで、32bitのCPUなのに、未だに lp　と付けてしまう漏れは orz
だって見やすいんだもん。。。。

>>497
> こちらの標準ヘッダでは一部のルーチンがライブラリになく
> ユーザが作成することになっていたため
その処理系がヘボなだけ。

> こちらの標準ヘッダでは一部のルーチンがライブラリになく
> ユーザが作成することになっていたため
> 入れ子をやめるか、ダミーの関数を作成するか
どっちにしろ使ってる関数なら作る必要があるんでね？
宣言してるだけで使ってない関数ならダミーの関数すらいらない。

そもそもヘッダでincludeしないのなら、
インクルードガードとか言うテクニックが広がる分けない。

>>ヘッダAを修正した結果、ヘッダBが必要になったら、 Aを使ってる全てのソースを修正

??
あと、ここで議論されていたのは、「ヘッダでは絶対includeしてはいけない」は有効か、なんだけど？

すまん、今意味がわかった。
…ﾏﾀﾞｱﾀﾏｶﾞﾈﾃﾙﾖorz

>>499
そういうレスは想像してたけど
ヘボなのはわかってるけど、元受の指定なので。
ヘボだろうとなんだろうとどうしようもない。
やらざるを得ないので。

>>500
そういやそうだ。あれ、なんでだったけな。。orz

>>504
> やらざるを得ないので。
愚痴はよそで垂れて。

この話題の結論は、
「ヘッダの入れ子include禁止、というコーディング規約は糞」
で、もう異論はないかね？

「ヘッダ内で不要なヘッダをincludeするな」ならまだしも
「ヘッダの入れ子include禁止」だもんなあ。
糞規約だな。

↓ 糞コーディング規約に関する次の愚痴，どうぞ

保守age

ポインタ禁止とかprivate禁止とかって実在するのかね

>510
ポインタ禁止は（C言語だと）流石に仕事にならんだろう…
でもprivate禁止は以前ネタで挙がってた気が。

alloc禁止ならやりかねない所もありそうな気が…

>>510
C++だと、ポインタ禁止にするとアホが駆逐されるからやりやすいよ。

>>513
それはそうかもしれんが、正直あんまりやりたくはないな。
自分の手足（＝ポインタ）が縛られてでも馬鹿に邪魔されないことがどれだけ重要かにかかってるな。
手足縛られるよりも酷いことになる馬鹿が居るんだとすると禁止でもいいかもしらん。
ところで参照は使ってもいいですか？

ただ、一部プラットフォームはそのAPI呼び出しにポインタ必須だからなぁ。
WindowsとかWindowsとかWindowsとか。例外処置？

はぁ？API呼び出しに、ポインタ必須じゃないプラットフォームを逆に聞かせろや

お前はWindowsしか知らんくせに、Windowsバカにしたい年頃なだけだろがボケ

嗚呼　Windows無くなったらおまんま食い上げだわ俺　鬱

>>515
周りの所為で自分に悲劇が降って来た嘆きながら
その実自分が回りに悲劇を振りまいた張本人だったというパターンだな

完全にC++のインターフェイスを用意してるプラットフォームの方が珍しいだろうなぁ。
C系のインターフェイス呼び出しにはどう頑張ってもポインタが付きまとうし。
そういう意味ではポインタ禁止はかなり厳しいのは確かだろうな。

ポインタ禁止と抜かしつつ、マクロで隠蔽したポインタを強制するプロジェクトなら実在するかも。
某診断室みたいなサイトにサンプル転がってないかな。

>>519
もう診断室はいいよぉ。いまさらだよぉ。

ポインタ禁止と言う事は、文字列使えないし、動的なメモリ確保も行えない。
関数のコールバックも使えないから、UIからの入力も受け取れない。
かといってコンソールからの入力もFILE*が必要だから出来ない。

何も出来なくない？

>>521
だから、C++だってば。
（もちろん完全に排除ってのは難しいと思うけど。）

C++はよくわからんのですが、
ポインタ使わずに、レジスタとか絶対アドレスをたたけるんですか？

>>523
C++にはポインタ演算のできないポインタのような参照がある。
ただ絶対アドレスは叩くのはたぶん無理。

>>524
ありがとうございます。
じゃあ組み込みには使えない規約ですね。

>>525
そりゃそうだ。
けどあえてむちゃくちゃを言わせてもらおう。

アドレスにマップされているレジスタとか絶対アドレスだったら、
アドレスをリテラルで用意しておけばポインタを使うことにはならないよね？（ｗ
（ポインタへのキャストは必要だけど）

asm使えよ。

で、結局リファレンスとポインタ共存は仕方ないとして(いいんだよね？)
どういう住み分けが一番いいのかな？

readに参照、writeにポインタだろ。

>>529
それらの区別は基本的にconstの役目。

つまり、参照は const でしか使わないということ。

配列ならポインタ、配列でなければ参照、などと適当な事を言ってみるﾃｽﾂ。

>>529
設計思想に無い意味を与えるのはよくない。しかも代替がある。
その住み分けがよいとは思えない。

ポインタは極力リファレンスに置き換えるべきだ

と書いてある本があるけど、端的な話？
それともほんとにそれが理想？

>>534
ポインタはオブジェクトを単に指し示すだけでなく、
配列演算やヌルポインタなどの意味ももれなく併せ持ってしまう。

参照であれば、単一のオブジェクトを指し示すだけの意味に絞れる。
意味が絞れれば、コードから意図を汲み取りやすい。

納得できる理由まで�dx

このスレ結構勉強になるんで、前スレも欲しいんだけど
誰かうｐしてくれませんか？専ブラの生データでもいいんで

>>535
int &func(){
int *ip=NULL;
return *ip;
}
参照型でヌルポインタが出てきたときの解りづらさときたら(ry

>537
∧＿∧
(　´∀｀)ぬるり

>537
まあこんなのは悪意があるか、よほどのうっかりさんでもない限り作られないからな。

>>539
以前、失敗したらNULLを返す関数の戻りが返される参照型の関数があって
外側で
int &hoge=func();
if(&hoge==NULL){
…
}
って書く羽目になった orz

1行80文字制限は無視してるヤツが多いのか。
オレもいい加減止めようかな。あんまり意味ないっぽいし。

制限すると今度は改行したあと、どこまでインデントするかで悩むんだよね。
メソッド呼び出しの引数が分割されたとき、
Method()の(で合わせるか、普通にインデントするだけにするか、とか。

>>541
> 1行80文字制限は無視してるヤツが多いのか。
オレはその制限で縛ってるよ。オマケに1インデント8文字分だし。
長過ぎる名前や、ネスト深くなり過ぎるとすぐに気づく。

引数の分割は普通にインデントしてる。

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"
);

だな。

タブ縛りはやめてくれ。

>>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;

>>545
そのCreateFontの例、俺もやってたことあるけど、
関数名を置換したときにインデントまでいじる必要が
出てくるのが面倒だった。
今は>>543の後者にしてる。

>>546
たしかにインデントし直すのはめんどいな。

インデントは半角「２文字」だの「４文字」だの言う割には
「秀丸のタブ設定変えるだけでいいよ」と言う。
でも正直4000円払っているか否かは多いに疑問…

関数名が長くなるとどんどん右へ寄ってってしまうのが嫌
Windowsの関数名ってやたらに長いし

漏れは xyzyy の c++mode を一部変更して使ってます。
(インデントにタブ使用禁止してスペース数を設定くらい)
普段は何も考えずにインデントされていくし、
[Tab]キーを押せば自動整形されるから超楽チン。
もう秀丸なんて使えないね。

xyzzy まんせー！！

↓IDE(ryと書く奴

vim最強伝説

すいません、質問です。
うちの大学の教授が、実習にて
｢プログラムのコメントは一行ごとに書くこと。
自分の書くプログラムすべてにコメントを入れるのはプロなら常識｣
「会社では、構造体のメンバを一個追加するためにも上司の書類が必要｣
とのことですが、プロの皆さんとしてこれはどうなんでしょうか？
プログラムの可読性を重視するという点についてはまったく異存はありませんが、
｢コメントが少ない｣と言う理由でレポートを突っ返された日には……

一行ごとに書くわけねーだろｗ
有名オプソコードでも提出してやれ。

つーか、むしろコメントは最低限じゃないとだめだろ。
まともに書いてあるコードならそれだけで何やってるか分かるはずだし。
必要なのは「なぜこの方法にするか」とかコードから読み取れない
メタ情報じゃないのか？

むしろ、無駄なコメントはかえって可読性を落とすよ。
コメントがあるとついついそっちで理解しようとしちゃうから、
コードだけ修正してコメント直し忘れたりすると、
バグが混じったとき永遠に気が付かなかったりするし。

// クラス something のインスタンスを制作
instance = new Something();

みれば分かるよ・・・・・・('A`;)

見りゃ分かるコードにコメント入ってると激しくウザイな。

もっともCでいうところの構造体のメンバに関しては簡単に増減できないと思う。
C++でいうところのメンバ変数がすべてpublicのclassなわけだから、
その構造体使ってるところ全部コード見直す必要が出てくる。
書類どうこうはまぁともかくとしても、勝手に弄って欲しくはないかな。
増やすくらいならどってことない気もするか…？

>>557
構造体でもファイルにそのまま保存したりとかあったりすると勝手な追加はやめて欲しい

>>553
大きく間違ってはいないと思う
要するに、行き当たりばったりで作るなということ
コメントも、書けないのと書かないのでは違う
コメントを入れたからといって効率おちるものではないし
学生のうちは書いておいて損ではない

あーなるほどな。
まあ、必要なコメントと不要なコメントの区別がつくようになるまでは
なんでもかんでもコメント入れるのは（訓練として）悪いことじゃないかもしれん。
ここで愚痴ってるってことは多分そのくらいのことは分かる自信があるくらいには
やれると思ってるってことなんだろうと思うが、大抵先生ってのは頭固いのが多いから折れとけ。
どうせ会社入ったって頭の固い上司ってのは居るもんだし、
そういう意味でも悪いことじゃないかもしれん。

ま、「プロなら常識」ってのは一体何年前のプロだよ？　って感じなのは確かだが、
上司（ここでは教授）の顔を立てておくのは世渡術として身に着けておくと良いかも知らん。

それとも、「そこは間違ってる」と教授に対して主張できるのは学生の特権かねぇ？

学校名と学部さらしとけ。
いまどきそんなアフォが居るとは･･･

アフォとは思わん。
ろくに書けないうちに中途半端な技術で、出来ると気になってこの業界に来られても困る
>>553 が反抗したいだけなのか、まんどくさいのを正当化したいだけなのか
いずれにせよ、言う事聞いとけ。間違っちゃいない。

>>563
アフォだな。

　　　　　　　　　　　　　　　　　　　　　　　　 ,､ｧ
　　　　　　　　　　　　　　 　 　 　 　 　 ,､ '";ｨ'
_＿_＿＿___　　　　　　　　　　　　　 ／::::::/l:l
─- ､::::;;;;;;;;;｀ﾞﾞ''‐ ､　 　 __,,,,......,,,,_／:::::::::/: !|
　　. : : : : : : ｀ﾞ'ヽ､:::ﾞヾ´::::::::::::::::::::::｀ﾞﾞﾞ'''‐'､. l|
､､ . : : : : : : : : r'":::::::::::::::::::::::::,r':ぃ::::ヽ::::::::ヽ!　　　　　　　　　　　　　　　　　,､- ､
.ヽ:ﾞヽ; : : : : : :ノ:::::::::::::::::::::;;､-､､ﾞ::: 　 　 rｰ-:'､　　　　　　　　　　　　　 　 ／　　 }¬､
.　＼::ﾞ､: : : :./::::::::::::::;､-''"::::::::::　　　,...,:::,::.,　:::':､　　　　　　　　　　　　_,,/,,　 ,､.,/ 　 }
　　　ヽ:ヽ､ /:::::::::::::::::::::::::　 　 　_　　｀ﾞ''‐''"　 __,,',,,,___　　　　　　　／~　　 ヾ::::ﾂ,､-/
　　　　 ｀ヽ､:::::::::;;;､､--‐‐'''''',,iﾆ-　　　 _|　　､-l､,},,　 ￣""'''¬-, '　 ''‐-､ .,ﾉ'ﾞ,i';;;;ﾂ
　　　_,,,､-‐l'''"´:::::::'　　,､-'" ,.X,_,,､-v'"''ﾞ''yr-ヽ / ﾞﾞ'ヽ､,　　　 ,.'　　　 　 jﾞ,,, ´　>>564またまた〜ご冗談を
,､-''"　　 　.l:::::::::::;､-''"　 ,.-'　　ﾞ､""ヾ'r-;;:l　　冫、 　 　 ヽ､ /　 　 __,,.ノ:::::ヽ. /
　　　　　　　l;､-'ﾞ:　　 ,／　　　 　 ゞ=‐'"~ﾞﾞ')　./.　＼　　　　/　　'''"/::::;:::;r-''‐ヽ
　　　　　,､‐ﾞ ヽ:::::..,.r'ﾞ　　　　　　　　 ,,. ,r／ ./　　　 ヽ.　　 ,'　　 　 '､ノ''"　　　ﾉ
　　 ,､‐'ﾞ　　 　 ﾝ;"::::::.　　　　　　　"´ 'ﾞ ´　/　　　　　 ﾞ､　,'　　　 　 　 　 　 ／
　　'　　　　　／/:::::::::　　　　　　　　　　　　{.　　　　　 　 V　　 　 　 　 　 ／
　 　 　 　 ／ ./:::::::::::::　　　　　　　　　　　　',　　　　　　 /　　　　　　 　 /
.　　　　／　 /:::::::::::::::::.　　　　　　　　　　　　',.　　　 　 /　　 ,.､　　　　 /

いや、可読性の高いプログラムを書くことに関してはなんら異存はない……
それに必修授業の担当教官にケンカ売ったって仕方ないし……

だがな、お前ら自分の書いたプログラムの一行ごとにコメント入れたいか？
無駄なコメントを入れるのは嫌だやりたくない……重要なのは可読性であってコメントじゃないはずなのに……
こういう非生産的な作業は本当に気が滅入る……

>>563
なんで高級言語が出来たと思ってるんだ？（ﾌﾟｹﾞﾗ

>>566
完全におまえは正しい。
ただし本当のプロなら、非生産的でも、理不尽でも、クライアントの要求は実現するものだ。

大は小を兼ねる
個人的には不満も出るだろうが、
生徒全体に教えるという意味では、最初はそういうもんでいいんでない？
生産的どうのこうの言ってたら何も出来んよ

まぁ漏れは>>568の意見に賛成だな

>>569
兼ねないだろ。
意味の無いコメント増えたら見づらいし、
意味があるとしてもコンパイラにチェックされない分、保守性も著しく下がる。

コメント書く癖が付いてなけりゃ、コメント書くのめんどくさいとしか思わないだろうが
コメントを非常識に多く書かされてりゃ、コメント書く癖は付く
その上で、どのぐらいが適度・適切なコメントなのか判断が付くようになる

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

見づらい、保守性下がる、などは言うまでもないこと
ただ、教育というものを考えればそういうのもアリだと思うが

>>571
根拠は？

アセンブラでｽｹﾞｰトリッキーな最適化コード書くときは１行ごとに説明入れたりしたが、
高級言語ではソースそのものが処理を説明していないとな。

>>571
禿同
まだ、なにが必要でなにが必要でないか判断もつかないのに生意気言うなというところ
とにかく書けよ、書けばわかるさ
反論してる奴は、たぶん（ry

>>574
根拠は？

つか、
>自分の書くプログラムすべてにコメントを入れるのはプロなら常識｣
だの
>「会社では、構造体のメンバを一個追加するためにも上司の書類が必要｣
だのは素人の妄言にしか聞こえない。

>>576
>「会社では、構造体のメンバを一個追加するためにも上司の書類が必要｣
これはあるが。

大げさに表現して、学生に言い聞かせようとしたか
真性なのか、どちらかだろうな

>>568
なんか腑に落ちた。
彼には皮肉のひとつやふたつ言ってやりたいけど、そんなことせずに
淡々と糞レポートを仕上げるべきなんだよな。

とは言えやっぱりやりたくない……
こんなことで時間を浪費するくらいならもっと生産的なこと(わいせつ画像収集等)をしていたほうがましだ……うう

コード見りゃわかる、といってろくにコメント書いてない奴が
あとで自分で見てパニクってたな
結局やめていって残された奴がひどいめにあったが
そうかと思えば、若い奴で　やっとコメント書いたかと思ったら
i=100; // i に100を代入する
みたいなコメント書きやがって（ｒｙ

おっと、ここは愚痴を書くスレじゃなかった

>>579
まー教授も学生が理解できてるか採点しなきゃいかんから
そんなこと言ってるんだと思っておくのが一番いいんじゃないか。

いや、実は教授はコードが読めなくて、コメントを見て判断してるに違いない。

i++;　　　　　　　//教授から評価を増加

過ぎたるは及ばざるが如しってな

>>579
ソースに見たまんまのコメントを追加するプログラムを作るんだよ
  i=100; // i に100を代入する
とかのレベルなら可能だ

それ面白い。
誰か作ってJOKEソフトとして(コメント入りのソース付きで)公開してくれ。

それいいな！
はじめにひとつ作っておけば後々の課題すべてに対応可能だな。

>553
その教授は授業でサンプルコード書いたりしないのか?
サンプルコードに1行毎のコメントが書いてなかったら、プロじゃないのかと小一時間問い詰めてやれ。

教授は別にプログラマとしてはプロじゃないよな。

もちろん学生もな。

大学ってアマチュアの溜まり場ですよね。ﾌﾟﾌﾟﾌﾟ

と、入社１年目のやつが語る。ﾌﾟﾌﾟﾌﾟ

>589
そう返されたら
「プロでもないのに知ったかぶってるんじゃね-YO!」
でトドメ。

単位もらえなさそうだなｗ

まぁ、必修じゃなければそれでもいいが。
俺も先生が気に入らなくて切った選択講義がひとつだけあるな。
プログラミング関係というかソフトウェア開発関係の講義だったかな…

マッキントッシュのことをマッキンと呼ぶのはやめて欲しかった。

パッキンフォッシュとかアホっぽいのがいいな

マクドナルドをマクドと呼ぶのなら
マッキントッシュをマッキンと呼ぶのが普通。

マクドナルドがマックなら
マッキントッシュもマックで良いが。

いーや

マクドナルドはマクド
マッキントッシュはマックだ

マクドナルドのフライドポテトの事をなんて呼ぶんだよ。
関西人が幾らあほな事を喚いたところで、マクドナルド自身がマックと呼んでいる事実は覆らない。

ネタにそんなムキになって突っ込まれてもな…(；´Д｀)

つーか略し方はお上が定めたものをそのまま受け入れるよりも
顧客側が呼びやすいものを選ぶものだろ？

顧客「マッキーでお願いします。」

マクドはマクドや！
マッキントッシュはMacやからマックって言うんや！

何か文句あるんか！？

ある。

ロッテリアはロッテって言うのか？言わんだろ
マクドはマック、マックはマックだ

ってことは、malloc は「マロ」でいいっすか。

分かってないな。
名称の頭を取るのが関西方式という訳やないねん。
マクドは結果的に頭だけ取った言い方やけど、そこから法則を決めつけるのは頭悪すぎやねん。

とりあえず貴様らを同化する。

まいどに語呂が似てるからマクドなんだろ
普段使ってるリズムだから使い易いわな
さわりは弱く、語尾を強くというイントネーションに合わせたらマクドになると

でもマックはマックだ。

>>605
ｴﾑｱﾛｸ

マクドシャイク
マクドフライ
てりやきマクド
ビッグマクド

>>608
callocはｼｰｱﾛｸ？

そうそう、こないだ「すてゅっどいん、すてゅっどいん」ってコードレビュー中に連呼する人がいて、
何のことかと思ったらstdinのことだったみたい。
「とぅくぴっぷ」思い出しちゃって、笑いこらえるの大変だった。

そろそろ言ってもいいかな

どこが「コーディング規約」よ？

すまん、まさかかような流れになるとは。

コーディング全体から見て、俺のは３割がコメントになる。
普通に書いていれば、そのくらいの割合。
Cだろうが、COBOLだろうが。大体においてそのくらいになる。

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


みんなのコードはどうよ？

どうでもいい

日本語が意味不明

http://flex.ee.uec.ac.jp/www/japanese/riron/rule/source.html
> 変数名の長さは、プログラムの中の10 行以内で独立に使うものを、 1 文字 (i,j,...),
> 20 行以内で独立に使うものを 2 文字 (i1, i2, etc) プログラム全体に渡って使うが非常に
> 頻繁に使うものを 3 文字, common 変数は 6 文字、というように文字の長さがその性質を示すように設定する。

……どうなのかと。

>>616
そういうルールならそう書くだけです。

コメントを書くまでもない慣用句の多い言語を使えばよい。
言語の不備をコメントで補うのは本末転倒。

自分では可読性の高いコードが、他人にとっては可読性が高いとは限らない。
三ヶ月後の自分が、自分のままであり続けるかどうかも保証されていない。

そういうのを思考停止と言います

三ヶ月後の自分で作ったライブラリって妙にメソッド名が厨臭く感じて拒絶反応が出る

漏れ式。
・ローカル変数は極力短く。
略語を使い、プレフィクスはなるべく付けない。（ポインタを表すp程度に留める）
・メンバ変数はなるべく意味を詳細に。
略語は使わず、型プレフィクスもメンテに支障が出ない程度に使用する。(※)
・グローバル変数には上記に加えg_を付ける

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

こんなんで良いのだろうか。批判よろ。

途中で型を変えるなんて設計が悪い

>623
あっしは型とかスコープじゃなくて、ポインタとか宣言とかの形態で
プレフィックスを付けとります。
ポインタ: p_somethingとかauto_ptr at_somethingとか。

オブジェクト、ポインタ、型(宣言)は、結局同じものの別の側面を
表しているだけのような気がしますな。

キャスト問題は割り算とかでは避けられないからあんま気にしない

>>625
auto_ptrや他のスマートポインタはポインタのセマンティックスで
動作することを念頭に置いているわけだし、たとえばスマートポインタの
場合、仕様変更やリファクタリングの結果、他のスマートポインタに
変更する可能性も十分あることから、at_somethingなどという
プレフィックスよりはp_somethingの方が優れているのでは、
とは思うな。まあ、俺はポインタでもプレフィックスは付けないけど。

ちょっとまて、auto_ptrに対応するプリフィックスが at_ なのか？
どっちにしても型を反映するプリフィックスは総じて嫌だが。

型なんてコンパイラの警告である程度(気休め)

変数の型をあらわすのってプレフィックスより
サフィックスの方が良いような気がする。

私はハンガリアンはまったく使わないな。必要性を感じない。
たまにポインタの p をつけるぐらいだ。

思わん

>627
shared_ptr weak_ptr 生ポインタあたりを混在させることが多いからね
それぞれに名前考えるのも面倒だし


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

確かにshared_ptr <-> auto_ptr あたりはありそうだけど、
リファクタリングして名前変更すれば良いんじゃない？

> リファクタリングして名前変更すれば良いんじゃない？
それが嫌だってんだよクソッタレが。

>634
でも、smart pointerの種類を変更すると所有権の扱いが変わるから、
何も変更せずに済むとも思えんけど。

>>635
それは「所有権の扱いが変わった」ことを反映した変更だ。
型が変わったから名前を変えるんじゃない。

うちのコーディング規約
グローバル変数は
m_
をつける事ってあるのだが、
クラスモジュール内の変数はどう名前つければいいんだろうか・・・
標準的なm_だと被るし

もう変数の頭に型名完全明記でいいじゃん
int int_i, int_j;
型変わったらリファクタリングブラウザで一括変換。そんだけ。

>>637
FValue;
なんてclass fieldのfをつける流儀もある(Borland Delphi)。

>636
>それは「所有権の扱いが変わった」ことを反映した変更だ。 
もちろん、名前が「所有権の扱い」のはっきりわかるものだったら
問題ないけど……

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

#local scope内の話なら別にどうでもいいけどね。

>>640
所有権の扱いが重要な場所でそれを名前に表すのは問題ない。
その方法として型名を名前に付けるのは安直で脆い。

>641
重要じゃない場所はそんなにないと思うけどね。
まあ、全部shared_ptrにしちまえば問題ないか。
＃効率はともかく

>>640
それも一理あるね。

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

データメンバの場合はgetter、setterなどのメンバ関数と
名前がかぶりやすいのでなんらかのプレフィックスなり
サフィックスを付けるのはしかたないとは思うけどね。

>>642(625)
型名を名前に反映させるなんて、まったくナンセンスなんだよ。

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

こんな形になってたら、その考え方でどうやって名前を付けるのかね？

>643
>各オブジェクトを識別するためにあるのであって、言語 
>レベルの制約によってその識別子の命名法が左右されるのは 
>抽象化の意味がないと思う。

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

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

確かにそうだけど、smart pointerは取り扱いを間違えると
ひどい目にあうからね。
まあ、これは私がタコだと公言しているようなもんだけど……

>644
いや、関数は使い分ける必要無い（別の側面が無い）から
そのまま命名してもいいんじゃない？

所有権の微妙な問題も無いし。

>>646 関数の名前じゃないだろ。アフォか。

>>646
>>644は、仮引数のpのことを言ってるんだと思われ

まあ、所有権が明らかでないポインタを渡すのは
好ましくないとか言いそうだな、君は。

>647
スマン、テンプレート引数のことか。
使い分ける必要無い（所有権を気にしなくていい）としたら何でもいいし、
特定のpointerに限られるとしたらそのpointerを示す名前にしたら
いいんじゃない？

……shared_ptr & 生ポインタのみつうのはどうしようかね？

スマートポインタで痛い目に遭ったのかもしれないが、
そろそろその傷の痛みを忘れる時期じゃないかね。

うお、仮引数pか……
これもテンプレート引数と同様に、何を想定しているかによって
変えますな。

>>651
templateでPointer受け取るようにしといて、
「おれは生ポインタを想定している」という理由で p〜 にするのか？

templateの意味無いじゃん。ほんとでちゃんと考えてしゃべってる？

>templateの意味無いじゃん
なんで？

たぶんおそらくスレ違い

>>653
特定の型を想定しているなら、型をtemplate引数にする意味が無いだろ。

templateを知らないんならともかく、こんなこと説明しないとわからないの？
嫌な言い方になるが、自論に反する情報はわざと目を背けてるように見えるな。

>特定の型を想定しているなら、型をtemplate引数にする意味が無いだろ。 
別にsmart pointerの種類を特定しても、templateのメリットが無くなるわけじゃ
ないと思うけど……自由度は減るけどね。

確かにスレ違いだな……

遅レスだが、サフィックスならFlashのActionScriptでやってるな
エディタと連携させるアルゴリズムが単純で面白い

反応無くなったね、656……
スレ違いだけど自己フォロー。
smart pointerの種類を限定している例として有名なのにSTLコンテナが
あるよ（悪名高いCOAPのこと）
また逆に引数に指定されたオブジェクトの所有権を譲り受ける場合は、
auto_ptrで明示した方がいいわけで……
smart pointerの種類を特定することが悪いわけじゃないですな。

>>658
おぉ。言葉の意味は良くわからんが、とにかくすげー必死だな。

えーと、STLコンテナがsmart pointerの種類を限定しているって？
意味がわからないし、聞いたことも無いな。
会話がしたいのなら、エスパー以外にもわかるように説明してね。

>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*突っ込めるなんて考えてないよね？

>>659
俺は625じゃないが、言いたいことはわかるけど、STLコンテナには
auto_ptrを入れてはいけないというのは規格で定められているよ。
COAP(Container of the auto pointer)は駄目って。

>>660
STLコンテナに auto_ptr を入れることができないのは、
要素の型に Assignable Concept が要求されていて
auto_ptr はその要求を満たさないから。
STLコンテナが auto_ptr を格納しないように設計されているのではない。

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

話を趣旨に戻すが、
型名を名前に反映させるなんて、まったくナンセンスなんだよ。

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

……というか、ポインタごとに名前考えるの面倒臭くない？

>662
>STLコンテナが auto_ptr を格納しないように設計されているのではない。 
いや、>661も指摘してるけど、C++標準はSTLコンテナにauto_ptrを格納しない
ように設計されている（=COAPを禁止している）よ……

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

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

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

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

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

fclose(input);

>>664
規格で決められてるってんなら、セクション番号で示してもらえる？
それができないなら、何を根拠に「規格で」とか「標準で」とか言ってるわけ？

ちなみに、↓を検索しても auto_ptr はひとつもヒットしないよ。
ttp://www.kuzbass.ru/docs/isocpp/lib-containers.html

>665
オレはこうだけど……

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

//local scopeのみ
FILE* ipt

……まあ、ファイルポインタは普通ポインタしか使わないから
プリフィックスはどうでもいいけど。

fclose(ipt);
どうにも、糞コード確定のような・・・。

>667
つながらん……
ちなみに根拠は「C++標準ライブラリ チュートリアル＆リファレンス」
と「Effective STL」ね。
ANSIはどっかに行っちまったので確認できないや

>>659
エスパーじゃないから、お前の糞具合もわからないって寸法だ。

>>667
FILE*はfpだろうが。えっ、違う？

俺だったらfpInputかpInputFileだな。

俺だったら
infp
outfp

625はウンコだな

>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++の"未定義"は"禁止"とほぼ同じだと思うけどね。
＃単に安全装置が付いてないだけ。

ウンコは放置しよう。

>>674
ハゲしくスレちがい。>>666みたいなウンコは放置してくれ。

↑うんこはお前だ

>>553 への化石レス

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

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


関数を呼び出すたびに「関数名、引数、戻り値」を全部コメントつけなきゃならんから、
引数が３つある関数を呼ぶだけで、既にコメントは５行になるからな・・・

>>678
常識的でないというより、生産的ではない
でも、学生にはそのくらいでいい。
それと、
いろいろあって、今の君の会社で今のルールがあるんだと思う
無駄だと思うなら、君が上司になった時とりやめてしまえばいい。

http://pc.2ch.net/tech/kako/1012/10127/1012715148.html

派遣の漏れにそんな権限はねーよ

「strncpyする前に、コピー先のメモリブロックを
　memsetで'\0'で埋める必要は無い。」
という規則を作りたい。本当に作りたい。

>>682
もっと広く「意味のない memset をするな」のほうがいいだろう。

>682,683
strncpyは '\0' を付けてくれない事があるから、全くの無意味ではない。
無駄ではあるけどさ。

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.
だよ。

longerな場合に付けてくれないだろ

列挙値などの定数をすべて大文字のスタイルにすることの是非を教えてください。
+ ソース中で定数であることがわかると読みやすい（値について文脈を無視できる）
- 名前空間（クラス名）の修辞と組み合わせると汚い（例： File::READ_ONLY ）
- マクロと区別できない（「全て大文字はマクロのみ」というルールと比較した場合）

是非を確定するまで行かなくても、↑で挙げた +/- についての突っ込みや
+/- の追加でもあれば、お願いします。

>>687
非。大文字だと
-入力しづらい

>>688
わはは。じゃぁ定数に限らず全部大文字にしたほうがいいな。

>>689
日本語は読めていますか？ﾏｼﾞﾚｽのつもりだったんだけど。

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

非。大文字だと
-読み辛い

> 全部大文字の識別子が列挙値定数か定数定義マクロかの判別が、すぐにはつかなくなる。
判別する意味があるのか？
> 定数であることをすぐにわかるようにするための方法としては識別子の命名工夫のほうがbetterだろう
では何故定数定義マクロの時にこうしなかったのか？

>>691
まともな反論を、ありがとう
>> 全部大文字の識別子が列挙値定数か定数定義マクロかの判別が、すぐにはつかなくなる。
>判別する意味があるのか？
意味があるのか無いかは、わからない。ただ「無い」と断言するだけの背景もない。
>> 定数であることをすぐにわかるようにするための方法としては識別子の命名工夫のほうがbetterだろう
>では何故定数定義マクロの時にこうしなかったのか？
知りません。単に慣習だと思いますが。
列挙型というものは本来のCには無かったということを考えてみて下さい

「ありそうだな」と考えていた反論が来て面白い。
貴方は全大文字にすべきだと考えているの？

Cにenumすら無かったことがあるのか。知らなかった。

だから今でもenumはいまいち多用されていない感がある。

プロトタイプ宣言も無かったが多用されてるよ。
enumが多用されてないのはそれほど使いどころが無いか、明らかな利点がないか
じゃない？

>>692
> 知りません。単に慣習だと思いますが。
> 列挙型というものは本来のCには無かったということを考えてみて下さい
「列挙型」が無いとしても「定数定義マクロ」で「命名工夫」はできるだろ。
「慣習」で大文字だけになったんだろ？
「列挙型があるかないか」と「命名工夫をしなかったこと」には何の因果関係も無い。
君プログラマに向いてないよ。

ただ今の決まり手：秘技「君プログラマに向いてないよ。」切り

enumが多用されてない理由を考えてみた。
- int型と同じサイズになってしまう。(c++では改善されてるが)
- constにした方がｳﾏｰ
- ソースの外部で定義できない。
- マクロの条件式で使えない
- grepで検索できない。

>>696
「マクロを作ったけどコード上では変数か定数かすぐにはわかんないな」
「シンプルな言語仕様にしたのに言語仕様の追加なんぞしたく無いぞ」
「じゃあ変数は今までのとおり全部小文字、定数は全部大文字という習慣にしよう」
「いい考えだ。俺たちがこれから全部そうすれば、みんな真似するだろう」

Cではconstは定数として使えないからenumの方がこの点では勝ると俺は思うのだがなぜか使われていない。
Windowsのウィンドウメッセージも#defineが使われている。連番になっているのだからenumのはまり役だと思うのだが。

>>696
>「列挙型があるかないか」と「命名工夫をしなかったこと」には何の因果関係も無い。
因果関係なんぞはもちろんありませんよ。
当然の事ながら命名工夫というのはコーディング規約レベルの話です。
そして「定数定義マクロを全部大文字にする」というのは命名工夫の一種ではあるのですが、
また慣習であってこれはコーディング規約に優先します。
私は「後から出来た列挙型定数における命名工夫として、
既存の定数定義マクロと同一の命名工夫を使用するのは反対です」
と言っているだけ。
貴方の主張が読み取れません
「定数定義マクロを全部大文字にするというのが気に入らない」では無いですよね？
ご自分の主張を>>687に対してレスしてみたらいかがですか。

>君プログラマに向いてないよ。
もう手遅れですが

列挙型が最初からあったとしたら全大文字にはならなかったとでも？

>700
ウィンドウメッセージの値は複数のヘッダに分散して定義されてるから、
enumは向いてないような。

>>701
>私は「後から出来た列挙型定数における命名工夫として、
>既存の定数定義マクロと同一の命名工夫を使用するのは反対です」

俺は「変数と区別しやすい」という方を優先したいな。
逆に定数マクロと列挙型の区別がしにくいとしてもさほど不便を感じない。
定数マクロと区別したいケースってのを例示してもらえばわかりやすいのだが。

>>704
>俺は「変数と区別しやすい」という方を優先したいな。
俺漏れも

>>704
レスをありがとう
>俺は「変数と区別しやすい」という方を優先したいな。
>逆に定数マクロと列挙型の区別がしにくいとしてもさほど不便を感じない。
>定数マクロと区別したいケースってのを例示してもらえばわかりやすいのだが。
はい。それはそれで一つの見識だと思います。ただ
「マクロで定義できるのは整定数だけではない」という問題がありますね。
列挙型の場合は整定数ですが。
これについてはどうでしょうか

静定数以外のマクロを許したら、どんな立派なコーディング規約を
作っても台無しだと思うが。

>>701のコーディング規約がどんなものか、一度見てみたいな。
＃マクロの名称規則ひとつに静的/動的の別、影響範囲とか、
＃事細かに規定しているんだろうか。

>>707
整定数って、整数型の定数ってことだろ。
整定数以外のマクロって許すも何も、
FLT_MAX とか NULL とか offsetof とか標準にも山ほどあるんじゃないの？

>>706
> 「マクロで定義できるのは整定数だけではない」という問題がありますね。
それからどうやって「整定数を全大文字で書くべきではない」に繋がるのかが分からない。

>>708
おお、読み間違えていた。
でもそれだとますます意味がわからんな。
int型の値を持つマクロとfloat型の値を持つマクロがあるからといって
どうだというんだろう？

>>709
定数を区別するために全大文字の名前を使うということは、
全大文字の名前を見たらそれは定数であると期待できる、
ということになるだろう。

その環境で、定数ではないマクロが全大文字で定義されていたら、
読み手に誤解を与える可能性が、、、、、あるかなぁ？

>>711
> >>709
> 定数を区別するために全大文字の名前を使うということは、
> 全大文字の名前を見たらそれは定数であると期待できる、
> ということになるだろう。
そう。それが全大文字で書かれている理由じゃないのかね。

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

int row = 3;
if (row > const_max_row) {
　　// error
}

-↓のようは
+↓のような

要は#defineであろうがなんであろうが
・定数は全大文字
ってことだろ。
逆に、#defineであっても
・定数でなければ全大文字にしない
だろ。
errnoグローバル変数なんて#defineだったりするんだが、
それでも明らかに定数では無く変数として扱っているから
全大文字にしない。

>>714
関数型マクロはどうする？
C++ で Class::CONSTANT や Namespace::CONSTANT はOK？

>関数型マクロはどうする？

普通は使わんな。
どうしても使う必要がある場合は、完全に関数として振舞うマクロとして作成し、
関数の名称規則に従う。要は定数か変数か関数か、その振る舞いに対して
名称規則を適用するということ。
マクロのような変幻自在のものをひとくくりにした名称規則を作っても意味がない。

>>715
716も言ってるように、関数として扱うのだから関数の命名規約に沿うべき。
マクロかどうかを区別できないとか言ってる香具師はこれが分かってない。

「引数付きマクロを関数として扱う」って
本当には関数に出来ない理由があるからじゃないの？

型チェックとか引数の評価の違いとか、見かけ上構文は関数と同じでも
マクロだと気をつけなきゃいけない点があるから、関数型マクロといっても
むしろ関数の命名規則より、それが関数じゃなくてマクロだとわかる規則に
従った方がいいと思う。

#include <ctype.h>のisXXXX(c)なんてマクロなんだが。
errnoもグローバル変数に見えて実は関数だったりする。

普通は使わんな、てなことは無い。

>>719
> マクロだと気をつけなきゃいけない点があるから
getc, getchar, putc, putcharを使う時に何に気を付けてる？マジレスキボン

> getc, getchar, putc, putcharを使う時に何に気を付けてる？
たとえばgetcなら、引数に副作用のある式を渡すときは気をつかうよね。
fgetcだとそんなこと気にしなくていい。

>>719
その通り。何も考えずにマクロを使うと「一見関数のように見えるけど実は...」
というケースが頻出して管理しきれなくなる。
そういう事態を避けるために多少コーディングの自由度を制限してでも
管理性/保守性を上げようというのがコーディング規約だろう。

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

>>719の規約では、有名なBEGINマクロみたいなのは許されるの？
許されないとしたら、使っていいマクロとそうでないマクロを切り分ける
基準は何？

>>723
保守性はまだしも。管理性ってなんですか？
「管理性」の一般的な語義として「把握する」というのがありますが。
「管理する対象」と「管理する目的」が全くわからない。
ｽﾚﾀｲそのものの存在理由に関わる問題だと思うので回答請う

> 保守性はまだしも。管理性ってなんですか？
723じゃないけど、manageabilityってことでは？

アレだよ
関数いっこ、変数いっこ作るのに
上に申請して
受理されて
振番してもらって
やっと使えるヤツ

>>725
manageabilityですか。なおさらわからなくなります。
その言葉はOS運用、ﾕｰｻﾞ、電源、ｾｷｭﾘﾃｨなどに使用されますが、この場合は管理対象が曖昧です。
ソフト生産について沢山の開発組織体がそれぞれの取り組みを行なっている現状下において、
ソースコードの管理単位として「いわゆる関数」という粒度にとどまらず、さらに細粒度の管理を行なう傾向があります。
ファイル名／関数／関数名にとどまらず、インクルードファイル／マクロ／マクロ名／変数／変数名
なども（多くの場合DB化して）管理するのです。管理の粒度についての私見は差し控えますが、
「ｺｰﾃﾞｨﾝｸﾞ規約の目的として管理性を付加するのは、
その種の取り組みを行なっている組織だけでの事ではないのか」と思う次第。
ｺｰﾃﾞｨﾝｸﾞ規約の存在目的自体の認識がずれていると議論も混乱すると思うので、
あえて>>724で質問／確認してみたのです。

>>726
そういう運用をしているところもあるでしょうねｗ

>>722
> たとえばgetcなら、引数に副作用のある式を渡すときは気をつかうよね。
どういうこと？具体的に副作用が出る式を書いて見てくれない？

>>727
「『管理性』という言葉」に対する認識はずれているようだな。そういう大仕掛けで
仰々しいものだけが「管理」だという思い込みがあるのかな？
>>723に書いたのは保守性とほぼ同義だと思ってもらっていいよ。目的が保守に
限定されるわけじゃないからああ書いただけで。

>>729
了解しました。ありがとう御座いました。
決してイチャモンをつけるつもりで質問したわけではない事をご理解下さい

>>728
*p++

そんなのgetcの引数で使うか? putcならまだしも

FILE *f[10]
とか？

>>731
それでホントに副作用出るのか？

*pの値が変わる、というのは副作用だよ

関数呼び出しも副作用だよ。
例えば
FILE *getdatafile() {
　static FILE *datafile = fopen(...); //C++だけど
　return datafile;
}
で、getc(getdatafile()); とか。

まあ、実際にこんな使われ方されることはまず無いとは思うけど
絶対にないという程ではないんじゃないかな。

>>735
getcが関数だと変わらないの？

>>737

.....まず「副作用」の意味から調べてきな。
薬の副作用とは違うから。

>>738
...まず規格によってマクロで実装されているとされているものについて調べてきな。

誤：実装されていると
正：実装すると

>>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.
とまで明記されてる。

「全部大文字」で思い出したけどマイクロソフトっていろんなものを
全部大文字にしてるよね。あれを不愉快に思うのは俺だけ？

たとえば？

たぶんVOIDとかのことだろう

BOOLとかUINTとか
あれ何でなんだろうね

>>745
マクロだからだろ。

>>745-746
ちゃんとtypedefを使っている。

もとはマクロだったとか

Java方式の関数名の最初に小文字を使うメリットって何かありますか？

>>749
Javaなら、Java方式であるということ自体がメリットになるんだろうな。
C++とかの他の言語でやるメリットはわかんね。

C++でもコードの見た目が柔和になる気がする。主観だけど。

｢prefix｣って
　｢プレフィックス｣なのか｢プリフィックス｣なのか気になったので
gooで調べてみた。
　俺には｢プリセックス｣としか聞えなかった。orz

Winアプリ作ってきた俺でもハンガリアンだけは受付ねー。
命名規則に言語依存の意味をくっつけるな。
pDataとかもいらん。ポインタのvectorとかだとdata[0]->xとか結局
pとか付いてないのに->アクセスになるし。
だったら変数名はGNUの規則でいいや。

変数名はおいといてGNUの{}のつけ方はいただけない。

BOOL GetQueuedCompletionStatus（
　HANDLE CompletionPort,　// I/O 完了ポート
　LPDWORD lpNumberOfBytesTransferred,
　　　　　// I/O 操作中に転送されたバイト数を
　　　　　// 受け取る
　LPDWORD lpCompletionKey,　　// ファイルの完了キーを受け取る
　LPOVERLAPPED *lpOverlapped,　// OVERLAPPED 構造体への
　　　　　// ポインタを受け取る
　DWORD dwMilliseconds　　　// オプションのタイムアウト値
);

なんだよこのLPOVERLAPPED *lpOverlappedという表記は。

BOOLを大文字にするな！
なんでCompletionPortはハンガリアンじゃないんだ？
もうね、pとかlpとか付けなくていいよ、ウザイから。

もともとのNTの命名規約はハンガリアンじゃないんだよな
Win16の亡霊がこんなことろにも

>>752
プリンセスとｾｸｰｽ!!

http://www.possibility.com/Cpp/CppCodingStandard.html

int aSex[10];
vector<int> vSox;

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

たとえば if とかの書き方を

if (0<a) {

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

if( 0<a ) {

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

foo (a,b) ;

って書かないでそ？

>>761
括弧の内側に空白を置かないのは一般的な英文がそうなっているから。
ifと(の間に括弧をあけるのは関数呼び出しと違いを際立たせるため。

といっても、関数呼び出しと勘違いするようなアホはたまにしかいないから面倒だなと思う。
たまにいるからやむを得ないんだろうけど。

ずっと if(0 < a) だったんだけど、
Visual C# 2005 のエディタが
if (0 < a) に訂正しやがるから、最近は自分のこれになってきた。

キーワードの後ろの ( はスペースを1個、関数呼び出しは詰める、だね。
理由は>>763らしいけど。

問題はキーワードでも関数呼び出しでもない sizeof 演算子をどうするかだ。
括弧つけない？

つける必要がある場合はつけて、つける必要がない場合はつけない

>>766
話題はsizeofと括弧の間にスペースを入れるか入れないか、ではないのか？

括弧がある場合は付けなくて
ない場合は付ける(というか付けないとコンパイルエラーになるから
スタイルの問題ではないか)

>>765
sizeofはキーワードだろ。
俺はsizeofの後には空白を開ける。

演算子であり、キーワードである

sizeofは括弧を詰めて記述していた俺は間違っていたのくぁっ！

好きに汁

ほｓｙ

array→ary 、manager→mgr など、3文字の英語で表す際の
規約みたいなものが書いてあるサイトってありますか？
ググっても見つからなくて。。
manage→mng なのに manager→mgr とか理解不能です（汗

>>774
そんな化石のようなルールが本当に今必要なのか？
たいした理由も無ければ array, manager とフルで綴れ。

>>775
Webアプリ開発でURLを短くしたいので、知りたかったのです。
例えば、コーディング規約は遵守しているのに
master→mtr とか間違えて命名してたら格好悪いなぁと思いまして。。

>>776
Web アプリの URL はユーザーが使うんだから、
コーディングの規約じゃなくてアプリの仕様として考えるべきじゃないの？

言葉の綾でしょうが、ソース内の変数名でも間違えたら恥ずかしい、
URLについては色んな意味（GETメソッドは255バイトまでなので短くしたい等）
で調べたい、それだけです。

>>778
> GETメソッドは255バイトまでなので短くしたい
これ、本当？何の仕様？
フルで綴れよ。間違えようも無いし。

IE6だと498バイトだな

>>780
IE6に限定しないなら255が一般的かと。

>>775-779(780に対してではないです)
貴方も分からないのであれば変に突っ掛ってこないで下さいね。
他で尋ねます。では。

個人的には変数名はフルで綴るより短い方がいいかな
長いとエディタを横スクロールさせないといけないことが多くなるし
たまにある20文字以上の変数名(クラス名)とか勘弁して欲しい

短い名前は大いに結構だが、短くした名前は混乱の元。

きちんとコメント入れとけば混乱することは無い

manager が mng になったり mgr になったり man になったり
そういう混乱はきちんとコメントを入れても避けられない。

そのためのコーディング規約だろう。
規約が守られなかったらってのはまた別の話。

きちんとした命名規約があるなら
短くした方がいいよ
規約があるのか知らんが

規約ウザイからなるべく増やしたくないんだ。
だいたい省略のルールなんて文書に起こそうと思ったら大変だろ？
（大げさな話、チェックもできるようにしようと思ったらもっと大変だろ？）

フルスペルのがいいと思うんだけどなぁ。
短くしたメリットや、古スペルにしたときのデメリットなんて、
ほんとのところ深刻な奴は無いんじゃないか？

>>782
20 文字程度で長いですか？
VGA で開発してます？

２０文字っていうと lexicographical_compare() とかでもアウトか。
C++ 使うのは辛そうだな。

ミスです 20文字じゃなくて30文字です
20文字なら超えてること結構ある(´ρ｀)

俺がつけた一番長い関数名は、55文字
ちなみに趣味じゃなくて、仕事で、ちゃんと出荷もした
コーディング規約もコードレビューも無かったからな

COBOLは文字制限あったな。
名前空間がないと結構つらいかも。

前カンマ派なんだけど、
みんなはカンマどっちにつける？

こーゆーの
select id, name

select
    id
    ,name

二項演算子で行を区切るときは、式の継続が目立つように行頭に演算子が来るようにしている。
その流れで、カンマで行を区切るときも行頭に来るようにしている。

頭を揃えたいがために演算子は行末にぶら下げてた

カンマは前派だなあ。
行末だと、なんか目がちらつく感じがする。

#SQLのインデントは結構迷う。

俺も今日から行頭にしよう

詳細設計書作るときに気をつけてることある？
こんなん気をつけてるけど、
・書式、文言の統一
・同一処理は参照で

具体的かつすぐに理解できるように気をつけてる

コメントいっぱい埋め込んでツール一発OK

>>801
それは、情報量だけ多くて本質的なところが見えない悪い仕様書の例。
doxygenで何でもかんでもYESにしてドキュメント吐かせるとよくわかる。

詳細設計がどのレベルをさしているのかマチマチだけど
コードに近いものなら、そんなドキュメントいらんよ。
その上の機能設計がしっかりしていれば、それでいい。

1年前くらいにやった仕事の命名規則

関数名： u1g_PRODN_MOD_SMOD_GetCnt_pstu2

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

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

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

これが日本の組み込みソフトの品質を保つ……本当か？

TextSS　のWindowsXP(Professional)64bit化おながいします

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

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

>804
名前のマングリングを人が、人のためにやってるのか…

>806
( ･∀･)つ〃∩ へぇーへぇーへぇー
マングリング
コンパイラは関数に装飾された名前（以下、装飾名）を作成します。
リンカは装飾名を使って、別ファイルにある関数や変数を参照します。
関数を正しく呼び出すのに、関数名だけでは不十分な場合があり、
名前を装飾することをマングリング（mangling）と呼びます。

"static"使うときってどんなとき？
今まで"static"って複数ユーザで
使いまわすモノだと思ってた...

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

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

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

return this.singleton;

>>808
意味がわかっていればそんな疑問も湧かないはずなんだが。

>>809
同意。

>>808
singleton なクラスにだけ使っとけ。

そもそもコーディング規約と関係ねぇ

>>774
亀だが、
http://www.thefreedictionary.com/
の、Acronym に色々あるべ。

↑スペルミスがあると思うけど気にするな。

Javaでいう”インスタンスメソッド／変数”と”クラスメソッド／変数”の区別は、
C++ ではstatic宣言の有無で区別するので強力ですよ。
Singleton用途でGlobalスコープにおく意図だけでstaticをつかっててはMOTTAINAI。
あ、Javaでも同じですか.... へんなことかいてたらすみません。

>>808
意味的に 型で共有されるべき操作な時とか
Utilityクラス
あるクラスを定義したとき、そのNullオブジェクトとか定数とか

>>811
いやいや、そういう使い方を定義する規約ってのも存在する。

>>815
ちょ、「static就職子はSingletonパターンを実装する際にしか使用してはいけない」
とかいうコーディング規約あったらマジキレるぞ俺。C++にしろJavaにしろだ。

ちょ、就職子てｗｗｗ
修飾子な

>>817
>>816 は、「static 就職子は Singleton パターンを実装する際にしか使用してはいけない」の「就職子」の誤字にキレちゃうんじゃない？w

>818
816と817は同一人物だろ。

ヒロシです。dummy を dumy と略すのはやめて欲しいとです。

ヒロシです。
getUserNameを、getUNとかに略すのやめてほしいとです。
メソッドの目的がさっぱりわかりません・・・('A`)

>>821
国連をゲットするんでしょ。

getUcchanNanchan

将来、使われなくなると予想される　変数　Maxは
asMax とする

東MAX！

C++で、ストリーム演算子をクラスのfriendにする必要が無い場合、
ストリーム演算子の宣言はクラス定義の外に置くべきでしょうか。

外に置くと、クラスの利用者がヘッダを見た時に見落としそうな気がしています。
と言って、friendをつけたままだと、演算子のソースコードを見た時に違和感があります。

Javaでコーディングしてるんだけど、
クラス変数や引数の宣言にこんなことやってる。
目的は、ソースの可読性を自分なりに向上させたいってところ。

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

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

他に、どんなやりかたあるのかな？

>>826
外だな。別ファイルでもいいが。
もはやオブジェクト指向とはアンチパターンである
クラスをいかに使わないかだ

>827
私は
クラス変数・インスタンス変数：Arg_
ローカル変数：arg
引数：Arg
です
あ，C++でした

>>829
argの意味わかってる？

>>829
なるほど。
javaだと変数名の先頭に大文字は推奨されないんで、
アンスコとかをうまく使おうかと思ってます。

('A`)

class
{
コンストラクタ
変数１
ゲタセタ
メソッド（）
メソッド（）
}
って、変ですか？

>>833
はい、恋です

>>833
・種類より public/private の区別を優先して並べて欲しい。
・「ゲタセタ」と「メソッド」を区別するのも意味なさげ。
　オブジェクトへの副作用有りと無しで分けてあると助かる。

>830
ごめん，なんも考えずに書き込んだ
ﾊｽﾞｶｼｽ

>>827
Javaのコーディング規約でいいんじゃない？
シンプルで利にかなっている。

コーディング規約とは言えないかもしんないけど、
描画オブジェクトに表示プライオリティを付ける場合、
値の大きいほうと小さいほう、どちらを手前に表示させるべきですか？

>>838
何が目的か、による。
例えば、WindowsのウィンドウのZオーダーは、0が最前面。
これは、ウィンドウを、ほかのウィンドウの後ろに持って行くよりは、
手前に持って行くことの方が多いだろうということから、
とりあえず、0を設定しておけば目的を達成できるだろうという考えだな。

特に定番があるわけじゃないんですね。
ゲームでのオブジェクトなのですが、
WindowsのZオーダーを踏襲しときます。ありがとうございました。

>828 遅くなってすみません。ありがとうございます。
別ファイルでがんばってみます。

不要になったコードをコメントアウトしていつまでも残しておくな
と主張している本があったと思うのですが、
何の本だったかわかる方いませんか？
プログラミング作法かコードコンプリートのような、けっこう
定番のものだったと思うのですが。

>>842
CVSとか使ってコード管理していると、
その手のコメントアウトがどれだけ残す意味のないものか良くわかる。

>>842
一例: MISRA
なぜか#if 0は禁止していない。

関数のヘッダや関数内部に更新履歴を残すのってどうよ？
これも美的感覚としては受け入れたくないけど、
ちゃんと書いてあればけっこう助かる気がする。
いったん「どう変更されたんだ？」と疑問に思ってから
csv logやannotateする手間が省けるから。

その更新履歴が絶対正しいならそれもありだろう。
だが、更新忘れたり、めんどくさくてやらなくなったりして放置されたコメントならHDDの肥やしに過ぎない。

履歴はワードの履歴機能使うのはどうかね？ｗ
コンパイルの際はちょっと工夫がいるが

ワードの履歴はコミットしたら消えちゃうし
コミットしないと変更した場所をまた変更すると履歴が残らないので不可。

>848
「ファイル」→「版の管理」→「文書を閉じる時に新しい版を自動的に保存する」

だったらSVNでも使ったほうがずっとラクというオチに

C/C++言語の関数の引数の順序についてのコーディング規約ってあるのかな

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

memcpy()はfooのほうだけど、boostライブラリはbarみたいだ（あまりよく知らん）

>>851
<algorithm>の関数も出力が後。

>>852

STLのAlgorithm? copy関数は出力が後ろだね。

ベル研のインデアン・ヒル・コーディング規則では前がよいということになっている。
http://www.gfd-dennou.org/arch/comptech/cstyle/cstyle-ja.htm
ちょっと古いかね。

C++ の namespace の命名規則でお勧めありますか? 衝突しにくくする
工夫とか、気をつけたほうがよいところとか。疑似 URL で表現しろとか。
または、これはダメ、という例でも良いです。よろしくお願いします。

>>855
ソースファイルのディレクトリ構造と一致させる。

>>856
例えばこんな感じですか?
namespace fuga::include::MultiMethod
namespace fuga::src::TriState

ただ、ここまで深い階層をつける予定はないので、どちらかと言うと、
最上位の名前空間(↑で言うところの fuga)を定義する時のポイント、
すべきこと、すべきではないこと、工夫といったあたりでアドバイスが
頂けると嬉しいです。

>>857
#include "fuga/include/MultiMethod.hpp"
とか書いてるならそうなる。
別件になるんだろうけど、ヘッダのパスに "include" が現れるのはクドイね。

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

あ、検証方法として、名前空間内の名前をグローバルから
全部読み上げてみて違和感がなければ OK とか。

かぶらないことが目的だから
くどすぎるくらい長い方が安全かとも思う。

>>858
include パスはコンパイラオプションで指定するので、実際には
#include "MutiMethod.h"
ですね。ライブラリを置く場所はユーザーの都合で変えられてしまう
こともあるから、あんまり物理的な位置に依存しないほうがいいのかな。
例えば、/usr/local/include にインストールされるヘッダなどは、この
手が使えないわけですよね。