5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

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


2 :1001:04/12/05 14:50:47
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

3 :1:04/12/05 14:53:34
とりあえず、wiki立てたいので、いいWikiと、いいサイトと、いい名前、教えてください。


4 :一星 ◆Cppn/.YI3. :04/12/05 14:55:02
教えてほしいだけなら質問スレで質問してくれよ。

5 :デフォルトの名無しさん:04/12/05 15:00:08
打鍵百回おのずから通づる。打つべし打つべし。

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


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

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


8 :デフォルトの名無しさん:04/12/05 15:16:00
キーボードに向かう前にチンコをいじって心を落ち着かせるべし。

9 :デフォルトの名無しさん:04/12/05 15:27:13
【すれ立てるまでもない質問はここで 第62刷】
http://pc5.2ch.net/test/read.cgi/tech/1100963189/

10 :デフォルトの名無しさん:04/12/05 15:34:51
コーディング規約はこのへんがまとまってるんじゃないか?

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


11 :デフォルトの名無しさん:04/12/05 15:50:49
>>10
iine

12 :1:04/12/05 19:45:03
http://www.hondarer-soft.com/cx/pukiwiki/pukiwiki.php?Link%2FProgram#content_1_17

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


13 :デフォルトの名無しさん:04/12/05 20:51:37
この↓本では力不足ですか?

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

14 :デフォルトの名無しさん:04/12/05 21:02:00
バグが無いのはもちろんのこと、
堅牢性、保守性、拡張性、可読性、etc.
を備えたものが良いコード。
見栄えは個人の好みもあるから、あまりうるさく言うな。

15 :デフォルトの名無しさん:04/12/05 21:16:08
とりあえず>>1の「良いコード」の定義を教えてくれ

16 :デフォルトの名無しさん:04/12/05 22:06:55
>>15
それを考えていきたい。

17 :デフォルトの名無しさん:04/12/06 00:03:37
>>1
なんかたたき台にするサンプルコードあげろよ。
短いのでもいいからさ。
具体的なコードがあった方が話が早い。

18 :デフォルトの名無しさん:04/12/06 01:25:26
実際には、悪いコードを書く奴を排除するノウハウの方が重要なのだが。

19 :デフォルトの名無しさん:04/12/06 07:50:14
>>18
例えば13あたりがその対象じゃないか?
URLが
http://www.amazon.co.jp/exec/obidos/ASIN/4774121738/
までで十分だから。

20 :デフォルトの名無しさん:04/12/06 11:15:43
18がうまいこと言った。

21 :1:04/12/06 21:32:50
たたき台サンプルコード
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文はこうだとか条件によってかわると、もう全部あわせるのは不可能


22 :1:04/12/06 21:37:22
たたき台サンプルコード
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文はこうだとか条件によってかわると、もう全部あわせるのは不可能


23 :1:04/12/06 21:39:15
うわ、失敗

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

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

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


24 :1:04/12/06 22:12:19
◆条件って書いたのは、条件を考えるにあたっての項目だな。


25 :1:04/12/06 22:32:19
Wiki立てました。構造的に問題あるので構造自体も好きに変えてください。

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


26 :デフォルトの名無しさん:04/12/06 22:38:59
>>21
おれがスペースを入れるのは
1. カンマ','のあと
2. if while forのかっこの左右
3. 2項演算子の左右

27 :デフォルトの名無しさん:04/12/06 22:44:59
>>25
がんばってますね。応援age

28 :1:04/12/07 00:17:21
>>25
応援どうもです。
なんでもいいんでwikiに書き込んでください


29 :デフォルトの名無しさん:04/12/07 00:29:07
おいしいラーメンの作り方を書いてもいいですか?

30 :1:04/12/07 01:42:52
>>29
それは、、、
訂正
いい方向性に向かうように、好きに書き込んでください。


31 :デフォルトの名無しさん:04/12/07 02:30:34
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

32 :デフォルトの名無しさん:04/12/07 03:02:37
良いコードを書くためのノウハウその1。
括弧の位置とかインデントとかそんなレベルにこだわらないこと。

33 :デフォルトの名無しさん:04/12/07 03:12:42

ほれ。
http://himatsubu.fc2web.com/22/fir/ かなりシュールな心理テストでオモロイ。



34 :デフォルトの名無しさん:04/12/07 03:15:14
>>33
Q3 あげまんという言葉は、いやらしい事だと思っていた。
(実は今もそう思っていた)

YES

NO

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



あげまんってあげまんこの略だよな?マジデマジデ

35 :デフォルトの名無しさん:04/12/07 03:24:26
動くコードが書けない僕でも、良いコードは書けますか

36 :1:04/12/07 03:59:38
頭悪いので、TexのWikiからのコピペを修正したものを張りました。
Wikiそのままのコピペで本をだすことはしないと約束します。


37 :デフォルトの名無しさん:04/12/07 06:19:06
スペースかっこ、著作権、Wikiとか
話がどんどん本題からずれていくのがおもしろい。

38 :デフォルトの名無しさん:04/12/07 09:08:42
インデントはタブがいいの?
それともスペース?

39 :1:04/12/07 14:29:01
Wiki書き換えてくれた人がいた。
ありがとうございます。

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



40 :1:04/12/07 14:29:32
>>38
俺も教えて欲しい。

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

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

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


41 :デフォルトの名無しさん:04/12/07 23:20:19
>>22
どうでもいいけど、何で f の次が g になってるの?
10に訂正してくれ。

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

42 :41:04/12/07 23:22:40
うわっ。
半角スペース連続投稿で消された・・・・・
逝ってくる。

43 :デフォルトの名無しさん:04/12/07 23:30:46
消されたわけではないが。

44 :デフォルトの名無しさん:04/12/07 23:45:49
a(ONE, ONE);


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

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

46 :45:04/12/08 01:19:04
ただ否定するだけだとさすがにアレなので、
コーディング技術を上達させるための有効な手段の一つを紹介します。
というのは、正しい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が書けることはまた別ですねー

47 :デフォルトの名無しさん:04/12/08 01:20:26
時間だよ。とにかく時間。
時間さえあれば並みのプログラマでもマシなものが書ける。
時間が無ければ凄腕プログラマでもHACKせざるを得ない。
余裕が無いが短すぎもしない期間で寄り道せずに最適解を導けるような知恵袋はあってもいいかもな。

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

48 :デフォルトの名無しさん:04/12/08 01:30:40
>>46
そんなのW3C勧告読めばいいだけの話じゃん。
良いコードを書く能力というよりかCで未定義じゃないコードを書く能力に近いというか・・。
最低限レベル?

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

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

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

50 :デフォルトの名無しさん:04/12/08 01:56:38
結局は文脈を読み取れる国語力が必要って事?

51 :デフォルトの名無しさん:04/12/08 01:59:22
いまどきあんな時代遅れのHTMLを意味に合わせて使うなんてナンセンスだよ。
UAが正しく理解できればそれで十分。
俺は文章の論理構造はXMLで書いて、XSLTで変換してる。
変換した先がどうなってようが(それでも一応validだけど)知ったこっちゃ無い。

52 :デフォルトの名無しさん:04/12/08 02:05:05
>>45
自分なりの哲学なんて邪魔なだけだ。
まずは自分を捨てるところから始めろ。

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

54 :デフォルトの名無しさん:04/12/08 02:15:46
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

55 :デフォルトの名無しさん:04/12/08 02:31:39
どうせ書くならwikiに書き込めよ。このチキン野郎

56 :デフォルトの名無しさん:04/12/08 02:53:50
>>40
>HTMLで記述する場合はタブ幅を指定できない。8文字に固定される。

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

57 :デフォルトの名無しさん:04/12/08 04:24:12
興味アル方メールください

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


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


勤務地
東京都渋谷区


58 :デフォルトの名無しさん:04/12/08 14:01:03
ここで募集しても糞しか集まらないよ

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


60 :1:04/12/08 22:56:10
>>40
そうですね。IEだと文字のサイズ変えても固定ですしね。

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

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

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


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


62 :デフォルトの名無しさん:04/12/09 09:36:45
>>60
Python はインデント変えると動かなくなるんだよ


63 :デフォルトの名無しさん:04/12/09 11:18:24
>>61
おれもプログラミングを始めたころに読んだけど、読みやすかった。

64 :デフォルトの名無しさん:04/12/10 01:04:01
>>47さんに賛成です。

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



65 :デフォルトの名無しさん:04/12/10 11:25:08
http://pc5.2ch.net/test/read.cgi/tech/1044457085/

66 :デフォルトの名無しさん:04/12/11 05:00:56
>良いコードを書くためのノウハウ

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

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

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


67 :デフォルトの名無しさん:04/12/11 05:28:13
 達人のソースコード読んだあと、ふと、自分の書いた
コードに目をやると、なんでこんなにごちゃごちゃしてるんやろ、と思う。

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

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

がんばろ。


68 :デフォルトの名無しさん:04/12/11 05:47:16
 とはいっても、良いとはいかずとも、バグを見つけ出し
やすいコードを書くノウハウはあると思います。

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

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

69 :デフォルトの名無しさん:04/12/11 07:54:34
Effective C++ とか読むといいとおもう
今更だけどEffectiv C も書いてほしいなあ…

70 :デフォルトの名無しさん:04/12/11 11:17:23
Effective〜っていうプログラミング指南書は全然役に立たない俗本。

71 :デフォルトの名無しさん:04/12/11 11:21:00
>>70
Effectiveってつく本を何冊読んだのか知りたい。

72 :デフォルトの名無しさん:04/12/11 11:29:21
>>70
少なくともEffective C++は読んだんだろうな?

73 :デフォルトの名無しさん:04/12/11 12:18:04
「関数内関数」使っちゃったw
int func () {
 struct local {
  static int func() { return 0; }
 };
 return local::func();
}

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

