いいえ、これはタイプミスではありません。 この記事は構造についてではなく、プログラムコードのテクスチャについてです。
それが何であり、なぜこの概念が私にとって重要なのかを説明するために、1つの話をします。
20世紀の70年代後半の非常に昔のことです。 その後、1つの大きな（当時の）システムをプログラムしました。 IDE（Integrated Development Enviropment）の概念はまだ存在せず、エディターを使用してプログラムコードを入力しました。
使用したエディターには1つの興味深い機能がありました。 ディスクからプログラムテキストを含むファイルをロードするとき、彼は最初にそれを表示し、モニター画面の最初の行から最後の行まで「スクロール」しました。 ダウンロードされたテキストは私の目の前で非常に速く実行されたため、この時点で個々の行を解析することは困難でした。
ある朝、次のテーブルで働いていた同僚が突然、「ああ、なんて美しいんだ！」と大声で言いました。 彼はあまり感情的な人ではなかったので、彼のテーブルに興味を持って行き、この喜びの理由を理解しました。
前夜、私たちの教祖の一人によって以前に書かれたプログラムをわずかに修正するタスクを彼が受け取ったことが判明しました。 彼の後ろに集まった聴衆のために、彼は再びディスクからプログラムテキストのロードをオンにしました。 また、プログラムコードの行は、画面の下部から上部にすばやく移動しました。 しかし、これらは私たちが慣れ親しんでいるものとは点線や破線とはまったく異なるテクスチャでした。 彼らは調和とある種の魔法に満ちていました。 彼らは本当にとても美しく、文字通り妖艶でした。 そのとき私は考えた：「そのようなコードは間違っているだろうか？」
明らかに、多分。 それ以来、私はさまざまなプログラミング言語で何百万行ものプログラムコードを自分で調べ、時には分析し、時には修正したり、書いたりしました。 そして、ほとんどの場合、優れたプログラマーは「美しい」コードと高品質なコードを生成すると確信していました。「美しい」だけでなく、ある種の「光学的に調和した」コードでもあります。
ただし、予約が必要です。 このルールは、手動で記述されたコードにのみ適用されます。 ジェネレータは、非常に構造化されているがエラーを起こしやすいコードを生成する場合があります。
コード構造とテクスチャ
まあ、私たちは概念にほぼ同意しました。 コンポーネントコードと個々のパーツの形式に分割することで定義されるプログラムコードの古典的な構造とは異なり、プログラムコードのテクスチャによって、画面上の視覚的表現を意味します。
70年代に見たテクスチャ、または今日の高解像度モニターで見られるテクスチャが、最終的にプログラムコードの構造を反映していることは明らかです。
プログラムコードの構造になると、プログラミングパターン（パターン）がほぼ自動的に思い浮かびます。
私の意見では、古典的なプログラミングパターンの使用の有無は、コードが「美しい」かどうかにほとんど影響しません。
コードの美しさは、まったく異なる構造の影響を受けます。 これらの構造は、いくつかの階層レベルに分割できます。
今日、最初のレベルは、IDEに組み込まれた適切に構成されたコードエディターによって提供されます。 それらは自動的にインデントをトリムし、忘れられた括弧や他の文字を追加し、標準のメソッドや関数の正しくフォーマットされたコードスケルトンを生成します。
第2レベルの構造は、個々のプログラムブロック（クラスやメソッドなど）の責任の選択、継承の実装、小さなブロックを大きなブロックにグループ化することに依存します。 コードのテクスチャとその「美しさ」に決定的な影響を与えるのは、これらの第2レベルの構造です。
明らかに、コードの視覚的な美しさはプロのプログラミングの目標ではありません。 それでも、光学的にエレガントなコード構造を見ると、画面上をさらにスクロールするように描かれることがよくあり、さらにいくつかの素敵なコードテクスチャが表示されることもあります。
結論の代わりに
それで、私はこのメモで何を言いたいですか？ そして、ここに何があります：
コード構造は思考構造を反映しています。
コードテクスチャはコード構造を表します。
したがって、コードテクスチャは思考の具体化の1つです。
プログラムコードが視覚的に美しい場合、作成者の考えはエレガントでした。 そして、優雅さと思考スタイルは、高いプロ意識の不可避の兆候です。
そして最後に-プログラマーに対する私の魅力：
注意を払って、もしあれば、コードの美しいテクスチャをお楽しみください。 この喜びは私たちの職業の人々にのみ利用可能です。