アカウント名:
パスワード:
コーディング標準が設定され、守られていればそんなことは起こらないはずだ。
「見たまえ。
メソッド名にm000001、m000002、m000003という名前を付けてるだろう？これはＱ社で80年台から96年まで使われていた規約なんだよ。」「ということはこれを書いたのはＱ社のプログラマーだと？」
「いや、ここのコメントに注目したまえ。『変数i00001に３を入れる』『変数o000002にc000001型のオブジェクトをnewする』。このようなコメントはR社で現在も使われている規約だ。
そしてこの部分。『追加１９７６年○月Ｘ日』『追加１９８２年○月Ｘ日』『削除１９８４年○月Ｘ日』『追加１９８５年○月Ｘ日』『追加１９９６年○月Ｘ日』『バグ修正１９９６年○月Ｘ日』『追加２００１年○月Ｘ日』『BUG FIX ２００５年○月Ｘ日』．．．一見すると1970年台から２０００年台になるまで使い続けられている、S社のコードのようにも見える。
しかしこれは犯人の偽装だ。というのもＳ社では２００４年に規約が変更され、その際にコード修正した場合はバグ管理番号とＶＳＳのコミットIDとコード修正の内容をそこに記載することが義務づけられたんだ。だからこんなに完結にコード変更履歴が書けるわけがないんだよ。」（以下省略）
＃じょ、冗談れすよ。こんな糞な規約を使ってる会社があるわけ無いじゃないですか（棒
一糸乱れず全員が同じようにコードを書くのが最も良いプログラミングなのだ
マネージャー「ようし、心の用意はいいか。まず「i」に右手薬指を載せろ、そして右手人差し指は「n」だ。 左手人差し指は「t」だ。「int」を1秒で打ち込むぞ。準備できたか。
・・・・そこ！mainはvoidじゃない！ ああ、お前も、includeを書くのは後からだ！ 誰がemacsを使っていいといった！」
> マネージャー「ようし、心の用意はいいか。まず「i」に右手薬指を載せろアッシは右手中指を乗せていました。間違っていたのか。不安になってきた。
プログラム終了時のfreeなんか不要と言い出す奴が出てきて暴れるに一票
あまり杓子定規なのも困り者。例えば静的解析ツールで特定のワーニングは0件にせよ、とか単体テストで全分岐の組み合わせ必ず通せ、だの。ツールや標準は決まりきった使い道や特定範囲の入力しかない(今後増える見込みもない)モジュール内の特定用途の下位関数と、他モジュールや人間とのI/F絡んでかなり異常値入力を警戒すべき関数の意味の違いを理解してくれない。やれelse節やswitchのdefaultがないだの引数NULLチェックしろだの金輪際使用されない予定の死んだコードを大量にソースに投入することでかえって見通しが悪くなったりバグ混入の機会が増えたり速度が遅くなったりバイナリサイズが膨れ上がったり...
×杓子定規○金科玉条
しかし、あんたが書いた内容ならレビュアーの言ってることの方が正しい。すくなくとも、職業プログラマーが企業システムを作るなら当然のことばかりだが。
個別にいちいち指摘はしなけど、switchにdefaultがない、と言われたら、throw new Exception('これが出たオレはプログラマーやめる’）;とでも書いておけ。（すぐやめることになると思うし、とっとと辞めた方がいい）
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
みんな、勝手な書き方しやがって… (スコア:0)
コーディング標準が設定され、守られていればそんなことは起こらないはずだ。
簡単な推理だよ、ワトソン君 (スコア:1)
「見たまえ。
メソッド名にm000001、m000002、m000003という名前を付けてるだろう？
これはＱ社で80年台から96年まで使われていた規約なんだよ。」
「ということはこれを書いたのはＱ社のプログラマーだと？」
「いや、ここのコメントに注目したまえ。
『変数i00001に３を入れる』『変数o000002にc000001型のオブジェクトをnewする』。
このようなコメントはR社で現在も使われている規約だ。
そしてこの部分。
『追加１９７６年○月Ｘ日』『追加１９８２年○月Ｘ日』『削除１９８４年○月Ｘ日』『追加１９８５年○月Ｘ日』『追加１９９６年○月Ｘ日』
『バグ修正１９９６年○月Ｘ日』『追加２００１年○月Ｘ日』『BUG FIX ２００５年○月Ｘ日』．．．
一見すると1970年台から２０００年台になるまで使い続けられている、S社のコードのようにも見える。
しかしこれは犯人の偽装だ。というのもＳ社では２００４年に規約が変更され、その際にコード修正した
場合はバグ管理番号とＶＳＳのコミットIDとコード修正の内容をそこに記載することが義務づけられたんだ。
だからこんなに完結にコード変更履歴が書けるわけがないんだよ。」（以下省略）
＃じょ、冗談れすよ。こんな糞な規約を使ってる会社があるわけ無いじゃないですか（棒
Re: (スコア:0)
一糸乱れず全員が同じようにコードを書くのが最も良いプログラミングなのだ
Re:みんな、勝手な書き方しやがって… (スコア:5, おもしろおかしい)
一糸乱れず全員が同じようにコードを書くのが最も良いプログラミングなのだ
マネージャー「ようし、心の用意はいいか。まず「i」に右手薬指を載せろ、そして右手人差し指は「n」だ。
左手人差し指は「t」だ。「int」を1秒で打ち込むぞ。準備できたか。
・・・・そこ！mainはvoidじゃない！ ああ、お前も、includeを書くのは後からだ！
誰がemacsを使っていいといった！」
Re: (スコア:0)
> マネージャー「ようし、心の用意はいいか。まず「i」に右手薬指を載せろ
アッシは右手中指を乗せていました。
間違っていたのか。不安になってきた。
Re: (スコア:0)
プログラム終了時のfreeなんか不要と言い出す奴が出てきて暴れるに一票
Re: (スコア:0)
あまり杓子定規なのも困り者。
例えば静的解析ツールで特定のワーニングは0件にせよ、とか
単体テストで全分岐の組み合わせ必ず通せ、だの。
ツールや標準は決まりきった使い道や特定範囲の入力しかない
(今後増える見込みもない)モジュール内の特定用途の下位関数と、
他モジュールや人間とのI/F絡んでかなり異常値入力を警戒すべき
関数の意味の違いを理解してくれない。
やれelse節やswitchのdefaultがないだの引数NULLチェックしろだの
金輪際使用されない予定の死んだコードを大量にソースに投入することで
かえって見通しが悪くなったりバグ混入の機会が増えたり速度が遅くなったり
バイナリサイズが膨れ上がったり...
Re:みんな、勝手な書き方しやがって… (スコア:2, すばらしい洞察)
×杓子定規
○金科玉条
しかし、あんたが書いた内容ならレビュアーの言ってることの方が正しい。
すくなくとも、職業プログラマーが企業システムを作るなら当然のことばかりだが。
個別にいちいち指摘はしなけど、
switchにdefaultがない、と言われたら、
throw new Exception('これが出たオレはプログラマーやめる’）;
とでも書いておけ。
（すぐやめることになると思うし、とっとと辞めた方がいい）