わかりやすい名前と80文字の行
私はこれら2つの貴重なプログラミング方法をよく耳にします。（1）コード行は80文字以下である必要があり、（2）変数、メソッド、クラスなどにわかりやすい名前を使用します。これらの両方のアドバイスの理由は理解していますが、 、それらはしばしばお互いのトレードオフのようです。コードを80文字/行未満に保つと、わかりにくい名前（特にPythonでは各インデントが4文字としてカウントされる）を使用しますが、よりわかりやすい名前を使用すると、 80文字を超える行を追加します。
それで、私の質問は、これらの2つのアドバイスのどちらを選ぶ必要があるかを理解するために、どちらを守ることが重要かということです。私はこれを独立した（趣味の）プログラマーとして考えていますが、より重要なのは、より大きな会社で働いているソフトウェアエンジニアの観点からです。
インデントは少なく、名前はわかりやすいものにしてください。改行を恐れないでください。
インデントを少なくしてください。
インデントとわかりやすい名前付けの間に苦労していることがよくあるので、一歩下がって自分のインデントレベルを確認します。 3レベルまたは4レベルよりもインデントしている場合（2レベルは自動的であり、多くの場合不可避です。読み取り：クラスメソッド定義）、コードを再構成して、機能を関数またはメソッドに抽象化することができます。
あなたの名前はわかりやすい
名前は常にわかりやすいものにしてください。説明的な名前は自己文書化コードを作成します。場合によっては名前を短くすることもできますが、読みやすさが最初になります。
改行を恐れないでください
たわごとが起こります。 80文字を超えると、行のスペースを再利用する方法が見当たらない場合は、改行してください。ほとんどの言語は改行を気にしないので、行を複数に分割します。ランダムな場所を選ぶだけではありません。物事を論理的にグループ化しておき、改行するときは別のレベルにインデントします。
両方ではない理由
まず、「説明」と「冗長」は同じではありません。たとえば、かなりローカルなループを作成している場合、iはループ変数の非常に優れた変数名です。 _current_iteration_index_は、間違いなく説明的で間違いなく詳細ですが、ループ変数としてのiの使用は広く受け入れられているため、はるかに悪く、まったく情報が追加されません。 iにとってそれ以外の意味はありません。
言語のイディオムとコードベースの規則に精通しているプログラマは、その役割が何であるかを簡単に推測できるという点で、適切な変数名はわかりやすいものですが、物事をコンパクトに保つのに十分簡潔でもあります。
80文字の制限は、もともと1970年代のテキスト端末の技術的制限の結果でしたが、今日でも多くの人が高く評価しています。それでも技術的な理由があります（一部のネットワークプロトコルの最大行長、特に電子メール関連）。より説得力のある理由は、心理的および社会的なものです。 66文字のマークの周りの行の長さは、自然言語の散文で最も快適な読書体験を生み出すことがわかります（興味深いことに、フォントサイズは大きな違いをもたらさず、その結果、画面や用紙のサイズも違いません）。 80文字の行制限はこれにかなり近いですが、通常のコードの大部分は通常少なくとも1レベルまたは2レベル（インデント設定に応じて4〜16文字）でインデントされるため、最終的にはこれは66（64〜76文字）にかなり近い値です。
80文字の行に固執する別の効果は、物事が複雑すぎる場合のかなり良い指標になることです。長い行は通常、次のいずれかが原因です。
- 引数のリストが長い関数。読みやすさを妨げ、簡単なバグを簡単に引き起こす可能性があるため、これは良いことではありません。コンパイラーがキャッチしない方法で引数の順序を入れ替えるとき。
- 条件式でよく見られる複雑な式（例：
if ((user.isLoggedIn && user.hasPermission(page.getRequiredPermission()) && !user.isBanned) || page.getRequiredPermission() == null)）;これも通常、解読がかなり難しく、コードはより構造化されたものに書き直す必要があります。最も可能性が高いのは、式が多すぎるため、メソッドまたは関数に組み込む必要があることです。 - 関数呼び出しや式で使用される長いリテラル。
print(translate(LANG_EN, LANG_ES, "This is the home page. Feel welcome to click around and see what we have."));。リテラルを変数または定数に移動します。それでも行の長さを超える可能性がありますが、これを一貫して行う場合、リテラルの残りのみが続くと想定して、リーダーは少なくとも安全に行の非表示部分を無視できます。または、リテラルをコードから外部データストア（ファイル、データベースなど）に移動します。 - 深くネストされたステートメント、例えばクラスメソッド内の6レベルの
ifステートメント（これは、一般的な設定では32列のインデントです）。繰り返しになりますが、深い入れ子は複雑で読みにくいコードを作成するため、ペストのように回避する必要があります。簡単に言えば、深い入れ子は、読み込み中に人間の脳のスタックをオーバーフローさせます。
これらすべては、結局のところ、長期的にはコードベースに必要のないものの症状であり、80文字の制限を適用することは、複雑さを抑えて読みやすさを維持するのに役立つ優れたシンプルな方法です。 （それはあなたが80列で完全に読めないコードを書くことができないと言うことではありません：様々な難読化された何かのコードのコンテストは明確な反例です）。
記述的なネーミングはFARの方が重要です。ほとんどのインターフェイスでは、スクロールして長い行を表示できます。どのような場合でも、システムは、名前が不適切な変数や関数の変換を支援できません。
長いコードの1行を複数の短いコードに分割する方法はたくさんあるので、名前が長くても1行あたり80文字にするのは難しくありません。たとえば、Cの条件ステートメントを40行未満に収まるように複数行に分割できます。文字、
if ( a == b || c == d || d == e
|| c == e || c == a || c == k
|| c == l)
関数呼び出しの行を複数の行に分割することもできます。
したがって、説明的な命名規則と80文字の行の両方に矛盾はなく、読みやすくするために共存させることができます。
80の制限は、ずっと前に増やすべきだったものです。この制限が使用されるのは、すべての識別子の長さが8文字に制限されていて、スクリーン/プリンタでフォントが1つしかなかった時代からです。フォントサイズを変更する可能性はありません。
神様、私たちは今、異なるスクリーンと印刷技術を持っています。プログラミング言語は大きく異なります。 80文字を使用する理由はもうありません。少なくとも120文字に増やしてください。
それでもハードリミットであってはなりません。あなたは一文字上に行きますか？まあ、何も起こりません！
編集：
行ごとの文字数 ウィキペディア
ウィチタ州立大学での研究では、CPLは速度と理解の要素を含め、読みやすさへの影響はわずかであることがわかりました。しかし、好みを尋ねられたとき、回答者の60％は、調査で使用された最短（35 CPL）または最長（95 CPL）のラインのどちらかを好みを示しました。同時に、回答者の100％が、これらの量のいずれかを最も望ましくないものとして選択しました。