【初心者向け】クソコードを書かないためのテクニック5選

Рет қаралды 98,988

Жыл бұрын

動画内の変数名の表記で "culc" と表記されている部分がいくつかありますが、
正しくは "calculation"(計算) の意味である "calc" となります。誤字があり申し訳ございません。
【エンジニアチャンネル公式Twitter】
/ engr_channel
【小川 Twitter】
/ ogaaryo
【粟島 Twitter】
/ masayan0911
【前田 Twitter】
/ shinnosuke_324
-----------------------------------------------------------------------
プロフィール
-----------------------------------------------------------------------
■エンジニアチャンネル
✅IT業界の裏事情・オフレコトーク ✅転職・就職・キャリア戦略 ✅効率的な学習方法を中心に「エンジニアになりたい方」や「IT業界で成長したい方」に向けた情報を発信しています。
■小川亮(おがわりょう)
株式会社エンジニアチャンネル代表取締役社長
ベンチャー企業の取締役CTOとして組織・サービス両面のリーダーとして活動後、フリーランスを経て起業。
プログラミング学習、転職・就職・キャリア戦略などの豊富な相談実績に基づき今日から使えるハウツーを発信。
■粟島正俊(あわしままさとし)
株式会社テックファクトリー代表取締役社長
エンジニアとしてキャリアをスタート。ベンチャー企業のCTOとしてサービス開発全般を行う。
フリーランスを経て、株式会社テックファクトリーを起業。自社サービスで稼ぐプロとして、エンジニアとビジネスの観点を織り交ぜて発信。

Пікірлер: 161

@lagavulin1968 Жыл бұрын

素晴らしい企画でとても勉強になりました。是非、継続してほしい企画です！！

@user-pc7gk1vu7p Жыл бұрын

この企画すごい良い笑続編期待

@tsukumon. Жыл бұрын

冗長性はわかりやすさとどう両立すればいいか、引っかかってたので勉強になりましたありがとうございます

@mokemoke768 Жыл бұрын

4:04 推測ですが、この関数は 0 を渡したら0が返ってきた方が便利だと思います。売数もしくは売価が0なら売上0円が返った方が便利でしょう。nil が返ってきたら呼び出し側が nil チェックをする必要が生じます。つまり4,5行目は削除したい。逆に、入力としてnil が渡されていないかのチェックに書き換えるのであれば有用性はあります。

@satoshi3851 Жыл бұрын

めっちゃ勉強になります！ありがとうございます！

@marx_d_24 Жыл бұрын

ざっくりまとめ・関数名はその中身の処理がわかる名前にする・変数名はその中身だけでなく型もわかる名前にする・余計な変数は作らない・マジックナンバーは使わない・エラー処理も書いておく・if文で「==true」の処理はいらないプログラミングは基本的にチームで行っていくものなのでただコードを書くだけじゃなくて伝わるコードを書くということが大事ですね。

@shusugai Жыл бұрын

@アップハンズ全くもってその通りですね。コードを修正してコメントを修正し忘れたらつまらぬ事で悩む羽目に、、リーダブルコードはどんな言語を使う人でも必読書ですね。

@user-nu2ev3se6e Жыл бұрын

コードレビューを観れるのめっちゃありがたいです！勉強になりました！

@user-qj5em2fq5v Жыл бұрын

めっちゃ勉強になります！

@techitechi003 6 күн бұрын

勉強になりました！！✨

@toopo888 Жыл бұрын

これ最高の企画じゃないですか💡

@user-sz9bo7dv3h Жыл бұрын

とても勉強になりました。第二回開催お願いします

@user-nr8de2vx2g Жыл бұрын

最後の答えが「return文をつける」だと思ってしまって草

@TL-ip3tl Жыл бұрын

思った「これ比較しとるだけで何も返らんやん」って思ってしまったら違ったのかw

@hoge_hoge Жыл бұрын

