綺麗なコードって何？初心者から一歩抜け出す「リーダブルコード」の3つの基本

公開日: 2026-03-31

プログラミングの学習を始めて、少しずつ自分の思い通りにプログラムが動くようになってきた頃。あなたはふと、1ヶ月前に自分が書いたコードを見返して、こう思ったことはありませんか？

「あれ、これって一体どういう意味の処理だっけ……？」

自分が書いたはずなのに、まるでまったく知らない誰かが書いた暗号の怪文書のように見えてしまう。焦って一行ずつ読み解いていくけれど、何をしているのかさっぱりわからない。実はこれ、プログラミングを学ぶ誰もが必ず通る「初心者の壁」なのです。

かく言う私も、エンジニアとしてのキャリアをスタートさせたばかりの頃は、自分が生み出した謎のコードに何度も泣かされてきました。

IT業界でエンジニアとして働き始めて10年。これまで数え切れないほどのシステムを作り、数百万行という膨大なコードを読んできました。その経験から、はっきりと断言できることが一つあります。それは、プログラミングにおいて「動くコードを書くこと」はゴールではなく、単なるスタートラインに過ぎないということです。

本当に価値のあるコード、現場で重宝されるプログラマが書くコードというのは、例外なく「綺麗なコード」です。では、この「綺麗なコード」とは一体何なのでしょうか。数学のように美しい数式のことでしょうか。それとも、極限まで文字数を減らした短いコードのことでしょうか。

答えは、そのどちらでもありません。エンジニアの世界で言う綺麗なコードとは、「他の人が読んだ時に、スラスラと理解できる読みやすいコード」のことを指します。

これを専門用語でリーダブルコード（Readable Code）と呼びます。

この記事では、IT初心者の方が「ただ動くコードを書く初心者」から一歩抜け出し、現場で愛される綺麗なコードを書けるエンジニアになるための3つの基本を、私の10年間の実体験を交えながら、できるだけわかりやすく、親しみやすい言葉で解説していきます。

なぜ私たちは「綺麗なコード」を追い求めるのか？¶

プログラミングを学んでいると、「とりあえず動いたからこれでいいや」と満足してしまう瞬間がたくさんあります。エラーが出ずに画面に正しい結果が表示されれば、なんだかすべてがうまくいったような気分になりますよね。しかし、実際のシステム開発の現場において、その考え方は少しだけ危険です。

ここでは、なぜ綺麗で読みやすいコードを書くことがそれほどまでに重要視されるのか、エンジニアのリアルな日常を通してお話しします。

コンピュータは動けば文句を言わないけれど¶

プログラミング言語というのは、最終的にはコンピュータに命令を伝えるための手段です。コンピュータは非常に優秀ですが、同時に非常に融通が利かない存在でもあります。文法が正しくて、論理的な矛盾さえなければ、どんなにぐちゃぐちゃに書かれた読みにくいコードであっても、コンピュータは文句一つ言わずに一瞬で処理を実行してくれます。

変数名が「a」や「b」ばかりでも、一つの関数が1000行を超えていても、コンピュータにとっては知ったことではありません。「動く」という観点だけで見れば、綺麗なコードも汚いコードも、まったく同じ価値を持っていると言えるでしょう。

それならば、なぜわざわざ時間をかけてまでコードを綺麗に整える必要があるのでしょうか？

コードは「書く」時間より「読む」時間の方が圧倒的に長い¶

その答えは、私たちが開発しているシステムが人間によってメンテナンスされ続けるものだからです。

想像してみてください。あなたが苦労して作り上げたシステムが無事にリリースされ、多くのユーザーに使われ始めました。しかし、1年後に「新しい機能を追加してほしい」「消費税率の変更に合わせて計算ロジックを変えてほしい」という依頼が舞い込んできます。

この時、あなたやあなたの同僚は、1年前に書かれたコードを再び読み解き、どこをどう修正すればいいのかを探し出さなければなりません。

エンジニアの業務時間を計測したある研究によると、プログラマがキーボードを叩いて新しいコードを書いている時間は全体のわずか1割程度に過ぎないそうです。では残りの9割の時間は何をしているのかというと、既存のコードを読んでいる時間」なのです。

つまり、コードが少しでも読みにくいと、そのコードを読むすべてのエンジニアから「理解するための時間」を少しずつ奪い続けることになります。読みやすいコードを書くことは、未来の開発スピードを劇的に上げるための、最も費用対効果の高い投資だと言えるのです。

