【MQL】EA・インジケーターの変数名・関数名の命名規則とコーディング規約について解説してみた(読みやすいコードの書き方)

変数名を`a`や`b`、関数名を`func1`のまま提出したEAを、

1ヶ月後に見返して、何をしている処理か分からなくなったことはないでしょうか。

動けばいいから名前は適当でいい、と思いがちですが、名前が分かりにくいコードは、

修正のたびに読み解く時間を奪います。

この記事では、入力変数・ローカル変数・関数名それぞれの命名規則と、

このサイトの記事群で実際に使っている命名規約を、コード比較で解説します。

なぜ命名規則が重要なのか

まず、命名規則を軽視するとどんな問題が起きるかを整理します。

「動けばいい」コードが後で読めなくなる理由

変数名や関数名は、コンパイラにとっては記号の1つにすぎませんが、

人間(将来の自分や、コードを見る他の人)にとっては、処理の意図を読み取るための、

唯一の手がかりです。

名前の付け方で起きる実務上のミス

大文字・小文字の違いだけの似た名前(`Lot`と`lot`等)を併用すると、

どちらを更新したつもりか混乱しやすく、意図しない変数を書き換えてしまうミスにつながります。

この記事で扱う範囲

この記事では、MQL4/MQL5共通で使える命名規則の基本パターンと、

このサイトの記事群で実際に採用している命名規約を扱います。

入力変数(input)の命名規則

ユーザーがチャート上で設定する入力変数の命名パターンを確認します。

このサイトのInp接頭辞規約

input double InpLots           = 0.1;
input int    InpStopLossPips   = 300;
input int    InpMagic          = 20261017;

このサイトの記事群では、入力変数の先頭に必ず`Inp`を付けています。

単位・意味をコメントで補足する

input int InpStopLossPips = 300; //損切り(pips)

`InpStopLossPips`のように、変数名自体に単位(Pips)を含めるか、

末尾コメントで単位を補足すると、後から見たときの誤解を防げます。

ローカル変数・関数名の命名規則

関数の中だけで使う変数と、関数名自体の命名パターンを確認します。

ローカル変数はキャメルケースで役割を表す名前にする

double marginLevel = AccountInfoDouble(ACCOUNT_MARGIN_LEVEL);
bool   hasPosition = HasOpenPosition();

小文字で始まり、2語目以降の先頭を大文字にする「キャメルケース」

で、変数が何を表しているかが分かる名前を付けます。

関数名は動詞から始める

bool IsWalkingUp(int shift, int bars) {...}
bool HasOpenPosition() {...}
void AdjustLotForSafety(double &lot) {...}

`Is`(状態を判定する)・`Has`(所持を判定する)・動詞(処理を実行する)のように、

関数名の先頭を見るだけで「何をする関数か」が推測できる名前にします。

マジックナンバーは変数・定数にして直接書かない

数値を直接書く「マジックナンバー」(今回のテーマの関数判別用の意味とは別の用語で、

コード中に意味不明な数値が埋め込まれることを指す一般的な呼び方です)は、

入力変数や名前付きの定数に置き換えることで、意味が伝わるようになります。

読みにくいコードと読みやすいコードの比較

同じ処理を、命名だけ変えて比較します。

Before: 名前から意味が読み取れないコード

void f1(double a)
  {
   double b = AccountInfoDouble(ACCOUNT_MARGIN_LEVEL);
   if(b > 0 && b < 150)
      a = a / 2.0;
  }

`f1`・`a`・`b`という名前だけでは、何のための関数で、

何を半分にしているのかが全く分かりません。

After: 役割が名前から分かるコード

void AdjustLotForSafety(double &lot)
  {
   double marginLevel = AccountInfoDouble(ACCOUNT_MARGIN_LEVEL);
   if(marginLevel > 0 && marginLevel < InpMarginLevelLimit)
      lot = lot / 2.0;
  }

関数名・変数名を見るだけで、「証拠金維持率が低いときにロットを安全な値に調整する関数」

だと推測できます。

処理内容を1行も変えずに読みやすさだけが変わる

2つのコードは処理内容が全く同じで、名前だけが違います。

命名規則の改善は、動作を変えずに取り組める、最も手軽なコード品質向上の手段です。

命名ミスが起きやすい場面と見つけ方

実際の開発でよく起きる命名関連のミスを確認します。

大文字・小文字だけが違う変数名を併用してしまう

似た名前の変数・関数が増えて役割が埋もれる

`lot`・`lots`・`lotSize`のように似た名前を増やすと、

どれがどの処理で使われているかを追いにくくなります。

役割が重複する変数は、1つに統一することを検討してください。

コンパイラは名前の意味を教えてくれない

名前が分かりにくくても、文法的に正しければコンパイルは通ります。

命名の良し悪しは、コンパイラではなく、コードを読む人間が気づくしかない問題です。

MQL4/MQL5共通で使える命名チェックリスト

執筆・修正のたびに確認したい項目をまとめます。

よくある質問

命名規則について、よく検索される疑問に回答します。

MQL4/MQL5に公式の命名規則はありますか?

言語仕様として強制される命名規則はありません。

ただし、MQLコミュニティでは、クラス名をStudlyCaps(先頭大文字の単語を連結)、

関数名をキャメルケースにする慣習が広く使われています。

今までのコードを全部直す必要がありますか?

いいえ、動いているコードを無理に書き換える必要はありません。

これから新しく書く関数・変数から、少しずつ意識して名付けていくだけで十分効果があります。

日本語のコメントと英語の変数名、どちらで書くべきですか?

このサイトの記事群では、変数名・関数名は英語、

説明コメントは日本語という組み合わせを採用しています。

変数名を無理に日本語のローマ字表記にすると、むしろ読みにくくなる場合があります。

【MQL】EA・インジケーターの変数名・関数名の命名規則とコーディング規約について解説してみた(読みやすいコードの書き方)：まとめ

この記事では、入力変数・ローカル変数・関数名の命名規則と、

このサイトの記事群で使っているInp接頭辞の規約を解説しました。

命名規則の改善は、処理内容を変えずに取り組める、最も手軽なコード品質向上の手段です。

`f1`や`a`のような名前を見つけたら、役割が分かる名前への置き換えを検討してください。

関連記事

• 値渡しと参照渡し(&の意味)についての記事
• 構造体(struct)でEAの設定をひとまとめにする方法の記事
• GetLastErrorでエラーコードを取得する方法の記事