@@TL-ip3tl コードを省略したら、考えさせられるコードが出来上がるというのは「本当に良いコードなのかな？？」って最近思います。（型定義の省略とかも、どうなんですかね。。）下手したら、保守性の低下を招く可能性もあるかと。。（コーディングした人とメンテする人が、同程度のスキルなら大丈夫だとは思いますが）

@user-ge6pn5bc4f Жыл бұрын

変数名って、複数人で開発する際は非常に大事になるんですね。個人で開発しているだけなので、全然気にしていませんでした。

@user-cs4mn5ds3q Жыл бұрын

面白い動画でした。個人的には、問4でDISCOUNT_PRICEを定数で定義するのはアリなのかとか、問5でチャンネル数を見るためだけにDBアクセスが必要なのかとか、仕様部分が気になってしまいました。仕様設計も考慮すると、コードレビューがより複雑になりそうです。

@DDD-ht6zs Жыл бұрын

新卒の子にこれは見た方が良いとお薦めしてます。いつもためになる動画で勉強になります

@takuyaoda Жыл бұрын

小川さんに答えられる前に、停止して改善点を考える事ができて、面白い企画だった！最後の問題5のヒントとか、コード内にコメントで記載していただいてると助かったかなと思いました！

@10A.Official.YT.account Жыл бұрын

まじで助かります!

@yoshiki6375 Жыл бұрын

いつも楽しく動画見させていただいています。単純に疑問がありました。関数の引数のところが"data"とか"user"とか、多分オブジェクトが入ると思うんです。でもそれって外部から見てどんなクラスのオブジェクトを入れたらいいか分かりにくくないのでしょうか？要するに型がよくわからないといいますか…この思考はC言語系ユーザ特有かも知れませんが。

@user-gd2cg9sz6k Жыл бұрын

めちゃためになる〜

@user-fg9pg1ve4t Жыл бұрын

この企画面白い！！

@user-rm2fp5ik2x Жыл бұрын

楽しみながらコードレビューしてる、面白い企画だった。　次回企画があったら、これ関数にした方がよくない？　これクラス使ってよ＝みたいなコードレビューもみてみたいです。 nil や data.price.zeroの.zeroは　よく使われますか？　（.zeroは、普通の変数でもつかえるのかな？）はずかしながら初めてみました。

@user-kv5jz2cz7y Жыл бұрын

勉強になりました

@user-yu7qn3dm3z Жыл бұрын

C言語しか知らないけど、雰囲気で最後以外は正解できました。変数名や関数名を分かり易くするの大切ですね。続編見たいです。

@user-hf7ok2hf5q Жыл бұрын

コメント欄も含めて勉強になる

@ryonnkoch Жыл бұрын

2問目、dataオブジェクトを想定するんじゃなくて、引数をpriceとcountの2つにしたほうが処理の見通しがよく、再利用性が高い

@user-ss3ci1cn6d Жыл бұрын

ほんまこれ

@user-xr2uf6mp3o Жыл бұрын

2回目もやって欲しいです！

@bryk6189 Жыл бұрын

1問目のはwhereしてfirstするよりfind_byのほうが良さそうです updateもupdate!にしてこのメソッド自体にも!を付けて例外を吐くメソッドって知らせると親切ですね

@ryokutya2000 Жыл бұрын

最後の5問目 seleniumとかでデータ引っ張ってくる時、 findとfind_allで要素数とかちゃう時に変数名間違えたりしてたの思い出した

@notchnotty Жыл бұрын

3問目 is_mizuhoは無理に消さなくてもいいかなフラグの意図が明確になるし、デバッグログ出力したり、今後拡張するときに使い回したりする可能性もあるし

@thy_thy7 4 ай бұрын

yagni

@kitajii Жыл бұрын

7:12 if 6

@user-lj5dp2jj3d Жыл бұрын

Python以外でその比較ってできるの？

@anata_no_kansou Жыл бұрын

@@user-lj5dp2jj3d 逆にできない言語ってあるの？

@_mitawa5109 Жыл бұрын

