コーディングスタイルにこだわるスレ

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
垢版 |
2007/10/28(日) 15:59:01
コーディングスタイルについて熱く語れ
2010/12/23(木) 22:21:26
>>558
そういうトラブルは typedef を禁止したところで
なくならないし未然防止にもならない。

そもそも言語に対するスキルというか
リテラシーが低いことが問題。

名前の長さも同じこと。 不思議な省略単語濫用で
20文字以内になっても意味がない。
2010/12/23(木) 23:58:54
>>566
んなことは分かてる、なんでルールを無視するんだ？ と言ってる
実際にあった話だが、顧客指定でLaTeXでドキュメント寄越せと言われたらどうするよ
2010/12/24(金) 01:23:48
タグ名と typedef 名が同一ならよいのだから、そのくらいはヴァリデータツールを書いて、通らなければコミットできないようにしてしまえばよいのではないか。
2010/12/24(金) 13:17:29
>>568
同一ならいいってわけじゃないだろう。 >>558 は読んだか？
2010/12/26(日) 10:09:36
まぁ、下請けになめられてるんだろうな。
2010/12/28(火) 19:29:32
>>569
読んだ上で問題ないと判断したんだが、具体的にどういう場合に不具合があるんだ？
そこにある三つの問題全てクリアになると思うよ。
2010/12/28(火) 22:13:38
>>571
"they must be declared exactly once"
"the header that defines the typedef must be included before the header that uses it"

A.h で struct A だけが宣言されていて、使う側で毎度 struct A と書く場合、
使う側で A.h をインクルードせずに struct A の前方宣言で済ませることができる。

A.h で struct A の宣言に加えて typedef struct A A があり、関連する関数の宣言に
struct A* ではなく A* が現れる場合、 A* を使うためには必ず A.h のインクルードが
必要になる。

問題が３つだとしたら２つは残ってるように見える。
何か誤解されてるんじゃなかろうか？
2010/12/29(水) 18:29:41
>>572
コーディング規約にすることで未然に防ぎたい不具合の具体的な例をお願い。

> A.h で struct A の宣言に加えて typedef struct A A があり、関連する関数の宣言に
> struct A* ではなく A* が現れる場合、 A* を使うためには必ず A.h のインクルードが
> 必要になる。

根拠が分からない。
手元の三つのコンパイラでコンパイルでき、警告さえ出さない。
俺が失念している規格があるのかもしれないから、具体的に示してもらえるとありがたい。

> A.h で struct A だけが宣言されていて、使う側で毎度 struct A と書く場合、
> 使う側で A.h をインクルードせずに struct A の前方宣言で済ませることができる。

というわけで、こちらも前方宣言で済ませることができる。
ただし typedef struct A A; の一行が余分に必要になる。
ちなみに C++ なら余分の typedef も不要。


と、ここまで書いてようやく気づいたが、同じ typedef 名の typedef がいけないということか。
typedef struct A A;
typedef struct A { int a; } A;
とあると、後者でエラーになるということか。

ちなみにこれは gcc ではエラーだが、cl と bcc32 ではスルーだった。
もちろん C++ ならどれも ok。

その理由で禁止なら、支持できるが、本当にこんなことを言ってたの？
2010/12/29(水) 18:34:40
>>573
> 手元の三つのコンパイラでコンパイルでき、警告さえ出さない。

どんなコードでテストしてるの？

> というわけで、こちらも前方宣言で済ませることができる。
> ただし typedef struct A A; の一行が余分に必要になる。
...
> typedef struct A A;
> typedef struct A { int a; } A;
> とあると、後者でエラーになるということか。

前方宣言のつもりで複数のヘッダに typedef struct A A; と書いたとしたら、
それらのヘッダをひとつの翻訳単位にインクルードすればやっぱりエラーになるだろ。
2010/12/30(木) 02:33:59
C禁止にしてC++に統合しようぜ。
2010/12/30(木) 07:16:23
そんな事したらリーナスおじさんが黙っていない
2010/12/30(木) 11:06:58
俺もOOPは大好きだが、
OOPLとしてのC++にも感謝してるが、
どっちか無くせといわれたら、C++がイランなｗ
Cは必要だな。
2010/12/30(木) 15:26:15
>>573
> もちろん C++ ならどれも ok。

