Размер видео: 1280 X 720853 X 480640 X 360
Показать панель управления
Автовоспроизведение
Автоповтор
1つ目はラムダ式で level + (exp >= 100) を返せば簡潔に1行で書けますね。是非はともかくPythonではTrue, Falseはそれぞれ1, 0と等価なので。if文のなかでいきなり代入するのはPython特有の書き方ですね。宣言のある言語ではifの外で宣言しておく必要がありますし、ブロックスコープの概念もあります。
なるほどですね！色々な考え方があって面白いです！！
興味深い動画をいつもありがとうございます。再代入は引数がミュータブルかイミュータブルかを意識しておかないと、思わぬバグになりかねないので注意が必要ですね。
コメントありがとうございます😊再代入、ミュータブル・イミュータブルを意識してコーディングするのは大切ですね！！
サプーさんの動画は実務で参考になるヒントがいっぱいで、楽しみにしてます！今回のトピックは、日頃もやもやしていた部分、スッキリした気分です！ ありがたい！
ご視聴いただきありがとうございます！あえて結論を出さない動画なので微妙だったかな...って思っていたのですが、そう言ってもらえて嬉しいです！！
Python 未経験です。某ミノ駆動本にかぶれている箇所が多々ありますが、自分はこうなりました。①else文は不要。書くとしても再代入せず pass 文で書くべき。②正直、再代入は避けたい。③早期 return は必須。網羅性を言うのであれば空のelse文で書いてネストを浅くするべき。④型は明示してほしい。
サプーさん、いつもありがとうございます。美しい声質と話し方、そして明瞭で美しい日本語が子守唄に聞こえます。よく分からないことがあっても、何か楽しいな。聞いていて頭の良い人だなーと羨ましく思います。
ありがとうございます！！全然、頭が良いということはないのですが、分かりやすさを大切に動画作りしています😊
自分はelseは書く派ですが、そのうえで1つ目は何もしないならelse: passにしますね。何もないことを明示したいので。（次の問題に再利用する都合でこうなさったのだとは思いますが。）再代入とか型ヒントとかは本当は意識したほうがいいんだろうなと思いつつ、1人で研究用途に使ってるだけなので動けばいいや精神ですw
ご視聴いただきありがとうございます！色々な意見があって興味深いですね！
基本的にelse書かない派だけど書くならこれかなぁ
動けばいいやはだめだとサプーさんに怒られてるので動画見て頑張って勉強します！笑
過去にCOBOLをやってた時は、網羅的に書く事が多かったです。誰が見ても分かりやすいからという理由でしたが、今は営業職なので自分勝手に書いてます。Pythonはインタプリタだから少ないコードの方が処理が早い気がしますね🤔
言語やチーム開発・個人の趣味かどうかなどによっても書き方が違ってくるかもですね！
今まで再代入の考えは気にしたことなかったです。ありがとうございます。
再代入は一度気にしだすとすごく気になるようになります笑 考えのきっかけになれてたら嬉しいです！
タイプアノテーション昔付けてなかったけど今はガッチガチにつけてるなーVS Codeの補完がめっちゃ便利になる！
分かります！！タイプアノテーションは私も初めは面倒くさがって付けてなかったのですが、一度使ってみると便利じゃん！って思って常に付けるようになってました笑
現在大学でパイソンを使っています。そのため、たくさん動画を視聴させてもらっています。わかりやすい動画で参考になっています！これからもお体に気を付けて動画投稿頑張ってください！微力ながら応援しています！！
大学のプログラミング授業でPythonを使っているのですかね！すごいです！！ありがとうございます😊少しでもお役に立てていたら嬉しいです！
@@pythonvtuber9917 律儀に返信ありがとうございます！授業で利用しています！
こういうとこは自然言語も同じですね、文脈が明確なら省略された物言いでも伝わるけど、そうでなければ事細かに説明しないと食い違いが起きてしまう開発に関わるメンバー人数や、SWの更新サイクルによっても答えは変わってきそう
そうですね！メンバーの人数・入れ替え頻度、組織の文化も含めて色々な要因でベストものは変わってきそうですね！
こういうのって新人時代にどんなコードを刷り込まれたかで分岐しますね。。。網羅的なコードはいいと思いますが、たくさんのコードを書いてるとその精神を貫けなくなるのでやっても良いけどまぁ、頑張れ！って感じです。再代入はやめておいた方が他の言語に行ったときに変な癖にならないし、同じ変数に対しての処理が散らかるとバグ対応が大変になります。よくあるステータスというアチコチで参照される変数でそれやるとバグりやすい。逆にマスキング処理やフィルター処理などのクレンジング処理では再代入した方がコードがスッキリしてかつ処理が集約されるので、やったほうがいいケースもありますね。型を明示するかって件についてもやっておいた方が他の言語へ移った時のショックが少ないし、エディタ補完が楽になるっていのもあるのでやっておいた方がいいですが、網羅的なコードと同じく沢山のコードを書いてるとその精神が貫けなくなりますね。なのでユーティリティのような目的がわかりやすいコードは省略して型が重要になりそうなモデルクラスには書くといったルールにするとまだらなコードにならなくて済みますね。なのでどっちか統一というより適材適所で手を抜くのが良いという結論ですが、どっちか決めないとヤダっていう勢力の時は仕方なく決めてます。。。
コメントありがとうございます！色々な考えがあって面白いですね！！
今度Python認定実践試験受けます！サプーさんの動画参考にします！
認定試験すごいです！！うまくいくよう応援しています😊
@@pythonvtuber9917 ありがとうございます😭動画ほんとに参考になります！
C++から移行した私の場合網羅的なのは書かない再代入は呼び出し元の変数を書き換えるので意図的にやる場合以外は避ける早期リターンはネストが嫌なので多用型ヒントは大体付ける。python登場当初は型もclassもなくて手が出せませんでしたが、年々C++に近づいてきて、便利な機能以外は使えるようになってきました。
～個人的な回答～1つ目・3つ目：docstringに書く か should_level_up(exp: int, th: int = 100) -> boolを定義してelseブロックを省略。書く量はむしろ増えるが、コードが見やすくなる。4つ目：結局代入する型や役割を間違えると使い物にならないので書く。また、戻り値のクラスを明示しておくと an_inst = build_an_inst() のような代入でエディタがan_instのメンバをサジェストしてくれることがある。静的型付けのすべてを知っているわけではないけれどan_inst: AClass = ...としなくてもこれができるのは強み。一方で代入時のアノテーションはエディタがクラスを判別不可能な場合を除いて省略。2つ目：難しい。必要に応じて使う。破壊的にはならないようにする。今回の例ならnew_levelを用意する派。
個人的な回答ありがとうございます！色々な考えがあって面白いです！！
「バグの温床を出来るだけ減らす」ポリシーで良いと思います。おっしゃる通りタイプアノテーションするくらいならnimとか使います。
確かにポリシーを決めていれば、どっちの方がバグが発生しないか？って考えやすくていいですね！
とても勉強になりました。2つ目の再代入を許すべきかどうかという議論の存在を初めて知りました。1つ目の問題は、様々な言語の掲示板で目にします。私はelseを書きません。しかし、人数の多いプロジェクトによっては、書いたほうが良いということにもなりました。3つ目のreturnは、私も使います。追跡する必要のない処理を早めに潰しておいたほうが、読みやすく不具合の混入が少ないと経験的に感じています。4つ目について、これも不具合の発生を防ぐ意味で使うことになりました。
ご視聴いただきありがとうございます！そうですね、掲示板やTwitterなどでも度々議論になっていますね！何を重視するかでどっちを取るかが決まるって感じですかね！
いつも解説して頂きありがとうございます！毎日勉強させてもらってます！現在PythonモジュールのKivyの勉強してます！Kivyをつかってアプリ開発についての解説をしていただければ嬉しいです！！！よろしくお願いします！！！
kivyのご要望ですね！ありがとうございます、検討してみますね！
型アノテーションを書かないのはあり得ない選択肢ですねアノテーションをつけるっていう簡単な作業だけで型に関する実行時エラーを大幅に減らせるんで、テスト工程まで考えれば全体の時間を大幅に削減できます型を書かない方が面倒くさいです
各問題で比較されていたコードはどちらが正しいではないにしても、サプーさんの観測範囲内でどちらの書き方が多いのかは気になった
どっちの書き方が多いかを言うと、そっちの方が正しいかのように受け取られかねないので控えさせてもらいました！
関数の引数にタイプアノテーションつけないとIDEのインテリセンスが効かなくて、フィールドやメソッドのアクセスがダルい。あとは保守性から考えても型付け派だなー
そうですね！私もPythonでタイプアノテーション使う派です！でも使いたくない派の人の気持ちも分かります笑
コードにコメントをちゃんと書くと大抵は解決しそうですが、後からコメントを書くのって面倒いですよね
そうですね、コメントがたくさんあるコードは読みにくいですしね...😵
処理とコメントが矛盾すると読んだ人は地獄。
写経動画をあげていただけると助かります。
検討してみますね！
2つ目の再代入が嫌なら定数でいいじゃない！と思ったけどPythonって定数をサポートしていないんですねｗ
そうなんです！言語仕様として再代入が不可能な定数として扱えるようなものはサポートしてないんです...
言われてみれば。C++では「書けるところには出来るだけconstを書こう」と書いてある本を読んだことがあります。
早期リターンにelseつけたらメリット台無しやん…と思ってしまう
早期リターンだと人間が考えるべき範囲も絞られるので読みやすいと思います。
아무래도 짧은 코드가 좋아.. 연산 사이클 아낄 수 있으니깐..
코멘트 감사합니다. 나도.
1つ目はラムダ式で level + (exp >= 100) を返せば簡潔に1行で書けますね。
是非はともかくPythonではTrue, Falseはそれぞれ1, 0と等価なので。
if文のなかでいきなり代入するのはPython特有の書き方ですね。宣言のある言語ではifの外で宣言しておく必要がありますし、ブロックスコープの概念もあります。
なるほどですね！色々な考え方があって面白いです！！
興味深い動画をいつもありがとうございます。
再代入は引数がミュータブルかイミュータブルかを意識しておかないと、思わぬバグになりかねないので注意が必要ですね。
コメントありがとうございます😊
再代入、ミュータブル・イミュータブルを意識してコーディングするのは大切ですね！！
サプーさんの動画は実務で参考になるヒントがいっぱいで、楽しみにしてます！
今回のトピックは、日頃もやもやしていた部分、スッキリした気分です！ ありがたい！
ご視聴いただきありがとうございます！
あえて結論を出さない動画なので微妙だったかな...って思っていたのですが、そう言ってもらえて嬉しいです！！
Python 未経験です。某ミノ駆動本にかぶれている箇所が多々ありますが、自分はこうなりました。
①else文は不要。書くとしても再代入せず pass 文で書くべき。
②正直、再代入は避けたい。
③早期 return は必須。網羅性を言うのであれば空のelse文で書いてネストを浅くするべき。
④型は明示してほしい。
サプーさん、いつもありがとうございます。
美しい声質と話し方、そして明瞭で美しい日本語が子守唄に聞こえます。よく分からないことがあっても、何か楽しいな。聞いていて頭の良い人だなーと羨ましく思います。
ありがとうございます！！全然、頭が良いということはないのですが、分かりやすさを大切に動画作りしています😊
自分はelseは書く派ですが、そのうえで1つ目は何もしないならelse: passにしますね。何もないことを明示したいので。
（次の問題に再利用する都合でこうなさったのだとは思いますが。）
再代入とか型ヒントとかは本当は意識したほうがいいんだろうなと思いつつ、1人で研究用途に使ってるだけなので動けばいいや精神ですw
ご視聴いただきありがとうございます！色々な意見があって興味深いですね！
基本的にelse書かない派だけど書くならこれかなぁ
動けばいいやはだめだとサプーさんに怒られてるので動画見て頑張って勉強します！笑
過去にCOBOLをやってた時は、網羅的に書く事が多かったです。誰が見ても分かりやすいからという理由でしたが、今は営業職なので自分勝手に書いてます。
Pythonはインタプリタだから少ないコードの方が処理が早い気がしますね🤔
言語やチーム開発・個人の趣味かどうかなどによっても書き方が違ってくるかもですね！
今まで再代入の考えは気にしたことなかったです。ありがとうございます。
再代入は一度気にしだすとすごく気になるようになります笑
考えのきっかけになれてたら嬉しいです！
タイプアノテーション昔付けてなかったけど今はガッチガチにつけてるなー
VS Codeの補完がめっちゃ便利になる！
分かります！！タイプアノテーションは私も初めは面倒くさがって付けてなかったのですが、一度使ってみると便利じゃん！って思って常に付けるようになってました笑
現在大学でパイソンを使っています。そのため、たくさん動画を視聴させてもらっています。わかりやすい動画で参考になっています！これからもお体に気を付けて動画投稿頑張ってください！微力ながら応援しています！！
大学のプログラミング授業でPythonを使っているのですかね！すごいです！！
ありがとうございます😊少しでもお役に立てていたら嬉しいです！
@@pythonvtuber9917 律儀に返信ありがとうございます！授業で利用しています！
こういうとこは自然言語も同じですね、文脈が明確なら省略された物言いでも伝わるけど、そうでなければ事細かに説明しないと食い違いが起きてしまう
開発に関わるメンバー人数や、SWの更新サイクルによっても答えは変わってきそう
そうですね！メンバーの人数・入れ替え頻度、組織の文化も含めて色々な要因でベストものは変わってきそうですね！
こういうのって新人時代にどんなコードを刷り込まれたかで分岐しますね。。。
網羅的なコードはいいと思いますが、たくさんのコードを書いてるとその精神を貫けなくなるのでやっても良いけどまぁ、頑張れ！って感じです。
再代入はやめておいた方が他の言語に行ったときに変な癖にならないし、同じ変数に対しての処理が散らかるとバグ対応が大変になります。
よくあるステータスというアチコチで参照される変数でそれやるとバグりやすい。
逆にマスキング処理やフィルター処理などのクレンジング処理では再代入した方がコードがスッキリしてかつ処理が集約されるので、やったほうがいいケースもありますね。
型を明示するかって件についてもやっておいた方が他の言語へ移った時のショックが少ないし、エディタ補完が楽になるっていのもあるのでやっておいた方がいいですが、網羅的なコードと同じく沢山のコードを書いてるとその精神が貫けなくなりますね。
なのでユーティリティのような目的がわかりやすいコードは省略して型が重要になりそうなモデルクラスには書くといったルールにするとまだらなコードにならなくて済みますね。
なのでどっちか統一というより適材適所で手を抜くのが良いという結論ですが、どっちか決めないとヤダっていう勢力の時は仕方なく決めてます。。。
コメントありがとうございます！色々な考えがあって面白いですね！！
今度Python認定実践試験受けます！
サプーさんの動画参考にします！
認定試験すごいです！！うまくいくよう応援しています😊
@@pythonvtuber9917
ありがとうございます😭
動画ほんとに参考になります！
C++から移行した私の場合
網羅的なのは書かない
再代入は呼び出し元の変数を書き換えるので意図的にやる場合以外は避ける
早期リターンはネストが嫌なので多用
型ヒントは大体付ける。
python登場当初は型もclassもなくて手が出せませんでしたが、年々C++に近づいてきて、便利な機能以外は使えるようになってきました。
～個人的な回答～
1つ目・3つ目：docstringに書く か should_level_up(exp: int, th: int = 100) -> boolを定義してelseブロックを省略。書く量はむしろ増えるが、コードが見やすくなる。
4つ目：結局代入する型や役割を間違えると使い物にならないので書く。また、戻り値のクラスを明示しておくと an_inst = build_an_inst() のような代入でエディタがan_instのメンバをサジェストしてくれることがある。静的型付けのすべてを知っているわけではないけれどan_inst: AClass = ...としなくてもこれができるのは強み。一方で代入時のアノテーションはエディタがクラスを判別不可能な場合を除いて省略。
2つ目：難しい。必要に応じて使う。破壊的にはならないようにする。今回の例ならnew_levelを用意する派。
個人的な回答ありがとうございます！色々な考えがあって面白いです！！
「バグの温床を出来るだけ減らす」ポリシーで良いと思います。おっしゃる通りタイプアノテーションするくらいならnimとか使います。
確かにポリシーを決めていれば、どっちの方がバグが発生しないか？って考えやすくていいですね！
とても勉強になりました。2つ目の再代入を許すべきかどうかという議論の存在を初めて知りました。1つ目の問題は、様々な言語の掲示板で目にします。私はelseを書きません。しかし、人数の多いプロジェクトによっては、書いたほうが良いということにもなりました。3つ目のreturnは、私も使います。追跡する必要のない処理を早めに潰しておいたほうが、読みやすく不具合の混入が少ないと経験的に感じています。4つ目について、これも不具合の発生を防ぐ意味で使うことになりました。
ご視聴いただきありがとうございます！
そうですね、掲示板やTwitterなどでも度々議論になっていますね！何を重視するかでどっちを取るかが決まるって感じですかね！
いつも解説して頂きありがとうございます！毎日勉強させてもらってます！
現在PythonモジュールのKivyの勉強してます！Kivyをつかってアプリ開発についての解説をしていただければ嬉しいです！！！
よろしくお願いします！！！
kivyのご要望ですね！ありがとうございます、検討してみますね！
型アノテーションを書かないのはあり得ない選択肢ですね
アノテーションをつけるっていう簡単な作業だけで型に関する実行時エラーを大幅に減らせるんで、テスト工程まで考えれば全体の時間を大幅に削減できます
型を書かない方が面倒くさいです
各問題で比較されていたコードはどちらが正しいではないにしても、サプーさんの観測範囲内でどちらの書き方が多いのかは気になった
どっちの書き方が多いかを言うと、そっちの方が正しいかのように受け取られかねないので控えさせてもらいました！
関数の引数にタイプアノテーションつけないとIDEのインテリセンスが効かなくて、フィールドやメソッドのアクセスがダルい。あとは保守性から考えても型付け派だなー
そうですね！私もPythonでタイプアノテーション使う派です！でも使いたくない派の人の気持ちも分かります笑
コードにコメントをちゃんと書くと大抵は解決しそうですが、後からコメントを書くのって面倒いですよね
そうですね、コメントがたくさんあるコードは読みにくいですしね...😵
処理とコメントが矛盾すると読んだ人は地獄。
写経動画をあげていただけると助かります。
検討してみますね！
2つ目の再代入が嫌なら定数でいいじゃない！と思ったけどPythonって定数をサポートしていないんですねｗ
そうなんです！言語仕様として再代入が不可能な定数として扱えるようなものはサポートしてないんです...
言われてみれば。
C++では「書けるところには出来るだけconstを書こう」と書いてある本を読んだことがあります。
早期リターンにelseつけたらメリット台無しやん…
と思ってしまう
早期リターンだと人間が考えるべき範囲も絞られるので読みやすいと思います。
아무래도 짧은 코드가 좋아.. 연산 사이클 아낄 수 있으니깐..
코멘트 감사합니다. 나도.