良かった…ちゃんと帰れるコードだ

>良かった…ちゃんと帰れるコードだ
100≦残金<おでんの価格の時帰れないぞ

１００円以下のおでんが売り切れてたら詰みじゃねえか

残金100円で130円のおでん買いたい

OdenNotFoundError

今7月だよおでん無いよ

fu3760805.jpg


トミージョンを受ける

>良かった…ちゃんと帰れるコードだ
おでんが途中で売り切れたら？

>>良かった…ちゃんと帰れるコードだ
>おでんが途中で売り切れたら？
おでんが入荷されるまで待機する

おでんを買う処理で値段を全く考慮してないなら逆に見かけは動くかもしれない

つまりスレ画は品質の低いコードなのか

>つまりスレ画は品質の低いコードなのか
それに関しては疑いようがねえよ

半年後の自分が読んでも分かるコード

label .conbini

while 1==1:
if self.money>=100:
try:
buy_oden(self.money)
expect:
pass
else:break

goto .homo

今このコード実行したら秋までコンビニでフリーズか

あーきてくちゃ？に従っておけばいいんでしょ
知ってるわよそれくらい！

最近フローチャートとか描かないわー

オライリーにそんな本結構あるな読んだことないけど

コンビニうちの近くにコンビニない

>オライリーにそんな本結構あるな読んだことないけど
リーダブルコードは名著

オライリーは基本

>goto .homo
ホモになってんじゃねぇよ！

>コンビニうちの近くにコンビニない
コンビニに行く

>コンビニうちの近くにコンビニない
コンビニ not found

出勤途中にコンビニに入ったらおしまい

残金が減らないままおでんが増え続けてオーバーフローするかもしれない

me._buyOden("tamago")

財布に数万円あったら大変なことにならない？

おでん購入BOTにそんな大金持たせるほうが悪い

どこのコンビニに行くかは支店名をアルファベット順で検索します

おでんの具はどれに致しますか？

財布を共有している兄弟の片方がコンビニに取り残されたりする

有り金の分だけおでん買うの治せって言ったでしょ

セブンとかのパックのおでんはどうなるんだ

絶対帰ってくるようにするには所持金を９９円以下に最初からしておけばいいな

すいません夏はおでんやらないんですよ

>すいません夏はおでんやらないんですよ
おでんを買う

>>すいません夏はおでんやらないんですよ
>おでんを買う
秋まで居座る気か…！？

残金がnull円の場合→帰る
こうすればお金が無い時は家に帰れるぞ！

>残金がnull円の場合→帰る
>こうすればお金が無い時は家に帰れるぞ！
何円になっても帰れないじゃねーか

リーダブルコードとクリーンアーキテクチャぐらいしか書籍読んだことないな
他にこれは読んだ方が良いみたいなのあるんだろうか

>何円になっても帰れないじゃねーか
お金というものの数値そのものが無くなれば帰れる

そもそも複雑なことをさせようとしなければ良いのでは

>そもそも複雑なことをさせようとしなければ良いのでは
コードはできるだけ単純であるべきだが、矮小化してはいけない
ってサッカーパンチのプログラマが言ってた

人間の処理能力ってすげえんだなって思い知らされる

アジャイルだとこのフローチャートで取り敢えずイテレーション1廻しするんだろうか

リーダブルコード読んだけどだから何だって感じだった

コードがドキュメントとか手抜きせずにちゃんと設計資料を作るのが大事
どういう振る舞いをするかじゃなくてなぜその処理をするのか目的を丁寧に書き残せ
スレ画のプログラムだと無事お家に帰り着くのが最優先目的だ

全部を場合分けするなんて無理だよ
流行りのえーあい？でなんとかならないの

ふつーに開発進めてくと
・新たなクラスが増える
・既存のクラスが大きくなる
・既存のクラス間の依存関係が増える
これで混沌としていく一方なのでいずれ死ぬ

