ヘッポコプラグラマを自認する私ですが、そんな私でもずーと思っていることがあります。命名規約やコーディング規約についてです。品質、生産性、保守性などの理由により大手、中小企業をはじめコーディング規約や命名規約を社全体やプロジェクトごとなどに決めている企業は沢山あります。
スポンサーリンク
「コーディング規約」だとか「命名規約」とか
命名規約やコーディング規約を作ることが悪いと言っているわけではありません。私も賛成です。あったほうが良いでしょう。100% 完全に遵守されることは皆無だと思われますが、あったほうが良いと思います。みなさんの会社(プロジェクト)ではどのような命名規約やコーディング規約があるでしょうか。また、下請けだと元請から強要されることも日常茶飯事だと思います。例えば。
- 関数(メソッド)名は CamelCase
- 定数 ( define ) は大文字でアンダーバー区切り
- C#のコーディング規約を準拠
- Integer 型の変数名はプレフィックスに i ( ex. iCount)
- クラスのメンバ変数はpublicにせず、setter / getter を用意する
- goto 文は使用しない
- クラス、関数の看板は○○○のようにする
- パラメータ名は○○で始める
- グローバル変数は使用しない
- 修正前のコードはコメントで残しておく
等々、色々あるとは思います。1つ1つに対しての良し悪しは考えさせられる部分はあるとは思いますが、ここでは言及しません。
面白いコーディング規約だとか命名規約があったら教えて欲しいです。
一番大切な規約は何か?
一番大切なコーディング規約は、関数名やクラス名の規約だと個人的には思っています。コーディング規約などには、
- 関数名は適切でわかりやく
- クラス名は名詞、メソッド名は動詞
などの記載はあるかもわかりませんが、守られていないことがほとんどです。user クラスに check メソッドが作成され続けています。ほとんどの場合は完全に意味不明です。user クラスの valid1 メソッドと valid2 メソッドとはそれぞれ何をするのですか?看板に書いてあるから OK ですか?その看板もコピペしてどちらも同じなんですけれど・・・
と言ったような経験がある人は大勢いると思います。このような命名をしてコーディングした人はきっと、「自分で何をしているか理解していない人」であると判断されることになるでしょう。
意味不明な命名されると困るのは当然ですが、その前にレビューで指摘できる側の人がそもそも、
- レビューする能力がない
- そもそもレビューしない
などのケースも多々見受けられます。お客さんにはレビュー工数や品質の向上を謳ってお金を請求しているかもしれませんが、このような酷い現状があることは現実です。残念です。
兎にも角にも
立派なコーディング規約や命名規約の前に、
- 英語わからないなら、ローマ字で日本語で
- やってることと関数名、クラス名、メソッド名は一緒に
- 英語よりも国語の勉強が先
- 自分が何の処理をしているか理解すること
と言うことができることが先であります。私も偉そうなことを言えないヘッポコですが、これは声を大にして言いたいのです。残念ながら(特に業務システム中心の場合) IT 業界は大手企業であるから優秀ということは決してありません。担当者次第です。
ここら辺の話題は是非、他業種の方の意見もお伺いしたいです。同じ問題を抱えている業種は沢山あると勝手に予想しています。
「初心者でもわかるようにプログラミングする」というような抽象的な規則があったりしますが、そんな人(物)にお金を払う人がいるのでしょうか。
>英語わからないなら、ローマ字で日本語で
→
同音異義語の数は日本語が世界一です。
音をそのままアルファベットにしてしまうローマ字はわかりにくいです。
また、読み間違いや誤字で、別の意味にとれるように変わってしまったら、
さらに混乱を招きます。
あとダサい。
最近だと、とあるシステムで”kaishi”とあり、
“開始”だと思ったら、”壊死”の読み間違いだったことがあります。
個人的にはひたすら英語を勉強してほしいです。
そうですね。
常に勉強を続けるようにありたいですね。
あと、壊死(えし)を ”かいし” と読み間違えたってのもすごいですね。
英語よりも漢字の勉強が必要な気がしますが。。。
電子カルテでしょうか。わたしも何度かやったことがあります。