- 1 名前：仕様書無しさん [2007/08/14(火) 23:48:45 ]
- この会社辞めようと思ったソースコード。
プログラマとして幻滅するソースコード。
プログラマを悩ませるソースコード。
をつらつらと綴っていって頂戴。
ちなみにここは質問スレじゃないので
技術的な質問がしたいならム板 pc11.2ch.net/tech/ に逝って。
前スレ
この会社辞めようと思ったソースコード＃17
pc11.2ch.net/test/read.cgi/prog/1183700531/
- 391 名前：仕様書無しさん mailto:sage [2007/09/11(火) 21:13:54 ]
- 臨海値65535か 16bit unsigned
- 392 名前：仕様書無しさん mailto:sage [2007/09/11(火) 21:19:13 ]
- コンパイラをバグらせるとは・・・
コンパイラ「想定の範囲外です・・・」
- 393 名前：仕様書無しさん mailto:sage [2007/09/11(火) 21:19:35 ]
- 臨海値
- 394 名前：仕様書無しさん mailto:sage [2007/09/11(火) 21:20:05 ]
- むしろfloatで
- 395 名前：仕様書無しさん mailto:sage [2007/09/11(火) 21:38:24 ]
- 今はlong long があるじゃまいか！
- 396 名前：仕様書無しさん mailto:sage [2007/09/11(火) 21:48:18 ]
- 遊戯、もうやめて！
コンパイラの示す warning は既に臨海値よ！！
- 397 名前：仕様書無しさん mailto:sage [2007/09/11(火) 21:59:07 ]
- const TYPE const*const&;
- 398 名前：仕様書無しさん mailto:sage [2007/09/11(火) 22:33:15 ]
- /* index.html */
#html
head()
{
style;style.css
}
body()
{
test.
}
#html
- 399 名前：仕様書無しさん mailto:sage [2007/09/11(火) 22:44:26 ]
- これは新しい言語
- 400 名前：仕様書無しさん mailto:sage [2007/09/12(水) 03:34:02 ]
- #define head nanntoka
#define style kanntoka
#define css kanntoka
#define body foo
#define test bar
#include "index.html"
- 401 名前：仕様書無しさん mailto:sage [2007/09/12(水) 09:09:54 ]
- #include "mychtml.h"
int main() {
html(
head(title("Test Page")),
body("Hello, world !!!<BR>\n")
);
}
- 402 名前：仕様書無しさん mailto:sage [2007/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 名前：仕様書無しさん mailto:sage [2007/09/12(水) 23:09:30 ]
- >>402
splitやり過ぎってヤツですか。
- 404 名前：仕様書無しさん mailto:sage [2007/09/12(水) 23:15:26 ]
- ソースコードがスパゲッティ！でもそんなの関係ねぇ！
- 405 名前：仕様書無しさん mailto:sage [2007/09/12(水) 23:33:39 ]
- >>402
んんん！？なんだか見覚えがあるw
- 406 名前：仕様書無しさん mailto:sage [2007/09/12(水) 23:50:26 ]
- >>402
これは素晴らしい無駄関数ですね
- 407 名前：仕様書無しさん mailto:sage [2007/09/13(木) 00:26:45 ]
- これはあれだ、きっとsplit呼び出しの結果が全て同じだと判断して、
自動的に一回の呼び出しに纏めてくれる、素晴らしいコンパイラが存在するんだよ！
- 408 名前：仕様書無しさん mailto:sage [2007/09/13(木) 00:29:07 ]
- それでも最適化なら・・・最適化ならきっとなんとかしてくれる・・・！！
- 409 名前：仕様書無しさん mailto:sage [2007/09/13(木) 00:31:24 ]
- 探すと本当にあるから困る
- 410 名前：仕様書無しさん mailto:sage [2007/09/13(木) 00:33:19 ]
- 最適化? こんぱいる?
くっふふふ
VBScriptというものは
ひとたび構文木にさえ解析されてしまえば
二度とは
二度とは
- 411 名前：仕様書無しさん mailto:sage [2007/09/13(木) 00:56:55 ]
- スパゲティと申したか
- 412 名前：仕様書無しさん mailto:sage [2007/09/19(水) 19:03:16 ]
- #ifndef Hoge
typedef struct tag_Hoge {
(略)
} Hoge;
#endif
え〜っと。
- 413 名前：仕様書無しさん mailto:sage [2007/09/19(水) 19:52:58 ]
- ・・・きっとCは初めてなんだよ。
先週入門書を読み終わったばかりなんだ。
きっと、きっと・・・
- 414 名前：仕様書無しさん mailto:sage [2007/09/20(木) 00:24:54 ]
- ifndefが嫌いだ
なんでifnodefじゃねぇんだ ややこしいよ
#if !definedのほうがマシだ。 どうせ多重防止とかだったらpragma onceで事足りるからいいけど
- 415 名前：仕様書無しさん mailto:sage [2007/09/20(木) 16:09:26 ]
- >>412
そのソースの意図がさっぱりわからない。
#define と typedef を混同したのだろうか…
- 416 名前：仕様書無しさん mailto:sage [2007/09/20(木) 18:13:33 ]
- >>414
リリース版を表すNDEBUGの方が…
標準に従うと、デバッグ版のみ有効にするのに
#ifndef NDEBUG
...
#endif
と否定が２回来て嫌な感じだ
結局可読性とかで _DEBUG が使うんだけどな
って脱線しすぎか。
- 417 名前：仕様書無しさん mailto:sage [2007/09/20(木) 18:42:13 ]
- NDEBUGは<assert.h>が見るんだっけか。
- 418 名前：仕様書無しさん mailto:sage [2007/09/20(木) 18:55:12 ]
- >>415
FAQ級の落とし穴らしい。
www.kouno.jp/home/c_faq/c10.html#15
- 419 名前：仕様書無しさん mailto:sage [2007/09/20(木) 19:52:18 ]
- そういうレベルが普通なのか？
- 420 名前：仕様書無しさん mailto:sage [2007/09/20(木) 23:51:55 ]
- >>415,418
？？。何をやろうとしてるのかすらさっぱりわからんのだが・・。
- 421 名前：仕様書無しさん mailto:sage [2007/09/21(金) 00:14:14 ]
- >>420
たぶん>>415の言うとおり#defineとtypedefを混同してるんだと思う。
・・・typedefを何回も呼ぶつもりなのか???
後から呼んだ方が有効になるなら、実害はなさそうだけど・・・
と思って試してみたら、さすがに名前が衝突してるってエラーが出た。
- 422 名前：仕様書無しさん mailto:sage [2007/09/21(金) 00:19:15 ]
- 「Hoge」がまだ定義されてなければtag_Hoge型の構造体としてHogeを定義、ってことだろう
何をしたいと思ったかは分かっても何に使うはさっぱりわからんw
- 423 名前：仕様書無しさん mailto:sage [2007/09/21(金) 00:40:31 ]
- Hogeが定義済みだったときにどんな動作をするんだろうな
- 424 名前：仕様書無しさん mailto:sage [2007/09/21(金) 03:36:09 ]
- なるほど、こういうレベルが普通なんだな……
- 425 名前：仕様書無しさん [2007/09/21(金) 13:07:19 ]
- public String getErrorMessage() {
// TODO 自動生成されたメソッド・スタブ
return null;
}
- 426 名前：仕様書無しさん mailto:sage [2007/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 名前：仕様書無しさん mailto:sage [2007/09/21(金) 21:15:10 ]
- >>425
？？？
・・・catchしたいのかなぁ・・・
- 428 名前：仕様書無しさん mailto:sage [2007/09/21(金) 22:00:54 ]
- >>425 が何を言いたいのかさっぱりわからない
これってIDE(eclipse,netbeans,etc)で自動生成されたメソッドでしょ？
納品されたソースにこんなのがあったら嫌だけど、開発中なら腐る程あるよ
- 429 名前：仕様書無しさん mailto:sage [2007/09/21(金) 22:20:59 ]
- private String errorMessage;
から自動生成されたのは分かるが戻り値がぬるぽ
- 430 名前：仕様書無しさん mailto:sage [2007/09/21(金) 23:33:24 ]
- もう辞めた会社のソースだけど、何年も運用を続けてきたシステムの仕様変更があるからと、
俺も参加することになったときに、一月に現行処理のバグを200くらい報告したことがある。
仕様変更自体よりバグとりの時間の方が長い位だった。
そのためだけに一月くらい時間をもらえたのが幸運だったけど。
あと今の現場。JSPのソースが全部スクリプトレット。全部 out.println とかで書いてありやがる。
ほとんどCGI気分だっ。
- 431 名前：仕様書無しさん mailto:sage [2007/09/21(金) 23:34:52 ]
- >>428
保守するコードを開いてみたらTODOだらけってのはよくある話。
- 432 名前：仕様書無しさん mailto:sage [2007/09/21(金) 23:56:00 ]
- 藤堂さんのおおいしょくばなんだね…
- 433 名前：仕様書無しさん mailto:sage [2007/09/23(日) 01:39:37 ]
- 手順書はsudoさんだらけだしな
- 434 名前：仕様書無しさん mailto:sage [2007/09/23(日) 02:07:31 ]
- 作業始めたら安藤さんのお世話になりっぱなしだ
- 435 名前：仕様書無しさん mailto:sage [2007/09/23(日) 02:28:45 ]
- うちには後藤さんが多いから困る
- 436 名前：仕様書無しさん mailto:sage [2007/09/23(日) 02:34:01 ]
- んなこたー知らねーよ
- 437 名前：仕様書無しさん mailto:sage [2007/09/23(日) 02:48:43 ]
- 三木だったり後藤だったりする
- 438 名前：仕様書無しさん mailto:sage [2007/09/23(日) 02:53:17 ]
- // クローズ処理
if(rs != null){
rs.close();
rs = null;
}
（；＾ω＾）・・・
- 439 名前：仕様書無しさん mailto:sage [2007/09/23(日) 02:59:31 ]
- >>438
あるいは正しいような気すらしてくる
- 440 名前：仕様書無しさん mailto:sage [2007/09/23(日) 03:04:50 ]
- 旧VBっぽいアレだな
- 441 名前：仕様書無しさん mailto:sage [2007/09/23(日) 09:12:56 ]
- もうやめたけど前の会社
面接でC++が出来るかどうか聞かれて、出来ますと答えて入社。
引き継いだコードの cout を printf で書き直したらただの C になった。
- 442 名前：仕様書無しさん mailto:sage [2007/09/23(日) 12:02:26 ]
- >>438
これはwindowsのリソース関係の処理？
windowsはよく知らないけど、きっと delete this; してるんだよ。そう願いたい。
- 443 名前：仕様書無しさん mailto:sage [2007/09/23(日) 12:26:43 ]
- >>438
javaではよく見るな。
優先的にGCの対象にするためにわざと参照を外しているらしい
- 444 名前：仕様書無しさん mailto:sage [2007/09/23(日) 12:42:49 ]
- >>443
インスタンス変数に持つとかアホな状況でなければ、変らないけどなー
- 445 名前：仕様書無しさん mailto:sage [2007/09/23(日) 12:54:05 ]
- そうなんだけど、今のプロジェクトでは
必要でなくなった変数にはnullを入れるというコーディング規約
さらにハンガリアン記法も強制
定数名が60文字以上ある状態なのに80文字で折り返し強制
ほか多数
バカ（というか時代遅れ？）が上に立つとろくな事にならんという見本
- 446 名前：仕様書無しさん [2007/09/23(日) 13:08:40 ]
- 長くても分かりやすい名前をつけろというけどさ、
その上でコードは80文字で折り返せって言うのも訳が分からん話だな。
- 447 名前：仕様書無しさん mailto:sage [2007/09/23(日) 13:22:07 ]
- >>445
なるほど、改善提案もできないコミュニケーション能力の欠如した引っ込み思案の自分を
棚上げしてこんなところで文句を垂れる君はバカではないんだw
- 448 名前：仕様書無しさん mailto:sage [2007/09/23(日) 13:33:44 ]
- 60文字の定数のどこが分かりやすいんだ？
- 449 名前：仕様書無しさん mailto:sage [2007/09/23(日) 14:01:15 ]
- >>447
くされ基盤チーム乙ｗ
- 450 名前：仕様書無しさん [2007/09/23(日) 14:06:28 ]
- >>447
お前はまずスレタイ読んだ方がいいな。
- 451 名前：仕様書無しさん [2007/09/23(日) 14:32:22 ]
- CHogeClass::CHogeClass()
{
delete m_pPtr;
...
}
いきなりdelete。
リリースモードだと奇跡的に動くがデバッグモードだと動かない。
そこで、コードを修正するのではなく全員リリースモードだけで開発し始めた。
当然数ヵ月後僕はその会社にいなかった。
- 452 名前：仕様書無しさん mailto:sage [2007/09/23(日) 14:40:01 ]
- >>451 直せよw
- 453 名前：438 mailto:sage [2007/09/23(日) 14:56:56 ]
- >>439 >>442 >>443 >>445
438です。
コメント部分が冗長すぎただけで、処理事態は問題はないです。
rs に null を入れるのは メモリ使用量の多いオブジェクトを、
早めにガーベージコレクションの対象にするためで
間違ってはいないと思います。
ただそれだけでした＞＜
- 454 名前：仕様書無しさん [2007/09/23(日) 15:04:54 ]
- >>451-452
ﾜﾛﾀ
- 455 名前：仕様書無しさん [2007/09/23(日) 15:06:41 ]
- >>453
コメントも別に冗長じゃないけど。
他の処理との兼ね合いで書いているだけでしょう？
//ここでクローズ処理してます。ガベコレ対策でnullいれとります。
//なにか問題でも？
とか書いてあったら冗長だけどな。
- 456 名前：仕様書無しさん mailto:sage [2007/09/23(日) 15:10:16 ]
- 無意味なコメントはよくあるよな。
// ストリームを開く。
public OutputStream openStream() {
...;
}
アホか。
- 457 名前：仕様書無しさん [2007/09/23(日) 15:16:15 ]
- >>456
コメントを抽出するソフトとかあるんだけど、それは知らない？
- 458 名前：仕様書無しさん mailto:sage [2007/09/23(日) 15:18:24 ]
- よーし、修正しちゃうぞ。
//! ストリームを開く。
public OutputStream openStream() {
...;
}
- 459 名前：仕様書無しさん mailto:sage [2007/09/23(日) 15:34:48 ]
- >>455 >>457
SUNが提唱している、
「Java Code Conventions」
ttp://www.tcct.zaq.ne.jp/ayato/programming/java/codeconv_jp/CodeConventions.doc4.html#385
＞コードの中に既に含まれている情報やコードから自明であるような情報を重複させることは避ける
に記載されているように、冗長なコメントは書くべきではないと私は考えます。
コメント自体は書けば書くほど可読性を下げます。
コメント無しで理解できるコードを目指すのがベストだと思っています。
（と、いってもまったくコメント無しでのコードを書くのも不可能でしょうけど）
ちなみにドキュメンテーションはまた別ですが。
- 460 名前：仕様書無しさん mailto:sage [2007/09/23(日) 15:36:08 ]
- >>457
抽出して削除＆書き直しするの？
僕のばあいは、もともとソフト会社じゃないから、Delphi、shのスクリプト、C、C++、C#、JavaScript、MATLAB
、WindowsScriptとか、あとNastran等々みんな適当なコードが残ってる。
「お前出来るだろ」ってほとんどコメント無しでの糞コードでくるから、リファクタリングとかだけでも
「無理っす。無理っす。無理っす。」を連発してる。
てか、いろいろ言葉が通じない。みんな言葉が通じるだけましだよ。
- 461 名前：仕様書無しさん [2007/09/23(日) 15:51:28 ]
- >>459
それは奢りだと思うよ。
誰でもコード読めるわけじゃないしね。
「このブロックでは、○○の処理をしています」って書いてある事で
とりあえず数十行が簡単に読み飛ばせるなら、その方が効率がいいのは自明。
あなたの理想は以心伝心っと同じで、まあある種ありえない理想だと思うよ。
それ言ったらドキュメントも折衝も要らないからね。
全ては「ソースみろ」で済む。
実際はそうあいかないよ。
- 462 名前：仕様書無しさん [2007/09/23(日) 15:53:25 ]
- >>460
抽出してドキュメントを作る参考にするんだよ。
それで処理のサマリーが分かれば、読むときに楽でしょ？
仮に明日全く知らない言語の修正依頼が来たらどう？
適切なコメントがあったら、楽だと思わない？
言語の勉強をゼロから初めて、それからソース読むよりはさ。
- 463 名前：仕様書無しさん mailto:sage [2007/09/23(日) 16:08:29 ]
- 日本人で>>459を実践したい人には
「なでしこ」
ちょーお奨めです。
- 464 名前：仕様書無しさん mailto:sage [2007/09/23(日) 16:09:36 ]
- >>437
「三木」って何？
- 465 名前：仕様書無しさん mailto:sage [2007/09/23(日) 16:16:52 ]
- >>462
書いてること正しいと思うけど、
”言語を全く知らない人”を想定してコメントを書くって作業は（個人的に）勘弁して欲しい。
- 466 名前：仕様書無しさん [2007/09/23(日) 16:22:27 ]
- >>465
だから、それがセンスとバランスなんだって。
//ファイルオープン
//読み込み
//整形
//出力
とかブロックごとにあったら、知らなくても概要は理解できるし、
知っている人にも（余程無能でなければ）邪魔にもならないでしょ。
全く知らない人に完璧に理解させるのは無理でも、手助けにはなる。
VBAとかExcelマクロも数えると、過去にやった言語は20くらいになるし、
極端に多いとも思わない。
ちょっとしたマクロの手直しのために、一からその言語の勉強やるのは厳しいしね。
コメント要らないなら、そもそも、除去なんて簡単にできるしね。
無いコメントを生成はできないけど。
- 467 名前：459 mailto:sage [2007/09/23(日) 16:22:30 ]
- >>461
私も、コメント無しで完全に理解できるコードは不可能だと思っています。
ただし、
「処理フローが明らかであるのにコメントを付けては、
品質が下がるだけでメリットがない」
ということを言いたかっただけです。
＞コメントは，コードの概観と，
＞コード自体からは読み取ることのできない付加的な情報を与えるものであるべきである．
この考えが伝わるつもりでレスしましたが、
文章が至らず誤解させてしまったようです。申し訳なかった。
- 468 名前：仕様書無しさん [2007/09/23(日) 16:24:56 ]
- >>467
書いた側と読む側が非常に優秀ならコメントなしでも読めるよ。
そんで俺の言ってる必要なコードは、あなたの言っている「コードの概観」の話だしね。
「コメントがあるほど可読性さがる」ってのが間違いだって言うなら別にいんだけど。
- 469 名前：仕様書無しさん [2007/09/23(日) 16:26:32 ]
- >>466
センスとバランスとかＳＥとは思えないアバウトな表現。
ＪＡＶＡ言語を知っているというのは、コードを読む上では必須でしょ。
言語を理解した上で
「スパゲティコードだからコメントつけないとわからん」
というならわかるけど。
君の理論だと、コメントの統一性が保たれない。
プロジェクトが始まる前に
このメソッドを使うときは コメントを付ける、つけないとか
全てのクラスに対して説明しなければいけない。
- 470 名前：仕様書無しさん mailto:sage [2007/09/23(日) 16:31:33 ]
- こんなコードはコメントが必須（実話）
// foo に bar を代入し、計算結果をDBに格納する
public getPoo() {
// ながーいコード
}
- 471 名前：仕様書無しさん mailto:sage [2007/09/23(日) 16:31:47 ]
- まぁ、見た限りだと
「ＪＡＶＡ初心者のためにコメントをつけて仕事を早く回す」か
「品質のために冗長なコメントはつけない」 の意見がわかれてるだけでしょ。
前者も後者も言い分はわかるけどね。
そもそも2人の目的からして違ってるから結論でないでしょ。
- 472 名前：仕様書無しさん mailto:sage [2007/09/23(日) 16:32:42 ]
- おっと訂正。
// foo に bar を代入し、計算結果をDBに格納する
public void getPoo() {
// ながーいコード
}
- 473 名前：仕様書無しさん mailto:sage [2007/09/23(日) 16:36:29 ]
- 中小企業なら前者の考え（コーディングを早く終わらせてコスト削減）
大企業なら後者の考え （早く終わらせるよりも品質確保）
でいいじゃん。
- 474 名前：仕様書無しさん mailto:sage [2007/09/23(日) 16:41:36 ]
- >>472
// foo に bar を代入し、計算結果をDBに格納する
public void getPoo() {
}
どこが get してるんだよｗｗ
- 475 名前：仕様書無しさん [2007/09/23(日) 16:52:11 ]
- >>471
いや、その場合品質って何？って話だと思うけど。
よっぽど冗長じゃなきゃ読み飛ばせばすむコメントで品質さがるかな？
そこまでストイックに減らすのって正直自己満足の世界だと思うんだけど。
//このブロックで、先頭の不要行を削除
で10行さらっと読み飛ばせるコメントをつけないメリットの方が
大きいとは思えないな。
- 476 名前：仕様書無しさん [2007/09/23(日) 16:54:34 ]
- 別につけたくないならつけないでいいけどさ。
もっとも害なのは変なこだわりとか自己満足をおしつけて
「俺はこれが正しいと思う。だから全員これをやれ。
これ以外はクオリティが下がるのでダメだ」って奴だと思う。
真面目な話。
そしてそういう奴は大抵「いや、あんたそれ以前にマシなコード書いてよ」
って奴なんだよな。
自己満足と自己肯定ばっかりで、「いや、もしかしたらこっちの方がいいのかも」
とは少しも考えない。
俺は人に押しつけまではしないけどね。
- 477 名前：仕様書無しさん mailto:sage [2007/09/23(日) 16:58:07 ]
- >>475
＞よっぽど冗長じゃなきゃ読み飛ばせばすむコメントで品質さがるかな？
下がるわ。コメント範囲の大小は関係ない。
- 478 名前：仕様書無しさん [2007/09/23(日) 16:58:19 ]
- >>475に同意。
三行ごとにコメントがついてるとかの極端な話じゃなければ、ついてて良いと思う。
何事もないよりある方がマシ。
- 479 名前：仕様書無しさん mailto:sage [2007/09/23(日) 16:58:59 ]
- >>476
だから、自己満足じゃなくて、Sunの規約に準じてるだけでしょ？
そこを無視するとかプログラム的にはありえんわ
- 480 名前：仕様書無しさん [2007/09/23(日) 17:00:31 ]
- ま、sunの言う通りにやればいいんじゃないの？
とにかくsunが言うんだから間違いないよねぇｗ
- 481 名前：仕様書無しさん mailto:sage [2007/09/23(日) 17:02:38 ]
- なでしこ使うんだ。
なでしこなら冗長なコメントなんか付けなくなる。
- 482 名前：仕様書無しさん [2007/09/23(日) 17:02:47 ]
- ちなみにCOBOLでコード書く場合もsunの規約に従う必要あんのかな？
Java限定の話だったっけ？
- 483 名前：仕様書無しさん mailto:sage [2007/09/23(日) 17:03:37 ]
- 自分の理論で「これはこうあるべき」って書くから駄目なんでしょ。
自己流コーディングはよくないよ。
Sunの規約として用意されてるなら使うべきだし、
そのプロジェクトの規約として別な方法が記載されていたらそっちを優先すべき。
- 484 名前：仕様書無しさん [2007/09/23(日) 17:04:43 ]
- >>483
プロジェクトの規約も使用言語も一切無視して、とにかく「コメントは少ない方がいい。
sunがいうんだから間違いない！！」ってキチガイさんに言ってやってくださいｗ
- 485 名前：仕様書無しさん mailto:sage [2007/09/23(日) 17:05:51 ]
- >>482
COBOLはその言語に適した規約があるでしょ。
言語によって保守や拡張性に対する考え方も違うしね。
- 486 名前：仕様書無しさん [2007/09/23(日) 17:07:07 ]
- >>485
だよね。
それを無視して「コメントは少ない方がいい！」ってほえてるのって馬鹿過ぎだよね。
いつからJavaの話になったんだか。
- 487 名前：仕様書無しさん mailto:sage [2007/09/23(日) 17:07:19 ]
- >>479
- 488 名前：仕様書無しさん mailto:sage [2007/09/23(日) 17:08:08 ]
- >>484
だからさ・・・
「プロジェクトの規約として別な方法が記載されていたらそっちを優先すべき」
って言ってるでしょ。
そりゃクライアントがそういう風に指定したらそっちを使うのが当たり前っしょ。
わざわざ指定されてるのに別な書き方してたら訴えられるそ。
おまえはどんなプロジェクトだろうと自己流コードをかいてりゃいいさ
- 489 名前：仕様書無しさん mailto:sage [2007/09/23(日) 17:08:38 ]
- >>482
sunのガイドラインがどうこう言う前に、コボルは旧コードをコメントアウトして残すのを辞めれ。
- 490 名前：仕様書無しさん mailto:sage [2007/09/23(日) 17:08:44 ]
- MSのハンガリアンマンセーに従ってた奴乙
- 491 名前：仕様書無しさん [2007/09/23(日) 17:09:44 ]
- >>488
＞ だからさ・・・
＞ 「プロジェクトの規約として別な方法が記載されていたらそっちを優先すべき」
うん。
だから言っている内容を変更したわけだよね？
それって後付けだよね？
だとしたら、最初に言った「コメントは少ない方がいい」って間違えたんだよね？
|
 |
