配列の添え字が０から始まるのが嫌で１から始まる配列の系を新たに作ろうとする人への説明ｍ９（＾～＾）

疑似コード

var days = []string[nil, "mon", "tue", "wed", "thu", "fri", "sat", "sun"]
print(days[1])
// mon

配列の添え字が　０　から始まるのが嫌で、
配列の添え字を　１　から始めたくて、
配列に下駄を１つ履かせて　調整している人もいるかと思う

コンピューター・プログラム言語は、 序数 を使うケースは少ないが、
現に Lua スクリプトのように　配列の添え字が 1 から始まる 序数 の系も存在した

また、

📂
├── 📄素材1.png
├── 📄素材2.png
├── 📄素材3.png
└── 📄素材4.png

👆 素材ファイルを読み込み、

var files = []string["素材1.png", "素材2.png", "素材3.png", "素材4.png"]
print(days[2])
// 素材3.png

👆 配列の [2] 番の画像を差し替えたくて 素材2.png ファイルを更新して　できたと思っていたら
変える必要もない配列の [1] 番の画像が指し替わっているという 錯誤 が起こることと思う。
錯誤とは、間違っていると思わず指示して、使われる者がルール通りに働いたら　思っているものと違うことをした、ということだ
　
これは、管理番号に 序数 を使っているが、配列は 基数 を使っていることによって起こる。

配列の添え字が０から始まるのが嫌で１から始まる配列の系を新たに作ろうとする人 というのは、
コンピューターは序数を使ってほしいと思っている人 だと言い換えることができる

なんで　そんなことをしようとするかというと、 錯誤 するからだ

ほんとうに慎重であるならば

first を 1st、 second を 2nd、 third を 3rd、 fourth を 4th とするとき、
じゃあ 112 は 112st, 112nd, 112rd, 112th のうち　どれか？

という問題がある。 これは n-th とか nth という名前で見かける
末尾の 2 に着目すれば 112nd としてしまいそうだが、
末尾の 12 に着目すれば 112th とするのが正しい。
122 なら 122nd となる

📂
├── 📄素材10th.png
├── 📄素材20th.png
├── 📄素材30th.png
└── 📄素材40th.png

👆 めんどくさいので 一の位が0になる呪い にかかることで全て th でいける

var files = []string[nil, "素材10th.png", "素材20th.png", "素材30th.png", "素材40th.png"]
print(days[20/10])
// 素材20th.png

こうすることで人間は 序数 を使っているし、コンピューターは 基数 を使う、
という意識付けができるが、 0th と３文字余分に打ち込むのが エコでないし
コンピューターが １０で割る のはイケてない、という見方もあるだろう

そこで、

📂
├── 📄素材1th.png
├── 📄素材2th.png
├── 📄素材3th.png
└── 📄素材4th.png

👆 英語の発音を無視し 全て th にし、

const geta = 1 // Japanese wooden clogs. Used to convert bases and ordinals.
var files = []string["素材1th.png", "素材2th.png", "素材3th.png", "素材4th.png"]
print(days[2 - geta]) // * `- geta` - 序数を基数に変換する
// 素材20th.png

👆 序数は - geta して基数に変換してから使うんだ、と念じる

var s = fmt.Sprintf("素材%dth.png", 2 + geta) // * `+ geta` - 基数を序数に変換する

👆 基数は + geta して序数に変換してから使うんだ、と念じる

この工夫により、

Pros

• 数（すう）に親しくなる
• スライスの [begin:end] に親しくなる
• 配列を [0] から使える
• for i:=1; i<len(array)+1; i++ { とか書かずに for i:=0; i<len(array); i++ { で書けるから 2文字短くなる
• 配列の添え字が 1 から始まる特別な系を作らなくて済む

Cons

• ファイル名が２文字長くなる。th を打鍵するのもめんどくさい
• geta が 日本語の下駄のローマ字で 昭和のおっさん臭く かっこわるい

などと言える

どこで序数を使い、どこで基数を使うか？

以下のとき、序数は優れている

暗記で、そらんじられる

わたしたちは　序数　を暗記で　そらんじられる。

いち、に、さん、 さんの次なんだっけ？ ということがない。

アルファベットでも　あいうえお　でも序数として利用するのに向いているし、
松竹梅　と、３つしかない序数もある

pros

• 漏れや、忘れ物がないか確認するために連番で点呼する。飛び番があると、誰かいないのではないか、何か抜けているのではないかと気づくことができる
• 全て数え上げると嬉しい

cons

• 配列の添え字が０から始まるのが嫌で１から始まる配列の系を新たに作ろうとする人が出てくる

リナンバリングしないことで嬉しいとき

出版した本のページ数などは、基本的に　変わらない　ので引用元を示すのに使いやすい。
野球選手の背番号も　たまに変わるが、そんなに頻繁に変わらないので　グッズ　はずっと使える。

それに比べ、

📂
├── 📄素材1.png  4/01
├── 📄素材2.png  4/01
├── 📄素材3.png  5/10
├── 📄素材4.png  4/02
└── 📄素材5.png  4/02

👆 「素材3.png を追加しました。 以前の 素材3.png 以降は数字が 1 ずれます」
という決定が飛んでくると

• ファイルのリネーム作業
• コードの改修
• 引用している資料の改修
• 周知

など工数が増え、その割にべつに大したメリットはないので、
リナンバリングしたいのなら 序数 を利用するのに向いてない。単に Id にすればよい

確かに　仕様書に 序数 が振ってあり　ソートされていれば 読む人は嬉しいというのはあるが、
それは開発中にやることではない

とくに序数でありたくなければ基数を使う

基数は　序数を兼ねることができる

JSON に出力するとき　どうするのか

{
    "value" : 1
}

👆　基数のつもりで格納しているのか、序数のつもりで格納しているのか、分からないケースがある

{
    "valueNth" : 1
}

👆　仕方がないので、 Nth を変数名につけたときは序数、それ以外は基数という　マイ・ルール　を決めておけばいいんじゃないか