エンジニア歴10年の私が経験した、地獄のスパゲッティコード事件¶

ここで、私が若手エンジニアだった頃に体験した、一生忘れられない苦い経験をお話しさせてください。

当時、私は社内で使われている古い顧客管理システムの改修プロジェクトに配属されました。そのシステムを作った先輩エンジニアはすでに退職しており、私は彼が残したコードを引き継ぐことになったのです。意気揚々とコードのファイルを開いた私を待ち受けていたのは、絶望的な光景でした。

変数名はすべて「data1」「data2」「temp_info」といった、中身がまったく推測できないものばかり。さらに、一つの処理の中に画面の表示、データベースの保存、メールの送信といった機能がごちゃまぜに書かれており、コードの行ったり来たりが激しい、いわゆる「スパゲッティコード」と呼ばれる状態でした。まるで、絡み合ったスパゲッティの麺の一本を引っ張ろうとすると、お皿全体の麺が動いてしまうような、そんな恐怖を感じるコードです。

本来であればたった3時間で終わるはずのちょっとした機能の追加に、私はなんと丸々3週間も費やす羽目になりました。コードを一行読み解いてはメモを取り、少しでも修正すると別のまったく関係ない機能が壊れてエラーを吐く。あの時の深夜のオフィスで感じた、先の見えない不安と疲労感は今でも鮮明に思い出せます。

この痛烈な経験から、私は「コードはコンピュータのために書くのではない。未来の自分と、次にこのコードを読む仲間のために書くのだ」という教訓を心の底から学びました。

コードの読みやすさが現場でいかに大切か、少しイメージしていただけたでしょうか。それでは、いよいよ「初心者が意識すべきリーダブルコードの3つの基本」の具体的なテクニックに入っていきましょう。まずは、すべての土台となる「名前付け」のお話からです。

基本1：すべてはここから。名前付け（ネーミング）の極意¶

プログラミングをしていると、データを一時的に入れておく「変数」や、処理のまとまりである「関数」など、ありとあらゆるものに名前をつける必要が出てきます。実は、綺麗なコードを書けるかどうかは、この「名前付け（ネーミング）」のセンスに大きく左右されると言っても過言ではありません。

名前付けの基本は、「そのコードを見ただけで、何を表しているのか、何をしているのかがひと目でわかること」です。

「とりあえず」で付けた変数が、後から牙を剥く¶

プログラミング初心者のコードを見ていると、とにかく名前付けが短すぎたり、曖昧すぎたりするケースによく遭遇します。

たとえば、計算の途中のデータを入れておく変数に「a」や「b」といったアルファベット一文字の名前をつけてしまったり、「処理するデータだから」という理由で「data」や「info」といったざっくりした名前をつけてしまったり。思い当たる節はありませんか？

確かにコードを書いているその瞬間は、あなた自身の頭の中に「この変数aには、ユーザーの年齢が入っているんだ」という文脈が残っているので、問題なく作業を進めることができます。しかし、たった3日後のあなたがそのコードを見た時、変数「a」が年齢だったのか、それとも金額だったのかを正確に思い出すことは絶対に不可能です。

悪い例と良い例のコードを見比べてみましょう。まずは、名前付けをサボってしまった悪い例のコードです。

# 悪い例：名前から処理の内容が推測できない
def calc(a, b):
    tmp = a * b
    res = tmp * 1.1
    return res

print(calc(1000, 2))

このコードを読んで、パッと「消費税込みの合計金額を計算しているんだな」と理解できる人はいないでしょう。「calc（計算する）」という関数の名前も曖昧ですし、引数の「a」や「b」、途中の「tmp（テンポラリ：一時的な）」「res（リザルト：結果）」といった名前も、具体性がまったくありません。

では、このコードのロジックは一切変えずに、変数と関数の名前だけを「名体を表す」ように変更してみます。

# 良い例：名前を見るだけで何をしているかハッキリわかる
def calculate_total_price_with_tax(item_price, quantity):
    TAX_RATE = 1.1
    subtotal = item_price * quantity
    total_price = subtotal * TAX_RATE
    return total_price

print(calculate_total_price_with_tax(1000, 2))

いかがでしょうか。コードが少し長くなりましたが、読みやすさは劇的に向上したはずです。

