クライアントのコーディング規約は絶対であり、それに沿ってコーディングしたプログラムが良質なのです

フリープログラマへの道

Home > プログラミング > コーディング規約

プログラミング時の約束事がコーディング規約です

Sponsored Link

コーディング規約

コーディング規約

フリープログラマは、当たり前の事ですが、ひとつの会社だけの仕事をするということは稀であり複数の会社の仕事を行います。 同時に2社の仕事をこなすといったことも起こりえるのです。そこでちょっと気をつけなくてはならいないことが事があります。

同じ言語であっても、それぞれの会社には独自のコーディング規約が存在し、それに沿ったプログラムを書かなければいけないということです。  同じ言語ならまだしも、違う言語で尚且つコーディング規約が違うとなれば、頭の中はパニック状態です^^。

コーディング気規約は明示的に文書化されている場合もあれば、暗黙のルールの場合もあります。  暗黙のルールの場合はサンプルプログラムを渡されてこんな感じでお願い、ということになります。

コーディング規約は、納品後のメンテナンスや修正のためのものであり、 仕事を請けたからには、そのクライアントの規約に従ってコーディングすることになります。  納品される会社にしてみれば、自社のコーディング規約に則って書かれたプログラムが質が良いプログラムであり、 読み易いプログラムといえるのです。 

しかし、私事ではありますが、あまりにも細かい規約は、かえってプログラムを読み難くし、 プログラミング効率も下がってしまうのではないかと思います。何事も程ほどが一番よいというこですね。

では実際どのようなコーディング規約があるのか見てみましょう。

変数名

変数は2つの部位に分けることができます、サフィックスと変数名です。たとえば状態を格納する変数を考えてみましょう。  私が一番先に思いつくのは”Status”という変数名です、

コーディング規約で変数には必ずデータ型を表す3文字を先頭につけるとすれば”intStatus”になります。 そして、その変数の存在箇所を示す1文字を先頭に付加するとあれば、 引数の場合は”pintStatus”クラス内でのローカル変数ならば”lintStatus” 関数ないのローカル変数ならば”iintStatus”といった具合になっていくことでしょう。 

また変数名自体も英語、ローマ字、日本語(漢字も含め)など指定される場合もあります。 

私個人的には、変数名は基本的には英語にし、固有名詞など、どうしても英語に変換しにくい場合だけはローマ字を使用し、 サフィックスは、引数だけは区別する程度でいいのではないかと考えています。 

変数にデータ型を付けることは、確かに変数名を見ただけでデータ型を認識することができるというメリットはありますが、 プログラミングの途中でデータ型を変更することはよくあることで、その時に変数名も変更しなくてはなりません、

それに間違ったデータ型の代入はコンパイル時にエラーやワーニングで確認できるので、 それほど気にしなくてもいいような気がします。

関数名

関数名もまたいろいろあります^^ サフィックスを付ける規約もあります、例えば返り値がある関数ない関数、 グローバル、プライベートなど切がないです。

例としてAマスターのリストを取得する関数名を考えて見ましょう 単純に"GetAList()"で良いと思うのですが、グローバルで返り値があるので、 "gfnkGetAlit()"などと書くコーディング規約もあります。

私は関数に関してはサフィックスより、何をする関数かを明示的にすることの方が大切だと考えています。  なので関数の頭3文字は動詞の短縮形を付けています。 

例えば"Get"、"Set"、"Mng"、などといった感じです。 全てこの形で表現できるわけではないのですが、 やはり関数は何らかの処理を行うわけですから、動詞を頭に付けることは意味があると思います。 

データベース

ソースのコーディング規約と同様にデータベースにも規約があります。

しかも、ソースに対するルールより厳密に規約が定められていることが多いように思います。 但しコーディング規約と同様に明示的に文書化されている場合もあれば、暗黙のルールの場合もあります、 暗黙というかその会社の癖といったほうがいいかもしれません。 

テーブル名、フィールド名の命名規則から、フィールドのNULLの許容、外部キー(FK)の使用の有無、まで、 ほんとに様々な規約があります。データベースの場合、 開発中に複数の開発者が参照することが多々あるわけで規約は厳しくなることは当然なのでしょう。 

その中でもフィールド名の命名規則については、会社により全く違うことが多いのです、 試行錯誤を繰り返した結果からできた規約や、単純に昔からそうだからあえて変える必要もなく延々と続いてる規約など様々です。 

極端な例でいえば、フィールド名を漢字でそのまま表現するという規約ならば、 例えば顧客管理番号は"顧客管理番号"とと言うフィールド名になるわけです、 また名称ではなく数値文字列で"AAA01000"などと命名する規約もあります、

どちらも極端な例ですが、実際現 場で開発してみると以外なメリットがあるのです、もちろんデメリットもありますが・・・^^  ただ暫く使っていると極端な規約であっても慣れてしまい、初期の違和感は消えてしまいます、

やはり慣れが一番大切なんでしょうか・・・

独自のコーディング規約

コーディング規約に縛られるというのは、ソフトウエアハウスなどの開発会社から依頼された仕事の場合です。 

もちろんエンドユーザーからの直接頂いた仕事では、独自のコーディング規約でプログラミングしていいのです。  といっても独自のコーディング規約をちゃんと文書化しているフリーランスのプログラマは今のところあったことがありません^^。 

もちろん私も文書化していません。 長年の培ってきた癖やら思いつきなどが入り混じった規約になっています。  せっかく他社のコーディング規約に触れる機会が多いのですから、いいとこどりでちゃんとした規約書を作るべきでしょう。 

っと自分にいいきかせておきます^^

Sponsored Link


Copyright (C) Breath.All right reserved