回答編集履歴

テキスト修正

2020/09/21 17:53

投稿

jun68ykt

スコア9058

test CHANGED Viewed

@@ -518,7 +518,7 @@
-BEMの以外のCSS設計論として [ECSS](https://ecss.io/)  というCSS設計の体系もありますが、これもハイフンやアンダーバーをその設計論による文法の一部として使います。クラス名を`users-list` や `users_list` とした場合、これらに含まれるハイフンやアンダーバーが、BEM や ECSS の文法の一部としてのハイフンやアンダーバーとしてよいのかは、CSSクラスの設計上で、`users` という識別子が、どのような対象、あるいはどこまでの範囲を示すものとするのか、によります。これらを検討するには、BEMやECSSがどのようなものかを知る必要があります。
+BEM以外のCSS設計論として [ECSS](https://ecss.io/)  というCSS設計の体系もありますが、これもハイフンやアンダーバーをその設計論による文法の一部として使います。クラス名を`users-list` や `users_list` とした場合、これらに含まれるハイフンやアンダーバーが、BEM や ECSS の文法の一部としてのハイフンやアンダーバーとしてよいのかは、CSSクラスの設計上で、`users` という識別子が、どのような対象、あるいはどこまでの範囲を示すものとするのか、によります。これらを検討するには、BEMやECSSがどのようなものかを知る必要があります。

テキスト修正

2020/09/21 17:53

投稿

jun68ykt

スコア9058

test CHANGED Viewed

@@ -120,7 +120,7 @@
-### 補足
+### 補足1
@@ -151,3 +151,419 @@
 といったように、変数名を単数形にすべきか複数形にすべきかについて、今のうちからこだわる習慣をつけておくと、後々、何かとよろしいかと思います。
+### 補足2
+コメントから頂きました、
+> CSSクラス名のところですが
+> 「.users-list」と「$usersLists」でなく、
+> 「.users_list」と「$users_lists」というのは…ナシでしょうか。
+とのご質問に、以下にて回答します。
+#### 1. JavaScriptの変数名について
+まず、JavaScript のほうの変数名を `$usersLists` ではなく `$users_lists` とすることについて
+> ナシでしょうか。
+に回答します。質問の捉え方によって回答も若干変わってきますが、まず、ひとつの捉え方として、今回の質問に挙げられているコードの範囲に限らず、
+- 今から、スネークケース(users_lists)とキャメルケース(usersLists)とで、どちらかに慣れていくとしたら、どちらがいいか？
+というご質問と捉えると、迷わずキャメルケース(usersLists)のほうをお勧めします。以下に、JavaScript ではキャメルケースのほうが慣例になっている事例を２つ挙げておきます。
+##### 1.1 Google の JavaScriptスタイルガイド
+Google の JavaScriptスタイルガイドというドキュメントがあります。
+- [Google JavaScript Style Guide](https://google.github.io/styleguide/jsguide.html)
+このドキュメントの目的は、1. Introduction の冒頭に
+> This document serves as the complete definition of Google’s coding standards for source code in the JavaScript programming language.
+と書かれています。つまり、グーグルにおけるJavaScriptでプログラムを書くときのお作法、といった内容です。このドキュメントの
+[6 Naming](https://google.github.io/styleguide/jsguide.html#naming)
+の章に、変数やメソッド名などの識別子についての名前の付け方のルールが記載されており、6.2.1 Package names
+から　6.2.10 Module-local names　までの間で、コードを書いているときに多く使う識別子である、
+- 6.2.3 Method names
+- 6.2.7 Parameter names
+- 6.2.8 Local variable names
+は、`lowerCamelCase` (先頭小文字のキャメル）を使うように記載されており、
+- 6.2.2 Class names
+は、`UpperCamelCase`　(先頭大文字のキャメル）を使うことが記載されています。
+##### 1.2 ESLint のルール
+JavaScript のコードの、文法的な誤りではなく、書き方の問題を指摘してくれる ESLint というツールがあります。
+- [ESLint](https://eslint.org/)
+コード上のどのような問題をESLint に指摘させるかを、様々なルール
+- [https://eslint.org/docs/rules/](https://eslint.org/docs/rules/)
+によって設定できます。上記のルール一覧の中に
+**camelcase**
+というルールがありますが、これは
+**enforce camelcase naming convention**
+という説明のとおり、このルールが設定されたESLint が、ソースコードを解析しているときに、スネークケースの識別子(例：`first_name`)をみつけると、
+**error  Identifier 'first_name' is not in camel case**
+といったエラーメッセージが出力されます。このように、スネークケースの識別子をキャメルケースにするようにと促すルールは存在しますが、逆に、キャメルケースの識別子をなるべくスネークケースにするよう求めるようなルールは見当たりません。
+まとめますと、私見としては、
+(1)GoogleのJavaScriptスタイルガイドでは、変数名などの識別子をキャメルケースで書くルールになっている。
+(2)ESLintで、キャメルケースになっていないことをエラーにするルール（camelcase)はあるが、スネークケースになっていないことをエラーにするルールは存在しない。（つまり、なるべくスネークケースでコードを書かせるようなESLintの設定を、誰も必要としていない）
+という二点を根拠として「今からどちらかに慣れていくとしたら、どちらがいいか？」というご質問であれば、迷わずキャメルケースをお勧めします。ですので、今回も、ちょっと違和感あるかもしれませんが、`$users_lists`ではなく`$usersLists` とするのをお勧めします。
+ただし、冒頭で
+> ナシでしょうか。
+というご質問の捉え方によって回答も若干変わってきます、と書きましたとおり、`$usersLists` と書くのが絶対ではありません。
+たとえば、業務や学校の課題などで、複数人のチームに所属して、その人たちと共同でホームページ等を作るというような
+状況になったとして、自分がそのプロジェクトに参加し始めた時点で、すでに大量のJavaScriptのコードが書かれていて、そのコードでは、変数名やプロパティ名がスネークケースで書かれているほうが多い、という状況においての
+`$users_lists` と書くのは
+> ナシでしょうか。
+というご質問であれば、
+（そういうことであれば、ひとまず） アリですね。
+という回答になります。
+GoogleやESLintのルールといっても絶対ではありませんので、これらで決まっているルールを知った上で、それらをごり押しするのではなく、周囲の人たちとうまくやり業務が円滑に進むように、臨機応変にご対応されるとよろしいかと思います。
+coletteさんとしては、スネークケースのほうが
+> スッキリさを感じます。
+とのことですが、先述したようにJavaScript ではキャメルケースが（広く使われ、推奨されるという意味で）標準です。ただし、これは、キャメルケースのほうがスネークケースよりも誰からみてもあらゆる点で優れているということではありません。実際、Python というプログラミング言語では関数や変数は、いわゆるスネークケース、すなわち、すべて小文字で、適宜、単語をアンダースコアで区切ることが PEP8 という規約
+- [pep-0008/#function-and-variable-names](https://www.python.org/dev/peps/pep-0008/#function-and-variable-names)
+に
+> Function and Variable Names
+> Function names should be lowercase, with words separated by underscores as necessary to improve readability.
+と定められています。私はときどきPythonでコードを書くこともあるので、スネークケースのほうが
+> スッキリさを感じます。
+というのも、実感として分かります。ですが、今後JavaScriptに熟達されたいのであれば、キャメルケースのほうに慣れて、JavaScriptのコードの中に `users_lists` が出てきたときに、なんとなく違和感を感じるぐらいを目指されることを推奨いたします。
+キャメルケースに慣れるための方法のひとつとしては、JavaScriptを書くときの開発ツールとして、VSCodeやWebStormを使うと、上記の ESLint が効くようにしておくことができるので、先のルール camelcase を設定すれば、エディタで
+`first_name`
+と書いたその場で、即座に `first_name` の下に赤い下線が引かれて、マウスをのせるとESLintのエラーメッセージが表示されるといったことができます。そういったツールの力を借りて、自分の書くコードを楽に矯正していくのも良い方法かと思います。
+#### 2. CSSのクラス名について
+次に CSS のクラス名のほうを、ハイフン区切りの`.users-list`ではなく、アンダーバー区切りの `.users_list` と書くのは
+> ナシでしょうか。
+に回答しますが、正直なところ、私自身は、これらのどちらがいいのか、というご質問に対して、あまり有用な知見を持ち合わせておりませんので、ちょっとstackoverflow を調べてみました。すると、
+- [What is the standard naming convention for html/css ids and classes?](https://stackoverflow.com/questions/6028211)
+という質問がありました。この質問は HTMLを書くときの `id` 属性の書き方として、以下の3つ
+```
+1. id="someIdentifier" - looks pretty consistent with javascript code.
+2. id="some-identifier" - looks more like html5-like attributes and other things in html.
+3. id="some_identifier" - looks pretty consistent with ruby code and is still a valid identifier inside of Javascript
+```
+のどれがいいのか？を問うもので、これの[ベストアンサー](https://stackoverflow.com/a/6028289) の冒頭を簡単に要約すると、
+```
+３つのうちのどれがいい、というのはない。どれでも、自分の見やすい、または書きやすい方法を選べばよい。
+ただし、開発チームですでに決まっている慣例があるのであれば、それに従おう。
+```
+といった感じです。私もこれに同意です。ただし、この回答者の最近の更新に、
+> Update 2020
+>
+A boring update this year. I'm still using BEM.
+というコメントがあり、いわく「BEMを使っている」とあります。
+このコメントにあるBEMとはCSSの設計手法のひとつで、以下
+- [http://getbem.com/naming/](http://getbem.com/naming/)
+のような感じで、クラス名を命名するときに、 ハイフンとアンダーバーを異なる意味で使用したり、2個連続したりします。ですので、BEMの文法として使うハイフンやアンダーバーと被らないようにするのであれば、`users-list` や `users_list` ではなく、上記３パターンのうちの 1.を使った `usersList` がよい、と言えるかもしれません。
+BEMの以外のCSS設計論として [ECSS](https://ecss.io/)  というCSS設計の体系もありますが、これもハイフンやアンダーバーをその設計論による文法の一部として使います。クラス名を`users-list` や `users_list` とした場合、これらに含まれるハイフンやアンダーバーが、BEM や ECSS の文法の一部としてのハイフンやアンダーバーとしてよいのかは、CSSクラスの設計上で、`users` という識別子が、どのような対象、あるいはどこまでの範囲を示すものとするのか、によります。これらを検討するには、BEMやECSSがどのようなものかを知る必要があります。
+ただし、上記はBEMやECSSのようなCSS設計手法を取り入れることが見えているのであれば検討すべきことですが、そのような予定はない、または、あるとしてもまだ先の話であれば、先の [stackoverflow の回答](https://stackoverflow.com/a/6028289) と同様に
+- `class="usersList"`
+- `class="users-list"`
+- `class="users_list"`
+のどれでも、自分が見やすいもの、分かりやすいものを選べばよろしいかと思います。
+#### 3. まとめ
+結論として、私見としては
+① JavaScript の変数名： キャメルケース(今回であれば、`$usersLists`) をお勧めします。
+② CSSクラス名： `.users-list` と `.users_list` との比較については、どちらでもよい。BEM や ECSS ではハイフンやアンダーバーがクラス名設計における文法の一部になっていることを頭の片隅に置きつつ、`.usersList` でもよい。
+という回答になります。ただし、私としては、業務で主に担当してきた範囲の偏りから、上記の①については、それなりに自信を持って言えますが、②については、WEBデザイナーやWEBコーダーの熟練の方々からはまた違った視点からの有益な助言があるかもしれませんので、上記だけだとちょっとモヤモヤする感じでしたら、CSSクラス名の命名のみに論点を絞った質問を、再度投稿されるとよろしいかもしれません。
+コメントから頂きましたご質問への回答は以上です。

テキスト修正

2020/09/21 15:46

投稿

jun68ykt

スコア9058

test CHANGED Viewed

@@ -150,4 +150,4 @@
-に今のうちからこだわる習慣をつけておくと、後々、何かとよろしいかと思います。
+といったように、変数名を単数形にすべきか複数形にすべきかについて、今のうちからこだわる習慣をつけておくと、後々、何かとよろしいかと思います。

テキスト修正

2020/09/20 09:44

投稿

jun68ykt

スコア9058

test CHANGED Viewed

@@ -18,7 +18,7 @@
-```
+```javascript
 // elementでいいですか？objectでしょうか？それ以外でしょうか？
@@ -52,7 +52,7 @@
 ```
-という変数名は、`$` で始まっているので、コードを読む人は、先頭の`$`を見ただけで`$element` にはjQuery object が入ってくるのだな、という読み方をしますが、`$` の後に続く、element という名前はDOMの要素であるelementを思わせるので、全体として
+という変数名は、`$` で始まっているので、JQueryをそれなりに経験した人が読むと、先頭の`$`を見ただけで`$element` にはjQuery object が入ってくるのだな、という読み方をしますが、`$` の後に続く、element という名前はDOMの要素であるelementを思わせるので、全体として
 ```javascript
@@ -60,7 +60,7 @@
 ```
-という名前の付け方は、あまりよろしくない、ということになります。では、どのような命名がよいかというと、`$('.users')` によって、`users`クラスの要素を含むjQuery objectが返ってきますが、その該当要素は複数である場合があるので、一例としては
+という名前の付け方は、あまりよろしくない、ということになります。では、どのような命名がよいかというと、`$('.users')` によって、`users`クラスの要素を含むjQuery objectが返ってきますが、その該当要素は複数である場合があるので、すぐに思いつくところだと、
@@ -82,9 +82,11 @@
 ```
+- **サンプルコード：** [codepen.io/jun68ykt/pen/WNwaBeX](https://codepen.io/jun68ykt/pen/WNwaBeX?editors=1011)
-とするのがよいか思います。あるいは、他により良い名前があるかもしれません。さらには、以下のように、CSSクラス名と、変数名を合わせることも考えられます。
+とするのがよいか思います。あるいは、他により良い名前があるかもしれません。さらには、`$usersLists`とするのであれば、以下のように、CSSクラス名も変数名に寄せることが考えられます。
@@ -110,7 +112,7 @@
-どのようにするのがよいかは、様々な事例や先達のご意見を参考に、ケースバイケースで検討するとよいかと思います。
+どのようにするのがよいかは、様々な事例や先達のご意見、開発チームでの慣例を参考に、ケースバイケースで検討するとよいかと思います。