元底辺エンジニアが語る、エンジニアとしての生き様、そしてこれからの生き方

生き様065. 勝手にコードレビュー ~イノウーの憂鬱 (25) の感想~

»

イノウーの憂鬱、面白いですよね!

毎週、一人のファンとしてリーベルGさんのPress Enter■を楽しく読んでいます。
今回のコラムは、その先週の回の内容についてです。
そこで行われたコードレビューに対して、いくつか思う所がありました。
なので、それをコラムにしてしまおうと思います。

既に新しい回が公開されており、周回遅れ感はありますが…
先週頑張って書いていたのですが、間に合わず公開を見送ったのです。
そこから1周間掛けて、頑張って書き上げました!

大分長くなりますが、お付き合いいただけると幸いです。


全体的な感想

登場人物の一人である、マギ情報システム開発の三ツ橋さんには、とても同情してしまいます。
僕も、マギ情報システム開発の提出したコードは、おおよそ酷いものだと感じます。

ですが、手放しで攻める気になれません。
その背景として「前例踏襲」「中途半端な流行の真似」という行動が見えるからです。
これらの行動は、現代日本のビジネスシーンにおいて、多々見られる悪習です。
ですから、三津橋さんも、その悪習の犠牲者だと、同情的に見てしまうのです。

それでは、ポイントとなりそうな箇所をピックアップしてみましょう。
タイトルにもなっている「クラス」「例外」「ロガー」「型定義」にも重なりますね。

  1. 変数名は分かりやすい名前を付ける(中途半端な流行吸収)
  2. 名称は統一しよう(前例踏襲?)
  3. システムに登場する全ての項目をクラス化(中途半端な流行吸収)
  4. メソッドの結果を必ずbooleanで返す(前例踏襲)
  5. 独自のLoggerを実装(前例踏襲)
  6. DBの文字コードフィールドの設定(前例踏襲)

これら一つずつについて、順番に見ていきたいと思います。
ただこき下ろすだけではなく「こうすればもっと良くなる」も含めてお話しましょう。

あくまでも【2020年11月現在の白栁のやり方】ですけれども。

※※お断り※※
 今回のコラムで取り扱う原典は、フィクションです。
 その為、フィクションを元にした仮定の話になります。
 原典が2020年11月時点での技術的な前提に則していない可能性もあります。
 そもそも、フィクションに「現実として」ツッコミを入れています。
 そういう、とても野暮な話であることをご承知下さい。


ケース1:変数名は分かりやすい名前を付ける

最近のトレンドでは「命名には、わかり易さ重視でかな漢字を使う」があります。
僕はこれ、あまり好きではありませんがね。
でも、テストコードのメソッド名等には、積極的に使っています。わかりやすいので。

そもそも、何故かな文字、所謂2バイト文字や、半角カナを変数名やクラス名等の命名に使うのを嫌っていたか、ご存知でしょうか?

それは、文字コードの違いにより、文字化けしやすいからです。
文字化けにより、入力不可能な文字に変換されてしまったらどうでしょう?
正しく処理を指定することができなくなります。
昔のコーディング規約では
「文字化けしやすい特定の文字はコメントでも避ける」
という指定があったそうです。
ローマ数字等の機種依存文字も同じですね。

コンパイラによっては、
「文字解釈により1バイトずつ分解して読み込む為、2バイト文字だと壊れる」
という話があったとかいう噂も、うっすら聞き覚えがあります。
これは、都市伝説、与太話程度に聴いておいて下さい。

もう一つ、変換の為に入力を切り替える手間を惜しんだから、というものもあります。
プログラミング言語の基本構文は、多くが半角英字ですからね。
そこからかな入力に切り替えるのが手間だ、と考える人も居るでしょう。
といいつつ、コメントは入力を切り替えて日本語で書いていたりもします。
そこまで惜しむなら、コメントも英語で…と言った人が過去にいました。

さて、文字コードの話に戻りましょう。
最近では、マルチバイト文字のUTF-8が主流です。
これにより「半角だから1バイト、全角だから2バイト」という括りは無くなります。
つまり「文字化けを警戒して全角文字を使わない」理由がなくなります。

