なぜコード仕様では1行あたり80文字を超えない制限が合理的なのか

Python符号化スタイルガイド(PEP 8)の中で最も議論されている部分は、1行あたり80文字を超えない制限かもしれません.そうです.実際には79文字ですが、80文字を使っています.これはプログラマーへの参照値です.
古いVT 100端末
現在、多くのソフトウェア会社が採用している符号化仕様は基本的にPEP 8であるが、行当たり80文字の制限を除く.GitHub上のプロジェクトの多くはPEP 8仕様に従っている(この点は高度な統一に達しているようだ)が、80文字の制限を遵守することは少ない.いくつかの明確に規定された仕様基準では、この制限は(100または120)増加し、完全に削除される可能性がある.このようによく見られる理由は、VT 100端末を使ってプログラミングする年代ではなく、より大きく、より高解像度のスクリーンを持っているからです.これは事実ですが、Python符号化ではこの80文字の仕様を採用し、スペースの使用に合わせて、コードをよりコンパクトにし、より読み取り可能にすることがわかりました.
自然な状況では、Python文の長さは一般的に約35～60文字(インデントを除く)を占めていることがわかります.もっと長い文は珍しい.突然、ある文が他の文よりずっと長いと、突き出ていて、面白くありません.同様に、強制的なスペースを使用して行幅を大きくすると、ネストされたループを減らすレイヤ数を視覚的に最適化することができます.一般的には、コードを再構築して4レイヤ以上インデントしないことをお勧めします.
たとえば、次のようにします.

def search(directory, file_pattern, path_match,
           follow_symlinks=True, output=True, colored=True):
    ''' Search the files matching the pattern. The files will be returned, and can be optionally printed '''

    pattern = re.compile(file_pattern)

    results = []

    for root, sub_folders, files in os.walk(directory, followlinks=follow_symlinks):
        # Ignore hidden directories
        if '/.' in root:
            continue

        # Search in files and subfolders
        for filename in files + sub_folders:
            full_filename = os.path.join(root, filename)
            to_match = full_filename if path_match else filename
            match = re.search(pattern, to_match)
            if match:
                # Split the match to be able to colorize it
                # prefix, matched_pattern, sufix
                smatch = [to_match[:match.start()], to_match[match.start(): match.end()], to_match[match.end():]]
                if not path_match:
                    # Add the fullpath to the prefix
                    smatch[0] = os.path.join(root, smatch[0])

                if output:
                    print_match(smatch, colored)

                results.append(full_filename)

    return results

これと比較すると、

def search(directory, file_pattern, path_match,
           follow_symlinks=True, output=True, colored=True):
    ''' Search the files matching the pattern.
        The files will be returned, and can be optionally printed '''

    pattern = re.compile(file_pattern)

    results = []

    for root, sub_folders, files in os.walk(directory,
                                            followlinks=follow_symlinks):
        # Ignore hidden directories
        if '/.' in root:
            continue

        # Search in files and subfolders
        for filename in files + sub_folders:
            full_filename = os.path.join(root, filename)
            to_match = full_filename if path_match else filename
            match = re.search(pattern, to_match)
            if match:
                # Split the match to be able to colorize it
                # prefix, matched_pattern, sufix
                smatch = [to_match[:match.start()],
                          to_match[match.start(): match.end()],
                          to_match[match.end():]]
                if not path_match:
                    # Add the fullpath to the prefix
                    smatch[0] = os.path.join(root, smatch[0])

                if output:
                    print_match(smatch, colored)

                results.append(full_filename)

    return results

最初のセグメントのコードにはスクロールバーが表示されますが、スクロールバーが表示されなくても、このコードは美しくなく、視覚的にバランスがとれていません.2段目のコードはもっとよく見え、読みやすいです.
もう一つ重要なのは、スクリーンにもっと多くのものを表示できることです.多くの場合、画面上で1つのファイルの複数の場所、または複数のファイルの内容を同時に見る必要があります.私が好きなこの目的を実現する方法は、それらを列ごとに並べることです.ファイル全体に80幅の制限がある場合、コードはよく表示されます.コードがエディタで自動的に折り曲げられるかどうか心配する必要はありません.エディタを構成するのに面倒をかける必要はありません.vimを使用してコマンドラインでファイルをすばやく編集する必要がある場合は、ファイルの幅を心配する必要はありません.コードに集中できます.
縦列表示
唯一問題があるのはDjangoを使うときです.Djangoフレームワークを使用する場合は、このような呼び出しを多く使用する必要があります.

ThisIsMyModel.objects.find(field1=value1, field2=value2).count()

インデントされたコードの中で、「最小」のmodel関数呼び出しはあまりスペースがありません...しかし、私は依然として同じ原則を堅持して、できるだけコードの表現をはっきり読めるようにしていますが、これは他のPythonコードよりずっと難しいです.
だから、この制限の最初の願いが今と完全に合わなくても、この制限はもっと読みやすいコンパクトなコードを書くのに役立つと思います.私は「可読性」を要求するマニアで、コードの可読性が最も重要な考慮すべき点だと思っています.プログラマーはいつでもこの点を銘記しなければなりません.本文は外刊IT評論網(www.aqee.net)がオリジナルで発表し、文章の住所:なぜコード規範の中で1行あたり80文字を超えない制限が合理的であることを要求するのか、[英語原文:80 chars per line is great]