page_adsence

ラベル Program の投稿を表示しています。 すべての投稿を表示
ラベル Program の投稿を表示しています。 すべての投稿を表示

2014年5月20日火曜日

プログラミング作法(名前の付け方編)

プログラムを書いている時によく頭を悩ますのが変数や関数等々の名前の付け方。
Google翻訳みたいな感じで最適な名前を返してくれるサービスが欲しいと何度思ったことか。

「名前は情報を含み、簡潔で覚えやすく、できれば発音可能な名前が望ましい。」

とか言われても正直そんないい名前ほいほい思いつかないです。
でも、訓練次第ではいい名前が付けられるようになると思うので、自戒の意味を込めて記載しておきます。

1.グローバルとローカルの名前の付け分け


「グローバルにはわかりやすい名前を、ローカルには短い名前をつける。」

グローバル変数は定義上プログラムのどこにでも出現する可能性があるため、読む人がその意味を思い出せる程度に長く、説明的な名前をつける必要がある。
個々のグローバル変数の宣言に短いコメントを入れておくとよい。
変数だけでなく、グローバルな関数、クラス、構造体にも、プログラム中での役割を表す説明的な名前をつける必要がある。

逆にローカル変数は短い名前で十分。
あまり長い名前は逆にプログラムの可読性を下げる。

2.統一性を出し、コードを文章に


「関連性のあるものには関連性のある名前をつけ、関係を示すと共に違いを際立たせるようにする。」

class UserQueue {
    int noOfItemsInQ, frontOnTheQueue, queueCapacity;
    public int noOfUsersInQueue() {…}
}

上記のプログラムではQueueという単語がQ、Queue、queueとして登場している。
しかしキューはUserQueue型の変数からしかアクセス出来ないので、メンバ名に"queue"を入れる必要はない。
文脈だけで十分に理解出来るので、下記の文は冗長である。
queue.queueCapacity

そのため、下記のプログラムの方が優れていると言える。
class userQueue {
    int nitems, front, capacity;
    public int nusers() {…}
}

このように記述することで、下記のように文を書けるようになる。
queue.capacity++;
n = queue.nusers();

3.関数名の付け方


「関数には能動的な名前をつけ、問題がなければそのあとに名詞をつける。」

now = date.getTime();
putchar('¥n');

ブール値を返す場合は、戻り値が不明確にならないような名前をつける必要がある。
わかりにくい
if (checkoctal(c)) ...

わかりやすい
if (isoctal(c))...

とりあえず今回はここまで。
今後もこの内容を意識してプログラミングしていきたいと思います。

2013年5月15日水曜日

MySQLの勉強法と構築法

最近MySQLに詳しい人と一緒に仕事をすることになり、結構色々と勉強になることを教えてもらったのでメモを残しておく。

プログラム全般に関して
プログラムのデザインパターンやソート関連のアルゴリズムは目を通しておく程度に勉強しておいた方がよい。
自分の中で概念のインデックスを作ることで、それを手がかりに実装方法を検索しプログラミングすることができる。

データベースソフトウェアに関して
データペースソフトに関してはOracleが最も優れているので、Oracleで実装されている機能を覚えておくとよい。(MySQLで実装されていなくとも、それに似たことをすることは出来る可能性がある。)

DB設計に関して
画面仕様書が出来る前にDB設計をすることはWeb系の案件ではほぼ皆無なので、画面からDB設計を行っていけるようにする。
設計の大まかな手順
1.画面上から保存しないといけない要素の洗い出し
2.正規化を行い、各テーブルに振り分ける

プログラミングに関して
プログラムを書く際には、DB側で出来る処理は全てDBに任せる。
DBでどうしても出来ないものに関してはWeb側で処理をする。
理由はユーザーの流入経路がWebからDBの順番であるから。
Web側にはユーザー数とイコールの関係で負荷が掛かるが、DBに関してはDBアクセスが必要なページ以外では負荷がかからないので、Web側の負担を軽くするために、なるべくDB側に寄せる方が懸命である。

データベースエンジンの選び方に関して
ログ系や認証系のものを保存するのであればMyISAMやKVSが向いている。
但し、1つのDBサーバにエンジンが異なるものを使用するのは現実的ではないため、大概のシステムでInnoDBが採用されている。
もし本当にDBを分ける必要があれば、エンジンごとに別のDBサーバを使用するのがよい。

MySQLのカラム数に関して
MySQLのカラム数が100を超えると格段にパフォーマンスが下がるので、その場合は正規化してやる必要がある。
そうすることで、インデックスの数も減るし、オプティマイザが迷うことが少なくなるので、高速化される。

とりあえず今日話した内容はざっくりこんな感じ。