C++ でも微妙だったりする。
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#407
2010/12/30(木) 23:31:39
揚げ足取りならC++ならC的な書き方もできるがね。

とはいえ組み込み系だと環境構築してる間に開発期間がなくなる勢いだから
トップダウンでCを減らして欲しい。ボトムアップじゃムリポ。
2010/12/31(金) 09:26:49
>>579
組み込み系だとC++が使えない程度に貧弱なハードの場合も多々あるんだが
つか、テンプレートとか使うとC++ってコードサイズが見積もれなくないか？
2011/01/01(土) 01:27:35
逆に、constなんかはCよりC++の仕様のほうが組込にも向いているように思う。

自分の知り合いは、テンプレートは使う（もちろんコードサイズ増加は織り込み済み）が、
それよりも動的メモリ確保(malloc/new等)禁止のほうを気にかけている感じだった。
これももちろん分野によるのだろうけど。
2011/01/01(土) 04:27:25
if文の中に長い関数式を書くのはあまり好みではないので分けて書くことが多いけどどうよ
何をあほな書き方してんだと思うかいな。

if (MessageBox("保存しますか?", "内容が変更されています", MB_YESNO | MB_ICONQUESTION) == IDYES)
文;
----------------------------------------------------
const char * const pc1 = "保存しますか?";
const char * const pc2 = "内容が変更されています";
int num1 = MessageBox(pc1, pc2, utype);
// もしくは
// const LPCTSTR lpctstr1 = "保存しますか?";
// const LPCTSTR lpctstr2 = "内容が変更されています";
// uint utype = MB_YESNO | MB_ICONQUESTION;
// int num1 = MessageBox(lpctstr1, lpctstr2, utype);
int num2 = num1 == IDYES;
if (num2)
文;
2011/01/01(土) 11:57:47
え？　折角変数使うのにnum2みたいな糞名前？

そんなんつけるくらいなら
int ret = MessageBox(pc1, pc2, utype);
if (ret == IDYES)

こうするほうがまだマシでは？
else if (ret == IDCANCEL)などと続けられることも考えて。
2011/01/03(月) 13:24:29
>>580
ハード性能の貧弱さで C++ が使えなくなるなんてことはないよ。

例外、 RTTI 、テンプレートとか、機能や具体的な使い方に応じて
費用対効果が見合わないことはあるだろうけどね。
でもそれは組み込みにかかわらずあたりまえの話。

マイナーすぎてコンパイラが無いっていう方向の貧弱さを言ってるんだったら別。
2011/01/03(月) 14:07:45
>>584 主記憶64kでやってみろよ
2011/01/03(月) 14:46:28
>>585 別に問題ありませんが何か？
2011/01/03(月) 22:32:32
>>585
むしろその環境に対して C++ の何が問題を起こすと思っているのか聞きたい。
2011/01/11(火) 01:09:09
C++ が問題というよりは、組み込みでテンプレとか
ガンガン使っておいて ROM/RAM 足りませんみたいな
こと言ってくる奴が多すぎて困る。

