建物のリストもあった><
Registry of Certified Buildings and Plants | ENERGY STAR
https://www.energystar.gov/buildings/certified_buildings_and_plants
Commercial Buildings | ENERGY STAR
https://www.energystar.gov/buildings
建物に対しても、ENERGY STARあったのか><;
FAQ お問い合わせ | 国際エネルギースタープログラム
https://www.energystar.go.jp/faq.html
"...さらに米国では、家電などの機器だけでなく、家屋・ビル等も対象に含まれており、販売員育成や購入資金補助など幅広い分野に対して実施されています。"
シンプル
ファミマ、備蓄米を1キロパックで販売 1袋388円で5日から - ITmedia NEWS
https://www.itmedia.co.jp/news/articles/2506/04/news069.html
白菜も白菜も(?)、他の色々なhoge菜のわりと多くも、結局はブラッシカ・ラパ><
ブラッシカ・ラパ - Wikipedia https://ja.wikipedia.org/wiki/%E3%83%96%E3%83%A9%E3%83%83%E3%82%B7%E3%82%AB%E3%83%BB%E3%83%A9%E3%83%91
長文><
形式検証と契約プログラミングって、型のデザインが過度に複雑にならずに安全性を高められるって点でも、むしろ初学者に優しくなるかも><
完全に型のみに頼れば、たとえば引数が0では無い整数である必要がある時には、『0では無い整数型』が必要になるし、結局どこかでその型への明示的な(あるいは暗黙の)型変換が必要になる><
でも、怠慢なプログラマは、ゼロになっていないかのチェックを事前に行わずに、型変換時のエラーに任せるコードを書いちゃって、実行時にエラーが出るか、または出ないけどロジック的には誤りになるコードを記述してしまい、わざわざ『0では無い整数型』を導入したメリットがほとんど無くなっちゃう><
形式検証であれば、実際のロジック部分(?)で「ゼロになる可能性があるのでその対策が必要なこと」をエラーまたはアドバイスにすることができ、
オプショナルで無視するつもりなら無視しておいて実行時のエラーに任せるという選択も出来て、同じ無視する場合でも型で記述する方式と比べると無駄な型変換コードが節約できる><
そういう面でも初学者に易しいかも><