昨年、私はチーム メンバーのコードのトラブルシューティングを行っていましたが、インデントとコメントがありませんでした。私は彼にそれは良い考えではないと言って話していましたが、彼は気分を害しました。彼は私よりも頭が良かった、または確かに教育を受けていた.
それ以来、彼がマイクロソフトに応募したことを知り、二重連結リストの実装を依頼されたとき、インデントやコメントなしで書いて、スタイルについて心配する時間がないと述べました。(完了までに 2 時間かかるメール送信でした)
マイクロソフトは彼に電話をかけませんでした.....彼らはどのように応答したと思いますか?あなたはどのように応答しますか?
この場合、彼らが何をするかを提案できるマイクロソフトの誰かがここにいますか?
孤島のプログラマーはいません。誰かが自分のコードを読まなければならない日が来るでしょう。ここで何度も繰り返されてきました：
あなたのコードを保守することになる人が、あなたがどこに住んでいるかを知っている暴力的なサイコパスであるかのように常にコーディングしてください。 -- マーティン・ゴールディング(たぶん)
とはいえ、彼らのスタイルが適切であれば、プログラマーを雇う際に評価すべき重要な点が他にもたくさんあります。しかし、彼らがコメントの使用を完全に拒否したり、コードを他の人が読めるようにしようとしたりすると、それは取り決めを破ることになります.
スタイルを気にしない開発者は、色を気にしない芸術家、画家のようなものです。
コメントしない言い訳も、インデントしない言い訳もありません。インデントは最高の編集者のほとんどによって処理され、コメントは、MS が雇いたいと思うかもしれない誰かにとって第二の性質として来るはずです。
どちらも確かに、人々が (自然に、または学校教育を通じて) 習得する分野であるため、どちらかを示さないことは、おそらく、規律の欠如を示しているか、少なくともそれを表現する努力を示しています.
編集: リンクされたリストに 2 時間?! なるほど… 残りの 1 時間 50 分ですべてのフォーマットを詰め込むのは、かなり大変だったでしょう。（私はただ遊んでいるだけです - リンクされたリスト以上のものがインタビューにあったと思います！）
コードは、コンピューター、プログラマー、そして最終的にはメンテナーという 3 つのエンティティによって読み取られます。
スタイルとフォーマットはコンピューターには関係なく、おそらくプログラマーにとっては重要ですが、プログラムの機能を理解しようとするメンテナーにとっては確かに重要です。
コードを読みやすくすることによって他の開発者に対応することを拒否することは、無礼です。
意味のある変数名とコメントで整理されたコードを作成することは、それを読む他の人にとって一般的な礼儀です。
プログラミングのスタイルは非常に重要です。コメントはさらにそうです。自分のプロジェクトで自分で作業している場合でも、コードにコメントを付ける必要があります。また、チームで作業している場合、不明確で、書式設定されておらず、コメントも付けられていないコードが問題を引き起こす可能性があります。
フォーマットには何の時間もかかりません。それはくだらない言い訳です。暴力的なサイコパスのために終わったら、エディターにフォーマットさせてください。
私は彼を解雇しましたが、幸いなことに、彼は実際に雇われることはありませんでした。
私は、彼がうまくいく何かを一緒に叩くよりも、彼がきれいで、ほとんど機能しているコードを書くのに2時間を費やしたほうがいいと思います。
プログラミングスタイルは、特にチームで作業する場合に重要です。
複数の人によって書かれたレガシーアプリケーションをサポートする場合、これは非常に重要になります。
スクリプトキディだけでなく、プロであることの一部は、コードに関心を持っています。それは、他の誰かが今から6か月後にこのコード（多分あなたでさえ！）を読むことを理解することです。したがって、保守をできるだけ簡単にする必要があります。
identing を使用せず、読みやすいスタイルでプログラミングすることは、段落や改ページのない本を書くようなものです。それは素晴らしいテキストの集まりであり、私はそれを理解するのに時間がかかりません.
私は Microsoft の反応を完全に理解しています。彼にも電話をかけません。
私は彼をお世辞にして、彼は他のプログラマーよりも複雑なことを行うことができるので、他の人が理解できるようにコメントしてうまくレイアウトする必要があると彼に伝えます。
面接でそのような態度を示す人がいたら、採用を慎重に検討すると思います。マイクロソフトでさえ、チーム プレーヤーを望んでいるに違いありません。
絶対に、スタイルは重要です。特にインデントや空白などの場合はそうです。後でそのコードを維持しなければならないのは人なので、コードは人が簡単に読めるようにする必要があります。コードが読みやすいほど、保守が容易になり、最終的にそのコードの品質が向上します。
コードスタイルで遊ぶためにやってくる心理的要因があります。コードが「醜い」で読みにくい/理解しにくい場合は、そのコードの所有権を減らしたいので、最善の仕事をする個人的なインセンティブが少なくなります。コードが読みやすく/理解しやすくなるにつれて、自分が行った作業について気分が良くなり、より多くの所有権を取得したいと思うようになります。あなたが感じるコードの所有権が多ければ多いほど、より良いコードを書くことが個人的に重要になります。
マイクロソフトがどのように対応したかに関しては、私はまったく同じ方法で対応したでしょう。彼に電話をかけ直さなかったという彼らの反応はおそらく完全に正当化されたと思います（そしてそれが貢献者だったと確信していますが、コードスタイルの欠如以外の要因があったかもしれません）。
実は、それが最も長く存続するソフトウェアライフサイクルフェーズはメンテナンスです。その間、ほとんどの場合、修正、再利用、拡張などを試みるhumenによって読み取られ、分析されます。これが、読みやすく理解しやすい状態に保つための最良の理由です。読みやすさに明確に影響するスタイルについて心配する時間がないと言う人は、ソフトウェアエンジニアとしての彼の未熟さだけを示しています。あるいは、単にソフトウェアのライフサイクルを理解していないだけかもしれません。
IDE、vi、メモ帳、ホワイトボード、ポストイットのいずれを使用する場合でも、適切なプログラマーがインデントなしでコードを作成する方法を知りたいです。コードのインデントは自然に行われるはずです。彼が提出したものが次のようなものである場合、私は彼に電話をかけません (私はウィキペディアから実装をコピーしているだけで、インデントの欠如に焦点を当てています):
struct Node{
data
next
prev
}
struct List{
Node firstNode
Node lastNode
}
function insertAfter(List list, Node node, Node newNode) {
newNode.prev := node
newNode.next := node.next
if node.next = null
list.lastNode := newNode
else
node.next.prev := newNode
node.next := newNode
}
function insertBefore(List list, Node node, Node newNode) {
newNode.prev := node.prev
newNode.next := node
if node.prev is null
list.firstNode := newNode
else
node.prev.next := newNode
node.prev := newNode
}
function remove(List list, Node node){
if node.prev = null
list.firstNode := node.next
else
node.prev.next := node.next
if node.next = null
list.lastNode := node.prev
else
node.next.prev := node.prev
destroy node
}
コード スタイルが重要である理由は他にもあります。プログラマーのプロフェッショナリズムを判断するためのプロキシとして機能できます。クジャクの尾羽が健康と精力を示すように (不健康な生物は、豪華な尻尾を作るために希少な資源を投入することはできません)、プログラムのスタイルは、それを書いた人に関する多くのことを明らかにすることができます。
命名規則に一貫性がなく、コメントがほとんどない不適切な形式のコードを目にすると、そのようなコードは本質的に判読できないという理由だけでなく、コードがこの厄介な表面の下にさらに深刻な問題を抱えている可能性が非常に高いため、それを避けます。
インタビューでは、コードをインデントしたりコメントしたりしなくても問題ありません。実際、あなたがそれをする時間があれば、私は驚かれることでしょう。通常、私たちはそれほど多くの時間を与えません。
ただし、一般的な慣例として、コードをインデントし、必要に応じてコメントを追加してください。実際、私たちのビルド マシンは、コードにスペースの代わりにタブを含めるなどの些細なことで失敗します。
コードの読みやすさは重要です。1 つの大きな段落 (構造化された小さな段落ではなく) を読むのが好きな人がいないのと同じように、書式設定されていない 1 つの大きなコードの塊を読むのが好きな人はいません。
インデントがないことが良い考えだと考える人がいるとは信じがたいです。それはばかげています、彼が面接で私のためにそれをしたとしても、私は彼に電話をかけません.
コメントは少し灰色ですが、優れたコードは大部分が自己文書化されています。優れたコードを書くのであれば、何が起こっているのかが本当に複雑でわかりにくい場所にのみ、コメントを控えめに配置する必要があります。
プログラミングのスタイルは非常に重要です。きれいなコードは目を楽しませ、プログラムの保守性を向上させます。したがって、それはプログラム自体の品質とアーキテクチャに直接関係しています。
インデントを強制する言語でさえ、悪いスタイルですべてを壊してしまう可能性があります。したがって、インデントやコメントの欠如が不適切なスタイルであるとは限りません。実際、私はコメントをほとんど使用しません。むしろ、docstring と全体的により良いドキュメントを作成することを好みます。修正すべき点や気になる点が本当にある場合は、コメントをコード全体に広げた小さなメモに関連付けます。
プログラミング言語にあなたの仕事の一部をさせないこととして、悪いスタイルを見たいと思います。1 つまたは 2 つの場所で適切に、きれいに記述されたマクロは、悪いというよりむしろ良いスタイルです。
彼がすぐにコメントを入れなかったのは気にしない。しかし、インデントは重要です。あなたがコードを書くとき、それが狂乱をタイプすることの1つの適合で直線的に出てくることはめったにありません。
いいえ、コードをテストしてデバッグする前であっても、通常は多くの編集が行われ、コード構造を明確に確認できることが重要です。
これは私のキャリアの早い段階で起こった事件を思い出させます。私はジュニアレベルのプログラマーでしたが、別のジュニアプログラマーが彼のコードについて助けを求めてきました。当時はPascalを使用していました。彼のコードはめちゃくちゃでした。インデントのないコードはこれまで見たことがありますが、ランダムなインデントのあるコードは見たことがありません。それに従う方法はありませんでした。
それで、私が最初にしたことは、インデントを修正することでした。彼はこっそりと言った。「それで問題が解決するとは思わない！」コードを振り返りました。エラーを簡単に見つけることができたので、それを指して立ち去りました。
私の意見では、スタイルが重要ではないと言うことは、スペルが重要ではないと言うことと同じです。あなたのスタイル（またはスタイルの欠如）が読みやすさの問題を引き起こしている場合、チームがこの人が書いている/編集しているファイルを扱うのは難しいでしょう。
同様に、プログラマーがコメントブロックや関数名などで単語を正しく綴るのに時間がかからない場合、コードを解読しようとしている他の開発者に問題が発生します。私はいつも自分に問いかけます。「自分で、これを1週間で見れば理解できますか？来年見ても理解できますか？」（または、少なくともドキュメントやコメントを読んで、思い出をジョギングすることができます）。
私にとって、ifブロックの次の行に中括弧を配置するのではなく、条件文の最後に中括弧を配置するのかについて話しているときは、スタイルは重要ではありません...コーディング標準を満たしている限り、内部的に一貫しています、およびチームの他のメンバーは同じアプローチを使用します。そうは言っても、コードの可読性に影響を与えるのであれば、スタイルは非常に重要だと思います。
MSは非常に大企業であるため、チームプレーヤーであると同時に、問題解決者になることができる人を探しているのではないでしょうか。「スタイリングする時間がない」と言う人は、私にはチームプレーヤーではないと出くわすでしょう。
いい質問です！
あなたの友人は彼の優先順位を正しくする必要があります、そして私の意見では、マイクロソフトはあなたがそう思うよりももっと気にかけるだろうと私は信じています。
さて、人生があり、それからインタビューがあります。
あなたの友人に聞いてください-彼はボロボロのジーンズと汚れたTシャツでインタビューに現れますか？
面接での彼の仕事は（形式に関係なく）、面接を行っている人に感銘を与えることです。仕事を提供されるのに十分な印象を与えます。
では、プログラマーの仕事に応募する場合、なぜこの男は「ボロボロのジーンズと汚れたTシャツ」のコードを提出するのでしょうか。
この人がコーディングスタイル、コメント、空白についての手がかりを持っていることを本当に望んでいます。その場合、彼はインタビュアーが「良さ」（私の解釈）よりも「正しさ」に関心があるという判断を下しました。
しかし、タスク（リンクリスト？これはプログラマーにとって簡単なはずです）を考えると、タスクはコードの単なる「正しさ」以上のものであるように思われます。
インタビュアーは、優れたコーディング手法を含め、多くのことを探していたのではないかと思います（最初から正しくコーディングするよりも、悪いプログラミング手法を「学ぶ」のは1000倍難しい）。インタビュアーはおそらく、イニシアチブ、適切な仮定の作成、おそらく創造性や創意工夫を示す何かも探していました。
たとえば、「正しい」リンクリストを作成する方法はたくさんありますが、（再帰を使用するなど）一部の方法は他の方法よりも「エレガント」であると見なされます。
このインタビューでは、あなたの友人がいくつかのレベルでマークを逃したのではないかと思います。
-R
これがコーディング標準が必要な理由です。チームは、通常のコーディング方法ではない場合でも、標準に準拠する必要があります。彼は私が持っているような他の誰かの混乱を実際に維持するためにたくさん学ぶことができました。7000行のC++は、7つのメソッド（ほとんどのメソッドは600行以上）に分割されたCスタイルで書き込みます。多くの1行のマクロには、メソッド内のラベルへのgotoが含まれています。また、ifステートメントが1行あり、これらのメソッドや他のメソッド呼び出しの最後にマクロが追加されていますが、スクロールして表示する必要があるため、表示されません。そのひどい変数名と一貫性のないブラケットスタイルに追加すると、保守不可能な混乱が発生します。良い点は、それがうまく機能し、私たちは何年もの間それを信頼してきたということです。
コーディング スタイルは、私たちのソフトウェア プログラマーの種類を反映していると考える傾向があります。
もし私たちが世間で気にせずずさんなコードを書いたら、そうです、私たちは他のチームメンバーを尊重しないという態度を描いていると思いますが、時間をかけて理解できるスタイルで書き、意識的に確実にしようとするなら私たちのコードが読みやすく、正しく構造化されている場合、私たちはチームに敬意を払う態度を示していますか?
スタイルとは、私たちが何を知っているかというよりも、私たちが誰であるかということです。
「スタイル」(私はむしろ「フォーマット」と呼んでいます) について: それは主に個人的な好みの問題ですが、チームで作業することは非常に重要です。 Eclipse ではフォーマッタ構成をエクスポートし、キーを押すとファイルがフォーマットされます)。すぐに誰もが標準に慣れ、コードを読むことの疲れが非常に少なくなるでしょう。
コメントについて: 私は自分のメソッドに適切な名前を付けることを好みますが、最もあいまいな部分の 2 つについてコメントすることは必須です。
実際にコードを書くよりもコードのインデントに多くの時間を費やすと、問題になる可能性があります。ただし、ソース コードのスタイル、規則、およびソリューション全体の一貫性は重要です。
そのため、ツールに頼っています。Resharper を使用すると、Ctrl+F キーと E キーの組み合わせを押すことで、すべてのコードを再フォーマットできます。
ソースコードを書いた後に破棄したい場合は、スタイルを無視しても構いません。これは、タスク用に作成した、実際には 1 回しか実行されない高速スクリプトに適用されます。一方で、一度だけ実行されるはずだったタスクが後で再利用されることは、どのくらいの頻度で発生しますか。
再利用は問題ないかもしれませんが、後で何が起こるかを理解するのが難しくなります。後でコードを変更したい場合は、何らかのスタイルがないと失われます。
適切なスタイリングがどれほど重要かは、コードを使用および変更する期間と、コードで作業する数によって異なります。
チームで作業する場合は、どのスタイルを適用するかについて話します。
It's said that 80% of the lifetime of a project is spent on maintenance. If your code is unreadable, you're bound to be wasting a lot of time for whoever is maintaining your code, and inevitably, you will make them think evil thoughts about you.
From what I've seen, though, most teams of programmers (or even a whole company, sometimes) have a document or something explaining the code conventions and styles they adhere to. It is therefore quite easy on your first day of working there to input their rules into your IDE and just have it auto-format your code so you won't have to worry about it. Even better, you can probably find someone who is willing to "export" their prefs file so it's just a matter of a few clicks until all the code you'll ever write at that company is formatted perfectly.
That being said, you won't always have access to these team-specific conventions (say, for instance, in an interview). It is always a good idea to follow some basic conventions that make sense. Depending on your language, a good idea would be to Google "yourLanguage code conventions" and read up on the basics. What's important in the interview situation is that you follow some basic guidelines and have a formatting style that you stick to. If you make the bracket after an "else" statement on the same line once and write it on the next line another time, you're probably telling the interviewer that you don't really care enough and/or you don't have enough experience that one way has become a habit for you.
あなたが信頼できる唯一のことは、あなたがいなくなった後にあなたのコードを見た人はあなたがばかだと思うだろうと私はいつも感じていました。重要なことは、コードが最初に表示されてからその判断が下されるまでの時間を最大限に延ばすことです。
適切な書式設定は N を増やす 1 つの方法であり、有益なコメントは別の方法です。
ソースコードの対象読者が誰であるかが問題です。正解は「その他のプログラマー」（メンテナーなど）です。あなたの同僚は、それは重要ではないと考えていました。なぜ MS が彼を雇わなかったのか、私には十分に理解できます。大企業が彼を雇うとしたら、私は驚くだろう!
「Communications of ACM」に掲載された「タイポグラフィ スタイルは見た目以上のものである」というタイトルの古い記事を覚えています。この記事では、適切にフォーマットされたコードが生産性に与える影響について実験を行いました。
彼らはプログラマーのグループを選び、ランク付けするためのテストを行いました。次に、グループを 2 つに分け、同じ割り当てを 2 つのグループに分けました。ソフトウェアの一部を変更して機能を追加します。
最初のグループは適切にフォーマットされたソース コードを使用し、他のグループは同じコードの乱雑なバージョンを使用しただけです。
彼らは再び生産性を測定し、最終結果は、最初のグループの最悪のプログラマーが、2番目のグループのより良いプログラマーよりも良いスコアを出したということでした.
それ以来、私は自分のコードを他の人が読めるように明確にするために常に特別な努力を払ってきました.
このトピックに興味がある人は、文芸的プログラミング、意図的プログラミング、およびその他の関連する概念について読むことをお勧めします。
「彼はスタイルについて心配する時間がありませんでした...」彼らが彼に電話をかけなかったのも不思議ではありません. 直接のインタビューにも応じず、すでに要求されたことを拒否しているのですか？これは、どの職業の面接にも合格しないための良い方法です。
スタイルは、私たちが行うすべてのものに固有のものです。オーバーレイではありません。アドオンではありません。それは特典ではありません。使う使わないに関わらず存在します。物事 - プログラム、製品、あなたが持っているもの - はスタイルによって改善されません。彼らは良いスタイルを持つことによって改善されます（その反対は単に悪いスタイルを持つことです）.
非常に技術志向の観点から来る人々の問題は、美的関心や評価によってバランスが取れていない場合、「スタイル」はプログラマーが使用しないツールであると想定されることです。「スタイル」とは「UI やマーケティング担当者に任せる」という意味です。それは単に真実ではありません。最善を尽くすためには、仕事のあらゆる面を改善しなければなりません。つまり、実行だけでなく、プレゼンテーションも意味します。
人間は視覚指向の生き物です。見た目で選んでいます（プリティガール！ピカピカのパッケージ！）。
スタイルを考える時間がないことを明確に宣言することで、彼は基本的に、Microsoft が求めていた光沢のあるパッケージではないという印象を与えました。そして、そのような明らかな事前謝罪により、彼はインデントとコメントの欠如を評価者に明らかにしました（ただし、コメントの欠如だけで彼を雇うことはなかったでしょう）.
適切に記述されたコードにはコメントは必要ないか、少なくともコメントはほとんど必要ないと主張できます。しかし、インデントの欠如は受け入れられません。コンパイラーは (ほとんどの場合) 気にかけますが、コードを保守している人々は気にかけます。
コーディング スタイルはかなり重要です。ほとんどの主要な開発会社には、必要な命名規則、コメントのガイドライン、およびコード スタイルとアーキテクチャのガイドラインに関するその他の細かな事柄を定義するドキュメントがあります。
これらはすべて非常に優れており、チーム メンバーが同僚のコードがどのように見えるかについて期待できる作業環境を促進するのに役立ちます。
次のようなコード レビューで、開発者に変更を強制するマネージャーのレベルまで下がらないようにしてください。
if( someBool() ) doSomething();
else doNothing();
彼らが「より良い」スタイルを「感じる」という理由だけで、このようなものに：
if( someBool() )
{
doSomething();
}
else
{
doNothing();
}
スタイルの要件について個人的な好みよりも優れた理由があれば、私たち全員がより幸せになることができます.
読みやすさを重視したスタイルが重要です。とっても大事。
多くのプログラマーはコメントの頻度と使用について議論していますが、ほとんどのプログラマーはそれらが必要であると主張しています。
インタビュイーが自分のコードにコメントすることは期待していません（インタビューのその場でコードを書いていると仮定します）。しかし、経験豊富な誰かにインタビューしていて、彼らがコードをインデントできなかった場合、それは確かに彼らに不利になります。インデントが完璧であったり、好きなスタイルであったりすることは期待できません。しかし、インデントしたほうがいいです。それはコードを書くことの一部です。
私が経験のない人を募集している場合（そして私は通常そうです）、それは問題ではありません。しかし、私は彼らに二重にリンクされたリストを書くように頼むつもりもありません。
私たちが判断するものの多くは見た目やスタイルであると思います。インデントやコメントなしでコードを見て、その中の天才を見るのは難しいでしょう。ほとんどの人はそれを見て、これはあまりにも複雑すぎると思います。書き直してみましょう。
提出する前に、おそらくマイクロソフトのコードスタイルガイドを読んだでしょう。あなたが汚れた服のインタビューに足を踏み入れないのと同じように、私はインデントされていない読めないコードを提出しません
何を言っているのか....新しいコードを書くことはセックスのようなもので、速くてエキサイティングです...コードを維持することは、セックスから生じる子供の世話をします。それも...
面接のコーディングテストでコメントを表示しないことは、試験を受けて何も機能していないことを示すようなものです。
確かにコメントは、プログラマーの戦略と思考への洞察の1つである必要がありますか？
プログラミング スタイルは、コードの識別とコメントだけに限定されません。
コード識別は、コードの可読性にとって非常に重要です。読みやすいインデントされていないコードを見たことがありません:)。
また、非常に重要なのは、コードが自明であることです。コメントは、実装がさまざまな理由で不可解になった場合、またはコードが明確に反映されていない場合にのみ使用する必要があります。過剰にコメントされたコードをたくさん見ましたが、ほぼすべての行にコメントがあるのを見るのは、侮辱のページを読んでいるようなものです。
とにかく、Microsoft が二重リンク リストの実装についてコメントしなかったという理由だけで、あなたの同僚を拒否したとは思えません。
コメントが多すぎると、読みやすさが低下する可能性があるため、コメントは両刃の剣と見なすことができます。ジェフはこれについて素晴らしい記事を書きました
それどころか、インデントは害を及ぼすことはなく、読みやすさを大幅に向上させます。これが、非常に多くの人が Python の重要な空白を好む理由の 1 つです。
これについては、上で述べたようにいくつかの見解があります。基本的に、スタイルとコメントは保守性に役立ちます。
コードはコンパイラーのためではなく、プログラマー (あなた自身を含む!) のために書かれています。コードを読む必要がない場合は、(本物のプログラマーのように!) 16 進パッドで打ち込んで完了です! :-)
しかし、そのようなことはほとんどありません。コードの有効期間中、コンパイラはコードの処理に合計数秒を費やす場合があります。しかし、プログラマーは何日も費やすことがあります。また、読みにくい、または理解しにくい場合は、その日数が数週間に及ぶこともあります。コードを自己文書化するために努力する必要がありますが、それに依存しないでください。これまで。
インデントは制御フローを示します。インデントのない一連の行には制御フローがある可能性がありますが、それを検出するには各行を読み取る必要があることを意味します。
if(someSituation) somethingElse++;
対。
if(someSituation)
somethingElse++;
2番目のバージョンは視覚的に飛び出します。決定が下されたことを確認するために、コードを読んで理解する必要はありません。コードをスキャンして何かをすばやく見つけるときに非常に重要です。
ほとんどの IDE とプログラミング エディターでは、コード ブロックを即座にインデントできます。これは非常に簡単なので、ぶら下がっている「else」やその他の演算子のヘッドスペースの問題が発生しないようにするためだけに実行する必要があります。インデントがないことを正当化するのは非常に困難です。
コメントも重要です。コメントがコードと一致しない場合、それらは両方とも間違っています (誰が最初にこれを言ったか覚えていませんが、彼/彼は死んでいます!)。
最初にコードをレイアウトするときにコメント ブロックを挿入し、次にコードを記述してデバッグし、再度コメントを確認します。問題を誤解している (コメントを変更する) か、間違ったことを実装している (コードを変更する) ことに気付くかもしれません。または、ライブラリ関数を再実装し (最終的に奇妙なことをする必要がある場合に備えて、一時的にすべてコメントアウトして)、関数の呼び出しを行ったことに気付くかもしれません。
不適切な名前のライブラリ関数を使用しなければならない場合があります。RTFM と言って先に進むか、要約コメントを入れて次のプログラマ (おそらく 6 か月後の自分) の労力を節約することができます。
// This allocates space for the message queue and initializes
// some OS overhead. All that remains after this is adjusting
// priority and content and then send the message.
prepareMessage(&myMessage);
さらに、2 日間かけてバグを調査し、コードに小さな変更を加えた場合、設計時にその変更が明らかでなかった可能性が高くなります。そうでなければ、そもそもそこにあったでしょう！したがって、将来誰かが「明白な」実装に戻すのを防ぐためにコメントが必要です。
memset(&myStatus, 0, sizeof(myStatus));
// The size member must be set before getting current values.
// This is used by library function GetCurrentStatus() to infer
// a version of the status structure.
myStatus.length = sizeof(myStatus);
GetCurrentStatus(&myStatus);
インデントされていない場合、私は彼のコードを読むことさえ気にしません。時間がないというのはひどい言い訳です。入力したコードをインデントするのに数秒かかります... ほとんどのエディターが自動的にインデントするという事実は言うまでもありません。おそらく彼は時間がなくなったかもしれないとコメントしていますが、それでもそれはまだ非常に貧弱な言い訳です. 作成したばかりのコードにコメントを付けるのに、それほど時間はかかりません。
インデントは自然に来ると思います。何かを自動的に書くたびに、私はそれをします。そうしないと混乱します。
コードは設計図のようなものだということに気が付きました。豪華な家の設計のためのよく計画された、美しく見事な青写真は、よく構造化され、役に立ちます。コードは同じである必要があります。
IDE 書式設定スタイルを使用しようとしています。そのため、コードの書き方に関する新しくて退屈な定義を避け、その結果、インデントとフォーマットの違いによる不要なマージを避けています。
ドキュメンテーションは、最もばかげたコードであっても必須です。コード内にドキュメント行を生成するためのテンプレートがあると便利です。チーム内での標準化と組織合意が最良のスタイルです。
IDE やプログラミング エディター、コード リフォーマッターは世の中に出回っています。ショップは、その目的に合ったスタイルを採用し、必要に応じてリフォーマッターを使用する必要があります。
要するに、インデントと区切り記号の配置は、もはやそれほど大したことではありません。
仕事に応募する際のコーディングに関しては、明示的に要求された場合を除いて、書いたコードにコメント/インデントを付けないという理由で候補者を却下するのは少し厳しいと思います。
いいえ
プログラミングスタイルは絶対に重要ではありません。重要なのは保守性と読みやすさです。
順調に進むためには、均質で読みやすいコード形式でチームを強化する必要があります。どちらでも構いません。誰もが喜ぶことはできず、コード形式を変更するソフトウェアがあります。
言語が複数のパラダイムを受け入れる場合は、1つだけを選択しようとしないでください。コードが十分にコメントされていて、その仕事をしている限り、誰がそれを気にするのか、その人は機能的または命令型のスタイルを使用しましたか？