トップページ⇒tech
567コメント189KB

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

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさんNGNG
良いコードを書きたいです。でも、書けないです。
良いコードを読めばよいと聞きますが、どれがよいコードなのか分かりません。
長くないけど、良いコードと悪いコードを比較して、わかり易く教えてください。
デザインパターン適用するといいと聞きますが、どれだけいいのか分かりません。
異常処理書くと汚くなってしまいます。
例外処理はtry{}catch(Exception e){}としてしまいます。
言語や環境、職場によって良いとされる書き方は変わります。
例えば、携帯Javaは容量を少なくするコードが良くなります。
スピードを徹底的に重視すれば、オブジェクト指向は邪魔なだけです。
関数型言語では、再帰呼び出しを使うのが上等です。
コードリーディングとか、達人プログラマーとか、
本買って読むといいらしいけど、お金ないし、
買いに行くのめんどくさいし、ウェブで見たいです。
そういうサイトつくりたいけど、頭悪くて作れません。
てことで、まとめWiki作って、勝手に書き込んで欲しいです。
トヨタ式的なものがソフトウェア産業でできてないと言うし悔しいです。
てことで、良いプログラムを書くためのやり方、良いソースの書き方を議論して、
最強のソフトウェア開発方法をまとめてください。
0002１００１NGNG
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
00031NGNG
とりあえず、wiki立てたいので、いいWikiと、いいサイトと、いい名前、教えてください。
0004一星 ◆Cppn/.YI3. NGNG
教えてほしいだけなら質問ｽﾚで質問してくれよ。
0005デフォルトの名無しさんNGNG
打鍵百回おのずから通づる。打つべし打つべし。
00061NGNG
教えて欲しいだけじゃなくて、まとめたいと思っています。
書き方が悪かったですかね？
一人で考えたことではなくて、いろいろな人が考えたことを、
まとめたものがないので、作りたいということなのですが。
作ったので、使ってくれって宣伝するのも嫌だし、、、。
もしそういったサイトがあったのなら、削除依頼出してきます。
00071NGNG
綺麗なソースを書くノウハウを書いてあるサイト
言語ごとに教えてください。
C,C++,Java,VB,Perl,Ruby,Scheme,
あんまし、無いと思うのだけど。

とりあえず、ググったら、こんな掲示板があったので、情報まとめてみます。
http://jibun.atmarkit.co.jp/scenter/bbs/viewtopic.php?mode=viewtopic&topic=10614&forum=21&start=0
0008デフォルトの名無しさんNGNG
キーボードに向かう前にチンコをいじって心を落ち着かせるべし。
0009デフォルトの名無しさんNGNG
【すれ立てるまでもない質問はここで 第6２刷】
http://pc5.2ch.net/test/read.cgi/tech/1100963189/
0010デフォルトの名無しさんNGNG
コーディング規約はこのへんがまとまってるんじゃないか？

http://www.objectclub.jp/community/codingstandard/
0011デフォルトの名無しさんNGNG
>>10
iine
00121NGNG
http://www.hondarer-soft.com/cx/pukiwiki/pukiwiki.php?Link%2FProgram#content_1_17

ここもまとまってました。
0013デフォルトの名無しさんNGNG
この↓本では力不足ですか？

センス・オブ・プログラミング!―抽象的に考えること・データ構造を理解すること
http://www.amazon.co.jp/exec/obidos/ASIN/4774121738/qid=1102247391/sr=1-1/ref=sr_1_10_1/249-2545910-7109969
0014デフォルトの名無しさんNGNG
バグが無いのはもちろんのこと、
堅牢性、保守性、拡張性、可読性、etc.
を備えたものが良いコード。
見栄えは個人の好みもあるから、あまりうるさく言うな。
0015デフォルトの名無しさんNGNG
とりあえず>>1の「良いコード」の定義を教えてくれ
0016デフォルトの名無しさんNGNG
>>15
それを考えていきたい。
0017デフォルトの名無しさんNGNG
>>1
なんかたたき台にするサンプルコードあげろよ。
短いのでもいいからさ。
具体的なコードがあった方が話が早い。
0018デフォルトの名無しさんNGNG
実際には、悪いコードを書く奴を排除するノウハウの方が重要なのだが。
0019デフォルトの名無しさんNGNG
>>18
例えば13あたりがその対象じゃないか？
URLが
http://www.amazon.co.jp/exec/obidos/ASIN/4774121738/
までで十分だから。
0020デフォルトの名無しさんNGNG
18がうまいこと言った。
00211NGNG
たたき台サンプルコード
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文はこうだとか条件によってかわると、もう全部あわせるのは不可能
00221NGNG
たたき台サンプルコード
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文はこうだとか条件によってかわると、もう全部あわせるのは不可能
00231NGNG
うわ、失敗

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

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

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

http://f55.aaa.livedoor.jp/~goodcode/index.php
0026デフォルトの名無しさんNGNG
>>21
おれがスペースを入れるのは
1. カンマ','のあと
2. if while forのかっこの左右
3. 2項演算子の左右
0027デフォルトの名無しさんNGNG
>>25
がんばってますね。応援age
00281NGNG
>>25
応援どうもです。
なんでもいいんでwikiに書き込んでください
0029デフォルトの名無しさんNGNG
おいしいラーメンの作り方を書いてもいいですか？
00301NGNG
>>29
それは、、、
訂正
いい方向性に向かうように、好きに書き込んでください。
0031デフォルトの名無しさんNGNG
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
0032デフォルトの名無しさんNGNG
良いコードを書くためのノウハウその1。
括弧の位置とかインデントとかそんなレベルにこだわらないこと。
0033デフォルトの名無しさんNGNG

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

0034デフォルトの名無しさんNGNG
>>33
Q3　あげまんという言葉は、いやらしい事だと思っていた。
（実は今もそう思っていた）

YES

NO

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



あげまんってあげまんこの略だよな？ﾏｼﾞﾃﾞﾏｼﾞﾃﾞ
0035デフォルトの名無しさんNGNG
動くコードが書けない僕でも、良いコードは書けますか
00361NGNG
頭悪いので、TexのWikiからのコピペを修正したものを張りました。
Wikiそのままのコピペで本をだすことはしないと約束します。
0037デフォルトの名無しさんNGNG
スペースかっこ、著作権、Wikiとか
話がどんどん本題からずれていくのがおもしろい。
0038デフォルトの名無しさんNGNG
インデントはタブがいいの？
それともスペース？
00391NGNG
Wiki書き換えてくれた人がいた。
ありがとうございます。

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

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

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

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

VC++だったりEclipseだったりすると、タブ幅は４文字、インデント４文字がいいのだと思う。
JBuilder、GNU Emacsとかの場合、タブ幅は８文字、インデントは２文字がいいのだと思う。
0041デフォルトの名無しさんNGNG
>>22
どうでもいいけど、何で f の次が g になってるの？
10に訂正してくれ。

俺は、
for(i; i<10; i++)
{
printf("%d", i);
}
こんな感じかな。
printf()の前は、タブスペース空けてる。
ってか、VC++が勝手にやってくれるからだけどね。
004241NGNG
うわっ。
半角スペース連続投稿で消された・・・・・
逝ってくる。
0043デフォルトの名無しさんNGNG
消されたわけではないが。
0044デフォルトの名無しさんNGNG
a(ONE, ONE);
0045デフォルトの名無しさんNGNG
>>1
哲学的になりますが、
そもそも「情報」って何だろう？
「情報技術」って何だろう？
といった問題を日頃から深く考えるのも大事だと思います。
より良いソースコードが書けることと、
情報という概念について自分なりの哲学を持っていることって
かなり密接な関係があると個人的に思っているので。
さすがに、言いすぎかもしれませんが。

ただ、少なくとも言えることは、
より良いコードを書くための断片的な知識をひたすら覚えていくだけでは、
絶対にプログラミングは上達しないと思いますよー。
数学の定理や公式や解法をいくら暗記したところで
数学が出来るようにはならないのと同じです。
004645NGNG
ただ否定するだけだとさすがにアレなので、
コーディング技術を上達させるための有効な手段の一つを紹介します。
というのは、正しい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が書けることはまた別ですねー
0047デフォルトの名無しさんNGNG
時間だよ。とにかく時間。
時間さえあれば並みのプログラマでもマシなものが書ける。
時間が無ければ凄腕プログラマでもHACKせざるを得ない。
余裕が無いが短すぎもしない期間で寄り道せずに最適解を導けるような知恵袋はあってもいいかもな。

スペースの位置とかインデントとか、どうでも良い問題にこだわる1は一番このスレにふさわしくないと思う。
そんなものは同じ関数内ですら統一されている必要なんか無い。
その程度で読みづらいと感じるようなやつはこの業界から早々に去れ。
0048デフォルトの名無しさんNGNG
>>46
そんなのW3C勧告読めばいいだけの話じゃん。
良いコードを書く能力というよりかCで未定義じゃないコードを書く能力に近いというか・・。
最低限レベル？
004945NGNG
>>48
確かにW3Cの仕様を読めば、文法的に正しいHTMLを書けるようには
なれると思います。
ただし、重要なのは文法が正しいことではなく、
その表現が妥当かどうか(分かりやすいかどうか)、ということです。

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

スレ違いなレスでごめんなさい
0050デフォルトの名無しさんNGNG
結局は文脈を読み取れる国語力が必要って事？
0051デフォルトの名無しさんNGNG
いまどきあんな時代遅れのHTMLを意味に合わせて使うなんてナンセンスだよ。
UAが正しく理解できればそれで十分。
俺は文章の論理構造はXMLで書いて、XSLTで変換してる。
変換した先がどうなってようが（それでも一応validだけど）知ったこっちゃ無い。
0052デフォルトの名無しさんNGNG
>>45
自分なりの哲学なんて邪魔なだけだ。
まずは自分を捨てるところから始めろ。
0053デフォルトの名無しさんNGNG
Eclipseのコードフォーマッタって便利なんだけど他人のソースでうっかりCtrl+Shift+FしちゃうとCVSが悲惨なことになるんだよなぁ。
コード横幅120文字に設定してるのが悪いのか・・・デフォルト80だしなぁ・・・。
自分を捨てることは必要かもしれん。
でも最近の高解像度ディスプレイで80文字は無いよなぁ・・・。
0054デフォルトの名無しさんNGNG
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
0055デフォルトの名無しさんNGNG
どうせ書くならwikiに書き込めよ。このチキン野郎
0056デフォルトの名無しさんNGNG
>>40
＞HTMLで記述する場合はタブ幅を指定できない。８文字に固定される。

<pre>では、タブは使わないのが推奨されてなかった?
0057デフォルトの名無しさんNGNG
興味アル方メールください

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


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


勤務地
東京都渋谷区
0058デフォルトの名無しさんNGNG
ここで募集しても糞しか集まらないよ
00591NGNG
>>54
情報サンキューです。
Wikiに反映しときます。
>>55
Wiki重かったりするし書き方分からないのかもしれないし情報いただけるだけで助かります。
てか、55がWikiに書き込んで欲しかった。
00601NGNG
>>40
そうですね。IEだと文字のサイズ変えても固定ですしね。

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

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

インデントうんぬんで文句言う奴がいたら、自動整形機能使って渡せば議論しなくてすむし。
00611NGNG
Javaアプレットで自前アルゴリズムで3D描画するプログラム
http://homepage1.nifty.com/open-prog/
http://homepage1.nifty.com/open-prog/java/index.html
ここのコードは綺麗でよいと思ったなぁ。
0062デフォルトの名無しさんNGNG
>>60
Python はインデント変えると動かなくなるんだよ
0063デフォルトの名無しさんNGNG
>>61
おれもプログラミングを始めたころに読んだけど、読みやすかった。
0064デフォルトの名無しさんNGNG
>>47さんに賛成です。

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

0065デフォルトの名無しさんNGNG
http://pc5.2ch.net/test/read.cgi/tech/1044457085/
0066デフォルトの名無しさんNGNG
>良いコードを書くためのノウハウ

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

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

コーディング規約のようなものは、読むソフトごとに様々で、
統一さえされていればよいのではと思いました。
0067デフォルトの名無しさんNGNG
　達人のソースコード読んだあと、ふと、自分の書いた
コードに目をやると、なんでこんなにごちゃごちゃしてるんやろ、と思う。

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

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

がんばろ。
0068デフォルトの名無しさんNGNG
　とはいっても、良いとはいかずとも、バグを見つけ出し
やすいコードを書くノウハウはあると思います。

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

C言語が使えるところなら、どこでも使えるというのもよいです。
0069デフォルトの名無しさんNGNG
Effective C++ とか読むといいとおもう
今更だけどEffectiv C も書いてほしいなあ…
0070デフォルトの名無しさんNGNG
Effective〜っていうプログラミング指南書は全然役に立たない俗本。
0071デフォルトの名無しさんNGNG
>>70
Effectiveってつく本を何冊読んだのか知りたい。
0072デフォルトの名無しさんNGNG
>>70
少なくともEffective C++は読んだんだろうな？
0073デフォルトの名無しさんNGNG
「関数内関数」使っちゃったｗ
int func () {
　struct local {
　　static int func() { return 0; }
　};
　return local::func();
}