バグったらバグったで自分じゃ解析できないから
ヘルプミーだと。 C++禁止にしようぜ。
2011/01/11(火) 23:44:50
テンプレ禁止しろよ
2011/01/12(水) 10:53:19
テンプレってリソース喰うん？
2011/01/12(水) 11:49:57
>>590 いいえ
2011/01/12(水) 12:12:04
リソースを食うコードを書いてしまいやすいと言うべきかな
593デフォルトの名無しさん
垢版 |
2011/01/12(水) 12:22:45
なにこのほほえましいスレ。
594デフォルトの名無しさん
垢版 |
2011/01/12(水) 18:43:10
>>588
禁止というか免許制にすればいいのにとは思う
595デフォルトの名無しさん
垢版 |
2011/01/12(水) 20:08:48
http://sky.geocities.jp/tcshacina/hash.c
これは？
2011/01/24(月) 02:34:22
Javaで使い終わった変数にnullセットとか意味あんの？
ゴスリングも、今のGCは賢いからそんなことせんでええと言っているし、
そもそもスタイルとして美しくないので嫌いなんだが。
あと、宣言時のnullセットも同じく。
ここの先輩諸氏はどう思われますか。
2011/01/24(月) 03:50:41
宣言時のnullセットは意味が無いな
2011/01/24(月) 09:14:31
インスタンス変数で、null代入しないとオブジェクトリークになる、
というのでもない限りいらんだろ。
2011/01/24(月) 09:17:46
GC目的のつもりの代入に限って言えば、
それを強いるなど狂気の沙汰だ。
2011/01/24(月) 10:34:58
生存時間の長いローカル変数に対して、時間がかかる処理の前にnull代入するのは意味がないこともないよ
GCの世代昇格を防いだり
2011/01/24(月) 11:02:17
>そもそもスタイルとして美しくないので嫌いなんだが。

なぜそう思う？
2011/01/24(月) 22:59:59
>>596
VB出身者が必要だと思ってるんだろ。それ。
2011/01/24(月) 23:02:00
使い終わった変数にnullを入れると安全になるって思い込んでるヤツは
よくみるな。
それで安全になるようなコードの書き方をしてるなら、そっちを見直すべき
なんだけど。
2011/01/29(土) 15:50:46
C++なら新人に多重deleteされないようにdeleteし終わったらNULL入れておくかな。
C++はNULLのdeleteは「何もしない」のが仕様として決まっているから。
無条件deleteでも問題ない話になる。
2011/01/29(土) 17:09:13
コーディングルールの話をしてて、それはダメだってことになると、
「これはヘタクソには有効だ」って反論がでてくるけど、ヘタクソ向けの
コーディングルールなんていらないよな。
だいたいヘタクソに対しても別に有効じゃねえだろって感じだし。
2011/01/29(土) 19:15:53
よう俺。
デメリットを指摘しても「でも僕はこっちの方がいいです。慣れですよ」とか言われるし。
2011/01/29(土) 20:13:55
個人でプログラムしてるのなら、
周りの人間がそいつのコーディングスタイルをどうのこうの言っても意味が無い
好みの問題に他人が口出しするものではない

が、チームを組んでプログラムしてたり、
そいつのソースを将来別の誰かがメンテしたりするのなら、
コーディングスタイルを合わせるよう「命令」しないといけない

デメリットやメリットは無意味で、問答無用で「命令」だ
2011/01/29(土) 20:37:06
もしかして:スレ違い
2011/01/29(土) 20:38:07
ヘタクソにコーディングルールを強いると、生産性が落ちてバグが増えそうで怖い。
なのでヘタクソのコーディングルールに合わせるのです。
2011/01/29(土) 20:54:06
>>609
> 生産性が落ちてバグが増えそうで怖い

見えないものを怖がるな

どのようなヘタクソに、どのようなコーディングルールを強いた場合、
生産性がどれくらい落ちて、バグがどれくらい増えるのか、ちゃんと検証すればいい

検証の結果、本当は逆に生産性が上がってバグが減るのかも知れない
2011/01/29(土) 21:51:55
>>604
スマートポインタ、最低でも auto_ptr で自分で delete 書かないほうがいいだろ。
確実だし、デストラクタでヌル詰めるとか無駄だし。
2011/01/30(日) 01:19:42
>611
>最低でもauto_ptr
そしてコンテナでハマると。

>609,610
バカをフォローする手間を省くためだと思う。
ルールを決めるに当たって
・バカでも憶えやすい・理解しやすい
・特定の条件下では最も無難
・機械的にチェックしやすい
に傾きがちなのもきっとそのせい。
2011/01/30(日) 02:32:19
昔は馬鹿を育てたんだけどな
俺も育てられたし
2011/01/30(日) 15:27:32
ポインタをnullクリアより、変数のスコープを小さくしましょうとか、
使い回しをやめろとか教えたほうがいいだろ。

