コーディング規約、皆さんはしっかりと守っていますか？
コーディング規約は、コードの読みやすさやメンテナンス性を向上させるための非常に重要なツールです。一貫性のあるコードは、新しいメンバーがチームに参加したときや、長期間放置されたコードを再び触るときなど、多くの場面でその価値を発揮します。
その中でも「命名規則」って意外と重要です。なぜなら、このルールによってクラスがプライベートだと分かったり、あるいは特殊なグループに属する変数だったりすることが（ルールをよく理解していれば）一目で伝わるからです。
しかし、せっかくのルールも、ときにあいまいな部分が残っていたりします。
その中でも特に「曖昧さ」が生じやすい部分、アクロニム、つまり頭字語の扱いについて当記事で深掘りしてみたいと思います。
アクロニムの悩み
私たちがコードを書く際、特にキャメルケースやパスカルケースを使う言語やフレームワークで、HTMLやIPといったアクロニムをどのように書くか迷った経験はありませんか？
例えば、getHTMLかgetHtml、IPaddressかIpAddress… どちらが正解なのか、迷ってしまいますよね。
キャメルケース、パスカルケース、あるいはスネークケースなどのどのパターンにするかは言語によってバラバラですが、アクロニムの扱いもやはり違いが大きいようです。
さまざまなガイドラインとPHPの例
- .NET Framework: こちらでは、2文字のアクロニムはすべて大文字、3文字以上は最初の文字だけ大文字とするルールが推奨されています。
- Java: Javaでは、アクロニムも通常の単語として扱い、キャメルケースやパスカルケースのルールをそのまま適用。
- Google’s JavaScript Style Guide: すべて小文字またはキャメルケースを適用するというスタンス。
- Apple’s Swift and Objective-C: アクロニム自体を避けることが推奨されています。
そして、PHP。PHPの規約と言えばPSRですが、そこではパスカルケースを使うのみ書かれておりアクロニムの扱いは明文化されていません。
実際、PHPの標準クラスでは、XMLがすべて大文字で表記されています。例としては、SimpleXML などが挙げられます。しかし ZendFramework では Zend_Config_Xml などのように Java と同じルールですね。
しっかりと合意を取ろう
いずれのルールも良い悪いはなく、ただルールを決めて守るだけの話なのですが、こういう細かい部分は、つい忘れがちになるので規約としてしっかりと明文化し、プロジェクトチームで合意を取りましょう。
コメント