7.は同じく違和感あった。ループの中の条件分岐でネストが無限に深くなっていくほうがよっぽど悪いと思ってたんだけど。少なくとも誰もが認めるというほど「悪い」とは思えない。構造化原理主義的にはbreakもcontinueも必要ないし実際Pascalには存在しないって話かね? 原文見たら > a rule-making group declared とか書いてるし全然普遍的なルールって気がしないんだけど。
while (i<a.length){ ... if (test(a[i]) then return a[i]; ... }
大体はやってないけど (スコア: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)
０．嘘を書く。
# 以上。
Re:大体はやってないけど (スコア:2)
6はもしかすると、
「この関数に渡す時だけに適用されるルールがある謎文字列」とか「オレオレJSONモドキ」とかのような、負の遺産まっしぐらなヤツを言っているのかもしれない。。。
7は私もよく使う。
もちろん1ループ単位で綺麗に終了条件が定まるフローを作るのが基本だけど、
「これ以降は処理しないでねフラグ」みたいなのを使うより、途中でぬける方がよほど好ましいと思う。
Re:大体はやってないけど (スコア:1)
冒頭の内容からも、それぞれのルールにたいするコメントからも、「XXXというルールがあるけど、破ったほうが良いときもあるよな！？破っても良いけど上司には黙っとけよ！」っていう記事に読めます。
たとえば、6については、要件を満たす上で標準ライブラリや広く知られているライブラリでは十分でない時に限って、データ構造を当たらしく作っても良いと書いてありますね。
7も同様で、ループの不変条件だけで制御しようとするとgoto禁止と同様な冗長な表現になるので問題だと有ります。
Re: (スコア:0)
7.は同じく違和感あった。ループの中の条件分岐でネストが無限に深くなっていくほうがよっぽど悪いと思ってたんだけど。少なくとも誰もが認めるというほど「悪い」とは思えない。構造化原理主義的にはbreakもcontinueも必要ないし実際Pascalには存在しないって話かね?
原文見たら
> a rule-making group declared
とか書いてるし全然普遍的なルールって気がしないんだけど。
Re:大体はやってないけど (スコア:2)
悪い一例として、
否定な名前を使う。
Re: (スコア:0)
どちらも時と場合によりけりだけど、
6.はその場しのぎのオレオレデータ構造
7.はループ離脱条件が甘すぎる、ほぼ無限ループを作ってしまうこと
ととらえていいんじゃないかな。
Re: (スコア:0)
私もここで引っかかりました。
6はSTLとか有名ライブラリーみたいな、あり物を極力活用しろって事ですかね、不勉強でごめんなさい。
7はちょくちょくやるうえに、たまに1との合わせ技で多重ループから抜けたりします。
Re: (スコア:0)
構造化を誤解して大量のフラグで個別に後処理をスキップしてループの頭に戻って別のフラグでループを抜けるとかやってた人がいたなあ。