であるならば、文字による処理の違いはないのですから、
「文字種に関係なく読みやすいものにしよう」というのは至極当然に思えます。

もしかしたら、数年後には「ぴえん」の絵文字が変数名に入っている時代がくるかもしれませんね!
※システムの都合により、絵文字が使えない為、文字での表現になります

ケース1処方:そこまでわかり易さに拘るなら、かな漢字で命名すればいい

ローマ字を使ったこのケースでは、一つだけ誉められる部分があります。
英語で命名した場合、内輪でしか通用しない、独特の省略文字が使われたでしょう。
【OODE→CD】や【Master → Mst】程度なら可愛いですね。
【Format → Fmt】【Count → Cnt】とかまで行くと、どうでしょう?

ケース2:名称は統一しよう

作中では、消費税の項目に対して3つのパターンが出てきます。 「syouhizei」「shouhizei」「syohizei」ですね。
三津橋さんは「それぞれ別のメソッドですから問題はない」と言い訳をされています。
当然ですが、そんな訳ありません

例えばこの消費税に対して、根本的な修正hが入ったとしましょう。
2年前に軽減税率が導入されていますから、現実的にありえない話ではありません。
命名がバラバラであれば、修正箇所の見落とし、漏れが発生する可能性が高くなります。

もしかしたら、ドキュメントでしっかりと管理されているかもしれません。
なので、消費税に関する修正箇所は、どこのクラスの、何処のメソッドにある、と突き止められるかもしれませんね。
ですがこの方法では、ドキュメントと修正したコードを突合するまで、修正の漏れの確認ができません。
もちろん、この方法は必要です。
名前の統一により、突合前にコードの上だけで確認することができます。

確認出来る方法は、手軽かつ数が多い方が好ましい、とは言うまでもありません。

僕は、なるべくデータベースの項目名に準拠した命名にする様にしています。
これなら、システム内で統一が図りやすいからです。

ケース2処方:システム内での名称・命名は統一しよう

ここからは余談です。
「実装されたクラスが違う」という理由で名称が変わる、について考えてみます。
これは、実装担当が「個人の趣味で命名している」ということです。
このケースで多いのが、「実装コードの重複」です。
担当者ごとに、同じ処理を別々に書いている事が多いのです。
メンテナンスコスト増大だけでなく、バグの温床にもなりやすい悪習ですね。

ケース3:システムに登場する全ての項目をクラス化

「システムに存在する項目を全てクラスとして用意する」
こう言われると、「とんでもない!」という感想を持つ人は、少なくないでしょう。
イノウー君もそうでした。
数年前の僕も、同じ感想を持っていました。

ですが、今はこのやり方が「多くの場合で適切だ」と考えています。
大規模なシステム開発であれば、迷わずに三津橋さんと同じ方法を取るでしょう。

「値オブジェクト」もしくは「ValueObject」と呼ばれるものがあります。
これは、最近のオブジェクト指向の流行です。
僕は「ValueObject」の呼び方が好きなので、以後はこれに統一します。

【ドメイン駆動開発(DDD)】とセットで語られる事が多いValueObjectですが、
僕は分けて捉えています。

ValueObject は クラスによる型表現を突き詰めたもの

と捉えているからです。 ValueObjectの利点は幾つかあります。
その最も大きな点は「型により値の種類が決められる」ことです。 例えば、単価に注文数量を掛けて金額を算出するメソッドがあります。

int price = Price.Calc ( int unitPrice, int orderQuantity );

これをValueObjectを使用して記述すると

Price price = Price.Calc ( UnitPrice unitPrice, OrcerQuantity orderQuantity );

となります。
どちらの方が、引数の設定ミスが少なくなるでしょう? 単純な掛け算なので、単価と注文数量が入れ替わっても計算上の問題なさそうです。
ですが、複雑な処理の引数となれば、設定ミスが減らせる効果は大きいはずです。