ポインタをnullクリアって、バグがおきないとかバグを発見しやすくする
工夫じゃなくて、バグってもなんとなく動いちゃう工夫だし。

あと上から目線で馬鹿向けって言ってるけど、使い終わったポインタを
NULLクリアするって言ってるやつって、馬鹿向けじゃなくて本気でそれ
がいいって思ってるっぽいし。
2011/01/30(日) 15:38:08
スタイルというより教育だな。
2011/01/30(日) 15:49:28
ある程度熟達すればコーディングスタイルにほとんどばらつきが出ない Lisp 系は、
コーディングスタイルという点ではけっこういい言語かも知れない
2011/01/30(日) 15:51:29
馬鹿の度合いにもよるけどな。
とにかくいじらせるコード量を減らすこと。
今はそれで対処できるのでそうしてる。
教育できそうな馬鹿っていいよね。
うらやましいよ。
こっちの馬鹿は英単語すら読めねえんだぜ。
だから当然エラーメッセージもw
2011/01/30(日) 15:54:38
>>616
ループを回すのに、dolist や loop を使うか、map 系を使うかというのでちょっ
と悩む。
2011/01/30(日) 15:57:54
>>614
> 本気でそれがいいって思ってるっぽい
一概にそうとは言いきれない

無限ループ
入力 -> フィルター -> 出力 ==> 別プロセス

をやると, 世代別 GC しか持ってない言語だと, フィルターの出力段近くで使っ
てる変数とか出力バッファがらみの動的オブジェクトは明示的に null 代入し
ないとメモリー足りなくなる
2011/01/30(日) 16:15:53
deleteしたポインタにnull入れても無意味だし、GCある言語でも
スコープはずれたり使いまわししてる変数にnull入れても無意味。
2011/01/30(日) 17:20:47
GC目的以外ならnullは有効だろう。
シングルトンパターンでの生成を遅延させたりするとき、
bool isinitedみたいなよけいないもんを使うより単に、
Foo foo = null;
getInstance() {
if (foo == null) foo = new FooBig();
return foo;
}
とすれば満足では。

あと、Foo::delete(Foo **foo)みたいにして
中でdelete *foo; *foo = null;とかさせておいて、
呼び出し元で、それ以降の望まないfoo->bar()を失敗させるのもやった。
当時はこれでうまくいったと思ってたが、今見るとなんかアホっぽいけど。
2011/01/30(日) 17:35:24
ポインタのnullクリアは、GC関連なら特殊なパターン以外は意味ないし、
バグを防ぐって意味なら、変数のスコープを狭くしなさいとか、使いまわしは
やめなさいとかってルールのほうがいいよね。
2011/01/30(日) 21:49:58
不正アクセス防止になるじゃねーの？　JAVAなんか使わないから知らんけど。
2011/01/30(日) 22:16:04
いやならないんじゃないの?
2011/01/31(月) 00:20:16
ぬるぽが出るんじゃないの？
2011/02/05(土) 00:36:57
nullクリアが真価を発揮するのは、デバッガでソース追う時。
スパゲティなソースでも、きちんとnullクリアしてるかどうかで
デバッグのしやすさが格段に違う。

「追いやすいコード」を目指すなら、多少手間でもnullクリアをしとくべき。
読みやすさを心がけてるなら、追いやすさも当然心がけるよな?
2011/02/05(土) 01:19:09
free(p);
#if DEBUG
p = NULL;
#endif

ですねわかります
2011/02/05(土) 02:04:04
>>626
null クリアでトレースしやすくなる理由がわかりません。
2011/02/05(土) 16:34:51
>627
そしてリリース版/デバッグ版の挙動の違いに悩まされる訳ですね。分かります。

