- 今となっては、当然のごとく使用していることを、ただ手紙としてしたためるだけの記事の第十弾。
- 「第十弾という非常にめでたい数字に、決してうぬぼれず、日々励むだけ。」という、限界をとうに超えた背伸びをした、大人な振る舞い。
- 「というか、この時間跳躍ごっこという、幻想しがみつき作業をそんなにやっていたのか」という、自己満足型被害妄想に、もう年齢という概念が見えない。
- よし。今回は入社後、知っておけばよかったことを書こう。
Javaコーディング作法
＜当時＞
- 「規約」・・・クラスやメソッドや変数等の、基礎的な命名のみ、気を付けていた。
- 「作法」・・・学習段階から、意識して記述しておらず、意味さえ通じれば良いと思ってた。
→チーム開発等において、統一性や可読性に欠ける記述をしてしまい、多大なご迷惑をかける。
＜現在＞
- 書籍やネット等で、規約や作法に関して基礎から学習しなおす。
- サンプルプログラムやオープンソースプロジェクト等を見ながら、人のコードを確認する。
基本
大文字と小文字での名前判別はしない。
「OK」
String firstMessage = "Hello";
String secondMessage = "I'm Bob";
String thirdMessage = "Bye";
「NG」
String message = "Hello";
String MESSAGE = "I'm Bob";
String Message = "Bye";
パッケージ
命名はすべて小文字。
「補足」
- 名前は内容がわかりやすい名前。
- 名前は単数形にする。
「OK」
package lang.java.hello;
package lang.java.name;
「NG」
package lang.java.Hello;
package lang.java.names;
名前を省略語にしない
「OK」
package lang.java.infomation;
「NG」
package lang.java.info;
インポートの「*」での省略はダメ。
「補足」
- 記述する順番は下記。
- Java標準クラスAPI
- グローバル（著名なものや市販のライブラリ）なもの
- ローカル（自社内やプロジェクト内のライブラリ）なもの
- 多数の場合は、アルファベット順
クラス
クラス名は役割ある名前にする。
「OK」
class SubmitAction {
}
「NG」
class Test1 {
}
名前の最初の1文字は大文字、複数単語の場合は各単語の先頭を大文字。
「補足」
- 各単語の先頭を大文字にすることを、「capitaliza（キャピタライズ）」という。
- キャピタライズした文字列形式を、「Pascal形式」という。
→別名「UpperCamel形式」とも言う。
「OK」
class TwitterApiClient {
}
「NG」
class twitterapiclient {
}
クラス名はきちんと完全に記述。
「OK」
class TwitterApiClient {
}
「NG」
class TwApiCli {
}
抽象クラスの名前には「Abstract」をつける
「OK」
abstaract class AbstractShowController{
}
class ShowController extends AbstractShowController{
}
「NG」
abstaract class MainShowController{
}
class showController extends MainShowController {
}
例外クラスの末尾に「Exception」をつける
「OK」
class TestObjectException extends Exception{
}
「NG」
class TestObjectError extends Exception {
}
メソッド
目的が明確な名前をつける
「OK」
public String toString(){
}
「NG」
public String test2(){
}
キャメル形式で記述
「補足」
- 最初の単語の先頭を小文字。
- 複数単語の場合は、それ以降の各単語の先頭を大文字。
「OK」
public String showInfo(){
}
「NG」
public String showinfo(){
}
booleanメソッドは真偽目的が分かりやすい名前にする。
「OK」
boolean canRemove()
boolean checkChange()
「NG」
boolean setName()
boolean isRemove()
変数
内容がわかる名前にする。
「OK」
startDate
endDate
maxPrice
minPrice
「NG」
a
num
str
boolean型変数は真偽目的が分かりやすい名前にする。
「OK」
boolean canRemove;
boolean checkChange;
「NG」
boolean isRemove;
boolean name;
コンポーネント型変数は、「使用目的 + コンポーネント名」。
補足
- 下記の例では、「Button」というコンポーネントがある場合。
「OK」
Button cancelButton = new Button():
「NG」
Button cancel = new Button():
定数
全て大文字
「OK」
static final int MODE = 7;
static final string COUNTRY = "JAPAN";
「NG」
static final string country = "JAPAN"
複数単語の場合は、アンダーバーで区切る。
「OK」
static final int EDIT_MODE = 1;
static final string MY_COUNTRY = "JAPAN";
「NG」
static final string myCountry = "JAPAN"
まとめ
- 今回は、Javaコーディング規約の把握ということで、学習も兼ねたグループ開発での、「統一性・可読性」の概念が無い無秩序地帯の頃を思い出しながら、記事を書く。
- 「何事も、ある程度の制限や倫理があることが大事なんだな。」と、まったく統一性・可読性を感じない記事を書きまくっている男は、一丁前に語ってしまう。
- 「今後も結束と思いやりを持った記述に臨もう」という、人工的な決意表明をしたところで、二通目の執筆の準備を始める。
参考
-
https://kazurof.github.io/GoogleJavaStyle-ja/
→こちらの記事を参考にしました。大変お世話になりました。