Posted at

【一年生の頃の私へつづる言葉⑩】最低限のJavaコーディング作法を把握してね。(一通目 : 命名編)


  • 今となっては、当然のごとく使用していることを、ただ手紙としてしたためるだけの記事の第十弾。

  • 「第十弾という非常にめでたい数字に、決してうぬぼれず、日々励むだけ。」という、限界をとうに超えた背伸びをした、大人な振る舞い。

  • 「というか、この時間跳躍ごっこという、幻想しがみつき作業をそんなにやっていたのか」という、自己満足型被害妄想に、もう年齢という概念が見えない。

  • よし。今回は入社後、知っておけばよかったことを書こう。


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コーディング規約の把握ということで、学習も兼ねたグループ開発での、「統一性・可読性」の概念が無い無秩序地帯の頃を思い出しながら、記事を書く。

  • 「何事も、ある程度の制限や倫理があることが大事なんだな。」と、まったく統一性・可読性を感じない記事を書きまくっている男は、一丁前に語ってしまう。

  • 「今後も結束と思いやりを持った記述に臨もう」という、人工的な決意表明をしたところで、二通目の執筆の準備を始める。


参考