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

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
垢版 |
2007/10/28(日) 15:59:01
コーディングスタイルについて熱く語れ
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の解説など
ネットで調べるなり本を読むなり該当スレへ質問するなり自分で考えてくれ
2011/02/07(月) 12:32:07
>>666
いや、俺は組み込み屋なんだが。
幸いにして関わったプロジェクトでは C++ コンパイラが使えたんで、
何の問題も無く使えている（ような気がする？）。
もちろん OS のある環境とまったく同じというわけにはいかないけど、
少なくともスマートポインタを使わない理由は無い。現に使えている。

なんだろうな？
まぁもうちょっと調べてみるよ。
2011/02/07(月) 12:39:41
スマートポインタは何を解決してくるの？
deleteの書き忘れ？
deleteを書き忘れちゃうようなコードを書く人のためのもの？
2011/02/07(月) 13:33:50
しょぼい組み込みだとコンパイラがないとか
コンパイラの信頼性とか、そういう世界なのかな。
2011/02/07(月) 14:26:40
>>668
マーフィーの法則によるとdeleteを書き忘れない人は存在しない
2011/02/07(月) 14:35:02
()や{}を書く時セットで両方記入しておいて、
カーソル移動して中身を後から書いてる。
同様に、new書いたらdeleteを直後に書く。

直後じゃなかったとしても、生成と破棄はセットで設計してるから大丈夫。
対になるものはいつも対応を取りながら進めていく。
2011/02/07(月) 14:57:55
>>667
ちなみにターゲットマシンのCPUは何でございましたでしょうか？
2011/02/07(月) 17:30:18
>>671
だからそれを人力でやってるのが駄目なんだっつーの。
そりゃ普通そう書くよ。
2011/02/07(月) 23:04:20
>671
変なフレームワークや仕様を強要されてる場合、newとdeleteを
別々のクラス/関数/スレッド/etcで実行せざるを得なかったりして
必ずしも1対1にできるとは限らないと思う。
2011/02/07(月) 23:29:24
>>671
そのやりかただと return や例外やその他いろいろ破綻する可能性が残る。

>>668 スマートポインタはこういった問題を防ぐためにある。
2011/02/07(月) 23:31:54
>>672
ARM7,9,11 と PowerPC 系が少し。
2011/02/08(火) 01:00:25
> newとdeleteを別々のクラス/関数/スレッド/etcで実行せざるを得なかったりして

そういうときはまず設計を改めたいものだ。
生成期間の管理があやふやになってスマポに頼るような時、
すでに半分棺桶に体突っ込んでるようなもの。どの道破綻する。
2011/02/08(火) 01:23:28
>>676
ゲーム? のはずないか。
そのあたりは c++ いけるしな。
2011/02/08(火) 07:58:22
>>677
> そういうときはまず設計を改めたいものだ。
メッセージ作って他のスレッドに投げてそのスレッドがさらにまた…
ってな事はしないのか？
2011/02/08(火) 14:14:39
スマポが嫌われるのは、多分
・どれを weak_ptr にするかでどうせ後々面倒が起こって、それじゃ delete 忘れ修正の手間と大差ない
・余分なメモリアロケーションが発生するのが嫌だ
のどちらかが大きいのではなかろうか。

参照カウンタではなくリンクリストで実装された侵入型ならどちらも回避できる。
が、リンクリストでの実装は参照カウンタに比べて遅いのだとか。


スマポが delete 忘れを解決するというが、たとえばコンストラクタで new したものを
delete する程度なら、調査追跡も楽だから、スワポなんて無くていい。

スワポがあると助かるのは、例えば、寿命の管理が面倒な場合など。
例えば、何らかのキューにオブジェクトを突っ込む必要があるような場合、突っ込んだ
側にとってはもう不要だが、キューから取り出す側はまだ delete されると困る、という
ような場合。

他には例えば、 Factory メソッドで生成するとか、new するオブジェクトと delete する
オブジェクトが違う場合などは、delete 忘れの追跡が面倒になることもあるから、スワポ
が便利。

スワポが必要になる状況が無いとか、ハンドルとかのスワポ以外の対策があるなら、
別に無理に使う必要は無い。


>>679
俺はスマポ反対ではないが、そういうときにリソースをやりとりして
誰の持ち物か分からなくなるようなのは行儀悪すぎるだろう。
2011/02/08(火) 14:32:50
>>680
> ・どれを weak_ptr にするかでどうせ後々面倒が起こって、それじゃ delete 忘れ修正の手間と大差ない
> ・余分なメモリアロケーションが発生するのが嫌だ

なら std::auto_ptr や boost::scoped_ptr を使わない理由は無いな。

> スマポが delete 忘れを解決するというが、たとえばコンストラクタで new したものを
> delete する程度なら、調査追跡も楽だから、スワポなんて無くていい。

そのやりかただと代入やコピーコンストラクタや例外やその他いろいろ破綻する可能性が残る。

> スワポがあると助かるのは、例えば、寿命の管理が面倒な場合など。

スワポってなぁに？

> 俺はスマポ反対ではないが、そういうときにリソースをやりとりして
> 誰の持ち物か分からなくなるようなのは行儀悪すぎるだろう。

boost::scoped_ptr なら移動不可能な単一所有権。
std::auto_ptr (std::uniqe_ptr) なら移動可能な単一所有権。
boost::shared_ptr なら共有される所有権。

単一所有権なら誰の持ち物かは明白。
共有される所有権が誰の持ち物か分からなくなるのは、まぁ当然だよね。
2011/02/08(火) 14:33:54
s/std::uniqe_ptr/std::unique_ptr/
2011/02/08(火) 15:16:56
> 他には例えば、 Factory メソッドで生成するとか

createみたいなメソッドはもう格上げして、
使う側からしたら　(new, create) <--> delete
という扱いにすればその心配はないかも。

deleteの追跡とやらは、createを呼び出した側での話しになる。
2011/02/08(火) 21:24:29
>>658
> なんせ未だにカラム制限のあるコーディング規約もあるくらいだ。
Linux カーネルとか *BSD とか Solaris とかのの話か?
685680
垢版 |
2011/02/08(火) 23:55:19
>>681
> なら std::auto_ptr や boost::scoped_ptr を使わない理由は無いな。
scoped_ptr の類まで嫌う人たちがいるのかな？

> スワポってなぁに？
市況2板を見た後だったので FX 脳になってた。
2011/02/09(水) 00:31:41
>>684
んにゃ、某大手家電メーカーの特定部署。1行80カラム以内で
コメントは(行単位でないなら)41カラムだかどこだかより前に出現してはいけない。
インデントも確か特殊だった記憶がある。
2011/02/09(水) 10:18:54
あー、そういう環境じゃしょうがないよね。
2011/02/13(日) 00:26:14
>>686
富士通みたいな所だな。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。