Javaプログラマが知るべき9のこと - @katzchang.contexts
はじめに ソースコードは設計であり、コードの記述は品質に直結するのは言うまでもない。ちなみに、プログラマにとって特に重要なのは保守性だ。コードは書いた直後から保守対象となるからだ。コードは要求文書の範囲で動けばいいと思っている人がいれば今すぐ、ソースコードをコピペして100klに増えるプラグインがいつの間にかインストールされる呪いをかけてあげよう。幸い、ここを読んでいる人にはそんな人はいないだろうと思うけれども。 ということで、コードの品質を下げる要因、すなわちシステム全体の品質を下げる要因となり、かつ使われやすいアンチパターンを挙げ、対策を検討していくことにする。対象は以下： 出力パラメータ 処理状態返却 意味のある配列 無意味な初期化 多すぎるtry-catch 暗黙の順序 コンパイラ警告の無視 過剰なコメント e.printStackTrace() 出力パラメータ メソッドの引数にオ
最短経路探索問題 - @katzchang.contexts
スタートからの距離がdであることが決定している点集合P(d) = [p1, p2, ... , pn]に隣接し、かつ距離が決定していない点集合をP(d+1)として決定する…というのを再帰的にやると、距離のマップが出るよね。このとき、壁は初期状態から距離∞（無限大）を持つとする。 で、経路は、ゴールから逆に、決定した距離が-1になる隣接点を辿れば、大丈夫なんかな。 アルゴリズムをググったら負けだと思っている。 コードは汚い。whileは負けだていうか再帰じゃないし。テストコードもない。あげくの果てにスタートまで塗りつぶしているがもう終わり。 多分…3時間は超えたなぁ。 Point = Origin mimic Point Start = Point mimic Point Start start? = true Point Start dist = 0 Point Wall = Point
privateメソッドは不要 - @katzchang.contexts
そのままの構造で全部publicにしろってわけじゃなく、大抵のprivateメソッドは別クラスに切り出して委譲できるか、もしくはstaticメソッドに切り出せるからそうしようって理屈です。とりあえずprivateな内部クラスとして定義するとか。結果、publicメソッドしか残らなければ上出来。 大抵のprivateメソッドは別の複数のpublicメソッドから呼ばれて、かつインスタンス変数の内容を更新する（つまりインスタンスの状態を変える）ことになるはず。そのprivateメソッドが更新する変数（の一部）を別のメソッドが更新できるようになると、あるインスタンス変数の状態を管理するのは誰なんだろうというのがとっても混乱する。privateメソッドに切り出したということは、そのprivateメソッドが更新するインスタンス変数はそのメソッドで共通的に管理したいという意図があるはずで、対象となるイン
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
