【脱・初心者プログラマー】読みやすいコードを書くためのポイント【可読性】

[@freestylechannel758]

後半の「保守性編」もぜひ合わせてチェックしてください💡 kzbin.info/www/bejne/sIbJooFpiLlrY9E 気になったことやこんな方法もあるのでは？というコメントもお待ちしています！

[@まこと-x1k]

個人開発も例外じゃなくて数ヶ月後、数年後の自分が読んで理解できるかってところにも繋がるのでとても重要ですね😮😮😮

[@freestylechannel758]

コメントありがとうございます！おっしゃるとおり、未来の自分のためにも読みやすいコードを心がけたいですね！

[@kenken__.]

3日前に書いたコードは他人のコードなんて言葉も聞きますしね

[@冬月十夜]

変数名本当に大事 この変数何やねん？っていうのが分かるだけでかなり読みやすくなるので

[@freestylechannel758]

コメントありがとうございます！

[@におき-k7n]

心当たりがあって参考になりました！後から読みやすくする為のコメントの付け方編みたいな動画も作って欲しいです。

[@freestylechannel758]

コメントありがとうございます！ご意見とてもありがたいです！今後の企画の参考にさせていただきます😄

[@sdbh-daipon]

元企業プログラマーですが、こういったルールは、知ってる人と知らない人がいて、人それぞれ考え方が違います。それぞれが自分の価値観で上から偉そうにルールを押し付けてくる方々の多い事多い事…。 一見ルールは良い事の様に思われがちですが、プログラミングの楽しさや向上心を壊す諸刃の剣である事をプログラマー全員が自覚し、人に対する物の言い方を改善するべきではないでしょうか。

[@freestylechannel758]

コメントありがとうございます🙇

[@vacuumcarexpo]

中括弧の置き方にまで名前が付いてるとは知らなかった❗ SMALL_DIFFERENCE定数変数を置く事で、「もっと」と「少し」の基準を変更しやすくしてるのですね。

[@freestylechannel758]

コメントありがとうございます！

[@patatan168]

（Javaではなく）JavaScriptをよく使うジュニアですが 趣味と職業プログラミングの違いはコード品質が評価されることですね。 とはいえリリース前なら少し品質悪くてもスコープが限定的なら許容することはありますね。

[@freestylechannel758]

コメントありがとうございます😌😌 仕事で作るものはやはり品質が大切ですね。 自分だけが使う目的のツールをコーディングする際に、ついつい手を抜いてしまって可読性・保守性を犠牲にしたことがあります。 そして修正・機能追加のために自分のプログラムを解析しなければいけない！なんて苦い思い出が... 最初からもっと整えておけばよかったな...と反省することがほとんどですね。 リリース時に完璧なものを提供できるのが理想ですが、 リリースしてからリファクタリングすることも場合によってはありますね！

[@みわと-o7e]

すんごいわかりやすい

[@freestylechannel758]

コメントありがとうございます😊

[@コンデンサー]

最近、LLMが優秀すぎて出してもらったコードを精査して、リファクタリングして、プロンプトにしてっていうのを繰り返す日々になってるのが悩みです。。 せめて設計や概念の理解を本などで勉強した方がいいですかね。そうですよね。もう自分で0→1を書く気にはなれないです。。

[@XD-regst54t]

再生時間が1024なのがオシャレ

[@freestylechannel758]

コメントありがとうございます😊

[@通りすがりの男子]

初めてFlake8に自分が書いたコードをチェックしてもらった時の驚き、絶望を思い出しました(苦笑)。 質問なのですが、コード中のコメントってどんな時にどう書けば良いですか？コード自体の可読性を高めればコメントは不要ですか？

[@freestylechannel758]