とはいえ、マギ情報システム開発のクラス定義は、改善が必要でしょう。
僕であれば、最低限、この様にクラス定義をします。

 // ※ JavaDocコメントについては省略する
 public class TorihikisakiMei {

     // 取引先名
     private String torihikisakiMei;

     // コンストラクタ
     public TorihikisakiMei(String torihikisakiMei) {
         this.torihikisakiMei = torihikisakiMei;
     }

     // 文字列として取得
     public toString() {
         return torihikisakiMei;
     }
 }

不要なgetter/setterを廃して、コンストラクタでのみ値を設定できるようにしました。
文字列が必要であれば、toStringメソッドで取り出せます。
これにより、オブジェクトとしてのカプセル化がより進んだでしょう。

できれば、ジェネリクスで型を指定できる基底クラスを用意しておきたいです。
実際の値はそちらで保持することにします。
そして、toStringメソッドや、必要になるであろう比較式・演算式を抽象定義することで、
多態性も上手く使える仕組みを用意したいですね。
当然、定義した型の値を取り出せる仕組みには、getterは使わないでしょう。

また、実際の型の定義には「関連する処理を集約できる」という利点があります。
例えば、先程示した Priceクラスでは、価格を計算する為の処理を持っています。
特定の文字変換がある様な項目、範囲が適正かチェックする必要がある項目など、
処理を集約することで、メンテナンス性が高くなる場面は多いでしょう。

ケース3処方:ValueObjectを適切に利用して、値を型で表現しよう

ケース4:メソッドの結果を必ずbooleanで返す

これは、僕もやっていた時期があります。
そして、未だに見ることが多いコードでもあります。

その昔、処理は「関数」と呼ばれ「与えられた引数によって、値を返す」が主流でした。
値を返さない処理を「サブルーチン」と呼び、「関数」と分けるケースもありました。
ですが、多くの場合で「処理の成否を取得できる様にする」為に、関数が好まれました。 エラー詳細を文字列で返すものもありました。
この場合、文字列が空であれば、正常となります。

Exceptionであれば、型と値により、エラーの種類や状態を保持することができます。
また、専用のエラー構文へジャンプしますので、そこで適切に処理をすれば良いのです。
逐一、処理が返した値を確認して、処理分岐をする必要がありません。
この処理分岐で、ネストが深くなっているケースは、結構見かけました。

ですが、Exceptionを嫌う人が一定層居るのも事実です。
その多くが「処理の出口は一箇所に限る」という考え方を持っています。
これは、Jump処理により、可読性やメンテナンス性が損なわれる、という意見です。
ですが、Exception を return や goto 等のJump処理と同列に扱うのは、間違っています。

Exceptionによるエラー構文では、catch によりエラーが処理されます。
実際には、処理はJampしていますが、出口は1つです。
catch句の後に、finally句の処理を実行することからも、明らかです。
処理でエラーが発生した場合、if文でその後の処理を回避することと、実質的な動きは変わりません。
むしろ、try~cath や Exception を利用せずに if文のネストを深める方が、可読性やメンテナンス性を下げています。

ケース4処方:Exceptionはたくさんの情報を持たせることができる。
try~catch構文と合わせて活用しよう!

少しだけマギ情報システム開発を擁護すると、booleanで返しているだけ「マシ」です。
文字列を返す例については、前述しましたが、よりめんどくさいケースがあるからです。
それは、intのステータスを返すケースです。
そのステータスの定義は、システムによりバラバラです。
0が正常だったり、1が正常だったり。-1が異常、9が異常。3は異常があったが後続処理に影響はない など。 酷いと、処理ごとに違っていたりします。

ケース5:独自のLoggerを実装

僕は、独自のLoggerを実装すること自体は、必ずしも悪いことではないと考えます。

僕が今主に関わっているシステムでは、独自Loggerを実装しているからです。
ただの自己保身で言っている訳ではありません。
色々な検討を重ねた結果、欲しい情報を効率よくログに残す為には、独自のLoggerである必要があった、ということなのです。
守秘義務で詳細は話せません。開発運用一体が前提となっている、特殊なケースです。
「ログの種類により、ログの出力場所を変える」という仕組みも入っています。
個人情報関連のログが、誰でもアクセス出来る所にあったら、問題ですよね。