もう間もなく設計書からソースコードが自動生成されるようになるはず
だけど性能とかの非機能要件で結局人の手でカリッカリにチューニングする必要が出てくるんだろうな…

>全部を場合分けするなんて無理だよ
>流行りのえーあい？でなんとかならないの
全部のテストパターンを作ってくれるよ

AIで手が早くなるだけで全部任せられるわけないし…

>もう間もなく設計書からソースコードが自動生成されるようになるはず
>だけど性能とかの非機能要件で結局人の手でカリッカリにチューニングする必要が出てくるんだろうな…
設計書からソースコードを自動で作る技術は富士通あたりが20年前からやってる
ご想像のとおり設計書を書く作業がプログラミングそのものになった

最近秋もおでんなくない？

>ふつーに開発進めてくと
>・新たなクラスが増える
>・既存のクラスが大きくなる
>・既存のクラス間の依存関係が増える
>これで混沌としていく一方なのでいずれ死ぬ
既存の企業はどうやって死なないようにしてるので…？

コードを書かないほど読まなくて済むので可読性が高い！

流行り病にかこつけてだいぶ置かなくなったと思う

すみません私はフランスから来た初学者なんですが
>fu3760805.jpg
の悪い部分が分かりません
23kgの部分を変数にするだけで良いんじゃないんですか？
getset使わない方法とかあるんですか？

お前が「」変数になったとして外部から自由に体重を制御できて正しいと思うか？ってことだ

よくあるコンストラクタだけ使え不変にしろって話じゃない

>可読性やら
命名ルールとか構造化で意図がわかりやすくなるようにがんばる
>信頼性やら
ユニットテスト書いたり手動で根性テストを繰り返しがんばる
>再利用性
捨てる

この人の書いたコードすげえ読みやすいわって人にレビューしてもらう
これに勝る方法は無い

オブジェクト指向わからない
雰囲気でやっている

自動…テスト…？

おでーん！

文脈わからんけど「現実世界では」って考え方は筋が悪い
コードの上では現実に起きないことも起きる
現実ではってのはまあわかりやすいのはそうなんだけどさ

オブジェクト指向って何なの？って聞いてる時はクラスとインスタンスの区別がついてないレベルが多いのにたいていポリモーフィズムとカプセル化と継承のご高説が始まるの辛い

>すみません私はフランスから来た初学者なんですが
>>fu3760805.jpg
>の悪い部分が分かりません
>23kgの部分を変数にするだけで良いんじゃないんですか？
>getset使わない方法とかあるんですか？
ロボトミーを受けろ

真面目な話をするとオブジェクト指向プログラミングをちゃんとやるならget setはなるべく使うなって話がしたいんだと思う

処理早かったり字数行数少なくできる書き方よりも数年後入って来た１年目の子でも読める書き方を優先した方が良い時もある

>処理早かったり字数行数少なくできる書き方よりも数年後入って来た１年目の子でも読める書き方を優先した方が良い時もある
何やってるか全部コメント部分に書くね…

このインターフェースってのわかりづらいんでif文ネストに書き直しておきました

>既存の企業はどうやって死なないようにしてるので…？
機能が増えるからクラスが増えるのは仕方ない
クラスを大きくしないように頑張る
依存関係を色々な手法で頑張って減らす

せめてswitchにして…
いやむしろパターンマッチにしてくれると

>>既存の企業はどうやって死なないようにしてるので…？
>機能が増えるからクラスが増えるのは仕方ない
>クラスを大きくしないように頑張る
>依存関係を色々な手法で頑張って減らす
これがSOLID原則だってことに最近気付いた

tsで型バトルしてる人たちが怖い
ていうか内包表記使えないの辛くない？

新卒の頃の先輩がelse ifやcaseを使わない人（elseをネストしてまたif elseして…）とforeachを知らない人だった
二人とも仕事はできたけどコードは書かないで欲しかった

依存関係は1方向にしよう！