初めて静的解析ツールを使った瞬間の衝撃はすごいですね。 指摘されている内容を理解できるだけの知識があるとまだ平常心を保っていられますが、 そうではないと絶望を感じますよね。 コメントについては少し意見が分かれます。 ・コメント完全排除派 ・コメント最低限派 ・コメント多用派 などなどがあり、どの考え方が正しいかを言い切ることはできません。 仕事では所属しているプロジェクトの意向に合わせることになりますが、 社内の教育ではコメントを最低限にすることを勧めています。 考え方としては「コメントがなくても読める・理解できるプログラムを書く」ことを前提として、 補足がないと他人が分かりずらいプログラムはコメントを追加するというものです。 特に初心者の間はこの判断が難しいので、 数週間後・数か月後の自分がプログラムを見返したときに処理内容をすぐ理解できるかを考えると良いです。 ※実際に数週間後に書いたプログラムを読み直して、分かりずらいところを探すのは良い練習かと思います。 また、コメントとして書くのは処理の意図や経緯が好ましいと考えます。 なぜその処理が必要なのか？なぜそのタイミングで処理を書いているのか？が有益な情報です。

[@ハバネロ-c5t]

可読性に関しては私好みの内容でした。 ただ、英語力が重要という共通認識がないと、playerGuessよりもpの方が短くていいでしょ？pに対して/*プレイヤーが入力した推測値*/とコメントすればいいでしょ？という事になりかねないです。

[@freestylechannel758]

コメントありがとうございます！今後の参考にさせていただきますね！

[@真珠恵瑠]

5:06 空行ではなく空白詰めの行をまき散らさないように注意 5:34 日本人向けに説明すると字下げ。空白数文字単位で1層の字下げをするのをよく見かけるが、これは字下げずれ事故を起こしやすい。tab 1個で1層にすれば事故りにくいし、文字量も減って得なのに少数派なのは謎 7:26 日本人向けに説明すると入れ子が多い

[@freestylechannel758]

コメントありがとうございます！今後の参考にさせていただきますね

[@Sola.No.17]

「言語によって」って解説がありますが、「コーディング規約によって」かと。個人開発でもチーム開発でも遊びでも仕事でも、立ち上げたプロジェクトの骨組みを作る際に、コーディング規約を決める事になります。これが曖昧だと、どんなに綺麗なコードを書いたとしても、統一性が失われます。重要なのは「読みやすい形での統一性」だと考えます。ですので、初心者には「事前にコーディング規約を設けて、それを遵守しましょう」でいいんじゃないですかね？その代表的な既存のコーディング規約を紹介するとか、コーディング規約を作る講座を開くとか、そういう事をした方のが実用的ではないですかね？同じ言語を使ってても、プロジェクト毎にルールは違いますよ。 それと、細かいようですが「コードの可読性」と「コードの設計」は、出発点とゴールがそれぞれ全く違うので、初心者講座などでは切り離すべきかと考えます。後半のネストが深い部分は、結果的に可読性が悪くなっているだけで、「コードの可読性」の問題ではなく、「コードの設計」の問題です。そして、「コードの設計」において「コードの可読性」を考慮して設計はしません。

[@kazemaru1234]

やばすぎてこのコメント以降返信無くなったの笑う

[@freestylechannel758]

コメントありがとうございます！今後の参考にさせていただきます。

[@tetrahydrok5738]

コード設計はコード可読性より広い意味だと思うんですが、コード設計においてコード可読性を考慮して設計はしませんというのもよく意味がわからないですね 可読性が関係ないなら全部アセンブラでいいですよね

[@tetrahydrok5738]

可読性というのは目で見て読みやすいとかのレベルではなくて、デザインパターンなどの話にもつながっていて、ひいてはコードの拡張性とかにも関係してくると思いますよ

[@Sola.No.17]

@@tetrahydrok5738 設計は設計ですよ。例えば、あなたが「ブロック崩し」を作るとして、その処理をするための設計をしますよね。その事を話しています。広義的な意味でも、抽象的な物でもないです。その設計をするのに、コードの可読性を考慮して設計はしませんよね。アセンブリ言語を使うかどうかは関係ないです。

[@コロン提督]

昔は変数は一番上にまとめて宣言して、コメントを添える形式だったな。 今はスコープが実装されたので、変数をまとめて宣言する必要も無いし、変数名を読んだだけでわかるものを付けるから添える必要も薄れた。

[@freestylechannel758]

コメントありがとうございます😌 昔は変数を一番上で宣言しないとコンパイルが出来ない言語もあったので、今でもなんとなく上で宣言する文化が残っている職場もあるようです。 社内のコードレビューを実施しているとことあたりの話しをする機会が多いです。 変数やメソッドなどが分かりやすく命名されているコードを読むと、コメントがあまりなくても内容が分かりやすくて助かりますよね。