しかしさて。
マギ情報システム開発が今回採用しているmagiLoggerは、その様な検討を重ねた末での選択でしょうか?
そうではないのだろう、ということは、イノウーと三津橋さんのやり取りから感じられます。

全体的な印象ですが、マギ情報システム開発の独自ライブラリ郡は「開発効率を重視したもの」ではなさそうです。
少し悪意のある見解ですが「ブラックボックス化して、相手を煙に巻く為のライブラリ」に見えます。

magiLoggerで出力されたログは、
「マギ情報システム開発のメンバーは読みやすい(かもしれない)が、開発者以外にはとても読み辛い」
という可能性があります。括弧内がポイントです。
ワンチャン、普通にタイムスタンプとテキストを垂れ流すだけの仕組みかも知れませんね。
ログレベル指定の機能はあるようですが…。

トラブルが発生した場合は、別途高額な出張費用を払ってマギ情報システム開発の開発者を呼ぶ必要がある。
これはボロい商売ですね!
僕は、ユーザー側のシステム部門があるなら、ログでのトラブル切り分け程度は、任せたいのですが。
「ログを見る」だけで一々呼び出されていたら、堪らない!と考えるからです。
ユーザー側の管理者に、ある程度ログの確認方法を教えて、不明点だけ別途対応する方が楽です。
そしてこれが一番大事なのですが責任を共有できます。
しかし世の中、同じ様に考える人ばかりではないのでしょうね。勉強になります。

24時間365日、ログのサポートをしてくれるなら(有料でも)。
とてもサポートの手厚い会社だな、と感じます。

ケース5処方:ケース5処方:ログは「誰が・なんの為」を考えて実装する。責任の分担。

ケース6:DBの文字コードフィールドの設定

実は、ここだけは何が悪いのか、理解できませんでした。
僕のDB設計の知識が、大分古いことは自覚しています。
なので「英数字で決まった桁数のコードを格納する」フォールドであれば、DB上にcher型で定義します。

作品中では「実は桁数が決まっていなかった」ということで、問題となっています。
これが、桁数固定だった場合でもtext型で定義するべき、というなら、腑に落ちません。

char型は、桁数が固定れる、固定長データ型です。
つまり、決められた桁数のデータが入っている事がDBにより保証されるのです。
この1点だけでも、char型を使う利点があるでしょう。
また、varchar型やtext型等の可変長データ型は、キーやインデックスに利用するのに向かないはずです。
もしかして、この辺の事情が変わったのでしょうか?

「varchar型よりも、text型を使うべき」の部分には、納得できます。
特に、UTF-8の文字列であれば、制御コードの関係で、varchar型は適さないでしょう。
ただし「厳密に容量算定の必要がある」ケースでは、varchar型でサイズを決めるでしょう。
この辺りの事情も、ディスク容量の増加等で変わっているのかもしれませんね。

ケース6処方:「文字型の場合、char 型を使うメリットはほとんどない」理由を教えて下さい!


故人曰く「神は細部に宿る」

僕は、コードの1行1行に、意味があると考えています。
昔の職人は言いました。
「神は細部に宿る」と。

コードについても、同じです。
究極、プログラムなんて、仕様書の通りに動いて、ユーザーが望む動作をしてくれていれば、中身なんてどーでもいいものです。

しかし、本当にそれで言い訳がない、ということを我々は知っています。
もし、バグがあったとき。
もし、仕様変更があったとき。
より早く、より安全に、より確実に。対応を行うためには、コードの1行1行に拘る必要があります。

今回、やり玉に挙げられたマギ情報システム開発の三津橋さんの最大の失敗は、
汚いコードを書いたことではありません。
何故そのコードを書いたのか、よく考えなかったことです。

よく考えた上で間違っていたのなら、修正の余地があります。
よく言われる【宗派の違い】ってヤツならば、調整の余地が生まれます。


今回の結論

上で【2020年11月現在の白栁のやり方】と書いたのは、
僕もまだまだ勉強の途中だからです。
一年後、一ヶ月後、もしかしたら明日には、ここに書いたことをひっくり返している可能性があります。
特に、ケース6については、僕の知識が古いです。
なので、アップデートされることにより変わる可能性がとても高いです。

