🐈

コーディング規約ってどこまで決めるか迷う

2023/10/16に公開

はじめに

開発をスタートさせようとすると色々と考えることが多いと思いますが
その中にコーディング規約をどうするか問題も出てくるかなとふと思ったので
今までやってきたことなどをまとめてみました。

本題

一人で開発をしていくならそこまで気にしなくてもいい(こともない)ですが
複数人で開発をしたりするとコーディング規約を作って開発を進めていくことになると思います。

今までいくつかのプロジェクトを経験してきて
いた業界的なものもあると思いますが
命名規則なら

  • ローワーキャメルケース(camelCase)
  • アッパーキャメルケース(PascalCase)
  • スネークケース

あたりはよく使ってた印象で、あとは好きにどーぞ!というふわっとした感じが多かったです。
自由にやることでこんな書き方もあるのかーと勉強になる部分も多々ありました。

ちなみに個々に任せた結果
if文だけでもこんな書き方を見てきました。(言語によって無理な書き方もあります)

if() {
} else if() {
} else {
}
if() {
}
else if() {
}
else {
}
if()
{
}
else if()
{
}
else
{
}
if()
{
}
else
if()
{
}
else
{
}

まぁ自由に書くとソース内に色んな書き方が混在してしまうのである程度は固めたほうがいいのかなと思いますが
どこまで固めるのかというのが難しいところ。

結局何が言いたいのか

複数人で開発を行うなら可読性を上げることは重要です。
(そうじゃなくても今書いているソースコードを誰かが参考に見る可能性もあります。)

今はkotlinを使っているので調べたところ

とかを発見。

言語的に規約が定まっているのと、IDE優秀だし任せちゃえ精神でやってますが
昔から一つだけ心がけていることは
誰かに見せられるソースコードにすること
です。

綺麗にかくとか、なんかすごいプログラムをする(語彙力)とかではなく

  • 処理ごとに改行入れてブロック分けする
  • 出来るだけコメントをつける(特に関数)
  • 無駄な改行は入れない
  • 関数名や変数名をつける時に迷ったら一般的な言葉を調べる

これくらいを心がけて、あとはIDEにお任せするだけでも結構いい感じになったりします。
(命名規則とかでwarningも出してくれるしほんとありがたい)

まぁ実際誰かに見せられるソースコード書くのってすごく難しいんです。
そんな感じで今日も自由気ままにプログラム。

コラボスタイル Developers

Discussion