コードレビューの時にどんなツッコミが来るか、ドキドキだｗｗうはｗｗおｋｗｗｗ
0074デフォルトの名無しさんNGNG
>>72
当然でしょ。
Effectiveのつく代表的な著作じゃない。
0075デフォルトの名無しさんNGNG
>>74
それを「全然役に立たない」と断じる根拠を知りたい。
0076デフォルトの名無しさんNGNG
>>75
全然役に立たないというのは言いすぎだったかもしれないけれど、プログラミング
してきて、ある程度の経験値を持っている人なら、書いてある内容に同感する部分
もあるだろうけれど、読んでいて、「やっぱり、そうだよねー」っていう感じで
世間話をしている感覚。
当然、(Mayersに対して)「う〜ん、そこまでしなくても…」と思うこともあれば、「あ、それはいいね」と思うこともある。
でも、まぁ、大体は、自分のスタイルに従うからあくまで世間話だね。
0077デフォルトの名無しさんNGNG
>>76
まぁ、エキスパートの人にはそうかもしれないが、CからC++に
移行してきて文法に振り回されてる人には、お勧めできるガイド
ラインだと思うんだけどなぁ。要は対象読者による、でしょ。

対象読者が誰であれ、お勧めできない本は他にいっぱいある気がする…。
ちょっと話ずれてｽﾏｿ
0078デフォルトの名無しさんNGNG
>>76
対称読者を間違えてる。
本来経験から得る知識を金払うだけで得れるんだからすばらしいじゃないか
0079デフォルトの名無しさんNGNG
>>77
そのあたりのことは全部見越して、>>70の発言なんじゃないか。
ようは、なんの脈絡もなく、「おれはすごい」って自慢できるきっかけを見付けたから
それに食いついただけでしょ。
0080デフォルトの名無しさんNGNG
できるだけコード量が少なくなるようにして、
メソッドの数をできるだけ少なくして
クラスはできるだけ作らないようにして
シンプル命でリファクタリングしつづけるだけ。

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

それでいいじゃん
0082マイク ◆yrBrqfF1Ew NGNG
まあ2chに入り浸るようなのじゃいくらノウハウを蓄積したところで
変わりはしないんだがな。
0083デフォルトの名無しさんNGNG
>>66
思っていたよりもってゆーか、関数は長くても一画面に収まる程度が望ましいんだけどね。
大半は数行から十数行程度で。
短い関数＝良いコードといっても過言ではないくらい重要だね。
現実的には手を抜いてしまいがちだけど。
C++だとprivateな関数増やすだけでヘッダの書き換えが必要になるから、なかなか厳しい。

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

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

これを反面教師にして、逆のコードを書けばちっとはマシになるだろ。
0084デフォルトの名無しさんNGNG
関数とメソッドってどう違うの
クラスのメンバ関数=メソッドでOK?
0085デフォルトの名無しさんNGNG
>>79
ひねくれているなぁ。
0086デフォルトの名無しさんNGNG
>>83
> 思っていたよりもってゆーか、関数は長くても一画面に収まる程度が望ましいんだけどね。
ここで言う一画面とはどの程度を指すんですか？
Unixターミナルのように80x24=1画面を基準とする？それともSXGAでEclipse標準フォントを使った
場合の約120x50を基準とする？
0087デフォルトの名無しさんNGNG
別に、メソッドは短くする意味がなければ長いままのほうがいいよ。
なんでもかんでも短ければいいっていうもんじゃない。メソッド増えるのキモいし。
長いメソッドのときは、まとまった処理ごとに適切なコメント入れればいいと思うね。
メソッドを定義したのと同じ表現力が得られる。
0088デフォルトの名無しさんNGNG
>>87
そのコメントをメソッド名にして切り出すべきだと思うんだけどね
0089デフォルトの名無しさんNGNG
>まとまった処理ごとに適切なコメント入れればいいと思う

もはや説明が必要な時点でNGだろw
0090デフォルトの名無しさんNGNG
一つのメソッドは30秒以内に理解できるものでないといけない
0091デフォルトの名無しさんNGNG
>>90
読む奴が無能ではどうしようも無い
0092デフォルトの名無しさんNGNG
>>88

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

一つのメソッドからしか呼ばれないメソッドってアフォでしょ。定義する価値なし。
0093デフォルトの名無しさんNGNG
>一つのメソッドからしか呼ばれないメソッド

長いメソッドをそんな風にしか分割できない時点でNGだろw
0094デフォルトの名無しさんNGNG
>>92
構造化プログラミングを勉強しなおせ。もしくはCOBOLでも使ってろ。
0095デフォルトの名無しさんNGNG
メソッドを無理やり短くするほうがいかんと思うけどね
短くなって複雑になるくらいなら長いままにしておいたほうがマシ
いい方法が見つかった時に短くする。
0096デフォルトの名無しさんNGNG
複数の条件判定の上で処理する場合、出来るだけネストを深くしないように
ループの場合は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;

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