74 :デフォルトの名無しさん:04/12/11 13:02:16
>>72
当然でしょ。
Effectiveのつく代表的な著作じゃない。

75 :デフォルトの名無しさん:04/12/11 14:03:06
>>74
それを「全然役に立たない」と断じる根拠を知りたい。

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

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

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

78 :デフォルトの名無しさん:04/12/11 14:42:06
>>76
対称読者を間違えてる。
本来経験から得る知識を金払うだけで得れるんだからすばらしいじゃないか

79 :デフォルトの名無しさん:04/12/11 14:42:07
>>77
そのあたりのことは全部見越して、>>70の発言なんじゃないか。
ようは、なんの脈絡もなく、「おれはすごい」って自慢できるきっかけを見付けたから
それに食いついただけでしょ。

80 :デフォルトの名無しさん:04/12/11 14:42:29
できるだけコード量が少なくなるようにして、
メソッドの数をできるだけ少なくして
クラスはできるだけ作らないようにして
シンプル命でリファクタリングしつづけるだけ。

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

81 :デフォルトの名無しさん:04/12/11 14:48:50
結局、メンタルの健康が一番大切なのかもしれん
己を知る
体を動かす
寝る
いいもの喰う

それでいいじゃん

82 :マイク ◆yrBrqfF1Ew :04/12/11 14:50:22
まあ2chに入り浸るようなのじゃいくらノウハウを蓄積したところで
変わりはしないんだがな。

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

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

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

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

84 :デフォルトの名無しさん:04/12/11 15:01:17
関数とメソッドってどう違うの
クラスのメンバ関数=メソッドでOK?

85 :デフォルトの名無しさん:04/12/11 15:02:53
>>79
ひねくれているなぁ。

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

87 :デフォルトの名無しさん:04/12/11 15:19:43
別に、メソッドは短くする意味がなければ長いままのほうがいいよ。
なんでもかんでも短ければいいっていうもんじゃない。メソッド増えるのキモいし。
長いメソッドのときは、まとまった処理ごとに適切なコメント入れればいいと思うね。
メソッドを定義したのと同じ表現力が得られる。

88 :デフォルトの名無しさん:04/12/11 15:25:37
>>87
そのコメントをメソッド名にして切り出すべきだと思うんだけどね

89 :デフォルトの名無しさん:04/12/11 15:31:03
>まとまった処理ごとに適切なコメント入れればいいと思う

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

90 :デフォルトの名無しさん:04/12/11 15:31:40
一つのメソッドは30秒以内に理解できるものでないといけない

91 :デフォルトの名無しさん:04/12/11 15:32:13
>>90
読む奴が無能ではどうしようも無い

92 :デフォルトの名無しさん:04/12/11 15:32:43
>>88

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

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

93 :デフォルトの名無しさん:04/12/11 15:34:21
>一つのメソッドからしか呼ばれないメソッド

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

94 :デフォルトの名無しさん:04/12/11 15:35:08
>>92
構造化プログラミングを勉強しなおせ。もしくはCOBOLでも使ってろ。

95 :デフォルトの名無しさん:04/12/11 15:41:55
メソッドを無理やり短くするほうがいかんと思うけどね
短くなって複雑になるくらいなら長いままにしておいたほうがマシ
いい方法が見つかった時に短くする。

96 :デフォルトの名無しさん:04/12/11 15:51:07
複数の条件判定の上で処理する場合、出来るだけネストを深くしないように
ループの場合は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;

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

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

97 :デフォルトの名無しさん:04/12/11 15:51:23
短くして複雑になるのは短くするやつが低脳なだけだろ

