アカウント名:
パスワード:
> 6.独自のデータ構造を書く> 7.ループの半ばでループを抜ける
これって駄目だったんだ？普通にやってしまってるけど……。
6番のデータ構造を書くっていうのが漠然とし過ぎて、具体的にどんなデータ構造を書いてどのように使ったらどう悪いのかわかんないなぁ。メソッドを持たないクラスを書いたらそれもデータ構造だと思うけど、それも駄目って事？構造体だけを言ってるんなら、何故に構造体だけ駄目なのか？ ……うーん、わからない。原文も読んでみたけど、どうも……要約すると「大体のデータ構造は既に用意されてるからそれ使えや」
単に、既存のライブラリで使える構造体を独自に実装するなってだけかと。で、余計な機能が付いてる駄目ライブラリなら無視して良いって、原文には書いてる。
あと、ループを抜ける件については、「ループを抜ける理由を書け」って事らしい。で、フラグ命名に抜ける理由を付けると可読性が上がるよって事だって。
でも個人的には、フラグ乱立の方がよっぽど危険だと思う。ま、この辺はケースバイケースだが。
> あと、ループを抜ける件については、「ループを抜ける理由を書け」って事らしい。> で、フラグ命名に抜ける理由を付けると可読性が上がるよって事だって。
えー、ループを抜ける場所にコメント書いておけばいいじゃん。つーか
> 2. 関数名だけで内容がわかるようにしてドキュメンテーションを避ける
とも言っているんだけどそれはどうなったのよ。関数じゃなくて変数だからいいんだとでもほざくのかこいつら?
コメントは嘘を書けるから信用に値しないと思う。
で、関数名だけでドキュメントを付けないのは、頻繁にリファクタリングされる場合に、関数名を変えられると何も残らないから駄目らしい。
でも、嘘のコメントはもっと有害だから、上手く使い分けろって事らしい。
関数名に嘘が書けないとでも？
関数なんて最初名前つけたら変えないから拡張したときに名前と機能は変わってるでしょうね。それとも拡張したときに関数名変えろと言う話しになるんですかね？
だから、関数名だけでドキュメントを付けないのは良くないって話なんじゃ。で、ドキュメント部分を更新せずに機能だけ付加するような改造はするなって事でしょう。//でも、多くの現場では実行コードしか修正しないからメンテ不能になる
そうするとフラグ変数の名前をドキュメント代わりにすることでどんなご利益があるの? 嘘(になった)名前で騙されるんじゃないの? という最初の疑問に戻る。
プログラミング技法に唯一の正解なんて無い。
改変を多数受けて、更にリファクタリングするものも在れば、そのまま使われ続けるコードもある。半年後に自分がメンテする場合もあれば、他人が弄り回す場合もある。つまりはケースバイケース。
で、今書いてるプログラムが何れに該当するかを見極めて最善の手法をとるのが優れたプログラマってだけ。ま、将来を予測出来る人間なんて滅多に居ないけどね。
コメントは嘘がかけるからドキュメントをつけるてドキュメントも嘘書けると思いますよ。
オレは、まずコメントでプログラム書いて、それを実行するように作るなー。
０．嘘を書く。
# 以上。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
大体はやってないけど (スコア:1)
> 6.独自のデータ構造を書く
> 7.ループの半ばでループを抜ける
これって駄目だったんだ？
普通にやってしまってるけど……。
6番のデータ構造を書くっていうのが漠然とし過ぎて、具体的にどんなデータ構造を書いてどのように使ったらどう悪いのかわかんないなぁ。
メソッドを持たないクラスを書いたらそれもデータ構造だと思うけど、それも駄目って事？
構造体だけを言ってるんなら、何故に構造体だけ駄目なのか？ ……うーん、わからない。
原文も読んでみたけど、どうも……要約すると
「大体のデータ構造は既に用意されてるからそれ使えや」
Re: (スコア:3)
単に、既存のライブラリで使える構造体を独自に実装するなってだけかと。
で、余計な機能が付いてる駄目ライブラリなら無視して良いって、原文には書いてる。
あと、ループを抜ける件については、「ループを抜ける理由を書け」って事らしい。
で、フラグ命名に抜ける理由を付けると可読性が上がるよって事だって。
でも個人的には、フラグ乱立の方がよっぽど危険だと思う。ま、この辺はケースバイケースだが。
-- Buy It When You Found It --
Re:大体はやってないけど (スコア:0)
> あと、ループを抜ける件については、「ループを抜ける理由を書け」って事らしい。
> で、フラグ命名に抜ける理由を付けると可読性が上がるよって事だって。
えー、ループを抜ける場所にコメント書いておけばいいじゃん。つーか
> 2. 関数名だけで内容がわかるようにしてドキュメンテーションを避ける
とも言っているんだけどそれはどうなったのよ。関数じゃなくて変数だからいいんだとでもほざくのかこいつら?
Re:大体はやってないけど (スコア:2)
コメントは嘘を書けるから信用に値しないと思う。
で、関数名だけでドキュメントを付けないのは、頻繁にリファクタリングされる場合に、関数名を変えられると何も残らないから駄目らしい。
でも、嘘のコメントはもっと有害だから、上手く使い分けろって事らしい。
-- Buy It When You Found It --
Re: (スコア:0)
関数名に嘘が書けないとでも？
Re: (スコア:0)
関数なんて最初名前つけたら変えないから拡張したときに名前と機能は変わってるでしょうね。
それとも拡張したときに関数名変えろと言う話しになるんですかね？
Re:大体はやってないけど (スコア:2)
だから、関数名だけでドキュメントを付けないのは良くないって話なんじゃ。
で、ドキュメント部分を更新せずに機能だけ付加するような改造はするなって事でしょう。
//でも、多くの現場では実行コードしか修正しないからメンテ不能になる
-- Buy It When You Found It --
Re: (スコア:0)
そうするとフラグ変数の名前をドキュメント代わりにすることでどんなご利益があるの? 嘘(になった)名前で騙されるんじゃないの? という最初の疑問に戻る。
Re:大体はやってないけど (スコア:2)
プログラミング技法に唯一の正解なんて無い。
改変を多数受けて、更にリファクタリングするものも在れば、そのまま使われ続けるコードもある。
半年後に自分がメンテする場合もあれば、他人が弄り回す場合もある。
つまりはケースバイケース。
で、今書いてるプログラムが何れに該当するかを見極めて最善の手法をとるのが優れたプログラマってだけ。
ま、将来を予測出来る人間なんて滅多に居ないけどね。
-- Buy It When You Found It --
Re: (スコア:0)
コメントは嘘がかけるからドキュメントをつけるて
ドキュメントも嘘書けると思いますよ。
Re:大体はやってないけど (スコア:1)
オレは、まずコメントでプログラム書いて、それを実行するように作るなー。
the.ACount
Re: (スコア:0)
０．嘘を書く。
# 以上。