良いコードを書くためのノウハウを蓄積するスレ

良いコードを書きたいです。でも、書けないです。
良いコードを読めばよいと聞きますが、どれがよいコードなのか分かりません。
長くないけど、良いコードと悪いコードを比較して、わかり易く教えてください。
デザインパターン適用するといいと聞きますが、どれだけいいのか分かりません。
異常処理書くと汚くなってしまいます。
例外処理はtry{}catch(Exception e){}としてしまいます。
言語や環境、職場によって良いとされる書き方は変わります。
例えば、携帯Javaは容量を少なくするコードが良くなります。
スピードを徹底的に重視すれば、オブジェクト指向は邪魔なだけです。
関数型言語では、再帰呼び出しを使うのが上等です。
コードリーディングとか、達人プログラマーとか、
本買って読むといいらしいけど、お金ないし、
買いに行くのめんどくさいし、ウェブで見たいです。
そういうサイトつくりたいけど、頭悪くて作れません。
てことで、まとめWiki作って、勝手に書き込んで欲しいです。
トヨタ式的なものがソフトウェア産業でできてないと言うし悔しいです。
てことで、良いプログラムを書くためのやり方、良いソースの書き方を議論して、
最強のソフトウェア開発方法をまとめてください。

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

とりあえず、wiki立てたいので、いいWikiと、いいサイトと、いい名前、教えてください。

教えてほしいだけなら質問ｽﾚで質問してくれよ。

打鍵百回おのずから通づる。打つべし打つべし。

教えて欲しいだけじゃなくて、まとめたいと思っています。
書き方が悪かったですかね？
一人で考えたことではなくて、いろいろな人が考えたことを、
まとめたものがないので、作りたいということなのですが。
作ったので、使ってくれって宣伝するのも嫌だし、、、。
もしそういったサイトがあったのなら、削除依頼出してきます。

綺麗なソースを書くノウハウを書いてあるサイト
言語ごとに教えてください。
C,C++,Java,VB,Perl,Ruby,Scheme,
あんまし、無いと思うのだけど。

とりあえず、ググったら、こんな掲示板があったので、情報まとめてみます。
http://jibun.atmarkit.co.jp/scenter/bbs/viewtopic.php?mode=viewtopic&topic=10614&forum=21&start=0

キーボードに向かう前にチンコをいじって心を落ち着かせるべし。

【すれ立てるまでもない質問はここで 第6２刷】
http://pc5.2ch.net/test/read.cgi/tech/1100963189/

コーディング規約はこのへんがまとまってるんじゃないか？

http://www.objectclub.jp/community/codingstandard/

>>10
iine

http://www.hondarer-soft.com/cx/pukiwiki/pukiwiki.php?Link%2FProgram#content_1_17

ここもまとまってました。

この↓本では力不足ですか？

センス・オブ・プログラミング!―抽象的に考えること・データ構造を理解すること
http://www.amazon.co.jp/exec/obidos/ASIN/4774121738/qid=1102247391/sr=1-1/ref=sr_1_10_1/249-2545910-7109969

バグが無いのはもちろんのこと、
堅牢性、保守性、拡張性、可読性、etc.
を備えたものが良いコード。
見栄えは個人の好みもあるから、あまりうるさく言うな。

とりあえず>>1の「良いコード」の定義を教えてくれ

>>15
それを考えていきたい。

>>1
なんかたたき台にするサンプルコードあげろよ。
短いのでもいいからさ。
具体的なコードがあった方が話が早い。

実際には、悪いコードを書く奴を排除するノウハウの方が重要なのだが。

>>18
例えば13あたりがその対象じゃないか？
URLが
http://www.amazon.co.jp/exec/obidos/ASIN/4774121738/
までで十分だから。

18がうまいこと言った。

たたき台サンプルコード
1 a(1,1);
2 a (1,1);
3 a( 1,1 );
4 a ( 1,1 );
5 a(1,1) ;
6 a (1,1) ;
7 a( 1,1 ) ;
8 a ( 1,1 ) ;
9 a(1, 1);
a a (1, 1);
b a( 1, 1 );
c a ( 1, 1 );
d a(1, 1) ;
e a (1, 1) ;
f a( 1, 1 ) ;
g a ( 1, 1 ) ;

コード規約、どれが一番好まれるのか?
人によってさまざまだけど、
1はスペースは入れないってことで分かる。
それ以外のスペースを入れるときってのは、
いろいろ人によって違うので合わせようにも合わせずらい。
for文はこうだとか条件によってかわると、もう全部あわせるのは不可能

たたき台サンプルコード
1 a(1,1);
2 a (1,1);
3 a( 1,1 );
4 a ( 1,1 );
5 a(1,1) ;
6 a (1,1) ;
7 a( 1,1 ) ;
8 a ( 1,1 ) ;
9 a(1, 1);
a a (1, 1);
b a( 1, 1 );
c a ( 1, 1 );
d a(1, 1) ;
e a (1, 1) ;
f a( 1, 1 ) ;
g a ( 1, 1 ) ;

コード規約、どれが一番好まれるのか?
人によってさまざまだけど、
1はスペースは入れないってことで分かる。
それ以外のスペースを入れるときってのは、
いろいろ人によって違うので合わせようにも合わせずらい。
for文はこうだとか条件によってかわると、もう全部あわせるのは不可能

うわ、失敗

>>18
恐ろしいけど、2chだからそれを話し合うのは面白い
でもそんなノウハウ、排除される側はたまらん

>>15
◆良いコードの定義
あたえられた条件にあっているコード
◆条件
バグの有無、堅牢性、保守性、拡張性、可読性、高速性、開発の高速性、コメントの有無

といったところですか。全部を兼ねそろえるのは無理な場合もある。
サンプルコードにはバグがあってもいいし、高速に動かなくても良いから、可読性が重視される。
開発速度が優先された場合は、スペース入れないほうが速いけど、可読性は落ちる。
自分中心に考えれば、自分が好きで使っているコーディング規約に基づいて書かれていて自分が書くよりも優れたコード。
定義とか言われると難しいな

◆条件って書いたのは、条件を考えるにあたっての項目だな。

Wiki立てました。構造的に問題あるので構造自体も好きに変えてください。

http://f55.aaa.livedoor.jp/~goodcode/index.php

>>21
おれがスペースを入れるのは
1. カンマ','のあと
2. if while forのかっこの左右
3. 2項演算子の左右

>>25
がんばってますね。応援age

>>25
応援どうもです。
なんでもいいんでwikiに書き込んでください

おいしいラーメンの作り方を書いてもいいですか？

>>29
それは、、、
訂正
いい方向性に向かうように、好きに書き込んでください。

FrontPageの電車男云々ははっきり言ってない方がいい。
必要なのはWikiの管理人がそこに書かれたテキストに発生する著作権をどうするのかというポリシー。
ここら辺あさってどうしたいのかを明記しとけ。
http://www.google.co.jp/search?sourceid=navclient&hl=ja&ie=UTF-8&oe=UTF-8&q=Wiki+%E8%91%97%E4%BD%9C%E6%A8%A9

良いコードを書くためのノウハウその1。
括弧の位置とかインデントとかそんなレベルにこだわらないこと。

ほれ。
http://himatsubu.fc2web.com/22/fir/　かなりシュールな心理テストでｵﾓﾛｲ。

>>33
Q3　あげまんという言葉は、いやらしい事だと思っていた。
（実は今もそう思っていた）

YES

NO

※「あげまん」とは、男をあげる（出世させる）という意味です。
〔1990 年（平成 2）発表の映画「あげまん」（監督・脚本伊丹十三）によって流行した〕



あげまんってあげまんこの略だよな？ﾏｼﾞﾃﾞﾏｼﾞﾃﾞ

動くコードが書けない僕でも、良いコードは書けますか

頭悪いので、TexのWikiからのコピペを修正したものを張りました。
Wikiそのままのコピペで本をだすことはしないと約束します。

スペースかっこ、著作権、Wikiとか
話がどんどん本題からずれていくのがおもしろい。

インデントはタブがいいの？
それともスペース？

Wiki書き換えてくれた人がいた。
ありがとうございます。

>>37
まとめる手法としてWikiを使い不特定多数の人から書き込んで欲しいと考えてレスを立てた。
そのためには、著作権の問題も考えとかないといけないってことだと指摘されたので直したってところです。
俺はボトムアップな思考しかできないから、そうなってしまうのかもしれん。

>>38
俺も教えて欲しい。

インデントは入れるほうがよい。
インデントは同じソース内で統一されているほうがよい。
統一できない場合、コミニュティ、ライブラリ、ソース、関数、処理内で統一されるとよい。
規模が大きくなればなるほど、統一が難しくなるが、いったん統一されると、変更するのは難しい。
インデントは２文字４文字８文字がよく使われる。
タブ幅のデフォルトは８文字である。
タブ幅はアプリケーションによって設定できるものとできないものがある。
タブ幅の設定も２文字４文字８文字がよく使われる。
タブ文字は使わずにスペースのみにする方法もある。
HTMLで記述する場合はタブ幅を指定できない。８文字に固定される。
タブを使うメリット
-タブ１文字で複数文字のインデントをつけることができる。
-容量を食わなくてすむ。
-タブのみでインデントされたソースは、環境を返るだけでインデント幅を変えられる。
スペースを使うメリット
-アプリケーションに左右されずに、元のイメージを再現できる。

あとは、コーディング規約による。
前提とするコーディング規約によって、
開発環境や自動整形ツールの機能も変わってくるのが現状ではないだろうか。

VC++だったりEclipseだったりすると、タブ幅は４文字、インデント４文字がいいのだと思う。
JBuilder、GNU Emacsとかの場合、タブ幅は８文字、インデントは２文字がいいのだと思う。

>>22
どうでもいいけど、何で f の次が g になってるの？
10に訂正してくれ。

俺は、
for(i; i<10; i++)
{
printf("%d", i);
}
こんな感じかな。
printf()の前は、タブスペース空けてる。
ってか、VC++が勝手にやってくれるからだけどね。

うわっ。
半角スペース連続投稿で消された・・・・・
逝ってくる。

消されたわけではないが。

a(ONE, ONE);

>>1
哲学的になりますが、
そもそも「情報」って何だろう？
「情報技術」って何だろう？
といった問題を日頃から深く考えるのも大事だと思います。
より良いソースコードが書けることと、
情報という概念について自分なりの哲学を持っていることって
かなり密接な関係があると個人的に思っているので。
さすがに、言いすぎかもしれませんが。

ただ、少なくとも言えることは、
より良いコードを書くための断片的な知識をひたすら覚えていくだけでは、
絶対にプログラミングは上達しないと思いますよー。
数学の定理や公式や解法をいくら暗記したところで
数学が出来るようにはならないのと同じです。

