07/09/27 00:33:01
>>596
いやーなんでだろうね。いまだにわかんない。
今は管理役（≠管理職）になってるからコード書かなくなったから、
一緒に仕事することもほとんどないし。
そうそう、if文とかwhile文の後ろが処理1つで済むとき(nNum++とか)は
スコープは絶対につけないというこだわりも持ってた。
こんなことを新人の頃のコードレビューで何度指摘されたことか。。。
601:仕様書無しさん
07/09/27 00:34:02
なるべくforよりforeachを使うぜ！
perlはお呼びでない？そんな……
602:595
07/09/27 00:43:30
>>597
"とりあえず"ってコメントは､今となっては俺も使っちゃうんだけど､
今一緒に仕事してる人から
「問題見つけたときに直す気なのかなって思うと指摘しづらいし､
勝手に直していいのかもわからないからやめて」
っていわれたよ。
うちは検索キーワードはプロジェクト始まるときに､
各機能ごとに決められてそれ以外使えなくなるよ。
603:仕様書無しさん
07/09/27 01:22:17
"とりあえず"
"取り急ぎ"
"おそらくこれでOK"
"暫定"
604:仕様書無しさん
07/09/27 01:33:51
"やらなきゃいけない"
おまえがやれ
605:仕様書無しさん
07/09/27 02:39:57
"なぜか動くのでこのまま"
606:仕様書無しさん
07/09/27 02:43:33
"ここでぬるぽ発生の可能性あり"
607:仕様書無しさん
07/09/27 04:16:17
"後で書き直す"
…いつ？
608:仕様書無しさん
07/09/27 05:38:39
"怒涛のごとく改変"
609:仕様書無しさん
07/09/27 07:40:25
>>603
w
言われてみれば確かに使う
ずーっといつまでも「とりあえず」のままだなｗ
610:仕様書無しさん
07/09/27 08:24:59
"適当に埋めてみた"
書いた奴を土に埋めたくなる……
611:仕様書無しさん
07/09/27 09:18:24
コメントスレになっとるｗ
そういや、笑ったコメント晒すスレ落ちちゃったね
612:仕様書無しさん
07/09/27 10:39:22
建てようとしたら規制かかってたorz
613:仕様書無しさん
07/09/27 12:28:48
"俺はもうだめだ・・・あとは・・・頼む・・・ぞ・・・・"
614:仕様書無しさん
07/09/27 13:07:36
コメントスレ需要有るんなら立てよっか
615:仕様書無しさん
07/09/27 13:10:00
立てた
コメント関係はこっちでよろ
ｽﾚﾘﾝｸ(prog板)
616:仕様書無しさん
07/09/27 23:19:45
c++でさ。メンバ変数ってどれぐらい公開する？
１） 全て非公開private or protected
２） 状況によりけり
３） 全て公開 public
俺は今まで、３は有り得ないと思ってたんだけど、
どのソースも３ばっかなんだ。誰か何とかしてくれ……
617:仕様書無しさん
07/09/27 23:21:24
(1)のつもりで作る
流動的に(2)へ移行することもある
618:仕様書無しさん
07/09/27 23:22:55
C++じゃgetメソッドいっぱい作っても使いにくいだけだし
619:仕様書無しさん
07/09/27 23:30:41
俺のいる職場のjavaでかかれたコードは
public static だらけだよ。
public final static String sShopNo = "ShopNo"; とか言うのがズラーっと並んでて、
文字列連結の + でつないでSQL文をつくってる。
620:仕様書無しさん
07/09/27 23:32:50
(1)だろ
(2)だって可能な限り避ける
(3)は確かに辞めたくなる...
621:仕様書無しさん
07/09/27 23:35:14
全部公開ってstructじゃん
622:616
07/09/27 23:42:58
やっぱそうか……色々といいたいことはあるコードばっかなんだが、やっぱりそうなんだな。
あと、もう一つ気になるところがある。
この会社では、同じ処理を書くときに、一から書き直す風習があるんだわ。
これもどうかなぁ……って思ってしまうよ。
623:仕様書無しさん
07/09/27 23:45:38
コピペじゃなくて新しく書くってこと？
624:仕様書無しさん
07/09/27 23:58:18
>>623
イエス。全く処理内容が同じなのに、新しく書き起こしている。
理由がさっぱり分からん。
625:仕様書無しさん
07/09/28 00:02:08
ステップ数(笑)稼ぎ
626:仕様書無しさん
07/09/28 00:10:24
>624
版管理とは別な意味でソースコード管理が下手なのかも。
「自社のコード」を蓄積しないで、「顧客に納めるコード」ばかり書いていて
結果、別PJで書いたコードは流用できないから毎回フルスクラッチとか……
627:仕様書無しさん
07/09/28 00:23:02
>>624
元のコードに問題が見つかったとか。
少しでも改善出来る部分があったとか。
新人の練習台にしてるとか。
そうでもしないと余る人員がいるとか。
628:仕様書無しさん
07/09/28 00:23:09
>>626
正解かも……
あれだ。顧客に納めるで思ったんだが、ソース納品な案件があれば少しは変わるような気がしてきた。
まぁ、あんなコードは外部に見せられないけど……
629:仕様書無しさん
07/09/28 00:25:05
>>627
そういうんじゃないんだよ。
例えば、ログ出力処理があったとするだろ。
そしたら、ある場合はグローバル関数にかかれてたり、ある場合はクラス化されてたり、
ある場合はダイアログクラスのメンバ関数に埋め込まれていたり。DLLになってたり……
いや、全部同じ処理なんだぜ。全く……何回読んでもこぴぺで良いじゃんって思えるコードなんだぜ……
630:仕様書無しさん
07/09/28 00:26:39
おっと、途中で投げてしまった。
そんなだから、人員が余る・新人の練習以外は全て違うんだよ。
ちなみに、中途採用ばかりで新人もいない会社だから、その理由で新人の練習という理由もない。
いつも人員不足で悩んでるところだから、人員が余るもない。
631:仕様書無しさん
07/09/28 00:27:58
>>629
いや、そこはコピペじゃなくてＤＬＬでいいじゃんとかクラスでいいじゃんじゃないのか？
632:仕様書無しさん
07/09/28 00:31:53
>>631
そうなんだけどね。要はつまり、とにもかくにも再利用しないとこだと言いたかった。
633:仕様書無しさん
07/09/28 00:37:49
カプセル化って大原則だと思ってたが
案外、世の中には浸透してないのか？
カプセル化されてないソースを読むなんて神業だろ。
634:仕様書無しさん
07/09/28 00:45:24
>638
日本は神の国で八百万の神が、ってのはあながち嘘でもないってことか
あれを読む程度で神と言えるのなら……
635:仕様書無しさん
07/09/28 00:47:10
八百万ステップなら神
636:仕様書無しさん
07/09/28 00:50:19
ロギング処理がダイアログのメンバ関数。
プログラミングできない連中麦価なんじゃないか？ 単純に
637:仕様書無しさん
07/09/28 01:31:18
ダイアログごとにロガーがあるのか？
638:仕様書無しさん
07/09/28 01:33:21
ぬるぽ
639:仕様書無しさん
07/09/28 01:34:43
>>634はこの３文字からあれだけの情報量を読み取ったのか
640:仕様書無しさん
07/09/28 01:41:22
妄想が激しすぎるな
641:仕様書無しさん
07/09/28 02:01:37
上司 『こんなところでレス返してる暇があったら、もっとステップを稼げッ』
642:仕様書無しさん
07/09/28 02:50:46
ステップ♪ステップ♪ランランラン♪
643:仕様書無しさん
07/09/28 02:54:57
また1名旅立たれたようです
644:仕様書無しさん
07/09/28 21:49:46
「来週あたり各自宅のPCの検査いくんで」
これはない
645:仕様書無しさん
07/09/28 23:48:48
void reduce(int*number, int*denom){int a,b,tmp; a=abs(*numer);
b=abs(*denom); /*a>=bとなるように入れ替える*/ if(a<b){tmp=a; a=b;
b=tmp;} /*互除法で最大公約数を求める*/ do{tmp=a%b; a=b; b=tmp;}
while(b!=0); /*約分する*/ if(a>1){*numer/=a; *denom/=a;}}
実際は途中改行なしで1行1関数
最初見たときプロトタイプ宣言が並んでるのかと思ったら
関数定義だからびっくりしたわ
646:仕様書無しさん
07/09/29 00:06:49
そして、それらは全てコメントアウトされていた。ってオチとか
647:仕様書無しさん
07/09/29 00:33:46
>>644
winny関連？家庭訪問みたいでやだなｗ
648:仕様書無しさん
07/09/29 00:37:12
>>644
それは上司の自宅へも行くのか？
649:仕様書無しさん
07/09/29 02:17:23
hoge.asdf(fuga);
x
piyo.method();
果たして彼は x と書いてある行にあった文字列を切り取り出来たのであろうか・・・・。
650:仕様書無しさん
07/09/29 02:39:46
辞めようとは思わないソースだけどｗ
ってかコンパイル通らなくね？defineされてるとか？
651:仕様書無しさん
07/09/29 02:43:04
>>645 改行がアレだけど、中身は以外と、まともっぽい。
652:仕様書無しさん
07/09/29 03:12:53
>>557
亀レスだが、
Xbox360のバグまみれソフトだった、カ○ドセプトサー○がそうだったらしい。
なにしろ、Releaseビルドだと、起動すらしなかったとか。
冗談だろ・・・って言ったら、冗談じゃねぇ・・・と言われたときはさすがにあきれたねぇ。
ちなみに聞いた奴はあのバグまみれ騒動以来会社辞めたらしい。(そりゃそーだ)
653:仕様書無しさん
07/09/29 08:51:25
>>633
うちの職場でもそうなんだけど
世の中はカプセル化を否定する方向に向かっているよ
URLﾘﾝｸ(www.arclamp.jp)
654:仕様書無しさん
07/09/29 09:53:22
カプセル化不要な方向に進んでいるのはあるけど、データの分離は別の話だと思うが？
しかし、プログラマのレベルが低すぎるからこそカプセル化が必要なんだと思われ。
655:仕様書無しさん
07/09/29 10:57:57
>>653
世の中もなにもその記事だけじゃん。
URLﾘﾝｸ(capsctrl.que.jp)
656:仕様書無しさん
07/09/29 13:06:17
>>653
…つまらん。
657:仕様書無しさん
07/09/29 21:46:25
VBだが文字列の切り出しに何でもかんでもMid使ってる
Mid(str, 1, 1)……ってLeft知らんのかこいつは……
658:仕様書無しさん
07/09/29 21:51:13
てか、VBの場合ついLeft$, Mid$, Right$, String$って書いてしまうのは漏れだけか？
659:仕様書無しさん
07/09/29 22:08:31
ロートル
660:仕様書無しさん
07/09/29 22:44:57
>658
｢1｣が変数なら間違いとは思わんが、直値なら･･･
まぁいいか、VBならｗ
661:仕様書無しさん
07/09/29 22:51:57
$つけないとVariant型が返ってくるぜ
662:仕様書無しさん
07/09/29 23:02:41
>658
ﾉｼ
……でも元ソースが全体に$なしがはびこってたり
そもそも、「そんなに文字列と数値をごたまぜで扱いたいならPerlで書けよ」
って言いたくなるよーなのだと諦めて$なしで書くorz
String型で計算の時だけCCurかましてずーーーーっと数値保持してるのを見たときなんてもうね(つ´д｀;)
663:仕様書無しさん
07/09/29 23:02:59
今調べたんだけど Mid てステートメントもあるんだね。
664:仕様書無しさん
07/09/29 23:08:37
>>657
Leftって文字列を扱うクラス以外にもあったから
VB6みたいにLeft()って書いてもエラーになる
名前空間とクラス名を指定しないとダメだから
そいつは使えないと判断したんじゃね
665:仕様書無しさん
07/09/29 23:38:15
えーっと VB.NET？
666:仕様書無しさん
07/09/30 01:34:01
microsoft.visualbasicはいらんぜよ
667:仕様書無しさん
07/09/30 01:36:03
VS2005は無料版があるけど、インストールがﾏﾝﾄﾞｸｾｰから試してねぇな
仕事で使ったことも無いな
668:仕様書無しさん
07/09/30 02:00:25
VC6のときのPlatformSDKがほしい
669:仕様書無しさん
07/09/30 02:08:42
VSEE2008インスコしたけど・・・どうなの？
670:仕様書無しさん
07/09/30 02:45:19
>668
CD取り寄せできるお
Feb 2003がVS6対応最後のPlatformSDK
めりけんからの送料掛かるけどなorz
671:仕様書無しさん
07/09/30 09:23:37
>>662
VB6の本質はVariantだった。
それが理解できずに普通の型チェックを期待して四苦八苦した時期がありました・・・
672:仕様書無しさん
07/09/30 10:32:47
単発ならLeft$使うけど
周囲にMid$があるなら敢えてMid$統一しておく
VB6の案件は厨や新人にお鉢が回るかもしれんから
673:仕様書無しさん
07/09/30 10:42:44
>>657
そのレベルだとどっちでもいいと思うが・・・
どっちかってとあとは本人の好みの問題。
674:仕様書無しさん
07/09/30 13:18:33
Midが周囲で使われてるからって、leftをmidに直しても、何もいいことないだろ?
675:仕様書無しさん
07/09/30 13:54:25
可読性があがる
VBで開発する以上、低スキルな保守要員が宛てがわれる可能性は考えとくべきじゃね？
昨日HelloWorldした新人でも違いが解りやすいじゃん
676:仕様書無しさん
07/09/30 14:10:24
Mid(str, 1, 1) なんて書いてあると、何か意味があるのかと悩んでしまうな。
意味がわかるような関数を使おう。
似たような事例で、PEARに登録されているPHPのライブラリのひとつだが、
こんなん書いてあって意味がわからなかった。
substr_replace('string', 'replace', 0, 0);
関数の意味は名前のとおり、第三引数はstart、第四引数はlength
実際のコードは第一引数は文字列の配列だった。
677:仕様書無しさん
07/09/30 14:20:44
何か意味があるのかと悩む理由が解らんな
自作関数ならともかく。
678:仕様書無しさん
07/09/30 14:21:35
それはお前が何も考えて無いからだなｗ 低脳コーダー乙
679:仕様書無しさん
07/09/30 14:30:49
新人でも文字列操作関数ぐらい全部わかるだろｗ
680:仕様書無しさん
07/09/30 14:32:07
動けばどっちでもいいと思うけど。
くだらん
681:仕様書無しさん
07/09/30 14:52:47
>>644
ありえねぇーｗｗｗｗ
んなこと言うような企業は間違いなくDQN
682:仕様書無しさん
07/09/30 15:04:22
>>644
言われても嫌だが、ソースコードに書いてあっても嫌だな...
683:仕様書無しさん
07/09/30 15:30:55
>>680
仕事なら、動くだけじゃだめだろ。
684:仕様書無しさん
07/09/30 16:05:16
>>683
仕事なのに「動けばいい」「スパゲティだからってゼロから作り直すのは駄目」とか
それなのに「機能追加しろ」とか言われ、選手交代になった派遣社員が通りますよ…
685:仕様書無しさん
07/09/30 16:54:10
>>675
いや、可読性下がるんじゃね?
686:仕様書無しさん
07/09/30 16:57:46
leftとmidを混在させないで、midに統一したら読みやすくなるって説は、
leftとmidの機能を思い出しながら読むのが大変って意味か?
687:仕様書無しさん
07/09/30 17:19:45
固定長テキストファイルを読み出すときに、
Left$(str, 10)
Mid$(str, 11, 10)
～
Mid$(str, 101, 10)
とかずらずら書いて、一番上のLeft$をMid$にしたら、
引数の数もそろって綺麗なんじゃね？ って10秒くらい考えたけど、
ばかばかしいのでそのままテストをした覚えはある。
688:仕様書無しさん
07/09/30 17:25:28
あー位置が揃うとか、そういう意味か。
689:仕様書無しさん
07/09/30 17:30:08
この場合だったら
for i = 1 to 10
hoge(i) = mid$(str, i*10+1, 10)
next
とか書けばすっきりじゃね？
690:仕様書無しさん
07/09/30 17:53:27
若人の俺は、VBのファニー文字みたいな奴がよくわからん。
体型立てて勉強しようにも、そういった資料が少なくない？
691:仕様書無しさん
07/09/30 17:56:27
ファニー文字って、$とか%とか?
ヘルプに載ってるんじゃないの?
692:687
07/09/30 18:47:14
>>688
そういう意味で悩んだけど、可読性があがるとは今でも思わないな俺は。
>>689
昔のコードなんで覚えてないからてきとーに書いたんだけど、
文字長ばらばらで、forでまとめるわけには行かなかったと思った。
そうであって欲しい。 そうでなければ悲しすぎる。
693:仕様書無しさん
07/09/30 18:57:52
もし使ってる言語に、midやらsubstring相当の機能しかなかったら、leftやらrightやらって
ルーチンを自作して使う。
機能が限定されてるルーチンのほうが意図が伝わるから。
694:仕様書無しさん
07/09/30 19:19:42
顧客 「開発方法はLyeeとありますが？」
カテナ「はい。Lyeeです。」
顧客 「Lyeeとは何のことですか？」
カテナ「理論です。」
顧客 「え、理論？」
カテナ「はい。理論です。開発期間が従来の5分の1～10分の1です。」
顧客 「・・・で、そのLyeeは当社での開発で何のメリットがあるとお考えですか？」
カテナ「はい。設計もテストも不要です。」
顧客 「いや、そもそも設計やテストは貴社の担当です。それに設計書が無いのは不安ですね。」
カテナ「でも、業務知識がなくても開発可能ですよ。」
顧客 「いや、可能とかそういう問題じゃなくてですね・・・」
カテナ「ドキュメント量が100分の1ですよ。」
顧客 「ふざけないでください。それに100分の1って何ですか。だいたい…」
カテナ「1%です。保守資料無しとも考えられます。深層心理においては…」
顧客 「聞いてません。帰って下さい。」
カテナ「あれあれ？怒らせていいんですか？使いますよ。Lyee。」
顧客 「いいですよ。使って下さい。Lyeeとやらを。それで満足したら帰って下さい。」
カテナ「運がよかったな。今、撤退を決めたみたいだ。」
顧客 「帰れよ。」
695:仕様書無しさん
07/09/30 20:14:58
>>694
Lyeeでググってみたけど、ＵＭＬからソースコード生成するのと似たようなもん？
完全生成できたとしてもシステムテストとかはするよな、普通。
696:仕様書無しさん
07/09/30 21:58:53
思い出した！
VBで「こうやんないとうまく動かない」みたいな(正確には覚えてないけど)関数名があった。
コメントならまだしも、勘数名でこれとは...
697:仕様書無しさん
07/09/30 23:08:32
>>694
普通はこうなる。
顧客 「開発方法はLyeeとありますが？」
カテナ「はい。Lyeeです。」
顧客 「Lyeeとは何のことですか？」
カテナ「理論です。」
顧客 「え、理論？」
カテナ「はい。理論です。開発期間が従来の5分の1～10分の1です。」
顧客 「つまりその分開発費用も安くなると言うことですか。すばらしい。よし採用。けってーい。」
まあ、Lyeeなんてしらんがなｗ
698:仕様書無しさん
07/10/01 01:06:28
Lyeeって情報システム板でやたらスレが荒れてた記憶があるな。
699:仕様書無しさん
07/10/01 02:31:13
だってあれは・・・良く見てみれば。プリコンパイラにしか過ぎない。
700:仕様書無しさん
07/10/01 03:52:55
てｓｔ
701:仕様書無しさん
07/10/01 12:41:33
>>670
URLﾘﾝｸ(www.microsoft.com)
702:仕様書無しさん
07/10/01 21:10:18
>>670
>>701
スレ違いになってしまったけどサンクス
これでCPANの古めのモジュールがmakeできるかもしれん
703:仕様書無しさん
07/10/02 22:02:30
>>696
そういえばあの関数なぜかうまく動かないからその関数は自分で作ったよ。
傍から見たらライブラリにあるのになんで？って思われるだろうな。
704:仕様書無しさん
07/10/05 01:03:37
Cで関数定義の頭に概要の説明が書いてあるソースがあった。
/* -- 概要
共通ログ出力関数
呼び出し方法: void logfunc(int errcd, char *funcname);
引数:なし
戻り値:0:正常 -1:異常
*/
void outlog(int errcd, char *funcname)
{
...以下定義
もう一つ
/*
呼び出し方法: int func(void)
戻り値:0:正常 -1:異常
*/
void func(){/* 定義 */}
..で実際の呼び出し箇所にいくと
func("XXXX");
1つ2つならまだいいけど、万事がこんな感じ。コメントウソ書きすぎ。
わざとやってるんじゃないかと疑いたくなってくる。
705:仕様書無しさん
07/10/05 02:41:57
「苦肉の策」とか「後で修正しておくこと」とかもう諦めてるんだけど、
「苦肉の策！(笑)」とか「後で修正する必要アリ(´д｀)」とかになってるとマジ辛い。
昨日も昼ごろ似たようなコメント見つけて午後ずっと気分悪かった。
706:仕様書無しさん
07/10/05 09:18:07
気持ちに余裕がないのね
707:仕様書無しさん
07/10/05 09:34:42
URLﾘﾝｸ(www.atmarkit.co.jp)
どれを削除したらいいか判断できないような混沌としたプロジェクト
Ｃ＃ってこんなのが普通なのか？
708:仕様書無しさん
07/10/05 10:51:30
>>707
コーディング規約や開発者のコード管理能力の問題だろ。
C#に限らず、どんな言語を使ったって、混沌とさせる奴はいる。
それを解決できるツールがたまたま（同じ必要性を感じた）先人によって作られているか、
そんなツールを見つけられるかどうかで、問題を糊塗できるかどうかの違いだけだ。
709:仕様書無しさん
07/10/05 13:04:25
>>708
C#だからひどくなったんでしょ
710:仕様書無しさん
07/10/05 13:10:19
>>708
スレタイ嫁
711:仕様書無しさん
07/10/05 13:39:25
>>708
何が原因でそんな混沌としたプロジェクトになったかなんて興味なくて、
そいうプロジェクトにいたら会社辞めたくなるだろうなってことだよ。
Ｃ＃は知らないけど、Ｃ＃だからこそ何を削除したらいいか検索するのが不可能って流れになってるじゃん。
少なくともＣ＋＋やＶＢだったら不要メソッドのリストアップは簡単に出来ただろうにね。
（Ｊａｖａも知らないけど、Ｊａｖａもそうなのか？）
Ｃ＃コワーｗ
712:仕様書無しさん
07/10/05 14:15:41
コードの7割くらいがコメントアウトされた過去のコードのプロジェクトに入れられた…
#if 0～#endifで除外されたブロックも多数あって発狂しそう orz
713:仕様書無しさん
07/10/05 14:36:27
スレ違いっぽい話題を引きずることになるかも知れないけど
C++やVBだと不要メソッドのリストアップにどういう方法があるの？
714:仕様書無しさん
07/10/05 14:59:20
うちはVB厨だが、これを使ってる
URLﾘﾝｸ(www011.upp.so-net.ne.jp)
715:仕様書無しさん
07/10/05 16:09:54
＞Ｃ＃だからこそ何を削除したらいいか検索するのが不可能って流れになってるじゃん。
どこにそんな流れがあるんだ
716:仕様書無しさん
07/10/05 16:13:01
>>713
ググレカス
717:仕様書無しさん
07/10/05 16:14:38
つーか、リフレクションを駆使するようなチームだったら、コードをクリーンに保つくらいすると思うんだが。
718:仕様書無しさん
07/10/05 16:51:09
>>715
C#嫌いが嵩じて幻覚でも見てるんじゃ
719:仕様書無しさん
07/10/05 17:00:20
>>713
VBでこれ使ってる。
URLﾘﾝｸ(www.aivosto.com)
Cならsplint、C++は昔なんか使ってたような気がするけど忘れた。
720:仕様書無しさん
07/10/05 22:33:55
不要社員のリストアップに
721:仕様書無しさん
07/10/05 23:41:32
>>708
この前、fxcopとかってツールをためしに使ったら、使われてないメソッドとかは指摘されてたような。うろおぼえ。
722:仕様書無しさん
07/10/05 23:41:46
>>711
C++はおろか、Javaや最近のVBですらリフレクションが実装されていることを知らないこと、
それ以前に問題の本質を見つけられない濁った目、そして文中に漂う全角アルファベット、
おまえ、もしかしてコボラだなww
723:仕様書無しさん
07/10/05 23:47:35
こぼらがいっぴき
こぼらがにひき…
この辺で…俺のはじめてのプロジェクトは火を噴いてあたりを転げまわりだした。
724:仕様書無しさん
07/10/06 00:02:02
ぇ、C++ってリフレクションあったっの? C++/CLIじゃなくて?
725:仕様書無しさん
07/10/06 00:02:49
>>707
関係ないが、そこで、上から目線で教えてやってるジッタってやつは、よそのスレで、ツッコミ入れられまくってたヤツだな。
このエントリで。
URLﾘﾝｸ(blogs.wankuma.com)
726:仕様書無しさん
07/10/06 00:22:24
本当に関係ねえ
727:仕様書無しさん
07/10/06 08:20:06
>>725
先輩だか上司だかに、添削と言って、こんなソースにされたら、やめたくなるよ。
728:仕様書無しさん
07/10/06 14:14:55
dim strTemp(10) as string
const intTemp as integer = 10
for i as integer = 1 to intTemp
strTemp(i) = ""
'処理
next
729:仕様書無しさん
07/10/06 14:17:15
どの辺が気に入らないんだろう
730:仕様書無しさん
07/10/06 14:30:39
VBなところ
731:仕様書無しさん
07/10/06 14:35:35
for i as integer = 0 to intTemp
732:仕様書無しさん
07/10/06 14:53:15
for i as integer = LBound(strTemp) to UBound(strTemp)
733:仕様書無しさん
07/10/06 15:03:54
ＶＢの文字列って初期化されてることが保障されてなかったっけ？
734:仕様書無しさん
07/10/06 15:06:03
for i as integer = 0 to intTemp-1
735:仕様書無しさん
07/10/06 15:12:03
綺麗なコーディングしてるだろ
バグってるんだぜ、これで…
736:仕様書無しさん
07/10/06 15:30:29
>>733
保障されてる
737:仕様書無しさん
07/10/06 19:51:32
VBって確か、
配列宣言時に指定する数が、
要素数じゃなくて添字の最大値なんだよな
738:仕様書無しさん
07/10/06 20:15:39
dim a(3) なら a(0) ～ a(3) だっけ？
昔のベーシックで a(0) を無しにしてメモリを節約するとかいう
セコいオプションがあったような記憶がある。
739:仕様書無しさん
07/10/06 20:21:04
VBでは、option base で配列の添字を 1～にするか0～にするか変更できる。
740:仕様書無しさん
07/10/06 20:59:49
もうすぐ64ビットが当たり前になる時代にそんなオプション意味あるんか？
741:仕様書無しさん
07/10/06 21:32:07
メモリの1バイトは血の一滴だ！
742:仕様書無しさん
07/10/06 21:39:56
おしい
血より精液のほうが説得力あったのに
743:仕様書無しさん
07/10/06 21:40:28
初期化が保証されてても初期化、ということにはあまり文句は言わない
でも過保護言語のVBだし事情が違うのかな
744:仕様書無しさん
07/10/06 21:43:52
初期化で思い出したけど
MFCとかでポインタ先が破棄済みかどうかに( pTest )ってやってるの困る
解放後の0割り当てなんてコード全体で徹底するのか？
いずれにせよMFC内部で delete this とかやるのあったらダメ
745:仕様書無しさん
07/10/06 22:06:11
メモリ管理もろくに出来ない無能な人間のための言語というアピールはひしひしと感じる
便利だから使うんじゃない，それしか使えないんだ，てな
746:仕様書無しさん
07/10/06 22:26:48
管理以前にそもそもメモリの概念が分かっていません。
747:仕様書無しさん
07/10/06 22:34:13
メモリの節約、スレッドの節約、etc...
748:仕様書無しさん
07/10/07 00:07:44
給料の節約、残業代の節約、etc...
749:仕様書無しさん
07/10/07 00:10:42
>>744
> 内部で delete this とかやるのあったらダメ
そうか?
750:仕様書無しさん
07/10/07 03:47:54
>>725
相当に疑わしい人間だな。
751:仕様書無しさん
07/10/07 07:16:38
> 解放後の0割り当てなんてコード全体で徹底するのか？
逆に delete して NULL 入れてないやつはぶっ殺したくなる
752:仕様書無しさん
07/10/07 08:29:44
自所持ﾎﾟｲﾝﾀをNULLにしたところで
その参照先を他のやつもﾎﾟｲﾝﾀで参照してたら・・・・そっちが自動でNULLになってくれるわけじゃないから
NULL当てはめて安心するなんて無意味っちゃ無意味
753:仕様書無しさん
07/10/07 09:22:50
意味不明。
自ポインタで必要なくなった参照先は、他のやつでも必要なくなるって決め付けてるのか？
そんなもん、プログラムのロジックによりけりだと思うが。他では保持する必要があるかもしれないし。
NULL当てはめて安心したいのは、処理が他の参照先に移ってるのに自ポインタが保持してるせいで
誤ってアクセスするというようなことを起こさないための防衛策もあるだろ。
「この会社辞めようと思った」の９０％くらいは真実だと思うが、１０％くらいは「辞めようと思った」奴の
レベルが低すぎるんじゃないかと思うことがある。
754:仕様書無しさん
07/10/07 09:53:34
言ってることが全然分からんな。
よほど内部・詳細設計が腐っていると見える。
755:仕様書無しさん
07/10/07 10:57:20
>>751
そんなことするのヘタクソだけだろ。
756:仕様書無しさん
07/10/07 10:59:49
Javaで、1000行以上のメソッド（この時点でどうかとおもうが）を抜ける時に
一々オブジェクトにnullを入れて片付けているのを見たとき。
そんなどうでもいい気を使う前に、そのくそ長いメソッドを見直せと。
757:仕様書無しさん
07/10/07 11:07:22
Javaは変数スコープ明確にしてGCに任せるだけだから楽だな
758:仕様書無しさん
07/10/07 12:32:51
gcなんて訳の分からんもんによくお任せできるな
お前は通りすがりのオヤジに家の留守番を頼めるのか？
759:仕様書無しさん
07/10/07 12:40:28
いや、javaは別にgc依存でいいんじゃないか？
そういう言語なんだし。
760:仕様書無しさん
07/10/07 12:50:25
>>753
deleteした場合の話だろ？
761:仕様書無しさん
07/10/07 13:00:12
同じアドレスを共有しているポインタがあるのに delete するって
それだけで重大な設計ミスだな
所有権移行なら、delete せずに権限渡して
自分のポインタは NULL 設定とかする(auto_ptr がこうなってるな)し、
複製ならオブジェクトのコピーするだろ、普通
複数箇所で共有するなら、いいからスマートポインタ使っとけって話だし
762:仕様書無しさん
07/10/07 13:06:13
>>757
スマートポインタも使わないのか？
参照カウンタだって立派なGCだが。
763:仕様書無しさん
07/10/07 13:13:28
>>758
それを言い始めたらコンパイラも実行環境も何もかも信用できなくなるよ
764:仕様書無しさん
07/10/07 13:42:04
ぬるぽ
765:仕様書無しさん
07/10/07 13:48:08
お前らはデンマークの2流都市出身の禿や
カナダの糞田舎で育ったキモいオッサンの作った言語なんて信用できるのか？
766:仕様書無しさん
07/10/07 14:02:00
malloc/freeのペアを使っていた時代は、freeの後にNULLは設定していたなー
論理的な異常処理とかでやむを得ず処理を終了する場合は、
ポインタ参照用変数がNULLじゃなけりゃ取りあえずfreeしまくってexitしていた。
まぁ、三つ子の魂百までじゃないけど、たまにそうコーディングして苦笑する事が最近はある。
767:仕様書無しさん
07/10/07 14:07:25
最初に疑うべきはいつの時代でも自分のコーディングだけどな！
768:仕様書無しさん
07/10/07 14:34:45
ポインタをNULLクリアしなきゃならないコードの書き方を疑え。
769:仕様書無しさん
07/10/07 15:01:04
>>763
どんなコンパイラも実行環境も最初は通りすがりのおっさん程度の信頼性しかないものだ。
それが大勢に使われて、もまれて、信頼できる警察官になるんだよ。
770:仕様書無しさん
07/10/07 16:00:39
いまどき C++ で自分で delete 書いてる時点で何かおかしいと疑ったほうがいい。
std::auto_ptr, boost::scoped_ptr, boost::shared_ptr で全部済ませとけ。
771:仕様書無しさん
07/10/07 16:12:58
boost の利用は標準に取り込まれてから考える
772:仕様書無しさん
07/10/07 16:52:43
std::auto_ptr を delete 書くのを省くためだけに使うんだったら帯に短し襷に長しだな
773:仕様書無しさん
07/10/07 17:17:30
>>772
へ？その目的で使ったら十分だと思うよ。
本人の意思とは関係なく例外安全性が付いてきたりするけど、別に余計なもんじゃないし。
774:仕様書無しさん
07/10/07 17:32:33
まぁでもエラー処理とか例外安全とか一切考慮してないような自作スマートポインタクラスを使うのもなぁ～
775:仕様書無しさん
07/10/07 17:33:38
普段ウォシュレットを使い慣れている奴はたまに駅の便所で拭かずにパンツを上げるらしい。
もしくは美味く拭けずに手にウンコ付けまくりんぐとか。
一番多いのが、ちゃんと拭いて流したつもりでも毛に残ったウンコでパンツが黄色いとかだな。
776:仕様書無しさん
07/10/07 17:57:15
エクセルが信用できないので計算機で出した値を手入力してます
ＧＣが信用できないので（ry
777:仕様書無しさん
07/10/07 18:12:18
GCはいつインスタンスが破棄されるか分からんのでデストラクタ使い辛いのがなぁ・・・
778:仕様書無しさん
07/10/07 18:33:56
ところでここはいつから"この会社辞めようと思った自分の一言"スレになったのですか?
779:仕様書無しさん
07/10/07 18:41:25
>>778
知るか。どうでもいい事書くな！ヴぉけ
780:仕様書無しさん
07/10/07 18:41:26
javaやC#も、スコープ抜けたら、デストラクタ(相当)がコールされる仕組みを作ってくれたらいいのに。
メモリ以外のリソースの開放がかえってめんどくさくなったな。
781:仕様書無しさん
07/10/07 18:41:49
1メソッドだらだら1000行とか書くやつは害虫としか思えん。
自分が辞めるよりそいつを駆除したほうがいいだろ普通。
782:仕様書無しさん
07/10/07 18:51:41
>>780
javaならファイナライザがあるよ
783:782
07/10/07 18:52:39
と思ったけど動くタイミングが微妙だな
784:仕様書無しさん
07/10/07 19:52:52
C++/CLIを使えばいいじゃない
785:仕様書無しさん
07/10/07 20:00:32
>>775
普通はウンコ吹いてからウォシュレット使うでしょ
786:仕様書無しさん
07/10/07 20:01:12
>>780
C#のusingでスコープ囲む奴じゃダメ？
787:仕様書無しさん
07/10/07 20:04:38
>>785
最初にウォシュレットで残留物を洗い流してから、
紙に色が付かなくなるまでふきふきしてる。
788:仕様書無しさん
07/10/07 20:13:15
>>786
usingでもいいけど、開放したいのが複数あったらネストが深くなるからね。
using (IDbConnection conn = new ・・・) {
conn.Open();
using (IDbCommand cmd = conn.CreateCommand()) {
cmd.CommandText = "・・・";
uding (IDbDataRedader reader = cmd.Execute・・・） {
while (reader.Next()) {
・・・
}
}
}
}
C++/CLI や D みたいにやれたらいいのに。
789:仕様書無しさん
07/10/07 20:15:33
>>787
それだと横に飛び散る様な気がするから俺は、>>785派
790:仕様書無しさん
07/10/07 20:33:57
>>788
順序は無視して、単純に開放したいのが複数あるときは
using( ... )
using( ... )
{}
って出来たと思う。的外してたらすまんす。
791:仕様書無しさん
07/10/07 20:58:01
exit(-1);
792:仕様書無しさん
07/10/07 22:11:26
>>777
デストラクタは破棄される自分自身が保持してるものをアボンヌする「のみ」・・・のはずだから
まぁタイミングなんて別にいいじゃん・・・・。いや実際処理入れられるけど、出来るけれど
793:仕様書無しさん
07/10/08 00:04:26
自分の持っているもののみを開放するのみとは言え、
class CFile {
public:
CFile() : m_fileptr(NULL) { }
~CFile() { Close(); } // まさに開放するのみ
bool OpenForRead(const std::string &path);
bool OpenForReadWrite(const std::string &path);
void Close();
private:
FILE *m_fileptr;
};
CFile *file = new CFile();
file.OpenForReadWrite("/tmp/hoge");
// ここで GC の対象になったとして
CFile *file = new CFile();
file.OpenForRead("/tmp/hoge");
OpenForReadWrite, OpenForRead は
Reader-Writer Lock で flock かかるとして、
OpenForRead が成功するか失敗するかわからん、
というのが悩みどころなのでは。
いや、この場合は明示的に Close してやればいいんだけど。
# C/C++ しかわからんので C++ + GC という謎の物体でスマン
794:仕様書無しさん
07/10/08 00:16:00
実処理の発動はともかく破棄権を与えるタイミングは把握できるはずだから問題ない・・・と思うんだけど
795:仕様書無しさん
07/10/08 03:43:17
># C/C++ しかわからんので C++ + GC という謎の物体でスマン
途中まで読んで、最近はgc付きのC++なんてのがあるのかと思ったぞ
796:仕様書無しさん
07/10/08 03:54:21
// cnt が 0 より大きかったら処理する
if (cnt > 0) {
}
797:仕様書無しさん
07/10/08 04:00:34
if (cunt < dick) {
// や～ん、こわれちゃう！
}
798:仕様書無しさん
07/10/08 05:34:57
デバックの結果、不等号の向きが逆、ってのはよくある話で
799:仕様書無しさん
07/10/08 07:00:58
// 余計な物がありますよ
if( a < 20 );
{
return hogehoge.detteiu( pero-n, a );
}
800:仕様書無しさん
07/10/08 09:40:32
>>796
見りゃわかるから、そんなコメントいらね！ってこと？
もしくは、 0 < cnt のほうが見やすいだろ！ってことか？
801:仕様書無しさん
07/10/08 11:29:35
>>800
そんなこともわからんのも
まずいと思う。
802:仕様書無しさん
07/10/08 12:07:32
>>gc付きのC++
C++/CLI でもこれはやるのかな?
803:仕様書無しさん
07/10/08 12:16:56
>>801
や、すまん。俺も悩んだ。
804:仕様書無しさん
07/10/08 12:21:43
if (cnt > 0) {
}
何の問題もないだろ、
おれもこう書くが？
805:仕様書無しさん
07/10/08 12:26:31
ネタはコメントの方だろ
806:仕様書無しさん
07/10/08 12:29:42
俺の部署のコーディングルールだと直値は禁止なので０じゃなくて
if(cnt > (int)NUMBER_ZERO){
}
とかにしないといけない。
807:仕様書無しさん
07/10/08 12:31:03
> NUMBER_ZERO
808:仕様書無しさん
07/10/08 12:31:41
> if(cnt > (int)NUMBER_ZERO){
> }
> とかにしないといけない。
まったく意味無しのウザイルールだな。
仕様が変わって 1 より大きくなったら、
if(cnt > (int)NUMBER_ONE){
}
ってすべて書き直すんだな。
あほだ
809:仕様書無しさん
07/10/08 12:33:12
古典的な誤りだな
810:仕様書無しさん
07/10/08 12:37:36
別にいいんだけど、NUMBER_ONEとかってセンスないっていうか、
ちょっとウケるな。
そもそもそこを閾値として、THRESHOLDなんたらとかにしておけば、仕様が変わった場合、
その定数の定義を変えるだけでいいが、NUMBER_ZEROだったら、
結局全部探して直さなきゃならないから、全く意味ないと思うが。
811:仕様書無しさん
07/10/08 13:22:51
> 仕様が変わって 1 より大きくなったら、
いやーこうじゃないか？
#if 0
#define NUMBER_ZERO 0
#endif
/* 2007/10/08 nanasi808 */
#define NUMBER_ZERO 1
812:仕様書無しさん
07/10/08 13:34:14
#if 0
#define NUMBER_ZERO 0
#endif
/* 2008/10/08 洋司 */
#define NUMBER_ZERO 1
813:仕様書無しさん
07/10/08 13:35:56
>>811
定数名と内容が一致してないだろ。
ダメダメなコードの典型だと思うぞ。
814:仕様書無しさん
07/10/08 13:38:30
#if 0
#define NUMBER_ZERO 0
/* 2008/10/08 洋司 */
#define NUMBER_ZERO 1
/* 2009/10/08 洋司 */
#define NUMBER_ZERO 2
/* 2010/10/08 洋司 */
#define NUMBER_ZERO 3
#endif
/* 2011/10/08 洋司 */
#define NUMBER_ZERO 4
815:仕様書無しさん
07/10/08 13:39:10
#defineでてきたか・・・、そんなことで#define使うなよ
その部分のソースのみを見て名前から動きが理解できないじゃないか・・・
816:仕様書無しさん
07/10/08 13:40:25
洋司うるさいｗ
817:仕様書無しさん
07/10/08 13:44:01
洋司はもうちょっと検討段階で頑張れよｗ
818:仕様書無しさん
07/10/08 13:46:51
#if 0
#define NUMBER_ZERO 0
/* 2008/10/08 洋司 35歳*/
#define NUMBER_ZERO 1
/* 2009/10/08 洋司 36歳*/
#define NUMBER_ZERO 2
/* 2010/10/08 洋司 37歳、リストラされる*/
#define NUMBER_ZERO 3
#endif
/* 2011/10/08 陳姪用 */
#define NUMBER_ZERO 4
819:仕様書無しさん
07/10/08 13:48:28
そういうところは仕様は絶対かわなんないんだよ。
もしNUMBER_ZERO で定義してるんだったらNUMBER_ONEってのもどっかにあるだろうし。
よほど変なコーディングでない限り、その部分が24になったり10456になったりとか
することはないよ。変わる仕様だったら別な名前でちゃんと定義してるだろ。
自分も>>808と似たようなところだが、
どんな数字も全部そう書くようにする規約があるからわかるんだが
１回しか登場しなくてどうやったって誰が書いてもどんなに仕様が変わっても
そこだけは必ず０から始まるようなものって結構あるんだよ。
たとえばゼロ割を回避するためだったり。
820:仕様書無しさん
07/10/08 13:49:01
引き継ぎcomplete!!
821:仕様書無しさん
07/10/08 13:49:36
>>819
うまいことまとまった。サンクス
822:仕様書無しさん
07/10/08 13:50:52
>>819
元の書き込みはそうだろうが、俺らが文句言っているのは>>808に対してなので、
その辺、勘違いしないでよね！！
823:仕様書無しさん
07/10/08 13:52:10
>>822
>>808 も >>819 も同じ事いってるだろ、ヴぉけ
お前は洋司レベルだな
824:仕様書無しさん
07/10/08 13:53:59
>>819
NUMBER_ZEROってのが一般的に利用するcommon的なソースであって絶対に変化のない物なら理解できる
だが、そのシステムに特化したソース内では利用すべきじゃないと思う
それならば別の名前を付けることもできるだろうし、ゼロってのは数字であって名称ではないし
825:仕様書無しさん
07/10/08 13:54:40
>>823
褒め言葉として受け取っておこう！！
826:仕様書無しさん
07/10/08 13:55:21
おれは洋司とは仕事したくないぞ
827:仕様書無しさん
07/10/08 13:56:00
>>824
そうだね。
そのゼロがなんなのか分かる名前なら意味あるけど、
ただNUMBER_ZEROじゃ、打つのが面倒なだけで、0って直書きするのと変わらない。
828:仕様書無しさん
07/10/08 14:20:27
しかし、これがNUMBER_ZEROでなく(int)NULLだとさらに混沌の度が増す……
829:仕様書無しさん
07/10/08 14:30:39
「FIVEは5か?」は昔からある教訓で、
>>819の考えは適切ではない。
830:仕様書無しさん
07/10/08 14:43:47
定数ゼロを使う場合なんて大半は
マクロ定義改変でゼロ以外に変更してコードの理屈が通るとは考えられないしなぁ
必要かどうか、なら要らないわな
831:811
07/10/08 14:44:24
完全にネタのつもりで書いたのに。マジレスしてるやつは議論の余地があるとでも思ってるのか？恐ろしい。
832:仕様書無しさん
07/10/08 14:45:08
NUMBER_ZERO
この名前に誰も突っ込まないのがなあ。
SECTION_ZEROとかROW_ZEROとかのグループ的な意味を持つ場合ならいいけど
そうじゃないイミフな定数は定義した意味が半減するし
833:仕様書無しさん
07/10/08 14:52:19
>>832
みんな突っ込んでるだろ。
ZEROと書いといて、仕様変更で「0」以外の値になることは考えないのか？という話で。
代案もセンス悪い。
漏れだったら、COUNTER_START_NUM か何か、ZEROを含まず機能を類推できる名前にする。
834:仕様書無しさん
07/10/08 14:55:06
現実に周囲を見回すと、物に名前を付けるって意味について二通りの意識を持つコーダーがいる気がするな
今後の拡張等を踏まえて、利便性を追求するのためにとりあえず名前を付ける人
ソースを分かりやすくするために適切な名前を付けようとする人
で、前者は大抵ワガママなソースになりがちで嫌われると思う
835:仕様書無しさん
07/10/08 14:58:59
＞誰も突っ込まないのがなあ
突っ込んでんじゃん
文盲か？
836:仕様書無しさん
07/10/08 15:02:18
>SECTION_ZEROとかROW_ZEROとかのグループ的な意味を持つ場合ならいいけど
いいのかよｗ
837:仕様書無しさん
07/10/08 15:07:02
釣れるのは雑魚ばかりか
838:仕様書無しさん
07/10/08 15:19:47
関数は５０行ぐらい、多くても１００行までにしてくれ、と言っても
理解できない奴が多すぎて困る。
１０００行とか天才かよと。
839:仕様書無しさん
07/10/08 15:25:22
関数分割って結構難しいと思う。
ノッて書き出すと１関数でずっと続けちゃうし、分割した方がいいと思っても、
バグ発生や見通しが悪くなるのが怖くてなかなか踏み切れない。
できるかできないかがプログラマのセンスの差なんだろう。
840:仕様書無しさん
07/10/08 15:44:21
そういう問題じゃねぇだろ
841:仕様書無しさん
07/10/08 15:44:42
> バグ発生や見通しが悪くなるのが怖くてなかなか踏み切れない。
釣りか？
842:仕様書無しさん
07/10/08 15:48:08
関数分割で見通しが悪くなる、ってどんだけ
843:仕様書無しさん
07/10/08 15:53:07
839だけど、俺くらい技術の低いプログラマだと、そういうレベルで
悩んでしまうってことです。
バグ発生は、同じ変数を他所でいじってるんじゃないかと取り越し苦労して、
見通しが悪くなるのは、機能を適切に分割できなくて、引数が複雑に
なったり、戻り値が凝ってる割にたいしたことやってなかったり拡張性が
悪い物だったりする。
844:仕様書無しさん
07/10/08 16:04:02
分からんなら分かる奴とかPGの取りまとめとかに聞け。
分からんからといって問題を放置されるのが一番タマラン。
845:仕様書無しさん
07/10/08 16:09:31
大きな関数をセンスで分割するというアプローチが既に誤り
目に見えない制約がたくさんあって、それを遵守すると機械的に
小さな関数群になる、という感じ
846:仕様書無しさん
07/10/08 16:16:32
こういうアクションで呼ばれた(たとえば、ボタン A が押された)ら、
「こうしてこうしてこうする」、というのを関数にして、
それぞれの「こうする」をさらに「こうしてこうする」にして…
というのを (OS なり何らかのライブラリなりの) API に達するまで繰り返す
というのを基本としたら、必然的に小さく収まるよなぁ
あー、何か俺自身感覚で分割してるような気になってきた
847:仕様書無しさん
07/10/08 16:47:51
>>844
すいません、今の職場、俺以外にPGいないんです。
社内間接部門で、他の人は仕様とりまとめて俺に卸してきます。コーディングは
Excel の自動生成マクロをちょっと手直しして使えるってれベルです。
プログラムは全部俺に任せるって言われてます。関数分割も含め、日々試行錯誤です。
OSSのソース読んだりして勉強してるつもりなんですが、外に出て実戦するのがいいのかなぁ。
848:仕様書無しさん
07/10/08 17:04:15
初心者が自己流だけでいくのは将来危険。
いろいろ回って経験積んだ人にまかせた方がいいと思う。
その経験積んだ人にまかせるのだって、ほんとは危険。
一人にやらせるってのがそもそも危険。
849:仕様書無しさん
07/10/08 17:21:53
プログラミングは危険。超危険。
850:仕様書無しさん
07/10/08 17:45:19
俺が今日作った関数500行ぐらいある。
疲れた。そして明日からももっと疲れるだろう。
851:仕様書無しさん
07/10/08 17:45:51
もはや釣りかネタとしか思えん
852:仕様書無しさん
07/10/08 18:10:51
>>801
本気でわからんので回答ください。
800 ：仕様書無しさん ：2007/10/08(月) 09:40:32
>>796
見りゃわかるから、そんなコメントいらね！ってこと？
もしくは、 0 < cnt のほうが見やすいだろ！ってことか？
801 ：仕様書無しさん ：2007/10/08(月) 11:29:35
>>800
そんなこともわからんのも
まずいと思う。
803 ：仕様書無しさん ：2007/10/08(月) 12:16:56
>>801
や、すまん。俺も悩んだ。
853:仕様書無しさん
07/10/08 18:17:47
見りゃわかるからだろ
どうでもいいとこにコメント書きまくってる奴に限って
本当に必要な所にはコメントなかったりするんだよな
854:仕様書無しさん
07/10/08 18:22:39
たいてい関数は短くするけど
ロジック的なものじゃなくて力任せにいろいろ構成を書いていく部分のコードだと長くなる 300とか
855:仕様書無しさん
07/10/08 18:34:56
ライブラリとか低位レイヤの関数は短いよね？
業務レイヤになってくると分割が意味を成さないような処理もあるから
ちょっとだけ長くなるよね？ ね？(一連動作を明示する意味もある！？)
短いとか長いとか両極端に走っちゃだめだよね？ ね？
856:仕様書無しさん
07/10/08 18:50:47
>>855
本来、業務ロジックなんか一番短くなってしかるべき
857:仕様書無しさん
07/10/08 19:14:48
長い関数の中の一行を修正しなくちゃならんという時、
その一行で使われている変数が前後でどう使われているか
普通チェックするもんじゃない？
関数が短ければ追っかけなきゃならんロジックが減って
あとで楽できると思うんだが。
俺だったらhoge()っていう300行の関数作らず
100行ぐらいのhoge_a(),hoge_b(),hoge_c()を作って
それを順番に呼び出すだけのhoge()を作るなぁ。
858:仕様書無しさん
07/10/08 19:43:39
>>855
ログ吐く
処理1を呼び出す
結果を見てエラーがあればコードに応じて処理を書く
ログ吐く
ログ吐く
処理2を呼び出す
・
・
・
みたいな感じで長くなることはあるな
859:仕様書無しさん
07/10/08 20:16:01
>>853
おｋ。納得した。
860:wolf ◆8VH3XAqjlU
07/10/08 20:34:59
>>852
// cnt が 0 より大きかったら処理する
if (cnt > 0) {
コメントがここに書いてある６番目の心掛けなければイケナイ事
URLﾘﾝｸ(www.ambysoft.com)
6. Document why something is being done, not just what
何をしているかをコメントにするのではなく、何故そうするのかを書きなさい
に抵触はしていますね
861:仕様書無しさん
07/10/08 20:38:32
「他人に分からせる気はこれっぽっちもない」けど「懇切丁寧ぶったコードには見える」んだよ ククク
862:仕様書無しさん
07/10/08 20:45:29
// cnt が 0 より大きかったら処理する
if (cnt > 0) {
ここの条件分岐が、実際の業務と直接リンクする場合は上のようなコメントを書くと思う。
そういうのはあり？たとえば「じいちゃんがココで死にそうだったら110番する」みたいな。
863:仕様書無しさん
07/10/08 20:48:57
でも0 ゼロだぞ
「○○がまだ残っている場合」とか
そういう書き方にならね
864:仕様書無しさん
07/10/08 20:52:58
>>862
それはありだと思う。
「（金額） cnt が 0 より大きかったら処理する」のように、cnt がもつ情報が類推できるような場合だよね。
ただし、それは他のコードやコメントと読み合わせてはじめて理解できるものじゃない？
コード例だけだと、類推のための手がかりがないから、論争になってるわけで。
865:仕様書無しさん
07/10/08 20:55:34
変数名がcntだから、count=「個数」であることは確か(なはず)なので、
金額は例としてはまずいな。
しかし、個数である場合に、
「あれば～」とか「残っていれば～」
などでなく本当に
「0より大なら～」
というコメントにすべき例を思いつかない。
866:仕様書無しさん
07/10/08 20:57:45
カウンタ絡みのテキトー変数名でcntがついても不思議じゃない
867:仕様書無しさん
07/10/08 20:58:05
つまり、cntが何を表すか、処理ってどんな処理か書けっって言いたいんだろう。
>>862 でいう「じいちゃん」とか「110番」って情報が抜けてる。
868:仕様書無しさん
07/10/08 21:01:41
// まだ在庫があれば、賞味期限を確認する
if (cnt > 0) {
/*賞味期限確認*/
}
869:仕様書無しさん
07/10/08 21:20:24
// cntが0以上だったら処理する
// 19XX.X.X. レビューで修正
//if (cnt > 0 || cnt == 0) {
if (!(cnt < 0)) {
870:仕様書無しさん
07/10/08 21:21:05
おまいら、なんか丁寧な議論をしてて好感が持てるぞ。
要は内部的な単なる処理に自明なコメント付けるなってことだよね。
i=i+1; //iに1を加算する みたいな。
871:仕様書無しさん
07/10/08 21:22:54
howじゃなくてwhatを残すんだろ
コメントの基本
872:仕様書無しさん
07/10/08 21:28:30
>>868
コメントを書きたくなったら変数名や関数名を考え直すんだ。
こんなかんじで。
if (zaiko > 0) {
shoumikigen_kakunin();
}
873:仕様書無しさん
07/10/08 21:30:33
>>869
わろす
874:仕様書無しさん
07/10/08 21:39:53
>>869
レビュワーのレベルも知れるな。
875:仕様書無しさん
07/10/08 21:41:45
修正前の方がまだマシのような気が・・・
876:仕様書無しさん
07/10/08 21:43:17
指摘した人間の想定の遙か上をいくアホであったのかも
877:仕様書無しさん
07/10/08 21:44:09
>>869
レビュワーの主義が知りたい。
878:仕様書無しさん
07/10/08 21:45:30
>>869
自分は今までIFは肯定文と否定文両方必要だと思ってたけど
今いるところで、無駄な文は作るなと直された。
SQLだと否定文を書くのはNGだけど
今の規約ではJavaの方は否定文なら否定文だけ書かされる（当たり前だが）
if (!methodA()) {
// 処理
}
879:仕様書無しさん
07/10/08 22:11:53
ちょい上のほうで関数分割ネタがあるんだが、
今漏れが見てるソースにおもろいのがあった。
VB6ですまんが
Sub calc()
処理１
・
・
処理１０
Call calc2
End Sub
Sub calc2()
処理１１
・
・
処理２０
Call calc3
End Sub
Sub calc3()
略
これは関数分割といっていいのか？ｗ
880:仕様書無しさん
07/10/08 22:43:55
>>879
分割なのかと言われると確かに分割してるなｗ
881:仕様書無しさん
07/10/08 22:49:44
>>879
そんな感じで分割(?)されてて、しかも連番の振り方が処理内容ではなく改修の順番だったというクソコードのメンテさせられたことがある。
882:仕様書無しさん
07/10/08 23:27:16
>879
calc2がcalc以外からも呼び出されるなら、まあ許せる範囲にはいるかもしれん
883:仕様書無しさん
07/10/09 00:26:20
ぱっと見てどれほどの量の処理なのかわかんないから、
どんどん続きの処理が出てきてウヴォアァってなるなー
メンテでそんなコード見たくないねぇ
884:仕様書無しさん
07/10/09 00:32:25
>>877
条件式は!と<さえあれば表現できるので、
わざわざ==や!=や>のような余計なものを使って
初心者を混乱させるべきでない
とか？
885:仕様書無しさん
07/10/09 00:34:16
4種類の単品マスターをセット組する処理で
単品マスターがカナとコードで検索が可能で
検索結果の並び順をカナ、コード、更新日時順で指定可能
24個のコピペ関数がKensaku1とかSearch2とかって名前で存在し、
cmdKensaku1で呼んでるのがKensaku4だった
ぐわーっとコメントアウトして書き直してしまった。
886:仕様書無しさん
07/10/09 00:37:26
>>885
俺、perlでそういうのに出会ったことがある。
正直あれは思い出したくない。
887:仕様書無しさん
07/10/09 00:51:31
あー。あるある。
888:仕様書無しさん
07/10/09 00:58:45
//if (cnt > 0 || cnt == 0) {
って結構見た目綺麗だよなぁ、と思ったりw
>=ってなんかキチャナイ気がするし
889:仕様書無しさん
07/10/09 03:30:10
左辺がもっと長かったら２回書くのは鬱陶しいよ
評価するために何らかの処理が走る場合は２回走っちゃうし（一時変数使えばいいけどやっぱ手数が増える）
890:879
07/10/09 05:50:29
>>880,882
一応きりのいいところできられてるっぽいが、
変数のスコープが狭くできているとかいうこともない。
calc2以下は前の関数から呼ばれることを前提に作られている。
関数分割のメリットはどこにあるのやらｗ
>>881
うっ・・・こっちのほうがまだましだったか
当時の事情はよくわかんねえんだが、たぶん、
関数の長さが長すぎるといけない、とかいうんで無理矢理ちぎった
というのがオチだろうと思います。
891:仕様書無しさん
07/10/09 08:48:12
case型構文があるときはどうすんの？ ちょんぎれないよね。
892:仕様書無しさん
07/10/09 11:22:48
ちょんぎるんじゃない、構造を見直すんだ
893:仕様書無しさん
07/10/09 12:14:08
case文ひとつで何百行にもなるのなら、その時点でおかしい。
ちょんぎるとかいうレベルじゃない。
894:仕様書無しさん
07/10/09 12:53:47
だって100とおりのcaseなら各中身が平均４行だって500行ぐらいすぐなるじゃない。
コマンドが何十種類とか。caseの数が多いこと＝設計ミスとは決めつけられないでしょ。
895:仕様書無しさん
07/10/09 13:01:03
決め付けはできないけど、大抵の言語でダメだよ
896:仕様書無しさん
07/10/09 13:03:01
>>893
つWindowsアプリのソースコード
897:仕様書無しさん
07/10/09 13:42:24
>>894
それはcase文ひとつで数行である、ってことでは？
898:仕様書無しさん
07/10/09 14:28:56
>>896
WndProc か?
LRESULT CALLBACK WndProc(HWND hWnd, UINT msg, WPARAM wp, LPARAM lp) {
switch(msg) {
case WM_PAINT: return OnPaint(hWnd, wp, lp);
case WM_SIZE: return OnResize(hWnd, wp, lp);
default: return DefWndProc(hWnd, msg, wp, lp);
}
}
ってするな、俺は。
実際には WPARAM や LPARAM をそのまま渡したりはせずに
MSDNの記述に従って分割してから渡すけど。
仮に処理するウィンドウメッセージが多くて、
この case が 1000 個連なったとしても OK だろ、この場合は。
よくあるプログラミング講座みたいに case の中につらつら書くのはダメだ
899:仕様書無しさん
07/10/09 18:35:36
>>898
それって非常にありがちだけど、個人的にはそういう書き方は自己満足にしかなってないと思うなあ。
一度反省的に自分のそういうコードを見直してみて欲しいよ。
一箇所からしか呼ばれないコードを関数に括りだすことが本当に可読性に資するのか。
むしろ、コードを読む際にそこに飛ぶ手間を増やしているだけじゃないのか。
「caseの中につらつら書いた」コードが本当に読みにくいのか。
むしろ教条主義的にそう思い込んでるだけじゃないのか。
900:仕様書無しさん
07/10/09 19:00:35
抽象ってどういう意味か考えてみて欲しいね
「読まければ意味がわからない関数」は括り出す意味は無い
可読性をあげるためには、「今まさに関心のある」レイヤ以外に存在する
関数について、「読む必要性自体」を消し去る必要があるのだが
901:仕様書無しさん
07/10/09 19:10:34
「コードを読む際にそこに飛ぶ」のにそんなに手間がかかるのかｗ
902:仕様書無しさん
07/10/09 19:13:13
>>894
俺ならcaseマッチングのテーブルを挟んでループさせるな。
マッチングオブジェクトは当然処理関数への参照を持たせる。
マッチングしたら対象オブジェクトの処理を呼び出す。
C/C++なら普通に書ける関数テーブル。
処理部分はスマートになるし、定義部分ではコメント多用して
逆に分かり易く表現出来る。
VBはしらねーよw
903:仕様書無しさん
07/10/09 19:17:03
OOPLにおいては、
どうやって分岐するか、と分岐した先で何をやるか
は、分離しとかないと基本的にはOCP違反になる
904:仕様書無しさん
07/10/09 19:34:57
関係の無いメッセージに対する処理を脳内でスキップする方が
関数1個参照に行くよりよほど時間かかるよな
何のサポートもしてくれないエディタ使ってる場合はどうか知らんが
長大な関数は変数のスコープなんかで
気にしないといけないことも爆発的に増えるし
905:仕様書無しさん
07/10/09 20:53:01
>>902
状態遷移表の実装なんかで俺もソレ良くやるけど、
関数ポインタ(Cなんで)使うと、静的解析で処理が追い辛くなるのが難点かねぇ。
906:仕様書無しさん
07/10/09 21:03:31
こういうときデリゲートとかラムダ式があれば…
boost禁止だしのぅ
907:仕様書無しさん
07/10/09 21:11:55
>>904
分かってないね。
「関係の無いメッセージに対する処理をスキップ」する必要性は
各メッセージの処理を関数に括り出そうがなくならない。
ただエディタ上で「読み飛ばす」行数が減るだけの効果しかないんだよ。
それに、ウィンドウプロシージャのような定型的で分かりきった処理は
行数が増えてもコードの見通しは悪くならない。
実際試せば実感できると思うけど、
こういう場合はむしろ関数呼び出しによる抽象化の方がコードの不透明性を高めるから
読んでイライラする蓋然性が上昇するよ。
908:仕様書無しさん
07/10/09 21:23:47
>>907
わかってないのはお前だ。だまされたままで良いから周囲にあわせとけ。
909:仕様書無しさん
07/10/09 21:26:18
んー・・・凄い個人的な主観的な話になるけど、
caseとcaseの間がエディタの半ページ以内なら気にならない。
1つのcaseでエディタ1ページを超えると途端に読み辛くなる。
開発環境によってエディタの行数変わるんだけど
(WindowsだとVCかサクラ、Linuxだとemacsとか)、
俺は大体こんな感じ。
910:仕様書無しさん
07/10/09 21:33:48
>>907
ガラクタを無秩序に押入れに押し込むことを抽象化と呼ぶのなら
お前のいうとおりだろうな
関数名に連番とか振ってないだろうなｗ？
911:仕様書無しさん
07/10/09 21:48:45
>>910
＞ガラクタを無秩序に押入れに押し込むことを抽象化と呼ぶのなら
そんなトンデモな前提に立った議論ではない。
君とか904は、まあダメなプログラマにありがちだけど
暗黙のうちに「プログラムを書いている時点の視点」に立っている。
確かにプログラムを書いている時点に限定すれば、ほとんどの場合は
関数に括り出した方が読みやすいし、見た目にもスッキリする。
「caseの中につらつら書いた」コードなんて醜いし見難いように思われる。
ところが同じコードを一年後に読むと評価が逆転するんだなこれが。
912:仕様書無しさん
07/10/09 21:53:11
なにそれ、全然理由になってない
913:仕様書無しさん
07/10/09 21:54:05
>>910
>関数名に連番とか振ってないだろうなｗ？
関数名、変数名がすべて [A-Z]{2,3}[0-9]{5} なコードの保守ならやらされたことがある。
それはともかく、case 文の中身が10行超えたら、普通 state か command か chain of responsibility あたりを使わね？
914:仕様書無しさん
07/10/09 21:54:51
case 1:
{
} break;
case 2
{
って最初に作っておいたらスコープ付くしbreak強制になるから便利
915:仕様書無しさん
07/10/09 21:55:11
>>911
オブジェクト指向にOCPってあるんだけど、きいたことある？
いろいろ勉強して、実践して、その上でいってるのか心配になっちゃうんだけど
916:仕様書無しさん
07/10/09 21:58:03
デリゲートを条件に使われる定数をインデックスにして連想配列にぶちこむのは一種のストラテジーパターンらしい
917:仕様書無しさん
07/10/09 21:59:40
>>915
そいつのレスはムダに長いが、主張したいことは最後の1-2行だけ。
そこ見たらこれ以上そいつにかまう必要が無いことがわかる。
918:仕様書無しさん
07/10/09 22:11:46
>>899
> >>898
> 一箇所からしか呼ばれないコードを関数に括りだすことが本当に可読性に資するのか。
Testability
919:仕様書無しさん
07/10/09 22:22:07
>918
君の一言を待っていた
920:仕様書無しさん
07/10/09 23:55:45
( ﾟдﾟ )
921:仕様書無しさん
07/10/10 00:47:25
この類の話は
センスがない人にはいくら説明しても理解できないんだよね。
たぶん>>899,907,911は文系か元コボラ。
922:仕様書無しさん
07/10/10 01:30:46
>>921
今追いついたけど同意
923:仕様書無しさん
07/10/10 01:38:13
厳しいこといえば、センスとか言ってるやつもヤバイ
基本中の基本だ
924:仕様書無しさん
07/10/10 01:57:12
こういうやつらが消火の悪いスパゲティ作るんだろうな
925:仕様書無しさん
07/10/10 03:54:45
燃え盛ったときに消しにくいんだな
926:仕様書無しさん
07/10/10 04:32:11
負け組PGの揚げ足取り乙
927:仕様書無しさん
07/10/10 08:17:56
>>899
逆でしょw
武道みたいにプログラミングでもスタイルや「型」は大事だし、
それらはほとんどの場合正しいが、いつでも正しいわけじゃない。
意味を持った処理は関数に括り出して抽象化することによって読みやすくなる、
という「型」はほとんどの場合正しいが、いつでも正しいわけじゃないんだが、
自分の頭で考えられない教条主義者（＝「センス」を欠いた人間）にはそれが
判断できないし、そういう発想が頭をよぎっても抑圧してしまうんだね。
王様は裸だ、と言えないのと同じ心理的メカニズムが作用するからねw
928:仕様書無しさん
07/10/10 08:38:05
何が「逆」なのか、説明してくれ
929:仕様書無しさん
07/10/10 10:11:44
おまえら、当然ファウラーの「リファクタリング」を読んだ上で発言しているだろうな。
930:仕様書無しさん
07/10/10 11:43:05
>>929
教科書主義者乙
931:仕様書無しさん
07/10/10 12:09:26
> 教科書主義
932:仕様書無しさん
07/10/10 12:15:19
いくら教条主義はNGだからつって、そもそも教科書読んでねえやつは論外なわけだ
933:仕様書無しさん
07/10/10 15:16:54
同意
934:仕様書無しさん
07/10/10 21:36:24
>>927
あいかわらずムダな長文だな。自分にレスして楽しいか？
935:仕様書無しさん
07/10/10 23:40:23
俺には無意味な事を二度書いて、
最後に無関係なたとえ話をしている様に見える。
誰か >>927 をリファクタリングしてくれ。
936:仕様書無しさん
07/10/10 23:49:49
case毎の処理を関数に切り出すと読み辛くなるってのは、
caseの切り分け方がおかしい証拠に他ならんと思うのだが。
あと
>927
>意味を持った処理は関数に括り出して抽象化することによって読みやすくなる、
>という「型」はほとんどの場合正しいが、いつでも正しいわけじゃないんだが
の「正しくないケース」ってどんな時さ。
抽象化によって読み辛くなるのは、抽象化の仕方がおかしい時だけでしょ。
937:仕様書無しさん
07/10/10 23:50:25
>>935
#修正しておきました。
938:仕様書無しさん
07/10/11 00:07:05
>>937
全消しかいｗ
939:仕様書無しさん
07/10/11 00:39:54
>>936
>>898-を参照
940:仕様書無しさん
07/10/11 00:45:20
WTLのメッセージマップとか激しく便利だお
941:仕様書無しさん
07/10/11 19:34:57
>>936
正しくないケースを考えてみた。
1. >>927みたいな奴しかいない現場
2. 作成した関数を全て紙で管理している現場
3. 将来メンテする奴への嫌がらせ
4. リソースがカツカツ
5. そもそもサブロジックを切り出せない言語だ
6. コンパイラの限界に挑戦中
こんなもんか？
942:936
07/10/12 02:21:01
>941
納得してしまった。w
943:仕様書無しさん
07/10/12 09:24:34
>>941
>5. そもそもサブロジックを切り出せない言語だ
そうかN88-BASICだったんだ
944:仕様書無しさん
07/10/12 11:56:55
N88-BASICじゃ仕方ないなｗ
N88-BASICでも、変数名と戻り値代わりに使う変数名を工夫すれば
GOSUB との組み合わせで何とかなるかもしれんが
本質じゃない不毛なコードが大量生産されそうだ
945:仕様書無しさん
07/10/12 13:33:21
いろんな火災現場を転々としてるダメPGが言うのもなんだけど
どちらの書き方でも、どんなに拘りの秘伝のソースでもいいが
可読性の無いソースを書くのはやめて欲しい。。
>>944
BASICの頃でも、ON (式) GOSUB *Label...でサブルーチン化はしてたよ。
946:仕様書無しさん
07/10/12 13:59:28
>945
>可読性の無いソースを書くのはやめて欲しい。。
無理。
自分の常識は他人の非常識である場合が多い。
# だからflgで３値を返すなとあれほど･･･
947:仕様書無しさん
07/10/13 15:07:00
いやそもそも可読性が無ければ保守不能だし。「可読性が低い」だろ。
じゃあその可読性の水準を向上させるためにはどうすれば良いか。
という話になるけど。これは99%以上が独学だろ。
スレの上のほうに出てきた本を読んでおくのは当然。
OSSという容易に読めるコードもあるじゃないか。