[@駄犬-q1j]

明確な変数名であれば可読性が高いっていう何らかのエビデンスや研究結果ってあるのですか？ 正直、スコープの長い変数名でない限り、変数名はなんでもいいというか、変数名をつけることよりもスコープを短く保つことの方がずっと大事だと思う。 構造化プログラミングだと、処理ごとにブロックを付けると、見栄えが変になるのでどうしようもないですが、変数名が重要だという主張は如何せん前時代的で古い習慣に思える。 スコープが短ければ変数名はなんでもいいし、 スコープが長ければ変数名がなんであれ大抵意味は覚えてくる 中途半端な範囲の変数があること自体が問題であって変数名が問題なことってほとんどないのでは？ 実際、randomって変数名がrになってようと、可読性になんの影響もないと思うし、rがrandomになっていて可読性が向上するってこともないように思える。 もちろん、色んなモジュールで同じように命名されているなら、その記憶で読みやすさは向上するだろうけど、それって別にrって名前で統一されてても同じだと思う。

[@freestylechannel758]

コメントありがとうございます！今後の参考にさせていただきますね

[@YoshifumiKobayashi]

lint強制すればよろしいと思います。

[@freestylechannel758]

コメントありがとうございます😌 チーム内で品質を一定に保つためにはlintを使うのは確かに非常に有効ですね。 問題個所がハイライトされるので見落としを回避できて助かります。 @YoshifumiKobayashiさんのおすすめのlintはありますか?

[@_kn8m339]

テスタブルじゃないのでダメです

[@freestylechannel758]

コメントありがとうございます！

[@ばっちょ-d6m]

ChatGPTにコピペして Fix

[@freestylechannel758]

コメントありがとうございます😌

[@五段松下]

命名規則知らん奴おるの？w

[@freestylechannel758]

コメントありがとうございます！

[@あの耳からバナナ生えてますよ]

変数に個性出してくる人嫌いじゃないわよ。

[@freestylechannel758]

コメントありがとうございます！

[@ab_221B]

うーん、ある程度適切な最低限のコメントさえ有れば、変数名が一文字だろうが統一制が多少無かろうがどうでも良い。

[@freestylechannel758]

コメントありがとうございます！今後の参考にさせていただきますね

[@momochi9790]

AIにコードにチェックしてもらうと、この動画で言ってる事と全く逆の事をダメ出しされて凹むでしょう。それに、これからの時代は「人が読みやすい」コードは必要ありません。AIコード生成が主流になるため、そもそも人にとって直接コードを読む事が（量的に）不可能な時代になります。しかし量や書式の多様性や可読性の問題はAIが緩衝として受け持ってくれます。プログラマのみなさん、もっと自分のスタイルで自由に創造しましょう。書式に制約を課す時代は終わりました。これからはコードの素の性能と品質で勝負です。

[@freestylechannel758]

コメントありがとうございます！今後の参考にさせていただきます。

[@Galaxy__Guy]

今AIにコードリファクタリングしてもらうと、大体マーティン・ファウラーっぽくリファクタリングされるぞ。 つまり変数に意味を持たせて、メソッドを分割・共通化して、スコープを小さくして、オブジェクトにしてとかだな。 お前もうちょっとAI使ったほうがいいよ

[@momochi9790]

@@Galaxy__Guy 少し煽り気味のコメントだったのでアレですが、（まだ未熟な）AIやlintは関係なく、コーディングは目的や業界が異なれば”正しい”書き方は変わりますよ、という話です。案件によって縛りもありますしね。 特にギフティッドIQの人や数学が得意な人のコードは異常なほど読みにくいのは知ってるでしょうか？まさにIQが20異なれば会話にならないわけです。 彼らにとってみれば、最もわかり易いのにも関わらず、一般人（他のチームメンバー）にとってはコードを汚す存在でしかないという不遇の時代がソフトウェア業界で続いてきました。それが今の日本のIT土方を生む土壌にもなっています。大手外資系企業のコードが日本人にとって汚く見えるのも同じ理由からきています。 それがAIによって新しい状況に変わろうとしている事を伝えたかったのです。Q関数が「正しい書式」から「コード性能」変わり、（コーダーにとって禁忌とされる）創造性とアイデアが最大化される時代に変わります。