ただ否定するだけだとさすがにアレなので、
コーディング技術を上達させるための有効な手段の一つを紹介します。
というのは、正しいHTMLを書く練習をすること。
自分で何かしらWebサイトを管理している人は、
Another HTML-lint(ttp://openlab.ring.gr.jp/k16/htmllint/htmllint.html)
ダサページ(ttp://web-channel.com/tips/webdesign/MIZ/031031.html)
などを参考にしながら、また時にはWeb制作板のW3C厨に叩かれながら
自分のサイトを改善していくことで、
自然と、情報を扱うセンスが磨かれることと思います。
もっとも、Webページを作る習慣のない人にとっては
どうでも良い話になってしまうかもしれませんが。

#余談ですが、Javadocが吐くHTMLが文法メチャクチャで汚かったのを見て
#幻滅したことがあります。
#優秀なSEであることと、優秀なHTMLが書けることはまた別ですねー

時間だよ。とにかく時間。
時間さえあれば並みのプログラマでもマシなものが書ける。
時間が無ければ凄腕プログラマでもHACKせざるを得ない。
余裕が無いが短すぎもしない期間で寄り道せずに最適解を導けるような知恵袋はあってもいいかもな。

スペースの位置とかインデントとか、どうでも良い問題にこだわる1は一番このスレにふさわしくないと思う。
そんなものは同じ関数内ですら統一されている必要なんか無い。
その程度で読みづらいと感じるようなやつはこの業界から早々に去れ。

>>46
そんなのW3C勧告読めばいいだけの話じゃん。
良いコードを書く能力というよりかCで未定義じゃないコードを書く能力に近いというか・・。
最低限レベル？

>>48
確かにW3Cの仕様を読めば、文法的に正しいHTMLを書けるようには
なれると思います。
ただし、重要なのは文法が正しいことではなく、
その表現が妥当かどうか(分かりやすいかどうか)、ということです。

例えば、Webページのタイトルにあたる記述は
「大きな文字を使ったパラグラフ」として表現するのではなく、
(例: <font size="+5">○○のほーむぺーじ</font>)
「見出し」として表現する、といったことです。
(例: <h1>○○のほーむぺーじ</h1>)

スレ違いなレスでごめんなさい

結局は文脈を読み取れる国語力が必要って事？

いまどきあんな時代遅れのHTMLを意味に合わせて使うなんてナンセンスだよ。
UAが正しく理解できればそれで十分。
俺は文章の論理構造はXMLで書いて、XSLTで変換してる。
変換した先がどうなってようが（それでも一応validだけど）知ったこっちゃ無い。

>>45
自分なりの哲学なんて邪魔なだけだ。
まずは自分を捨てるところから始めろ。

Eclipseのコードフォーマッタって便利なんだけど他人のソースでうっかりCtrl+Shift+FしちゃうとCVSが悲惨なことになるんだよなぁ。
コード横幅120文字に設定してるのが悪いのか・・・デフォルト80だしなぁ・・・。
自分を捨てることは必要かもしれん。
でも最近の高解像度ディスプレイで80文字は無いよなぁ・・・。

Pythonコーティングスタイルガイド

ttp://www-acc.kek.jp/WWW-ACC-exp/KEKB/Control/Activity/Python/doc-j/pep-0007-J.html
ttp://oldriver.org/python/pep-0008j.html

どうせ書くならwikiに書き込めよ。このチキン野郎

>>40
＞HTMLで記述する場合はタブ幅を指定できない。８文字に固定される。

<pre>では、タブは使わないのが推奨されてなかった?

興味アル方メールください

業務内容
サーバ・アプリケーションの設計・開発・運用・保守管理などの業務に取り組んでいただきます。
資　格
学歴不問25〜40歳位迄、下記項目中2項目以上の経験者が望ましい。


Java開発経験者(Tomcat等のJakarta Projectを利用した開発)
DB開発運用経験者(Oracle,PL/SQL,Pro*C,MySQL,PostgreSQLを利用した大規模DBの運用・開発経験者)
Linuxサーバの構築・運用経験者(bind,sendmail,qmail,ネットワーク一般、セキュリティ設定等)
システム開発プロジェクトマネージャー経験者


勤務地
東京都渋谷区

ここで募集しても糞しか集まらないよ

>>54
情報サンキューです。
Wikiに反映しときます。
>>55
Wiki重かったりするし書き方分からないのかもしれないし情報いただけるだけで助かります。
てか、55がWikiに書き込んで欲しかった。

>>40
そうですね。IEだと文字のサイズ変えても固定ですしね。

>>47
条件しだいで、良いコードの定義は変わると。
時間がない場合は、インデントにこだわらないほうが良いし、
保守する場合、diff取ることを考えると、インデントを変えるのはいけないことだろうし。
でも、テストケースが完璧にそろっているならば、インデント変えても大丈夫なはずですし。
でその条件を与える項目の一つとして、インデントやスペースがあると思うのですが。
書き方は基本的なことだし、初心者でも分かりやすいことだから先にまとめとこうと思ってるんです。

俺の批判よりコーディング規約以外の一番重要はものをどう考えているか教えてください。

インデントうんぬんで文句言う奴がいたら、自動整形機能使って渡せば議論しなくてすむし。

Javaアプレットで自前アルゴリズムで3D描画するプログラム
http://homepage1.nifty.com/open-prog/
http://homepage1.nifty.com/open-prog/java/index.html
ここのコードは綺麗でよいと思ったなぁ。

>>60
Python はインデント変えると動かなくなるんだよ

>>61
おれもプログラミングを始めたころに読んだけど、読みやすかった。

>>47さんに賛成です。

software designに連載されていた。
コードデザイン最前線(http://homepage2.nifty.com/yamazaki/)
を読んでみて下さい。

http://pc5.2ch.net/test/read.cgi/tech/1044457085/

>良いコードを書くためのノウハウ

　公開されているソースコードを読むとよいと、何度か聞いたことがあります。
どのソフトのソースを読むかについては、
・自分のパソコンで動かすことが出来て
・興味のある分野で
・定評のあるソフト
がよいかも。
言語好きなら、Rubyのとか。
ゲーム好きなら、DOOMのとか。

サンプルプログラムの類からは学べない、
プログラムを破綻無く書くためのノウハウがつまっていると感じました。
いくつか読んで、一般的に言えそうなのは、
（注：C言語の場合）
・関数は、思っていたよりも、短いものばかり
・マクロを巧みに用いて、抽象度を高めている（そのぶん、最初は挙動を追いにくい場合も）
ことなど。なんか、ソフトの動作の複雑さに比して、ソースはあっけない
くらい、あっさりとしていることが多いです。

コーディング規約のようなものは、読むソフトごとに様々で、
統一さえされていればよいのではと思いました。

　達人のソースコード読んだあと、ふと、自分の書いた
コードに目をやると、なんでこんなにごちゃごちゃしてるんやろ、と思う。

たぶん、良いコードを書く「ノウハウ」のようなお手軽な
ものはなくて（良い小説を書くノウハウがないのと同じように）、
ひたすら書き続けるなかで、１０年ぐらいかけて、身に付ける
もんじゃなかろうか。

デザインパターンにしても、例外処理にしても、いざ書こうとすると、
なかなかうまく書けなかったりするし。

がんばろ。

　とはいっても、良いとはいかずとも、バグを見つけ出し
やすいコードを書くノウハウはあると思います。

C言語の場合、使わない人もいますが、assert()が重宝します。
いろいろな場所で、暗黙の仮定をassertしておくと、
一部の関数の仕様変更などで、誤って生じた境界条件での
ロジックの乱れを、掬い出してくれます。
コードが自らバグを表出してくれる感じがよいです。

C言語が使えるところなら、どこでも使えるというのもよいです。

Effective C++ とか読むといいとおもう
今更だけどEffectiv C も書いてほしいなあ…

Effective〜っていうプログラミング指南書は全然役に立たない俗本。

>>70
Effectiveってつく本を何冊読んだのか知りたい。

>>70
少なくともEffective C++は読んだんだろうな？

「関数内関数」使っちゃったｗ
int func () {
　struct local {
　　static int func() { return 0; }
　};
　return local::func();
}

コードレビューの時にどんなツッコミが来るか、ドキドキだｗｗうはｗｗおｋｗｗｗ

>>72
当然でしょ。
Effectiveのつく代表的な著作じゃない。

>>74
それを「全然役に立たない」と断じる根拠を知りたい。

>>75
全然役に立たないというのは言いすぎだったかもしれないけれど、プログラミング
してきて、ある程度の経験値を持っている人なら、書いてある内容に同感する部分
もあるだろうけれど、読んでいて、「やっぱり、そうだよねー」っていう感じで
世間話をしている感覚。
当然、(Mayersに対して)「う〜ん、そこまでしなくても…」と思うこともあれば、「あ、それはいいね」と思うこともある。
でも、まぁ、大体は、自分のスタイルに従うからあくまで世間話だね。

>>76
まぁ、エキスパートの人にはそうかもしれないが、CからC++に
移行してきて文法に振り回されてる人には、お勧めできるガイド
ラインだと思うんだけどなぁ。要は対象読者による、でしょ。

対象読者が誰であれ、お勧めできない本は他にいっぱいある気がする…。
ちょっと話ずれてｽﾏｿ

>>76
対称読者を間違えてる。
本来経験から得る知識を金払うだけで得れるんだからすばらしいじゃないか

>>77
そのあたりのことは全部見越して、>>70の発言なんじゃないか。
ようは、なんの脈絡もなく、「おれはすごい」って自慢できるきっかけを見付けたから
それに食いついただけでしょ。

できるだけコード量が少なくなるようにして、
メソッドの数をできるだけ少なくして
クラスはできるだけ作らないようにして
シンプル命でリファクタリングしつづけるだけ。

とにかく素早く頭働かすことだな。
時間かかるように見えて、リファクタリングすることが結局、一番早い。
そのうえで、これ以上早くするとなると、素頭の、完成形までのイメージをスムースに描ける
ストーリ構築力というか、国語力みたいなものが問われるな。これは才能の部分が大きいかもしれん。
もちろん、鍛えることは可能だと思うけども。

結局、メンタルの健康が一番大切なのかもしれん
己を知る
体を動かす
寝る
いいもの喰う

それでいいじゃん

まあ2chに入り浸るようなのじゃいくらノウハウを蓄積したところで
変わりはしないんだがな。

>>66
思っていたよりもってゆーか、関数は長くても一画面に収まる程度が望ましいんだけどね。
大半は数行から十数行程度で。
短い関数＝良いコードといっても過言ではないくらい重要だね。
現実的には手を抜いてしまいがちだけど。
C++だとprivateな関数増やすだけでヘッダの書き換えが必要になるから、なかなか厳しい。

自分で作ったメソッド名を他人に変更してもらうと分かりやすいコードが出来上がる。
独りよがりになりがちだからね。

Javaだけど俺がメンテしててこりゃ駄目だと思ったコードは
・メソッドが長い、数百行ある。
・メソッド名が正しくない、やってることと名前が全然違う。
・入力専用のはずのパラメータを平気で書き換えている。（結果自爆したり呼び出し元で惨劇）
・クラスは継承しない。
・メソッド、フィールドは全てstatic。
・ローカル変数は全部関数冒頭で宣言する。
・変数はいろいろな意味に使いまわす。
・抽象化がされておらず、似たような処理がいろいろな位置に散在して、異なる方法で実装されている。
・意味の無いコメントが目立つ。(例: boolean succeeded = false; // 成功したか)

これを反面教師にして、逆のコードを書けばちっとはマシになるだろ。

関数とメソッドってどう違うの
クラスのメンバ関数=メソッドでOK?

>>79
ひねくれているなぁ。

>>83
> 思っていたよりもってゆーか、関数は長くても一画面に収まる程度が望ましいんだけどね。
ここで言う一画面とはどの程度を指すんですか？
Unixターミナルのように80x24=1画面を基準とする？それともSXGAでEclipse標準フォントを使った
場合の約120x50を基準とする？

別に、メソッドは短くする意味がなければ長いままのほうがいいよ。
なんでもかんでも短ければいいっていうもんじゃない。メソッド増えるのキモいし。
長いメソッドのときは、まとまった処理ごとに適切なコメント入れればいいと思うね。
メソッドを定義したのと同じ表現力が得られる。

>>87
そのコメントをメソッド名にして切り出すべきだと思うんだけどね

>まとまった処理ごとに適切なコメント入れればいいと思う

もはや説明が必要な時点でNGだろw

一つのメソッドは30秒以内に理解できるものでないといけない

>>90
読む奴が無能ではどうしようも無い

>>88

他で使いまわしたくなったりオーバライドが要るときになったらそうする
（シンプルにしてれば簡単なはずだ）

一つのメソッドからしか呼ばれないメソッドってアフォでしょ。定義する価値なし。

>一つのメソッドからしか呼ばれないメソッド

長いメソッドをそんな風にしか分割できない時点でNGだろw

>>92
構造化プログラミングを勉強しなおせ。もしくはCOBOLでも使ってろ。

メソッドを無理やり短くするほうがいかんと思うけどね
短くなって複雑になるくらいなら長いままにしておいたほうがマシ
いい方法が見つかった時に短くする。

複数の条件判定の上で処理する場合、出来るだけネストを深くしないように
ループの場合はcontinue、ifやswitchの場合はその部分を関数に切り出して
returnさせるようにしてるんですが、こういうのってどうなんでしょ？自分では
読みやすい(コメントも付けてるし)良いコードだと思ってるんですが、読みにくかったり
するんでしょうか？

for (SmplCls hoge in arg) {
    /* expr1がfalseの場合をふるい落とす */
    if (!hoge.expr1)
        continue;

    /* expr2の文字列をチェック */
    if (!(hoge.expr2 == "hogestr")
        continue;

    /* expr3が限界値を超えていればふるい落とす */
    if (limit < hoge.expr3)
        continue;

    /* 実処理 */
    /* ... */
}

どうせならループの場合も関数に切り出したほうがいいかとも思うんですが、結局
エラー・例外処理が絡んできて値を返し、呼び出し元で分岐させなければならなく
なるのでそこまではやってません。

短くして複雑になるのは短くするやつが低脳なだけだろ

条件を適当に付け加えたので括弧を入れ忘れました
-    if (!(hoge.expr2 == "hogestr")
+    if (!(hoge.expr2 == "hogestr"))

>>96
脊髄反射でレス
コメントが必要だと思ったらその時点で駄目なコードだと思え。

>>99
そりゃ言いすぎだ。趣味でやってるなら許すが。

>>99
そういう通念をヘタに浸透させると、ダメなコードでもコメント入れない奴が
量産されるから、公の場では言わないように。

>>99
いやー、実際のところコメントなんて無くても読めると思うんですよ。
しかし読む側にすると自然言語によるコメントが付いているとありがたい。
英語の読み書きは出来るけれど、やはり日本語ドキュメントを読むほうが
楽だというのと同じことじゃありませんか？結局は読む側の時間節約の
ためにコメントを付けるものでは？自然言語で解説を添えておくことは
後々自分の保守作業の助けにもなると思いますが。

-for (SmplCls hoge in arg) {
+foreach (SmplCls hoge in arg) {

書いてる時から何かおかしいと思ってたんだorz

時間がたつにつれてコメントと実コードの間にずれが生じてくる。
コメントは間違っててもテストに引っかからないしエラーにもならないからね。

それとは別に、もし96のようなコメントを本当に入れてるなら、やめた方がいいよ。
コメントと、その下の行で全く同じことを別の言語で書いてるだけだし、日本語読むより下のコード読んだほうが早いし正確。

もし入れるならなら

/* expr1がfalseの場合、XXXなのでふるい落とす */
if (!hoge.expr1)
continue;
くらいしてくれ。
プログラミング言語はWHATは記述できるけどWHYは記述できない、WHYの部分をコメントにすべき。

ネスト回避にcontinueやreturnでふるい落とすのは良いスタイルなのかというのを
聞きたかったんですが・・・。

ともかく、>>104アドバイスありがとうございます。CVSのコミットログにはwhat i didではなく
why i did itを書け、というのと同じですね。

>>105
頭の方で条件に合致しない場合はreturnで落とすスタイルは広く使用されてる。
名前も付いてるけど忘れた。

いつもコメントの書き方にこまるです。
自分、強迫神経症的な部分があるから、
とことん書かないと気がすまない。

コメント書く際の標準とかってある？

>>107
標準はないけれど、JavaDoc風に書くとわりと幸せになれるかも。
例えば、DoxygenだとJavaDoc風の書き方に対応しているからソースのコメントを元に
ドキュメントが生成できたりします。

あーなるほど、そういえばPerlにはPodだっけ？なんて書き方がありますな。
（ソースのコメントを元にドキュメント生成できる）

ところで、PHPにはそういうのはないんでしょか？

Doxygen

RD

>>109
PEAR は PHPDoc を使うことが義務付けられている。
Doxygen も PHP に対応しているし。

>>96
そういうやり方を嫌う人は多いな。
聞いてみると、仕様をそのままコードに落とした方が分かりやすい
ということらしい。
ネストが深くなるのを嫌って関数の頭でふるいにかける形でコード書いたら
SEから「俺が書いた仕様と違う」と拒否されたこともある。

>SEから「俺が書いた仕様と違う」

ｱﾌｫです
直訳と意訳は違うんでつ

アホだな

正しく動くコード
正しいコード
良いコード
これらは全て違う

良いコードを書くためには少しの酒と旨いつまみが必要だ

>>113
コードレベルのフローチャートみたいなのが、仕様書に含まれてるところなのだろうか。

良いコード…、俺がコーディングしなきゃOK。

コメントって>>96みたいな「何をしているのか」を書くものなのかな？
私は「何をしたいのか」をコメントとして書いてるけど・・・。
他の方々はどーしてます？

>>120
「何をしたいのか」を書く方がいい。

なぜこの方法を採用したのか、他の方法ではどうダメなのかをコメントで切々と説く。

したいこととその方法を書く。

phpのソース上キレイにかくか、
outputのhtmlをキレイにかくか、
で迷う

>124
phpをきれいに書いたほうが後々自分が楽。

>>125

まぁ、そうなんだよね。
ただ、PHP使えない人がなんかしら作業することを考えるとき、
（デザイン変更とか）
htmlをキレイにかいたほうがいいんだよね・・・

できれば両方キレイにしたほうがいいんだろうが・・・そんなヒマはない

普通デザイン部分のhtmlは別ファイルにするだろ？

php使うならxmlつかったほうがいい

良いコードを書くのにノウハウなんていらね。
たった一つの事を守れば良い。

そのたった一つの事とは、、、。

========================
ここで一旦コマーシャル。
========================

>>129-130
Cを高級アセンブラだと思わないこと。
特にアセンブラから入った人間。

どう違う？浮動小数点演算をターゲットに応じて展開(レジスタ割付とか)してくれるぐらいしか思い浮かばんが

あ、レジスタ割付は本質から外れるな。浮動小数点演算をどのように扱うか、という
面倒を見てくれることか

たった一つの冴えたやり方

意味を明確にしたコーディングをする、ということが大事だと思います。

例えば "2004-12-20 00:30" という形式の文字列
(データベースの時間データによくある書式)を引数にとり、
"2004/12/20 00:30" という文字列に変換する関数を作るとします。

この関数を実現する方法として、以下の2つを挙げます。
「引数の文字列に含まれる"-"を、すべて"/"に変換し、変換後の文字列を返す」
「引数の文字列のうち、
1〜4文字目を『年』、
6〜7文字目を『月』、
9〜10文字目を『日』、
12〜16文字目を『時刻』とする。
"『年』/『月』/『日』 『時刻』"という文字列を返す」

ソースコードの長さは、前者のほうが短くなるでしょうが、
ソースコードの分かりやすさは後者のほうが上なはずです。
もしも、シビアなパフォーマンスを要求される場合には
前者を使う場合も有り得ますが、
基本的には後者のほうが保守性が高いと思います。

すごく極端な例になってしまいましたが。

>>130
馬鹿はコードを書かない。

>>136
コメント一行書けばしまいじゃん。

>>136
日付時刻クラスでも作ったほうがいい。

>>139
日付・時刻クラスをつくるってことは
後者にあたるんじゃないかい？

日付時刻クラスの中では年、月、日、時刻はメンバとして持ってるだろうし。

>>139
俺ならこうしちゃうけどね。

sscanf(
　"2004-12-20 00:30",
　"%d-%d-%d %d:%d",
　&year, &month, &day, &hour, &minutes
);
printf("%d/%d/%d %d:%d",
　year, month, day, hour, minutes
);

へ〜、sscanfってそういう使い方できるんだ。メモメモ。

俺は前者だな。
前者の方が短くて速くて分かりやすい。
後者は冗長でかえって何がしたいのかわからなくなる危険がある。

>>136
使う側からすれば、どうでもいい話。

>>136
2005-1-1 00:00
になったらバグが出ないか？

あと、フォーマット固定な後者の方が
パフォーマンス的にも有利だと思うんだけど。

前者はデータの性質を利用した（あるいは依存した）トリッキーな実装って
意味のただの例だろ。細部に突っ込んでも意味ないだろ。

後者もデータ形式に依存しまくりだろ

個人的には後者のほうが嬉しい
時刻とか誰もが共通の知識を持ってるものは別に良いけど、
専門的な分野の話になるとトリッキーなことされると理解に困る
コメントついてるものもあるけど、
変更とか拡張とか入るとコメントはうさんくさくなっちゃうし…
いっそコメントいらんから分かりやすいコード書いてくれって思う

後者って、Cで書いちゃうと
date[4] = date[7] = '/';
なんだよな。

>1〜4文字目を『年』、
>6〜7文字目を『月』、
>9〜10文字目を『日』、
>12〜16文字目を『時刻』とする。

これがダメ
未来永劫フォーマット固定なのか？

>145も書いているが
2004-1-2 23:45
とかにならないのか？

>>147
文字列の後半に'-'が含まれないって非本質的な性質を利用したって意味だよ。

>>150
例題なんだから、その辺の仕様の善し悪しは置いといていいんじゃない？
要は分かりやすいコードと短いコードではどっちがいいか？
という話だと思うんだけど…

だいたい、長いコードは分かり難い。

例が悪すぎというのに尽きる。関数だというんだから>>136の前者でいい。そもそも
文字列操作を日付形式変換という意味のある操作に転換するために関数に抽出するんだし。

もっと別の例をきぼんぬ。

>>151
どこにどの区切り文字が入っているかは書式化された日付においてはきわめて本質的な性質だけど？

アホばっか

たかが文字列の変換によくもまあこんなに沢山レスがつくもんだｗ
いままで同様な処理を書いたかなんぞ憶えていないが、全部、前者だ。
前者が気に入らないのなら、関数ごと差しかえれば良いだけの話だろ。
なんでこんなつまらんことで話が盛り上がるかが理解し難い

そのための2chです。

現実じゃなくて理想の話だからな
現実的な解決方法は求めてないだろう

>例えば "2004-12-20 00:30" という形式の文字列
>(データベースの時間データによくある書式)を引数にとり、
>"2004/12/20 00:30" という文字列に変換する関数を作るとします。

そんな ad hoc な関数は作らないように設計する、
というのが正解だと思う。

なぜDBの時間データを文字列形式で取ってくるのかという問題

>>136なのですけど。。。
反応多くてびっくりです。

とりあえずちょっとずつレスしていきますね。
良いコードかどうかって、いろんな考え方があるのですが
一つの尺度に、「リファクタリングに耐えうるかどうか」
というのがあると思います。

>>136で挙げた例で、例えばクライアントからこういう要求があったとします。
「"2004/12/22 04:00" という形式ではなく、
"2004年12月22日 04:00" という形式にしてくれ」
あるいは、
「年の情報はいらない。"12/22 04:00" という形式だけにして欲しい」
などなど。

こういった変更が、どれだけ容易に、確実に出来るかどうか。
前者は、関数をまるまる作り直さなきゃいけないのでコストがかかるけど
後者の関数は、情報の「意味」に着目しているから、
変更しやすいし、ミスも起きにくい。
というわけで、「意味を明確にしたコーディングが大事だ」と
考えている次第です。

それだったら
「"04/12/22 04:00" という形式ではなく、
"2004年12月22日 04:00" という形式にしてくれ」
とかもありえる

この場合前者なら修正不要ですが

＞一つの尺度に、「リファクタリングに耐えうるかどうか」
＞というのがあると思います

から

＞というわけで、「意味を明確にしたコーディングが大事だ」と
＞考えている次第です。

という流れがどうもふにおちん。

>>162
つか、まるまる作り直しでいいじゃん。
下手に既存のものに付け足してしのごうとすると汚くなりがちだし、
バグの温床にもなる。

仕様が変わっちゃうと、それはもうリファクタリングじゃない。。

>>162
>前者は、関数をまるまる作り直さなきゃいけないのでコストがかかるけど
>後者の関数は、情報の「意味」に着目しているから、
>変更しやすいし、ミスも起きにくい。
全然そのようには思わんが。
後者は「仕様に実装が密着しすぎ」だ

例が極端すぎたね。

>>167
>>113 世の中にはこういう人も居る

作ってる本人はわかりやすくても
他の人には迷惑なだけかもね

>>167
前者の方が仕様に密着してると思うが。

> 例えば "2004-12-20 00:30" という形式の文字列
> (データベースの時間データによくある書式)を引数にとり、
> "2004/12/20 00:30" という文字列に変換する関数を作るとします。

→-を/に置き換えれば良い。

2004 が年で、12が月で、20が日で・・以下略
ってのは、後者のコードを書いたやつが仕様を勝手にそう解釈してるに過ぎない。

マクロならば
#define GSUB( str, s, d ) { int i; for( i = 0; i<=strlen( str ); i++) if( str[i] ==s ) str[i]=d; }
かな。・・・もう止めない？。この程度の処理に・・・。
俺は136のレベルが低すぎるだけだと思うのだけど

>>172
おいおい、毎回strlen()するなよ。

レベルが低いのは172ということで決着しました

>>173
ぉぉ。確かに。でもこの程度の事はｷﾆｼﾅｲｗ
別変数を用意しなきゃならないし、ここがボトルネックになるはずはないからな。
・・・まあこういうところまで気にしなければならない開発が存在することを否定するわけではないけど。

>>174 ｻﾝｸｽ

>>171
確かに、おっしゃるとおりで。
"yyyy/mm/dd hh:dd" という書式に特別な意味がある場合だったら、
(仕様でそれが厳密に決まっているとか)
前者のコーディングでも十分ですね。

他の方がおっしゃるとおり、例の出し方が悪かったです。
"yyyy-mm-dd hh:dd"という書式にするのが最終目標なのではなく、
「時刻をユーザーに分かりやすい書式に変換するして画面に出力する」という大きな目的があって、
その目的の一部として、この関数を作る必要性があった
などのシナリオを明示するべきでしたね。

この例自体、「情報の意味を明確にしたコーディング」というのを説明するために
出しただけなので、別の説明のしかたもあったかもしれません。

>>176
誤: "yyyy-mm-dd hh:dd"という書式にするのが最終目標なのではなく、
正: "yyyy/mm/dd hh:dd"という書式にするのが最終目標なのではなく、

すみません(_ _)

C++だとlambdaを使うか、lambdaを使わないかってこった。
lambdaはごくごく単純な式なら役に立つことも全く無いとは言えないが、
どうせじきに式が複雑になってインラインじゃとても読めた代物じゃなくなるんだから
はじめからファンクタか関数にしとけってこと。

>>178
C++にlambda式はありません。

エラー処理を始めとする例外処理は、最初からまじめに書いとけ。
あとになって「こんなエラーがあるんだけど」と言われても、対処できん。

>>179
boost::lambda、あるいはそれっぽい実装のこと指してんだろ

ttp://www3.symbian.com/faq.nsf/0/FF12966FF9AD528C80256C3A00428CE4?OpenDocument
SymbianOSの開発環境では，こんな事になっていて

　typedef int TBool; // SymbianOSではboolのかわりにTBoolを使う
　enum TFalse { EFalse = 0 };
　enum TTrue { ETrue = 1 };
　// 以下の比較演算子は，宣言してるだけ。実装は存在しない。
　TBool operator==(TTrue, volatile const TBool);
　TBool operator==(volatile const TBool, TTrue);
　TBool operator!=(TTrue, volatile const TBool)
　TBool operator!=(volatile const TBool, TTrue);;

もし
　if ( someBoolValue == ETrue )
のように ETrue と比較するようなコードを書いた時に
ビルドエラーが出るようになっています。
よく考えられていますね。

っていうか，そんな意地になってまで独自の型を使わずに
素直に bool 使えばいいのに(；´Д`)

>>182
俺だったらそれ以前にtypedef enum {EFalse, ETrue} TBool;とするだろうな。

Eって、もしかしてEnumのE？
アホ？

intとの暗黙の変換を嫌ったんじゃないの。
超厳格なプログラムを書くならありはありなんじゃないの。

日付についてはデータフロー中では日付型のまま扱い、プレゼンテーション層
に入ってから文字列変換するのが普通だろうな。
ビジネスロジック中でわざわざ文字列化する意義が在るとは思えんし。

>>186
新しいプログラムのために、既存のシステムのコードを変えるのもなぁ。

>>187
日付を文字列で引き回すような糞コードなら捨ててしまえ。

>>188
内部でどう処理してるかは知らんけど、外部に日付型なデータを提供してない場合は多いし。

日本が戦争に勝って
西暦が使われなかったら
やっぱり平成を単位にしてるんだろうか

>>189
あほか。
I/Fが文字列型だとしてもこちら側で日付型に再変換してやれば済むだろ。
糞システムに合わせて糞システム作る気か？

>>190
皇紀。

>>191
文字列でやり取りしなければいいじゃんて言われても、
状況によってはそうもいかないこともあるって言ってるだけなんだけど。

＞ I/Fが文字列型だとしてもこちら側で日付型に再変換してやれば済むだろ。
それはまた別の話。

>>190
日本に西暦が導入されたのは戦前だべ

神武天皇がお生まれになった年を0年に設定すれば良いのだ。
西暦など糞。

どこかの生保が皇紀を使ってると聞いたけどどこだっけ?
2000年問題関連でその話が出たときにサヨの痛い人が観察されたんだよな。

>>99 同意
>>100
とても長い間、仕事でそうしているが。何か？

ランバダ

>>197
引き継いだ人が苦労しているだけですが、何か？

format("yy/mm/dd hh:mm:ss", "04/12/05 14:50:20") → 1102225820
1102225820 → format("YYYY/mm/dd hh:mm:ss", "2004/12/05 14:50:20")
1102225820 → format("dd-mm-yy hh:mm:ss", "05-12-04 14:50:20")
1102225820 → format("wwww年mm月dd日 hh:mm:ss", "平成16年12月05日 14:50:20")
1102225820 → format("kkkk年mm月dd日 hh:mm:ss", "皇紀2664年12月05日 14:50:20")

↑こいつアフォ
datetimevalue("yy/mm/dd hh:mm:ss", "04/12/05 14:50:20") → 1102225820
format("yy/mm/dd hh:mm:ss", 1102225820) → "04/12/05 14:50:20"
format("YYYY/mm/dd hh:mm:ss", 1102225820) → "2004/12/05 14:50:20"
format("dd-mm-yy hh:mm:ss", 1102225820) → "05-12-04 14:50:20"
format("wwww年mm月dd日 hh:mm:ss", 1102225820) → "平成16年12月05日 14:50:20"
format("kkkk年mm月dd日 hh:mm:ss", 1102225820) → "皇紀2664年12月05日 14:50:20"

>>197
今すぐ仕事辞めろ。

なんで？

>>197
一目でばっちり分かっちゃうコードならいいが。
そういう仕事はしてないんだろ？（褒めてる）
その素晴らしいコードを残されたものは多分そのコードが作られたときより
短時間で理解して、書き換えなきゃならないこともあるんだよ･･･

>>197
「あのプログラム、君しか分かる人いないから全部任せるよ」
って言われて喜んでないか？

>>204
コメントを信じる根拠は何処にも存在しない。
従ってメンテナンス時にもコメントは信用しない。
貴方はコード内のコメントが常に正しいと思っているのか？
#メンテナンス時にわざわざコメントを削除するぞｗ
だからこそコメントを書かないのだ。

>>205
「気合入れて読まなければ分からない」とか
「気合入れて読めば分かる」とは言われるが。

あのさあ。「コメント無しでも理解できるコードを記述する努力」はしないの？
その種の努力を放棄したのなら、「コメント書かないという人間を叩く」
という行動も理解出来ないことはないけど

コメントに日時入れないのは最悪

何を意図して書かれたかもわからないようなコードを信じる根拠も無いわけだが。

つか、「コメントを書く」＝「コメントがないと読めないコードを書く」と勝手に決められてもな。
あんたがコメント書かなかったせいで気合を入れる分だけの余計なコストがかかってるんだよ。

いらんよそんなもん。cvs annotateを見る方が確実。

そんなもん=日時ね。

コメントが間違っててそれに振り回されてる人が多い。ソース読みさえすれば分かるのに。
それで読んでも意図が分からんソースなら捨てて作り直せば良いだけなのにね。

>それで読んでも意図が分からんソースなら捨てて作り直せば良いだけなのにね。
といっている奴のコードにまともに読めるコードがあったためしがないのが現実。

コード追って分かるのは「どう動作するか」だけ。
その動作が正しいかどうかは分からない。

コメント見てもわからないぞそんなこと

>>214
どういう動作を期待しているかが分かるようなコメントを書かないからだ。

コメントはコードが正しく動いていれば激しく有用なんだが、
コードが正しくないととたんに害悪になる。
人間プログラミング言語を読むときは一意一句逃さないように慎重に読むが、
コメントがついているとその先入観に惑わされて、コードをまじめに追わなくなる。
特にコードがシンプルなところほど見逃しやすくなる。

if ( a<upper_bound ) break;

というコードならすぐに間違いを見つけられるが。

// 上限を超えたら終了
if( a<upper_bound ) break;

は見逃しやすい。

問題はソースを読む必要があるのはたいてい正しく動いてないときなんだ。

コメントが無けりゃ間違いかもわからんじゃないか

なら、こういうのはどうか

// 上限を超えたら終了
if( a>lower_bound ) break;

コメントが無けりゃ間違いかもわからんじゃないか

>>206
> 貴方はコード内のコメントが常に正しいと思っているのか？
> #メンテナンス時にわざわざコメントを削除するぞｗ
> だからこそコメントを書かないのだ。

オマエ最悪だよ。
自分のコスト下げるために周りにコスト押しつけて平然としてるなんて。

>>216
そういう単純な間違いを含んだソースを読むという状況がよく分からないです。
そんなの書いた本人がデバッグしてないだけじゃないの？

>>216
> // 上限を超えたら終了
> if( a<upper_bound ) break;

その例もおかしい。
コメントというのはプログラムコードの日本語訳じゃない。
上限の数値に配列のサイズ程度の意味しかないならそのコメントは不要。
プログラムコードが仕様とどうリンクするのかを中心に記述し、注意を要する複雑な
例外判定などポイントを絞って詳細に記述すべきだ。
誰が書いてもそのようになるコードにわざわざコメントを付けるのは無意味。

>>216
コード書いた本人にとっては、
aやupper_boundが何を表しているかも分かってるし、前後にどういう処理が行われているかも分かってるし、
どういう条件の時にどう動かなければいけないかってのも分かっているかもしれないが

コード読むほうにとっては、
aやupper_boundが何を表しているかも分からないし、前後にどういう処理が行われているかも分からないし、
どういう条件の時にどう動かなければいけないかってのも分からないんだよ。

「そんなものはすべてコードで表してる」と主張するかもしれないが、読むほうは
コードが表していると思われる内容が正しいか間違っているかも含めて解析しないといけないんだ。
特に、正しく動いていない時には。

コメントには
「何をしているか」ではなく (それはコードを読めば分かるから)
「なぜそうしているか」を書くのがよい。

>>224
そのコードがjmpの嵐だったりするわけだ。
フローチャート程度のコメントは欲しいぞ。

私も>216や>218のようなコメントを見つけたら削除するね。
なので>224には同意。
だがそういうコメントを適切に書けない香具師に限って意図不明のコードを書くんだ。

>>208
滅茶苦茶だな。コードを信用しないでコメントを信用するのか？
>「コメントを書く」＝「コメントがないと読めないコードを書く」と勝手に決められてもな。
そんな事は言っていない。「コメントは読まない」とか「コメントを書くのはどうぞ自由に。だが俺は書かない」
と言っているだけだが。

>>211
同意

>>213
正しい。だからコンパイル単位とか動作単位の仕様記述がなければメンテナンスは不可能なのだ。
その種のメンテを押しつけられているなら、気の毒だなぁ

>>220
ああなるほど。俺が叩かれる理由はそれかｗ
「コメントを書けばメンテナンス時の工数が常に下がる」と思っているわけか

>>227
え？コメントを消して回ってるのに？

>>227
もしかしてfunction単位とかファイル単位のサマリも書かないのか？

コメント書かない主義の奴が作って、別の奴がメンテナンスすると最初のコードの意図は
完全に無視されることが多いんだよな。で、行き当たりばったりの「動けばいいや」パッチ
が当てられることになる(/* 多分、ここでエラーを返さないといけない */ みたいなコメント付で)。

だから、
何をしているといった類のコメントはいらない

何のための、とか行う目的のコメントを残せ

>最初のコードの意図

当初の目的でさえ間違ってたなら、別に最初のコードの意図は無視しても無問題だが？

コメント書かない香具師が改造やると最悪だよな。
既に動いてる他のコードの意図無視して適当にパッチ当てやがる。

>>232
最初のコードで意図してたことは(多分)正しかっんだけど、実装でミスを犯すことはあるよね。
そのほかにも環境変わったら動かなくなっちゃったとか。
で、その不具合を修正するためにコード見ても、元のコードの意図がよくわかんないんで
無理矢理修正しがちって話。

もっとも、俺はミスなんかしないぜっていう奴には関係ない話だけどね。

>>234
ミスをしない奴ばっかりなら、そもそもソフトウェア工学自体が必要なくなってきそうだけどな。

最初に作る時にはコメントは不要
後でバグ取りで直す時になぜバグったのか、
どう処置したのかをコメントに書いておく

224 ：デフォルトの名無しさん ：04/12/26 11:25:38
コメントには
「何をしているか」ではなく (それはコードを読めば分かるから)
「なぜそうしているか」を書くのがよい。

231 ：デフォルトの名無しさん ：04/12/26 14:13:33
だから、
何をしているといった類のコメントはいらない

何のための、とか行う目的のコメントを残せ


．．．たったこれだけの話なんだけどなぁ

>>197
疑問・・・君はアセンブリで書くときもコメント書かないのかい？
もし、他人が書いたコメントなしのアセンブリリストを保守できるなら神だな

なんか馬鹿が多いようだが、
正直メソッド内にコメント書いちゃだめだろ？
書かなきゃ解らない時点でそのメソッドは機能がでかすぎるんだよ。
もちろんメソッドの直前に機能説明は書くべきだが。

ビットシフト使いまくりっていいコード？

>>239
書いてあっても良い、書いていない奴のコードが汚いのが問題。
コメントを打つとコードを綺麗に書く技術が身についてくる、
そのうちにコメントが無くなって来るのだ。
コメントを書かない奴はコメントを書かないようにする技術が大抵無い。

>>240
使うべくして使ってんならどんなにあってもいいコード

>>241
>コメントを打つとコードを綺麗に書く技術が身についてくる、
嘘だ。逆説を書いてみようか。
コメントを打つとコードが汚いことを隠せたような気になって、綺麗に書く様には決してならない。
#わずか四行で矛盾したことを言えるのはすごい才能だね

逆説？

>>243
クソこぎちゃないソースにコメントがない最悪のソースコードなら良く見た事がある。
その反対は滅多にないな、まったくないとは言わない程度に。
特にコメントが無いのが正しいとかいっている奴のソースコードにまともなものがあった為しは皆無、
まずコメント回避の前にリファクタリングを勉強しろと小一時間の奴ばかり。

コメントの無いコードはコメントを極めた奴だけが可能にできる物だ。
理由は簡単で、コメントの持つ機能が各種名前に移っただけだからね、
基本的にコメントに書くべき適切な内容が考えられない奴は、
メソッド名・変数名に移しても事態は変わらないのだ。
意味が変わっているのに、変数名がそのままだったりとか、
機能分割したが機能が変わっているのにprivateメソッドの名前がそのままだったりとか
特に忙しくなったときは顕著だ、ここはキッチリ名前をかかなければ妥協できないという場所とどうでも良い場所の区別がつかないのだ。
手際よくコメントを書く技術が無い、が、手際よくリファクタリングする能力がない
に代わっただけで中身がダメならダメなものはダメなのだよ。

マ板のヨタ話みたいなレスしかないな

>>239
その強迫観念にとらわれて馬鹿みたいに小さなメソッドを乱造したのはオマエか！

>馬鹿みたいに小さなメソッドを乱造
これも典型だね、
必要な機能は近くにあったほうが良いというのは基本中の基本、
分けるときにはトレードオフを判断する必要があるが、
コメント皆無を妄信しているととんでもないクソコードを作り出す。

>>245
×コメントの無いコードはコメントを極めた奴だけが可能にできる物だ。
○コメントの無いコードはプログラミングをある程度以上、習熟した奴が可能にできる物だ。

つーか、１メソッドって一つの機能しか持たせなくね？
んで、処理実行！みたいなメソッドで他のメソッドを呼び出しコントロールする。
みんな違うのか？
１メソッドにあほみたいに機能を詰め込んでる？？

まあ、>>245の適切な名前をつけろは同意。
それがコメント極めることと同じとは考えたこと無かったけどな。

皆が"一つの機能"という感覚を共有できたら戦争など起きないだろうな

>>251
たしかに曖昧だが、
コメントをばりばり書かないと理解できないメソッドは、
１つの機能じゃないと思う。

なんか「機能」という言葉の定義が違うような・・・
どんな大きな機能だとてそれは一つの機能。
分割する事によってコードイメージが想像できる程度のサイズになるのが
設計だと思っているのだけれど。

例えば、パスワードの照合後、指定された年月時点での月次の貸借対照表を引っ張ってきて、
エクセルへ書き出す、というアプリケーションを作るとする。非常に大まかに書くと、
Foo()
{
　CollateUser();
　GetBalanceSheet(year, month);
　WriteBalanceSheetToExcelFile(fileName);
}

みたいに書くのか、上記３つのメソッドの内容を１つのメソッドの中で一緒くたにやって
しまうのか、という違いか。

例えば「更新」ボタンを考えてみる

更新を押すとサーバと通信し、クライアントアプリケーションの
ルートから一部を除いた状態を反映して画面を全て書き換えたいとする。
状態の更新と画面の更新は特に連動する機構はない。
また、更新が終わったらステータス画面にｎ秒間「更新しました」と
メッセージを表示したい。

この、「更新」を押すというメソッドはどう書けばいいだろうか？
１つの機能で済むだろうか。

>>254
自分中心にしか物事が見えて無くないか？

多分俺が「一つの機能」=1メソッドとして書いたなら
CollateUser()はさらに複数のメソッドで構成されることだろう。

構造化プログラミングで、最小単位をどの粒度まで小さくするかなんて
コンセンサスは無いように思える。

>>256
議論の叩き台であって、俺が別に必ずそういう風にコードを書くという意味ではないが。
CollateUserといっても、相手がファイルなのかデータベースなのかでいろいろ
変わって来るからね。

リファクタリング嫁

おまいら、自分が見て来たコードが世の中の全てとか平均と勝手に思ってないですか。
何年PGやってるか知らないけど、おまいが見たソースコードは世界中のソースコードの
１％にも満たないんじゃないですか。
そもそも話題の焦点にしている開発内容はなんですか。言語はなんですか。

>>257
つか、DBかファイルかでCollateUserの外が変わるような構造にするなよ。
すべてCollateUserの中で解決しろ。

あたしゃ馬鹿だから、対象でI/Fが変わるような関数作っても覚えられないから
対象ごとにクラス作って同じ名前のメソッドは同じI/Fにしちゃうねぇ。
んで、I/Fが違うのはコンストラクタだけだったり。

>>260
CollateUserメソッドの中身が、いろいろ変わってくる、と言っているのです。

なんつーか、実現したい機能（業務ロジックだったり、データをExcelに書き出す機能だったり）は
クラスつかえるなら１クラスに、使えんならファイルスコープでくくるなり、
グループ化するだろ。
同じインターフェースで使いたい似たような機能があるなら、interfaceやfactoryも用意する。

その上で作成されたクラス内の１メソッドも
・データ（ファイルでもDBでもメモリでも）取得
・処理１
・処理２
・処理３
・データ書き込み
みたいに抑えるべきでないのかい？

Button_OK()にOKボタンの処理全てを書いてしまうと、そりゃコメントは必要になる。

なんか間違えた。
読み込み、書き込みとも同じクラスってのはやんねーな。
・データ取得クラス
・なんかの処理クラス
・データ書き込みクラス
って感じで、それぞれのクラスで
処理１、２、３だな

>>264
なんかとっても手続き型ですね。

パフォーマンス上の理由とかで
読み書きを同時に行いたいとかなったらどうするの？
さらにサーバと通信しながらとか
画面書き換えながらとか
連携するのがほとんどだと思うけど
コメントないとなんでこういう順番なのかわかんなかったり

>>265
C++やらJavaやら使っている時点で手続き型なんですが。

>>264-265
今のプロジェクトのコードがすげー気持ち悪かったんだが、なんとなく理由がわかった。
手続きを中心に考えたクラス設計になってるからか(そういうパラダイムの奴が設計したんだろう)。

>>267
>C++やらJavaやら使っている時点で手続き型なんですが。

いや、>>265 は、

俺は「オブジェクト指向」という
「非手続き型」の世界の人間だ。

と言いたいのだろう。

そっとしておいてやれよ。
それはそれで一つの生き方なのだから・・・

いやいや、JavaにしろC++にしろ1メソッドの中身が手続きを中心に書かれるのは分かるし
コントローラークラスみたいなクラスがあるのも分かるけども

>>264のクラス設計は気持ち悪い。
データ取得クラスはデータを取得するっていうpublicなメソッドと
その他のprivateメソッドから出来てるわけですよね。
それはCのライブラリのようにstaticメソッドだけのクラスばかりを
作る人と大差ないと思うのです。

>>264
その「なんかの処理クラス」が「データ取得クラス」と「データ書き込みクラス」を所有
してたりデータアダプタとしてプロパティ化しているならその設計も有りだな。
あるメソッド中でその3つのクラスを個別に操作しているなら、でっかいクラスに3つの
手続き型メソッドを書いてるのと何ら変わりない糞コード。
いや、細かい単能jクラスが増えるだけさらに有害かもしれん。

実際はこう。
・FooDAOFactory
・FooDAO
・FooDAOImpl
・FooLoader
・FooRegister
クラスやメソッドの説明は必要。だけどメソッド中にコメントはいらん。
コード嫁。以上。

>>272
Fooに対してなんでLoaderとDAOが同列に存在するのさ？

>>272
Fooは扱うデータか？いやそれにしてはFooクラスが無いな。
名前空間というか接頭語みたいな物か？
意図の分からん命名ってコードを読む気力を激しく奪うぞ。

関数は粉々になるまで分けるのが正しいらしいが
関数名に困る

良いコードを書くためのウハウハを蓄積するスレ

>>275
名前が付けられないのは分けすぎの証拠。

>>275
関数のオーバヘッドは無視できない。

>>278
粉々にしているんだからinlineにすればいいだけだと思う。

>278
最近のWindowsPGで
関数のオーバーヘッドを気にするような必要ってある？
そもそも、処理を関数で細分化するのは、メンテを容易にするためであって
高速化の為ではない訳で・・・

俺も、>275と同じ問題はしょっちゅう感じる
ある処理を細分化して
その処理中の１度しか呼ばれないような関数の場合の
命名手法はどんな感じ？

>>280
そこで匿名関数を使う。

>>280
Cのような代入型言語を使うのではなくて、最近では関数型を使った方が生産性が
高い事が多くなったように思わない？

>>280
「処理の分離／細分化」ではない。「機能の分割」だ。#細かなところは突っ込まないで
機能の分割が出来ていれば命名に悩む事なぞないと思うが

>>280
名前の付け方で困るほど細分化したら却ってメンテ性下がるだろ。
何のための関数なのかが自明なレベルで止めとけって。
（自分には判ってるから大丈夫とかアマチュアな事言うなよ。）

>>280
＞ ある処理を細分化して
＞ その処理中の１度しか呼ばれないような関数の場合の
＞ 命名手法はどんな感じ？
他の関数と同じ方法でつければいいじゃん。

ラムダよりもforeachが欲しい

>>286
アルゴリズムのstd::for_eachで十分……、なわけないよな。

ラムだっちゃ☆

>>286
C#使ってみなよ、あんまり便利でもないよ、for文+イテレータのほうがシンプルでいいね。

>ある処理を細分化して
>その処理中の１度しか呼ばれないような関数の場合の
>命名

そんな困るような分割するのが頭悪い

>>290
たとえば、Cにおけるコマンドライン引数処理なんて
mainの中から一度呼ぶだけだったりしますが。

>>291
呼ばれる頻度で名前の付け方変えるってどこの世界の命名規則でつか？

>>292
さぁ。そんな命名規則見たこと無いけど。

頻度っていうかprivate, staticなものはいい加減に付けがち

関数にしたんなら
関数にされた一連の処理群に何らかの意味的なマトマリを見い出してるはずだから
その意味を英訳して関数名にするがよい

勿論「returnで流れ制御」したいがために関数を作っちゃう馬鹿はどっかいけ

296
便利さと性能、どちら優先かによる

Cライクな言語はもううんざり。

これからはschemeか。

Schemeもいいけれど、ML系のOCaml辺りの方が実用的でよさそう。

＞returnで流れ制御
って何？

例えばreturnで多段breakをしたいが為だけに関数を分割するって話だろ

>291
>コマンドライン引数処理

そう名づけりゃいいじゃんかよ

>>303
一度しか呼ばれないような関数を作る奴は頭悪いんだろ。

>304
>一度しか呼ばれないような関数を作る奴は頭悪い

ってのは違うぞw
名前付けに困ってるんだろ？

名前付けに困るような分割＝１度しか呼ばれないような関数への分割でしょ。

>>303
main も駄目でつか？

func(){
　func_init();
　func_run();
　func_done();
}
とかだらだらと_でつないでいけば少なくとも迷うことはない。

通行人A、通行人B ・・・ でどうだろうか？

ん？

>１度しか呼ばれないような関数への分割
するときに名前付けに困る時があるって話だろ？

名前付けに困らないから、先のケエスは無問題だ

1 度しか呼ばれない関数を作るのが抽象化の目的であれば良いコードです

どうでもいいけど１度って書くと角度みたいだね

んん？
角度ってラジアンだろ？

>>313
いいえ。

１００前後読んでたら、仕様書からいきなりコーディングしてる奴がいた。

蓄積しま
ttp://www.okisoft.co.jp/esc/go/style0.html

>>272
スコープが
上３つはpublic
下２つはpackage

>>317
>>272書いた人？
静的クラス図書いてUPしてほしいな。

スレッドも1/3経過したことだし、これまでに蓄積されたノウハウをまとめない？

電車男みたいに本にして儲けたいらしいが、
ttp://f55.aaa.livedoor.jp/~goodcode/
にまとめるとか。

これまでの成果
---
・公開されているよいソースコードを読むとよい
・assert文を使うとよい
・よい本を読むとよい
・コード量が少なくなるようにする
・メソッドの数をできるだけ少なくする
・クラスはできるだけ作らないようにする?
・リファクタリングする
・素早く頭働かす?
・メンタルの健康を保つ?
・ネストはできるだけ下げないようにする?
・変更履歴にはwhat i didではなく why i did itを書け?
---

この先続けてもたいした成果は得られないような…

結論
自分で書かない
人のやつをパクる

シンプルが一番
可読性も保守性も効率だって

万一、実行速度が問題になったとしてもそれに集中しやすいし

>>322
人のやつもパクらない。
作る側から使う側へクラスチェンジする。

297 ：仕様書無しさん ：05/01/06 00:55:02
テストファーストとはテスト項目に重点をおいてコーディングを行う開発手法のこと。
テストを通ることを最優先して実装を行う。
モジュールの品質はテストによって保障されるが、 最初からテストを通ることを主目的にしているため、品質の確保がしやすい。
利点として
・テストケースにない機能は実装しないので
「将来発生するかもしれない」とか「仕様書にない機能」のような余分なことをしないので、
余計なバグの混入を防ぐ
・あらかじめテスト項目を作成するため、PGの頭の中でロジックが整理しやすい
などがある。

「テスト」とひとくくりにすると混同しやすいが、 「テスト工程をクリアしたら品質が保障される」ということを逆手にとって
「では最初からテスト工程を通ることを重視する」だけであり、 テスト工程でのテスト作業そのものを指すわけではない。

298 ：仕様書無しさん ：05/01/06 01:03:16
もちろんテスト作業の質を上げる工夫もされているが、 テスト作業（テストケースの作成、結果確認など）がタコなら品質は保証できない。 （これはアフターテストでも同じだが）
アジャイル開発などでは、コードの修正を行ったら回帰テストを全項目行うことを推奨していたはず。
全項目を確認しなおすことで、ソースに対する信頼性を保障することが出来る。
ただし、これを人手やるのは大変なので回帰テストの自動化が求められている。

301 ：仕様書無しさん ：05/01/06 03:51:53
俺が思うに「最初にテストケースを考える」ことこそテストファーストの真髄だと思うんだ。
（テストファーストを唱えてる人がどう思ってるか知らんけど）
そこで生まれたテストケースが貧弱かどうかは実はどうでもよくて発想の転換で
テストケースを濃くする事とコード書く時に外部条件を意識して書くようにする事
要するに熟達したプログラマが普通にやってるこの2点をシステマチックにやる事で品質向上を狙うモノではないかと。

if(flag){
　　func();
}
というインデントが多いみたいだけど
if(flag)
{
　　func();
}
これだとダメなの？
こちらのほうが対応するカッコの数とか分かりやすいんだけど。

>>326
人それぞれ。
私は前者。

>>326
なるべく行数を減らした方がコード全体を把握しやすくなるというメリットがある。

でも行数が減って積め積めになるとかえって読みづらいと思う。
コード数を減らす事が良いコーディングと聞いて行数を減らそうと
勘違いする人がいるけど、そういう人に限って凄く密集したような
コーディングするんだよなぁ。
しかも変数名もとにかく短くて意味の通らないものにしたりするし。

>>329
いや、たしかにそうなんだけど、私が言っているのはもっと物理的な面の話。

しかし、こういうのは人に強制できるものじゃないから
人それぞれのコーデイングスタイルがプロジェクト内で混ざり
まくるんだよなぁ。
深いインデントの中に違うスタイルのインデントが入ってきたりとか。

>>329
ifとfuncの間が一行空いている積極的な理由が思いつかない。

if(flag) func();

>>326
つか、カッコの数を数えないといけないようなコードを書くな。

>>326
K&Rに倣っている人も多いんじゃないかな。

>>334
呼んだ？

>>336
インデントはエディタに任せるから数えたことないなぁ

括弧の前に改行一個入れるか入れないかで
議論になるお前らのミジンコサイズの根性がかわいいぜ

シッコの穴の小さいやつらだ

>ifとfuncの間が一行空いている積極的な理由が思いつかない。

見やすいじゃないか。ifの横にカッコがある事に気づかない事も
たまにあるしブロック化されているのが明確になっていて良い。

見やすいか? それと同じように>>326の下の方が見にくいという主張も成り立つが。
むしろ条件と関係なくローカルスコープを作るためのブロックと混同しそうでいやだ。

do
{
if (...)
{
...;
}
else
{
...;
}
}
while (...);
と書くのだろうか…
私なら
do {
if (...) {
...;
} else {
...;
}
} while (...);
と書くのだが。

条件式が複数行になる場合
if(...
　...
　...) { // ここと
　...; // ここがくっついて見えるのが嫌

>>342
インデントされてないが上の書き方のほうが見やすい。
まぁdoは自分は使わないけど。

>>344
do
{
while (...) ...;
}
while (...);
while (...) ...;
と
do {
while (...) ...;
} while (...);
while (...) ....;
では?

うえは
}
while (...);
が紛らわしくてやだ

>>340
＞ ブロック化されているのが明確になっていて良い。
ifとそれに続く処理が別のブロックのように見えちゃうのはいかんだろ。

良いコードを書くためには
Eclipseを用意し、設定でコードの警告メッセージを出す設定で、無視となっているものをすべて警告に変更する。
コードフォーマッタを使う。
Subclipseプラグインをインストールし、Subversionでバージョン管理する。
メトリクスプラグイン、プロファイラプラグイン、CheckStyeプラグイン、Jalopyプラグイン、Findbugsプラグイン、
Code Analysisプラグイン、SolarEclipseプラグイン、SimScanプラグイン、プロパティエディタプラグイン、
Lombozプラグイン、Sysdeo Tomcatプラグイン、Hibernateプラグイン、Sobalipseプラグイン、
JBoss-IDEプラグイン、DbEditプラグイン、EclipseUML Omondoプラグイン、Easy Strutsプラグイン、
Bytecode Ontlineプラグイン、XMLプラグインをインストールする。

Apache Ａｎｔでbuild.xmlを書く。
MevenideをEclipseにインストールし、
Apache Mavenでproject.xmlを書く。
Mavenを利用してJakarta CommonsのAPIを積極的に使う。

テストファーストを実践し、JUnitを毎日欠かさず実行する。

これでよしっ！

>>341
>ローカルスコープを作るためのブロックと混同しそうでいやだ

ローカルスコープを作るためのブロックなんて使わない。
これで万事解決。

>>349
アフォハケーン

>>345
do
{
　　while (...)
　　{
　　　　 ...;
　　}
}
while (...);

while (...)
{
　　...;
}

インデント、ブロック化、改行を活用する。

結論はやはり人それぞれ。

３０年かわらぬ嗜好品だな

人間の目は横に並んでいるので縦方向に長いものは把握しにくい

do{
　　while (...){
　　　　 ...;
　　}
}while (...);

while (...){
　　...;
}


どう考えてもこっちの方が把握しやすい

本で読んだ受け売りだけど。
#ifdef FOO
if (hoge)
#else
if (piyo)
#endif
{
　　statements;
}
こういう場合に、エディタの括弧対応調査機能が働きやすいというのがある。

バッドノウハウだな。

if(hoge){
foo;
}

の人は何で

if(hoge{
foo;}
にしないの？

}else{

>>358
}が最後尾になって追跡しにくいから。
関数型だったら手続きがないから最後尾の}はOKだけど。

>>356
それに近い事よくやるよ。
ifの行だけ#ifdefとかで無効になっても残ったブロック部分も
問題なくコンパイル出来るしね。

>>356
普通は
#ifdef FOO
#define COND hoge
#else
#define COND piyo
#endif
if (COND) {
　stmts;
}
みたいに書かないか？

単独で記述することができないキーワードが先頭に来るのはきもい。
x
if (hoge)
{
}
else
{
}

o
if (hoge) {
} else {
}

きもいじゃ理由にならん。
見た目で語るなら個人差がある。

>>362
それだとifでbreak張ってもCONDがどちらか分からないんじゃない？

m
a
i
n

これにはびっくりしたよw

>>356 >>362
普通は
int hoge()
{
...
}
int piyo()
{
...
}
int (*stmts[])() = {hoge, piyo};
int fuga = stmts[FOO]();
みたいに書かないか？

>>367
#define FOO
だったらどうする

>>368
あふぉか？

>>21
> 9 a(1, 1);
これだな。

こういったスペースの調整はとりあえずフォーマッタツールでどうにかなる
Eclipseならコードフォーマッタの設定でできる。

しかし、フォーマッタツールによっては厄介なこともまだまだある。
たとえばEclipseのコードフォーマッタは
//によるコメントを乱してしまう。

たとえば
////////////////////////////////////////////////////
//　　　　　　　コメント　　　　　　　　　　　　　　　　　　　　　　　　//
//　　　　　　　コメント　　　　　　　　　　　　　　　　　　　　　　　　//
//　　　　　　　コメント　　　　　　　　　　　　　　　　　　　　　　　　//
////////////////////////////////////////////////////
のようなボックスで囲まれたコメントをつける癖のあるコメントがある
コードにたいしてコードフォーマッタを実行すると
見事にこのコメントが乱れてしまう。
VC++プログラマがEclipseを使おうとしたときによく陥る問題である。

こういう場合
/**
* コメント
* @author $Author$
* @version $Id$
*/
で統一する必要がある。
VC++プログラマが書いたコードを調整したいときもこの問題に直面する。
//を好んで使う癖がある人のコードに対して/** */ を求めると
抵抗する人もいる。実際そういう人と仕事をしている。

>>362
それだと

#ifdef CHECK
if (COND)
#endif
{
    sttmts;
}

と書けないから。

>//を好んで使う癖がある人のコードに対して/** */ を求めると

Eclipse側の問題を//スタイルのプログラマにしわ寄せさせるのは良くない。

(;ﾟ∀ﾟ)=3ウハウハを蓄積

>>372
>Eclipse側の問題を//スタイルのプログラマにしわ寄せさせるのは良くない。

C89 との互換性を考慮するプログラマにしわ寄せさせるのも
いかがなものかと。

互換性考慮がチームで決定された方針なら全員あわせるべき。
それが個人による趣味の範囲なら人それぞれ。
C++で//を使うなという話自体はナンセンス。

複数行に渡るコメントは、#if 0 を使ったり　include にしたり

>>376
>include にしたり
?

>>377
コメント行のみで構成されるテキストファイルを作ってincludeするのだよ

>>376
それはそれでひとつのテクニックだとは思うけど、
コメントの為にあるものではないし、
エディタ上ではコメント扱い(の表示)になってくれない。

>>378
ごめん、それ、何の意味があるのか判らない。
例えばfoo.cppに
// See foo.txt for detail.
って書けば済む気がしてならないんだけど。

>>378
基本的に、コメントはコンパイラじゃなくて人が読む物なのに、
わざわざ別ファイルにして、そっちを開かなきゃいけなくなるのが馬鹿馬鹿しい。と思えるのは自分だけですか？

無意味

まともに動けばそれで良い

>>378
プリプロセッサを通さないとコメント読めないの？
とてつもなく不便な気がする。

ifやwhileの{を条件式の後に続ける人でも
関数始まりの{は行頭に書くのはなんで？

確かにそうだよな。統一感が無いね。

おれは関数始まりでも行の後ろに{つける派。

ふふふ。やはり不評だｗ
>>379
前半。ご指摘の通り。
後半。色分けが出来るエディタ使用を前提にされてもね。
>>380
これまたご指摘の通り。
>>381
貴方だけではないｗ
>>384
全くその通り。

私が恐れるのは「複数行に渡るコメントを記述する事が、コード自体の可読性を損ねる場合」だ。
一読すればわかるレベルの10行程度の関数に20行ものコメントヘッダを付加しなければならないとしたら、
ソースファイルの行数は単純計算で三倍になるよね。
・・・いやまあ叩き続けたいならそうしてもいい。
単に自分の習慣の一部を書いただけだし、議論する気もない。

逃げたか・・・

>>389
いいや。逃げていない。
道義的な悪をなしたと思っていないので「逃げる」という言葉が適切だとも思えないしね。
議論したいの？。不毛だと思うけどね。反論したくなるレスをどうぞ。

>>390
コードの容量を無駄に食うだけで、何の意味も無いと思う。
確かに大量のコメントによるコードの可読性が損なわれるケースはあるけど、
それならプログラムとは別に専用のファイルを作ればいいでしょう。
includeする意味なんて皆無だと思う。

>>391
意味は確かにないのだが。
「全ての関数にはコメントヘッダがなくてはならない」
という考えを持った人間と仕事したことがあってねｗ。
コメントヘッダの総行数がコードの総行数より多くなったので、
コメントヘッダ全てをincludeにした。とても読み易いコードになったよ

>>392
で、あなたがその考えを今も引きずっている訳は？

>>393
引きずってなどいませんよ。
規約にもないのに「全ての関数にはコメントヘッダがなくてはならない」という
横車をする人間がいない限りは。普段からそんな事なぞ絶対にしないｗ。

Doxygenを使うと関数にコメント付けるけどそれについてはどう思う？

コメントだったら、エディタによっては隠す事ができる機能がある物もあるよね。
そういうエディタを使えば気にならないんじゃない？
ソースと同じところにコメントがあってこそ意味があると思うし、
Doxygenなんてもろにその思想でしょう？

>>395
ああ。ソースコードからプログラム/詳細設計書を生成するツールだね。
あれは基本的にプログラム/詳細設計書を作成しなければならないという契約下における
省力化のためのツールだ。もちろんその様な規約になっていればその通りにするけど。
「プログラム/詳細設計書を作成しなければならない」という事自体に、反対。
#ruby開発者と同意見かな
#ツールの話ではなく、コードの話をしたいのだけど

>>397
それだけではなく、
ソースを読むときに手助けになるから、初めて読むようなソースにはDoxygenかける
こともあるよ。自分のソースを見返すときにかけることもある。

>>392
ひとりでしこしこ書くコードじゃないのなら、
せめて引数と戻り値の仕様は書け。

DoxygenとCVSを組み合わせるとソースにリビジョン番号を
埋め込む事ができるよね。
確かコメントに何か仕掛けするんだと思ったけど。
コメントだけ別ファイルにするとわけが分からん事になりそうだ。

>>400 それ、Doxygen関係ない。

>>400
これのことだろ。
ドキュメントにもリビジョン番号が付加されて (ﾟдﾟ)ｳﾏｰなんで重宝してる。

【ソースの先頭部】さくらエディタのソースより拝借
//  $Id: CAutoSave.cpp,v 1.6 2001/12/19 04:19:10 genta Exp $
//
//  CAutoSave.cpp
/*! @file
    @brief ファイルの自動保存

    @author genta
    @date 2000
    $Revision: 1.6 $
*/

【doxygenでの出力結果】
ttp://members.at.infoseek.co.jp/sakura_editor/html/CAutoSave_8cpp.html

メンバ変数の名前は
1 m_testData;
2 m_TestData;
3 testData;
4 TestData;
だったらどれがいい？

m_test_dataだったり。

おれもだ。
以前どっかのサイトでそのスタイルを推奨してるところあったよ。

私は最近mTestData;

VBだと完全一致検索で「_」が無視されるので(´･ω･`)

>>326
実際のところ、紙面上の都合が全て。
下のコードだとページ数が余計にかかり、コスト高になる。
他の理由はそれを誤魔化すためのものにすぎないのだ。

ハァ?

いまだに行数で値段決めてんのか？

>>410
お前の一行1円。

なんのコストだよ。ケチ臭い。

実装した機能に対して行数が少ない程対価が多くなるようなレートを設ければ
競ってリファクタリングせざるを得ないだろう。コードを読む方はそれを望む。

>>413
行数じゃなくて、もうちょっとちゃんとした「読みやすさ」の指標がほしいね。

改行なくて全部一行とか、変数みんな一文字とか、処理全部一関数とか…
そんなコードが高い対価を得ても困るし。

短いトリッキーなコードより、少し長くても素直なコードのほうが読みやすいよ。

>短いトリッキーなコードより、少し長くても素直なコードのほうが読みやすいよ。

いくら素直なコードでも、なんの工夫もなく無駄にだらだらと長いコードは
かえって読みづらくなると同時にメンテナンス性も著しく低下するし、
このへん、「こーゆーのが理想的」とかっていうなんらかの客観的な指標が欲しいね。

こんな所でだべってないでコード書けよ。

こんな時間にコード書いたって、いいコードにはならない。

>短いトリッキーなコードより、少し長くても素直なコードのほうが読みやすいよ。

そんな事行ってたらtemplateなんてどーすんの。
トリッキーの塊みたいなもんだし。
改行も故意に入れないといつの間にか横長になるしな。

404-405
GNUコーディング規約は小文字でアンダースコアだね。

マジだ。
http://www.gnu.org/prep/standards/standards.html#Formatting
変数はこれから小文字とアンダーバーで決まりだね。

ブロックのインデントこ↓だったわけだが。
do
{
a = foo (a);
}
while (a > 0);

そのへんは後でフォーマッタかければなんとでもなる。

ちなみにsunのjavaコーディング規約
http://www.tcct.zaq.ne.jp/ayato/programming/java/codeconv_jp/index.html

俺はJava厨だからこれが一番だなぁ。

>>420-422
GNUは、Cで書くことが前提になっているからね。

なんでsunの社内規則に従わにゃならんの

>>415
それは、読むのがつまんないってだけで。
お前を面白がらせるためにコード書いてる訳じゃないので…

>>425
似たようなコードがそこらじゅうにちりばめられてて、
その部分にバグがあった時の大変さを知らんのか？
その手のコードは共通部分をまとめて抜き出そうなんて
考えが全然ないから本来なら共通化できるコードと
そうでないコードが完全にごちゃまぜで、デバッグが
洒落んならんぞ。

>>426
トリッキーなコードと簡潔なコードの区別ぐらいしようよ。

>>427
いや、だから「客観的な指標が欲しい」つってんじゃん。

>>428
構造化も出来てないコードは簡潔云々以前の問題だろ。

>>429
最初はちゃんと構造化されてても
なんの工夫もなく無駄にだらだらと長いコード書いてたら
結果として自然にそうなってくるんじゃないのか？

構造化ってなんだ･･･

>>430
最初に構造化と決めたならなんの工夫もなくても構造化だけは
普通やってくんじゃないの？そこにテンプレートとか組み合わせれば
似たコードはだいぶ少なくなると思うけど。
そして欲を言えばOOPと。

トリッキーなコードというとboost::lambdaとかを想像する

>>426
低レベルな奴らは、本来共通化しちゃいけないものを無理矢理共通化するから侮れない。

それはオブジェクト指向の考え方がまったく身についてないからだな。

何でもかんでもオブジェクト指向を適用するのは勘弁して欲しい。
オブジェクト指向こそが優れ、C++でのコーディングはC流より優れる。

こういう考えの人が最近多い気がする。

勘弁して欲しい理由は？
例えばあえてOOPに反するが自分では良いコードと思っている例を
挙げる事ができる？

> 勘弁して欲しい理由は？
簡単。オブジェクト指向なんてメンテのためだけにあるただの経験則。
速くて効率の良いコードとは何の関係もない。
良いアルゴリズムの開発にオブジェクト指向なんて何の役にも立たないし、
少人数の意志の疎通が良くできる精鋭でのプロジェクトならオブジェクト指向なんかいらん。

大規模なプロジェクトでダメダメな人間も参加する場合や、時間とともにいろ
んな水準の人間がコードをメンテしなきゃいけないような場合は、効率を犠牲
にしてでも見通しのいいコードの方が経済的。
オブジェクト指向なんてそんな場合にしか有効じゃないよ。

きちんとした理論もないし、現場から汲み上げられたノウハウで80年代には既に広まってた。
今どきまだオブジェクト指向なんて叫んでるやつの気が知れん。

そう言う見方もあるのは判るが、そう言う見方だけに拘泥していては大局を見失うよ。

>>438
良いアルゴリズムを良いまま隠蔽するためにもオブジェクト指向は有効よん。

>>438
> オブジェクト指向なんてそんな場合にしか有効じゃないよ

実際は「そんな場合」のほうが大方なワケよ。
あんたは「少人数の意志の疎通が良くできる精鋭でのプロジェクト」
しか経験したことが無いのか。幸せだな。

>>441
> 実際は「そんな場合」のほうが大方なワケよ。
そりゃあんたの不幸な環境ではそうだ、って話。優秀ならそんなみじめな境遇には陥らんよ。

>>442
お前さんの書いた優秀なかっこいいコードをうぷきぼんぬ

>>438
アルゴリズムと設計は別物であることもわかってないような職場では働きたくないなぁ。

分野によるんじゃない？
数値計算とか解析だったらオブジェクト指向なんて使わないでしょ。

なぁ、そろそろ設計時のオプジェクト指向と実装時のオブジェクト指向を
はっきり区別して話さないか。

保守のためだけでOOPにしてると思われたくないものだな。
データ構造が保証されるんだよ。ある程度。小規模であっても。
設計時のOOPはどうでも良いが。ソースコードでしゃべれない人は論外なので分ける必要がない。

>>447
> データ構造が保証されるんだよ。ある程度。小規模であっても。
頭悪いんですね。「データ構造が保証される」だって。

何の話をしているのかさえあやふやになってきたｗ

プロジェクトなんかどうでもいい。
アルゴリズムを研究する人間にとってはOOPなんか本質でもなんでもない。
ここには職業プログラマしかいない、みたいに決めつけた議論はやめとけ。

アルゴリズムだけを追ってる立場では、良いコードなんか本質でもなんでもないわけだが。

>>451
良いコードとは良いアルゴリズムの具現である。

>>452
グローバル変数使いまくりでスパゲッティ状態なコードがいいコード？

よいコード書ける奴はこんなとこで油売っていない罠

>>454
ダメだよ、そんな元も子もないこと言ったら。

　　　　_、_　　　　　　プログラミングの友　マクロン
　 　（　,_ﾉ` ） 　 　　n　　　　＿＿
　￣　　 　 ＼　 　 （ E）　／ ＿／|
　ﾌ 　　　 /ヽ ヽ_／／　　|◎±|／　MACRON POWER

http://www.casing.com.tw/

>>451
アルゴリズムだけを追ってる立場では、良いコードとは速くて効率の良いコードなわけだが。

良いコードとはアセンブラで書かれた最速のコードである。
ただし最適化しすぎると他人には解読不能。

ハードで実装したほうが良くないか？

アルゴリズムだけを追っている立場では、良いコードとはアルゴリズムを説明しやすいコードである。

「良いコード」の定義次第になってきてんのか。やっかいだなぁ。
アプリケーションを作る立場で考えると
一般的にはモジュールを細分化するほど保守効率が上がる。
（ただし数が増えるので、モジュールの管理効率は下がる）。
逆に細分化をやめて、中身を最適化すれば実行時効率が上がる。

そんなことから俺の思う「良いコード」は基本的には細分化されていて、
ここが変えたい（実行時効率が欲しいって要求かもしれないし、仕様変更かもしれない。）
って時に簡単に差し替えられるようなコード（設計？）だろうか。
差し替えできないコードなんてやってられん。

>>461
あるかどうか判らない改造のためにプラグイン的な構造にするのは無駄｡
都度リファクタリング汁｡

2chでは「リファクタリング汁」が流行ってるけど
ほんとにそんなにちょくちょくモジュールに手を入れてるの？
で、リファクタリングの前提となるUnitTest用のテストケースを完備してるの？

対象とするプログラムをある程度仮定しないと議論しようがないと思うのだが・・・。

・数値計算
・デスクトップアプリケーション
・組み込み
・コンピュータグラフィック

どれも性格が異なるでしょ。

>>463
それを言えるのは研究的、または先進的な職場か
極少人数で開発しているからのような気がする。
知らぬ間にリファクタリングでコードがガラッと変わってたりしたら怖すぎる。
UnitTestは単体作成者でも使えるから手は出しやすいよね。

詰めviｽｷｰな人はﾘﾌｧｸﾀﾘﾝｸﾞ奨励派

>>465
> 知らぬ間にリファクタリングでコードがガラッと変わってたりしたら怖すぎる。
OOPでコード管理していればそんなこと思えない

>>467
この間半月かけて解析したのに、また一からやり直しかよ。

>>463
将来の改造のためにモジュール化を推し進めるよりその努力をUnitTest作る方に向けるべき。

>>469
それどういう環境で実践してるの？
個人の趣味開発じゃないよね。

>>470
業務系システムのサブシステムを5人程度で。
コード行数は10万行ぐらい。
言語はVB6（ｗ

うむむ・・・。ご愁傷様ﾃﾞｽ

「本当のリファクタリング」なら書き方は変わっても
内容は変わらないのだから問題ないはずだけどね。

いやだから、何に注力すべきかという問題で。
469の開発環境が「保守性より信頼性を要求されている」という事では？。
どっちも定量化の困難な品質特性だから、「ここまでやったから（充分で）今度はこっち」
という匙加減が出来ないのかも

リファクタリングの誤用
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?RefactoringMalapropism
| リファクタリング中に2,3日システムが動かなくなっちゃってーなどと言ってる奴がいたら、んなもんリファクタリングじゃあなーいと言ってやれ。

信頼性確保のための UnitTest ね。
リファクタリングには必須。まぁ、理念だけど。

何かしらソースに変更加えたら、それが正しいか検証するのは大変だ。
リファクタリングソフトが完全なら良いのだが、誰も保証してない

>>476
そのためのUnitTestって話なんだろうけどね。

>>474
哲学になってくるからねぇ。

どういうスタイルを推奨するかっていうのは
構成する人間の性質やスキル、経験による部分が多いし。
言ったことしかやらない人間が多数なら
コーディングの見た目をコロコロ変えないで判に押したように
作らせるのも一つの（あくまで一つの）手段だよな。
理想はできる奴用、できない奴用の部分を綺麗に
分けちゃうことか。できる奴には上位の概念まで必要な特殊な
ところを担当させる〜みたいな。

どっちにしてもUnitTestは外したくないけど。

うむ。この中にリファクタリングを理解していない人がいるようだ。
参考文献をどうぞ。
ttp://e-words.jp/w/E383AAE38395E382A1E382AFE382BFE383AAE383B3E382B0.html
ttp://www-6.ibm.com/jp/developerworks/opensource/040130/j_os-ecref.html
ttp://www.amazon.co.jp/exec/obidos/ASIN/4894712288/
ttp://www.andore.com/money/trans/rework_ja.html

UnitTestなんてウゼーとか言う奴に「じゃあ単体テストは一度しかやらないの？」って尋ねると
不思議そうな顔するな（ｗ
GUIならともかく、ビジネスロジックの反復テストを手動でやるコストをどう考えてるんだろう？

>>474
保守性と信頼性がトレードオフな関係だと思ってる？
UnitTestちゃんと書いてれば保守性も後から付いてくるんだけど。

信頼性とはデータ隠蔽の方だと思うので保守性と信頼性とが共存できるとは限らない

UnitTestって良く分かんないんだけど、普通の単体テストとassertでの事前・事後条件の
チェックと違ってどういうメリットがあるの？教えてエロイ人！

UnitTestって良く分かんないんだけど､普通の単体ﾃｽﾄの自動化というﾒﾘｯﾄがある?教えてｴﾛｲ人!

>>484
GUI部分以外で手動のテストってあるのか？

>>485
ない。
GUI部分も自動のﾃｽﾄってあるよ。
教えたとおりにﾏｳｽｶｰｿﾙがﾂﾂｰと勝手に動いてやってくれるやつ｡
製品名忘れました｡

UnitTestはUnitTestでしかないからねぇ。
テストに通ったからといって信頼性の高いシステムになるわけでもないし、
リファクタリングしたからといって改修しやすいコードになるわけでもない。

>>487
え？
テストが通ってるのに信頼性が低いのって単にテスト項目が不適切なだけじゃん。
リファクタリング出来たのに改修困難って何のためのリファクタリング？

UnitTestでテストできる範囲なんてたかが知れてるし、
リファクタリングの方向性に合った改修が入ることなんて稀。

ＳＥ「え？あそこの条件変えればいいだけじゃないの？」
ＰＧ「いやぁ、前回のコードからがさっと変えちゃったんで、
　　　ちょっとすぐには回答できないっす」

>>489
> UnitTestでテストできる範囲なんてたかが知れてる

そうか？
それはテストファーストで設計してないからそう思うだけじゃないのか？
UnitTestでテスト困難なコードは手動でやっても困難だと思うがな。

テストファーストだろうが、あとで手動でテストしようが、
それは一連のテストに通ったということしか保障しない。

＞ UnitTestでテスト困難なコードは手動でやっても困難だと思うがな。
そういう領域でいかに良質なコードを書くかが問題なわけで。

結合ﾃｽﾄ、機能ﾃｽﾄ、高負荷ﾃｽﾄとか後段階のﾃｽﾄを含めたﾃｽﾄ計画全体に対するﾕﾆｯﾄﾃｽﾄのしめる割合がたいしたことないと言いたいのでは？

使わないよりもコードの品質を高める効果はあるよね。
デグレードを防いでくれる部分もあるし。
それに全部勝手にやってくれるからテスト抜けみたいなこともない。
あと手動だと、あっちを立てればこっちが立たずって時に苦しい。

後段階のテストでうまく行かない原因が、単体の不備に帰着する
っていう状況を減らせるとは思う。

＞＞ UnitTestでテスト困難なコードは手動でやっても困難だと思うがな。
＞そういう領域でいかに良質なコードを書くかが問題なわけで。
そういう部分にのみ集中するための時間を作る道具として利用したら
いいと思う。道具は特性を見極めて使ったら良いのではないかな。

みなさんどんな品質のコード書いてますか？

>>494
最低品質のｺｰﾄﾞ書いてます｡
その代わり､ｺｰﾃﾞｨﾝｸﾞ時間は最短｡
それでﾊﾞｸﾞ･ﾚﾎﾟｰﾄたくさん｡
でも直ちに最低品質のｺｰﾄﾞで修正｡
最初に戻る｡

>>495
素早いリリースを実践していらっしゃるのですね。

>>495
急がば回れ

素早いﾘﾘｰｽってなんじゃらほい｡

　　空の関数を作成
　　↓
┌→｢動かねぇ〜｣
│　↓
│　与えたﾃﾞｰﾀと結果を教えてもらう
│　↓
│　ﾃｽﾄｹｰｽに追加する
│　↓
│　全てのﾃｽﾄｹｰｽで動くようにする
└─┘
ﾃｽﾄｹｰｽを作るのって面倒なんだよ｡
思いもしない使い方をする輩がいるし｡

面倒なので現実的なﾃｽﾄｹｰｽを上の方法で他人から得ている…ごめんなさい｡
他人には最初からﾃｽﾄ&ﾃﾞﾊﾞｯｸﾞのみで開発なんかしてないなんて口が裂けたら言えません｡

ﾊﾞｸﾞ曲線で残りﾊﾞｸﾞ予想件数が0.5件未満になる時期を出すと欝になるね｡

>>498
ヘタクソな奴の典型。

それ以前に仕事してると言わんよ。回りの血圧上げるためにいるようなもんだ。

Wikiみれねーぞ

>>499
ﾍﾀｸｿな奴の典型ですよ｡

>>500
仕事していませんよ｡
私の血圧下げるためにやるようなもんだ｡

>>498
ワロタ。パーセプトロンかよ。

お陰さまで最高血圧が90まで下がりました。

とりあえず、テスト困難なコードは設計がまずいことが多い。
中でも、テスト困難になりがちな副作用が多いコードは設計を見直すよう心がけている。

>>504
普段から最高血圧90付近ですが、なにか。

一日目。神懸かりモードで能力の限界に挑戦しながら書き上げる。
二日目。ゆっくり整理・リファインしつつコミット。
三日目。まったり。
最初に戻る。

>>503
ﾜﾛｰﾃつかぁさい｡ﾊﾟｰｾﾌﾟﾄﾛﾝでござい｡

>>506
低血圧ぎりぎり正常｡

ここは悪いコードを書くためのノウハウをも蓄積するｽﾚでっか？

>>510
何が悪いかを知れば、何が良いかを知ることにつながる

>>1
朝食食べるといいらしいぞ

このあとトイレに流されますか？

DHAのサプリメントを摂る

言っちゃった・・・・

>>514
正直、ブルーベリーも重要だと思う。

フラグを二回立てたくなったときの裏技
BOOL flag = TRUE * 2;

「フラグ使わんと書けないのか」
というのは煽りになるのかのぅ

同じ変数の使いまわしなんてもってのほかだし

皆さんこんにちは。
このスレは終了ですか？

今、C++で堅いプログラムを書いているのですが
コツを教えてください。

Exceptionを使わないと仮定すると、
エラー処理をしたい関数の戻り値は
処理結果ということになると思います。
そうすると、少しの処理でもコードが長くなってしまいます。
このあたりをうまいこと見やすくするコツや参考になるソース等は
ありますでしょうか？

http://n219079028097.netvigator.com/
おｋｗｗｗｗっっうぇうぇｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗ
おｋｗｗｗうぇｗｗｗｗおｋｗｗｗ
おｋｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

>>519
無い

マジですか。
そんな殺生な！

>>519
ちょっとまて。
例外を使わない場合、戻り値はエラー判定用の値になるんじゃないか？
bool DoSomething( T& result ); // こんなかんじで

もしくは、大域変数を使うか

>>519
例外が使えない場合は、gotoを使ってエラー処理を本処理から分離する事で、本処理が
エラー処理に埋もれる事を阻止する。

例えば、このコードは、、、

FILE *fp_a = fopen( "file_a", "r" );
if( fp_a == NULL ){
　return -1;
}
FILE *fp_b = fopen( "file_b", "w" );
if( fp_b == NULL ){
　return -2;
}
FILE *fp_c = fopen( "file_c", "w" );
if( fp_c == NULL ){
　return -3;
}

//ごめん間違えた
FILE *fp_a = fopen( "file_a", "r" );
if( fp_a == NULL ){
　return -1;
}
FILE *fp_b = fopen( "file_b", "w" );
if( fp_b == NULL ){
　fclose( fp_a );
　return -2;
}
FILE *fp_c = fopen( "file_c", "w" );
if( fp_c == NULL ){
　fclose( fp_a );
　fclose( fp_b );
　return -3;
}

レスありがとう。

>>523

処理結果とはそういう意味で書いたのですが
確かに紛らわしかったです。失礼しました。

例外を積極的に使うべきなのでしょうか？

>> 524

なるほど。getLastError()といった処理を毎回行うことになるのでしょうか？

//gotoを使うとこうなる。
FILE *fp_a = NULL, *fp_b = NULL, *fp_c = NULL;
int err;

fp_a = fopen( "file_a", "r" ); if( fp_a == NULL ) err = -1, goto error;
fp_b = fopen( "file_b", "w" ); if( fp_b == NULL ) err = -2, goto error;
fp_c = fopen( "file_c", "w" ); if( fp_c == NULL ) err = -3, goto error;

// 処理...

error:
if( fp_a ) fclose( fp_a );
if( fp_b ) fclose( fp_b );
if( fp_c ) fclose( fp_c );
return err;

>>528は519でした。間違えました。

>>525さん
レスありがとうございます。
大変参考になりました。

実は、例外を使わない明確な理由はないのです。
周りであまり使っている人がいなかったので、
C++ではあまり使わないのかなと思ってのことです。

どちらにしてもエラー処理は確実に行いながら
見やすくメンテしやすいものにしたいです。

goto文って結構つかうもんですか？

>>531
例外を使わない理由が無いなら、使っておけ。

>>531
周りが例外を使っていないのなら自分から推し進めていけ。

gotoはよっぽどの必要性があっても使わない。(例外などがない言語は529のように使うこともあるが)
せいぜい多重のループから一気に抜けたいとき。


でも俺はそういうときinline関数にしてreturnを使うようにする。
あくまでも俺の場合。他人がこういう場面でgoto使っても否定はしない。

> 実は、例外を使わない明確な理由はないのです。
> 周りであまり使っている人がいなかったので、
> C++ではあまり使わないのかなと思ってのことです。
……

うーむ、Exceptionの有用さくらい教科書に書いてあると思うが・・・
よっぽど特殊な環境じゃない限り、Exceptionが実装されている言語では
使え。特にライブラリっぽいものを作る段階になって階層構造ができてくると
便利。

ところで、Ｃ＋＋とかでオブジェクトを作るときに2 phases construction/destructionっていう
方法があるんですけど、どれくらい使ってる人います？

class MyClass {
public:
MyClass();
~MyClass();
bool Create();
bool Destroy();
private:
void Initialize();
int data;
// etc...
};

んでまず、コンストラクタではメンバーをイニシャライズするのみ。
Createを呼んだ時点ではじめてメモリーに何か読み込むとかの処理をする。
だからデストラクタはDestroyを呼ぶだけ。

だから、どこから来たのかわからないオブジェクトを再利用したい時は
DestroyしてからCreateすれば確実にきれいな状態からはじめられる。

ただ2段階にしただけなんだけど、これだけで結構硬い構造になると思う。

>>536
俺は忌み嫌ってるね。
Initialize() されてないという状態が無駄に存在するのが嫌。

私はまず「どこから来たのかわからないオブジェクトを再利用」するのが激しく嫌。
素直に毎回コンストラクト・デストラクトしたい。

>536って、例えばMFCもそうだけど無駄にノウハウが必要になるから却ってバグの温床になりそう。

>>536
無理せずにGCの有る処理系使えよ。

>>536
その方法を使う利点ってどんなものがあるんだろう？？
とりあえず思い付く局面としては、

「オブジェクトの生成(内部で使うオブジェクトの生成も含める)に
　時間がかかるから、生成のタイミングをずらそう」

ってところだけど。

でもこれ、全てのメソッドに Create 済みかどうかのチェックを
入れなきゃいけないからな…これについては面倒だな。
(NullObject が使えるかもしれない)

>>539
同意。

多分俺の説明の仕方が悪いんだと思うんだけど、確かにこの方法を
長年実行している知り合いは、かなりユニークなコーディングの
スタイル。でも実際一人で巨大なアプリ書いて
すごい安定してる（テストのコードもかなりの量ある）。

例えばゲーム作るときでもキーイベントをリスナーする親玉クラスをつくったとして
privateメンバーにこういうのをいれといて

SuperMario *m_mario;
FireBall *m_fire;

でファンクションで

void OnKeyboard(int key) {
if (key == SPACE) {
m_fire->Create(m_mario->GetX(), m_mario->GetY());
}
}

void OnTimer() {
if (time%100 == 0 && IsOutOfScreen(m_fire->GetX(), m_fire->GetY()){
m_fire->Destroy();
}
}

こんな感じかな？もちろんこのリスナーがDestroyされるときはすべてのメンバーを
明示的にDestroy()する。もし忘れてもデストラクタのなかで一応Destroyしてあるから
大丈夫。

俺も最初Initializeされただけの状態があるのはやだなと思ったけど、巨大な
ファイルをロードするときは、ロードするタイミングを調整しやすいからじゃないかな？
あ、541さんの指摘した通りだと思います。
つまり上の例だと、スタート画面ではまだマリオはロードされてませんという利点があるのかも。
確かにCreate済みのチェックはめんどそうですね。

Createの中でもまず最初にDestroy()を呼んでから
何かをすると言っていた。つまり、確実にメモリなどを開放してあることを保障してからオブジェクトを作ると。

コンストラクタではInitializeを呼ぶだけ、すべての
値を0とかnullに。

>>540
こないだから遊びでJ2MEを触っていますが、じつは似たような話が出てきてるんです。
つまりメモリが限られてるので、明示的にDisposeというメソッドをつけて、
メンバーにnullを割り当てろ、と。つまりＧＣに教えてやることでゴミ掃除を早める
という話でした。ほんとかな。多分、SWTとかも明示的にメモリ開放（ＧＣを呼ぶ）
することでＧＵＩの処理を早めてるんじゃないのかな。想像だけど。

上の例なぜかポインタにしちゃったけど普通に作成するの間違いです
FireBall m_fire;
//...
m_fire.Create();

という風になると思います。

遅延初期化はよく使われる手法だよ。（再利用はあんまりないけどな）
どんなオブジェクトもさまざまな状態があって、当然初期状態では実行できないメソッドがあっても良い。
人間だって生まれたすぐには生殖できないし、年をとれば生殖能力を失う。
段階的にオブジェクトを構築し、最終的に完全なオブジェクトになり、いつしか不完全になり、破棄される。

不完全な状態はできるだけ外に出ないほうが望ましいけど、なければいけないこともある。

このスレらしくなって参りました

>>542
普通にポインタでいいじゃないか。
std::auto_ptr<FileBall> m_fire;
m_fire.reset(new FireBall(m_mario.GetX(), m_mario.GetY()));
m_fire.reset();

>>543
> つまり上の例だと、スタート画面ではまだマリオはロードされてませんという利点があるのかも。
マリオがロードされて無いくてもいいスタート画面で、
SuperMario のインスタンスが（不完全な状態で）存在する意味は無いんじゃないか？

今のところ、やっぱりいいとこ無しだな。

方法を利用する理由は異なるかもしれないのですが、
2 phases construction/destruction
（って呼ばれていたんですね。知りませんでした。）
的な方法を実際に使用したことがあります。

MyClass* p = new MyClass[size]; とすると、
デフォルトのコンストラクタしか呼ばれません。
そこで、>>536 のCreateメソッドをいくつかオーバーロードしておいて、
MyClass* p = new MyClass[size]; とした後に、
Createメソッドをコールしてました。

当初は、ポインタの配列を動的に確保した後にnewを繰り返していたのですが、
大量にオブジェクトを生成することが要求されるようになるにつれて、
メモリの管理領域のオーバヘッドが軽視できないほど大きくなってしまったので、
（特化したアロケータを作成するスキルも当初は無く、）
苦肉の策として導入していました。

俺は
do{
...
} while(expression);
は
for(;expression;)
{
...
}
と書くけど、どう？

>>549
一回は突入することが判っている場合、
突入してからでないとexpressionが確定できない場合、
私はdo - whileを使う。

>>549
動作が変わってるぞ。気をつけろ。
for(;exp;){} は while(exp) {} の改悪にしか思えん。

>>549
#include <stdio.h>

int main(int argc, char *argv[])
{
int i;

i=3;
for(; i<3; ){ printf("A. %d\n", i); i++; }
i=3;
while(i<3){ printf("B. %d\n", i); i++; }
i=3;
do
{
printf("C. %d\n", i);
i++;
}while(i<3);

return 0;
}

=>
C. 3

組み込みなど、容量とサイズに制約がある場合、
効率の良いプログラムを書くには、どのような点に注意するべきでしょうか？

書かないこと

>>553
容量とサイズではなく、容量／サイズと速度だろ。
言語も記述せずにその質問に答えろと？
アセンブリコードに落ちたときどうなるかを理解できる様になれば
その質問には自分で答えられるようになる

２フェーズコンストラクションというと、SymbianOSのC/C++ライブラリが使っていたな。
あれは >>536 のようなものではなくて、よくは憶えていないけど、確かコンストラクタ
で例外ジャンプをする弊害(?)対策だったような。

ごめんなさい；；
組み込みなど、容量と時間に制約がある場合、
効率の良いプログラムを書くには、どのような点に注意するべきでしょうか？
C言語です。

>>557
時間 : メモリアロケーションを頻繁に行わない。
容量 : コンテキストで必要なときだけ変数用のメモリをとる。

両者は背反する。

自前のカスタムアロケータを使う

で両者はそれなりに満たされるんじゃないの？

いや、それは本質的には何も変わっていない。

まぁ、妥協して適当なものにするってのはそのとおりだが、
妥協が必要なのは背反しているゆえなわけで。

そういう曖昧論はつまらん

>>557

　参考になりそうな書籍としては、以下のようなものがあるようです。↓
http://www.amazon.co.jp/exec/obidos/ASIN/4873110130/
http://www.amazon.co.jp/exec/obidos/ASIN/4894714086/

日本の、携帯機器や家電製品の開発現場にも、ノウハウの蓄積が
ありそうです。

メモリキツキツの環境では基本的にmallocは使わない

>>515
知ってるか、結局アントシアニンが効果あるので、
赤シソだとかカシスでも良いわけ。
カシスのほうが効率的に摂取できるんだぜ。

うえっｗｗｗｗｗｗｗ
低脳発言スレと間違えたｗｗｗｗｗｗｗ

>組み込みなど、容量と時間に制約がある場合、効率の良いプログラムを書くには、

効率って何?
開発時間?
実行時間?
メモリ使用量?

>>548
裏読みとかに対応させる為に俺はそうしてる。
メンバの初期値とかはなるべく定義に埋め込む。