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

[@mokemoke768]

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

[@marx_d_24]

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

[@shusugai]

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

[@濵田悠樹-r8l]

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

[@江越-p5d]

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

[@TL-ip3tl]

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

[@hoge_hoge]

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

[@ryonnkoch]

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

[@遠藤大輔-h7u]

ほんまこれ

[@lagavulin1968]

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

[@kitajii]

7:12
if 6

[@user-lj5dp2jj3d]

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

[@anata_no_kansou]

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

[@_mitawa5109]

@@anata_no_kansou (

[@Gent-Owl]

pythonでは同じ条件を「if 6

[@MrTakusomikke]

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

[@tsukumon.]

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

[@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インターフェース使った方がいいと思いました

[@hiroshifukushima1512]

「優れたプログラムは、プログラムそのものが仕様書になる」の好例ですね。
もちろん仕様書があることでプログラムの品質を保証するから仕様書は必須だと思います。

[@notchnotty]

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

[@thy_thy7]

yagni

[@watarukumagai6110]

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

[@中野翔太-u8c]

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

[@washihatensaija]

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

[@sirokuma5963]

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

[@haruhibouEX0]

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

[@user-pl8dp3zv4o]

@@sirokuma5963まあプログラミング学習の目的は文法を覚える事ではなく、論理的な思考力、プログラミングの様にルールを基に秩序立てて考える力を育む事が目的のはずだからな。思考に重点を置いているんだろ

[@24jojo8]

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

[@Pacmania100]

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

[@Gent-Owl]

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

[@本山香-z5p]

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

[@Gent-Owl]

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

[@es-vf8du]

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

[@本山香-z5p]

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

[@Gent-Owl]

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

[@DDD-ht6zs]

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

[@めいみく-r7o]

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

[@h.m.277]

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

[@それがし-i6j]

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

[@bryk6189]

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

[@yoshiki6375]

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

[@瀧田佳一郎]

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

[@haraoki4434]

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

[@takuyaoda]

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

[@バアル昇]

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

[@数学完全に理解した]

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

[@shusugai]

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

[@bluerose1412]

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

[@user-hf7ok2hf5q]

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

[@pastmemories0115]

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

[@だめおやじエンジニアの奮闘]

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

[@user-sz9bo7dv3h]

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

[@toppo8ss]

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

[@ヒローシ]

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

[@nangakiya]

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

[@まおまお-f2c]

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

[@10A.Official.YT.account]

まじで助かります!

[@ねもうす-s7t]

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

[@mse121]

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

[@kou-u2o]

勉強になりました

[@ryokutya2000]

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

[@yoshito323]

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

[@ベビーメタル-x3j]

この企画面白い！！

[@無垢の巨人が嫌い]

めちゃためになる〜

[@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と呼ぶことからきています)

[@ばぁど-f9h]

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

[@304]

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

[@otanoshimi4]

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

[@e3chicago]

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

[@IamSuperLovely]

これは楽しい

[@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

[@hagehagehage]

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

[@スカイウォーカーソフィス]

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

[@onme4780]

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

[@tanakataro372]

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

[@qaz-asdfghjkl]

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

[@NONAME-qt9og]

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

[@04rinel64]

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

[@neil9444]

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

[@100Gorilla]

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

[@jajathree9506]

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

[@mokemoke768]

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

[@jajathree9506]

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

[@地球の皆さんどうぞよろしく]

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

[@jajasuke2525]

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

[@nangakiya]

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

[@takukunita4968]

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

[@真珠恵瑠]

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

[@MegaGeek2]

この話いいね！

[@ぷにょーん]

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

[@takukunita4968]

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

[@KS-517]

またやって欲しい

[@スライムハウス]

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

[@mng6501]

これ言語なんですか？

[@applepi314root]

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

[@Arsche]

よくわかんないけど、とある証明が効率的じゃないってこと？
でも、証明ってアイデアの問題なわけで、効率問題にすべき？

[@杉ハラ]

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

[@furusatonotkokyou]

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

[@nangakiya]

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

[@kino785]

その行数の節約いる？

[@なななな-d5i]

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

[@nangakiya]

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

[@なななな-d5i]

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

[@nangakiya]

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

[@ak2channel]

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

[@tadashifujinaga]

Bルームなんすねー

[@きさらぎともえ]

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

[@poypoyh4413]

1.1ってそういうことか！

[@mh-em8rg]

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

[@Nijist5_BR]

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

[@本山香-z5p]

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

[@Nijist5_BR]

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

[@ファギョ]

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

[@Nijist5_BR]

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

[@Takuu-]

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

[@huguya]

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

[@e3chicago]

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

[@nekoretu]

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

[@naoh4991]

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

[@Yu-jx1xd]

宗教色が強い動画やなあ

[@shima01134]

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

[@dmdm4494]

モブプロやね

[@pierrot8762]

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

[@KM-we9tf]

Rubyという言語ですね。

[@shuchan51513]

これ何の言語や？

[@UNITY-CONFLICT]

５歳以下は通常料金ｗ

[@komas3008]

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

[@半純血の王]

声がヨビノリ

[@Hoshi-No-Chidori]

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

[@人間失格-c4z]

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

[@Hoshi-No-Chidori]

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

[@人間失格-c4z]

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

[@ccx6676]

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

[@dFish12]

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

[@山田太郎-c6s1d]

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

[@sirosiroking]

いんだよ動けばクソコードでも

[@100マス計算世界ランク1位]

5歳以下って学割適用されないんだっけ？笑

[@dangomushi983]

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

[@yumohi6939]

クソ変数名w

[@nangakiya]

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

[@mokemoke768]

Ruby では返ります