@@anata_no_kansou (

@Gent-Owl Жыл бұрын

pythonでは同じ条件を「if 6

@MrTakusomikke Жыл бұрын

左オペランドに変数というのは、リーダブルコード的にも合ってますよ。

@Pacmania100 Жыл бұрын

プログラミング初期のあるあるですよねー。特にフラグや演算子の過剰な使い方は、まだ頭がプログラミング言語ベースの論理思考に完全移行できていなく、どこか電卓を使って計算している最中の様な心理や思考癖が残っているからなんでしょうね。

@24jojo8 Жыл бұрын

社内でコーディング規約とかあるので、何が正解かはそれぞれですね。私の会社だと、 •リターンに計算結果を直接返してはいけない。 •引数で持ってるものは一旦ローカルに落とし込むなどなど、、 Cメインなのでってのもありますが、、

@IamSuperLovely Жыл бұрын

これは楽しい

@watarukumagai6110 Жыл бұрын

12:40 初心者なので教えてほしいですが、"channel_list=....channels(channel_name); channel_list.count>0;"という書き方ですが、直接"....channels(channel_name).count>0;"はダメなんでしょうか？単にlistとして取得してからのほうが可読性の点でベターという感じでしょうか。

@washihatensaija Жыл бұрын

今の小中学生がプログラミング勉強してるみたいだけどこういう初歩的なこと教えるべきだよなちょっとした英単語の意味覚えるのにも役立つし

@sirokuma5963 Жыл бұрын

いまの小中学生はブロックプログラミングというコードを書かないでゲームを作るというのをやっているところがほとんどです。自分はコードでやった方がおもしろいし多くのことができると思うんですがねぇ（by 現役中学生）

@haruhibouEX0 Жыл бұрын

穴抜き問題やってるっていうのを見たわw

@user-jo7xh7sv7v Жыл бұрын

1問目　あるあるです。最初作ろうと思ったことなんだけど、ここでできちゃうなって思って色々追加するとこうなる

@nangakiya Жыл бұрын

3問目 if user.is_studentはユーザーデータのis_studentカラムを参照しているのでは？だから下のis_student関数は関係ないと思ったんだけどね。関係あるのであれば、if is_student(user)と書かなければいけない。

@haraoki4434 28 күн бұрын

今は人に見せるためでなく、５分後の自分へのプレゼントだと思いコメントやソースを修正してます。良い動画と感じました。結局、５分後の自分がつらいのですよね。。

@tanakataro372 Жыл бұрын

面白いから中級編もお願いします

@NONAME-qt9og Жыл бұрын

三脚使わずにカメラマン立たせてるのなんかおもろい

@04rinel64 Жыл бұрын

プロマネ向けの内容ですね！

@h.m.277 Жыл бұрын

youtube_channel_existsに関しては、「channel」という名前のチャンネルが存在するか調べたいとき、Trueしか返って来ないと思うけど、本当に「channel」という名前のチャンネルがあるかはわからない。だから配列の中に完全一致する文字列が含まれているかどうかまで調べるようにしたらいいと思う。あとAPIのメソッド名まで直せるなら、get_channel_namesにしたほうがstr型の配列が返ってくることが分かって健全。

@MegaGeek2 Жыл бұрын

この話いいね！

@304 Жыл бұрын

return を省略しているところとしていないところがあるけれど、何か理由があるのだろうか。

@100Gorilla Жыл бұрын

他の言語でもぜひやってほしい

@ak2channel Ай бұрын

「Rubyなのかな？」とは思うんだけど… return user.age >= 6 and user.age

@bluerose1412 Жыл бұрын

素人です。ここで使われている言語は何という言語なのでしょうか？

@renyskm Жыл бұрын

6:58 3問目は、ポリモーフィズムを利用するのはどうでしょうか？ Rubyを知らないので、文法は適当で書きます。 Bankインターフェースにtransferメソッドを定義して作成。 NormalBankクラスとMizuhoBankクラスを作成。 Bankインターフェースをそれぞれのクラスにインプリメンツし、transferメソッドに具体的な処理を実装。 bank_transferメソッドの最初に、mapで [MIZUHO_BANK_CODE => MizuhoBankクラスのインスタンス, NORMAL_BANK_CODE => NormalBankクラスのインスタンス] みたいに定数とインスタンスのマッピングを作成しておく。あとは、処理実行時にmapから取り出したインスタンスを、Bank型の変数に代入し、変数.transfer()を実行。これで、どれだけバンクの種類が増えてもif文がないコードになりますがどうでしょうか？

@renyskm Жыл бұрын

↑のような考え方はどうでしょう？どなたか感想いただきたいです。

@mokemoke768 Жыл бұрын

一般論としてはいいデザインだと思います。

@renyskm Жыл бұрын

@@mokemoke768 ご返信ありがとうございます。自信が持てました。ポリモーフィズムの使いこなしは難しいですが、うまく使えばきれいなコードになりますね。

@ryo8212 Жыл бұрын

自分もBankインターフェース使った方がいいと思いました

@mse121 Жыл бұрын

bankのやつは通常処理なのかを判定するメソッドがあると、呼び出し側がコードに対する知識を持たないのでいいと思う

@Gent-Owl Жыл бұрын

3問目、コードを確かめる必要があるなら拡張性を意識してswitch文にするかもです。銀行のコードが1つだけとは思えないので。 5問目、個人的にはchannelsの結果をnullチェックしたくなりますね。必要ない言語とか、絶対に最低でも空配列取得とかだったら良いんですが

@user-yj2ub4sw8p Жыл бұрын

三問目はそもそも　user.bahk にexecute_transfer を生やしたいですね。 bankがcodeをもってるなら内部で判別すれば良い気がします。

@Gent-Owl Жыл бұрын

@@user-yj2ub4sw8p いやいや、userが持ってるbank情報にexecute_transfer(振り込み実行)なんて機能持たせてはダメかと……

@es-vf8du Жыл бұрын

銀行コードが増える度に分岐が増えるのでメソッドの肥大化が免れない実装には変わりなさそうです可能であればFactory MethodパターンやStorategyパターンなどを用いて条件分岐を消す方向で実装したく思いました

@user-yj2ub4sw8p Жыл бұрын

@@Gent-Owl ちなみにその場合execute_transfer はどんなクラスに持たせますか？

@Gent-Owl Жыл бұрын

@@user-yj2ub4sw8p user.bankってクラスで表すとしたらユーザーそれぞれが持つ銀行の情報ってことで「UserBankInfo」とかになると思うんですよ。となればそれを呼び出して使う側、振り込みを実行する側、と考えると「Bank」クラスや「Atm」クラスのようなものではないですかね。そこはどんなシステムに乗せるのか次第でしょうか。

@pastmemories0115 Жыл бұрын

4:30の問題、そもそも入力が構造の時点で中身の計算が分からないから、priceとcount で入れた方がわかりやすい。後もっと言うなら、税率をかけるんだから、税込価格を計算するという関数名にすべき。

@KS-517 Жыл бұрын

またやって欲しい

@user-kz9wl4rs5c Жыл бұрын

2問目の引数にあるdataは、priceとcountでそれぞれ受け取りたいなとも思いました。dataというデータ構造に依存しすぎている？かなぁ。まぁ好みの問題ですね。

@otanoshimi4 Жыл бұрын

何言語か全く判らないのですが、２問目、今は１０％とか８％とかあるので、関数名calc_amount_price_with_tax(data,tax_rate)とかいかがでしょうか？

@e3chicago Жыл бұрын

できれば *_price_after_tax とかがいい。普通に英語で after tax や before tax って言うから。

@user-md4sh8wt7x Жыл бұрын

問2でcount=0でエラーって言ってるけど、除算じゃないからエラーにならないよね？

@onme4780 Жыл бұрын

前にdictionaryなのにxxListって命名して、先輩に騙したなって言われたの思い出した笑

@darakusho Жыл бұрын

2問目は関数内で値が0のチェックはしたくない派

@hagehagehage Жыл бұрын

1問目、Userのis_paid_memberが冗長で、paidでいいんじゃないのと思いましたw 2問目、calc_amount_priceになにか副作用があるわけじゃないのだから動詞を使わず単に amount_price あるいは amount でよい気がします。 4問目のreturnは、動画中で軽く触れられていますが全部省けます。これはポリシーにもよりますね。私なら全部省いちゃいます。以上、細かい点ですし全部ポリシーによることなので必ずしも間違っているとか良くないというわけではないです。こういうことが書かれた本って40年以上前のカーニハンの「プログラム書法」とかwriting solid codeくらいしか知らないけど、現代だともっといい本あるんすかね。

@shima01134 Ай бұрын

rubyなんですかね？初めて見たけど、Pythonっぽいんですね。最後のはrubyではよくあるのかわからないけど、関数名に？があるのが違和感でした

@yoshito323 Жыл бұрын

8:40で消えたけど、修正前の11行目のインデントが揃ってなかった。

@poypoyh4413 Жыл бұрын

1.1ってそういうことか！

@neil9444 7 ай бұрын

クソコードとかそういう言葉遣いが面白いと思ってる業界の雰囲気が怖い

@user-rt3id1dh3b Жыл бұрын

問2、価格と個数0でもエラー起きなくないですか？Rubyだと起きるんですかね。 TAX_RATEが少数なので切り捨てか切り上げも必要ですね。実際には消費税のみの表示も必要になるので、消費税計算関数を別途作ってこの関数内では税抜き累計に消費税を足すという処理のほうが後々楽です。あと個数0でエラーにするかどうかの判断は、この関数ではなく別の関数でやるべきでは。データオブジェクトのインターフェースで定義できてしまえば楽ですね。ついでに実際にはおまけ商品なんかもなくはないので、価格0は許容してもよさそう。クーポンの実装によっては価格マイナスもなくはないので0をエラー出すならマイナスも考慮しなくてはいけないような。

@shusugai Жыл бұрын

動画内では消費税だとは言ってないけど税率計算は厄介ですね。確かに消費税をかけてからクーポン100円とか値引きしてはいけないし、様々なキャッシュレス決済のポイント値引きやキャンペーンを考慮すると消費税計算は最後の最後にしなければならない。地代家賃に消費税はかからない。宗教法人やNPO法人の収入も消費税はかからない。消費税以外も考慮するとありとあらゆる税率計算は全て別々に関数を用意して掛ける順序も複雑。無料で客に渡すものでも在庫管理のためにレシートに0円表示が必要で在庫は帳簿上の資産として個数管理が必要ですね。

@I-Love-yon-so-lets-go-to_bed 3 күн бұрын

まぁ要するにリーダブルコードを読めと言う結論ですね

@user-wp1zt5uh6z Жыл бұрын

==trueは1番ナシな書き方。かと言って「！」演算子の有無で判断するのはあまり可読性高いとは言えない。1文字しか違わないから。個人的な最適解は「==false」のようにfalseの時だけ==をつけるかな 7文字(スペース込みだと9文字)多いか少ないかだと絶対に見分け着くから

@keng2024 Жыл бұрын

1問目 0:30 def update_user_paid_member_by_uid(uid) user = User.find_by(uid: uid) if(user.present?) return user.update(is_paid_number: true) // update!の方が良いかも // elseの処理も必要になりそう end end 2問目 2:03 TAX_RATE = 1.1 def calc_amount_price(price, count) // dataで受け取るんじゃなくてpriceとcountに分けて受け取ったほうが良さそう return price * count * TAX_RATE end 3問目 4:35 MIZUHO_BANK_CODE = '0001' def bank_transfer(user) // userのbank, bankのcodeが必ずある前提 // ない場合もあるなら&.使うなりtry使うなり変数に代入してnilチェックするなり // なんでもかんでも.でつなげるのもよくない場合がある if user.bank.code == MIZUHO_BANK_CODE mizuho_bank_transfer(user) else normal_bank_transfer(user) end end 4問目 7:08 // 個人的には真偽値を返すならstudent?とかstudent_age?とか?で終わる関数名の方が好き // 2問目と同じく年齢を確認するだけならageで受け取るほうがいいかも def is_student(user) return 6

@dmdm4494 Жыл бұрын

モブプロやね

@tadashifujinaga Жыл бұрын

Bルームなんすねー

@druggggg_anya Жыл бұрын

2問目、1.1 は消費税ですがでは軽減税率の場合は0.8 なので、そもそも TAX をDI できた方が良いかなと思います。あと price と count を引数にとるようにする方が data とか言う謎のオブジェクトを作らないで済む後者に関しては TypeScript であれば function calc(data: {price: number, count: number}): number のように実装しますが Python のシンタックスに明るくないための感想です関数名にしてもcalc → calc_amount_price は伸びただけでどのように使うのかがあまりピンとこないですね、やりたい事は税込価格の計算なので get_total_price などが妥当かなと思います(totalと言う変数を使うのはこのデータをGAなどに送る場合、大体税込価格のことをGAがtotalと呼ぶことからきています)

@jajathree9506 Жыл бұрын

5問目のpython のdef の　関数宣言に ? を使えるのが気になりました。 def youtube_channel_exist ？

@mokemoke768 Жыл бұрын

PythonではなくてRubyです。Rubyでは使えます

@jajathree9506 Жыл бұрын

@@mokemoke768 ありがとう。そうでしたか。勉強になります。

@Yu-jx1xd Жыл бұрын

宗教色が強い動画やなあ

@user-ck1ex2lz5s 7 ай бұрын

2問目の引数は dataはだめでしょ。品物を示す名前にしないといけない。　あと、型指定もしてあげないとだめ。

@jajasuke4942 Жыл бұрын

これってなんの言語なんですか？ruby？

@user-td5pw4cz5q Жыл бұрын

==trueはいらないけど、別に見にくくもないから残してる

@dangomushi983 27 күн бұрын

全体として引数のアノテーションがないのがやはり気持ち悪いw

@user-mm1oi8rp9o 2 ай бұрын

最後のやつは exist = channels.count > 0 return exits にしなさい

@nangakiya Жыл бұрын

1問目って、もう一点書くと、is_paid_memberがtrueの状態でuserデータ返ってこないよね。アップデートする前に取得したuserデータだから。そもそもこれは何の言語だろう、rubyかな。

@takukunita4968 Жыл бұрын

ActiveRecord（ORマッパー）のupdateメソッドはオブジェクトの値を破壊的に変えちゃうのでuserが返ってきます

@user-uv9fm9oy6e Жыл бұрын

(問2) 回答の括弧不要じゃないの?

@applepi314root Жыл бұрын

サムネの件、1.1ってなんだァｧ!!!!! (今から視聴)

@nangakiya Жыл бұрын

基本的にif elseでいずれもreturnするときはelseは不要。いつも下のように書いている。 if (条件) 　return 値1 end return 値2

@kino785 Жыл бұрын

その行数の節約いる？

@user-kb9nk6zo5q Жыл бұрын

アーリーリターンの亜種？バリデーションみたいに上から順に引っかかったらfalse返す、一連の前処理終わったら本処理を書くならありですが、ただ単に分岐でreturnするだけならreturn一行もしくはきちんとelseも囲む方がいい気がします。他の人が保守するときにはendの後ろにコード書けちゃう余地があるので混乱するかも。。

@nangakiya Жыл бұрын

@@user-kb9nk6zo5q プログラミング全体の話として、なるべくコード量を減らしたほうがミスをするリスクを減らせるし処理も早くなるので個人的にはこのほうがいいと思っています。保守をするときに関数の中を見て、if elseの中でreturnされているほうが、一瞬コード書けちゃう余地があるように見受けられませんか？関数の最後がifのendよりreturnで終わってるほうがスッキリして見えます。

@user-kb9nk6zo5q Жыл бұрын

@@nangakiya 確かにifの終わりで関数が終わっているのは私も好みではないです。ただ、真偽で別々の処理が入る場合はやはりelseで囲む方が見通しがよいように思います（if elseの2つの分岐であることが構造から明らかになるので）。実際には処理の目的や規模によって書き方を変えます。もちろん大規模になればコーディング規約作りますが、その時は結構悩みますね。。

@nangakiya Жыл бұрын

@@user-kb9nk6zo5q もう一点として、ifの中でreturnをしてる時点で、そのあとの処理はifの条件に引っかからなかった場合の処理ということがわかるので、わざわざelseを書く必要はないかと思いました。

@user-ff9un5zb6x Жыл бұрын

色々言いたいことあるけど、まず最初に何の言語かハッキリ説明した方がいい。今回の問題は、意図的に短いコードとして切り取ったのかもしれないけど、1〜2行程度で済むなら下手に関数を分割しない方が見やすいと思う。5問目なんか特に、書きかけのコードで続きを書き忘れたのかと思った。他に指摘するとすれば、 1問目 userとUserが混在してて紛らわしい。 2問目値が適正かどうかは、dataに値を格納する段階でやっておくべきことだし、勝手に0を不正な値と決めつけるのはおかしい。(例：サービス品等で価格0になっている場合や、数量0を明示的に表示する必要がある場合) 消費税率を掛けるなら、円未満の端数処理を何もしないのはおかしいし、一律10％でいいのか、8％の商品や非課税の商品が混在する可能性がないか、よく確認しとかないと後でフラグ判定の追加に悩んだり、商品データの構造の見直しが発生したりとか、修正が大変なことになる。 4問目学生証の有無じゃなく年齢で判定してるのに、studentはおかしい。(特に大学生とか) 多分、大人料金と子供料金の区別をしたいんだろうけど、5歳以下の幼児料金が定義されてなくてNOMAL_PRICEになるのはおかしい。無駄に関数を分割したせいでバグを見落とす典型例だと思う。あと、この言語の仕様詳しくないけど、本当にこの書き方でis_student呼び出せるのかな？

@takukunita4968 Жыл бұрын

userは変数で、Userクラスのインスタンスのようなものが参照されています全体的に同意なのですが、初級者向けの動画なので大枠の指摘中心だと思いました（感想）

@user-ed6fp1qj1v Жыл бұрын

pythonのコード読むの苦手なんだよな

@furusatonotkokyou Жыл бұрын

同じく… みんなが結構読みやすいのだと何になるだろ、C/C++かJavaあたり？

@user-vc1bt6uy5e Жыл бұрын

声がヨビノリ

@mng6501 Жыл бұрын

これ言語なんですか？

@Nijist5_BR Жыл бұрын

2:26 字幕「culc_price」ではなくて「calc_price」にすべき　ｗ　。次の「culc_amount_price」も同様😅 9:54 is_student()が不要で　2行目に　if(user.age >=6 and user.age

@user-yj2ub4sw8p Жыл бұрын

後者はダメですね。メソッド名の是非はさておき、年齢確認をするロジックが分散するので、Userインスタンスなどの特定のクラスやインスタンスにまとめたいです。（もしくは他の仕様クラスなど）

@Nijist5_BR Жыл бұрын

@@user-yj2ub4sw8p 回答ありがとうございます。参考になりました。２箇所以上で「6歳以上18歳以下」を判定する箇所があることを想定してるのですね。

@user-fr3wp9ch9m Жыл бұрын

関心の分離・細分化的に、is_studentメソッドは欲しい。1度しか呼ばれないとかだったら直で書いてもいいと思うが、行数が少ない=素晴らしいコードではない。

@Nijist5_BR Жыл бұрын

@@user-fr3wp9ch9m 回答ありがとうございます。実際のコードで２回以上呼ばれるなら　私もis_studentメソッド作りますね。　クイズ形式で１回しかでてこなかったのでチョットそこの判断がわからなかったです。「行数が少ない=素晴らしいコードではない」こちら覚えておきます。

@Takuu- Жыл бұрын

@@Nijist5_BR この問題だと仕様(前提条件)が提示されていないので、関数化する必要ないんじゃね？って私もレビューで言っちゃうと思いますw

@UNITY-CONFLICT Жыл бұрын

５歳以下は通常料金ｗ

@nekoretu Жыл бұрын

なぜエンジニア系の動画はみんな、前提条件になる言語や環境の説明をしないのだろうか？

@komas3008 Жыл бұрын

比較で6や18というり直値を使うのは良くないと思います booleanを返却するのに比較してtrue,falseを返すのは可読性という面ではありでクソコードは言い過ぎです

@mh-em8rg Жыл бұрын

9:10 is_student内でuser.ageを使って学生かどうか判定してるけど学生かどうかと年齢は別なので、Flagとして別に持った方がいい情報かなと思ったりしました。日本でも30歳で大学入りなおす人とかいますし、学生かどうかの情報はtrue/falseで持ってるべきかなぁと。入力項目が増えてめんどくさくなるんですけどね。

@huguya Жыл бұрын

そもそもコメントが無いっていうのはダメですか！？

@e3chicago Жыл бұрын

一般的にはコメントは無い方がいいね。するとすれば何が起きてるのかを説明するのではなく「なぜそうしたのか」を書くべきだし。

@Hoshi-No-Chidori Жыл бұрын

凄い共感できるけど、実際のコーディングで毎回ここまで意識出来てるかというと……(´・ω・`) というか、そもそもだけどある程度はコメント入れようぜって思う。

@user-tv2je1wk1d Жыл бұрын

適切に命名したり、責務を切り分けてコードを書けば、読めば分かるコードに近づきます。読めば分かるコードに、わざわざコメントを書くのは冗長ですし、そもそも良いコードを書く努力をせずにコメントで解決しようとするのは姿勢としても良くありません。コメントは有用なものですが、基本的にコードの内容を補完する程度に留めておくべきだと思います。もちろん、上記はあるべき論ですし、組織の都合やプログラミング言語としての表現力が弱く、コメントがないとコードリーディングが難しいケースもあるかと思いますのでケースバイケースにはなりますが。

@Hoshi-No-Chidori Жыл бұрын

@@user-tv2je1wk1d ケースバイケースなのはその通り。みんながみんな優秀なエンジニアならそれが最適なんだろうけど、仕事となるとコーディング初心者から毛が生えた程度の新人とかも見ることも考える必要がある。その辺りを考えると経験的にはある程度コメントは入れた方がプロジェクトとしてベターだと思うってのが言いたかった。

@user-tv2je1wk1d Жыл бұрын

@@Hoshi-No-Chidori ああなるほど、まあ確かにあって損するものでもないですしね。確かにコメントの有無で言えばあった方が対応できるプロジェクトやメンバーは多そうです。

@naoh4991 Жыл бұрын

やべ、複数形にしとけば分かるやろってことで、listとかarrayに変数名ずっとしてなかった笑

@pierrot8762 Жыл бұрын

これなんの言語ですか？無知です

@KM-we9tf Жыл бұрын

Rubyという言語ですね。

@nangakiya Жыл бұрын

4問目。returnがない！結果が返ってこない！！比較してるだけ！！そこは突っ込まない！？？ヤバイヨヤバイヨ～

@mokemoke768 Жыл бұрын

Ruby では返ります

@shuchan51513 Жыл бұрын

これ何の言語や？

@ccx6676 Жыл бұрын

2問目 ①1.1がハードコーディングなのでよくない。定数宣言しといて、定数モジュールとかからもってくるとよさげでは？と思いました ②関数の説明がない

@dFish12 Жыл бұрын

PythonにはAny関数ってないん？countよりanyのが速いとか聞いたことがあるきがする

@yumohi6939 Жыл бұрын

クソ変数名w

@_erune Жыл бұрын

4問目 def get_price(user) if user.is_student return DISCOUNT_PRICE end return NORMAL_PLICE end

@takukunita4968 Жыл бұрын

最後の問題は結局1件でもあればtrue返すメソッドなのであれば最後の行もいらないと思いました。 nil(null)、""（空文字）も含まれるとして、それらははじくとすると以下のような感じでしょうか（やりすぎ？笑）。 KZfaqAPI.channels.reject(&:blank?).present?