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

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
垢版 |
2007/10/28(日) 15:59:01
コーディングスタイルについて熱く語れ
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
富士通みたいな所だな。
2011/02/22(火) 12:38:52.11
某fj2で、携帯作ってるトコなんかだと
自動的にテスト仕様書を生成するために

//:　unkがmoreそうな場合はleaveする
　if (iUnk < iMore) {
　　User::Leave(EGodBlessYou);
　}

みたいに、「//:」を0カラム目にしてコメントを書け
という規定があるね
2011/02/27(日) 23:18:33.78
プリプロセスの#includeとかが行頭にないとコンパイラがスルーしたことならあったな。
もう直ったのかshc
2011/03/02(水) 16:28:45.71
20年くらい前かな
関数名のプリフィックスを2文字、機能単位で3文字、ユニークな部分を3文字に制限された
チームがあった
2011/03/02(水) 20:36:20.17
うっせーバカ！現在進行形だ！
2011/03/06(日) 19:22:45.45
今まさに、boostが使えない（or入れるのに手間がかかる）プロジェクトに居るんだが、
std::auto_ptrのみで、このスレで紹介されたような状況を対応する方法はあるのだろうか？
2011/03/06(日) 19:35:04.41
>>693
コピーしたときの妙な特性さえ把握してれば普通に使える奴だよ std::auto_ptr は。
何が心配なの？
2011/03/10(木) 22:21:32.27
>>694
すまん、書き方が悪かった。
一番聞きたかったのは、boost::sheard_ptrでないと解決できないような問題は存在する（多いのか）？
大抵の問題はstd::auto_ptrを駆使すれば問題を解決できるのか。

boost::sheard_ptrはboostが使える環境でないと使えない。（あたりまえだけど）
で、組込み系だと使えるライブラリが制限されていることは多いんで、
boostがあれば解決、だと、現実解にならない場面が多いのよ。
2011/03/11(金) 00:39:48.77
仮に boostがあれば解決だったとして、
boostが使えない環境で boost::sheard_ptr 相当の、
あるいは必要な部分だけの機能を自作することは現実的ではないの？
2011/03/11(金) 01:27:42.99
>>695
そんなもん、「作るものによる」としか言えないに決まってるじゃねーか。
心配している「状況」を挙げないと。
2011/03/11(金) 19:06:21.02
>>695
スレ違い。
本を読んで自分で考えろ。その後まだ質問があれば、適切なスレで質問するといい。
2011/03/20(日) 01:23:32.02
std::auto_ptr はコンテナ（vectorとか）との相性が悪い。
2011/06/05(日) 05:34:53.68
横に長いソースはやめてください
フルHDのモニタでエディタ全画面表示にしてもラップするって酷いお
2011/06/05(日) 06:57:16.18
フォントがでかすぎるんじゃねぇの?
2011/06/06(月) 00:11:56.44
>>701
お前に俺の気持ちは分からない
2011/06/06(月) 01:25:22.03
しらんがな
2011/07/03(日) 22:33:58.14
２０１１年、Ruby,Perl,PHP,Pythonって並べたときにさ
ここで、Ruby以外を選ぶ奴ってマジでなんなんだろうな


本当にバカだな
2011/07/03(日) 23:46:31.28
巣に帰れ
2011/09/17(土) 23:31:20.71
C++のコンストラクタ初期化子のインデントについて

CHoge() : hoge1(0), hoge2(0), hoge3(0), ...

この初期化子を1行1メンバで並べるときインデントはどうしてますか？
VS2008だと半角スペースが2つ入るんだけどMSはそういうスタイルなのかしら
2011/09/18(日) 00:35:41.14
VS って自動で埋め込まれるインデントの
量（空白３つ分とか）をユーザーが設定することはできないの？
708デフォルトの名無しさん
垢版 |
2011/11/22(火) 12:56:04.40
どうなの？
2011/11/22(火) 16:45:32.56
>>700
同意だわ。読みづらい。
最近は異常に識別名が長すぎるんだよな。
2012/06/02(土) 18:48:09.93
場合によって、敢えて横長にする人もいるから何とも。
右側は別に文脈を読む上では重要じゃないときとか、似たようなことを連続で書く時とか。
711uy
垢版 |
2012/08/14(火) 23:40:41.70
test
712デフォルトの名無しさん
垢版 |
2012/10/14(日) 16:45:51.75
スペースやインデントは
コーディングスタイルに含めるべきではない。

これらはコードの文字の長さによって
変わるもので、決まったルールなんか作れない。
短ければ改行入れないが、
ながければ改行入れるでしょう？
2013/10/17(木) 22:14:47.56
スペース・タブ混在インデントは絶滅して欲しい。
一々ソース書いた奴のタブ幅設定の推測しなきゃならんとか腐りすぎだ。
スペースインデントは表示が崩れないだけまだマシだが、
2文字インデントとか2・3・3文字インデントとか変なルールで読むことを強要するあたりやっぱ腐ってる。
って訳でインデントはタブ文字にして、インデント幅はタブ幅設定で好きに設定してくれ。
桁揃えはインデント分をタブ文字、桁揃え分をスペースだと崩れにくい。
714デフォルトの名無しさん
垢版 |
2013/10/31(木) 13:15:45.62
整形ツール使えば気にならなくなるし
2013/10/31(木) 13:25:22.86
今作ってるツールの設定ファイルで空白・タブ混在させてるのを思い出した
よく考えたら絶対文句言われるな作りだなｗ
2013/12/14(土) 18:37:49.80
if文が深くなるの避けるために否定にして抜けるのってあり？

if A:
____spam()
____if B:
________egg()
を
if not A:
____continue

if not B:
____continue
spam()
egg()
にするの
if A and Bはなしとして
2013/12/14(土) 23:59:10.77
A=true,B=falseの時の動作が違うことないかそれ
2013/12/15(日) 05:35:07.74
>>716
そうやって間違う元だから、無闇と否定するのはよくない。
真理値表でも作れば間違えないだろうけれど、読む方が間違う元だ。
だからと言って、一々コメントに真理値表を書くのも間抜けだしね。

たまにどや顔でドモルガンの定理を使って書き換える奴いるけど、
そういう奴もしばしば書き換えに失敗しているよ。
2013/12/15(日) 14:03:29.97
>>716
その if が、エラーチェックみたいなやつなら、普通にそうしてる。
2014/03/12(水) 21:56:07.66ID:TvgG9E6E
>>713
俺がこのスレを開いたときに考えたことと
丸っきり同じ事が書いてあってびっくりした
願わくば今のソース全部再フォーマットしたいわ
2015/02/11(水) 00:06:57.40ID:/sPzO2m3
ネストしたfor文を意図的に抜けたい時、for文の繰り返し条件のところに脱出フラグも書くのってアカン？
for (初期値; 繰り返し条件 && 脱出フラグ; インクリメント) {
}
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。