C ++の美しいコードとは何ですか？なぜほとんどのプログラマーはそんなに気にかけているのですか？
ほとんどのプロジェクトはC++ APIを使用しているため、APIの制約とプロジェクト自体の制約を扱います。
私はプログラミングの初心者ですが、OOPを使用するのはあまり好きではありません。他のプログラマーを防ぐためにプライベートスコープで制限することが非常に重要である理由は誰にもはっきりと説明できなかったためです。ある種のデータ編成の一貫性を壊すため。
QtやOgre3Dのような素晴らしいものを作ることができるので、私はまだOOPで大丈夫ですが、それらはAPIではなくアプリケーションであり、それらのコードは完璧である必要があり、誰も作業を批判できません。
ほとんどのプログラマーがAPIではなくアプリを作成しているため、なぜ天才的なコードを設計するように完璧なコードを作成し、これに時間を浪費するのかを理解できません。
"No man is a island"という言葉を聞いたことがありますか？
ほとんどのプログラマにとってこれは真実です。 「単なるアプリ」であるコードを書く人はほとんどいない。重要なアプリの多くでは、1人のプログラマーがUIを作成しますが、UIはデザイナーが簡単に変更する必要があります。また、ビジネスロジック（Controller、ViewModel、または呼び出したいもの）への明確なデータバインディングを可能にする必要があります。別のプログラマーがそのコントローラーを作成しますが、これはしばしば非常に複雑になる可能性がありますが、フロントエンドプログラマーが簡単に使用できるように単純である必要があります。そのビジネスロジックコーダーは、データレイヤー（モデル、リポジトリなど）を作成した人からのコードを使用しています。 OOPを使用する必要はありませんが、OOPの優れた点は、ロジックをインターフェイスの背後にカプセル化して、作業している他の人がコードを壊すことなく使用できるようにすることです（仮定）あなたはそのインターフェースをテストしました！）抽象化は特効薬ではありませんが、Ogre3dのようなライブラリーを使用すると確実にそれを楽しむことができ、自分で完全に達成することはほとんど不可能です。
だから、あなたは今「真剣に、私は例外であり、誰も私のコードを見たり、コードで作業したりすることはない」と言っているかもしれません。十分に公平ですが、数か月後にそのアプリのバグを修正する必要がある場合、またはいくつかの機能を追加したい場合は、そのコードを書いた人と、今それを変更している人が、全く違う二人。だらしないコードを書く理由の核心にあるものを覚えていると思うことがよくありますが、実際には、6か月後の自分では、アプリケーションに今行ったハッキングを覚えていません。あなたの将来の自己は十分に対処することができるので、彼/彼女に休憩を与えませんか？
どんな愚か者も、コンピューターが理解できるコードを書くことができます。優れたプログラマーは、人間が理解できるコードを作成します。 〜Martin Fowler
一言で言えば、それが美しいコードを気にしたい理由です。
コンピュータのコードを書く必要はありません。とにかく、コンピューターはバイナリコード（コンパイラーとインタープリターを経由してソースコードから生成されたもの）しか理解しません。美しさや明快さ、またはコードが想定どおりに機能するかどうかは関係ありません。
仲間のプログラマーのためにコードを書きます。そして、彼らはあなたのために同じことをします。他の誰かが書いたコードを理解できない場合、バグを見つけて修正したり、新しい機能を追加したりする可能性は何だと思いますか？
もちろん、将来再びコードが必要になる可能性があるかどうかわからないように他の人が言ったことは当然です。
しかし、私にとって重要な点が1つあります。なぜ私は常に美しいコードを書こうとしているのかです。
良くなるためのトレーニングです。
私が使用する言語やプログラミングの一般的な概念について何か新しいことを学んだら、すぐにそれを利用しようとし、それを私の日常のワークフローとメンタルツールチェーンの一部にしようとします。
OOPのようなものについてのみ読んだ場合、数週間以内にそのほとんどを忘れてしまいます。そして、小さな問題にそれを適用することによって独学しない限り、あなたはそれを大きな問題に適切に適用する方法のトレーニングを受けることは決してありません。
例：
プライベートスコープで制限することがなぜ重要なのですか？
小規模なプロジェクトではそうではありません。一部の言語（Rubyなど）は、この種のカプセル化をある程度妨げています。しかし、それには用途があります。たくさんの。
それを使用すると、特定の問題と多くの詳細を学ぶ必要があります。小さなプロジェクトでそれを使用すると、これがわかります。コンパイラからは初めてのエラーメッセージが表示され、小規模なプロジェクトでは問題の原因をより簡単に見つけることができます。
C++の名前空間について学びます。小規模なプロジェクトではそれほど必要はありません。ヘッダーファイルとインクルードの一般的な構造についても同様です。小さなコードベースを保護することで、これらすべてを早期に学ぶことができます。
それはすべて、レガシーコードを維持する必要があるということです。そして、数か月以内に、現在作成しているコードは、維持しなければならないレガシーコードになります。
R0MANARMYがコメントで述べたこと。クリーンで「美しい」コードを使用すると、自分だけでなく、他の人にとっても、将来の読み取り、理解、維持、変更、修正が容易になります。
一部の人々は、何かをするとき、それを可能な限り最善の方法で、可能な限り最善の方法で作ろうとするので、それは「完璧」、またはこの場合は「美しい」です。この一連の人々と開発者（私も含めて！）の間に大きな重複があることがわかりました。
ただし、「美しい」、「きれい」、「エレガント」は非常に主観的な用語であり、人によって異なることを意味します。私が見てきたことから、美しく、クリーンで、エレガントであると広く見なされているコード、
- 読みやすく、理解しやすい
- 不要なコードがないか、ほとんどない
- 簡単に拡張および/またはモジュール化されている
- 十分に文書化されている
- 関連する言語/技術の標準に従います
- 予期しないことは何もしません（例：アクセサメソッドの副作用）
メンテナンス性について同意します。自分で比較的大きなプロジェクトを作成してみてください。バグの修正、新機能の追加など、すべての混乱が見られます。ただし、美しさについては、
美しいコードが望ましい製品品質です（少なくとも、C++）プログラミングはARTです
[...]他のプログラマが何らかのデータ編成の一貫性を壊すのを防ぐためにプライベートスコープで制限することがなぜ重要であるのか、なぜ誰も明確に説明できませんでした。
十分に小さなコードベースを備えた十分に小さなチームで、優れた標準（たった1人の場合もある）と十分に調整されている場合、誰でもすべてのデータフィールドを操作できるように、すべてのデータを公開する信頼できるソフトウェアを見つけることができます。 struct公開されたワイドオープンとstruct定義のワイドオープンで、そのヘッダーを含むすべてのユーザーがアクセスできます。マーフィーの法則は、それらの場合に常に適用されるわけではありません。
しかし、私は数百万のLOCがあり、80年代にさかのぼる巨大なコードベースの反対のシナリオで作業しました。かろうじて同じ言語、人々がとにかく従わないことが多いSDK以外のコーディング標準、ユニット/統合テスト、ブランチなしのSVNの使用、場合によってはコードのチェックインなしの6週間、バグによる爆撃のみ、および情報を隠すと不変式を維持することの価値を本当に理解したのは、それまででした。
私は自分のマシンで一貫して問題を再現することさえできず、時にはチーム全体で誰もできないバグに対処しました。そして、あらゆる種類の試行錯誤の後で、ユーザーから報告された問題またはそれに類似した問題をようやく幸運に再現できたとき（そして、試行錯誤は、ソフトウェアの非効率性とユーザーエンドの生産に対するデバッグでの実行との組み合わせにより、多くの場合、数時間かかりましたデータは、データをロードするためだけに15分以上かかることがよくあります）、structがガベージネガティブ数に設定された文字列型のlenのようなものまで追跡します、文字列の長さ-921141282など。
それは決して起こらないはずですが、誰がやったのですか？したがって、メモリブレークポイントを設定して確認する必要があり、最終的に設定したとき、それは、初期化されていない変数の算術的に使用されるカスケード相互作用のようであり、最終的には負のガベージ番号に設定される文字列lenフィールドに追加されました、そしてそのコードは何年も変更されていませんでした。それはレーダーの下を飛んだ。
そして、このような多くのバグに遭遇した後、私は自分のソフトウェアがgettersとsettersを使用した場合、ソフトウェアの信頼性はどれほど向上するかと思いました。ゲッターとセッターは一般に、可能な最悪の種類のインターフェイス設計を示していますが、誰かが文字列の長さを負の値に設定しようとした場合、セッターは少なくともアサーションエラーをトリガーする可能性があります。私たちはそのバグyearsを、それが導入された正確な時刻で、数時間の調査努力の集大成ではなく、正確にキャッチすることができました。そして、それは開発者として利己的に考えているだけです。ユーザーとQAチームを救うことができた悲しみのすべての時間をカバーしているわけではありません。あなたが徹夜で修正した最後の35個のバグに直面してセッターとゲッターを使用した場合にどれほど改善できるかを夢見ていて、システムがかなり悪い場所にあることを知っています。
structsが他の誰もこれらのデータフィールドにアクセスするべきではなく、それらのデータフィールドにアクセスするシステム内の場所を見つけるためだけであることを文書化するケースもありました。
したがって、これらは、最悪のシナリオに直面することで本当に最大限に感謝することができるものですが、よく調整されたチームと小さなコードベースで残りの人生を過ごすのに十分な運がない限り、多くの場合、そうするでしょう。強力なコーディング標準。
C++の美しいコードは何ですか[...]？
それは難しいことです。私はまだそれを理解しようとしています。私が長年にわたって書いた、または少なくとも信頼性が高く、比較的時代を超えて安定している（変更を必要としない、または変更する必要がない）私が美しいと思うコードのほとんどはCで、最近はLuaで書かれました。私はまだ数年後にそれを振り返らず、少なくともwish変更できるまで、時間のテストに合格するように見えるC++コードを書くのにまだ苦労しています。 C++ 11以来ずっと簡単になっているように感じますが、変更を確認せずにコードがどれだけうまく機能しているかを確認するには、数年かかる必要があります。私にとって、究極の「美しさ」は「安定性」です。それ以上の変更を必要とせず、誘惑することもありませんが、メンテナンスコストがかからないコードであるため、今後何年にもわたって関連性があり有用です。