「calculate_total_price_with_tax（税込み合計金額を計算する）」という関数の名前を見れば、誰もがその目的を理解できます。「item_price（商品の価格）」や「quantity（数量）」という変数の名前は、その中にどんなデータが入ってくるのかを明確に物語っています。また、謎の数字だった「1.1」も「TAX_RATE（税率）」という名前をつけることで、なぜその数字を掛けているのかがすぐにわかりますよね。

具体的で、誤解の余地がない単語を選ぶテクニック¶

名前をつける時は、「これ以上、別の意味に受け取られる心配がないか？」と自分に問いかける癖をつけてください。辞書を引きながらでも構わないので、より具体的で、情報をたくさん含んだ英単語を選ぶのがコツです。

ここで、初心者がつい使ってしまいがちな「避けるべき曖昧な名前」と、それをどのように改善すればよいかを表にまとめてみました。ぜひ、自分がコードを書く時の参考にしてみてください。

避けるべき曖昧な名前	改善後の具体的な名前	なぜ改善されたのか（プロの視点）
`data`	`user_profile_data`	単なる「データ」ではなく、誰の何のデータなのかが明確になったため、扱い方が想像しやすくなります。
`flag`	`is_account_active`	プログラムでよく使う「フラグ（目印）」ですが、それが「アカウントが有効かどうか」を表すオンオフであることがひと目でわかります。「is」や「has」から始めるとYes/Noの変数だと伝わりやすいです。
`getInfo()`	`fetchUserPurchaseHistory()`	「情報をゲットする」では範囲が広すぎます。「どこから（fetch）」「誰の何を（UserPurchaseHistory）」取得するのかが具体的になり、誤用を防げます。
`tmp`	`current_total_price`	計算途中の「一時的な（temporary）」変数であっても、その瞬間に何が入っているのかを明記することで、バグを未然に防ぎます。
`check()`	`validatePasswordLength()`	「チェックする」という言葉は危険です。「パスワードの長さを検証する」という具体的なアクションに落とし込むことで、関数の役割が限定されます。

名前を考えるのに数分間の時間を費やしたとしても、それは決して無駄な時間ではありません。あなたが丁寧に考え抜いてつけたその名前は、明日以降のあなた自身と、チームの仲間がコードを読み解く時間を何時間も節約してくれる素晴らしい道しるべになるのです。

名前の重要性がわかったところで、次はコードに添える「コメント」の書き方について考えていきましょう。コメントは親切心から書くものですが、一歩間違えると逆効果になってしまうこともあるのです。