>628
一部のデバッガが、未初期化・delete後の領域に
0xccとか埋める理由を考えてみると良いかと。

とか書くとnullクリアしなくても、その機能だけでも十分とか言い出すんだろうな。
2011/02/05(土) 16:42:32
>>629
0xcc とか埋めるのはデバッガじゃないよ。
VC++ でデバッグビルドの時のデフォルト動作だったはず。

で、その機能はトレースのしやすさとは関係ないと思うんだけど、どういうこと？

うっかり破棄後のポインタを触る可能性を考えるなら、スマートポインタを
使っておけばスコープアウトで解放するんだからほぼ根絶できるし、
スコープアウト前に解放する場合はスマートポインタが null クリア相当の
ことはするし。

手間をかけてでも null クリアしとけというのはやっぱりわからん。
2011/02/05(土) 20:54:22
Javaの話じゃなかったのか
2011/02/05(土) 21:35:50
Java で 0xcc 埋めとか、無いよな。
2011/02/06(日) 18:13:55
そんなもん入ってたら大変なことになるだろうな
2011/02/06(日) 21:32:52
>>633
なんで？

プログラマやデバッガが Java の意味として解釈できるアクセス対象は、
せいぜいバイトコードまでで、そりよりしたのレベルはランタイムに依るから、
実際のところ 0xcc で埋められていようといまいと、何も起こらないと思うんだが
（正確にはインターフェースのこちら側にとっては何も起こってないように見える）
2011/02/06(日) 21:45:00
>>634
その 0xcc 埋めは Java では実装できないだろ。
JVM の実装として話すんなら C++ 以下の話だろう。
2011/02/06(日) 22:13:55
>>635
> その 0xcc 埋めは Java では実装できないだろ

だから、プログラマやデバッガの立場では 0xcc 埋めできないんだから、
実際に 0xcc が入っていても大変なことになんてなるわけないと思うんだが
2011/02/06(日) 22:22:39
>>636
そういうことか。
「Java の話ではない」って流れについて言ってるのかと思った。ごめん。
2011/02/07(月) 00:29:09
>630
>うっかり破棄後のポインタを触る可能性を考えるなら、スマートポインタを
>使っておけばスコープアウトで解放するんだからほぼ根絶できるし

それはメモリ管理が楽になるだけであって、トレースしやすさとは別の話だと思うけど。
トレースし易いってのは、nullとか0xCCとか埋められれば、特定のアドレスの値を
見れば状態が分かるとかいう事だと思うが。
2011/02/07(月) 00:32:55
0xccが無効なオブジェクト扱いになるんかいな。NULLは処理系として例外扱いだろ？
2011/02/07(月) 00:36:36
>>638
0xcc の話なら確かに「特定のアドレスの値を見れば状態が分かる」けど、
破棄後のポインタにヌルを入れてもそんなことにはならないよ。
2011/02/07(月) 00:47:22
>640
ポインタの値を見れば、そのポインタの状態は一目瞭然ですよね。
2011/02/07(月) 00:51:49
>>641
スコープアウトさせてしまえば見るまでも無く状態は明白ですよね。
2011/02/07(月) 00:56:31
>642
「デバッガでポインタをウォッチしているケース」は想定してます?
2011/02/07(月) 01:01:32
>>643
してません。何のためにそんなことしてるのかな？
2011/02/07(月) 01:36:36
例えば
　Hoge *p = new Hoge()
　if( … ) {
　　// 何かの処理
　}
　moge( p );
のようなソースで、一々ソース追わずに moge() まで飛ばしてから p を見るとか。
2011/02/07(月) 01:43:58
>>645
だから、たとえば何のために p を見るの？それで何が知りたいの？
2011/02/07(月) 01:48:41
デバッガを使わないとコーディングもデバッグもできない人が世の中にはいるようで。
2011/02/07(月) 02:39:24
>646
>たとえば何のために p を見るの？それで何が知りたいの？
仕様通りの結果が得られたかを 知るため/知りたい。
null 埋めルールが徹底されてりゃ、途中で p が delete されたかどうかも
pを見るだけで容易に分かる。
p の先を見たり、大袈裟なツールに頼る必要も無い。
「トレースしやすい」とはそーいうことです。

