  |
はてなキーワード:enumとは
タスクタイプのENUMとタスク内容のStringと日付をDBに保存するコマンドプログラムを書いて タスク内容はタスクタイプによっては固定になる場合と任意のStringの場合がある
これで下のようなものが出たがENUM側に持たせてるので言い方の問題だと思うよ
public staticvoidmain(String[] args) {
Scanner scanner = new Scanner(System.in);
System.out.println("Task type:");
for (TaskType type : TaskType.values()) {
System.out.println("- " + type.name());
}
TaskType taskType = TaskType.valueOf(scanner.nextLine().trim());
if (taskType.hasFixedContent()) {
taskContent = taskType.getFixedContent();
System.out.println("Task content fixedas: " + taskContent);
} else {
System.out.print("Enter task content: ");
taskContent = scanner.nextLine();
}
System.out.print("Enter taskdate (yyyy-MM-dd): ");
LocalDate taskDate = LocalDate.parse(scanner.nextLine());
Task task = new Task(taskType, taskContent, taskDate);
System.out.println("Task saved successfully.");
}
}
DAILY_REPORT("Daily report submission"),
MEETING(null),
MAINTENANCE("Systemmaintenance task");
privatefinalString fixedContent;
TaskType(String fixedContent) {
this.fixedContent = fixedContent;
}
public boolean hasFixedContent() {
return fixedContent != null;
}
publicString getFixedContent() {
return fixedContent;
}
}
プログラミング言語のＣ＋＋に暫く離れていたが便利そうな機能が出来ていたんですね。
自分が調べても色々理解しきれていないのでここの紹介で間違いがあったらすみません。
異なるクラスを代入して保持するものであり、例えばunionのような機能を実現できるらしい。
武器として使う場合は攻撃力変数は必要でも守備力変数は必要なく、
鎧として使う場合は守備力変数は必要でも攻撃力変数は必要ない場合らしい。
このような使わない変数を隠蔽しバグを作ってしまうことを回避できるらしい
例えば、boolで実装する場合は、関数戻り値をboolで成功か失敗かを返し、欲しい値を関数の引数のポインタに返す・・というプログラミングになると思う。
std::optionalでは戻り値として欲しい値と失敗かどうかを一緒に返せるらしい。
メモリの動的確保だが自分でdeleteしなくて良いのでメモリ解放忘れを防いでくれる。
スマートポインタは前からあったが現在の推奨はstd::unique_ptr
(C++20以上と記載していましたがC++11とのご指摘を受けたため修正しました。すみませんでした。)
列挙クラス
列挙型だが従来の列挙型と異なり変数名が外部と衝突しない
nodiscard属性が付いている関数は戻り値の受け取りが必須となる。
ちなみにstd::optional＜std::string＞ obj;のように＜＞内に書かれているのは昔からあったテンプレート機能のようです。
拡張子については、例えばExcel の拡張子が変わったとき一括対応できる、とか？
あとは普通に".txt" で取り扱ってるファイルはどれだ、って時にその定数の参照箇所を見ればもれなく分かるとか、
取り扱うファイルの種別を段階的に変えようってときも、どのファイルは変え終わっててどのファイルはまだ、とかも同じように分かる
あとはあれだ、どのスコープにおける分類なんだって話を明確にする事も出来るだろうな。
とか。
パラメータについては、複数の選択肢から選ぶ奴はenum にしろよ、とは思うが、
文字コードも大体同じような話か。
ここに定義したもの以外は登場しないよ、という保証をする事は出来るわな。
自分には6年付き合った年上の彼女がいた。名前はPHP。学生の時からの付き合いで、自分にとっては初めての彼女だった。付き合った当初は全てが新鮮で、オブジェクト指向やSOLID原則、大事なことは全て彼女から教えてもらった。（そう思われるかもしれないが、）時間が経って彼女の魅力が感じられなくなってしまったということはなくて、彼女は歳をとっても魅力的なままだった。むしろreodonlyプロパティやEnum、null safe演算子など、新しい機能が導入されてますます綺麗になっていったように思う。最近ではジェネリクスさえ導入されたようだ。彼女は本当に努力家だ。
（褒められた話ではないが一応、彼女以外の女性を全く知らなかったわけではなく、TypeScriptという若い子と少し遊んでいたこともある。TypeScriptは昔からの知り合いのJavaScriptの妹で、大雑把な姉と違って几帳面で、少しオタク気質もある個性的な子だった。よく新しい型パズルを考案して楽しそうに話してくれたが、自分には正直よく分からなかった笑。）
そんな中でも基本的には6年間PHPとずっと一緒に過ごしてきた。前述の通り彼女に何か不満があったわけではない。ただ、彼女との将来に不安を覚えるようになってしまっていた。周囲に彼女と付き合っていることを話すと、「え、まだPHPと付き合ってたんだ？（昔は人気だったけど、最近はそうでもないよね）」みたいなことを、彼女のことをよく知らない人から言われたりもした。そこまで直接的ではなかったけれど。自分も、彼女以外の女性のことをほとんど知らずにずっと彼女と付き合っていて大丈夫なのかななんて思ってしまったりしていた。
結局自分はPHPと別れて、新しい女性と付き合う決断をした。新しい彼女の名前はGo。彼女は若いのに自分の芯がしっかりしていて、みんなの憧れの格好良い女性といった人だった。そんな彼女と付き合いだして、最初は戸惑うことも多かった。
例えばこんな感じだ。
また、今まで当たり前だと思っていたPHPの良さに気づくことも多い。PHPStanを使えば静的型付け言語と同じように型安全性を担保できていたし、彼女のWebFWには歴史が長いだけあって痒いところまで手が届く様々な機能が完備されていた。経験豊富でこちらの要望をなんでも受け止めてくれるような包容力があったことに今更気づいた。
とはいえ、いつまでも昔の彼女を引きずっていてもしょうがない。Goにはこちらに積極的に合わせてくれるような包容力はないが、彼女なりの哲学を持っていてそれ故の美しさがあると思う。そして正直、まだ彼女の10分の1も理解できていない。彼女が得意だという並行処理や、実行速度が求められるような処理も、自分はまだ実際に実装したことはない。でもこれからしっかり向き合って、Goのことをもっと理解して、実りのある交際にしていきたいと考えている。PHPと別れてGoと付き合う決断したのは自分なのだから。
時は金なりという意味か？
public class Person { BasicInfo info; float stock; floatValue; publicstringName(bool isSpy){ return isSpy ? info.Name : info.Name.ToSecondName(); } publicstringSex(bool isNormal){ return isNormal == info.isMan ? "Man" : "Woman"; } public float Earn(bool isExtra =false){ floatsexPad = info.isMan ? 1f : 0.5f; floatracePad = info.isWhite ? 1f : 0.5f; var delta = DateTime.Now - info.Birth; intage = (int)(delta.TotalDays / 365); float result =Value *sexPad *racePad *age; if(isExtra){Value += result; } return result; }enumRace{White, Black,Yellow }; class BasicInfo{ publicstringName; public int NationalId; public bool isWhite; public bool isMan; public DateTimeBirth; public BasicInfo(stringName, int NationalId,Racerace, bool isMan){ this.Name =Name; this.NationalId = NationalId; this.isWhite =race ==Race.White; this.isMan = isMan;Birth = DateTime.Now; } }
おう！外部キー制約を語るとは、RDB を勉強しているのだな？いい心がけだ。増田は外部キー制約があると「どんなメリットがあるか知りたい」のだな？良し、答えてやろう！外部キー制約があると「変なデータが入らない」ということが開発者が『保証』できるのだ。うん、それで？って増田は思うだろう。それで、実例を挙げるけど、sex というカラムを create で作ったときに、そこに insert into で入る値が「男」「女」「その他」というデータに限りたいときが設計者にあったとする。そうすると、「 insert するのは『チンポ』でしょ？」みたいなアホを防げるだろ？もちろん、limit みたいな副クエリで実装しても構わない場合もある。型を指定して、boolean にしたい場合もある。だが、「入るのはこれだけだと思うが、後に追加で変更できる」としたら、嬉しい場合があるのじゃ。まぁ、究極的にOOP や関数型言語、または（古い）命令形言語だと、enum みたいなものなんだよ。いや、だとしたら、enum でよくね？って思うのなら、リプライくれ。答えるから。
言語によると思う
javaなら普通にオブジェクトでEnumを継承したインスタンスになるからその分メモリ使うし、enum内部で結局String持ってる（コンパイラがStringをEnumの子クラスのコンストラクタに渡す）からStringの方がリソースは無駄にならない
ねぇXちゃんさぁ。なんでこんな動的なオブジェクトをstaticにしてんの？
これさぁ、そこそこ重いけどさ、セッションごとに生成される一時的なインスタンスで持ってるだけでも十分パフォーマンス的に問題ないよね？
なんでプロセス間でわざわざ共有してんの？
ネットワークリソースつったって利用者はたかだか数百人でしょ？
その中でリソースを同時利用するってゆってもたかだか十数人でしょ？
プロセス内でこのオブジェクトを全共有することでリソースの削減なんてたかが知れてるよね？
それをわざわざプロセス内でこのオブジェクトを全共有ってマジ管理できるの？シンクロナイズドとか書いてっけどさぁ？削減できるリソースの量に比べて超危険すぎねぇ？
コミットログ見たけど、ぜんぜん性能問題とかと関係のない問題の修正だったみたいだけど、なんでこんな危険なコードになったわけ？
Xちゃんさ、そもそもコードが品雑なんだけど、これエンプラJava案件なのよ
なんでCの組み込みコードみたいにif文の鬼ネストとか、引数に空のList渡して破壊的に値を設定するような、読みづらいコード書いてるわけ？
Listくらい普通に返り値で返しなさいよ…
状態管理もif文の鬼ネストやめて専用クラスとかEnum使ってコマンドパターンで対処しなさいよ
もしかして、Xちゃんオブジェクト指向にピンときていないのかな？
俺ちゃんはどっちかってーっとPHPパーなので、ゴリゴリのオブジェクト指向はそりゃ専門じゃないよ
それでもさ、interfaceとか使って、各処理の実装を切り分けるとか、やりようはいくらでもあるじゃん。
あと不要なnullチェックも多すぎです。コンストラクタで初期化が保証されているfinalなフィールド値がnullかどうかなんて確認しないでください
ユーザー入力、DB入力、環境リソースとか、外部の情報起源じゃない変数がnullとか、明らかなバグなんだから暗黙的なぬるぽでクラッシュさせましょう
こんなバグが出荷に乗ることなんてありえません。わざわざ専用のエラー処理で専用の例外飛ばすとか無意味です。
いちいちなんか冗長で複雑なんですよねぇ。
俺ちゃんみたいな若造が、ベテランのXちゃんにこんなこといいたくないけどさ、
Xちゃんのコード。どこか昭和の匂いがするんだよねぇ。悪い意味で。
プログラマなんだけど、なんでも揃えようとしてる人がうざい
よくあるのが、JSON とかオブジェクト系の記述するところで、 「:」とか「＝＞」みたいなのの位置
揃えられると一見すると見やすいが、金額みたいに揃ったみやすさが必要ないところでされると面倒
10行並んでたら1つ変えたのが原因で10行とも変えないといけなかったりする
面倒だけどツール使えば揃えること自体は楽にできるからこれはまぁいい
だが、バージョン管理ソフトでの変更行数が無駄に増えるのでパット見たときに結構大きな変更してるように見えたりするからちょっとイヤ
さらにgrep かけようにも空白数が不定だから正規表現にしないといけない
んだけど、まあここまでは別にいい
この揃えるときに
aaa : { bbbb :100 ccccc: 200},dddd : { e: : 300}
みたいに（フォントによっては揃ってなく見えるかも）、ネストが違うのに全部を揃えようとするの、ホントやめろ
わかりづらい
上の例みたいなシンプルだと困らないが複雑な構造になってるとかなり見づらい
上でいうaaa と dddd の行が10行程度離れていたら、ここを揃えても全くきれいに見えないし無駄
bbbb と ccccc みたいなときだけならまあ許せる
仏の顔も三度まで、
(1)文字数を合わせようとする
上で書いたみたいなのは文字数が違うから合わせるためにスペースを入れる必要がでる
きれいなのはわかる、だが無理やり合わせようと単語を探し始めるとかありえない
5つ項目があって、4つが6文字の単語で残りの1つが4文字だったとする
無駄な上に、本来のそれに適した単語じゃないのを無理やり使うのでわかりづらい
揃ってることはパット見綺麗でもプログラムみたいのだと、単語まで似てると気づかないミスが出て来る
beer と bear、 form と from、 fall と fail みたいな見た目が似てる単語と、見た目が全く違う単語の比較ではミスの数が明らかに変わると思う
なのに、enum みたいな選ぶタイプのもので、数文字違うだけの似た見た目の単語を探してきて選ぶとか、ミスを誘発しようとしてるのかと言いたい
(2)単語の語尾とか
(1)のように大半が揃ってると残りも無理やりそうしたいということで、単語を勝手に変化させたものがある
例えばだが、語尾が1つを除き全部 -ly になってたとする
そうすると残り一つに無理やり ly をつける
なんなの？イン踏みたいの？ラッパーなの？？
そもそも名前みたいな固有名詞にすらそんなことしてるから意味不明にもほどがある
上の時点で英語を完全無視で英語力のなさはわかっただろうが、さらにこういうのもある
過去形にはed 、複数形には s のようなルールには単語によっては特殊な形をするものがあるのはもちろん知ってると思う
プレフィックスにis つけるみたいな単語の組み合わせ部分なら気にしないけど単語としておかしいから、自分で書くときに本来の形で書くとエラーでるからさらにイライラする
例えばこういうこと
readed, catched, taked, companys, boxs, mans, childs, fishs, classs
見てるとムズムズする
英語得意でない自分ですら違和感を感じるのに、これに何も感じないとか英語力ひどすぎると思う
まあエラーメッセージでdon't have ～ とすべきところをhas not ～ とか書いてたくらいだからなぁ
これが部下とか下の立場の人なら 「使う前にググってみて。おかしかったら『もしかして、～～』みたいの出るから」と言って直させるけど、上だからどうしようもない
間違ってますよー、と遠回しに言ってみたことはあるものの、直す気は全くないようだし、それどころか無邪気に揃えてやったぜみたいなこと言ってドヤ顔してるからホントどうしようもない
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。
要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。
ここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここにお詫びと感謝を述べておきたい。
抽出条件だが、参考にできそうなコミットログを多く含んでいそうなリポジトリをGitHubのSTARの多い方からざっと目で見て適当に選び、それぞれ最新コミットから5000件抽出した（あわせて前処理として、コミットログ冒頭のタグ情報は消去した）。
atomのみ5400件抽出していたため、計25400件のコミットログがベースである。このうち、以下の条件に合致するものは参考例にすべきでないとして一律排除した。
こうして残った8540件を眺めながら、適当に切り出したのがこの用例集である。個人的に「うーんこの」と思った表現も、散見される場合は載せた。
ということで、以下用例を羅列していく。
以上の用例をふまえ、今回の参考ログ8540件から先頭の単語を出現回数で並べると次のようになった。
| Add | 1149 |
| Fix | 1014 |
| Update | 584 |
| Remove | 566 |
| Use | 382 |
| Don't | 260 |
| Make | 228 |
| Move | 178 |
| Change | 103 |
| Rename | 85 |
| Improve | 76 |
| Avoid | 68 |
| Allow | 65 |
| Implement | 60 |
| Handle | 58 |
コミットログの基本形はもちろん動詞 +名詞である。名詞は固有名詞、複数形、不可算名詞が多いが、単数形の場合の冠詞は a が使われるか、あるいは省略される。the はまず使われない。
何かを追加した、という表現では非常に広くAdd が使われる。メソッドからテスト、ドキュメントに至るまで大概これでまかなえる。
一方、何かを修正した、という表現では広くFix が使われる。「何か」はtypo やcrash といった単語からメソッド名まで幅広い名詞を取るが、動名詞はあまり取らないのと、that節は取らないのでその点は注意が必要である。
Fix は「何かが正しく動くようにした」ことを示し、正しい動作内容が何かを説明しない。そこで正しい動作内容に言及したい場合はMake sure が使われる（こちらはthat節が取れる）。ただしFix よりもニュアンス的に重い表現と思われ、Fix を使わずMake sure ばかり使うのはちょっとキモいのではないかと思う（Ensure はさらに重い表現っぽい）。
また、Fix はtypo 以外でのドキュメント修正に対して使われることは稀である。対して Update はドキュメント、コメント、テストに使われ、本体のコードの修正に対しては使われない。本体コードの修正にあわせてテストも更新したなら Update が使われる。ただ、テスト機構それ自体のバグを修正したならFixである。
無駄な何かを単純に除去したなら Remove を使う。これまでのもの(A)から別のもの(B)に切り替えたのであれば Use B instead of A かChange A to B が使われる。新たに何かを利用するようにしたのであれば Use を、利用を取りやめた場合はDon't use を使うことが多い。
何かをしないようにしたならDon't を、内部実装の効率化ならMake A +比較級/形容詞 かImprove が使われる。
中身の変更を伴わない単なる名前の変更なら Rename A to B、コードや機能の論理上の場所を移動させたならMove A to Bである。
この辺はリファクタリングと呼ばれる行為と思うが、Refactor というぼんやりした動詞はあまり使われず、このように変更内容の種類に応じて動詞が使い分けられている。
コミットログにはWhyを書くべきだ、というのを何かで見かけたので because とか since を使ったログがどの程度あるかを調べたが、8540件のうち22件だった。基本的に短く、シンプルに、一目で意味が取れるログが好まれる傾向がある。例えばget rid of とか2件しか使われておらず、圧倒的に removeである。
一方で、シンプルな単語だけど開始単語としては使われないものもある。例えば次のような単語である。Expand(9)、Extend(8)、Print(5)、Optimize(5)、Publish(4)、Append(4)、Modify(3)、Manage(2)、Revise(2)、Dump(2)、Insert(2)、Migrate(2)、Enhance(1)、Edit(1) 。いずれもカッコ内は8540件に対する冒頭での登場回数である。結局、より一般的で平易な単語で表せたり、Refactor同様に抽象度が高すぎると使われないのだろう。
8000件もログを見たおかげで、迷いなくコミットメッセージが思いつくようになったのが個人的には今回書いてて最大の収穫だった。たぶんカンニングペーパーを作る行為それ自体が効率のいい学習になるという話と同じだと思う。
このまとめも100以上用例を転載してあるので、それを読むだけでも多少は効果があるんじゃないかと思う。同じようにコミットログ書きたくねぇなぁ英語わっかんねぇなぁと思っている人にとって、何か役に立つところがあれば幸いである。
ちょっとした事情からシステムディスクの移設をしたところかなり躓いたので、備忘録的にメモ。
時代に逆行して個人的な書き物をする場所を一切持ってないのでお借りします。
以下、Linuxなりの最低限の知識があり、バイトオーダーもわかり、細かいところは勝手に補間できる人向け。
オフセット32256バイトを1048576バイトに調整する。
得てして非AFTからAFTという状況と思われる。
コピー元が壊れかけの時はやらないほうが吉。
