camelCaseとsnake_caseの混在

[ysakasin]

問題点

Rubyの慣習ではメソッド/変数名にはsnake_caseを用いることになっている。しかし、現状のコードでは、camelCaseとsnake_caseが混在し、大変見辛いことになっている。

Rubyの慣習に全て合わせるのが最もメンテナンス性が上がるが、主要なメソッドの大部分がcamelCaseで命名されているため、全て変更するわけにもいけない。そこで、議論して折衷案的な命名の統一ルールを設けたい

個人的な考え

確定

• メソッド名を変更するのは無理なので、camelCaseを維持する
  • 公開されている部分は camelCase にする
• ローカル変数はRubyに合わせて 全て snake_caseにした方が良い

🤔

• privateなメソッドはどうするか？
  • publicメソッドとの整合性のために camelCaseにする
  • privateなのだからローカル変数と同様に snake_caseにする

要調査

• atterは現状どうなっている？
• 実際はcamelCaseとsnake_caseどっちが多い？

[ochaochaocha3]

過渡期の状態として、メソッド名はcamelCase、ローカル変数はsnake_caseとするのに賛成いたします。ただし、一部のメソッドの名前がsnake_caseとなっている場合があり（例：BCDice#dice_command）、それは維持せざるを得ないと思います。

privateなメソッドについても、camelCaseの名前としておくのが良いのではないでしょうか。現状では private と明示されている部分が非常に少なく、publicなものとの区別が難しいと考えました。

[ochaochaocha3]

名前付けのパターンの集計スクリプトを ochaochaocha3/bcdice_naming に作ってみました。集計結果を見ると、やはりcamelCaseが多いですね。

[ysakasin]

集計すごく助かります。

今後の展望として、最終的にメソッド名全てがsnake_caseになるのが良いと思っています。 現在camelCaseなメソッドは少なくともVer2系でそのままにするとしても、新しく作成するメソッドはsnake_caseにするというのもいいかなと思ってきました。

camelCaseからsnake_caseへの移行期ではメソッドエイリアスを活用すればなんとかなる気もするなーとも思ってます。

[kumakaba]

きっかけとなった私のPRについては、「元の書式」を極力保つように書いた結果として混ざってしまったのですが、この件も含め、コーディングスタイルに関しては、コア部分とsrc/diceBot以下の部分を分けて考えたほうがいいと思っています。

コア部分はコーディングスタイルを統一した方がメリットが大きいでしょうが、src/diceBot以下、つまりシステム別ダイスボット部分に必要以上のコーディングスタイルを強いて敷居を上げるのは、システム別ダイスボットだけを寄稿あるいはメンテする人がいることを考えた場合に、ちょっとデメリットの方が大きいかなと、今回スペースやインデントスタイルでrubocopに怒られながら感じました。

[ysakasin]

インデント等の機械的に直せる部分はRubocopが自動でできるので、それをどこかに明記するとして、他のコーディングスタイルはコミッター陣がPull Requestのブランチに関与して適宜直せばいいかなと思ってます。

そもそも、GitHubのPRを出すことがハードル高いので、Pull Requestのガイドラインを書けば、コーディングスタイルに関してはあまり問題ないかなと思います。

[ysakasin]

v3での方針

• コア機能は全てRubyの文化に準拠
• 各ゲームシステムのコードで定義されているメソッド等のcamenCaseは直さずにそのまま
  • 外部から呼び出される部分はコア機能のリファクタリングに合わせて直す