>647
古文書の解析にはデバッガ必須。
2011/02/07(月) 02:43:55
>>648
> null 埋めルールが徹底されてりゃ、途中で p が delete されたかどうかも
> pを見るだけで容易に分かる。

その null 埋めルールを徹底するためにもスマートポインタ使ったほうがいい（ >>630 ）
ってのはわかってて言ってるの？
2011/02/07(月) 02:49:12
>>645
いまどき生ポインタ使って自分で delete するやつなんていねーだろ。
2011/02/07(月) 03:01:24
>649
分かってて言ってます。
（勿論スマートポインタを使う方が賢いと言うことも。）

>で、その機能はトレースのしやすさとは関係ないと思うんだけど、どういうこと？
とか言ってるから、null埋めそのものがトレースにどう有益かを述べてるだけですが何か。
2011/02/07(月) 03:31:41
つまり、「おいらの頭はスカスカだから、NULL埋めしてデバッガで追わないとどうしようもないスパゲッティコーディングしかできないよ」ってことですね。判ります。
2011/02/07(月) 03:33:11
或いは、「適切にコーディングされた工芸品のようなコードでもデバッガで追わないと理解できないくらい頭がゆるゆるなんです」とか。
2011/02/07(月) 03:33:33
>>651
あぁそうなの。てっきり >>626 の「多少手間でもnullクリア」に賛同してる人なのかと思ってた。

明示的にコードを書くかどうかを別にした「null埋めそのものがトレースにどう有益か」に
異論は無いよ。ありがとう。
2011/02/07(月) 03:40:56
>652
貴方のような物分りの悪い方に「このポインタは用済み」ってのを明示するためです。
2011/02/07(月) 03:42:50
nullを埋めないと明示できないのか。
2011/02/07(月) 05:01:59
スマートポインタを使えない状況も考慮すると、NULL埋めを徹底させた方がいい気もするなぁ

実際の大規模プロジェクトの現場では、スマートポインタで統一させるのと
初期化/使用後にNULL埋めを徹底させるのと、どっちが多いんだろうか？
2011/02/07(月) 08:55:11
Cに縛られているロートルが多いと言うことを鑑みると、後者が多いと思われ。
なんせ未だにカラム制限のあるコーディング規約もあるくらいだ。
2011/02/07(月) 09:11:44
>>657
> スマートポインタを使えない状況も考慮すると、NULL埋めを徹底させた方がいい気もするなぁ

どんな状況だ？
最低でも std::auto_ptr は使えるだろ。
2011/02/07(月) 10:28:07
馬鹿なプログラマがスマポ使えないんだお。
2011/02/07(月) 11:28:21
スマポが必要になったことが無い。俺が馬鹿だからだろうか。
2011/02/07(月) 11:37:22
>>661 そのとおりか、あるいは経験不足か、あるいは経験過多です。
2011/02/07(月) 11:42:21
つまり、明日は晴天だけど時々曇りで場合によっては雨ということですね
2011/02/07(月) 11:47:12
>>659
組み込み系やデバイスドライバ開発だと
スマポが使えない/使わないケースがよくあるよ
場合によってはC++ NGでCだけでの開発を求められたりとか
2011/02/07(月) 11:50:40
>>664
それ、技術的な制約でそうなるの？（だとしたらどんな制約？）
それとも決定権のある人が無理解なだけなの？
2011/02/07(月) 12:25:09
>>665
OSが提供する安全なユーザ空間の上でしかプログラムを組んだ事の無い
アプリ屋さんだと、ちょっと想像しにくいと世界だと思う
そういうもんなんだよとしか言えないし面倒なんで詳しい説明はしない
OSの構造や設計法あるいはリアルタイムOSの解説など
ネットで調べるなり本を読むなり該当スレへ質問するなり自分で考えてくれ
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況