【Console Application】ファイルとデータベース 168【学習記】
ファイルとかデータベースの話🤤
Q.
もしかして：の前に
A.
Java だと無くても良かったのに Kotlin だと null 許容のままだと null 検査が義務になるのでコードが凄い増えるのよ😞
→ Java では呼び出し側が気をつける事だが Kotlin は null 許容を事前に排除するのが美しいらしいと思った null 安全化の巻🤤
【Console Application】ファイルとデータベース【学習記】
仕様
https://note.com/sayka/n/nb8a67fa90a64?magazine_key=m7bb64c6a359f#br1mB
仕様
レコード
・レベル
1-12
・難易度
b,n,h,a,l
・曲名
・ランプ
-,x,a,e,c,h,e,f
オプションスイッチ
-u file.csv # 更新(略値)
ファイル名だけ指定した場合更新処理と見做す
-d file.csv # 削除
-p # csv 出力(略値)
何も指定せずに起動した場合出力処理と見做す
-v # バージョン
-h # ヘルプ
----備忘録
AnalyzeArgs で引数の並びが判別不能になる機能不足を解消
null 安全
Csv の when の中身やる前に、前回思った「 null チェック増えてめんどくさーい😫」を解消しようと思う🤤
Java の場合は放っておいても null 混在なんだけど null じゃない事を前提に組む事ができちゃってその結果ぬるぽになる事故が多かったのかな🤔
その状況を打開する為？に Kotlin では null 許容という仕組みが導入されてこの型の場合必ず null チェックしないとコンパイラが怒るっていう仕掛けになってる🤤
この仕組自体は Swift にも有って型混在を許す JS にも判定方法で似た概念が入ってきてるので null を気軽に入れられる型というのは分断が進んでいるのが最近の開発言語の方向みたい🤔
JS でもやり始めたら末期かな…不自由すぎる😞
今回は「 null 許容」が存在する言語へ移植するという事でもっとその概念が活きる移植改造を施そうって思ったわけ🤤
これやっとけば Swift へ移行する時も同じ思考が可能になる🤪
ただ、 OC の場合は null 安全は若干不完全だった気がするから Java 方式になる可能性が濃厚かな🤔
まぁ、やってみないとわからないけど🤤
とりあえず今の状態でコミットな👇
null 安全化の枝を作るぽ🤤
それじゃ、作った順に null 安全化開始よー🤪
MathUtil
そもそも null と無縁！終了！🤪
Console
打って変わってこちらは沢山有りそう🙄
readLine はそもそも「何も入力されなかった」を検知できる必要があるのでこれはそのまま😑
そういうのもｱﾙﾉﾖ🤤
AnalyzeArgs は(プロパティが) null 安全になってる🤤
これは確か移植した直後は null 許容にしてたんだけど main の引数 args が null 安全で args 内に null 入って来ない(プロンプト入力で null 渡すとか不可能だと思うし)ので Java では入れてた args の null 検査は Kotlin だと「 null は入ってこないから( null 検査は)意味ないぞ」って IntelliJ が言うから null 許容を外したんだった筈🤔
要するに、こいつは null 安全化済🤪
StdlibKT
………🤔
どうしようかなこれ…🙄
引数入って無くても空の配列を作る方が動作としては有用？🤔
なんかそんな気がする。忘れてたならそれはプログラムエラーだし意図して null を入れるのは null が入ってても処理を続行して欲しい場合が殆どだし配列として0項目なら for も null チェックしなくても良くなってしかも反復しないから tableStringToArrayString は null 安全化してもいいかな🤤
この修正の影響で呼び出してる側に影響が有る筈なんだけど…
IntelliJ 「この式は常に true だぞ」
あ、はい🙄
無意味ではあるけど有効な式だったのでエラー表示されてなかったってだけみたい🤔
コメント化してメモ入れとこ🤤
file.Utils
file に2つある内の片方は単なる列挙だから Utils に飛ぶお🤤
クラス内唯一の機能の返り値が列挙型！！終了！🤪
次回は
引き続き null 安全化🤤
結局早々に Csv に戻ってきてしまい、こいつのプロパティを null 安全にするのが主題だったってオチ…🙄