どうせならループの場合も関数に切り出したほうがいいかとも思うんですが、結局
エラー・例外処理が絡んできて値を返し、呼び出し元で分岐させなければならなく
なるのでそこまではやってません。
0097デフォルトの名無しさんNGNG
短くして複雑になるのは短くするやつが低脳なだけだろ
0098デフォルトの名無しさんNGNG
条件を適当に付け加えたので括弧を入れ忘れました
-    if (!(hoge.expr2 == "hogestr")
+    if (!(hoge.expr2 == "hogestr"))
0099デフォルトの名無しさんNGNG
>>96
脊髄反射でレス
コメントが必要だと思ったらその時点で駄目なコードだと思え。
0100デフォルトの名無しさんNGNG
>>99
そりゃ言いすぎだ。趣味でやってるなら許すが。
0101デフォルトの名無しさんNGNG
>>99
そういう通念をヘタに浸透させると、ダメなコードでもコメント入れない奴が
量産されるから、公の場では言わないように。
0102デフォルトの名無しさんNGNG
>>99
いやー、実際のところコメントなんて無くても読めると思うんですよ。
しかし読む側にすると自然言語によるコメントが付いているとありがたい。
英語の読み書きは出来るけれど、やはり日本語ドキュメントを読むほうが
楽だというのと同じことじゃありませんか？結局は読む側の時間節約の
ためにコメントを付けるものでは？自然言語で解説を添えておくことは
後々自分の保守作業の助けにもなると思いますが。
0103デフォルトの名無しさんNGNG
-for (SmplCls hoge in arg) {
+foreach (SmplCls hoge in arg) {

書いてる時から何かおかしいと思ってたんだorz
0104デフォルトの名無しさんNGNG
時間がたつにつれてコメントと実コードの間にずれが生じてくる。
コメントは間違っててもテストに引っかからないしエラーにもならないからね。

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

もし入れるならなら

/* expr1がfalseの場合、XXXなのでふるい落とす */
if (!hoge.expr1)
continue;
くらいしてくれ。
プログラミング言語はWHATは記述できるけどWHYは記述できない、WHYの部分をコメントにすべき。
0105デフォルトの名無しさんNGNG
ネスト回避にcontinueやreturnでふるい落とすのは良いスタイルなのかというのを
聞きたかったんですが・・・。

ともかく、>>104アドバイスありがとうございます。CVSのコミットログにはwhat i didではなく
why i did itを書け、というのと同じですね。
0106デフォルトの名無しさんNGNG
>>105
頭の方で条件に合致しない場合はreturnで落とすスタイルは広く使用されてる。
名前も付いてるけど忘れた。
0107デフォルトの名無しさんNGNG
いつもコメントの書き方にこまるです。
自分、強迫神経症的な部分があるから、
とことん書かないと気がすまない。

コメント書く際の標準とかってある？
0108デフォルトの名無しさんNGNG
>>107
標準はないけれど、JavaDoc風に書くとわりと幸せになれるかも。
例えば、DoxygenだとJavaDoc風の書き方に対応しているからソースのコメントを元に
ドキュメントが生成できたりします。
0109107NGNG
あーなるほど、そういえばPerlにはPodだっけ？なんて書き方がありますな。
（ソースのコメントを元にドキュメント生成できる）

ところで、PHPにはそういうのはないんでしょか？
0110デフォルトの名無しさんNGNG
Doxygen
0111デフォルトの名無しさんNGNG
RD
0112デフォルトの名無しさんNGNG
>>109
PEAR は PHPDoc を使うことが義務付けられている。
Doxygen も PHP に対応しているし。
0113デフォルトの名無しさんNGNG
>>96
そういうやり方を嫌う人は多いな。
聞いてみると、仕様をそのままコードに落とした方が分かりやすい
ということらしい。
ネストが深くなるのを嫌って関数の頭でふるいにかける形でコード書いたら
SEから「俺が書いた仕様と違う」と拒否されたこともある。
0114デフォルトの名無しさんNGNG
>SEから「俺が書いた仕様と違う」

ｱﾌｫです
直訳と意訳は違うんでつ
0115デフォルトの名無しさんNGNG
アホだな
0116デフォルトの名無しさんNGNG
正しく動くコード
正しいコード
良いコード
これらは全て違う
0117デフォルトの名無しさんNGNG
良いコードを書くためには少しの酒と旨いつまみが必要だ
0118デフォルトの名無しさんNGNG
>>113
コードレベルのフローチャートみたいなのが、仕様書に含まれてるところなのだろうか。
0119デフォルトの名無しさんNGNG
良いコード…、俺がコーディングしなきゃOK。
0120デフォルトの名無しさんNGNG
コメントって>>96みたいな「何をしているのか」を書くものなのかな？
私は「何をしたいのか」をコメントとして書いてるけど・・・。
他の方々はどーしてます？
0121デフォルトの名無しさんNGNG
>>120
「何をしたいのか」を書く方がいい。
0122デフォルトの名無しさんNGNG
なぜこの方法を採用したのか、他の方法ではどうダメなのかをコメントで切々と説く。
0123デフォルトの名無しさんNGNG
したいこととその方法を書く。
0124デフォルトの名無しさんNGNG
phpのソース上キレイにかくか、
outputのhtmlをキレイにかくか、
で迷う
0125デフォルトの名無しさんNGNG
>124
phpをきれいに書いたほうが後々自分が楽。
0126124NGNG
>>125

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

できれば両方キレイにしたほうがいいんだろうが・・・そんなヒマはない
0127デフォルトの名無しさんNGNG
普通デザイン部分のhtmlは別ファイルにするだろ？
0128デフォルトの名無しさんNGNG
php使うならxmlつかったほうがいい
0129デフォルトの名無しさんNGNG
良いコードを書くのにノウハウなんていらね。
たった一つの事を守れば良い。
0130デフォルトの名無しさんNGNG
そのたった一つの事とは、、、。
0131デフォルトの名無しさんNGNG

========================
ここで一旦コマーシャル。
========================
0132デフォルトの名無しさんNGNG
>>129-130
Cを高級アセンブラだと思わないこと。
特にアセンブラから入った人間。
0133デフォルトの名無しさんNGNG
どう違う？浮動小数点演算をターゲットに応じて展開(レジスタ割付とか)してくれるぐらいしか思い浮かばんが
0134デフォルトの名無しさんNGNG
あ、レジスタ割付は本質から外れるな。浮動小数点演算をどのように扱うか、という
面倒を見てくれることか
0135デフォルトの名無しさんNGNG
たった一つの冴えたやり方
0136デフォルトの名無しさんNGNG
意味を明確にしたコーディングをする、ということが大事だと思います。

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

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

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

すごく極端な例になってしまいましたが。
0137デフォルトの名無しさんNGNG
>>130
馬鹿はコードを書かない。
0138デフォルトの名無しさんNGNG
>>136
コメント一行書けばしまいじゃん。
0139デフォルトの名無しさんNGNG
>>136
日付時刻クラスでも作ったほうがいい。
0140デフォルトの名無しさんNGNG
>>139
日付・時刻クラスをつくるってことは
後者にあたるんじゃないかい？

日付時刻クラスの中では年、月、日、時刻はメンバとして持ってるだろうし。
0141デフォルトの名無しさんNGNG
>>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
);
0142デフォルトの名無しさんNGNG
へ〜、sscanfってそういう使い方できるんだ。メモメモ。
0143デフォルトの名無しさんNGNG
俺は前者だな。
前者の方が短くて速くて分かりやすい。
後者は冗長でかえって何がしたいのかわからなくなる危険がある。
0144デフォルトの名無しさんNGNG
>>136
使う側からすれば、どうでもいい話。
0145デフォルトの名無しさんNGNG
>>136
2005-1-1 00:00
になったらバグが出ないか？

あと、フォーマット固定な後者の方が
パフォーマンス的にも有利だと思うんだけど。
0146デフォルトの名無しさんNGNG
前者はデータの性質を利用した（あるいは依存した）トリッキーな実装って
意味のただの例だろ。細部に突っ込んでも意味ないだろ。
0147デフォルトの名無しさんNGNG
後者もデータ形式に依存しまくりだろ
0148デフォルトの名無しさんNGNG
個人的には後者のほうが嬉しい
時刻とか誰もが共通の知識を持ってるものは別に良いけど、
専門的な分野の話になるとトリッキーなことされると理解に困る
コメントついてるものもあるけど、
変更とか拡張とか入るとコメントはうさんくさくなっちゃうし…
いっそコメントいらんから分かりやすいコード書いてくれって思う
0149デフォルトの名無しさんNGNG
後者って、Cで書いちゃうと
date[4] = date[7] = '/';
なんだよな。
0150デフォルトの名無しさんNGNG
>1〜4文字目を『年』、
>6〜7文字目を『月』、
>9〜10文字目を『日』、
>12〜16文字目を『時刻』とする。

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

>145も書いているが
2004-1-2 23:45
とかにならないのか？
0151デフォルトの名無しさんNGNG
>>147
文字列の後半に'-'が含まれないって非本質的な性質を利用したって意味だよ。
0152デフォルトの名無しさんNGNG
>>150
例題なんだから、その辺の仕様の善し悪しは置いといていいんじゃない？
要は分かりやすいコードと短いコードではどっちがいいか？
という話だと思うんだけど…
0153デフォルトの名無しさんNGNG
だいたい、長いコードは分かり難い。
0154デフォルトの名無しさんNGNG
例が悪すぎというのに尽きる。関数だというんだから>>136の前者でいい。そもそも
文字列操作を日付形式変換という意味のある操作に転換するために関数に抽出するんだし。

もっと別の例をきぼんぬ。
0155デフォルトの名無しさんNGNG
>>151
どこにどの区切り文字が入っているかは書式化された日付においてはきわめて本質的な性質だけど？
0156デフォルトの名無しさんNGNG
アホばっか
0157デフォルトの名無しさんNGNG
たかが文字列の変換によくもまあこんなに沢山レスがつくもんだｗ
いままで同様な処理を書いたかなんぞ憶えていないが、全部、前者だ。
前者が気に入らないのなら、関数ごと差しかえれば良いだけの話だろ。
なんでこんなつまらんことで話が盛り上がるかが理解し難い
0158デフォルトの名無しさんNGNG
そのための2chです。
0159デフォルトの名無しさんNGNG
現実じゃなくて理想の話だからな
現実的な解決方法は求めてないだろう
0160デフォルトの名無しさんNGNG
>例えば "2004-12-20 00:30" という形式の文字列
>(データベースの時間データによくある書式)を引数にとり、
>"2004/12/20 00:30" という文字列に変換する関数を作るとします。

そんな ad hoc な関数は作らないように設計する、
というのが正解だと思う。
0161デフォルトの名無しさんNGNG
なぜDBの時間データを文字列形式で取ってくるのかという問題
0162136NGNG
>>136なのですけど。。。
反応多くてびっくりです。

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

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

こういった変更が、どれだけ容易に、確実に出来るかどうか。
前者は、関数をまるまる作り直さなきゃいけないのでコストがかかるけど
後者の関数は、情報の「意味」に着目しているから、
変更しやすいし、ミスも起きにくい。
というわけで、「意味を明確にしたコーディングが大事だ」と
考えている次第です。
0163デフォルトの名無しさんNGNG
それだったら
「"04/12/22 04:00" という形式ではなく、
"2004年12月22日 04:00" という形式にしてくれ」
とかもありえる

この場合前者なら修正不要ですが
0164デフォルトの名無しさんNGNG
＞一つの尺度に、「リファクタリングに耐えうるかどうか」
＞というのがあると思います

から

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

という流れがどうもふにおちん。
0165デフォルトの名無しさんNGNG
>>162
つか、まるまる作り直しでいいじゃん。
下手に既存のものに付け足してしのごうとすると汚くなりがちだし、
バグの温床にもなる。
0166デフォルトの名無しさんNGNG
仕様が変わっちゃうと、それはもうリファクタリングじゃない。。
0167デフォルトの名無しさんNGNG
>>162
>前者は、関数をまるまる作り直さなきゃいけないのでコストがかかるけど
>後者の関数は、情報の「意味」に着目しているから、
>変更しやすいし、ミスも起きにくい。
全然そのようには思わんが。
後者は「仕様に実装が密着しすぎ」だ
0168デフォルトの名無しさんNGNG
例が極端すぎたね。
0169デフォルトの名無しさんNGNG
>>167
>>113 世の中にはこういう人も居る
0170デフォルトの名無しさんNGNG
作ってる本人はわかりやすくても
他の人には迷惑なだけかもね
0171デフォルトの名無しさんNGNG
>>167
前者の方が仕様に密着してると思うが。

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

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

2004 が年で、12が月で、20が日で・・以下略
ってのは、後者のコードを書いたやつが仕様を勝手にそう解釈してるに過ぎない。
0172デフォルトの名無しさんNGNG
マクロならば
#define GSUB( str, s, d ) { int i; for( i = 0; i<=strlen( str ); i++) if( str[i] ==s ) str[i]=d; }
かな。・・・もう止めない？。この程度の処理に・・・。
俺は136のレベルが低すぎるだけだと思うのだけど
0173デフォルトの名無しさんNGNG
>>172
おいおい、毎回strlen()するなよ。
0174デフォルトの名無しさんNGNG
レベルが低いのは172ということで決着しました
0175172NGNG
>>173
ぉぉ。確かに。でもこの程度の事はｷﾆｼﾅｲｗ
別変数を用意しなきゃならないし、ここがボトルネックになるはずはないからな。
・・・まあこういうところまで気にしなければならない開発が存在することを否定するわけではないけど。

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

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

この例自体、「情報の意味を明確にしたコーディング」というのを説明するために
出しただけなので、別の説明のしかたもあったかもしれません。
0177136NGNG
>>176
誤: "yyyy-mm-dd hh:dd"という書式にするのが最終目標なのではなく、
正: "yyyy/mm/dd hh:dd"という書式にするのが最終目標なのではなく、

すみません(_ _)
0178デフォルトの名無しさんNGNG
C++だとlambdaを使うか、lambdaを使わないかってこった。
lambdaはごくごく単純な式なら役に立つことも全く無いとは言えないが、
どうせじきに式が複雑になってインラインじゃとても読めた代物じゃなくなるんだから
はじめからファンクタか関数にしとけってこと。
0179デフォルトの名無しさんNGNG
>>178
C++にlambda式はありません。
0180デフォルトの名無しさんNGNG
エラー処理を始めとする例外処理は、最初からまじめに書いとけ。
あとになって「こんなエラーがあるんだけど」と言われても、対処できん。
0181デフォルトの名無しさんNGNG
>>179
boost::lambda、あるいはそれっぽい実装のこと指してんだろ
0182デフォルトの名無しさんNGNG
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 使えばいいのに(；´Д`)
0183デフォルトの名無しさんNGNG
>>182
俺だったらそれ以前にtypedef enum {EFalse, ETrue} TBool;とするだろうな。
0184デフォルトの名無しさんNGNG
Eって、もしかしてEnumのE？
アホ？
0185デフォルトの名無しさんNGNG
intとの暗黙の変換を嫌ったんじゃないの。
超厳格なプログラムを書くならありはありなんじゃないの。
0186デフォルトの名無しさんNGNG
日付についてはデータフロー中では日付型のまま扱い、プレゼンテーション層
に入ってから文字列変換するのが普通だろうな。
ビジネスロジック中でわざわざ文字列化する意義が在るとは思えんし。
0187デフォルトの名無しさんNGNG
>>186
新しいプログラムのために、既存のシステムのコードを変えるのもなぁ。
0188デフォルトの名無しさんNGNG
>>187
日付を文字列で引き回すような糞コードなら捨ててしまえ。
0189デフォルトの名無しさんNGNG
>>188
内部でどう処理してるかは知らんけど、外部に日付型なデータを提供してない場合は多いし。
0190デフォルトの名無しさんNGNG
日本が戦争に勝って
西暦が使われなかったら
やっぱり平成を単位にしてるんだろうか
0191デフォルトの名無しさんNGNG
>>189
あほか。
I/Fが文字列型だとしてもこちら側で日付型に再変換してやれば済むだろ。
糞システムに合わせて糞システム作る気か？
0192デフォルトの名無しさんNGNG
>>190
皇紀。
0193デフォルトの名無しさんNGNG
>>191
文字列でやり取りしなければいいじゃんて言われても、
状況によってはそうもいかないこともあるって言ってるだけなんだけど。

＞ I/Fが文字列型だとしてもこちら側で日付型に再変換してやれば済むだろ。
それはまた別の話。
0194デフォルトの名無しさんNGNG
>>190
日本に西暦が導入されたのは戦前だべ
0195デフォルトの名無しさんNGNG
神武天皇がお生まれになった年を0年に設定すれば良いのだ。
西暦など糞。
0196デフォルトの名無しさんNGNG
どこかの生保が皇紀を使ってると聞いたけどどこだっけ?
2000年問題関連でその話が出たときにサヨの痛い人が観察されたんだよな。
0197!99NGNG
>>99 同意
>>100
とても長い間、仕事でそうしているが。何か？
0198デフォルトの名無しさんNGNG
ランバダ
0199デフォルトの名無しさんNGNG
>>197
引き継いだ人が苦労しているだけですが、何か？
0200デフォルトの名無しさんNGNG
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")
0201デフォルトの名無しさんNGNG
↑こいつアフォ
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"
0202デフォルトの名無しさんNGNG
>>197
今すぐ仕事辞めろ。
0203デフォルトの名無しさんNGNG
なんで？
0204デフォルトの名無しさんNGNG
>>197
一目でばっちり分かっちゃうコードならいいが。
そういう仕事はしてないんだろ？（褒めてる）
その素晴らしいコードを残されたものは多分そのコードが作られたときより
短時間で理解して、書き換えなきゃならないこともあるんだよ･･･
0205デフォルトの名無しさんNGNG
>>197
「あのプログラム、君しか分かる人いないから全部任せるよ」
って言われて喜んでないか？
0206197NGNG
>>204
コメントを信じる根拠は何処にも存在しない。
従ってメンテナンス時にもコメントは信用しない。
貴方はコード内のコメントが常に正しいと思っているのか？
#メンテナンス時にわざわざコメントを削除するぞｗ
だからこそコメントを書かないのだ。

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

あのさあ。「コメント無しでも理解できるコードを記述する努力」はしないの？
その種の努力を放棄したのなら、「コメント書かないという人間を叩く」
という行動も理解出来ないことはないけど
0207デフォルトの名無しさんNGNG
コメントに日時入れないのは最悪
0208デフォルトの名無しさんNGNG
何を意図して書かれたかもわからないようなコードを信じる根拠も無いわけだが。

つか、「コメントを書く」＝「コメントがないと読めないコードを書く」と勝手に決められてもな。
あんたがコメント書かなかったせいで気合を入れる分だけの余計なコストがかかってるんだよ。
0209デフォルトの名無しさんNGNG
いらんよそんなもん。cvs annotateを見る方が確実。
0210デフォルトの名無しさんNGNG
そんなもん=日時ね。
0211デフォルトの名無しさんNGNG
コメントが間違っててそれに振り回されてる人が多い。ソース読みさえすれば分かるのに。
それで読んでも意図が分からんソースなら捨てて作り直せば良いだけなのにね。
0212デフォルトの名無しさんNGNG
>それで読んでも意図が分からんソースなら捨てて作り直せば良いだけなのにね。
といっている奴のコードにまともに読めるコードがあったためしがないのが現実。
0213デフォルトの名無しさんNGNG
コード追って分かるのは「どう動作するか」だけ。
その動作が正しいかどうかは分からない。
0214デフォルトの名無しさんNGNG
コメント見てもわからないぞそんなこと
0215デフォルトの名無しさんNGNG
>>214
どういう動作を期待しているかが分かるようなコメントを書かないからだ。
0216デフォルトの名無しさんNGNG
コメントはコードが正しく動いていれば激しく有用なんだが、
コードが正しくないととたんに害悪になる。
人間プログラミング言語を読むときは一意一句逃さないように慎重に読むが、
コメントがついているとその先入観に惑わされて、コードをまじめに追わなくなる。
特にコードがシンプルなところほど見逃しやすくなる。

if ( a<upper_bound ) break;

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

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

は見逃しやすい。

問題はソースを読む必要があるのはたいてい正しく動いてないときなんだ。
0217デフォルトの名無しさんNGNG
コメントが無けりゃ間違いかもわからんじゃないか
0218デフォルトの名無しさんNGNG
なら、こういうのはどうか

// 上限を超えたら終了
if( a>lower_bound ) break;
0219デフォルトの名無しさんNGNG
コメントが無けりゃ間違いかもわからんじゃないか
0220デフォルトの名無しさんNGNG
>>206
> 貴方はコード内のコメントが常に正しいと思っているのか？
> #メンテナンス時にわざわざコメントを削除するぞｗ
> だからこそコメントを書かないのだ。

オマエ最悪だよ。
自分のコスト下げるために周りにコスト押しつけて平然としてるなんて。
0221デフォルトの名無しさんNGNG
>>216
そういう単純な間違いを含んだソースを読むという状況がよく分からないです。
そんなの書いた本人がデバッグしてないだけじゃないの？
0222デフォルトの名無しさんNGNG
>>216
> // 上限を超えたら終了
> if( a<upper_bound ) break;

その例もおかしい。
コメントというのはプログラムコードの日本語訳じゃない。
上限の数値に配列のサイズ程度の意味しかないならそのコメントは不要。
プログラムコードが仕様とどうリンクするのかを中心に記述し、注意を要する複雑な
例外判定などポイントを絞って詳細に記述すべきだ。
誰が書いてもそのようになるコードにわざわざコメントを付けるのは無意味。
0223デフォルトの名無しさんNGNG
>>216
コード書いた本人にとっては、
aやupper_boundが何を表しているかも分かってるし、前後にどういう処理が行われているかも分かってるし、
どういう条件の時にどう動かなければいけないかってのも分かっているかもしれないが

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

「そんなものはすべてコードで表してる」と主張するかもしれないが、読むほうは
コードが表していると思われる内容が正しいか間違っているかも含めて解析しないといけないんだ。
特に、正しく動いていない時には。
0224デフォルトの名無しさんNGNG
コメントには
「何をしているか」ではなく (それはコードを読めば分かるから)
「なぜそうしているか」を書くのがよい。
0225（；д；）○ぽんぽんぽんぽぽぽぽんぽんぽん ◆1xsES22i66 NGNG
>>224
そのコードがjmpの嵐だったりするわけだ。
フローチャート程度のコメントは欲しいぞ。
0226デフォルトの名無しさんNGNG
私も>216や>218のようなコメントを見つけたら削除するね。
なので>224には同意。
だがそういうコメントを適切に書けない香具師に限って意図不明のコードを書くんだ。
0227197NGNG
>>208
滅茶苦茶だな。コードを信用しないでコメントを信用するのか？
>「コメントを書く」＝「コメントがないと読めないコードを書く」と勝手に決められてもな。
そんな事は言っていない。「コメントは読まない」とか「コメントを書くのはどうぞ自由に。だが俺は書かない」
と言っているだけだが。

>>211
同意

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

>>220
ああなるほど。俺が叩かれる理由はそれかｗ
「コメントを書けばメンテナンス時の工数が常に下がる」と思っているわけか
0228デフォルトの名無しさんNGNG
>>227
え？コメントを消して回ってるのに？
0229デフォルトの名無しさんNGNG
>>227
もしかしてfunction単位とかファイル単位のサマリも書かないのか？
0230デフォルトの名無しさんNGNG
コメント書かない主義の奴が作って、別の奴がメンテナンスすると最初のコードの意図は
完全に無視されることが多いんだよな。で、行き当たりばったりの「動けばいいや」パッチ
が当てられることになる(/* 多分、ここでエラーを返さないといけない */ みたいなコメント付で)。
0231デフォルトの名無しさんNGNG
だから、
何をしているといった類のコメントはいらない

何のための、とか行う目的のコメントを残せ
0232デフォルトの名無しさんNGNG
>最初のコードの意図

当初の目的でさえ間違ってたなら、別に最初のコードの意図は無視しても無問題だが？
0233デフォルトの名無しさんNGNG
コメント書かない香具師が改造やると最悪だよな。
既に動いてる他のコードの意図無視して適当にパッチ当てやがる。
0234デフォルトの名無しさんNGNG
>>232
最初のコードで意図してたことは(多分)正しかっんだけど、実装でミスを犯すことはあるよね。
そのほかにも環境変わったら動かなくなっちゃったとか。
で、その不具合を修正するためにコード見ても、元のコードの意図がよくわかんないんで
無理矢理修正しがちって話。

もっとも、俺はミスなんかしないぜっていう奴には関係ない話だけどね。
0235デフォルトの名無しさんNGNG
>>234
ミスをしない奴ばっかりなら、そもそもソフトウェア工学自体が必要なくなってきそうだけどな。
0236デフォルトの名無しさんNGNG
最初に作る時にはコメントは不要
後でバグ取りで直す時になぜバグったのか、
どう処置したのかをコメントに書いておく
0237デフォルトの名無しさんNGNG
224 ：デフォルトの名無しさん ：04/12/26 11:25:38
コメントには
「何をしているか」ではなく (それはコードを読めば分かるから)
「なぜそうしているか」を書くのがよい。

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

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


．．．たったこれだけの話なんだけどなぁ
0238デフォルトの名無しさんNGNG
>>197
疑問・・・君はアセンブリで書くときもコメント書かないのかい？
もし、他人が書いたコメントなしのアセンブリリストを保守できるなら神だな
0239デフォルトの名無しさんNGNG
なんか馬鹿が多いようだが、
正直メソッド内にコメント書いちゃだめだろ？
書かなきゃ解らない時点でそのメソッドは機能がでかすぎるんだよ。
もちろんメソッドの直前に機能説明は書くべきだが。
0240デフォルトの名無しさんNGNG
ビットシフト使いまくりっていいコード？
0241デフォルトの名無しさんNGNG
>>239
書いてあっても良い、書いていない奴のコードが汚いのが問題。
コメントを打つとコードを綺麗に書く技術が身についてくる、
そのうちにコメントが無くなって来るのだ。
コメントを書かない奴はコメントを書かないようにする技術が大抵無い。
0242デフォルトの名無しさんNGNG
>>240
使うべくして使ってんならどんなにあってもいいコード
0243デフォルトの名無しさんNGNG
>>241
>コメントを打つとコードを綺麗に書く技術が身についてくる、
嘘だ。逆説を書いてみようか。
コメントを打つとコードが汚いことを隠せたような気になって、綺麗に書く様には決してならない。
#わずか四行で矛盾したことを言えるのはすごい才能だね
0244デフォルトの名無しさんNGNG
逆説？
0245デフォルトの名無しさんNGNG
>>243
クソこぎちゃないソースにコメントがない最悪のソースコードなら良く見た事がある。
その反対は滅多にないな、まったくないとは言わない程度に。
特にコメントが無いのが正しいとかいっている奴のソースコードにまともなものがあった為しは皆無、
まずコメント回避の前にリファクタリングを勉強しろと小一時間の奴ばかり。

コメントの無いコードはコメントを極めた奴だけが可能にできる物だ。
理由は簡単で、コメントの持つ機能が各種名前に移っただけだからね、
基本的にコメントに書くべき適切な内容が考えられない奴は、
メソッド名・変数名に移しても事態は変わらないのだ。
意味が変わっているのに、変数名がそのままだったりとか、
機能分割したが機能が変わっているのにprivateメソッドの名前がそのままだったりとか
特に忙しくなったときは顕著だ、ここはキッチリ名前をかかなければ妥協できないという場所とどうでも良い場所の区別がつかないのだ。
手際よくコメントを書く技術が無い、が、手際よくリファクタリングする能力がない
に代わっただけで中身がダメならダメなものはダメなのだよ。
0246デフォルトの名無しさんNGNG
マ板のヨタ話みたいなレスしかないな
0247デフォルトの名無しさんNGNG
>>239
その強迫観念にとらわれて馬鹿みたいに小さなメソッドを乱造したのはオマエか！
0248デフォルトの名無しさんNGNG
>馬鹿みたいに小さなメソッドを乱造
これも典型だね、
必要な機能は近くにあったほうが良いというのは基本中の基本、
分けるときにはトレードオフを判断する必要があるが、
コメント皆無を妄信しているととんでもないクソコードを作り出す。
0249デフォルトの名無しさんNGNG
>>245
×コメントの無いコードはコメントを極めた奴だけが可能にできる物だ。
○コメントの無いコードはプログラミングをある程度以上、習熟した奴が可能にできる物だ。
0250デフォルトの名無しさんNGNG
つーか、１メソッドって一つの機能しか持たせなくね？
んで、処理実行！みたいなメソッドで他のメソッドを呼び出しコントロールする。
みんな違うのか？
１メソッドにあほみたいに機能を詰め込んでる？？

まあ、>>245の適切な名前をつけろは同意。
それがコメント極めることと同じとは考えたこと無かったけどな。
0251デフォルトの名無しさんNGNG
皆が"一つの機能"という感覚を共有できたら戦争など起きないだろうな
0252デフォルトの名無しさんNGNG
>>251
たしかに曖昧だが、
コメントをばりばり書かないと理解できないメソッドは、
１つの機能じゃないと思う。
0253デフォルトの名無しさんNGNG
なんか「機能」という言葉の定義が違うような・・・
どんな大きな機能だとてそれは一つの機能。
分割する事によってコードイメージが想像できる程度のサイズになるのが
設計だと思っているのだけれど。
0254デフォルトの名無しさんNGNG
例えば、パスワードの照合後、指定された年月時点での月次の貸借対照表を引っ張ってきて、
エクセルへ書き出す、というアプリケーションを作るとする。非常に大まかに書くと、
Foo()
{
　CollateUser();
　GetBalanceSheet(year, month);
　WriteBalanceSheetToExcelFile(fileName);
}

みたいに書くのか、上記３つのメソッドの内容を１つのメソッドの中で一緒くたにやって
しまうのか、という違いか。
0255デフォルトの名無しさんNGNG
例えば「更新」ボタンを考えてみる

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

この、「更新」を押すというメソッドはどう書けばいいだろうか？
１つの機能で済むだろうか。
0256デフォルトの名無しさんNGNG
>>254
自分中心にしか物事が見えて無くないか？

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

構造化プログラミングで、最小単位をどの粒度まで小さくするかなんて
コンセンサスは無いように思える。
0257デフォルトの名無しさんNGNG
>>256
議論の叩き台であって、俺が別に必ずそういう風にコードを書くという意味ではないが。
CollateUserといっても、相手がファイルなのかデータベースなのかでいろいろ
変わって来るからね。
0258ﾏｰﾁﾝﾌｧｳﾗNGNG
リファクタリング嫁
0259デフォルトの名無しさんNGNG
おまいら、自分が見て来たコードが世の中の全てとか平均と勝手に思ってないですか。
何年PGやってるか知らないけど、おまいが見たソースコードは世界中のソースコードの
１％にも満たないんじゃないですか。
そもそも話題の焦点にしている開発内容はなんですか。言語はなんですか。

0260デフォルトの名無しさんNGNG
>>257
つか、DBかファイルかでCollateUserの外が変わるような構造にするなよ。
すべてCollateUserの中で解決しろ。
0261デフォルトの名無しさんNGNG
あたしゃ馬鹿だから、対象でI/Fが変わるような関数作っても覚えられないから
対象ごとにクラス作って同じ名前のメソッドは同じI/Fにしちゃうねぇ。
んで、I/Fが違うのはコンストラクタだけだったり。
0262デフォルトの名無しさんNGNG
>>260
CollateUserメソッドの中身が、いろいろ変わってくる、と言っているのです。
0263デフォルトの名無しさんNGNG
なんつーか、実現したい機能（業務ロジックだったり、データをExcelに書き出す機能だったり）は
クラスつかえるなら１クラスに、使えんならファイルスコープでくくるなり、
グループ化するだろ。
同じインターフェースで使いたい似たような機能があるなら、interfaceやfactoryも用意する。

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

Button_OK()にOKボタンの処理全てを書いてしまうと、そりゃコメントは必要になる。
0264デフォルトの名無しさんNGNG
なんか間違えた。
読み込み、書き込みとも同じクラスってのはやんねーな。
・データ取得クラス
・なんかの処理クラス
・データ書き込みクラス
って感じで、それぞれのクラスで
処理１、２、３だな
0265デフォルトの名無しさんNGNG
>>264
なんかとっても手続き型ですね。
0266デフォルトの名無しさんNGNG
パフォーマンス上の理由とかで
読み書きを同時に行いたいとかなったらどうするの？
さらにサーバと通信しながらとか
画面書き換えながらとか
連携するのがほとんどだと思うけど
コメントないとなんでこういう順番なのかわかんなかったり
0267デフォルトの名無しさんNGNG
>>265
C++やらJavaやら使っている時点で手続き型なんですが。
0268デフォルトの名無しさんNGNG
>>264-265
今のプロジェクトのコードがすげー気持ち悪かったんだが、なんとなく理由がわかった。
手続きを中心に考えたクラス設計になってるからか(そういうパラダイムの奴が設計したんだろう)。
0269デフォルトの名無しさんNGNG
>>267
>C++やらJavaやら使っている時点で手続き型なんですが。

いや、>>265 は、

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

と言いたいのだろう。

そっとしておいてやれよ。
それはそれで一つの生き方なのだから・・・
0270265NGNG
いやいや、JavaにしろC++にしろ1メソッドの中身が手続きを中心に書かれるのは分かるし
コントローラークラスみたいなクラスがあるのも分かるけども

>>264のクラス設計は気持ち悪い。
データ取得クラスはデータを取得するっていうpublicなメソッドと
その他のprivateメソッドから出来てるわけですよね。
それはCのライブラリのようにstaticメソッドだけのクラスばかりを
作る人と大差ないと思うのです。
0271デフォルトの名無しさんNGNG
>>264
その「なんかの処理クラス」が「データ取得クラス」と「データ書き込みクラス」を所有
してたりデータアダプタとしてプロパティ化しているならその設計も有りだな。
あるメソッド中でその3つのクラスを個別に操作しているなら、でっかいクラスに3つの
手続き型メソッドを書いてるのと何ら変わりない糞コード。
いや、細かい単能jクラスが増えるだけさらに有害かもしれん。
0272デフォルトの名無しさんNGNG
実際はこう。
・FooDAOFactory
・FooDAO
・FooDAOImpl
・FooLoader
・FooRegister
クラスやメソッドの説明は必要。だけどメソッド中にコメントはいらん。
コード嫁。以上。
0273デフォルトの名無しさんNGNG
>>272
Fooに対してなんでLoaderとDAOが同列に存在するのさ？
0274デフォルトの名無しさんNGNG
>>272
Fooは扱うデータか？いやそれにしてはFooクラスが無いな。
名前空間というか接頭語みたいな物か？
意図の分からん命名ってコードを読む気力を激しく奪うぞ。
0275デフォルトの名無しさんNGNG
関数は粉々になるまで分けるのが正しいらしいが
関数名に困る
0276デフォルトの名無しさんNGNG
良いコードを書くためのウハウハを蓄積するスレ
0277デフォルトの名無しさんNGNG
>>275
名前が付けられないのは分けすぎの証拠。
0278デフォルトの名無しさんNGNG
>>275
関数のオーバヘッドは無視できない。
0279デフォルトの名無しさんNGNG
>>278
粉々にしているんだからinlineにすればいいだけだと思う。
0280デフォルトの名無しさんNGNG
>278
最近のWindowsPGで
関数のオーバーヘッドを気にするような必要ってある？
そもそも、処理を関数で細分化するのは、メンテを容易にするためであって
高速化の為ではない訳で・・・

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


0281デフォルトの名無しさんNGNG
>>280
そこで匿名関数を使う。
0282デフォルトの名無しさんNGNG
>>280
Cのような代入型言語を使うのではなくて、最近では関数型を使った方が生産性が
高い事が多くなったように思わない？
0283デフォルトの名無しさんNGNG
>>280
「処理の分離／細分化」ではない。「機能の分割」だ。#細かなところは突っ込まないで
機能の分割が出来ていれば命名に悩む事なぞないと思うが
0284デフォルトの名無しさんNGNG
>>280
名前の付け方で困るほど細分化したら却ってメンテ性下がるだろ。
何のための関数なのかが自明なレベルで止めとけって。
（自分には判ってるから大丈夫とかアマチュアな事言うなよ。）
0285デフォルトの名無しさんNGNG
>>280
＞ ある処理を細分化して
＞ その処理中の１度しか呼ばれないような関数の場合の
＞ 命名手法はどんな感じ？
他の関数と同じ方法でつければいいじゃん。
0286デフォルトの名無しさんNGNG
ラムダよりもforeachが欲しい
0287デフォルトの名無しさんNGNG
>>286
アルゴリズムのstd::for_eachで十分……、なわけないよな。
0288デフォルトの名無しさんNGNG
ラムだっちゃ☆
0289デフォルトの名無しさんNGNG
>>286
C#使ってみなよ、あんまり便利でもないよ、for文+イテレータのほうがシンプルでいいね。
0290デフォルトの名無しさんNGNG
>ある処理を細分化して
>その処理中の１度しか呼ばれないような関数の場合の
>命名

そんな困るような分割するのが頭悪い
0291デフォルトの名無しさんNGNG
>>290
たとえば、Cにおけるコマンドライン引数処理なんて
mainの中から一度呼ぶだけだったりしますが。
0292デフォルトの名無しさんNGNG
>>291
呼ばれる頻度で名前の付け方変えるってどこの世界の命名規則でつか？
0293デフォルトの名無しさんNGNG
>>292
さぁ。そんな命名規則見たこと無いけど。
0294デフォルトの名無しさんNGNG
頻度っていうかprivate, staticなものはいい加減に付けがち
0295デフォルトの名無しさんNGNG
関数にしたんなら
関数にされた一連の処理群に何らかの意味的なマトマリを見い出してるはずだから
その意味を英訳して関数名にするがよい
0296デフォルトの名無しさんNGNG
勿論「returnで流れ制御」したいがために関数を作っちゃう馬鹿はどっかいけ
0297デフォルトの名無しさんNGNG
296
便利さと性能、どちら優先かによる
0298デフォルトの名無しさんNGNG
Cライクな言語はもううんざり。
0299デフォルトの名無しさんNGNG
これからはschemeか。
0300デフォルトの名無しさんNGNG
Schemeもいいけれど、ML系のOCaml辺りの方が実用的でよさそう。
0301デフォルトの名無しさんNGNG
＞returnで流れ制御
って何？
0302デフォルトの名無しさんNGNG
例えばreturnで多段breakをしたいが為だけに関数を分割するって話だろ
0303デフォルトの名無しさんNGNG
>291
>コマンドライン引数処理

そう名づけりゃいいじゃんかよ
0304デフォルトの名無しさんNGNG
>>303
一度しか呼ばれないような関数を作る奴は頭悪いんだろ。
0305デフォルトの名無しさんNGNG
>304
>一度しか呼ばれないような関数を作る奴は頭悪い

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

0306デフォルトの名無しさんNGNG
名前付けに困るような分割＝１度しか呼ばれないような関数への分割でしょ。
0307デフォルトの名無しさんNGNG
>>303
main も駄目でつか？
0308デフォルトの名無しさんNGNG
func(){
　func_init();
　func_run();
　func_done();
}
とかだらだらと_でつないでいけば少なくとも迷うことはない。
0309デフォルトの名無しさんNGNG
通行人A、通行人B ・・・ でどうだろうか？
0310デフォルトの名無しさんNGNG
ん？

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

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

0311デフォルトの名無しさんNGNG
1 度しか呼ばれない関数を作るのが抽象化の目的であれば良いコードです
0312デフォルトの名無しさんNGNG
どうでもいいけど１度って書くと角度みたいだね
0313デフォルトの名無しさんNGNG
んん？
角度ってラジアンだろ？
0314デフォルトの名無しさんNGNG
>>313
いいえ。
0315デフォルトの名無しさんNGNG
１００前後読んでたら、仕様書からいきなりコーディングしてる奴がいた。
0316デフォルトの名無しさんNGNG
蓄積しま
ttp://www.okisoft.co.jp/esc/go/style0.html
0317デフォルトの名無しさんNGNG
>>272
スコープが
上３つはpublic
下２つはpackage
0318デフォルトの名無しさんNGNG
>>317
>>272書いた人？
静的クラス図書いてUPしてほしいな。
0319デフォルトの名無しさんNGNG
スレッドも1/3経過したことだし、これまでに蓄積されたノウハウをまとめない？
0320デフォルトの名無しさんNGNG
電車男みたいに本にして儲けたいらしいが、
ttp://f55.aaa.livedoor.jp/~goodcode/
にまとめるとか。
0321デフォルトの名無しさんNGNG
これまでの成果
---
・公開されているよいソースコードを読むとよい
・assert文を使うとよい
・よい本を読むとよい
・コード量が少なくなるようにする
・メソッドの数をできるだけ少なくする
・クラスはできるだけ作らないようにする?
・リファクタリングする
・素早く頭働かす?
・メンタルの健康を保つ?
・ネストはできるだけ下げないようにする?
・変更履歴にはwhat i didではなく why i did itを書け?
---

この先続けてもたいした成果は得られないような…
0322デフォルトの名無しさんNGNG
結論
自分で書かない
人のやつをパクる
0323デフォルトの名無しさんNGNG
シンプルが一番
可読性も保守性も効率だって

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

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

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

301 ：仕様書無しさん ：05/01/06 03:51:53
俺が思うに「最初にテストケースを考える」ことこそテストファーストの真髄だと思うんだ。
（テストファーストを唱えてる人がどう思ってるか知らんけど）
そこで生まれたテストケースが貧弱かどうかは実はどうでもよくて発想の転換で
テストケースを濃くする事とコード書く時に外部条件を意識して書くようにする事
要するに熟達したプログラマが普通にやってるこの2点をシステマチックにやる事で品質向上を狙うモノではないかと。
0326デフォルトの名無しさん05/02/05 03:05:22
if(flag){
　　func();
}
というインデントが多いみたいだけど
if(flag)
{
　　func();
}
これだとダメなの？
こちらのほうが対応するカッコの数とか分かりやすいんだけど。
0327デフォルトの名無しさん05/02/05 03:06:08
>>326
人それぞれ。
私は前者。
0328デフォルトの名無しさん05/02/05 03:07:27
>>326
なるべく行数を減らした方がコード全体を把握しやすくなるというメリットがある。
0329デフォルトの名無しさん05/02/05 03:19:39
でも行数が減って積め積めになるとかえって読みづらいと思う。
コード数を減らす事が良いコーディングと聞いて行数を減らそうと
勘違いする人がいるけど、そういう人に限って凄く密集したような
コーディングするんだよなぁ。
しかも変数名もとにかく短くて意味の通らないものにしたりするし。
0330デフォルトの名無しさん05/02/05 03:28:24
>>329
いや、たしかにそうなんだけど、私が言っているのはもっと物理的な面の話。
0331デフォルトの名無しさん05/02/05 03:38:03
しかし、こういうのは人に強制できるものじゃないから
人それぞれのコーデイングスタイルがプロジェクト内で混ざり
まくるんだよなぁ。
深いインデントの中に違うスタイルのインデントが入ってきたりとか。
0332デフォルトの名無しさん05/02/05 07:32:07
>>329
ifとfuncの間が一行空いている積極的な理由が思いつかない。
0333デフォルトの名無しさん05/02/05 07:50:19
if(flag) func();
0334デフォルトの名無しさん05/02/05 07:57:42
>>326
つか、カッコの数を数えないといけないようなコードを書くな。
0335デフォルトの名無しさん05/02/05 08:02:40
>>326
K&Rに倣っている人も多いんじゃないかな。
0336LISP大好き05/02/05 08:04:29
>>334
呼んだ？
0337EmacsLisp使い05/02/05 09:05:43
>>336
インデントはエディタに任せるから数えたことないなぁ
0338デフォルトの名無しさん05/02/05 10:01:09
括弧の前に改行一個入れるか入れないかで
議論になるお前らのミジンコサイズの根性がかわいいぜ
0339デフォルトの名無しさん05/02/05 12:06:51
シッコの穴の小さいやつらだ
0340デフォルトの名無しさん05/02/05 14:46:08
>ifとfuncの間が一行空いている積極的な理由が思いつかない。

見やすいじゃないか。ifの横にカッコがある事に気づかない事も
たまにあるしブロック化されているのが明確になっていて良い。
0341デフォルトの名無しさん05/02/05 15:07:26
見やすいか? それと同じように>>326の下の方が見にくいという主張も成り立つが。
むしろ条件と関係なくローカルスコープを作るためのブロックと混同しそうでいやだ。
0342デフォルトの名無しさん05/02/05 15:27:22
do
{
if (...)
{
...;
}
else
{
...;
}
}
while (...);
と書くのだろうか…
私なら
do {
if (...) {
...;
} else {
...;
}
} while (...);
と書くのだが。
0343デフォルトの名無しさん05/02/05 15:47:33
条件式が複数行になる場合
if(...
　...
　...) { // ここと
　...; // ここがくっついて見えるのが嫌
0344デフォルトの名無しさん05/02/05 16:15:32
>>342
インデントされてないが上の書き方のほうが見やすい。
まぁdoは自分は使わないけど。
0345デフォルトの名無しさん05/02/05 16:24:11
>>344
do
{
while (...) ...;
}
while (...);
while (...) ...;
と
do {
while (...) ...;
} while (...);
while (...) ....;
では?
0346デフォルトの名無しさん05/02/05 16:29:16
うえは
}
while (...);
が紛らわしくてやだ
0347デフォルトの名無しさん05/02/05 16:34:23
>>340
＞ ブロック化されているのが明確になっていて良い。
ifとそれに続く処理が別のブロックのように見えちゃうのはいかんだろ。
0348デフォルトの名無しさん05/02/05 16:46:37
良いコードを書くためには
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を毎日欠かさず実行する。

これでよしっ！
0349デフォルトの名無しさん05/02/05 16:56:00
>>341
>ローカルスコープを作るためのブロックと混同しそうでいやだ

ローカルスコープを作るためのブロックなんて使わない。
これで万事解決。
0350デフォルトの名無しさん05/02/05 17:31:10
>>349
アフォハケーン
0351デフォルトの名無しさん05/02/05 18:27:23
>>345
do
{
　　while (...)
　　{
　　　　 ...;
　　}
}
while (...);

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

インデント、ブロック化、改行を活用する。
0352デフォルトの名無しさん05/02/05 20:22:55
結論はやはり人それぞれ。
0353デフォルトの名無しさん05/02/05 22:51:35
３０年かわらぬ嗜好品だな
0354デフォルトの名無しさん05/02/05 23:15:02
人間の目は横に並んでいるので縦方向に長いものは把握しにくい
0355デフォルトの名無しさん05/02/05 23:19:41
do{
　　while (...){
　　　　 ...;
　　}
}while (...);

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


どう考えてもこっちの方が把握しやすい
0356デフォルトの名無しさん05/02/05 23:30:37
本で読んだ受け売りだけど。
#ifdef FOO
if (hoge)
#else
if (piyo)
#endif
{
　　statements;
}
こういう場合に、エディタの括弧対応調査機能が働きやすいというのがある。
0357デフォルトの名無しさん05/02/05 23:32:34
バッドノウハウだな。
0358デフォルトの名無しさん05/02/05 23:41:13
if(hoge){
foo;
}

の人は何で

if(hoge{
foo;}
にしないの？
0359デフォルトの名無しさん05/02/05 23:42:07
}else{
0360デフォルトの名無しさん05/02/05 23:44:24
>>358
}が最後尾になって追跡しにくいから。
関数型だったら手続きがないから最後尾の}はOKだけど。
0361デフォルトの名無しさん05/02/05 23:47:12
>>356
それに近い事よくやるよ。
ifの行だけ#ifdefとかで無効になっても残ったブロック部分も
問題なくコンパイル出来るしね。
0362デフォルトの名無しさん05/02/06 00:11:17
>>356
普通は
#ifdef FOO
#define COND hoge
#else
#define COND piyo
#endif
if (COND) {
　stmts;
}
みたいに書かないか？
0363デフォルトの名無しさん05/02/06 00:15:47
単独で記述することができないキーワードが先頭に来るのはきもい。
x
if (hoge)
{
}
else
{
}

o
if (hoge) {
} else {
}
0364デフォルトの名無しさん05/02/06 01:30:05
きもいじゃ理由にならん。
見た目で語るなら個人差がある。
0365デフォルトの名無しさん05/02/06 02:17:00
>>362
それだとifでbreak張ってもCONDがどちらか分からないんじゃない？
0366デフォルトの名無しさん05/02/06 04:40:28
m
a
i
n

これにはびっくりしたよw
0367デフォルトの名無しさん05/02/06 08:36:21
>>356 >>362
普通は
int hoge()
{
...
}
int piyo()
{
...
}
int (*stmts[])() = {hoge, piyo};
int fuga = stmts[FOO]();
みたいに書かないか？
0368デフォルトの名無しさん05/02/06 09:50:48
>>367
#define FOO
だったらどうする
0369デフォルトの名無しさん05/02/06 10:28:22
>>368
あふぉか？
0370デフォルトの名無しさん05/02/06 15:36:03
>>21
> 9 a(1, 1);
これだな。

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

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

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

こういう場合
/**
* コメント
* @author $Author$
* @version $Id$
*/
で統一する必要がある。
VC++プログラマが書いたコードを調整したいときもこの問題に直面する。
//を好んで使う癖がある人のコードに対して/** */ を求めると
抵抗する人もいる。実際そういう人と仕事をしている。
0371デフォルトの名無しさん05/02/06 15:38:33
>>362
それだと

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

と書けないから。
0372デフォルトの名無しさん05/02/06 15:52:02
>//を好んで使う癖がある人のコードに対して/** */ を求めると

Eclipse側の問題を//スタイルのプログラマにしわ寄せさせるのは良くない。
0373デフォルトの名無しさん05/02/06 16:00:56
(;ﾟ∀ﾟ)=3ウハウハを蓄積
0374デフォルトの名無しさん05/02/06 16:03:21
>>372
>Eclipse側の問題を//スタイルのプログラマにしわ寄せさせるのは良くない。

C89 との互換性を考慮するプログラマにしわ寄せさせるのも
いかがなものかと。
0375デフォルトの名無しさん05/02/06 17:04:29
互換性考慮がチームで決定された方針なら全員あわせるべき。
それが個人による趣味の範囲なら人それぞれ。
C++で//を使うなという話自体はナンセンス。
0376デフォルトの名無しさん05/02/06 17:09:35
複数行に渡るコメントは、#if 0 を使ったり　include にしたり
0377デフォルトの名無しさん05/02/06 17:56:34
>>376
>include にしたり
?
037837605/02/06 18:15:11
>>377
コメント行のみで構成されるテキストファイルを作ってincludeするのだよ
0379デフォルトの名無しさん05/02/06 18:23:33
>>376
それはそれでひとつのテクニックだとは思うけど、
コメントの為にあるものではないし、
エディタ上ではコメント扱い(の表示)になってくれない。
0380デフォルトの名無しさん05/02/06 18:25:33
>>378
ごめん、それ、何の意味があるのか判らない。
例えばfoo.cppに
// See foo.txt for detail.
って書けば済む気がしてならないんだけど。
0381デフォルトの名無しさん05/02/06 18:27:08
>>378
基本的に、コメントはコンパイラじゃなくて人が読む物なのに、
わざわざ別ファイルにして、そっちを開かなきゃいけなくなるのが馬鹿馬鹿しい。と思えるのは自分だけですか？
038269式フリーPG ◆hND3Lufios 05/02/06 18:28:14
無意味
0383デフォルトの名無しさん05/02/06 18:49:54
まともに動けばそれで良い
0384デフォルトの名無しさん05/02/06 18:50:16
>>378
プリプロセッサを通さないとコメント読めないの？
とてつもなく不便な気がする。
0385デフォルトの名無しさん05/02/06 18:54:36
ifやwhileの{を条件式の後に続ける人でも
関数始まりの{は行頭に書くのはなんで？
0386デフォルトの名無しさん05/02/06 19:13:57
確かにそうだよな。統一感が無いね。
0387デフォルトの名無しさん05/02/06 19:17:26
おれは関数始まりでも行の後ろに{つける派。
038837805/02/06 19:23:06
ふふふ。やはり不評だｗ
>>379
前半。ご指摘の通り。
後半。色分けが出来るエディタ使用を前提にされてもね。
>>380
これまたご指摘の通り。
>>381
貴方だけではないｗ
>>384
全くその通り。

私が恐れるのは「複数行に渡るコメントを記述する事が、コード自体の可読性を損ねる場合」だ。
一読すればわかるレベルの10行程度の関数に20行ものコメントヘッダを付加しなければならないとしたら、
ソースファイルの行数は単純計算で三倍になるよね。
・・・いやまあ叩き続けたいならそうしてもいい。
単に自分の習慣の一部を書いただけだし、議論する気もない。
0389デフォルトの名無しさん05/02/06 19:27:38
逃げたか・・・
039037805/02/06 19:40:40
>>389
いいや。逃げていない。
道義的な悪をなしたと思っていないので「逃げる」という言葉が適切だとも思えないしね。
議論したいの？。不毛だと思うけどね。反論したくなるレスをどうぞ。
0391デフォルトの名無しさん05/02/06 19:43:04
>>390
コードの容量を無駄に食うだけで、何の意味も無いと思う。
確かに大量のコメントによるコードの可読性が損なわれるケースはあるけど、
それならプログラムとは別に専用のファイルを作ればいいでしょう。
includeする意味なんて皆無だと思う。
039237805/02/06 19:50:34
>>391
意味は確かにないのだが。
「全ての関数にはコメントヘッダがなくてはならない」
という考えを持った人間と仕事したことがあってねｗ。
コメントヘッダの総行数がコードの総行数より多くなったので、
コメントヘッダ全てをincludeにした。とても読み易いコードになったよ
0393デフォルトの名無しさん05/02/06 19:55:59
>>392
で、あなたがその考えを今も引きずっている訳は？
0394デフォルトの名無しさん05/02/06 20:06:22
>>393
引きずってなどいませんよ。
規約にもないのに「全ての関数にはコメントヘッダがなくてはならない」という
横車をする人間がいない限りは。普段からそんな事なぞ絶対にしないｗ。
0395デフォルトの名無しさん05/02/06 20:32:49
Doxygenを使うと関数にコメント付けるけどそれについてはどう思う？
0396デフォルトの名無しさん05/02/06 20:39:16
コメントだったら、エディタによっては隠す事ができる機能がある物もあるよね。
そういうエディタを使えば気にならないんじゃない？
ソースと同じところにコメントがあってこそ意味があると思うし、
Doxygenなんてもろにその思想でしょう？
039737805/02/06 20:46:44
>>395
ああ。ソースコードからプログラム/詳細設計書を生成するツールだね。
あれは基本的にプログラム/詳細設計書を作成しなければならないという契約下における
省力化のためのツールだ。もちろんその様な規約になっていればその通りにするけど。
「プログラム/詳細設計書を作成しなければならない」という事自体に、反対。
#ruby開発者と同意見かな
#ツールの話ではなく、コードの話をしたいのだけど
0398デフォルトの名無しさん05/02/06 20:57:00
>>397
それだけではなく、
ソースを読むときに手助けになるから、初めて読むようなソースにはDoxygenかける
こともあるよ。自分のソースを見返すときにかけることもある。
0399デフォルトの名無しさん05/02/06 21:13:48
>>392
ひとりでしこしこ書くコードじゃないのなら、
せめて引数と戻り値の仕様は書け。
0400デフォルトの名無しさん05/02/06 21:41:50
DoxygenとCVSを組み合わせるとソースにリビジョン番号を
埋め込む事ができるよね。
確かコメントに何か仕掛けするんだと思ったけど。
コメントだけ別ファイルにするとわけが分からん事になりそうだ。
0401デフォルトの名無しさん05/02/06 21:45:03
>>400 それ、Doxygen関係ない。
0402デフォルトの名無しさん05/02/06 22:10:51
>>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
0403デフォルトの名無しさん05/02/06 22:11:47
メンバ変数の名前は
1 m_testData;
2 m_TestData;
3 testData;
4 TestData;
だったらどれがいい？
0404デフォルトの名無しさん05/02/07 01:29:10
m_test_dataだったり。
0405デフォルトの名無しさん05/02/07 02:40:26
おれもだ。
以前どっかのサイトでそのスタイルを推奨してるところあったよ。
0406デフォルトの名無しさん05/02/07 06:01:08
私は最近mTestData;
0407ぶび05/02/07 10:48:37
VBだと完全一致検索で「_」が無視されるので(´･ω･`)
0408デフォルトの名無しさん05/02/07 13:35:01
>>326
実際のところ、紙面上の都合が全て。
下のコードだとページ数が余計にかかり、コスト高になる。
他の理由はそれを誤魔化すためのものにすぎないのだ。
0409デフォルトの名無しさん05/02/07 14:09:19
ハァ?
0410デフォルトの名無しさん05/02/07 17:30:47
いまだに行数で値段決めてんのか？
0411デフォルトの名無しさん05/02/07 17:33:11
>>410
お前の一行1円。
0412デフォルトの名無しさん05/02/07 21:27:38
なんのコストだよ。ケチ臭い。
0413デフォルトの名無しさん05/02/08 18:59:54
実装した機能に対して行数が少ない程対価が多くなるようなレートを設ければ
競ってリファクタリングせざるを得ないだろう。コードを読む方はそれを望む。
0414デフォルトの名無しさん05/02/08 20:55:28
>>413
行数じゃなくて、もうちょっとちゃんとした「読みやすさ」の指標がほしいね。

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

短いトリッキーなコードより、少し長くても素直なコードのほうが読みやすいよ。
0415デフォルトの名無しさん05/02/08 22:48:01
>短いトリッキーなコードより、少し長くても素直なコードのほうが読みやすいよ。

いくら素直なコードでも、なんの工夫もなく無駄にだらだらと長いコードは
かえって読みづらくなると同時にメンテナンス性も著しく低下するし、
このへん、「こーゆーのが理想的」とかっていうなんらかの客観的な指標が欲しいね。
0416デフォルトの名無しさん05/02/08 22:49:07
こんな所でだべってないでコード書けよ。
0417デフォルトの名無しさん05/02/08 22:50:46
こんな時間にコード書いたって、いいコードにはならない。
0418デフォルトの名無しさん05/02/08 22:55:14
>短いトリッキーなコードより、少し長くても素直なコードのほうが読みやすいよ。

そんな事行ってたらtemplateなんてどーすんの。
トリッキーの塊みたいなもんだし。
改行も故意に入れないといつの間にか横長になるしな。
0419デフォルトの名無しさん05/02/09 01:26:51
404-405
GNUコーディング規約は小文字でアンダースコアだね。
0420デフォルトの名無しさん05/02/09 03:11:01
マジだ。
http://www.gnu.org/prep/standards/standards.html#Formatting
変数はこれから小文字とアンダーバーで決まりだね。

ブロックのインデントこ↓だったわけだが。
do
{
a = foo (a);
}
while (a > 0);
0421デフォルトの名無しさん05/02/09 03:58:12
そのへんは後でフォーマッタかければなんとでもなる。
0422デフォルトの名無しさん05/02/09 13:41:13
ちなみにsunのjavaコーディング規約
http://www.tcct.zaq.ne.jp/ayato/programming/java/codeconv_jp/index.html

俺はJava厨だからこれが一番だなぁ。
0423デフォルトの名無しさん05/02/09 13:49:13
>>420-422
GNUは、Cで書くことが前提になっているからね。
0424デフォルトの名無しさん05/02/09 15:44:29
なんでsunの社内規則に従わにゃならんの
0425デフォルトの名無しさん05/02/09 18:59:49
>>415
それは、読むのがつまんないってだけで。
お前を面白がらせるためにコード書いてる訳じゃないので…
0426デフォルトの名無しさん05/02/09 22:57:57
>>425
似たようなコードがそこらじゅうにちりばめられてて、
その部分にバグがあった時の大変さを知らんのか？
その手のコードは共通部分をまとめて抜き出そうなんて
考えが全然ないから本来なら共通化できるコードと
そうでないコードが完全にごちゃまぜで、デバッグが
洒落んならんぞ。
0427デフォルトの名無しさん05/02/09 23:07:44
>>426
トリッキーなコードと簡潔なコードの区別ぐらいしようよ。
0428デフォルトの名無しさん05/02/09 23:14:35
>>427
いや、だから「客観的な指標が欲しい」つってんじゃん。
0429デフォルトの名無しさん05/02/09 23:27:39
>>428
構造化も出来てないコードは簡潔云々以前の問題だろ。
0430デフォルトの名無しさん05/02/09 23:39:24
>>429
最初はちゃんと構造化されてても
なんの工夫もなく無駄にだらだらと長いコード書いてたら
結果として自然にそうなってくるんじゃないのか？
0431デフォルトの名無しさん05/02/10 00:01:03
構造化ってなんだ･･･
0432デフォルトの名無しさん05/02/10 01:05:18
>>430
最初に構造化と決めたならなんの工夫もなくても構造化だけは
普通やってくんじゃないの？そこにテンプレートとか組み合わせれば
似たコードはだいぶ少なくなると思うけど。
そして欲を言えばOOPと。
0433デフォルトの名無しさん05/02/10 01:07:54
トリッキーなコードというとboost::lambdaとかを想像する
0434デフォルトの名無しさん05/02/10 01:57:31
>>426
低レベルな奴らは、本来共通化しちゃいけないものを無理矢理共通化するから侮れない。
0435デフォルトの名無しさん05/02/10 02:20:57
それはオブジェクト指向の考え方がまったく身についてないからだな。
0436デフォルトの名無しさん05/02/10 02:23:36
何でもかんでもオブジェクト指向を適用するのは勘弁して欲しい。
オブジェクト指向こそが優れ、C++でのコーディングはC流より優れる。

こういう考えの人が最近多い気がする。
0437デフォルトの名無しさん05/02/10 03:09:09
勘弁して欲しい理由は？
例えばあえてOOPに反するが自分では良いコードと思っている例を
挙げる事ができる？
0438デフォルトの名無しさん05/02/10 04:00:13
> 勘弁して欲しい理由は？
簡単。オブジェクト指向なんてメンテのためだけにあるただの経験則。
速くて効率の良いコードとは何の関係もない。
良いアルゴリズムの開発にオブジェクト指向なんて何の役にも立たないし、
少人数の意志の疎通が良くできる精鋭でのプロジェクトならオブジェクト指向なんかいらん。

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

きちんとした理論もないし、現場から汲み上げられたノウハウで80年代には既に広まってた。
今どきまだオブジェクト指向なんて叫んでるやつの気が知れん。
0439デフォルトの名無しさん05/02/10 04:19:33
そう言う見方もあるのは判るが、そう言う見方だけに拘泥していては大局を見失うよ。
0440デフォルトの名無しさん05/02/10 05:03:28
>>438
良いアルゴリズムを良いまま隠蔽するためにもオブジェクト指向は有効よん。
0441デフォルトの名無しさん05/02/10 05:47:21
>>438
> オブジェクト指向なんてそんな場合にしか有効じゃないよ

実際は「そんな場合」のほうが大方なワケよ。
あんたは「少人数の意志の疎通が良くできる精鋭でのプロジェクト」
しか経験したことが無いのか。幸せだな。
0442デフォルトの名無しさん05/02/10 07:20:47
>>441
> 実際は「そんな場合」のほうが大方なワケよ。
そりゃあんたの不幸な環境ではそうだ、って話。優秀ならそんなみじめな境遇には陥らんよ。
0443デフォルトの名無しさん05/02/10 07:29:53
>>442
お前さんの書いた優秀なかっこいいコードをうぷきぼんぬ
0444デフォルトの名無しさん05/02/10 09:06:13
>>438
アルゴリズムと設計は別物であることもわかってないような職場では働きたくないなぁ。
0445デフォルトの名無しさん05/02/10 09:51:37
分野によるんじゃない？
数値計算とか解析だったらオブジェクト指向なんて使わないでしょ。
0446デフォルトの名無しさん05/02/10 10:14:28
なぁ、そろそろ設計時のオプジェクト指向と実装時のオブジェクト指向を
はっきり区別して話さないか。
0447デフォルトの名無しさん05/02/10 10:39:27
保守のためだけでOOPにしてると思われたくないものだな。
データ構造が保証されるんだよ。ある程度。小規模であっても。
設計時のOOPはどうでも良いが。ソースコードでしゃべれない人は論外なので分ける必要がない。
0448デフォルトの名無しさん05/02/10 11:32:42
>>447
> データ構造が保証されるんだよ。ある程度。小規模であっても。
頭悪いんですね。「データ構造が保証される」だって。
0449デフォルトの名無しさん05/02/10 11:50:16
何の話をしているのかさえあやふやになってきたｗ
0450デフォルトの名無しさん05/02/10 13:03:54
プロジェクトなんかどうでもいい。
アルゴリズムを研究する人間にとってはOOPなんか本質でもなんでもない。
ここには職業プログラマしかいない、みたいに決めつけた議論はやめとけ。
0451デフォルトの名無しさん05/02/10 13:25:46
アルゴリズムだけを追ってる立場では、良いコードなんか本質でもなんでもないわけだが。
0452デフォルトの名無しさん05/02/10 13:27:40
>>451
良いコードとは良いアルゴリズムの具現である。
0453デフォルトの名無しさん05/02/10 13:29:58
>>452
グローバル変数使いまくりでスパゲッティ状態なコードがいいコード？
0454デフォルトの名無しさん05/02/10 13:31:31
よいコード書ける奴はこんなとこで油売っていない罠
0455デフォルトの名無しさん05/02/10 13:35:52
>>454
ダメだよ、そんな元も子もないこと言ったら。
0456デフォルトの名無しさん05/02/10 13:38:18
　　　　_、_　　　　　　プログラミングの友　マクロン
　 　（　,_ﾉ` ） 　 　　n　　　　＿＿
　￣　　 　 ＼　 　 （ E）　／ ＿／|
　ﾌ 　　　 /ヽ ヽ_／／　　|◎±|／　MACRON POWER

http://www.casing.com.tw/
0457デフォルトの名無しさん05/02/10 14:11:59
>>451
アルゴリズムだけを追ってる立場では、良いコードとは速くて効率の良いコードなわけだが。
0458デフォルトの名無しさん05/02/10 23:57:31
良いコードとはアセンブラで書かれた最速のコードである。
ただし最適化しすぎると他人には解読不能。
0459デフォルトの名無しさん05/02/11 00:01:06
ハードで実装したほうが良くないか？
0460デフォルトの名無しさん05/02/11 00:06:42
アルゴリズムだけを追っている立場では、良いコードとはアルゴリズムを説明しやすいコードである。
0461デフォルトの名無しさん05/02/15 15:27:14
「良いコード」の定義次第になってきてんのか。やっかいだなぁ。
アプリケーションを作る立場で考えると
一般的にはモジュールを細分化するほど保守効率が上がる。
（ただし数が増えるので、モジュールの管理効率は下がる）。
逆に細分化をやめて、中身を最適化すれば実行時効率が上がる。

そんなことから俺の思う「良いコード」は基本的には細分化されていて、
ここが変えたい（実行時効率が欲しいって要求かもしれないし、仕様変更かもしれない。）
って時に簡単に差し替えられるようなコード（設計？）だろうか。
差し替えできないコードなんてやってられん。
0462デフォルトの名無しさん05/02/16 18:03:51
>>461
あるかどうか判らない改造のためにプラグイン的な構造にするのは無駄｡
都度リファクタリング汁｡
0463デフォルトの名無しさん05/02/16 18:21:30
2chでは「リファクタリング汁」が流行ってるけど
ほんとにそんなにちょくちょくモジュールに手を入れてるの？
で、リファクタリングの前提となるUnitTest用のテストケースを完備してるの？
0464デフォルトの名無しさん05/02/16 19:20:08
対象とするプログラムをある程度仮定しないと議論しようがないと思うのだが・・・。

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

どれも性格が異なるでしょ。
0465デフォルトの名無しさん05/02/16 20:55:06
>>463
それを言えるのは研究的、または先進的な職場か
極少人数で開発しているからのような気がする。
知らぬ間にリファクタリングでコードがガラッと変わってたりしたら怖すぎる。
UnitTestは単体作成者でも使えるから手は出しやすいよね。
0466デフォルトの名無しさん05/02/16 21:23:31
詰めviｽｷｰな人はﾘﾌｧｸﾀﾘﾝｸﾞ奨励派
0467デフォルトの名無しさん05/02/16 21:24:48
>>465
> 知らぬ間にリファクタリングでコードがガラッと変わってたりしたら怖すぎる。
OOPでコード管理していればそんなこと思えない
0468デフォルトの名無しさん05/02/16 21:57:13
>>467
この間半月かけて解析したのに、また一からやり直しかよ。
0469デフォルトの名無しさん05/02/16 23:52:00
>>463
将来の改造のためにモジュール化を推し進めるよりその努力をUnitTest作る方に向けるべき。
0470デフォルトの名無しさん05/02/16 23:53:50
>>469
それどういう環境で実践してるの？
個人の趣味開発じゃないよね。
0471デフォルトの名無しさん05/02/17 02:15:48
>>470
業務系システムのサブシステムを5人程度で。
コード行数は10万行ぐらい。
言語はVB6（ｗ
0472デフォルトの名無しさん05/02/17 10:59:58
うむむ・・・。ご愁傷様ﾃﾞｽ
0473デフォルトの名無しさん05/02/17 11:40:51
「本当のリファクタリング」なら書き方は変わっても
内容は変わらないのだから問題ないはずだけどね。
0474デフォルトの名無しさん05/02/17 12:22:53
いやだから、何に注力すべきかという問題で。
469の開発環境が「保守性より信頼性を要求されている」という事では？。
どっちも定量化の困難な品質特性だから、「ここまでやったから（充分で）今度はこっち」
という匙加減が出来ないのかも
0475デフォルトの名無しさん05/02/17 13:00:15
リファクタリングの誤用
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?RefactoringMalapropism
| リファクタリング中に2,3日システムが動かなくなっちゃってーなどと言ってる奴がいたら、んなもんリファクタリングじゃあなーいと言ってやれ。

信頼性確保のための UnitTest ね。
リファクタリングには必須。まぁ、理念だけど。
0476デフォルトの名無しさん05/02/17 14:45:26
何かしらソースに変更加えたら、それが正しいか検証するのは大変だ。
リファクタリングソフトが完全なら良いのだが、誰も保証してない
0477デフォルトの名無しさん05/02/17 16:49:24
>>476
そのためのUnitTestって話なんだろうけどね。
0478デフォルトの名無しさん05/02/17 17:18:46
>>474
哲学になってくるからねぇ。

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

どっちにしてもUnitTestは外したくないけど。
0479デフォルトの名無しさん05/02/17 17:42:44
うむ。この中にリファクタリングを理解していない人がいるようだ。
参考文献をどうぞ。
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
0480デフォルトの名無しさん05/02/17 21:53:29
UnitTestなんてウゼーとか言う奴に「じゃあ単体テストは一度しかやらないの？」って尋ねると
不思議そうな顔するな（ｗ
GUIならともかく、ビジネスロジックの反復テストを手動でやるコストをどう考えてるんだろう？
0481デフォルトの名無しさん05/02/17 21:58:25
>>474
保守性と信頼性がトレードオフな関係だと思ってる？
UnitTestちゃんと書いてれば保守性も後から付いてくるんだけど。
0482デフォルトの名無しさん05/02/17 22:00:58
信頼性とはデータ隠蔽の方だと思うので保守性と信頼性とが共存できるとは限らない
0483デフォルトの名無しさん05/02/17 22:26:25
UnitTestって良く分かんないんだけど、普通の単体テストとassertでの事前・事後条件の
チェックと違ってどういうメリットがあるの？教えてエロイ人！
0484デフォルトの名無しさん05/02/17 22:29:37
UnitTestって良く分かんないんだけど､普通の単体ﾃｽﾄの自動化というﾒﾘｯﾄがある?教えてｴﾛｲ人!
048548305/02/17 22:37:10
>>484
GUI部分以外で手動のテストってあるのか？
048648405/02/17 22:51:16
>>485
ない。
GUI部分も自動のﾃｽﾄってあるよ。
教えたとおりにﾏｳｽｶｰｿﾙがﾂﾂｰと勝手に動いてやってくれるやつ｡
製品名忘れました｡
0487デフォルトの名無しさん05/02/18 00:02:01
UnitTestはUnitTestでしかないからねぇ。
テストに通ったからといって信頼性の高いシステムになるわけでもないし、
リファクタリングしたからといって改修しやすいコードになるわけでもない。
0488デフォルトの名無しさん05/02/18 00:57:43
>>487
え？
テストが通ってるのに信頼性が低いのって単にテスト項目が不適切なだけじゃん。
リファクタリング出来たのに改修困難って何のためのリファクタリング？
0489デフォルトの名無しさん05/02/18 01:05:02
UnitTestでテストできる範囲なんてたかが知れてるし、
リファクタリングの方向性に合った改修が入ることなんて稀。

ＳＥ「え？あそこの条件変えればいいだけじゃないの？」
ＰＧ「いやぁ、前回のコードからがさっと変えちゃったんで、
　　　ちょっとすぐには回答できないっす」
0490デフォルトの名無しさん05/02/18 01:16:02
>>489
> UnitTestでテストできる範囲なんてたかが知れてる

そうか？
それはテストファーストで設計してないからそう思うだけじゃないのか？
UnitTestでテスト困難なコードは手動でやっても困難だと思うがな。
0491デフォルトの名無しさん05/02/18 01:28:14
テストファーストだろうが、あとで手動でテストしようが、
それは一連のテストに通ったということしか保障しない。

＞ UnitTestでテスト困難なコードは手動でやっても困難だと思うがな。
そういう領域でいかに良質なコードを書くかが問題なわけで。
0492デフォルトの名無しさん05/02/18 01:34:29
結合ﾃｽﾄ、機能ﾃｽﾄ、高負荷ﾃｽﾄとか後段階のﾃｽﾄを含めたﾃｽﾄ計画全体に対するﾕﾆｯﾄﾃｽﾄのしめる割合がたいしたことないと言いたいのでは？
0493デフォルトの名無しさん05/02/18 09:31:23
使わないよりもコードの品質を高める効果はあるよね。
デグレードを防いでくれる部分もあるし。
それに全部勝手にやってくれるからテスト抜けみたいなこともない。
あと手動だと、あっちを立てればこっちが立たずって時に苦しい。

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

＞＞ UnitTestでテスト困難なコードは手動でやっても困難だと思うがな。
＞そういう領域でいかに良質なコードを書くかが問題なわけで。
そういう部分にのみ集中するための時間を作る道具として利用したら
いいと思う。道具は特性を見極めて使ったら良いのではないかな。
0494デフォルトの名無しさん05/02/19 04:20:14
みなさんどんな品質のコード書いてますか？
0495デフォルトの名無しさん05/02/19 04:54:54
>>494
最低品質のｺｰﾄﾞ書いてます｡
その代わり､ｺｰﾃﾞｨﾝｸﾞ時間は最短｡
それでﾊﾞｸﾞ･ﾚﾎﾟｰﾄたくさん｡
でも直ちに最低品質のｺｰﾄﾞで修正｡
最初に戻る｡
0496デフォルトの名無しさん05/02/19 12:01:30
>>495
素早いリリースを実践していらっしゃるのですね。
0497デフォルトの名無しさん05/02/19 13:36:51
>>495
急がば回れ
0498デフォルトの名無しさん05/02/19 14:00:29
素早いﾘﾘｰｽってなんじゃらほい｡

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

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

ﾊﾞｸﾞ曲線で残りﾊﾞｸﾞ予想件数が0.5件未満になる時期を出すと欝になるね｡
0499デフォルトの名無しさん05/02/20 09:15:59
>>498
ヘタクソな奴の典型。
0500デフォルトの名無しさん05/02/20 09:28:39
それ以前に仕事してると言わんよ。回りの血圧上げるためにいるようなもんだ。
0501デフォルトの名無しさん05/02/20 11:17:05
Wikiみれねーぞ
0502デフォルトの名無しさん05/02/20 12:22:03
>>499
ﾍﾀｸｿな奴の典型ですよ｡

>>500
仕事していませんよ｡
私の血圧下げるためにやるようなもんだ｡
0503デフォルトの名無しさん05/02/21 00:59:35
>>498
ワロタ。パーセプトロンかよ。
0504デフォルトの名無しさん05/02/21 01:14:49
お陰さまで最高血圧が90まで下がりました。
0505デフォルトの名無しさん05/02/21 01:16:04
とりあえず、テスト困難なコードは設計がまずいことが多い。
中でも、テスト困難になりがちな副作用が多いコードは設計を見直すよう心がけている。
0506デフォルトの名無しさん05/02/21 01:21:46
>>504
普段から最高血圧90付近ですが、なにか。
0507デフォルトの名無しさん05/02/22 19:16:09
一日目。神懸かりモードで能力の限界に挑戦しながら書き上げる。
二日目。ゆっくり整理・リファインしつつコミット。
三日目。まったり。
最初に戻る。
0508デフォルトの名無しさん05/02/22 20:37:40
>>503
ﾜﾛｰﾃつかぁさい｡ﾊﾟｰｾﾌﾟﾄﾛﾝでござい｡
0509デフォルトの名無しさん05/02/22 20:40:12
>>506
低血圧ぎりぎり正常｡
0510デフォルトの名無しさん05/02/22 20:46:01
ここは悪いコードを書くためのノウハウをも蓄積するｽﾚでっか？
0511デフォルトの名無しさん05/02/22 21:00:16
>>510
何が悪いかを知れば、何が良いかを知ることにつながる
0512デフォルトの名無しさん05/02/24 21:54:10
>>1
朝食食べるといいらしいぞ
0513デフォルトの名無しさん05/02/25 01:32:12
このあとトイレに流されますか？
0514デフォルトの名無しさん05/02/25 20:38:36
DHAのサプリメントを摂る

言っちゃった・・・・
0515デフォルトの名無しさん05/03/05 00:24:53
>>514
正直、ブルーベリーも重要だと思う。
0516デフォルトの名無しさん05/03/12 00:26:06
フラグを二回立てたくなったときの裏技
BOOL flag = TRUE * 2;
0517デフォルトの名無しさん05/03/12 12:30:38
「フラグ使わんと書けないのか」
というのは煽りになるのかのぅ
0518デフォルトの名無しさん05/03/12 18:05:39
同じ変数の使いまわしなんてもってのほかだし
0519デフォルトの名無しさん2005/05/09(月) 22:04:57
皆さんこんにちは。
このスレは終了ですか？

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

Exceptionを使わないと仮定すると、
エラー処理をしたい関数の戻り値は
処理結果ということになると思います。
そうすると、少しの処理でもコードが長くなってしまいます。
このあたりをうまいこと見やすくするコツや参考になるソース等は
ありますでしょうか？
0520デフォルトの名無しさん2005/05/09(月) 22:13:34
http://n219079028097.netvigator.com/
おｋｗｗｗｗっっうぇうぇｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗ
おｋｗｗｗうぇｗｗｗｗおｋｗｗｗ
おｋｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
0521デフォルトの名無しさん2005/05/09(月) 22:24:37
>>519
無い
05225192005/05/09(月) 22:58:22
マジですか。
そんな殺生な！
0523デフォルトの名無しさん2005/05/09(月) 23:44:29
>>519
ちょっとまて。
例外を使わない場合、戻り値はエラー判定用の値になるんじゃないか？
bool DoSomething( T& result ); // こんなかんじで
0524デフォルトの名無しさん2005/05/09(月) 23:46:43
もしくは、大域変数を使うか
0525デフォルトの名無しさん2005/05/09(月) 23:58:21
>>519
例外が使えない場合は、gotoを使ってエラー処理を本処理から分離する事で、本処理が
エラー処理に埋もれる事を阻止する。
05265252005/05/09(月) 23:58:57
例えば、このコードは、、、

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;
}
05275252005/05/10(火) 00:00:17
//ごめん間違えた
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;
}
05285232005/05/10(火) 00:00:38
レスありがとう。

>>523

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

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

>> 524

なるほど。getLastError()といった処理を毎回行うことになるのでしょうか？
05295252005/05/10(火) 00:02:57
//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;
0530デフォルトの名無しさん2005/05/10(火) 00:02:58
>>528は519でした。間違えました。
05315192005/05/10(火) 00:10:08
>>525さん
レスありがとうございます。
大変参考になりました。

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

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

goto文って結構つかうもんですか？
0532デフォルトの名無しさん2005/05/10(火) 00:36:07
>>531
例外を使わない理由が無いなら、使っておけ。
0533デフォルトの名無しさん2005/05/10(火) 18:17:27
>>531
周りが例外を使っていないのなら自分から推し進めていけ。

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


でも俺はそういうときinline関数にしてreturnを使うようにする。
あくまでも俺の場合。他人がこういう場面でgoto使っても否定はしない。
0534デフォルトの名無しさん2005/05/10(火) 18:27:44
> 実は、例外を使わない明確な理由はないのです。
> 周りであまり使っている人がいなかったので、
> C++ではあまり使わないのかなと思ってのことです。
……
0535デフォルトの名無しさん2005/05/20(金) 12:23:53
うーむ、Exceptionの有用さくらい教科書に書いてあると思うが・・・
よっぽど特殊な環境じゃない限り、Exceptionが実装されている言語では
使え。特にライブラリっぽいものを作る段階になって階層構造ができてくると
便利。
0536デフォルトの名無しさん2005/05/23(月) 02:26:14
ところで、Ｃ＋＋とかでオブジェクトを作るときに2 phases construction/destructionっていう
方法があるんですけど、どれくらい使ってる人います？

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

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

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

ただ2段階にしただけなんだけど、これだけで結構硬い構造になると思う。
0537デフォルトの名無しさん2005/05/23(月) 02:39:40
>>536
俺は忌み嫌ってるね。
Initialize() されてないという状態が無駄に存在するのが嫌。
0538デフォルトの名無しさん2005/05/23(月) 03:24:06
私はまず「どこから来たのかわからないオブジェクトを再利用」するのが激しく嫌。
素直に毎回コンストラクト・デストラクトしたい。
0539デフォルトの名無しさん2005/05/23(月) 09:00:33
>536って、例えばMFCもそうだけど無駄にノウハウが必要になるから却ってバグの温床になりそう。
0540デフォルトの名無しさん2005/05/24(火) 00:12:55
>>536
無理せずにGCの有る処理系使えよ。
0541デフォルトの名無しさん2005/05/24(火) 01:16:07
>>536
その方法を使う利点ってどんなものがあるんだろう？？
とりあえず思い付く局面としては、

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

ってところだけど。

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

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

例えばゲーム作るときでもキーイベントをリスナーする親玉クラスをつくったとして
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();
}
}

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

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

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

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

>>540
こないだから遊びでJ2MEを触っていますが、じつは似たような話が出てきてるんです。
つまりメモリが限られてるので、明示的にDisposeというメソッドをつけて、
メンバーにnullを割り当てろ、と。つまりＧＣに教えてやることでゴミ掃除を早める
という話でした。ほんとかな。多分、SWTとかも明示的にメモリ開放（ＧＣを呼ぶ）
することでＧＵＩの処理を早めてるんじゃないのかな。想像だけど。
05445362005/05/24(火) 02:15:50
上の例なぜかポインタにしちゃったけど普通に作成するの間違いです
FireBall m_fire;
//...
m_fire.Create();

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

不完全な状態はできるだけ外に出ないほうが望ましいけど、なければいけないこともある。
0546デフォルトの名無しさん2005/05/24(火) 08:54:42
このスレらしくなって参りました
0547デフォルトの名無しさん2005/05/24(火) 09:58:35
>>542
普通にポインタでいいじゃないか。
std::auto_ptr<FileBall> m_fire;
m_fire.reset(new FireBall(m_mario.GetX(), m_mario.GetY()));
m_fire.reset();

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

今のところ、やっぱりいいとこ無しだな。
0548デフォルトの名無しさん2005/05/24(火) 11:21:21
方法を利用する理由は異なるかもしれないのですが、
2 phases construction/destruction
（って呼ばれていたんですね。知りませんでした。）
的な方法を実際に使用したことがあります。

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

当初は、ポインタの配列を動的に確保した後にnewを繰り返していたのですが、
大量にオブジェクトを生成することが要求されるようになるにつれて、
メモリの管理領域のオーバヘッドが軽視できないほど大きくなってしまったので、
（特化したアロケータを作成するスキルも当初は無く、）
苦肉の策として導入していました。
0549デフォルトの名無しさん2005/06/26(日) 08:01:13
俺は
do{
...
} while(expression);
は
for(;expression;)
{
...
}
と書くけど、どう？
0550デフォルトの名無しさん2005/06/26(日) 11:45:20
>>549
一回は突入することが判っている場合、
突入してからでないとexpressionが確定できない場合、
私はdo - whileを使う。
0551デフォルトの名無しさん2005/06/26(日) 11:55:30
>>549
動作が変わってるぞ。気をつけろ。
for(;exp;){} は while(exp) {} の改悪にしか思えん。
0552デフォルトの名無しさん2005/06/26(日) 16:23:37
>>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
0553うん子です2005/06/26(日) 19:58:06
組み込みなど、容量とサイズに制約がある場合、
効率の良いプログラムを書くには、どのような点に注意するべきでしょうか？
0554デフォルトの名無しさん2005/06/26(日) 20:05:18
書かないこと
0555デフォルトの名無しさん2005/06/26(日) 20:11:19
>>553
容量とサイズではなく、容量／サイズと速度だろ。
言語も記述せずにその質問に答えろと？
アセンブリコードに落ちたときどうなるかを理解できる様になれば
その質問には自分で答えられるようになる
0556デフォルトの名無しさん2005/06/26(日) 20:22:04
２フェーズコンストラクションというと、SymbianOSのC/C++ライブラリが使っていたな。
あれは >>536 のようなものではなくて、よくは憶えていないけど、確かコンストラクタ
で例外ジャンプをする弊害(?)対策だったような。
0557うん子でございます2005/06/26(日) 21:24:59
ごめんなさい；；
組み込みなど、容量と時間に制約がある場合、
効率の良いプログラムを書くには、どのような点に注意するべきでしょうか？
C言語です。
0558デフォルトの名無しさん2005/06/26(日) 21:28:52
>>557
時間 : メモリアロケーションを頻繁に行わない。
容量 : コンテキストで必要なときだけ変数用のメモリをとる。

両者は背反する。
0559デフォルトの名無しさん2005/06/26(日) 22:12:49
自前のカスタムアロケータを使う

で両者はそれなりに満たされるんじゃないの？
0560デフォルトの名無しさん2005/06/26(日) 22:17:38
いや、それは本質的には何も変わっていない。

まぁ、妥協して適当なものにするってのはそのとおりだが、
妥協が必要なのは背反しているゆえなわけで。
0561デフォルトの名無しさん2005/06/26(日) 22:19:29
そういう曖昧論はつまらん
0562デフォルトの名無しさん2005/06/26(日) 22:52:07
>>557

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

日本の、携帯機器や家電製品の開発現場にも、ノウハウの蓄積が
ありそうです。
0563デフォルトの名無しさん2005/06/26(日) 22:56:50
メモリキツキツの環境では基本的にmallocは使わない
0564デフォルトの名無しさん2005/10/22(土) 23:59:39
>>515
知ってるか、結局アントシアニンが効果あるので、
赤シソだとかカシスでも良いわけ。
カシスのほうが効率的に摂取できるんだぜ。
0565デフォルトの名無しさん2005/10/23(日) 00:00:22
うえっｗｗｗｗｗｗｗ
低脳発言スレと間違えたｗｗｗｗｗｗｗ
0566デフォルトの名無しさん2005/10/23(日) 01:03:11
>組み込みなど、容量と時間に制約がある場合、効率の良いプログラムを書くには、

効率って何?
開発時間?
実行時間?
メモリ使用量?
0567デフォルトの名無しさん2005/10/23(日) 03:51:23
>>548
裏読みとかに対応させる為に俺はそうしてる。
メンバの初期値とかはなるべく定義に埋め込む。
■ このスレッドは過去ログ倉庫に格納されています