コーディング規約の草案を作ってみた

coding-guidelineずーっと課題だったコーディング規約の草案を作ってみた。
公開されている規約も多いので、今回はGitHubを使ってみる(とりあえず個人アカウント)。
草案なので当然完成している訳ではなく、中途半端で終わっている部分があったりするけど、とりあえず公開してみた(日の目を見ないと更新しなさそうだし)。
coding-guideline


この草案を作るにあたり、念頭に置いたのは以下。

  1. 意味不明な短縮ID及びCLASS名を作らせない
  2. ID/CLASS名の単語はハイフンつなぎで統一
  3. 画像の名付けの統一
  4. OOCSS(参考:OOCSS(Object-Oriented CSS)の考え方 – in0in0の日記)をベースとした考え方を取り入れるようにする

この草案を作る決心をしたのは、OOCSSの前提を知らない若手が「?」なCLASS名を作った事に始まる。
参考としたのはOOCSSの思想を持ったCSSなのだが、その思想を知らないため、本人にしかわからないようなCLASS名を作ったらしい。
当然、OOCSSの思想から離脱してる上、通常そのような名称を作る事はないので(少なくとも見慣れない文字列なのは確か)、初見だと何のCLASSかわからない。

OOCSSの思想を知らないのはかまわないけど、本人にしかわからない奇妙なIDやCLASS名を連発されても困るので、この草案には短縮名の一覧があったりする(そして今後も増える予定)。

今回の草案はOOCSSの思想をベースとするものの、汎用クラス(特にmarginやpadding)にやや抵抗があるので、完全なOOCSSという訳ではない(と思う)。
命名規則としてはBEMもわかりやすくて、規約として盛り込む事も考えたけど、名前が冗長的なものになりやすいし、アンスコやハイフンを2連にするとか言うのがどうも微妙な感じ。なにより思想をわかってないと、これの利用も微妙になるので今回は取りやめた(参考:CSSの命名規則にBEMを取り入れてみる )。
(ちなみに、やっぱりアンスコやハイフンを2連にする事に違和感感じる人がいるようで、CSS – BEM記法を自分なりに改良したいという思惑 – Qiitaという話題があったりします)

一部を除いて汎用クラスを非推奨にしてるのも理由があり、marginやpaddingの汎用クラスは便利な反面、どこでも使えるが故にレイアウトの崩れを起こしたりして、経験上、後々面倒になりやすい事が多かったので、今回は最小限にとどめてみた。

ID/CLASS名の単語つなぎはアンスコ、ハイフン、キャメルケースと悩んだのだが、Google HTML/CSS Style Guideでハイフン押しだった&Bootstrapがハイフンつなぎだったのでそちらに倒してみた。
特にBootstrapの利用が多くなる可能性があるので混乱しないようにした。

一応草案に盛り込んだものの、必要なのか迷ったものがある(たとえば、js-のプレフィックスをつけるとか。そしてなぜかCSSの項目にある謎。)。

使いやすさ使いづらさというのは、その案件によってさまざまで、規約であまりにも縛りすぎると皆が不幸になるし、かといって縛らないとやはり不幸になる(だからプロパティの順番は特に問わなかったりしてる。それを入れるとコーディングが遅くなるから)。

私自身は一度制作を終えてしまうとすっかり忘れてしまうので、後日ID/CLASS名から内容を推測できるよう安易な名称にしている。が、皆がそういう考えをもってるかというと結構微妙。
フリーランスの時に、いくつか他人のコーディングを見た事があって、結構ひどいのも存在した(そして引き継いでひどい目に遭う)。

作り上げておしまいならやっつけ名称でもなんでもいいけれど、運用していく事や担当は永遠に担当ではないという事が考えると、規約で縛るのが一番なのかもしれない。

とりあえずあげた。草案は。

ところで、久しぶりに黒い画面を使ったら、vimをすっかり忘れていて、コミットコメント入力するのにえらい時間がかかってしまったorz
svnはeclipse使ってたりするので、ターミナルはhostの書き換えとか、ごく小さな事しか使っていない。
やっぱりGUI使うのがいいなあ。GitHubにもGUIあるんだけど、OSの関係で今のところ使えてない(会社のMacは使える)。
GUI使うために自宅のOSバージョンUPするのもアレだし、それによってその他もUPしなくちゃならなくなるので、一旦は保留で。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です