98 :デフォルトの名無しさん:04/12/11 15:52:13
条件を適当に付け加えたので括弧を入れ忘れました
-    if (!(hoge.expr2 == "hogestr")
+    if (!(hoge.expr2 == "hogestr"))

99 :デフォルトの名無しさん:04/12/11 15:52:33
>>96
脊髄反射でレス
コメントが必要だと思ったらその時点で駄目なコードだと思え。

100 :デフォルトの名無しさん:04/12/11 15:55:52
>>99
そりゃ言いすぎだ。趣味でやってるなら許すが。

101 :デフォルトの名無しさん:04/12/11 15:57:00
>>99
そういう通念をヘタに浸透させると、ダメなコードでもコメント入れない奴が
量産されるから、公の場では言わないように。

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

103 :デフォルトの名無しさん:04/12/11 16:01:21
-for (SmplCls hoge in arg) {
+foreach (SmplCls hoge in arg) {

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

104 :デフォルトの名無しさん:04/12/11 16:07:43
時間がたつにつれてコメントと実コードの間にずれが生じてくる。
コメントは間違っててもテストに引っかからないしエラーにもならないからね。

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

もし入れるならなら

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

105 :デフォルトの名無しさん:04/12/11 16:14:44
ネスト回避にcontinueやreturnでふるい落とすのは良いスタイルなのかというのを
聞きたかったんですが・・・。

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

106 :デフォルトの名無しさん:04/12/11 16:24:26
>>105
頭の方で条件に合致しない場合はreturnで落とすスタイルは広く使用されてる。
名前も付いてるけど忘れた。

107 :デフォルトの名無しさん:04/12/12 00:49:57
いつもコメントの書き方にこまるです。
自分、強迫神経症的な部分があるから、
とことん書かないと気がすまない。

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

108 :デフォルトの名無しさん:04/12/12 00:59:19
>>107
標準はないけれど、JavaDoc風に書くとわりと幸せになれるかも。
例えば、DoxygenだとJavaDoc風の書き方に対応しているからソースのコメントを元に
ドキュメントが生成できたりします。

109 :107:04/12/12 01:05:21
あーなるほど、そういえばPerlにはPodだっけ?なんて書き方がありますな。
(ソースのコメントを元にドキュメント生成できる)

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

110 :デフォルトの名無しさん:04/12/12 13:53:51
Doxygen

111 :デフォルトの名無しさん:04/12/12 16:47:02
RD

112 :デフォルトの名無しさん:04/12/16 04:00:02
>>109
PEAR は PHPDoc を使うことが義務付けられている。
Doxygen も PHP に対応しているし。

113 :デフォルトの名無しさん:04/12/17 02:10:23
>>96
そういうやり方を嫌う人は多いな。
聞いてみると、仕様をそのままコードに落とした方が分かりやすい
ということらしい。
ネストが深くなるのを嫌って関数の頭でふるいにかける形でコード書いたら
SEから「俺が書いた仕様と違う」と拒否されたこともある。

114 :デフォルトの名無しさん:04/12/17 02:13:31
>SEから「俺が書いた仕様と違う」

アフォです
直訳と意訳は違うんでつ

115 :デフォルトの名無しさん:04/12/17 02:23:43
アホだな

116 :デフォルトの名無しさん:04/12/17 08:13:04
正しく動くコード
正しいコード
良いコード
これらは全て違う


117 :デフォルトの名無しさん:04/12/17 08:59:57
良いコードを書くためには少しの酒と旨いつまみが必要だ

118 :デフォルトの名無しさん:04/12/17 10:49:39
>>113
コードレベルのフローチャートみたいなのが、仕様書に含まれてるところなのだろうか。

119 :デフォルトの名無しさん:04/12/17 19:20:22
良いコード…、俺がコーディングしなきゃOK。

120 :デフォルトの名無しさん:04/12/17 20:55:27
コメントって>>96みたいな「何をしているのか」を書くものなのかな?
私は「何をしたいのか」をコメントとして書いてるけど・・・。
他の方々はどーしてます?

121 :デフォルトの名無しさん:04/12/17 22:33:20
>>120
「何をしたいのか」を書く方がいい。

122 :デフォルトの名無しさん:04/12/17 23:18:45
なぜこの方法を採用したのか、他の方法ではどうダメなのかをコメントで切々と説く。


123 :デフォルトの名無しさん:04/12/17 23:24:56
したいこととその方法を書く。

124 :デフォルトの名無しさん:04/12/18 01:46:54
phpのソース上キレイにかくか、
outputのhtmlをキレイにかくか、
で迷う

125 :デフォルトの名無しさん:04/12/18 01:56:06
>124
phpをきれいに書いたほうが後々自分が楽。

126 :124:04/12/18 03:47:37
>>125

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

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

127 :デフォルトの名無しさん:04/12/18 08:02:07
普通デザイン部分のhtmlは別ファイルにするだろ?

128 :デフォルトの名無しさん:04/12/18 20:50:29
php使うならxmlつかったほうがいい

129 :デフォルトの名無しさん:04/12/18 21:37:06
良いコードを書くのにノウハウなんていらね。
たった一つの事を守れば良い。

130 :デフォルトの名無しさん:04/12/19 14:23:41
そのたった一つの事とは、、、。


131 :デフォルトの名無しさん:04/12/19 14:27:19

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

132 :デフォルトの名無しさん:04/12/19 18:29:21
>>129-130
Cを高級アセンブラだと思わないこと。
特にアセンブラから入った人間。

133 :デフォルトの名無しさん:04/12/19 18:35:29
どう違う?浮動小数点演算をターゲットに応じて展開(レジスタ割付とか)してくれるぐらいしか思い浮かばんが

134 :デフォルトの名無しさん:04/12/19 18:41:51
あ、レジスタ割付は本質から外れるな。浮動小数点演算をどのように扱うか、という
面倒を見てくれることか

135 :デフォルトの名無しさん:04/12/19 23:22:19
たった一つの冴えたやり方

136 :デフォルトの名無しさん:04/12/20 00:47:49
意味を明確にしたコーディングをする、ということが大事だと思います。

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

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

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

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


137 :デフォルトの名無しさん:04/12/20 09:23:19
>>130
馬鹿はコードを書かない。

138 :デフォルトの名無しさん:04/12/20 10:49:19
>>136
コメント一行書けばしまいじゃん。


139 :デフォルトの名無しさん:04/12/20 10:59:15
>>136
日付時刻クラスでも作ったほうがいい。

140 :デフォルトの名無しさん:04/12/20 12:52:08
>>139
日付・時刻クラスをつくるってことは
後者にあたるんじゃないかい?

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

141 :デフォルトの名無しさん:04/12/20 15:06:57
>>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
);


142 :デフォルトの名無しさん:04/12/20 23:35:09
へ〜、sscanfってそういう使い方できるんだ。メモメモ。

143 :デフォルトの名無しさん:04/12/21 00:00:34
俺は前者だな。
前者の方が短くて速くて分かりやすい。
後者は冗長でかえって何がしたいのかわからなくなる危険がある。

144 :デフォルトの名無しさん:04/12/21 00:05:42
>>136
使う側からすれば、どうでもいい話。

145 :デフォルトの名無しさん:04/12/21 00:24:14
>>136
2005-1-1 00:00
になったらバグが出ないか?

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

146 :デフォルトの名無しさん:04/12/21 00:27:58
前者はデータの性質を利用した(あるいは依存した)トリッキーな実装って
意味のただの例だろ。細部に突っ込んでも意味ないだろ。

147 :デフォルトの名無しさん:04/12/21 00:48:17
後者もデータ形式に依存しまくりだろ

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

149 :デフォルトの名無しさん:04/12/21 01:10:12
後者って、Cで書いちゃうと
date[4] = date[7] = '/';
なんだよな。

150 :デフォルトの名無しさん:04/12/21 01:53:39
>1〜4文字目を『年』、
>6〜7文字目を『月』、
>9〜10文字目を『日』、
>12〜16文字目を『時刻』とする。

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

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


151 :デフォルトの名無しさん:04/12/21 02:10:37
>>147
文字列の後半に'-'が含まれないって非本質的な性質を利用したって意味だよ。

152 :デフォルトの名無しさん:04/12/21 08:08:45
>>150
例題なんだから、その辺の仕様の善し悪しは置いといていいんじゃない?
要は分かりやすいコードと短いコードではどっちがいいか?
という話だと思うんだけど…

153 :デフォルトの名無しさん:04/12/21 08:58:14
だいたい、長いコードは分かり難い。

154 :デフォルトの名無しさん:04/12/21 10:46:19
例が悪すぎというのに尽きる。関数だというんだから>>136の前者でいい。そもそも
文字列操作を日付形式変換という意味のある操作に転換するために関数に抽出するんだし。

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


155 :デフォルトの名無しさん:04/12/21 13:19:31
>>151
どこにどの区切り文字が入っているかは書式化された日付においてはきわめて本質的な性質だけど?

156 :デフォルトの名無しさん:04/12/21 13:29:10
アホばっか

157 :デフォルトの名無しさん:04/12/21 15:50:18
たかが文字列の変換によくもまあこんなに沢山レスがつくもんだw
いままで同様な処理を書いたかなんぞ憶えていないが、全部、前者だ。
前者が気に入らないのなら、関数ごと差しかえれば良いだけの話だろ。
なんでこんなつまらんことで話が盛り上がるかが理解し難い

158 :デフォルトの名無しさん:04/12/21 16:40:42
そのための2chです。

159 :デフォルトの名無しさん:04/12/21 17:06:03
現実じゃなくて理想の話だからな
現実的な解決方法は求めてないだろう

160 :デフォルトの名無しさん:04/12/21 18:59:05
>例えば "2004-12-20 00:30" という形式の文字列
>(データベースの時間データによくある書式)を引数にとり、
>"2004/12/20 00:30" という文字列に変換する関数を作るとします。

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


161 :デフォルトの名無しさん:04/12/21 19:07:25
なぜDBの時間データを文字列形式で取ってくるのかという問題

162 :136:04/12/22 04:33:48
>>136なのですけど。。。
反応多くてびっくりです。

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

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

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

163 :デフォルトの名無しさん:04/12/22 08:18:15
それだったら
「"04/12/22 04:00" という形式ではなく、
"2004年12月22日 04:00" という形式にしてくれ」
とかもありえる

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

164 :デフォルトの名無しさん:04/12/22 08:32:17
>一つの尺度に、「リファクタリングに耐えうるかどうか」
>というのがあると思います

から

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

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

165 :デフォルトの名無しさん:04/12/22 09:01:54
>>162
つか、まるまる作り直しでいいじゃん。
下手に既存のものに付け足してしのごうとすると汚くなりがちだし、
バグの温床にもなる。

166 :デフォルトの名無しさん:04/12/22 09:23:32
仕様が変わっちゃうと、それはもうリファクタリングじゃない。。

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

168 :デフォルトの名無しさん:04/12/22 09:54:24
例が極端すぎたね。

169 :デフォルトの名無しさん:04/12/22 10:41:36
>>167
>>113 世の中にはこういう人も居る

170 :デフォルトの名無しさん:04/12/22 10:57:09
作ってる本人はわかりやすくても
他の人には迷惑なだけかもね

171 :デフォルトの名無しさん:04/12/22 11:27:59
>>167
前者の方が仕様に密着してると思うが。

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

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

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


172 :デフォルトの名無しさん:04/12/22 11:45:11
マクロならば
#define GSUB( str, s, d ) { int i; for( i = 0; i<=strlen( str ); i++) if( str[i] ==s ) str[i]=d; }
かな。・・・もう止めない?。この程度の処理に・・・。
俺は136のレベルが低すぎるだけだと思うのだけど

173 :デフォルトの名無しさん:04/12/22 15:45:50
>>172
おいおい、毎回strlen()するなよ。

174 :デフォルトの名無しさん:04/12/22 16:11:15
レベルが低いのは172ということで決着しました

175 :172:04/12/22 19:20:25
>>173
ぉぉ。確かに。でもこの程度の事はキニシナイw
別変数を用意しなきゃならないし、ここがボトルネックになるはずはないからな。
・・・まあこういうところまで気にしなければならない開発が存在することを否定するわけではないけど。

>>174 サンクス

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

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

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


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

すみません(_ _)

178 :デフォルトの名無しさん:04/12/22 22:03:31
C++だとlambdaを使うか、lambdaを使わないかってこった。
lambdaはごくごく単純な式なら役に立つことも全く無いとは言えないが、
どうせじきに式が複雑になってインラインじゃとても読めた代物じゃなくなるんだから
はじめからファンクタか関数にしとけってこと。

179 :デフォルトの名無しさん:04/12/22 22:13:57
>>178
C++にlambda式はありません。

180 :デフォルトの名無しさん:04/12/22 22:48:42
エラー処理を始めとする例外処理は、最初からまじめに書いとけ。
あとになって「こんなエラーがあるんだけど」と言われても、対処できん。

181 :デフォルトの名無しさん:04/12/22 23:05:28
>>179
boost::lambda、あるいはそれっぽい実装のこと指してんだろ

182 :デフォルトの名無しさん:04/12/24 00:06:22
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 使えばいいのに(;´Д`)

183 :デフォルトの名無しさん:04/12/24 13:37:53
>>182
俺だったらそれ以前にtypedef enum {EFalse, ETrue} TBool;とするだろうな。

184 :デフォルトの名無しさん:04/12/24 18:59:36
Eって、もしかしてEnumのE?
アホ?

185 :デフォルトの名無しさん:04/12/25 00:16:00
intとの暗黙の変換を嫌ったんじゃないの。
超厳格なプログラムを書くならありはありなんじゃないの。

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


187 :デフォルトの名無しさん:04/12/25 14:19:10
>>186
新しいプログラムのために、既存のシステムのコードを変えるのもなぁ。

188 :デフォルトの名無しさん:04/12/25 14:21:23
>>187
日付を文字列で引き回すような糞コードなら捨ててしまえ。

189 :デフォルトの名無しさん:04/12/25 14:27:20
>>188
内部でどう処理してるかは知らんけど、外部に日付型なデータを提供してない場合は多いし。

190 :デフォルトの名無しさん:04/12/25 14:28:18
日本が戦争に勝って
西暦が使われなかったら
やっぱり平成を単位にしてるんだろうか

191 :デフォルトの名無しさん:04/12/25 14:34:08
>>189
あほか。
I/Fが文字列型だとしてもこちら側で日付型に再変換してやれば済むだろ。
糞システムに合わせて糞システム作る気か?

192 :デフォルトの名無しさん:04/12/25 14:36:01
>>190
皇紀。

193 :デフォルトの名無しさん:04/12/25 14:41:23
>>191
文字列でやり取りしなければいいじゃんて言われても、
状況によってはそうもいかないこともあるって言ってるだけなんだけど。

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

194 :デフォルトの名無しさん:04/12/25 14:45:27
>>190
日本に西暦が導入されたのは戦前だべ

195 :デフォルトの名無しさん:04/12/25 17:16:36
神武天皇がお生まれになった年を0年に設定すれば良いのだ。
西暦など糞。

196 :デフォルトの名無しさん:04/12/25 17:33:53
どこかの生保が皇紀を使ってると聞いたけどどこだっけ?
2000年問題関連でその話が出たときにサヨの痛い人が観察されたんだよな。


197 :!99:04/12/25 21:22:58
>>99 同意
>>100
とても長い間、仕事でそうしているが。何か?

198 :デフォルトの名無しさん:04/12/25 21:36:33
ランバダ

199 :デフォルトの名無しさん:04/12/25 21:55:49
>>197
引き継いだ人が苦労しているだけですが、何か?

200 :デフォルトの名無しさん:04/12/25 22:06:49
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")


201 :デフォルトの名無しさん:04/12/25 22:09:45
↑こいつアフォ
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"


202 :デフォルトの名無しさん:04/12/25 22:55:37
>>197
今すぐ仕事辞めろ。

203 :デフォルトの名無しさん:04/12/25 23:44:11
なんで?

204 :デフォルトの名無しさん:04/12/26 00:55:51
>>197
一目でばっちり分かっちゃうコードならいいが。
そういう仕事はしてないんだろ?(褒めてる)
その素晴らしいコードを残されたものは多分そのコードが作られたときより
短時間で理解して、書き換えなきゃならないこともあるんだよ・・・

205 :デフォルトの名無しさん:04/12/26 01:03:53
>>197
「あのプログラム、君しか分かる人いないから全部任せるよ」
って言われて喜んでないか?

206 :197:04/12/26 03:32:40
>>204
コメントを信じる根拠は何処にも存在しない。
従ってメンテナンス時にもコメントは信用しない。
貴方はコード内のコメントが常に正しいと思っているのか?
#メンテナンス時にわざわざコメントを削除するぞw
だからこそコメントを書かないのだ。

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

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

207 :デフォルトの名無しさん:04/12/26 04:15:42
コメントに日時入れないのは最悪

208 :デフォルトの名無しさん:04/12/26 04:23:09
何を意図して書かれたかもわからないようなコードを信じる根拠も無いわけだが。

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


209 :デフォルトの名無しさん:04/12/26 04:23:16
いらんよそんなもん。cvs annotateを見る方が確実。


210 :デフォルトの名無しさん:04/12/26 04:23:39
そんなもん=日時ね。


211 :デフォルトの名無しさん:04/12/26 04:42:11
コメントが間違っててそれに振り回されてる人が多い。ソース読みさえすれば分かるのに。
それで読んでも意図が分からんソースなら捨てて作り直せば良いだけなのにね。


212 :デフォルトの名無しさん:04/12/26 04:43:34
>それで読んでも意図が分からんソースなら捨てて作り直せば良いだけなのにね。
といっている奴のコードにまともに読めるコードがあったためしがないのが現実。


213 :デフォルトの名無しさん:04/12/26 04:59:55
コード追って分かるのは「どう動作するか」だけ。
その動作が正しいかどうかは分からない。

214 :デフォルトの名無しさん:04/12/26 05:10:22
コメント見てもわからないぞそんなこと

215 :デフォルトの名無しさん:04/12/26 05:13:23
>>214
どういう動作を期待しているかが分かるようなコメントを書かないからだ。

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

if ( a<upper_bound ) break;

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

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

は見逃しやすい。

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

217 :デフォルトの名無しさん:04/12/26 06:49:50
コメントが無けりゃ間違いかもわからんじゃないか


218 :デフォルトの名無しさん:04/12/26 07:07:43
なら、こういうのはどうか

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

219 :デフォルトの名無しさん:04/12/26 08:50:19
コメントが無けりゃ間違いかもわからんじゃないか

220 :デフォルトの名無しさん:04/12/26 11:03:04
>>206
> 貴方はコード内のコメントが常に正しいと思っているのか?
> #メンテナンス時にわざわざコメントを削除するぞw
> だからこそコメントを書かないのだ。

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

221 :デフォルトの名無しさん:04/12/26 11:09:35
>>216
そういう単純な間違いを含んだソースを読むという状況がよく分からないです。
そんなの書いた本人がデバッグしてないだけじゃないの?

222 :デフォルトの名無しさん:04/12/26 11:10:55
>>216
> // 上限を超えたら終了
> if( a<upper_bound ) break;

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

223 :デフォルトの名無しさん:04/12/26 11:14:52
>>216
コード書いた本人にとっては、
aやupper_boundが何を表しているかも分かってるし、前後にどういう処理が行われているかも分かってるし、
どういう条件の時にどう動かなければいけないかってのも分かっているかもしれないが

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

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

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


225 :(;д;)○ぽんぽんぽんぽぽぽぽんぽんぽん ◆1xsES22i66 :04/12/26 12:07:24
>>224
そのコードがjmpの嵐だったりするわけだ。
フローチャート程度のコメントは欲しいぞ。

226 :デフォルトの名無しさん:04/12/26 12:48:14
私も>216や>218のようなコメントを見つけたら削除するね。
なので>224には同意。
だがそういうコメントを適切に書けない香具師に限って意図不明のコードを書くんだ。

227 :197:04/12/26 13:45:08
>>208
滅茶苦茶だな。コードを信用しないでコメントを信用するのか?
>「コメントを書く」=「コメントがないと読めないコードを書く」と勝手に決められてもな。
そんな事は言っていない。「コメントは読まない」とか「コメントを書くのはどうぞ自由に。だが俺は書かない」
と言っているだけだが。

>>211
同意

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

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

228 :デフォルトの名無しさん:04/12/26 13:51:17
>>227
え?コメントを消して回ってるのに?

229 :デフォルトの名無しさん:04/12/26 14:06:56
>>227
もしかしてfunction単位とかファイル単位のサマリも書かないのか?

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


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

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

232 :デフォルトの名無しさん:04/12/26 14:24:20
>最初のコードの意図

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

233 :デフォルトの名無しさん:04/12/26 14:26:51
コメント書かない香具師が改造やると最悪だよな。
既に動いてる他のコードの意図無視して適当にパッチ当てやがる。

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

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

235 :デフォルトの名無しさん:04/12/26 14:54:48
>>234
ミスをしない奴ばっかりなら、そもそもソフトウェア工学自体が必要なくなってきそうだけどな。

236 :デフォルトの名無しさん:04/12/26 15:08:14
最初に作る時にはコメントは不要
後でバグ取りで直す時になぜバグったのか、
どう処置したのかをコメントに書いておく


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

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

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


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

238 :デフォルトの名無しさん:04/12/26 17:02:03
>>197
疑問・・・君はアセンブリで書くときもコメント書かないのかい?
もし、他人が書いたコメントなしのアセンブリリストを保守できるなら神だな

239 :デフォルトの名無しさん:04/12/26 22:12:59
なんか馬鹿が多いようだが、
正直メソッド内にコメント書いちゃだめだろ?
書かなきゃ解らない時点でそのメソッドは機能がでかすぎるんだよ。
もちろんメソッドの直前に機能説明は書くべきだが。

240 :デフォルトの名無しさん:04/12/26 22:22:46
ビットシフト使いまくりっていいコード?

241 :デフォルトの名無しさん:04/12/26 23:41:50
>>239
書いてあっても良い、書いていない奴のコードが汚いのが問題。
コメントを打つとコードを綺麗に書く技術が身についてくる、
そのうちにコメントが無くなって来るのだ。
コメントを書かない奴はコメントを書かないようにする技術が大抵無い。

242 :デフォルトの名無しさん:04/12/26 23:44:42
>>240
使うべくして使ってんならどんなにあってもいいコード

243 :デフォルトの名無しさん:04/12/27 00:35:28
>>241
>コメントを打つとコードを綺麗に書く技術が身についてくる、
嘘だ。逆説を書いてみようか。
コメントを打つとコードが汚いことを隠せたような気になって、綺麗に書く様には決してならない。
#わずか四行で矛盾したことを言えるのはすごい才能だね

244 :デフォルトの名無しさん:04/12/27 00:56:40
逆説?

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

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


246 :デフォルトの名無しさん:04/12/27 01:00:42
マ板のヨタ話みたいなレスしかないな

247 :デフォルトの名無しさん:04/12/27 01:16:13
>>239
その強迫観念にとらわれて馬鹿みたいに小さなメソッドを乱造したのはオマエか!

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

249 :デフォルトの名無しさん:04/12/27 02:02:29
>>245
×コメントの無いコードはコメントを極めた奴だけが可能にできる物だ。
○コメントの無いコードはプログラミングをある程度以上、習熟した奴が可能にできる物だ。


250 :デフォルトの名無しさん:04/12/27 02:04:19
つーか、1メソッドって一つの機能しか持たせなくね?
んで、処理実行!みたいなメソッドで他のメソッドを呼び出しコントロールする。
みんな違うのか?
1メソッドにあほみたいに機能を詰め込んでる??

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


251 :デフォルトの名無しさん:04/12/27 02:06:41
皆が"一つの機能"という感覚を共有できたら戦争など起きないだろうな

252 :デフォルトの名無しさん:04/12/27 02:12:35
>>251
たしかに曖昧だが、
コメントをばりばり書かないと理解できないメソッドは、
1つの機能じゃないと思う。

253 :デフォルトの名無しさん:04/12/27 02:27:01
なんか「機能」という言葉の定義が違うような・・・
どんな大きな機能だとてそれは一つの機能。
分割する事によってコードイメージが想像できる程度のサイズになるのが
設計だと思っているのだけれど。

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

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


255 :デフォルトの名無しさん:04/12/27 02:28:29
例えば「更新」ボタンを考えてみる

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

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

256 :デフォルトの名無しさん:04/12/27 03:42:24
>>254
自分中心にしか物事が見えて無くないか?

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

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


257 :デフォルトの名無しさん:04/12/27 04:02:15
>>256
議論の叩き台であって、俺が別に必ずそういう風にコードを書くという意味ではないが。
CollateUserといっても、相手がファイルなのかデータベースなのかでいろいろ
変わって来るからね。

258 :マーチンファウラ:04/12/27 07:33:16
リファクタリング嫁


259 :デフォルトの名無しさん:04/12/27 08:07:48
おまいら、自分が見て来たコードが世の中の全てとか平均と勝手に思ってないですか。
何年PGやってるか知らないけど、おまいが見たソースコードは世界中のソースコードの
1%にも満たないんじゃないですか。
そもそも話題の焦点にしている開発内容はなんですか。言語はなんですか。



260 :デフォルトの名無しさん:04/12/27 08:58:16
>>257
つか、DBかファイルかでCollateUserの外が変わるような構造にするなよ。
すべてCollateUserの中で解決しろ。

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

262 :デフォルトの名無しさん:04/12/27 09:29:56
>>260
CollateUserメソッドの中身が、いろいろ変わってくる、と言っているのです。


263 :デフォルトの名無しさん:04/12/27 10:09:57
なんつーか、実現したい機能(業務ロジックだったり、データをExcelに書き出す機能だったり)は
クラスつかえるなら1クラスに、使えんならファイルスコープでくくるなり、
グループ化するだろ。
同じインターフェースで使いたい似たような機能があるなら、interfaceやfactoryも用意する。

その上で作成されたクラス内の1メソッドも
・データ(ファイルでもDBでもメモリでも)取得
・処理1
・処理2
・処理3
・データ書き込み
みたいに抑えるべきでないのかい?

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


264 :デフォルトの名無しさん:04/12/27 10:19:01
なんか間違えた。
読み込み、書き込みとも同じクラスってのはやんねーな。
・データ取得クラス
・なんかの処理クラス
・データ書き込みクラス
って感じで、それぞれのクラスで
処理1、2、3だな

265 :デフォルトの名無しさん:04/12/27 13:04:48
>>264
なんかとっても手続き型ですね。

266 :デフォルトの名無しさん:04/12/27 15:23:56
パフォーマンス上の理由とかで
読み書きを同時に行いたいとかなったらどうするの?
さらにサーバと通信しながらとか
画面書き換えながらとか
連携するのがほとんどだと思うけど
コメントないとなんでこういう順番なのかわかんなかったり

267 :デフォルトの名無しさん:04/12/27 18:31:32
>>265
C++やらJavaやら使っている時点で手続き型なんですが。

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

269 :デフォルトの名無しさん:04/12/27 23:29:22
>>267
>C++やらJavaやら使っている時点で手続き型なんですが。

いや、>>265 は、

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

と言いたいのだろう。

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


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

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

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

272 :デフォルトの名無しさん:04/12/28 01:40:40
実際はこう。
・FooDAOFactory
・FooDAO
・FooDAOImpl
・FooLoader
・FooRegister
クラスやメソッドの説明は必要。だけどメソッド中にコメントはいらん。
コード嫁。以上。

273 :デフォルトの名無しさん:04/12/28 03:27:40
>>272
Fooに対してなんでLoaderとDAOが同列に存在するのさ?

274 :デフォルトの名無しさん:04/12/28 04:02:44
>>272
Fooは扱うデータか?いやそれにしてはFooクラスが無いな。
名前空間というか接頭語みたいな物か?
意図の分からん命名ってコードを読む気力を激しく奪うぞ。

275 :デフォルトの名無しさん:04/12/28 09:24:10
関数は粉々になるまで分けるのが正しいらしいが
関数名に困る

276 :デフォルトの名無しさん:04/12/28 10:26:26
良いコードを書くためのウハウハを蓄積するスレ

277 :デフォルトの名無しさん:04/12/28 17:42:42
>>275
名前が付けられないのは分けすぎの証拠。

278 :デフォルトの名無しさん:04/12/28 17:53:07
>>275
関数のオーバヘッドは無視できない。

279 :デフォルトの名無しさん:04/12/28 23:33:29
>>278
粉々にしているんだからinlineにすればいいだけだと思う。

280 :デフォルトの名無しさん:04/12/29 00:39:15
>278
最近のWindowsPGで
関数のオーバーヘッドを気にするような必要ってある?
そもそも、処理を関数で細分化するのは、メンテを容易にするためであって
高速化の為ではない訳で・・・

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




281 :デフォルトの名無しさん:04/12/29 00:52:23
>>280
そこで匿名関数を使う。

282 :デフォルトの名無しさん:04/12/29 00:53:40
>>280
Cのような代入型言語を使うのではなくて、最近では関数型を使った方が生産性が
高い事が多くなったように思わない?

283 :デフォルトの名無しさん:04/12/29 02:19:27
>>280
「処理の分離/細分化」ではない。「機能の分割」だ。#細かなところは突っ込まないで
機能の分割が出来ていれば命名に悩む事なぞないと思うが

284 :デフォルトの名無しさん:04/12/29 02:23:09
>>280
名前の付け方で困るほど細分化したら却ってメンテ性下がるだろ。
何のための関数なのかが自明なレベルで止めとけって。
(自分には判ってるから大丈夫とかアマチュアな事言うなよ。)

285 :デフォルトの名無しさん:04/12/29 07:25:32
>>280
> ある処理を細分化して
> その処理中の1度しか呼ばれないような関数の場合の
> 命名手法はどんな感じ?
他の関数と同じ方法でつければいいじゃん。

286 :デフォルトの名無しさん:04/12/29 08:48:29
ラムダよりもforeachが欲しい

287 :デフォルトの名無しさん:04/12/29 09:05:00
>>286
アルゴリズムのstd::for_eachで十分……、なわけないよな。

288 :デフォルトの名無しさん:04/12/29 11:12:49
ラムだっちゃ☆

289 :デフォルトの名無しさん:04/12/29 14:07:51
>>286
C#使ってみなよ、あんまり便利でもないよ、for文+イテレータのほうがシンプルでいいね。

290 :デフォルトの名無しさん:04/12/29 14:38:03
>ある処理を細分化して
>その処理中の1度しか呼ばれないような関数の場合の
>命名

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

291 :デフォルトの名無しさん:04/12/29 15:02:50
>>290
たとえば、Cにおけるコマンドライン引数処理なんて
mainの中から一度呼ぶだけだったりしますが。

292 :デフォルトの名無しさん:04/12/29 16:02:51
>>291
呼ばれる頻度で名前の付け方変えるってどこの世界の命名規則でつか?

293 :デフォルトの名無しさん:04/12/29 16:09:08
>>292
さぁ。そんな命名規則見たこと無いけど。

294 :デフォルトの名無しさん:04/12/29 16:10:02
頻度っていうかprivate, staticなものはいい加減に付けがち

295 :デフォルトの名無しさん:04/12/29 17:12:29
関数にしたんなら
関数にされた一連の処理群に何らかの意味的なマトマリを見い出してるはずだから
その意味を英訳して関数名にするがよい

296 :デフォルトの名無しさん:04/12/29 17:14:26
勿論「returnで流れ制御」したいがために関数を作っちゃう馬鹿はどっかいけ

297 :デフォルトの名無しさん:04/12/29 17:21:54
296
便利さと性能、どちら優先かによる

298 :デフォルトの名無しさん:04/12/29 17:31:16
Cライクな言語はもううんざり。

299 :デフォルトの名無しさん:04/12/29 17:34:41
これからはschemeか。

300 :デフォルトの名無しさん:04/12/29 17:39:50
Schemeもいいけれど、ML系のOCaml辺りの方が実用的でよさそう。

301 :デフォルトの名無しさん:04/12/29 17:40:43
>returnで流れ制御
って何?

302 :デフォルトの名無しさん:04/12/29 18:00:46
例えばreturnで多段breakをしたいが為だけに関数を分割するって話だろ

303 :デフォルトの名無しさん:04/12/29 18:16:13
>291
>コマンドライン引数処理

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

304 :デフォルトの名無しさん:04/12/29 18:20:35
>>303
一度しか呼ばれないような関数を作る奴は頭悪いんだろ。

305 :デフォルトの名無しさん:04/12/29 18:25:54
>304
>一度しか呼ばれないような関数を作る奴は頭悪い

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



306 :デフォルトの名無しさん:04/12/29 18:31:12
名前付けに困るような分割=1度しか呼ばれないような関数への分割でしょ。

307 :デフォルトの名無しさん:04/12/29 18:36:58
>>303
main も駄目でつか?


308 :デフォルトの名無しさん:04/12/29 18:38:18
func(){
 func_init();
 func_run();
 func_done();
}
とかだらだらと_でつないでいけば少なくとも迷うことはない。

309 :デフォルトの名無しさん:04/12/29 18:39:03
通行人A、通行人B ・・・ でどうだろうか?

310 :デフォルトの名無しさん:04/12/29 18:39:13
ん?

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

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



311 :デフォルトの名無しさん:04/12/29 19:19:30
1 度しか呼ばれない関数を作るのが抽象化の目的であれば良いコードです

312 :デフォルトの名無しさん:04/12/29 20:00:19
どうでもいいけど1度って書くと角度みたいだね

313 :デフォルトの名無しさん:04/12/29 20:08:07
んん?
角度ってラジアンだろ?

314 :デフォルトの名無しさん:04/12/29 20:12:46
>>313
いいえ。

315 :デフォルトの名無しさん:04/12/30 12:48:08
100前後読んでたら、仕様書からいきなりコーディングしてる奴がいた。


316 :デフォルトの名無しさん:04/12/30 20:21:10
蓄積しま
ttp://www.okisoft.co.jp/esc/go/style0.html

317 :デフォルトの名無しさん:04/12/31 11:54:40
>>272
スコープが
上3つはpublic
下2つはpackage

318 :デフォルトの名無しさん:04/12/31 12:59:23
>>317
>>272書いた人?
静的クラス図書いてUPしてほしいな。


319 :デフォルトの名無しさん:05/01/03 12:47:09
スレッドも1/3経過したことだし、これまでに蓄積されたノウハウをまとめない?

320 :デフォルトの名無しさん:05/01/04 10:11:50
電車男みたいに本にして儲けたいらしいが、
ttp://f55.aaa.livedoor.jp/~goodcode/
にまとめるとか。

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

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

322 :デフォルトの名無しさん:05/01/04 21:35:28
結論
自分で書かない
人のやつをパクる

323 :デフォルトの名無しさん:05/01/04 21:44:19
シンプルが一番
可読性も保守性も効率だって

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

324 :デフォルトの名無しさん:05/01/05 13:50:40
>>322
人のやつもパクらない。
作る側から使う側へクラスチェンジする。


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

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

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

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

326 :デフォルトの名無しさん:05/02/05 03:05:22
if(flag){
  func();
}
というインデントが多いみたいだけど
if(flag)
{
  func();
}
これだとダメなの?
こちらのほうが対応するカッコの数とか分かりやすいんだけど。

327 :デフォルトの名無しさん:05/02/05 03:06:08
>>326
人それぞれ。
私は前者。

328 :デフォルトの名無しさん:05/02/05 03:07:27
>>326
なるべく行数を減らした方がコード全体を把握しやすくなるというメリットがある。

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

330 :デフォルトの名無しさん:05/02/05 03:28:24
>>329
いや、たしかにそうなんだけど、私が言っているのはもっと物理的な面の話。

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

332 :デフォルトの名無しさん:05/02/05 07:32:07
>>329
ifとfuncの間が一行空いている積極的な理由が思いつかない。

333 :デフォルトの名無しさん:05/02/05 07:50:19
if(flag) func();

334 :デフォルトの名無しさん:05/02/05 07:57:42
>>326
つか、カッコの数を数えないといけないようなコードを書くな。

335 :デフォルトの名無しさん:05/02/05 08:02:40
>>326
K&Rに倣っている人も多いんじゃないかな。

336 :LISP大好き:05/02/05 08:04:29
>>334
呼んだ?

337 :EmacsLisp使い:05/02/05 09:05:43
>>336
インデントはエディタに任せるから数えたことないなぁ

338 :デフォルトの名無しさん:05/02/05 10:01:09
括弧の前に改行一個入れるか入れないかで
議論になるお前らのミジンコサイズの根性がかわいいぜ

339 :デフォルトの名無しさん:05/02/05 12:06:51
シッコの穴の小さいやつらだ

340 :デフォルトの名無しさん:05/02/05 14:46:08
>ifとfuncの間が一行空いている積極的な理由が思いつかない。

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

341 :デフォルトの名無しさん:05/02/05 15:07:26
見やすいか? それと同じように>>326の下の方が見にくいという主張も成り立つが。
むしろ条件と関係なくローカルスコープを作るためのブロックと混同しそうでいやだ。


342 :デフォルトの名無しさん:05/02/05 15:27:22
do
{
if (...)
{
...;
}
else
{
...;
}
}
while (...);
と書くのだろうか…
私なら
do {
if (...) {
...;
} else {
...;
}
} while (...);
と書くのだが。

343 :デフォルトの名無しさん:05/02/05 15:47:33
条件式が複数行になる場合
if(...
 ...
 ...) { // ここと
 ...; // ここがくっついて見えるのが嫌


344 :デフォルトの名無しさん:05/02/05 16:15:32
>>342
インデントされてないが上の書き方のほうが見やすい。
まぁdoは自分は使わないけど。

345 :デフォルトの名無しさん:05/02/05 16:24:11
>>344
do
{
while (...) ...;
}
while (...);
while (...) ...;

do {
while (...) ...;
} while (...);
while (...) ....;
では?

346 :デフォルトの名無しさん:05/02/05 16:29:16
うえは
}
while (...);
が紛らわしくてやだ

347 :デフォルトの名無しさん:05/02/05 16:34:23
>>340
> ブロック化されているのが明確になっていて良い。
ifとそれに続く処理が別のブロックのように見えちゃうのはいかんだろ。

348 :デフォルトの名無しさん: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 Antでbuild.xmlを書く。
MevenideをEclipseにインストールし、
Apache Mavenでproject.xmlを書く。
Mavenを利用してJakarta CommonsのAPIを積極的に使う。

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

これでよしっ!

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

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


350 :デフォルトの名無しさん:05/02/05 17:31:10
>>349
アフォハケーン

351 :デフォルトの名無しさん:05/02/05 18:27:23
>>345
do
{
  while (...)
  {
     ...;
  }
}
while (...);

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

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

352 :デフォルトの名無しさん:05/02/05 20:22:55
結論はやはり人それぞれ。

353 :デフォルトの名無しさん:05/02/05 22:51:35
30年かわらぬ嗜好品だな

354 :デフォルトの名無しさん:05/02/05 23:15:02
人間の目は横に並んでいるので縦方向に長いものは把握しにくい


355 :デフォルトの名無しさん:05/02/05 23:19:41
do{
  while (...){
     ...;
  }
}while (...);

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


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

356 :デフォルトの名無しさん:05/02/05 23:30:37
本で読んだ受け売りだけど。
#ifdef FOO
if (hoge)
#else
if (piyo)
#endif
{
  statements;
}
こういう場合に、エディタの括弧対応調査機能が働きやすいというのがある。

357 :デフォルトの名無しさん:05/02/05 23:32:34
バッドノウハウだな。

358 :デフォルトの名無しさん:05/02/05 23:41:13
if(hoge){
foo;
}

の人は何で

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

359 :デフォルトの名無しさん:05/02/05 23:42:07
}else{

360 :デフォルトの名無しさん:05/02/05 23:44:24
>>358
}が最後尾になって追跡しにくいから。
関数型だったら手続きがないから最後尾の}はOKだけど。

361 :デフォルトの名無しさん:05/02/05 23:47:12
>>356
それに近い事よくやるよ。
ifの行だけ#ifdefとかで無効になっても残ったブロック部分も
問題なくコンパイル出来るしね。

362 :デフォルトの名無しさん:05/02/06 00:11:17
>>356
普通は
#ifdef FOO
#define COND hoge
#else
#define COND piyo
#endif
if (COND) {
 stmts;
}
みたいに書かないか?

363 :デフォルトの名無しさん:05/02/06 00:15:47
単独で記述することができないキーワードが先頭に来るのはきもい。
x
if (hoge)
{
}
else
{
}

o
if (hoge) {
} else {
}


364 :デフォルトの名無しさん:05/02/06 01:30:05
きもいじゃ理由にならん。
見た目で語るなら個人差がある。

365 :デフォルトの名無しさん:05/02/06 02:17:00
>>362
それだとifでbreak張ってもCONDがどちらか分からないんじゃない?

366 :デフォルトの名無しさん:05/02/06 04:40:28
m
a
i
n

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

367 :デフォルトの名無しさん:05/02/06 08:36:21
>>356 >>362
普通は
int hoge()
{
...
}
int piyo()
{
...
}
int (*stmts[])() = {hoge, piyo};
int fuga = stmts[FOO]();
みたいに書かないか?


368 :デフォルトの名無しさん:05/02/06 09:50:48
>>367
#define FOO
だったらどうする

369 :デフォルトの名無しさん:05/02/06 10:28:22
>>368
あふぉか?

370 :デフォルトの名無しさん:05/02/06 15:36:03
>>21
> 9 a(1, 1);
これだな。

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

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

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

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

371 :デフォルトの名無しさん:05/02/06 15:38:33
>>362
それだと

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

と書けないから。


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

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

373 :デフォルトの名無しさん:05/02/06 16:00:56
(;゚∀゚)=3ウハウハを蓄積

374 :デフォルトの名無しさん:05/02/06 16:03:21
>>372
>Eclipse側の問題を//スタイルのプログラマにしわ寄せさせるのは良くない。

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


375 :デフォルトの名無しさん:05/02/06 17:04:29
互換性考慮がチームで決定された方針なら全員あわせるべき。
それが個人による趣味の範囲なら人それぞれ。
C++で//を使うなという話自体はナンセンス。

376 :デフォルトの名無しさん:05/02/06 17:09:35
複数行に渡るコメントは、#if 0 を使ったり include にしたり

377 :デフォルトの名無しさん:05/02/06 17:56:34
>>376
>include にしたり
?

378 :376:05/02/06 18:15:11
>>377
コメント行のみで構成されるテキストファイルを作ってincludeするのだよ

379 :デフォルトの名無しさん:05/02/06 18:23:33
>>376
それはそれでひとつのテクニックだとは思うけど、
コメントの為にあるものではないし、
エディタ上ではコメント扱い(の表示)になってくれない。

380 :デフォルトの名無しさん:05/02/06 18:25:33
>>378
ごめん、それ、何の意味があるのか判らない。
例えばfoo.cppに
// See foo.txt for detail.
って書けば済む気がしてならないんだけど。

381 :デフォルトの名無しさん:05/02/06 18:27:08
>>378
基本的に、コメントはコンパイラじゃなくて人が読む物なのに、
わざわざ別ファイルにして、そっちを開かなきゃいけなくなるのが馬鹿馬鹿しい。と思えるのは自分だけですか?

382 :69式フリーPG ◆hND3Lufios :05/02/06 18:28:14
無意味

383 :デフォルトの名無しさん:05/02/06 18:49:54
まともに動けばそれで良い

384 :デフォルトの名無しさん:05/02/06 18:50:16
>>378
プリプロセッサを通さないとコメント読めないの?
とてつもなく不便な気がする。

385 :デフォルトの名無しさん:05/02/06 18:54:36
ifやwhileの{を条件式の後に続ける人でも
関数始まりの{は行頭に書くのはなんで?

386 :デフォルトの名無しさん:05/02/06 19:13:57
確かにそうだよな。統一感が無いね。

387 :デフォルトの名無しさん:05/02/06 19:17:26
おれは関数始まりでも行の後ろに{つける派。

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

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

389 :デフォルトの名無しさん:05/02/06 19:27:38
逃げたか・・・

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

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

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

393 :デフォルトの名無しさん:05/02/06 19:55:59
>>392
で、あなたがその考えを今も引きずっている訳は?

394 :デフォルトの名無しさん:05/02/06 20:06:22
>>393
引きずってなどいませんよ。
規約にもないのに「全ての関数にはコメントヘッダがなくてはならない」という
横車をする人間がいない限りは。普段からそんな事なぞ絶対にしないw。


395 :デフォルトの名無しさん:05/02/06 20:32:49
Doxygenを使うと関数にコメント付けるけどそれについてはどう思う?

396 :デフォルトの名無しさん:05/02/06 20:39:16
コメントだったら、エディタによっては隠す事ができる機能がある物もあるよね。
そういうエディタを使えば気にならないんじゃない?
ソースと同じところにコメントがあってこそ意味があると思うし、
Doxygenなんてもろにその思想でしょう?

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

398 :デフォルトの名無しさん:05/02/06 20:57:00
>>397
それだけではなく、
ソースを読むときに手助けになるから、初めて読むようなソースにはDoxygenかける
こともあるよ。自分のソースを見返すときにかけることもある。


399 :デフォルトの名無しさん:05/02/06 21:13:48
>>392
ひとりでしこしこ書くコードじゃないのなら、
せめて引数と戻り値の仕様は書け。

400 :デフォルトの名無しさん:05/02/06 21:41:50
DoxygenとCVSを組み合わせるとソースにリビジョン番号を
埋め込む事ができるよね。
確かコメントに何か仕掛けするんだと思ったけど。
コメントだけ別ファイルにするとわけが分からん事になりそうだ。

401 :デフォルトの名無しさん:05/02/06 21:45:03
>>400 それ、Doxygen関係ない。

402 :デフォルトの名無しさん: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

403 :デフォルトの名無しさん:05/02/06 22:11:47
メンバ変数の名前は
1 m_testData;
2 m_TestData;
3 testData;
4 TestData;
だったらどれがいい?

404 :デフォルトの名無しさん:05/02/07 01:29:10
m_test_dataだったり。


405 :デフォルトの名無しさん:05/02/07 02:40:26
おれもだ。
以前どっかのサイトでそのスタイルを推奨してるところあったよ。

406 :デフォルトの名無しさん:05/02/07 06:01:08
私は最近mTestData;

407 :ぶび:05/02/07 10:48:37
VBだと完全一致検索で「_」が無視されるので(´・ω・`)

408 :デフォルトの名無しさん:05/02/07 13:35:01
>>326
実際のところ、紙面上の都合が全て。
下のコードだとページ数が余計にかかり、コスト高になる。
他の理由はそれを誤魔化すためのものにすぎないのだ。

409 :デフォルトの名無しさん:05/02/07 14:09:19
ハァ?


410 :デフォルトの名無しさん:05/02/07 17:30:47
いまだに行数で値段決めてんのか?


411 :デフォルトの名無しさん:05/02/07 17:33:11
>>410
お前の一行1円。

412 :デフォルトの名無しさん:05/02/07 21:27:38
なんのコストだよ。ケチ臭い。

413 :デフォルトの名無しさん:05/02/08 18:59:54
実装した機能に対して行数が少ない程対価が多くなるようなレートを設ければ
競ってリファクタリングせざるを得ないだろう。コードを読む方はそれを望む。

414 :デフォルトの名無しさん:05/02/08 20:55:28
>>413
行数じゃなくて、もうちょっとちゃんとした「読みやすさ」の指標がほしいね。

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

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

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

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

416 :デフォルトの名無しさん:05/02/08 22:49:07
こんな所でだべってないでコード書けよ。

417 :デフォルトの名無しさん:05/02/08 22:50:46
こんな時間にコード書いたって、いいコードにはならない。

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

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

419 :デフォルトの名無しさん:05/02/09 01:26:51
404-405
GNUコーディング規約は小文字でアンダースコアだね。

420 :デフォルトの名無しさん:05/02/09 03:11:01
マジだ。
http://www.gnu.org/prep/standards/standards.html#Formatting
変数はこれから小文字とアンダーバーで決まりだね。

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

421 :デフォルトの名無しさん:05/02/09 03:58:12
そのへんは後でフォーマッタかければなんとでもなる。


422 :デフォルトの名無しさん:05/02/09 13:41:13
ちなみにsunのjavaコーディング規約
http://www.tcct.zaq.ne.jp/ayato/programming/java/codeconv_jp/index.html

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

423 :デフォルトの名無しさん:05/02/09 13:49:13
>>420-422
GNUは、Cで書くことが前提になっているからね。

424 :デフォルトの名無しさん:05/02/09 15:44:29
なんでsunの社内規則に従わにゃならんの

425 :デフォルトの名無しさん:05/02/09 18:59:49
>>415
それは、読むのがつまんないってだけで。
お前を面白がらせるためにコード書いてる訳じゃないので…

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

427 :デフォルトの名無しさん:05/02/09 23:07:44
>>426
トリッキーなコードと簡潔なコードの区別ぐらいしようよ。

428 :デフォルトの名無しさん:05/02/09 23:14:35
>>427
いや、だから「客観的な指標が欲しい」つってんじゃん。

429 :デフォルトの名無しさん:05/02/09 23:27:39
>>428
構造化も出来てないコードは簡潔云々以前の問題だろ。

430 :デフォルトの名無しさん:05/02/09 23:39:24
>>429
最初はちゃんと構造化されてても
なんの工夫もなく無駄にだらだらと長いコード書いてたら
結果として自然にそうなってくるんじゃないのか?

431 :デフォルトの名無しさん:05/02/10 00:01:03
構造化ってなんだ・・・

432 :デフォルトの名無しさん:05/02/10 01:05:18
>>430
最初に構造化と決めたならなんの工夫もなくても構造化だけは
普通やってくんじゃないの?そこにテンプレートとか組み合わせれば
似たコードはだいぶ少なくなると思うけど。
そして欲を言えばOOPと。

433 :デフォルトの名無しさん:05/02/10 01:07:54
トリッキーなコードというとboost::lambdaとかを想像する

434 :デフォルトの名無しさん:05/02/10 01:57:31
>>426
低レベルな奴らは、本来共通化しちゃいけないものを無理矢理共通化するから侮れない。

435 :デフォルトの名無しさん:05/02/10 02:20:57
それはオブジェクト指向の考え方がまったく身についてないからだな。

436 :デフォルトの名無しさん:05/02/10 02:23:36
何でもかんでもオブジェクト指向を適用するのは勘弁して欲しい。
オブジェクト指向こそが優れ、C++でのコーディングはC流より優れる。

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

437 :デフォルトの名無しさん:05/02/10 03:09:09
勘弁して欲しい理由は?
例えばあえてOOPに反するが自分では良いコードと思っている例を
挙げる事ができる?

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

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

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


439 :デフォルトの名無しさん:05/02/10 04:19:33
そう言う見方もあるのは判るが、そう言う見方だけに拘泥していては大局を見失うよ。

440 :デフォルトの名無しさん:05/02/10 05:03:28
>>438
良いアルゴリズムを良いまま隠蔽するためにもオブジェクト指向は有効よん。

441 :デフォルトの名無しさん:05/02/10 05:47:21
>>438
> オブジェクト指向なんてそんな場合にしか有効じゃないよ

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

442 :デフォルトの名無しさん:05/02/10 07:20:47
>>441
> 実際は「そんな場合」のほうが大方なワケよ。
そりゃあんたの不幸な環境ではそうだ、って話。優秀ならそんなみじめな境遇には陥らんよ。


443 :デフォルトの名無しさん:05/02/10 07:29:53
>>442
お前さんの書いた優秀なかっこいいコードをうぷきぼんぬ

444 :デフォルトの名無しさん:05/02/10 09:06:13
>>438
アルゴリズムと設計は別物であることもわかってないような職場では働きたくないなぁ。

445 :デフォルトの名無しさん:05/02/10 09:51:37
分野によるんじゃない?
数値計算とか解析だったらオブジェクト指向なんて使わないでしょ。

446 :デフォルトの名無しさん:05/02/10 10:14:28
なぁ、そろそろ設計時のオプジェクト指向と実装時のオブジェクト指向を
はっきり区別して話さないか。

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

448 :デフォルトの名無しさん:05/02/10 11:32:42
>>447
> データ構造が保証されるんだよ。ある程度。小規模であっても。
頭悪いんですね。「データ構造が保証される」だって。


449 :デフォルトの名無しさん:05/02/10 11:50:16
何の話をしているのかさえあやふやになってきたw

450 :デフォルトの名無しさん:05/02/10 13:03:54
プロジェクトなんかどうでもいい。
アルゴリズムを研究する人間にとってはOOPなんか本質でもなんでもない。
ここには職業プログラマしかいない、みたいに決めつけた議論はやめとけ。

451 :デフォルトの名無しさん:05/02/10 13:25:46
アルゴリズムだけを追ってる立場では、良いコードなんか本質でもなんでもないわけだが。

452 :デフォルトの名無しさん:05/02/10 13:27:40
>>451
良いコードとは良いアルゴリズムの具現である。

453 :デフォルトの名無しさん:05/02/10 13:29:58
>>452
グローバル変数使いまくりでスパゲッティ状態なコードがいいコード?

454 :デフォルトの名無しさん:05/02/10 13:31:31
よいコード書ける奴はこんなとこで油売っていない罠

455 :デフォルトの名無しさん:05/02/10 13:35:52
>>454
ダメだよ、そんな元も子もないこと言ったら。

456 :デフォルトの名無しさん:05/02/10 13:38:18
    _、_      プログラミングの友 マクロン
   ( ,_ノ` )     n    __
  ̄     \    ( E) / _/|
 フ     /ヽ ヽ_//  |◎±|/ MACRON POWER

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

457 :デフォルトの名無しさん:05/02/10 14:11:59
>>451
アルゴリズムだけを追ってる立場では、良いコードとは速くて効率の良いコードなわけだが。


458 :デフォルトの名無しさん:05/02/10 23:57:31
良いコードとはアセンブラで書かれた最速のコードである。
ただし最適化しすぎると他人には解読不能。

459 :デフォルトの名無しさん:05/02/11 00:01:06
ハードで実装したほうが良くないか?

460 :デフォルトの名無しさん:05/02/11 00:06:42
アルゴリズムだけを追っている立場では、良いコードとはアルゴリズムを説明しやすいコードである。

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

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

462 :デフォルトの名無しさん:05/02/16 18:03:51
>>461
あるかどうか判らない改造のためにプラグイン的な構造にするのは無駄。
都度リファクタリング汁。

463 :デフォルトの名無しさん:05/02/16 18:21:30
2chでは「リファクタリング汁」が流行ってるけど
ほんとにそんなにちょくちょくモジュールに手を入れてるの?
で、リファクタリングの前提となるUnitTest用のテストケースを完備してるの?

464 :デフォルトの名無しさん:05/02/16 19:20:08
対象とするプログラムをある程度仮定しないと議論しようがないと思うのだが・・・。

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

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

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

466 :デフォルトの名無しさん:05/02/16 21:23:31
詰めviスキーな人はリファクタリング奨励派

467 :デフォルトの名無しさん:05/02/16 21:24:48
>>465
> 知らぬ間にリファクタリングでコードがガラッと変わってたりしたら怖すぎる。
OOPでコード管理していればそんなこと思えない

468 :デフォルトの名無しさん:05/02/16 21:57:13
>>467
この間半月かけて解析したのに、また一からやり直しかよ。

469 :デフォルトの名無しさん:05/02/16 23:52:00
>>463
将来の改造のためにモジュール化を推し進めるよりその努力をUnitTest作る方に向けるべき。

470 :デフォルトの名無しさん:05/02/16 23:53:50
>>469
それどういう環境で実践してるの?
個人の趣味開発じゃないよね。

471 :デフォルトの名無しさん:05/02/17 02:15:48
>>470
業務系システムのサブシステムを5人程度で。
コード行数は10万行ぐらい。
言語はVB6(w

472 :デフォルトの名無しさん:05/02/17 10:59:58
うむむ・・・。ご愁傷様デス

473 :デフォルトの名無しさん:05/02/17 11:40:51
「本当のリファクタリング」なら書き方は変わっても
内容は変わらないのだから問題ないはずだけどね。

474 :デフォルトの名無しさん:05/02/17 12:22:53
いやだから、何に注力すべきかという問題で。
469の開発環境が「保守性より信頼性を要求されている」という事では?。
どっちも定量化の困難な品質特性だから、「ここまでやったから(充分で)今度はこっち」
という匙加減が出来ないのかも

475 :デフォルトの名無しさん:05/02/17 13:00:15
リファクタリングの誤用
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?RefactoringMalapropism
| リファクタリング中に2,3日システムが動かなくなっちゃってーなどと言ってる奴がいたら、んなもんリファクタリングじゃあなーいと言ってやれ。

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

476 :デフォルトの名無しさん:05/02/17 14:45:26
何かしらソースに変更加えたら、それが正しいか検証するのは大変だ。
リファクタリングソフトが完全なら良いのだが、誰も保証してない

477 :デフォルトの名無しさん:05/02/17 16:49:24
>>476
そのためのUnitTestって話なんだろうけどね。

478 :デフォルトの名無しさん:05/02/17 17:18:46
>>474
哲学になってくるからねぇ。

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

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

479 :デフォルトの名無しさん: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

480 :デフォルトの名無しさん:05/02/17 21:53:29
UnitTestなんてウゼーとか言う奴に「じゃあ単体テストは一度しかやらないの?」って尋ねると
不思議そうな顔するな(w
GUIならともかく、ビジネスロジックの反復テストを手動でやるコストをどう考えてるんだろう?

481 :デフォルトの名無しさん:05/02/17 21:58:25
>>474
保守性と信頼性がトレードオフな関係だと思ってる?
UnitTestちゃんと書いてれば保守性も後から付いてくるんだけど。

482 :デフォルトの名無しさん:05/02/17 22:00:58
信頼性とはデータ隠蔽の方だと思うので保守性と信頼性とが共存できるとは限らない

483 :デフォルトの名無しさん:05/02/17 22:26:25
UnitTestって良く分かんないんだけど、普通の単体テストとassertでの事前・事後条件の
チェックと違ってどういうメリットがあるの?教えてエロイ人!

484 :デフォルトの名無しさん:05/02/17 22:29:37
UnitTestって良く分かんないんだけど、普通の単体テストの自動化というメリットがある?教えてエロイ人!

485 :483:05/02/17 22:37:10
>>484
GUI部分以外で手動のテストってあるのか?

486 :484:05/02/17 22:51:16
>>485
ない。
GUI部分も自動のテストってあるよ。
教えたとおりにマウスカーソルがツツーと勝手に動いてやってくれるやつ。
製品名忘れました。

487 :デフォルトの名無しさん:05/02/18 00:02:01
UnitTestはUnitTestでしかないからねぇ。
テストに通ったからといって信頼性の高いシステムになるわけでもないし、
リファクタリングしたからといって改修しやすいコードになるわけでもない。

488 :デフォルトの名無しさん:05/02/18 00:57:43
>>487
え?
テストが通ってるのに信頼性が低いのって単にテスト項目が不適切なだけじゃん。
リファクタリング出来たのに改修困難って何のためのリファクタリング?

489 :デフォルトの名無しさん:05/02/18 01:05:02
UnitTestでテストできる範囲なんてたかが知れてるし、
リファクタリングの方向性に合った改修が入ることなんて稀。

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

490 :デフォルトの名無しさん:05/02/18 01:16:02
>>489
> UnitTestでテストできる範囲なんてたかが知れてる

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

491 :デフォルトの名無しさん:05/02/18 01:28:14
テストファーストだろうが、あとで手動でテストしようが、
それは一連のテストに通ったということしか保障しない。

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

492 :デフォルトの名無しさん:05/02/18 01:34:29
結合テスト、機能テスト、高負荷テストとか後段階のテストを含めたテスト計画全体に対するユニットテストのしめる割合がたいしたことないと言いたいのでは?

493 :デフォルトの名無しさん:05/02/18 09:31:23
使わないよりもコードの品質を高める効果はあるよね。
デグレードを防いでくれる部分もあるし。
それに全部勝手にやってくれるからテスト抜けみたいなこともない。
あと手動だと、あっちを立てればこっちが立たずって時に苦しい。

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

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


494 :デフォルトの名無しさん:05/02/19 04:20:14
みなさんどんな品質のコード書いてますか?

495 :デフォルトの名無しさん:05/02/19 04:54:54
>>494
最低品質のコード書いてます。
その代わり、コーディング時間は最短。
それでバグ・レポートたくさん。
でも直ちに最低品質のコードで修正。
最初に戻る。

496 :デフォルトの名無しさん:05/02/19 12:01:30
>>495
素早いリリースを実践していらっしゃるのですね。


497 :デフォルトの名無しさん:05/02/19 13:36:51
>>495
急がば回れ

498 :デフォルトの名無しさん:05/02/19 14:00:29
素早いリリースってなんじゃらほい。

  空の関数を作成
  ↓
┌→「動かねぇ〜」
│ ↓
│ 与えたデータと結果を教えてもらう
│ ↓
│ テストケースに追加する
│ ↓
│ 全てのテストケースで動くようにする
└─┘
テストケースを作るのって面倒なんだよ。
思いもしない使い方をする輩がいるし。

面倒なので現実的なテストケースを上の方法で他人から得ている…ごめんなさい。
他人には最初からテスト&デバッグのみで開発なんかしてないなんて口が裂けたら言えません。

バグ曲線で残りバグ予想件数が0.5件未満になる時期を出すと欝になるね。

499 :デフォルトの名無しさん:05/02/20 09:15:59
>>498
ヘタクソな奴の典型。

500 :デフォルトの名無しさん:05/02/20 09:28:39
それ以前に仕事してると言わんよ。回りの血圧上げるためにいるようなもんだ。


501 :デフォルトの名無しさん:05/02/20 11:17:05
Wikiみれねーぞ

502 :デフォルトの名無しさん:05/02/20 12:22:03
>>499
ヘタクソな奴の典型ですよ。

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

503 :デフォルトの名無しさん:05/02/21 00:59:35
>>498
ワロタ。パーセプトロンかよ。

504 :デフォルトの名無しさん:05/02/21 01:14:49
お陰さまで最高血圧が90まで下がりました。

505 :デフォルトの名無しさん:05/02/21 01:16:04
とりあえず、テスト困難なコードは設計がまずいことが多い。
中でも、テスト困難になりがちな副作用が多いコードは設計を見直すよう心がけている。


506 :デフォルトの名無しさん:05/02/21 01:21:46
>>504
普段から最高血圧90付近ですが、なにか。

507 :デフォルトの名無しさん:05/02/22 19:16:09
一日目。神懸かりモードで能力の限界に挑戦しながら書き上げる。
二日目。ゆっくり整理・リファインしつつコミット。
三日目。まったり。
最初に戻る。


508 :デフォルトの名無しさん:05/02/22 20:37:40
>>503
ワローテつかぁさい。パーセプトロンでござい。

509 :デフォルトの名無しさん:05/02/22 20:40:12
>>506
低血圧ぎりぎり正常。

510 :デフォルトの名無しさん:05/02/22 20:46:01
ここは悪いコードを書くためのノウハウをも蓄積するスレでっか?

511 :デフォルトの名無しさん:05/02/22 21:00:16
>>510
何が悪いかを知れば、何が良いかを知ることにつながる

512 :デフォルトの名無しさん:05/02/24 21:54:10
>>1
朝食食べるといいらしいぞ

513 :デフォルトの名無しさん:05/02/25 01:32:12
このあとトイレに流されますか?

514 :デフォルトの名無しさん:05/02/25 20:38:36
DHAのサプリメントを摂る

言っちゃった・・・・

515 :デフォルトの名無しさん:05/03/05 00:24:53
>>514
正直、ブルーベリーも重要だと思う。

516 :デフォルトの名無しさん:05/03/12 00:26:06
フラグを二回立てたくなったときの裏技
BOOL flag = TRUE * 2;

517 :デフォルトの名無しさん:05/03/12 12:30:38
「フラグ使わんと書けないのか」
というのは煽りになるのかのぅ

518 :デフォルトの名無しさん:05/03/12 18:05:39
同じ変数の使いまわしなんてもってのほかだし

130 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)