ITエンジニアは、常に学び続けなければいけません。
それは、必ずしも最新の流行技術を追いかけるだけではありません。

仕様やコードと向き合い、その中からより良い方法を探索し続ける。
その中にも、十分な学びはあります。

それよりも、その探索の中で、判断の根拠になる知識を集める必要がでるでしょう。
それこそが、本当に学び続けるという言葉の意味なのだと、考えています。

以上!




ミニコーナー:白栁の2ヶ月だけホンキダイエット!(最終回)

ここ1週間の体重推移報告です。

体重(kg)
11/1290.1
11/1388.3
11/1488.9
11/1590.1
11/1690.1
11/1788.9
11/1888.4

最後のトレーニングが終わり、この企画も最終回を迎えました。
本来であれば、今回のコラムでまとめをする予定でした。
しかし、どうしても書きたい事ができたので、先送になりました。

改めてまとめた際に、総括やジムで計量した公式記録を載せたいと思います。

12月は、ダイエットのまとめ、婚活のまとめと、まとめ回が増えそうですね。


ITエンジニアの視点で、時事ニュースを5分間で紹介する動画を平日毎日公開してます。
「日々の生活の中にエンジニアリングがある」からこそ、
身近な時事ニュースから学ぶことが重要です。

#ほぼ日ITエンジニアニュース

パスワード付きZipをメール添付することがセキュリティ的に意味がない、とようやく周知され始めそうです。
今日公開された動画では、その話題を取り上げています。
これを切っ掛けに、日本のビジネスシーンでの情報セキュリティ意識が変わればいいな、と願っています。


Comment(24)

コメント

匿名

書いておられること諸々には賛同できるところが多いですが
誤字脱字が多くて読みづらいので
投稿前にチェックしてはいかがでしょうか

ちゃとらん

いやー面白いです。


とはいうものの『ケース2:名称は統一しよう』と『ケース6:DBの文字コードフィールドの設定』以外は、すべて賛成しかねます。
# というか、私も古い人間なので、自分の方法が『今風』とは思っていませんけど。


とりあえず一つだけ。


public class TorihikisakiMei クラス、flnal を使わないのはなぜでしょうか?
このあたりは私の『110.取引先クラス』に解説しているので、見てみてください。
# …って、ひそかに宣伝も入れておきます。

藤井秀明

イノウーでは無いですが、「『決められた桁数のデータが入っている事がDBにより保証される』ことで何か役に立ったことがあったんですか?」というところでしょうか。
静的型付けと違って、桁数を固定するのはデメリットの方が大きいように感じますね。

ちゃとらん

> 三津橋さんの擁護のために…
実は私も『あれなら普通のSEじゃないかな~』と思った口です。
あと、プログラムに関しては宗教戦争をする気はありませんので、あくまで私は…というレベルです。


> 藤井秀明さん
> 「…何か役に立ったことがあったんですか?」
ないですね。登録前に桁数チェックを入れてますし。
でも、データ移行やEDIなどによる取り込みなど、「おかしなデータ」が絶対に入らないとは限りませんから、私は桁数制限はアリだと思っています。(桁数固定はナシですけど)


> 白栁隆司さん
> 「桁数を固定する事のディメリット」
桁数固定(cher型)と桁数制限(Verchar(n)型)と桁数制限なし(Verchar型)が混在するのが嫌ですね。NUMBERが混ざるのは仕方なし…ちょっと矛盾ですね。
桁数固定は、フラグ類(0,1や、A,Bなど)を設定する場合くらいしか思いつきません。
その場合、Vercher(1) で NOT NULL 制約で使ってます。char型は使ってませんね。


桁数が固定でなく制限されている場合、後ろにスペースを入れられても結局使い勝手が悪くなるので、Vercharで十分です。つまり、「使うメリットがない」というデメリットがあるという事でしょうか?

藤井秀明

charが定義された長さの文字列のみ受け付けるのであればその辺のメリットは納得できるんですが、実際は超えたときこそエラーになるものの足りない場合は空白を付与して格納されるだけなんですよね。
だから、前者のメリットは「文字列長0の文字列」が「文字列長nの空白文字列」に置き換わるだけだと思いますし、後者の安全性はデータ型どうこうでは難しいのではないかと思います。

