07/09/08 07:17:40
>>349
作るな！
バグ・トラッキング・システムを使え！
351:仕様書無しさん
07/09/08 09:21:30
おれ、バグ見つけるのも再現させるのも、そしてそれを直すのも得意なんだけど、
何故かみんなから嫌われてる...orz
352:仕様書無しさん
07/09/08 10:01:40
人には「自分とは異質なもの（自分に出来ないことをやっちゃう奴・
自分には理解できない話をする奴・自分の知らないことを知ってる奴）
を嫌ったり排除したりする」傾向があるからな...しかも馬鹿な野郎ほどその傾向が強い。
353:仕様書無しさん
07/09/08 10:07:29
その傾向に陥ってないか自問自答するのは容易じゃないよね．
354:仕様書無しさん
07/09/08 10:11:13
351じゃないけど、
バグ出しを続けた結果、そのシステムは作らなかったことになったことがあるな。
一つ直させると二つ壊れてくるというゴールドラッシュだったな。
355:仕様書無しさん
07/09/08 10:13:50
１つで２つならば少ないんじゃない？
少しでもいじるとシステムが動かなくなるのがデフォってのもあるわけで・・・
356:仕様書無しさん
07/09/08 12:10:28
>>350
開発部署で用意されてるBTSに入れてるんだけどさ、見てくれないし全部スルーされちゃうんだよね
357:仕様書無しさん
07/09/08 13:44:29
>>356
それはきっと
バグ
たっぷりで
際限が無い
からだよ
358:仕様書無しさん
07/09/09 00:46:34
>>350
でも結局報告するときは結局BTSからバグ一覧を作成することになる場合が多い希ガス。
csvとかで。
359:仕様書無しさん
07/09/09 01:12:28
>>358
なるよな。。
なんか紙で出てこないと不安らしい。
我慢できる限界がエクセルの一覧表。
しょうがないから、BTSのxmlからcsv吐き出すスクリプト組んだよ。。
余計な仕事させやがって。
360:仕様書無しさん
07/09/09 21:24:20
/*
if いふ
else えるす
while わほいる？
do どー
fopen ふぉーぷん
fread ふれっど
fwrite ふうらいと
fclose ふくろーず
*/
なにこのカンペ……
361:仕様書無しさん
07/09/09 21:34:42
>>360
答えが間違ってるカンペって・・・
362:仕様書無しさん
07/09/09 21:44:18
「わほいる？」に萌えた
語感がかわいい
わほいる
363:仕様書無しさん
07/09/09 21:52:48
微笑ましいが・・・・他所でやって欲しいな
364:仕様書無しさん
07/09/09 21:57:06
/* */
ってVC2005だと
行選択時の//の一括付加・削除のときに巻き込まれて /* → * になったりするから使いづらい
ゲイツ死ね
365:仕様書無しさん
07/09/09 22:11:42
/*横綱.c/*
#include <朝青龍.h>
366:仕様書無しさん
07/09/09 23:04:45
>>360
do どー
fclose ふくろーず (梟？)
がチョット好き
>>365
/* 横綱.c/* これコメントとして間違ってない？
下の行もコメントアウトしてるのか。
367:仕様書無しさん
07/09/09 23:10:27
どう見ても間違ってますw
368:仕様書無しさん
07/09/09 23:11:25
>>360
ふくろーずってバンドの名前みたいだなw
369:仕様書無しさん
07/09/09 23:15:17
きっと甲本ヒロト。
370:仕様書無しさん
07/09/10 08:52:15
ギリギリガガンガン
371:仕様書無しさん
07/09/10 20:03:31
ソースというよりmakefileなんだけど、
依存関係が間違ってるとか、は当然のごとくあり。
今日見たのは、
CFLAGS=
としてオプションも消しているのを見た。
コメント化してデフォルトを有効にすると、警告がでるわでるわ。
コンパイラを誤魔化すためにやってるんじゃないかと思った。
もともとバグのあるソースだし、表面的にでも動くように、見なかったことにしました。
(ほんとはバグも表面化してるけどw)
372:仕様書無しさん
07/09/10 20:45:49
今更だけど、なんで日本のソフトウェア業界ってこんなに壊滅的なの？
373:仕様書無しさん
07/09/10 20:52:39
どこの国も変わらんと思うぞ。
派手さでいえば米国の方が上だし。
374:仕様書無しさん
07/09/10 21:49:17
C言語で作ってあったプログラムで、makefileでヘッダの依存関係が無かったので
depend追加したら毎回全てのソースがコンパイルされるようになった。
なんでかな～、と思って調べてみたら、依存関係のトップにあるヘッダが
make時に毎回自動生成されてやがる。
こんなmake環境にした開発者、氏ね。
375:仕様書無しさん
07/09/11 00:24:58
>>373
米国の場合は、それを埋め合わせるセンスがあるんじゃないかと思ってる。
着眼点や、機能のまとめかたやUIの作りなどのセンス。
これがスマートだと、バグが判明しても、使い続けざるを得ないという気になってしまう。
376:仕様書無しさん
07/09/11 01:02:33
使い物にならない奴が志望してくるのがいかん。
大学で切り落とせ。
アホに単位をやるな。
377:仕様書無しさん
07/09/11 01:11:47
未経験者をいきなり実戦投入するとひどいのが出来上がる。
俺自身「今ならもっと上手く書けるのに」「あの時これを知ってれば」って思い出すことがある。
そんな自分と比べても、酷すぎるのが今の職場...orz
378:仕様書無しさん
07/09/11 01:36:06
>376
そこでFizzBuzzですよ
379:仕様書無しさん
07/09/11 01:36:10
新人が使えないのは仕方ないが
使えないベテランが沢山いる、不思議なこの業界
380:仕様書無しさん
07/09/11 02:01:54
>379
「ベテラン」というのが履歴書に書かれた経験年数に基づく呼称でないのなら
確かに不思議だが
381:仕様書無しさん
07/09/11 02:20:30
使えない奴は派遣するってことで
382:仕様書無しさん
07/09/11 03:57:18
>>374
正直makefileって規模でかいとよく分からなくなるのがデフォというか
新たな仕様にしてほしいぐらいだ
383:仕様書無しさん
07/09/11 07:23:02
>>382
ant使え、
384:仕様書無しさん
07/09/11 08:14:37
今のパソコンなら速いから、全コンパイルのbatでもすぐ終わるでしょ。
俺はmakeとbatと両方用意して、「makeを知らない保守者はbatでいいよ」と書き添えてる。
385:仕様書無しさん
07/09/11 08:15:57
扱うファイルが、100個ぐらいとか、依存関係がシンプルなものだけなら、makefile もまだ手軽で良いけどね。
それ以上で makefile 使ってるプロジェクトに関わると眩暈がするな。
世の中、もうちょっとマシなものが、いくらでもあるのによりによって makefile かよって。
386:仕様書無しさん
07/09/11 10:57:02
>>384
んなもん、規模や開発環境によるだろ
うちのプロジェクトはフルコンかけると2時間くらいかかるぞ
重要なヘッダが更新されると、すぐにフル逝っちまう orz
387:仕様書無しさん
07/09/11 12:20:57
ヘッダの切り分けがおかしいんだろ
388:仕様書無しさん
07/09/11 14:25:27
フルコン2時間って携帯？
規模に対して環境が貧相な現場って他に浮かばないんだけど
昔、入った携帯の現場で warning が10000超えたのは笑ろた
389:仕様書無しさん
07/09/11 18:31:45
少ねえ少ねえ
390:仕様書無しさん
07/09/11 21:10:04
コンパイルのバグか何かで、6万後半あたりでwarningの数が一旦0になったこともあったな。
391:仕様書無しさん
07/09/11 21:13:54
臨海値65535か 16bit unsigned
392:仕様書無しさん
07/09/11 21:19:13
コンパイラをバグらせるとは・・・
コンパイラ「想定の範囲外です・・・」
393:仕様書無しさん
07/09/11 21:19:35
臨海値
394:仕様書無しさん
07/09/11 21:20:05
むしろfloatで
395:仕様書無しさん
07/09/11 21:38:24
今はlong long があるじゃまいか！
396:仕様書無しさん
07/09/11 21:48:18
遊戯、もうやめて！
コンパイラの示す warning は既に臨海値よ！！
397:仕様書無しさん
07/09/11 21:59:07
const TYPE const*const&;
398:仕様書無しさん
07/09/11 22:33:15
/* index.html */
#html
head()
{
style;style.css
}
body()
{
test.
}
#html
399:仕様書無しさん
07/09/11 22:44:26
これは新しい言語
400:仕様書無しさん
07/09/12 03:34:02
#define head nanntoka
#define style kanntoka
#define css kanntoka
#define body foo
#define test bar
#include "index.html"
401:仕様書無しさん
07/09/12 09:09:54
#include "mychtml.h"
int main() {
html(
head(title("Test Page")),
body("Hello, world !!!<BR>\n")
);
}
402:仕様書無しさん
07/09/12 22:56:12
Const Arr = "a,b,c,d"
function aaa()
for i = lbound(split(arr,",")) to ubound(split(arr,","))
if split(arr,",")(i) = "a" then
aaa = split(arr,",")
end if
next
end function
こんなん
403:仕様書無しさん
07/09/12 23:09:30
>>402
splitやり過ぎってヤツですか。
404:仕様書無しさん
07/09/12 23:15:26
ソースコードがスパゲッティ！でもそんなの関係ねぇ！
405:仕様書無しさん
07/09/12 23:33:39
>>402
んんん！？なんだか見覚えがあるw
406:仕様書無しさん
07/09/12 23:50:26
>>402
これは素晴らしい無駄関数ですね
407:仕様書無しさん
07/09/13 00:26:45
これはあれだ、きっとsplit呼び出しの結果が全て同じだと判断して、
自動的に一回の呼び出しに纏めてくれる、素晴らしいコンパイラが存在するんだよ！
408:仕様書無しさん
07/09/13 00:29:07
それでも最適化なら・・・最適化ならきっとなんとかしてくれる・・・！！
409:仕様書無しさん
07/09/13 00:31:24
探すと本当にあるから困る
410:仕様書無しさん
07/09/13 00:33:19
最適化? こんぱいる?
くっふふふ
VBScriptというものは
ひとたび構文木にさえ解析されてしまえば
二度とは
二度とは
411:仕様書無しさん
07/09/13 00:56:55
スパゲティと申したか
412:仕様書無しさん
07/09/19 19:03:16
#ifndef Hoge
typedef struct tag_Hoge {
(略)
} Hoge;
#endif
え～っと。
413:仕様書無しさん
07/09/19 19:52:58
・・・きっとCは初めてなんだよ。
先週入門書を読み終わったばかりなんだ。
きっと、きっと・・・
414:仕様書無しさん
07/09/20 00:24:54
ifndefが嫌いだ
なんでifnodefじゃねぇんだ ややこしいよ
#if !definedのほうがマシだ。 どうせ多重防止とかだったらpragma onceで事足りるからいいけど
415:仕様書無しさん
07/09/20 16:09:26
>>412
そのソースの意図がさっぱりわからない。
#define と typedef を混同したのだろうか…
416:仕様書無しさん
07/09/20 18:13:33
>>414
リリース版を表すNDEBUGの方が…
標準に従うと、デバッグ版のみ有効にするのに
#ifndef NDEBUG
...
#endif
と否定が２回来て嫌な感じだ
結局可読性とかで _DEBUG が使うんだけどな
って脱線しすぎか。
417:仕様書無しさん
07/09/20 18:42:13
NDEBUGは<assert.h>が見るんだっけか。
418:仕様書無しさん
07/09/20 18:55:12
>>415
FAQ級の落とし穴らしい。
URLﾘﾝｸ(www.kouno.jp)
419:仕様書無しさん
07/09/20 19:52:18
そういうレベルが普通なのか？
420:仕様書無しさん
07/09/20 23:51:55
>>415,418
？？。何をやろうとしてるのかすらさっぱりわからんのだが・・。
421:仕様書無しさん
07/09/21 00:14:14
>>420
たぶん>>415の言うとおり#defineとtypedefを混同してるんだと思う。
・・・typedefを何回も呼ぶつもりなのか???
後から呼んだ方が有効になるなら、実害はなさそうだけど・・・
と思って試してみたら、さすがに名前が衝突してるってエラーが出た。
422:仕様書無しさん
07/09/21 00:19:15
「Hoge」がまだ定義されてなければtag_Hoge型の構造体としてHogeを定義、ってことだろう
何をしたいと思ったかは分かっても何に使うはさっぱりわからんw
423:仕様書無しさん
07/09/21 00:40:31
Hogeが定義済みだったときにどんな動作をするんだろうな
424:仕様書無しさん
07/09/21 03:36:09
なるほど、こういうレベルが普通なんだな……
425:仕様書無しさん
07/09/21 13:07:19
public String getErrorMessage() {
// TODO 自動生成されたメソッド・スタブ
return null;
}
426:仕様書無しさん
07/09/21 13:13:55
Cで継承とかしようってことかな。
#include "FooExt.h"
#ifndef FOO
#define FOO
typedef strcut foo{
method1,
method2,
}Foo;
#endif
で、FooExt.hとかで
typedef strcut foo{
method1,
method2,
method3,
}Foo;
#define FOO
とか。。
考え過ぎか？。
427:仕様書無しさん
07/09/21 21:15:10
>>425
？？？
・・・catchしたいのかなぁ・・・
428:仕様書無しさん
07/09/21 22:00:54
>>425 が何を言いたいのかさっぱりわからない
これってIDE(eclipse,netbeans,etc)で自動生成されたメソッドでしょ？
納品されたソースにこんなのがあったら嫌だけど、開発中なら腐る程あるよ
429:仕様書無しさん
07/09/21 22:20:59
private String errorMessage;
から自動生成されたのは分かるが戻り値がぬるぽ
430:仕様書無しさん
07/09/21 23:33:24
もう辞めた会社のソースだけど、何年も運用を続けてきたシステムの仕様変更があるからと、
俺も参加することになったときに、一月に現行処理のバグを200くらい報告したことがある。
仕様変更自体よりバグとりの時間の方が長い位だった。
そのためだけに一月くらい時間をもらえたのが幸運だったけど。
あと今の現場。JSPのソースが全部スクリプトレット。全部 out.println とかで書いてありやがる。
ほとんどCGI気分だっ。
431:仕様書無しさん
07/09/21 23:34:52
>>428
保守するコードを開いてみたらTODOだらけってのはよくある話。
432:仕様書無しさん
07/09/21 23:56:00
藤堂さんのおおいしょくばなんだね…
433:仕様書無しさん
07/09/23 01:39:37
手順書はsudoさんだらけだしな
434:仕様書無しさん
07/09/23 02:07:31
作業始めたら安藤さんのお世話になりっぱなしだ
435:仕様書無しさん
07/09/23 02:28:45
うちには後藤さんが多いから困る
436:仕様書無しさん
07/09/23 02:34:01
んなこたー知らねーよ
437:仕様書無しさん
07/09/23 02:48:43
三木だったり後藤だったりする
438:仕様書無しさん
07/09/23 02:53:17
// クローズ処理
if(rs != null){
rs.close();
rs = null;
}
（；＾ω＾）・・・
439:仕様書無しさん
07/09/23 02:59:31
>>438
あるいは正しいような気すらしてくる
440:仕様書無しさん
07/09/23 03:04:50
旧VBっぽいアレだな
441:仕様書無しさん
07/09/23 09:12:56
もうやめたけど前の会社
面接でC++が出来るかどうか聞かれて、出来ますと答えて入社。
引き継いだコードの cout を printf で書き直したらただの C になった。
442:仕様書無しさん
07/09/23 12:02:26
>>438
これはwindowsのリソース関係の処理？
windowsはよく知らないけど、きっと delete this; してるんだよ。そう願いたい。
443:仕様書無しさん
07/09/23 12:26:43
>>438
javaではよく見るな。
優先的にGCの対象にするためにわざと参照を外しているらしい
444:仕様書無しさん
07/09/23 12:42:49
>>443
インスタンス変数に持つとかアホな状況でなければ、変らないけどなー
445:仕様書無しさん
07/09/23 12:54:05
そうなんだけど、今のプロジェクトでは
必要でなくなった変数にはnullを入れるというコーディング規約
さらにハンガリアン記法も強制
定数名が60文字以上ある状態なのに80文字で折り返し強制
ほか多数
バカ（というか時代遅れ？）が上に立つとろくな事にならんという見本
446:仕様書無しさん
07/09/23 13:08:40
長くても分かりやすい名前をつけろというけどさ、
その上でコードは80文字で折り返せって言うのも訳が分からん話だな。
447:仕様書無しさん
07/09/23 13:22:07
>>445
なるほど、改善提案もできないコミュニケーション能力の欠如した引っ込み思案の自分を
棚上げしてこんなところで文句を垂れる君はバカではないんだw
448:仕様書無しさん
07/09/23 13:33:44
60文字の定数のどこが分かりやすいんだ？
449:仕様書無しさん
07/09/23 14:01:15
>>447
くされ基盤チーム乙ｗ
450:仕様書無しさん
07/09/23 14:06:28
>>447
お前はまずスレタイ読んだ方がいいな。
451:仕様書無しさん
07/09/23 14:32:22
CHogeClass::CHogeClass()
{
delete m_pPtr;
...
}
いきなりdelete。
リリースモードだと奇跡的に動くがデバッグモードだと動かない。
そこで、コードを修正するのではなく全員リリースモードだけで開発し始めた。
当然数ヵ月後僕はその会社にいなかった。
452:仕様書無しさん
07/09/23 14:40:01
>>451 直せよw
453:438
07/09/23 14:56:56
>>439 >>442 >>443 >>445
438です。
コメント部分が冗長すぎただけで、処理事態は問題はないです。
rs に null を入れるのは メモリ使用量の多いオブジェクトを、
早めにガーベージコレクションの対象にするためで
間違ってはいないと思います。
ただそれだけでした＞＜
454:仕様書無しさん
07/09/23 15:04:54
>>451-452
ﾜﾛﾀ
455:仕様書無しさん
07/09/23 15:06:41
>>453
コメントも別に冗長じゃないけど。
他の処理との兼ね合いで書いているだけでしょう？
//ここでクローズ処理してます。ガベコレ対策でnullいれとります。
//なにか問題でも？
とか書いてあったら冗長だけどな。
456:仕様書無しさん
07/09/23 15:10:16
無意味なコメントはよくあるよな。
// ストリームを開く。
public OutputStream openStream() {
...;
}
アホか。
457:仕様書無しさん
07/09/23 15:16:15
>>456
コメントを抽出するソフトとかあるんだけど、それは知らない？
458:仕様書無しさん
07/09/23 15:18:24
よーし、修正しちゃうぞ。
//! ストリームを開く。
public OutputStream openStream() {
...;
}
459:仕様書無しさん
07/09/23 15:34:48
>>455 >>457
SUNが提唱している、
「Java Code Conventions」
URLﾘﾝｸ(www.tcct.zaq.ne.jp)
＞コードの中に既に含まれている情報やコードから自明であるような情報を重複させることは避ける
に記載されているように、冗長なコメントは書くべきではないと私は考えます。
コメント自体は書けば書くほど可読性を下げます。
コメント無しで理解できるコードを目指すのがベストだと思っています。
（と、いってもまったくコメント無しでのコードを書くのも不可能でしょうけど）
ちなみにドキュメンテーションはまた別ですが。
460:仕様書無しさん
07/09/23 15:36:08
>>457
抽出して削除＆書き直しするの？
僕のばあいは、もともとソフト会社じゃないから、Delphi、shのスクリプト、C、C++、C#、JavaScript、MATLAB
、WindowsScriptとか、あとNastran等々みんな適当なコードが残ってる。
「お前出来るだろ」ってほとんどコメント無しでの糞コードでくるから、リファクタリングとかだけでも
「無理っす。無理っす。無理っす。」を連発してる。
てか、いろいろ言葉が通じない。みんな言葉が通じるだけましだよ。
461:仕様書無しさん
07/09/23 15:51:28
>>459
それは奢りだと思うよ。
誰でもコード読めるわけじゃないしね。
「このブロックでは、○○の処理をしています」って書いてある事で
とりあえず数十行が簡単に読み飛ばせるなら、その方が効率がいいのは自明。
あなたの理想は以心伝心っと同じで、まあある種ありえない理想だと思うよ。
それ言ったらドキュメントも折衝も要らないからね。
全ては「ソースみろ」で済む。
実際はそうあいかないよ。
462:仕様書無しさん
07/09/23 15:53:25
>>460
抽出してドキュメントを作る参考にするんだよ。
それで処理のサマリーが分かれば、読むときに楽でしょ？
仮に明日全く知らない言語の修正依頼が来たらどう？
適切なコメントがあったら、楽だと思わない？
言語の勉強をゼロから初めて、それからソース読むよりはさ。
463:仕様書無しさん
07/09/23 16:08:29
日本人で>>459を実践したい人には
「なでしこ」
ちょーお奨めです。
464:仕様書無しさん
07/09/23 16:09:36
>>437
「三木」って何？
465:仕様書無しさん
07/09/23 16:16:52
>>462
書いてること正しいと思うけど、
”言語を全く知らない人”を想定してコメントを書くって作業は（個人的に）勘弁して欲しい。
466:仕様書無しさん
07/09/23 16:22:27
>>465
だから、それがセンスとバランスなんだって。
//ファイルオープン
//読み込み
//整形
//出力
とかブロックごとにあったら、知らなくても概要は理解できるし、
知っている人にも（余程無能でなければ）邪魔にもならないでしょ。
全く知らない人に完璧に理解させるのは無理でも、手助けにはなる。
VBAとかExcelマクロも数えると、過去にやった言語は20くらいになるし、
極端に多いとも思わない。
ちょっとしたマクロの手直しのために、一からその言語の勉強やるのは厳しいしね。
コメント要らないなら、そもそも、除去なんて簡単にできるしね。
無いコメントを生成はできないけど。
467:459
07/09/23 16:22:30
>>461
私も、コメント無しで完全に理解できるコードは不可能だと思っています。
ただし、
「処理フローが明らかであるのにコメントを付けては、
品質が下がるだけでメリットがない」
ということを言いたかっただけです。
＞コメントは，コードの概観と，
＞コード自体からは読み取ることのできない付加的な情報を与えるものであるべきである．
この考えが伝わるつもりでレスしましたが、
文章が至らず誤解させてしまったようです。申し訳なかった。
468:仕様書無しさん
07/09/23 16:24:56
>>467
書いた側と読む側が非常に優秀ならコメントなしでも読めるよ。
そんで俺の言ってる必要なコードは、あなたの言っている「コードの概観」の話だしね。
「コメントがあるほど可読性さがる」ってのが間違いだって言うなら別にいんだけど。
469:仕様書無しさん
07/09/23 16:26:32
>>466
センスとバランスとかＳＥとは思えないアバウトな表現。
ＪＡＶＡ言語を知っているというのは、コードを読む上では必須でしょ。
言語を理解した上で
「スパゲティコードだからコメントつけないとわからん」
というならわかるけど。
君の理論だと、コメントの統一性が保たれない。
プロジェクトが始まる前に
このメソッドを使うときは コメントを付ける、つけないとか
全てのクラスに対して説明しなければいけない。
470:仕様書無しさん
07/09/23 16:31:33
こんなコードはコメントが必須（実話）
// foo に bar を代入し、計算結果をDBに格納する
public getPoo() {
// ながーいコード
}
471:仕様書無しさん
07/09/23 16:31:47
まぁ、見た限りだと
「ＪＡＶＡ初心者のためにコメントをつけて仕事を早く回す」か
「品質のために冗長なコメントはつけない」 の意見がわかれてるだけでしょ。
前者も後者も言い分はわかるけどね。
そもそも2人の目的からして違ってるから結論でないでしょ。
472:仕様書無しさん
07/09/23 16:32:42
おっと訂正。
// foo に bar を代入し、計算結果をDBに格納する
public void getPoo() {
// ながーいコード
}
473:仕様書無しさん
07/09/23 16:36:29
中小企業なら前者の考え（コーディングを早く終わらせてコスト削減）
大企業なら後者の考え （早く終わらせるよりも品質確保）
でいいじゃん。
474:仕様書無しさん
07/09/23 16:41:36
>>472
// foo に bar を代入し、計算結果をDBに格納する
public void getPoo() {
}
どこが get してるんだよｗｗ
475:仕様書無しさん
07/09/23 16:52:11
>>471
いや、その場合品質って何？って話だと思うけど。
よっぽど冗長じゃなきゃ読み飛ばせばすむコメントで品質さがるかな？
そこまでストイックに減らすのって正直自己満足の世界だと思うんだけど。
//このブロックで、先頭の不要行を削除
で10行さらっと読み飛ばせるコメントをつけないメリットの方が
大きいとは思えないな。
476:仕様書無しさん
07/09/23 16:54:34
別につけたくないならつけないでいいけどさ。
もっとも害なのは変なこだわりとか自己満足をおしつけて
「俺はこれが正しいと思う。だから全員これをやれ。
これ以外はクオリティが下がるのでダメだ」って奴だと思う。
真面目な話。
そしてそういう奴は大抵「いや、あんたそれ以前にマシなコード書いてよ」
って奴なんだよな。
自己満足と自己肯定ばっかりで、「いや、もしかしたらこっちの方がいいのかも」
とは少しも考えない。
俺は人に押しつけまではしないけどね。
477:仕様書無しさん
07/09/23 16:58:07
>>475
＞よっぽど冗長じゃなきゃ読み飛ばせばすむコメントで品質さがるかな？
下がるわ。コメント範囲の大小は関係ない。
478:仕様書無しさん
07/09/23 16:58:19
>>475に同意。
三行ごとにコメントがついてるとかの極端な話じゃなければ、ついてて良いと思う。
何事もないよりある方がマシ。
479:仕様書無しさん
07/09/23 16:58:59
>>476
だから、自己満足じゃなくて、Sunの規約に準じてるだけでしょ？
そこを無視するとかプログラム的にはありえんわ
480:仕様書無しさん
07/09/23 17:00:31
ま、sunの言う通りにやればいいんじゃないの？
とにかくsunが言うんだから間違いないよねぇｗ
481:仕様書無しさん
07/09/23 17:02:38
なでしこ使うんだ。
なでしこなら冗長なコメントなんか付けなくなる。
482:仕様書無しさん
07/09/23 17:02:47
ちなみにCOBOLでコード書く場合もsunの規約に従う必要あんのかな？
Java限定の話だったっけ？
483:仕様書無しさん
07/09/23 17:03:37
自分の理論で「これはこうあるべき」って書くから駄目なんでしょ。
自己流コーディングはよくないよ。
Sunの規約として用意されてるなら使うべきだし、
そのプロジェクトの規約として別な方法が記載されていたらそっちを優先すべき。
484:仕様書無しさん
07/09/23 17:04:43
>>483
プロジェクトの規約も使用言語も一切無視して、とにかく「コメントは少ない方がいい。
sunがいうんだから間違いない！！」ってキチガイさんに言ってやってくださいｗ
485:仕様書無しさん
07/09/23 17:05:51
>>482
COBOLはその言語に適した規約があるでしょ。
言語によって保守や拡張性に対する考え方も違うしね。
486:仕様書無しさん
07/09/23 17:07:07
>>485
だよね。
それを無視して「コメントは少ない方がいい！」ってほえてるのって馬鹿過ぎだよね。
いつからJavaの話になったんだか。
487:仕様書無しさん
07/09/23 17:07:19
>>479
488:仕様書無しさん
07/09/23 17:08:08
>>484
だからさ・・・
「プロジェクトの規約として別な方法が記載されていたらそっちを優先すべき」
って言ってるでしょ。
そりゃクライアントがそういう風に指定したらそっちを使うのが当たり前っしょ。
わざわざ指定されてるのに別な書き方してたら訴えられるそ。
おまえはどんなプロジェクトだろうと自己流コードをかいてりゃいいさ
489:仕様書無しさん
07/09/23 17:08:38
>>482
sunのガイドラインがどうこう言う前に、コボルは旧コードをコメントアウトして残すのを辞めれ。
490:仕様書無しさん
07/09/23 17:08:44
MSのハンガリアンマンセーに従ってた奴乙
491:仕様書無しさん
07/09/23 17:09:44
>>488
＞ だからさ・・・
＞ 「プロジェクトの規約として別な方法が記載されていたらそっちを優先すべき」
うん。
だから言っている内容を変更したわけだよね？
それって後付けだよね？
だとしたら、最初に言った「コメントは少ない方がいい」って間違えたんだよね？
492:仕様書無しさん
07/09/23 17:10:15
>>486
いや、>>485は君と対立してた俺なんだけど・・・
Javaの話してたんじゃないの？
そういうことならすまんかったわ。
あくまで俺のはJava限定の話ね。
493:仕様書無しさん
07/09/23 17:11:12
自分がコメントあったほうが読みやすいから、そうしてる
規約でダメなら渡すときにコメント全削除してやるからいいよ
494:仕様書無しさん
07/09/23 17:11:20
>>469
495:仕様書無しさん
07/09/23 17:11:50
>>492
そうか。
Java限定なんて前提は初めてだけど、君が前提を間違えていたと言う事ね。
なら仕方ない。
もっともJava限定でも当初の「コメントは少ない方が良い」って間違えているけどね。
プロジェクト規約の方が優先度高いんだから。
ま、今は理解したらしいけど、少なくとも最初は間違えて書いたのは事実だよ。
気をつけてねｗ
496:仕様書無しさん
07/09/23 17:12:43
>>493
天才児あらわるｗ
>>494
その前からJava前提で書いているよ。
そんな話どこにもなかったのにね。
497:仕様書無しさん
07/09/23 17:14:35
>>495
プロジェクトの規約に従うのは前提条件でしょ？
後付けで、
「プロジェクトとしてまったく異なる規約が存在しているとしたら？」
と言われても困るわ
そりゃ、どんな間違った書き方でも仕様でも、客が指定してきたら従うよ。
その点については君と同意。
ただし、特に指定されてないならSun準拠にしとけば間違いないでしょ。
ちなみに俺もいちいちほかの人の書いたものを指摘はしないけどね。
お金くれるなら別だけど。
498:仕様書無しさん
07/09/23 17:16:33
>>497
煩いバカだな。
499:発端
07/09/23 17:27:12
>>438 >>453 >>459 です。
私の書いたことが原因でスレが荒れてしまい申し訳ないです。
みなさんそれぞれの意見が聞けたことで大変勉強になりました。
このスレは好きなスレの一つなので、
上記の件については終わりということでお願いしますm(__)m
500:仕様書無しさん
07/09/23 17:30:40
流れていたときにリアルタイムで読んでなかったのでタイミングを逃したけど。
>>461
>誰でもコード読めるわけじゃないしね。
>「このブロックでは、○○の処理をしています」って書いてある事で
>とりあえず数十行が簡単に読み飛ばせるなら、その方が効率がいいのは自明。
○○を名前にしたメソッドに切り出す。
というのが定石で、Sunのなんたらってのも、そういうコーディングが前提かと。
まあ、我々はネイティブではないので
メソッド名でわかるコードを書くというのは現実的には敷居が高いが、
Javadoc をちゃんと書けばそれほど無茶な話でもないと思われ。
501:仕様書無しさん
07/09/23 17:31:25
悪いコメントの例 言語はC
int wrk_COUNTER1; /* カウンタ1 */
具体的な文言はともかくこのレベルのコメントが実在した。
どんな言語だろうとコレはさすがに....ていうか変数名からしてヤバい。
しかもコレグローバル変数なんだぜ！
ほかにも /*ファイルを開く */ /* 変数をインクリメント */
納品するソースを練習台にするなよorz
502:仕様書無しさん
07/09/23 17:45:08
ステートメントレベルコメントの問題は
・コードとコメントを同期させて管理していくのが手間
・コメントを付ける基準の統一が難しく、個々のコーダー任せになる
かな。
前者は関数レベルでも同じじゃないかと思うかもしれないけど、
関数レベルというのは設計段階で fix されているべきもので (少なくとも理屈では)
そこが頻繁に更新されるというのは、コメント以前に別の問題がある。
503:仕様書無しさん
07/09/23 18:48:23
コードの方をわけ分からなくすれば解決だぜ!
// ストリームを開く。
public T0000 F0000() {
...;
}
504:仕様書無しさん
07/09/23 19:25:43
>>503
天才
505:仕様書無しさん
07/09/23 19:28:41
>>503
本気であるので困る
// 検索結果を取得する
public D001_0012 F001_0012(I001_001 arg0) {
}
当然、Excelの管理台帳（笑）で管理される
506:仕様書無しさん
07/09/23 19:30:52
これはひどい・・・
507:仕様書無しさん
07/09/23 19:37:47
ちなみにサーバーサイドJavaだったんだが、表示するJSPも G001_002U.jspとかだぜ。
あわせてG001_002U.jsがそれぞれセットになっているからカオスすぐる
で、Gなんだが良く解らないから聞いてみたんだ。
「画面のGだろ、そんなことも解らないのか？」と怒られた(´・ω・`)
508:507
07/09/23 19:43:19
思い出せばもっと色々あったぞ。
・変数は全て文字列（当然DBも）
・親会社のバグだらけの怪しいフレームワーク強制
で、オチだったんだが、中国へのオフショア（笑）で夜逃げされた。
509:仕様書無しさん
07/09/23 19:44:07
なんというコボル脳…。
510:仕様書無しさん
07/09/23 19:44:49
画面のGとか凄すぎるﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌ
511:仕様書無しさん
07/09/23 19:51:09
printf("HelloWorld!!ﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌ\n");
512:507
07/09/23 19:51:11
もっと晒すぜ、ﾋｬﾎｰ
データ構造定義（笑）はこんな感じ
データ構造定義ID D001_0012
項目ID 長さ （中略） 備考
D001_0012_001 18 （中略） 商品ID（9桁）
513:仕様書無しさん
07/09/23 19:53:02
まぁアレだろ。Fだろ。
514:仕様書無しさん
07/09/23 19:55:53
Gって言ったらゴキブ
ぅゎぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁ
515:仕様書無しさん
07/09/23 19:56:44
>>513
残念。 N系
516:仕様書無しさん
07/09/23 19:57:23
誤： printf("HelloWorld!!ﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌ\n");
正： printf("HelloWorld!!\n");ﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌﾌ
517:仕様書無しさん
07/09/23 19:58:23
寿司食いたいﾌﾌﾌﾌﾌﾌﾌ
518:仕様書無しさん
07/09/23 20:04:09
printf(buf);
buf内に%sが入って死亡・・・・・・
519:仕様書無しさん
07/09/23 20:13:51
祭りに乗り遅れた・・・
520:仕様書無しさん
07/09/23 20:18:52
// ずっと俺のターン
while (1)
printf'("ﾌ");
521:仕様書無しさん
07/09/23 20:34:35
ガリでも食ってろﾌﾌﾌﾌﾌﾌﾌ
522:仕様書無しさん
07/09/24 02:20:45
G001_001？？？ってのは、
画面ＩＤをそのまま名前にしてるんなら保守はしやすいのかもしれん。
もちろん画面ＩＤがきっちり管理できてるのが前提だけど。
523:仕様書無しさん
07/09/24 02:33:26
>>522
おまえは設計するなよ！約束だぞ！
524:仕様書無しさん
07/09/24 02:40:18
ID項目それぞれに対する説明の文書なりpdfがあるんじゃないの
それなら分かる
525:仕様書無しさん
07/09/24 06:57:17
>>524
わかりやすい命名になってればその文書自体不要になるか、
大幅に簡略化できる。
なまじ素直な性格だと、
「業界の先輩たちが長いことやってることだから、なにかよいことがあるんだろう」
って思っちゃうんだよなあ…
昔々、ディレクトリというものが無く、
データ領域につける名前に大文字と数字6文字とか8文字とかしか
使えなかった時代の習慣を引きずってるだけなんだが。
526:仕様書無しさん
07/09/24 07:19:10
コボルのコメントってどう書くんだっけ。さすがに３８年も書いてないと忘れた。
527:仕様書無しさん
07/09/24 07:42:33
*
528:仕様書無しさん
07/09/24 09:31:28
きたねえ穴だな
529:仕様書無しさん
07/09/24 11:29:14
>>522
氏ね
せめて、ItemList_02.jsp とかある程度はまとめた上での連番にするべきだろ
530:仕様書無しさん
07/09/24 11:31:49
>526
行番号の直後の桁にアスタリスク
531:仕様書無しさん
07/09/24 11:57:25
>>530
きたねえ穴だな
532:仕様書無しさん
07/09/24 12:07:51
>>530
きたねえ穴だな // じつは入れたいと思っている気持ちの裏返しの発言
533:仕様書無しさん
07/09/24 12:48:06
// キーボードの状態を取得する
bool getKeyboardStatus()
{
//キーボードの状態がおかしい
if (status_ == RESPONSE_ERROR) {
// 投げる
throwKeyboard();
}
return status_;
}
みたいな名前と処理が一致しない関数が
山ほどあって気が抜けない (´Д｀;)
534:仕様書無しさん
07/09/24 12:49:29
>>533の返り値は気にしないで・・・。
535:仕様書無しさん
07/09/24 13:17:56
while (1)
{
int nRet;
nRet = 仕事();
if (nRet == ERROR)
{
int nMood = Get今の気持ち();
if (nMood == BUTIKIRE)
{
throwMouse();
throwKeyboard();
beatNeighbor();
quitJob();
break();
}
}
}
536:仕様書無しさん
07/09/24 13:47:47
while(辞めない) {
while (1)
{
int nRet;
nRet = 仕事();
if (nRet == ERROR)
{
int nMood = Get今の気持ち();
if (nMood == BUTIKIRE)
{
throwMouse();
throwKeyboard();
beatNeighbor();
quitJob();
break();
}
}
}
}
537:仕様書無しさん
07/09/24 14:02:06
>>536
＼ ∩─ｰ､
＼／ ● ､_ ｀ヽ
/ ＼( ● ● |つ
| X_入__ノ ミ 俺は釣られないクマ ･･･
､ (＿／ ノ
＼＿＿＿ノﾞ
／ 丶' ⌒ヽ:::
/ ヽ / /:::
/ /へ ヘ/ /:::
/ ＼ ヾミ /|:::
（__／| ＼___ノ/:::
538:526
07/09/24 17:28:31
>>530 ありがとです。
539:仕様書無しさん
07/09/24 17:30:27
プログラミングが上達するコツ
ｽﾚﾘﾝｸ(tech板)
540:仕様書無しさん
07/09/24 19:11:26
int mind;
mind = kokoro()
while (1)
{
mind -= 1;
if (mind < 0)
{
takeMedicine();
goHospital();
if (mind < 0)
{
quitJob;
break();
}
}
}
541:仕様書無しさん
07/09/24 20:42:13
>>540
これバグってるだろｗｗ
仕事してないのになんで mind-=1 なんだよ。
仕事しろ仕事ｗ
542:仕様書無しさん
07/09/24 20:50:48
>>540
Jobインターフェースが実装されてません。
java.neet.helloworkパッケージからインポートして実装してください
543:仕様書無しさん
07/09/24 21:02:35
NoSuchMethod : kokoro()
544:仕様書無しさん
07/09/24 21:14:18
今システムテストしてるソース群みてびっくりしたよ、
ぜんぜんエラーハンドリングしてないの
最近の奴らは戻り値とか関係なしか?
545:仕様書無しさん
07/09/24 21:21:29
俺は自分がデバッグする時楽するために
必ず戻り値のチェック入れてる
546:仕様書無しさん
07/09/24 21:21:51
レスをスルー
例外もスルー
547:仕様書無しさん
07/09/24 21:54:30
「この子画面処理中に異常が発生したらどうすべきか」全く書いてないから実装してあげませんw
548:仕様書無しさん
07/09/24 22:34:12
レスをスロー
例外もスロー
549:仕様書無しさん
07/09/24 23:26:52
まぁ、なんでもかんでもCatchすりゃいいって考えるのは厨だね。
本来どっかでバグがあってこけることでそのバグを見つけるかもしれないってのに
Catchして適当な処理したら、何年たっても見つからない可能性がある。
550:仕様書無しさん
07/09/24 23:27:57
catch 厨
551:仕様書無しさん
07/09/25 00:14:56
>>549
戻り値を監視しながら処理を進めるのが普通だと思ってたが
転職先ではエラー処理は書かないのが基本だった…
郷に入れ歯
552:仕様書無しさん
07/09/25 00:21:51
C系だとアサーションは入れるけど
結局リリース時には素通りだったりするよね
553:仕様書無しさん
07/09/25 00:22:00
>>551
お前が正しい。
554:仕様書無しさん
07/09/25 01:44:59
>>552
だったりと言うかリリースならアサーションはスルーされて当然じゃ？
555:仕様書無しさん
07/09/25 01:46:41
>>554
開発・テスト時に異常にならなければそれでOKじゃね？とエラー処理入れないままなパターン。
556:仕様書無しさん
07/09/25 02:02:11
たまに実行時エラーにアサーション入れたりする奴がいるから困る。
つか、リリースモードでリリースする、
っていう確約が何も無いのにアサーション入れたりする奴がいるけど、
全くもって正気かどうか疑いたくなる。
557:仕様書無しさん
07/09/25 02:37:16
>>556
リリース版で最終テストしてリリースするっていうのは、
ものすごく基本的な話なんじゃないのか?
世の中には、
『デバック版でしか動かないからそのままリリース』
という輩も居るらしいが…
558:仕様書無しさん
07/09/25 04:05:27
msvcrtd.dll（デバッグ版Cランタイム）は再配布禁止…らしいな。
559:仕様書無しさん
07/09/25 11:05:02
FILE1 とか RET2 とか…ソレは何のファイルなのか、どんな戻り値なのか。
辞めようとまでは思わないけどさ。
560:仕様書無しさん
07/09/25 14:13:53
ABAPで例外を拾おうとあくせくした日々が懐かしい。
そもそもまともに例外を拾う気の無いツールでそんなことするのは無駄だった。
561:仕様書無しさん
07/09/25 17:23:02
スレ無いから聞いてみるけど、"QAC"ってどうなの？
そこそこ使えるようだが俺的には hoge==TRUE を問題として検出しないツールはあまり信用できない。
(ほかにも=と==の間違い疑惑を指摘しなかったりとか）
で、うちの会社アホみたいにこのツールの出力結果を信奉している。
相当投資したみたいだから盲信したくなるのはわからないこともないがね。
562:仕様書無しさん
07/09/25 17:36:06
TRUE==hogeを俺は認めないぞ
可読性が著しく低下する。
そんなソースは書いたことがないぞ。
563:仕様書無しさん
07/09/25 18:11:03
TRUE==hogeってことは…TRUE値と、他の真の値を区別したい場合だよな、きっと？
564:仕様書無しさん
07/09/25 18:28:11
もしも真実がホゲだったなら...どうする!?
565:仕様書無しさん
07/09/25 19:03:55
QACを参考に修正したことなど一度も無いな。
開発内テストが終わった後にかけるので意味が無い。
というかこれユーザインタフェースが終わってる。
使いづらいったらありゃしない。
566:仕様書無しさん
07/09/25 21:14:29
・副作用がある
・定数として評価できる
567:仕様書無しさん
07/09/25 21:45:14
「hoge==TRUE」よか「=と==の間違い疑惑」のほうが重要じゃね？
後者に引っかからなくていいから前者に引っかかって欲しいの？
変数同士になっても有効なのは後者じゃ？
ま、どっちでもええか
568:仕様書無しさん
07/09/25 22:23:30
>>561
たぶん検出のための設定があると思うぞ。
569:仕様書無しさん
07/09/25 22:40:20
bool check(hoge){
bool TRUE;
if (hoge >= 0 && hoge <= 100){
TRUE = true;
} else {
TRUE = false;
}
return TRUE;
}
570:仕様書無しさん
07/09/25 22:41:03
うわすっげえむずむずするコード
571:仕様書無しさん
07/09/25 22:46:42
>>569
きもちわりぃｗ
定数左派の人って範囲チェックのときはどうかくの？
( 0 < hoge && 100 > hoge )ってなるのかな？
==の時だけ定数左？
572:仕様書無しさん
07/09/25 22:56:49
>>571のいる会社は大変だな
573:仕様書無しさん
07/09/25 22:59:25
for文書くときもやっぱ
for(int i=0;10>i;i++)
みたいに書くんだろうか？
574:仕様書無しさん
07/09/25 23:13:54
>>573
そういう人もいるよ。
575:仕様書無しさん
07/09/25 23:13:57
gccで動かしててC99仕様で書いてる。
QACにかけるとエラーだらけ。。
576:仕様書無しさん
07/09/25 23:19:08
C99はできる子。
577:仕様書無しさん
07/09/25 23:28:36
>>572
周りに定数左派がいないもんで、ちょいと疑問に思っただけなんだ。
578:仕様書無しさん
07/09/26 01:08:52
気分で左右を入れ替える俺は駄目人間だぜ
579:仕様書無しさん
07/09/26 01:20:07
統一感が無いのはいかんな
580:仕様書無しさん
07/09/26 05:33:49
i++ でも ++i でもいいときに
++i を使う人ってどれくらいいるかな
581:仕様書無しさん
07/09/26 07:40:44
そもそも++i 自体使わなければならない場面はゼロに近いし・・・
わんらいなー気取りで可読性を低くしているのに気付かないだけ
582:仕様書無しさん
07/09/26 08:31:40
「間」なんかは数学では ( 0<x<100 ) とか書くでしょ。だからｃでも ( 0<x && x<100 ) って書く。
583:仕様書無しさん
07/09/26 08:35:28
iteratorを進めるときは使うなぁ、++i。
584:仕様書無しさん
07/09/26 09:32:02
普通の組み込み型等なら後置、イテレータだったりオーバーロードされテルものだったら前置
585:仕様書無しさん
07/09/26 10:13:58
これはイテレータとか、区別するのも性能劣化も嫌だから、
どちらでも良いときは常に前置。
586:仕様書無しさん
07/09/26 10:19:44
同じく無駄な性能劣化は嫌だし、区別するのも面倒だから前置
最近の賢いコンパイラなら後置でも最適化で一時オブジェクトつくらずにやってくれるかもしれんが
587:仕様書無しさん
07/09/26 10:21:11
>そもそも++i 自体使わなければならない場面はゼロに近いし・・・
for (int i = 0; i < N; ++i) なんて頻出じゃないのか？
C#やJavaのforeach(相当)構文や、C++のgenericを使いまくるんなら別だが。
それでも数値インデックスが必要な場合は結構あると思うけど。
588:仕様書無しさん
07/09/26 10:30:55
性能劣化のは ++i より i++ が遅いってやつ？
589:仕様書無しさん
07/09/26 10:45:49
i++ はもとの i を返すために operator++ 内で一時オブジェクトを作るからな
int 程度だったら無視しても構わない劣化に過ぎないだろうが、
オブジェクト(よく使うのは iterator)のコピーなんてさせたらどれだけ劣化するか。
それが最適な構文なら、富豪的プログラムの観点からは問題無いんだが
i++ と ++i ってソースの可読性上は大した違いは無いから、
必要以上に自ら望んで劣化させる必要も無かろうと。
個人的には後置++ はあまり必要ないんだよな。
int j = i++;
とか書かれると一瞬思考が止まる。
漏れのアホな頭ではどうにも評価順が自然に解釈できないらしい。
590:仕様書無しさん
07/09/26 11:39:18
どうしても後置がいいっていうのは
array[ index++ ] = x;
みたいなときだな
591:仕様書無しさん
07/09/26 15:46:27
>>589
なるほど。
普段からjava使ってるから operator オーバライドの影響は頭から飛んでたわ。
++i 派から i++ に矯正された身でやんす。
592:仕様書無しさん
07/09/26 16:17:47
do {
} while( (++n)<(sizeof hoge) ) なんてよく書くから、けっこう使うな。
593:仕様書無しさん
07/09/26 16:22:29
for文でやれ
594:仕様書無しさん
07/09/26 17:10:37
forだと初期化のあとケツの判定に飛ぶのがｲﾔﾝ。初期化のあとに１回判定が入る展開もあったり。
do whileだと静的にも動的にもキレイ。
595:仕様書無しさん
07/09/26 23:39:18
なぜか俺の教育係だった人はfor文を嫌っていた。
俺が下についていたとき、ほとんどのループ処理をwhileで書いてた。
コメントを見ると”とりあえず”って言葉が多くて大丈夫かいな？って思ってた。
596:仕様書無しさん
07/09/26 23:45:22
そういわれるとforって異質かなという気がしてくる。
( ; ; )セミコロンが気に入らんとか？ｗ
597:仕様書無しさん
07/09/26 23:51:42
>>595
「とりあえず」は俺もよく使う。
検索とかに使うキーワードというか、いわばタグ的に。
統合開発環境のブックマーク機能を使えという話もあるが
作業ファイルをクリーンすると飛んでしまうこともあるから、と言い張って
俺様専用的に使わせてもらってる。
598:仕様書無しさん
07/09/26 23:54:47
「せっかくだから」とか使おうかしら
599:仕様書無しさん
07/09/27 00:11:19
某IDEに毒されたか、VBでも「' TODO:」ってやっちまう最近の俺
600:595
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行ぐらいある。
疲れた。そして明日からももっと疲れるだろう。