|
× [PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。 |
|
 |
 |
|
印刷可能文字９４文字のうち９１文字使って
バイナリをテキスト変換するｂａｓＥ９１があるので ９４文字すべて使う変換はないかなと探していたら・・・ 検索結果にＡｓｃｉｉ８５とかＢａｓｅ８５とか呼ばれるものが出てきた 調べてみると・・・ btoa versionとかAdobe version、RFC 1924 versionなど いくつかのバージョンがあるが 基本的には４オクテットを５桁の８５進数に変換する またパディング文字は使用しない 不足分を符号時は０で複合時は８４で埋める 変換後、追加した分を捨てる またバージョンによっては 特定の場合（４オクテットが全て０とか空白）は ８５文字以外の１文字で表す等色々な工夫がされている ９４文字全て使って変換するより ９１文字＋残りの文字に特別なビット列を割り当てた方が 効率よくなる場合もあるなぁ 両方の実装を考えてみるかな PR |
|
|
|
|
|
コメントは悪である
コメントに時間を費やすより 解説的なコードを書くことに時間を費やせ コードを修正してもコメントは修正されなかったり コメントがコードの処理方法と微妙に違ったりと コメントを書くより説明的なコードを書いた方がいい 脱初心者としてよかった思う本を3冊上げるとすれば クリーンコードを含む以下の本かな＾＾
|
|||||||||
|
|
|||||||||
|
|||||||||
|
|
メソッドは1,2行がベストである
20行を超えるメソッドは ほとんどあってはならない Javaを独学しはじめたころ 上から順番に処理されのだから 重複がなければメソッドに分割する必要はないと思った そんな時同じことを考えてる人が・・・ 10年ほど前の話だが・・・ なぜ複数のメソッドに分割するのだろうか？ 一度しか呼ばれないメソッドにもかかわらず メソッドの呼び出しもタダでないのに・・・ 馬鹿げている・・・と書かれていた記事を読んだ （どこで読んだか覚えていないが・・・） それから大きな塊のメソッドを書いていたが・・・ 「クリーンコード」を読んで その考え方が変わった メソッドを修正するとき その影響範囲を調べるが その範囲は狭いほうがいい 変数もスコープが小さければ小さいほどいい スコープが広ければ 実際には使われていなくても その範囲全体を調べるし なぜそれだけのスコープを必要としたか 悩んでしまう 同じ1000行のコードでも １つのクラスで書かれたものと 200行のクラス×５で書かれたものでは 後者のほうが読みやすい おっきな引き出し１つに全部入っているものと ちぃさな引き出し沢山に1つずつ入ってるものでは・・・ 多少処理速度が遅くなっても 読みやすくバグが入りにくくなった方がいい＾＾ |
|
|
|
|
|
クリーンコード・・・
この本を読む前後で同じような処理をするプログラムを書いた その後この処理方法を変更することに・・・ この本を読んだ後に書いたプログラムはすんなり変更できたが・・・ 読む前に書いたものは・・・＞＜ なぜこの本にもっと早く出会わなかったのだろう・・・；； 中でも印象に残っているのが・・・ メソッドは第一に小さくせよ 第二にもっと小さくせよ メソッドの引数にbooleanが含まれていたり 本体にif文等が含まれていたりすると そのメソッドは２つ以上のことをしている可能性がある メソッドは１つのことだけをする （複数の処理をしない） クラスについても同様で 第一に小さくせよ 第二にもっと小さくせよ メジャーなフレームワークでも 多くのクラスは200行以下で書かれている クラスは１つだけの責務を持つべきである クラスの書き方は新聞の書き方に似ている 見出しがあってだんだん詳細について書いていく 大きい粒度のメソッド 中粒度のメソッド 小粒度のメソッド 新聞のレイアウトを参考に 上から下に読み進めれるようにする 上下に行ったり来たりする量と幅を小さくすることで より読みやすいソースコードになる
 |
||
|
|
||
|
||
|
|
Ｚの法則・・・
広告など見るとき 人はＺに紙面を見る・・・ この性質を利用して 見て欲しいものから配置する また同じように配置されたものが続くと 他のものを見てもそこにあるものと・・・ ＧＵＩも同じで一般アプリと同じように ボタン等を配置しないと・・・ 自分で作ったものでも配置が違うと・・・ 頭では分かっているつもりでも・・・ 間違えるし使い辛い・・・＾＾； ＵＩも奥が深い・・・ |
|
|
|
|
|
忍者ブログ [PR] |