桁数固定のデメリットに関しては、まず本編であったように想定外のデータに対応できないことですね。
本編では要件定義ミスでしたが、それ以外にも今後の仕様追加や変更など、桁数を変える必要や、固定できなくなるケースなどは容易に想像できると思います。
桁数固定による安全性よりは、この柔軟性の乏しさのデメリットの方が大きい印象です。
また、先程も述べたように桁数に満たないデータには空白が付与されてしまうので、例えば脱字を確認したくともchar_lengthでは確認できなかったり、データを扱うときに空白を考慮した取り扱いをする必要が出てくると思います。

パッと思いつくのはこの辺りでしょうかね。

匿名

データ定義の際、なんでも間でもtext型では、そのカラムの持つ意味をデータ定義から読み取りづらくなると思います。
入る桁数が決まっていて、必ずその桁数が格納されるような、キー値にはchar型を使用すべきではないでしょうか。

まりも

>最近のトレンドでは「命名には、わかり易さ重視でかな漢字を使う」があります。
なんですか?

10年前から日本語識別子の必要性を強く訴え、(https://www.slideshare.net/potimarimo/ss-12314191)
日本にオブジェクト指向などが根付かないのはプログラミングに母国語を使えないのが最大の原因の一つだ、
とか嘆いていた私としてはかなりの朗報ですね。

反対が多くて諦めかけていましたが。
いよいよ良い時代が来るかな?

藤井秀明

僕も普段使ってるのがSQL Serverなので、ほかの言語は付け焼き刃ではあるんですが・・・笑
作中に出てきたPostgreSQLでは、上限超えた場合はエラーになるそうです。

まぁ結局のところはトレードオフの話ではあるんですが、やっぱりバリデーションの意味を成していない固定長はイマイチな感じがしてます。
それプラス、DBの設計を途中で変更するようなことはしたくないから可変長を選ぶって感じですかね。

まりも

オブジェクト指向と母国の関係について言えば、
オブジェクト指向の最大の利点というかむしろ大前提は、
プログラムに使う名詞や動詞が自然言語と同じように読めるということです。
それによって、自然言語で考えた設計がそのままに近い形でプログラム上に現れる。

日本人に、日本語みたいに読めるプログラムを見せて、こうすれば読みやすいでしょう?と説明すればわかりやすいですが、
日本人に英語みたいなプログラムを見せてわかりやすいでしょう?と言っても、どこが?と思う人がほとんどなのでは?

私自身、日本語でオブジェクト指向をやる練習をして、
初めてオブジェクト指向の本来の意味が分かったと感じています。

一度それができるようになった後では、英語でもあまり困らないと思いますが。

学習中には一度日本語で書くのに慣れてみたほうがいいです。

アメリカ人は皆、英語くらいわかりやすい変数名を付けろと習っています。
日本人もみな、英語くらいわかりやすい変数名を付けろと習います。

この意味は全然違うでしょう?意味する分かりやすさの程度が。
この違いがある限り、日本はプログラムの一流国にはなれないと思っています。

ちゃとらん

『日本語でオブジェクト指向』は、反対とまでは言いませんが、それほど魅力を感じません。


1.英語でいう大文字小文字が無いので、クラス、メソッドの区別をどう付けるか?
2.会社コード、会社コード、企業IDなど、結局ゆらぎは発生するので統一は必要
3.ArrayListを配列表とするのか、HashMapを寄せ集め地図とするのか?
4.XXFactoryメソッドをXX工場メソッドにするのか、XX生成メソッドとするのか?


結局、ルールというか規約というかそういうものをきちんとそろえる必要性は、あまり変わらないと思います。

おたみ

to まりもさん

自分の思考をまとめるためのコードや実験的なコードでは日本語を使った命名を行うことはありますが、本番(特に業務)で行うことはほとんどありません。

グローバルな展開も考慮すると


・文字コードの問題(日本語フォントが入っていない環境もあり得ます)
・開発メンバーの識字率の問題(日本語を母国語としないメンバーも参加します)


などがあり、グローバルな展開を考えなくても


・アルファベットとかな漢字が入り混じるので見た目の統一感がなく見づらい(あくまで私の主観ですが。。。)


といった問題もあります。

教育目的には良さそうですが、実務での適用範囲はかなり限られると思います。


to ちゃとらんさん

私個人の話ですが、1.には


・クラス → 名詞
・メソッド → 動詞


とすることで対処してます。(そういう区別じゃない?)

なので、4.も私の場合は「XXFactory.生成する()」のような命名にすると思います。

まりも

>ちゃとらんさん


新しい規約を作る時には、そういう試行錯誤は必ずやっているはずですね。
たぶんあと10倍はいろいろ検討して決める必要があると思います。


私も自分でやるときはいろいろ考えました。
複数形のsをどうするかなどが特に頭を悩ませましたね。


規約をそろえる必要性については日本語かどうかとは関係しないので、全く変わらないのではないでしょうか。

ちゃとらん

※ 人のブログのコメントを間借りして、申し訳ございません。


> おたみさん
>・クラス → 名詞
>・メソッド → 動詞
そういう事ですが、
> 「XXFactory.生成する()」
を、「XXFactory.作成する()」とかする人が出てくると、命名規約は必要になりますよね、という感じです。


> まりもさん
> 規約をそろえる必要性については日本語かどうかとは関係しないので、全く変わらないのではないでしょうか。
そうなんです。
なので、規約を作るのであれば、日本語でも英語でも同じで、おたみさんも指摘されているように、色々と面倒だな~というのが、(あくまで個人的な)感想です。


そのあたりも含めての『反対とまでは言いませんが、それほど魅力を感じません。』という感想になっています。あくまで、反対はしませんよ。
# でも、チームメンバーの一人だけが日本語で作成してれば、『ちょ、待てよ』とキムタク風に言うと思います。

まりも

日本語識別子について。


過去、泥沼の激論を何度かやってきているので、
よそ様のコメント欄で発言するのは気が引けるところがあるのですが。


重要なのは、日本語かどうかではありません。


単語一つ一つについてじっくり推敲して、一番読みやすいものを選び抜く、
という体験をしたことがあるかどうかです。


論文ならやるでしょう?
そして、プログラムで伝えなければならない内容の複雑さが、論文以下だとは思えません。
経験上論文ほど手をかける必要がない、と思っているならそれははっきり学びが足りません。


単語一つ一つについてじっくり推敲して、一番読みやすいものを選び抜く。
これを、英語でできますか?
そして、これを学ぶことを、英語でできますか?


日本人が、英語で論文や小説を書くことはできると思いますけど。
最初に論文を書く時から英語で書き方を学ぶのは、かなり難易度が違うと思うのですよね。

あと。具体的なメソッド名の例示についてですが、
「データを取得」ではだめで、「データを取得する」じゃないといけないと思います。
単語で終わっては名詞か動詞かの区別が付かないので、表現力が足りません。
日本語の文法は助動詞込みで完結するもので、単語終わりは省略表現であり、フルスペックのビジネス伝達には耐えられないようです。


単語選びについては、英語識別子名が数十年かけて貯めたノウハウをもう一度考え直す必要がありますから、
考慮が必要なのは当然ですね。
その労力が必要ないとは思っていません。
単語の統一くらいなら、仕様書で培った経験がある程度流用できるとは思いますが。
getterについて言えば定訳を調査すれば「取得する」一択じゃないかな。
少なくともマイクロソフトのドキュメントを調査した限りではそうでした。


規約を一から作る作業が必要になるわけですから。
ぱっと考えて適切な解決策が思いつかないのはむしろ当然ですよ。
なので、そういう例を挙げても論理的に意味を持ちません。


やろうと思えば明日からすぐできるようなことを提唱しているつもりはありません。
準備はかなり面倒です。
とはいえ、アメリカ人が見て意味が通る変数名をきちんとつけられるようになるまで英語を勉強するよりは、
かなり労力は少ないと思いますけどね。

コメントを投稿する