ちなみに、Pythonには変数名として使ってはいけない予約語というルールがあります(詳しくはこちらの記事へ）。また、変数名の工夫に加えて『型ヒント』というテクニックを使うと、さらにコードの意図が明確になります。型ヒントの基礎についてはこちらの記事で解説しています。

基本2：嘘をつかない、本当に意味のある「コメント」とは¶

プログラミング言語には、プログラムの実行には影響を与えずに、人間が読むためのメモ書きを残せる「コメント」という機能があります。学習を始めたばかりの頃は、「忘れないように、書いたコードの横にとにかく全部コメントをつけておこう！」と意気込む方も多いのではないでしょうか。

しかし、リーダブルコードの世界において、コメントの扱い方は少し慎重にならなければなりません。なぜなら、良くないコメントはコードを読みやすくするどころか、むしろ読み手を混乱させるノイズになってしまうからです。

コードを日本語に翻訳するだけのコメントは、今すぐ消そう¶

私が新人エンジニアだった頃、親切心のつもりですべての行にコメントを書いていました。しかし、先輩のコードレビュー（書いたコードをチェックしてもらうこと）で、こっぴどく叱られたのを覚えています。

「コードを見ればわかることを、わざわざ日本語で繰り返すな。画面がごちゃごちゃして読みにくいだけだ」と。

当時の私が書いていたような、「良くないコメント」の例を見てみましょう。

# 悪い例：コードを見れば明らかなことを書いているコメント
user_age = 25  # ユーザーの年齢に25を代入する

# もしユーザーの年齢が18以上だったら
if user_age >= 18:
    print("成人です")  # 「成人です」と画面に出力する

確かに、プログラミングを始めたその日に見るのであれば、このコメントはありがたいかもしれません。しかし、プログラミングの文法を理解している人にとって、「user_ageに25を入れている」ことや「if文で18以上か判定している」ことは、コードを見れば一瞬でわかります。

このような「コードの動きをそのまま日本語に翻訳しただけのコメント」は、読み手にとって新しい情報を何も提供していません。ただ文字数を増やし、本当に重要な情報を見落とさせる原因になってしまうのです。

さらに恐ろしいのは、システムが改修されてコードが変更された時、コードは直したけれどコメントの修正を忘れてしまうというケースです。コードは「年齢が20以上」に変わっているのに、横のコメントには「18以上だったら」と残ったままになる。こうなると、未来のエンジニアは「どっちが正解なんだ！？」と頭を抱えることになります。嘘をつくコメントほど、厄介なものはありません。

未来の仲間へ向けた「なぜ（Why）」の手紙を書く¶

では、私たちが本当に書くべき「良いコメント」とはどのようなものなのでしょうか。

それは、「コードが何をしているか（What）」ではなく、「なぜそのように書いたのか（Why）」という背景や理由を説明するコメントです。

プログラミングをしていると、ビジネスの複雑なルールや、システム特有の事情によって、一見すると「なぜこんな回りくどい書き方をしているんだろう？」と不思議に思われるコードを書かなければならない場面に必ず遭遇します。そういった「コードからだけでは絶対に読み取れない人間の意図」を残すことこそが、コメントの真の役割なのです。

先ほどの年齢判定のコードを使って、「背景を説明する良いコメント」の例を見てみましょう。

# 良い例：コードからは読み取れない「ビジネスの背景」を書いている
user_age = 25

# 注意：2022年の民法改正により、成人年齢が20歳から18歳に引き下げられました。
# 過去のデータと整合性を合わせるため、ここでは新基準の18歳を使用しています。
if user_age >= 18:
    print("成人です")

いかがでしょうか。「なぜ18という数字を使っているのか」という背景のストーリーが語られていますよね。これなら、数年後にこのコードを読んだ別のエンジニアも、「なるほど、法改正に対応するためにここで18歳で判定しているんだな。勝手に20歳に戻してはいけないな」と、作者の意図を正確に汲み取ることができます。

もし、あなたがコードを書いていて「この部分は、後から見たら絶対に『なんでこんな書き方したの？』って思われそうだな」と感じたら、そこがコメントを残す最大のチャンスです。

「こっちの書き方の方が処理が高速だから採用した」「この一時停止処理は、外部システムの通信遅延を待つための苦肉の策である」といった、あなたの頭の中にしかない試行錯誤のプロセスを、未来の仲間への手紙のように残してあげてください。

コード自体が語るなら、コメントは不要である¶

エンジニアの世界には、「最高のコメントとは、コメントを書かなくても理解できるほど綺麗に書かれたコードそのものである」という格言があります。

基本1でお話しした「具体的な名前付け」がしっかりとできていれば、わざわざコメントで説明しなくても、変数名や関数名がすべてを語ってくれます。コメントを書こうとした手が止まったら、まずは「コメントを書かなくても済むように、変数や関数の名前をもっとわかりやすく変更できないだろうか？」と考える癖をつけてみてください。

さて、名前も綺麗になり、意味のあるコメントも残せるようになりました。しかし、どれだけ名前がわかりやすくても、一つの処理が果てしなく長くなってしまうと、やはり人間の脳はパンクしてしまいます。最後に解説するのは、複雑なコードをスッキリと整理する「分割」のテクニックです。

基本3：複雑さを和らげる、魔法の「分割」スキル¶

システム開発が進むにつれて、プログラムがやらなければならない仕事はどんどん増えていきます。初心者の頃は、新しく思いついた処理を、今書いている関数の下へ下へとどんどん書き足してしまいがちです。

その結果生まれるのが、スクロールしてもスクロールしても終わりが見えない、数百行から数千行にも及ぶ「巨大な関数」です。これもまた、リーダブルコードの大敵です。

1つの関数には1つの仕事だけをさせる（単一責任の原則）¶

長すぎるコードがなぜ読みにくいかというと、人間の脳が一度に記憶・理解できる情報量（ワーキングメモリ）には限界があるからです。

上から順番にコードを追っていって、「えーと、ここでファイルを読み込んで、次にデータを計算して、あ、ここでエラー処理が入って、それから画面に表示して……あれ、最初の方で計算したデータってどこにいくんだっけ？」と、途中で思考が迷子になってしまいます。

これを解決するための魔法のアプローチが、「関数の分割」です。プログラミングの設計において非常に重要視されている「単一責任の原則（Single Responsibility Principle）」という考え方があります。これは、「1つの関数（処理のまとまり）には、1つの仕事だけを完璧にこなさせるべきだ」というルールです。

悪い例として、何でもかんでも1つの関数に詰め込んでしまったコードを見てみましょう。

# 悪い例：1つの関数が「ファイルの読み込み」「計算」「出力」という3つの仕事をしている
def process_user_data_and_print_result(filepath):
    # 仕事1：ファイルを開いてデータを読み込む
    with open(filepath, 'r') as file:
        data = file.readlines()

    # 仕事2：読み込んだデータを計算・加工する
    processed_data = []
    for line in data:
        value = int(line.strip())
        processed_data.append(value * 1.5) # 何らかの複雑な計算

    # 仕事3：計算結果を画面に出力する
    for result in processed_data:
        print(f"処理結果は: {result} です")

# 実行
process_user_data_and_print_result("data.txt")

このコードは短く見えますが、構造としては「ファイル読み込み」「データの計算」「結果の表示」という、まったく毛色の違う3つの仕事が混ざり合っています。もし「計算のロジックだけを別の場所でも使い回したい」と思っても、このままでは不可能です。

これを「単一責任の原則」に従って、それぞれの仕事ごとに小さな関数に切り分けて（分割して）みましょう。

# 良い例：仕事ごとに小さな関数に分割し、メインの処理でそれらを呼び出す

# 仕事1だけをする関数
def read_data_from_file(filepath):
    with open(filepath, 'r') as file:
        return [int(line.strip()) for line in file.readlines()]

# 仕事2だけをする関数
def calculate_data(raw_data_list):
    return [value * 1.5 for value in raw_data_list]

# 仕事3だけをする関数
def print_results(results_list):
    for result in results_list:
        print(f"処理結果は: {result} です")

# メインの実行処理（指揮者の役割）
def main():
    raw_data = read_data_from_file("data.txt")
    calculated_data = calculate_data(raw_data)
    print_results(calculated_data)

# 実行
main()

いかがでしょうか。全体の行数は少し増えましたが、コードの読みやすさと整理整頓された美しさは格段に上がったはずです。

一番下にある main() という関数に注目してください。この関数の中身を読むだけで、「ファイルを読み込んで、計算して、結果を表示しているんだな」という全体のストーリー（大まかな流れ）が、まるで目次を読むようにスッと頭に入ってきますよね。

もし計算のロジックにバグが見つかったとしても、read_data_from_file や print_results の関数を気にする必要はありません。calculate_data という小さな関数の中身だけをピンポイントで確認して直せばいいのです。このように、巨大な塊を「意味のある小さな塊」に切り分けていくスキルは、現場で複雑なシステムを構築する上で欠かせないテクニックです。

縦スクロールの恐怖をなくす¶

私が過去に銀行系のシステム改修に携わった時、驚くべきものに出会ったことがあります。それは、一つの関数の中に業務のすべてのルールが詰め込まれた、実に3000行を超える「神関数（God Function）」でした。

マウスのホイールをどれだけ回しても関数が終わらず、途中で何重にも「if文」の条件分岐が入れ子（ネスト）になっており、コードが画面の右端に向かってどんどんズレていくのです。自分が今、どの条件分岐の中にいるのかさえわからなくなり、少しコードを直すたびに手のひらに嫌な汗をかいたのを覚えています。

もし、あなたが書いている関数の行数が、パソコンの画面の高さを超えてスクロールしなければ読めなくなってきたら、それは「分割のサイン」です。「この処理の中で、独立して別の関数に切り出せる部分はないだろうか？」と立ち止まって考える習慣をつけてください。

「名前付け」「意味のあるコメント」、そして「関数の分割」。この3つの基本を意識するだけで、あなたの書くコードは驚くほど劇的に、そして美しく生まれ変わるはずです。

綺麗なコードを書くために、明日からできる実践アクション¶

ここまで、リーダブルコードを書くための具体的な考え方とテクニックを解説してきました。しかし、これらを頭で理解しただけで、明日から急に完璧なコードが書けるようになるわけではありません。綺麗なコードを書く技術は、スポーツや楽器の演奏と同じように、日々の意識的な練習によって少しずつ身についていくものです。

最後に、現場で活躍するエンジニアたちが、どのようにしてコードの品質を保ち、綺麗に書き続けているのか。そのための心構えと実践的なアクションを2つお伝えします。

ボーイスカウトルール：「来た時よりも美しく」の精神¶

エンジニアの世界には、「ボーイスカウトルール」と呼ばれる有名な教えがあります。もともとは「キャンプ場を去る時は、自分たちが来た時よりもそこを綺麗にしてから去りなさい」というボーイスカウトのルールのことですが、プログラミングの世界ではこのように解釈されています。

「既存のコードを修正する時は、自分が触る前よりも、少しだけコードを綺麗にしてから保存しなさい」

機能を追加したりバグを直したりするためにコードを開いた時、ついでに「少しわかりにくい変数名」を見つけたら、より具体的な名前に変更する。不要な古いコメントを見つけたら削除する。長すぎる関数の一部を切り出してみる。

一度にシステム全体のコードを綺麗に直そうとする必要はありません。それはあまりにも巨大な作業になり、必ず途中で挫折してしまいます。そうではなく、自分が作業した「ついでに」、周辺のコードのゴミを拾い、少しだけ磨いておくのです。この小さな親切の積み重ねが、チーム全体のコードの品質を長期間にわたって美しく保つ最大の秘訣です。

勇気を持って「リファクタリング」に挑戦する¶

プログラミングの作業は、大きく2つのフェーズ（段階）に分かれます。一つは「とにかく動くものを作るフェーズ」、もう一つは「動くコードを、読みやすく綺麗な形に整えるフェーズ」です。

初心者のうちは、この2つを同時にやろうとして頭が混乱してしまうことがよくあります。綺麗な名前を考えながら複雑なロジックを組み立てるのは、プロのエンジニアにとっても至難の業です。

だからこそ、最初は「とりあえず動くこと」を最優先にして、少々汚いコードを書いてしまっても構いません。変数名が「a」になってしまっても、関数が長くなっても大丈夫です。まずは目の前の課題を解決し、プログラムを正しく動かしてください。

本当に大切なのは、プログラムが動いて安心した「その後」です。一息ついたら、自分が書き散らしたコードをもう一度上から見直してみてください。「動くコードの動作は一切変えずに、内部の構造だけを綺麗に整理整頓すること」。これを専門用語で「リファクタリング（Refactoring）」と呼びます。

「とりあえず動いたからいいや」とエディタを閉じるのではなく、そこからさらに15分だけ時間を使って、「もっとわかりやすい名前はないか？」「処理を分割できないか？」と自問自答しながらリファクタリングを行う。この泥臭い推敲のプロセスこそが、あなたを「初心者」から「一人前のエンジニア」へと押し上げる最も確実なステップアップの階段なのです。

おわりに：綺麗なコードは、未来の自分への最高のプレゼント¶

長い文章に最後までお付き合いいただき、本当にありがとうございました。

「綺麗なコードって何？初心者から一歩抜け出す『リーダブルコード』の3つの基本」というテーマで、私の10年間の経験で得た教訓をたっぷりとお話しさせていただきました。

名前付けは「名体を表す」の精神で、具体的に。
コメントは「何をしているか」ではなく、「なぜそうしたか」を語る。
複雑な塊は「単一責任の原則」に従って、小さく分割する。

この3つの基本は、どんなに新しいプログラミング言語が登場しようとも、どんなに強力なAIツールがコードを書くサポートをしてくれるようになろうとも、決して色褪せることのない普遍的なエンジニアリングの原則です。

今日学んだことを、いきなりすべて完璧に実践しようと焦る必要はありません。最初は誰だって、自分が書いた下手くそなコードに絶望し、試行錯誤を繰り返しながら成長していくものです。私自身、10年経った今でも「うわっ、半年前の自分のコード、読みにくいな！」と頭を抱えながらリファクタリングをする日々を送っています。

大切なのは、「少しでも読みやすいコードを書こう」という意識を常に持ち続けることです。

もし今夜、あなたがパソコンを開いてコードを書く機会があるなら。関数に名前をつける時、少しだけタイピングの手を止めて、5秒だけ考えてみてください。「この名前で、3日後の自分は意味を理解できるだろうか？」と。

そのほんの少しの思いやりと工夫の積み重ねが、数ヶ月後、数年後のあなた自身を助ける最高のプレゼントになります。そしていつか、あなたが書いた美しいコードが、一緒に働く仲間から「すごく読みやすくて助かったよ！」と感謝される日が必ずやってきます。

綺麗で読みやすいコードを書くことは、Pythonという言語が持つ最大の哲学でもあります。Python開発者たちの美しいコードへの想いが込められた『Pythonの禅』については、以下の記事で熱く語っていますので、ぜひプログラミングの息抜きに読んでみてくださいね。 Pythonの禅とは？「import this」に隠された秘密を徹底解説

#python #コラム

メニュー