私はこれらの2つの価値あるプログラミング慣行を頻繁に耳にします。（1）コードの行は80文字以下である必要があり、（2）変数、メソッド、クラスなどにわかりやすい名前を使用します。 、彼らはしばしばお互いのトレードオフのようです。コードを80文字/行未満に保つと、よりわかりにくい名前を使用することになります（特に各インデントが4文字としてカウントされるPythonでは）が、より説明的な名前を使用すると、80文字を超える行になります。

だから、私の質問は、これらの2つのアドバイスのうち、どちらを選択する必要があるかを守ることがより重要ですか？私はこれを独立した（趣味の）プログラマーだと思っていますが、もっと重要なのは、大企業で働くソフトウェアエンジニアの観点からです。

インデントを少なくし、名前をわかりやすくし、改行を恐れないでください。

インデントを少なくしてください。

多くの場合、インデントと記述的な命名法との間の闘争に身を置くと、一歩下がってインデントレベルを確認します。3レベルまたは4レベルよりもインデントしている場合（多くの場合、2レベルは自動で避けられません。読み取り：クラスメソッド定義）、コードを再構築し、機能をメソッドまたはメソッドに抽象化します。

わかりやすい名前

名前は常にわかりやすいものにしてください。わかりやすい名前は、自己文書化コードを作成します。場合によっては名前を短くすることもできますが、読みやすさが最初になります。

行を壊すことを恐れないでください

たわごとが起こる。80文字を超えていて、とにかく行のスペースを取り戻すことができない場合は、改行してください。ほとんどの言語は改行を気にしないので、行を複数に分割します。ランダムな場所を選ぶだけではありません。物事を論理的にグループ化し、行を分割するときに別のレベルをインデントします。

なぜ両方ではない？

まず、「記述的」と「詳細」は同じではありません。たとえば、かなりローカルなループを記述している場合はi、ループ変数の非常に適切な変数名です。current_iteration_index、おそらくより記述的で間違いなく冗長iですが、ループ変数としての使用はほとんど普遍的に受け入れられており、それ以外の意味はないので、はるかに悪く、まったく情報を追加しませんi。

適切な変数名は、言語のイディオムとコードベースの規則に精通しているプログラマーがその役割を簡単に推測できるという点で記述的ですが、物事をコンパクトに保つ​​のに十分簡潔です。

80文字の制限は、もともと1970年代のテキスト端末の技術的な制限の結果でしたが、今日でも多くの人に評価されています。技術的な理由（一部のネットワークプロトコル、特に電子メール関連の最大行長）より説得力のある理由は、心理的および社会的なものです。66文字のマークの周りの行の長さは、自然言語の散文で最も快適な読書体験を実現します（興味深いことに、フォントサイズは大きな違いを生まないため、画面サイズも用紙サイズも変わりません）。80文字の行制限はそれにほぼ近いですが、通常のコードの大部分は通常少なくとも1つまたは2つのレベルでインデントされます（つまり、インデント設定に応じて4〜16文字）。

80文字の行に固執するもう1つの効果は、状況が複雑すぎる場合の非常に良い指標であるということです。長い行は通常、次のいずれかが原因です。

• 引数の長いリストを持つ関数。読みやすさを妨げ、微妙なバグを簡単に引き起こす可能性があるため、これは良いことではありません。たとえば、コンパイラーがキャッチしない方法で引数の順序を入れ替える場合です。
• 条件式（例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."));。リテラルを変数または定数に移動します。それでも行の長さを超える可能性がありますが、一貫して行えば、読者はリテラルの残りだけが続くと仮定して、少なくとも安全に行の不可視部分を無視できます。または、さらに良いことに、リテラルをコードから外部データストア（ファイル、データベースなど）に移動します。
• 深くネストされたステートメント。たとえばif、クラスメソッドの6レベルのステートメント（通常の設定では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文字に増やします。

それでも、それは厳しい制限ではありません。行を1文字越えますか？まあ、何も起こりません！

編集：

80文字の制限の履歴に関する詳細な回答

ウィキペディアの行ごとの文字

ウィチタ州立大学の研究では、CPLが速さと理解の要因を含め、読みやすさにわずかな影響しか及ぼさないことがわかりました。ただし、選好を求められた場合、回答者の60％が、研究で使用された最短（35 CPL）または最長（95 CPL）のいずれかの選好を示しました。同時に、回答者の100％が、これらの量のいずれかを最も望ましくないものとして選択しました。