エム・アールデザイン|デザインブログコンテンツへスキップエム・アールデザイン|デザインブログデザインの話を細々としています。TAKAHASHIMARIコーディング規約の草案を作ってみたずーっと課題だったコーディング規約の草案を作ってみた。公開されている規約も多いので、今回はGitHubを使ってみる(とりあえず個人アカウント)。草案なので当然完成している訳ではなく、中途半端で終わっている部分があったりするけど、とりあえず公開してみた(日の目を見ないと更新しなさそうだし)。coding-guidelineこの草案を作るにあたり、念頭に置いたのは以下。in0in0の日記)をベースとした考え方を取り入れるようにするこの草案を作る決心をしたのは、OOCSSの前提を知らない若手が「?」なCLASS名を作った事に始まる。参考としたのはOOCSSの思想を持ったCSSなのだが、その思想を知らないため、本人にしかわからないようなCLASS名を作ったらしい。OOCSSの思想から離脱してる上、通常そのような名称を作る事はないので(少なくとも見慣れない文字列なのは確か)、初見だと何のCLASSかわからない。OOCSSの思想を知らないのはかまわないけど、本人にしかわからない奇妙なIDやCLASS名を連発されても困るので、この草案には短縮名の一覧があったりする(そして今後も増える予定)。今回の草案はOOCSSの思想をベースとするものの、汎用クラス(特にmarginやpadding)にやや抵抗があるので、完全なOOCSSという訳ではない(と思う)。命名規則としてはBEMもわかりやすくて、規約として盛り込む事も考えたけど、名前が冗長的なものになりやすいし、アンスコやハイフンを2連にするとか言うのがどうも微妙な感じ。なりやすい事が多かったので、今回は最小限にとどめてみた。Guideでハイフン押しだった&Bootstrapがハイフンつなぎだったのでそちらに倒してみた。Bootstrapの利用が多くなる可能性があるので混乱しないようにした。一応草案に盛り込んだものの、必要なのか迷ったものがある(たとえば、js-のプレフィックスをつけるとか。CSSの項目にある謎。使いやすさ使いづらさというのは、その案件によってさまざまで、規約であまりにも縛りすぎると皆が不幸になるし、かといって縛らないとやはり不幸になる(だからプロパティの順番は特に問わなかったりしてる。それを入れるとコーディングが遅くなるから)。私自身は一度制作を終えてしまうとすっかり忘れてしまうので、後日ID/CLASS名から内容を推測できるよう安易な名称にしている。皆がそういう考えをもってるかというと結構微妙。フリーランスの時に、いくつか他人のコーディングを見た事があって、結構ひどいのも存在した(そして引き継いでひどい目に遭う)。作り上げておしまいならやっつけ名称でもなんでもいいけれど、運用していく事や担当は永遠に担当ではないという事が考えると、規約で縛るのが一番なのかもしれない。