コード英語
希哲館が提唱してきた、英語を基礎にした「コード向け共通言語」hiro.icon 英：Code English、Codish（コーディッシュ）
希哲館訳語では「交度英語」「交英語」という
体系的片言化による体系的片言英語（Systematic Broken English）とも
デルンの実用化と同時に、2012年頃に概念が確立しすでに14年ほどの蓄積がある 命名で悩む全国のプログラマーたち、待たせてごめん……
コード英語話者になるとプログラミングは別世界のように快適になる
心苦しいが、あなた達が「名前を省略しない」という教義に四半世紀ほどのあいだ騙されていたことを告げなくてはならない
例えば standard を std と表現する
このように、英略語として扱われてきた語を正規の単語として扱うことに最大の特徴がある
2000年代以降のプログラミングで一般化した「名前を省略しない」のアンチテーゼとして std を standard、msg を message、ptr を pointer と読めない技術者はいない
略語というのはどんな分野でも記録や意思疎通の効率化のために自然発生するもの
それをプログラミングなんて神経質極まりない作業で使わない？アホか！という憤り
数学の潔さを見よ
「名前を省略しない」のは結局無理がある
println とか shared_ptr とか、最悪でしょ
結局めんどくさくなって更によく分からない略語が氾濫する
じゃあこの手の略語を基礎にした新しい言語体系を作ってしまおう
「名前を省略しない」に無理に合わせるより、「省略しかしない名前」に合わせていった方が実は合理的であるという気付き
実際に使用しながら試行錯誤を重ね、辞書を作って成果を共有していけばいい
Cμ をはじめ、虎哲開発全般で実際に長年利用している https://dlt.kitetu.com/KNo.F85E/0758-FCB8.webp?20260619171557
Cμ によるデライトのコードの一部
「読むコード」から「見るコード」へ
徹底的に単純化された語彙と文法からなる言語は、記号として直感的に把握しやすい
中途半端な略語が混ざったコードにならず一貫性が高まり、見ての通りかなり整然とする
横に短いコードは視線移動も短くなる
頭で考えて読むというより、「感じるコード」になる
コードがある種の図のように機能してくる
英語をそのまま使うことには非英語話者にとっての障害になる
J-IT の生産性を下げていた小さくない理由だと思う 文法の単純化
そもそもスコープ（文脈）を適度に分割するというプログラミングの基本が出来ていれば複雑な構造の名前は必要にならない
基本的に、主となる語を先頭に置き、形容詞などは後置していく
これにより視認性が高まる
識別子の先頭部分でその役割が概ね判断できるのが大きい
「文字列を分割する」は cut_str、「分割された文字列」は str_cut
ちなみに「文字列を結合する」は cat_str
str は文脈により s と略してもいいことにしているので cut_s でもいい
さらに Cμ では C++ の ADL を利用しているので関数呼び出しは cut( s, dlm ) で済むようになっている
C++には伝統的に文字列分割関数がない（今でも？）が、標準にあったとすると std::split( str, delim ) のようになるだろう
std:: いちいち付けるのも str みたいな略語を中途半端に使うのもダメダメだけど、これが一番ありがちなスタイル
std:: が無いと混乱するからじゃなくて、そもそも使わない規約で名前設計してくれと誰も言わなかったのか？とよく思う
言語名からすでに始まっているC++の命名センスの壊滅的な悪さは、ビャーネ・ストロヴストルップが自分の名前の複雑さに慣れてしまっていることから来ているのではないかという気がしてならない なるほどzatsma.icon
単数形・複数形の扱いなど、英語の細かい文法は煩雑過ぎる
日本人はまず正確に扱えない
交度英語では、基本的に日本語感覚で、単数形・複数形の区別はしない
単語は複数性を持つことを原則として、単数性を表現したい時は one などで修飾する