作業中にコードをコンパイルすることには利点がありますか?


183

最近、就職の面接を受けました。実際のコードを書くのに1時間かかりました。それほど多くはなく、おそらく100行未満でした。約45分後、コンパイルして実行し、動作するようになりました。コンパイルエラーと2、3の小さなバグを解決するのに5〜10分かかったかもしれませんが、全体的に非常にスムーズでした。(ちなみに、私は彼らから申し出を受けました。)

しかし、私が戸惑ったのは、完成したコードを渡した後、インタビュアーが私が間違ったことは「進行中にコンパイルしない」ことだけだと言ったということでした。私は彼に違いは何であるかを尋ね、彼は「もしあなたがコードを完成させ、それが時間内にコンパイルしなかったらどうするだろう」と言った。

私の理解では、それは無効な引数です。なぜなら、特定の長さのコードに対して「コードをコンパイルする」には、通常、一定数のコンパイルエラーの修正が含まれ、かなり一定の時間がかかります。コードの記述を終了するか、コーディング時間をインターリーブする場合。どちらかといえば、欠落しているセミコロンを検索するためにコーディングを中断することは、おそらくあなたの効率に有害です。派生クラスの仮想関数などのエッジケースの周りの不明瞭さを実験している極端な状況を除いて、経験豊富な開発者によって書かれたコードは、時折の入力エラーを除いてコンパイルされることを期待するのが妥当と思われますそうでない場合、それは '

別の同様の事件では、インタビューで不完全なコードベースが与えられ、それを完成させ、それを実行するために必要な変更を加えるように頼まれました。最初に既存のコードを読んでから、数分後(コードを見終える前であっても)、インタビュアーはそれで十分だと言った。私が彼に何をしたか(すなわち、「私は何を間違えたのか」)と尋ねたとき、彼はすぐにコードをコンパイルすることから始めたと言った。

なぜそれが関連するのでしょうか?私の意見と私の経験では、コードの一部がコンパイルされるかどうかは本質的にランダムであり、セミコロンが欠落しているかどうかなどが含まれており、基礎となるプログラムの正確性とはほとんど関係ありません。(私にとって、コンパイルに焦点を当てることは、文法をチェックするために校正せずに記事をスペルチェックに通すようなものです。)

不完全なコードを教えてくれた場合、最初にすべきことはそれを読むことです。コードが何をしているのかがわかり、アルゴリズムが正しいことがわかるまで、コンパイルしようとはしません。

とにかく、これらは最近のいくつかの事件に過ぎませんが、一般的に、多くの開発者がコードの進行について話をしているのを聞いたことがあります。あなたがコードをテストする利点を理解していますが、なぜコンパイルするのですか?

だから私の質問はこれです:私が逃したものはありますか?実際にコンパイルする利点はありますか?または、これはソフトウェアコミュニティによって伝播された神話のようなもので、コードを頻繁にコンパイルする必要がありますか?


54
それとも、私の習慣は、異なる習慣を持つ人々から悪い習慣と呼ばれています。
キャプテンコードマン14年

9
@DocBrown最終目標が正しい製品を持っている場合、比較は有効です。「実行」するプログラムは、正しく実行されないプログラムよりも優れています。文法の間違いを修正するためのスペルチェックが期待できる以上に、コンパイルがコードをチェックすることは期待できません。
キャプテンコードマン14年

7
コンパイルがワークフローを妨げるかどうかは非常に主観的であり、言語、ビルド環境、プロジェクトのサイズ/複雑さなどに依存します。IMOは大規模なレガシープロジェクトで問題になる可能性が高くなります。
pjc50 14年

64
OPに完全に同意します。誰かが自分の仕事の習慣についてどのように判断することができるか、たとえばコンパイラを起動するために使用するときなど、理解できません。重要なのは、努力の成果です。それが正しいか?保守可能ですか?予想される時間内に実行されますか?実装にどれくらいかかりましたか?これらは興味深い質問です。他のすべては任意のBSです。インタビュイーが最初の試行でコンパイルする2時間の完璧なコードを書いた場合、問題はどこにありますか?インタビュアーが異なる方法でそれを行うからですか?私の神。
JensG 14年

9
また、特定の言語とIDE(Java / [Eclipse | NetBeans | etc]、C#/ Visual Studioなど)については、入力時にリアルタイムでIDEがすべてをバックグラウンドで既にコンパイルしていることにも注意してください。間違いを犯したかどうかについて、即座にフィードバックループを提供します。IDEの開発者が、このコンパイル時のアプローチのアプローチを裏付ける研究を希望することでしょう。
オーガ詩sal 33 14年

回答:


223

実際にコンパイルする利点はありますか?

がある。これにより、フィードバックループが短くなります。一般に、設計(UI、ソフトウェアの作成、ビジュアルデザインなど)が良いことです。

短いフィードバックループを使用すると、エラーの修正がより高価になる前に、エラーを早期にすばやく修正できます。

あなたの例を借りるには、Cライクな言語でコーディングしていて}、プログラムの途中でどこかを忘れたとしましょう。

ステートメントを書き終えた直後にコンパイルする場合、コンパイルエラーを導入したばかりで、そこで数秒以内に修正できます。

ただし、そうでない場合}は、修正が実際に意図されたものであるというエラーを見つけたら、コードを読んで正確な位置を探し、確認するのに十分な時間を費やす必要があります。これは、そのコードの一部を残してからしばらくすると起こります。あなたが書いた瞬間ほど明確ではありません。


今、はい、最終結果は同じですが、コンパイラがあなたを助けるためにそこにある構文上の問題にかなりの時間を浪費しました-あなたが行っているようにコンパイルした場合、大幅に短縮できる時間。


72
確かに、そのような構文エラーの場合、最新のIDEは基本的に常にコンパイルと再コンパイルを行い、フィードバックループを合理的にできるだけ短くします。これは、軽微なミスをキャッチするのに不合理に役立ちます。
Phoshi

12
@CaptainCodeman-かなり多くのコードを掘り下げる必要があるコンパイルエラーがあると思います。これは、より大きなコードベースとより大きな変更セットに対してより当てはまります。
オデッド

29
コンパイラは、gccテンプレートエラーなどのヒントではなくパズルを表示する場合があります。
pjc50 14年

14
@ pjc50:絶対に(これは、次のコンパイルの前に一度に多くのものを変更しないことで処理が容易になるため、最後に変更した内容を正確に把握できます)。
ドックブラウン14年

21
アイデアは、ランダムにコンパイルするだけではありません。重要な各ステップでコンパイルし、適切に動作すると予想されるときにコンパイルします。たとえば、コンパイルして、オブジェクトが適切に作成/削除されていることを確認するか、作成した新しいクラスに対してイベントが適切に発生することを確認します。クラスを作成し、何らかの方法でプログラムにフックする場合は、アプリに他のものをフックする前に、正しくクラスを作成したことを確認したいと思います。小さなアプリではそれほど重要ではなく、大きなアプリには不可欠です。
Thebluefish 14年

108

コンパイル、特にHaskellMLなどの型を広範囲に使用する言語でのテストの形式です。他の言語では、ほとんど意味がない構文スキャンです。

そうは言っても、「あなたが行くようにコンパイルする」というのは非常に状況的な習慣のようです。同様に、面接官の個人的な偏見よりも頻繁にコンパイルすることで「けいれん的」であると評価されることもあります。ちょっとしたピッキングのようですね。インタビュイーがテストに合格したことを認めるのを好む人はいません。給与交渉の規模を決めるものです。

すべてのビルドシステムが高速というわけではありません。Makeがビルドに必要かどうかを判断するためにすべてをstatするだけで30秒費やし、変更を加えた場合、ほとんどのファイルはビルドに数分かかる(C ++)プロジェクトに取り組みました。10〜15分ごとよりも頻繁にこれを行うことに消極的でした。誰かが間違いなくパンチカードのデッキを別の建物に運ぶというコンパイルの逸話を提供するでしょう...

頭の中で完全な概念単位を実行し、それを検証する準備ができたと感じたらコンパイルします。ワークフローに応じて、1分に1回または週に1回。


25
ロードするためにsysopsにパンチカードを持っていくとき、正しい順序に戻すことは本物のPitAであるため、決してドロップしないようにしてください。ああ、重要なデバッグツールがエラスティックバンドであった時代。
gbjbaanb

3
プログラミングを始めたとき、コンパイルせずに書くことができるコードの量、つまり基本的にはメンタルコンパイラの品質によって、進捗状況を測定しました。最初は数文字で、それから数行でした。今、私はそれを気にしません。わずかな変更で多くのコンパイルを行いますが、その効果を確認したいだけです。プロジェクトの構造レイアウトを行うときにはほとんどコンパイルしません。
フィル14年

うーん。よく書かれたC ++ファイルは、コンパイルに数秒以上かかりません。それより長い場合、それは悪いコードの匂いです。そして、makeに問題があるほど大きい場合、アプリケーションがモノリシックすぎると主張します。「私の」makeには問題がなく、Linuxをコンパイルするときでさえ不公平でした。
フレネル14年

2
私が去ったときは150万LOCでした。LinuxはC ++ではなくCです。gccではテンプレートが遅いようです。コンパイルに時間がかかる賢い便利な機能を実行した場合、コンパイラをプロファイリングしてそれが何であるかを簡単に確認する方法はありません。
pjc50 14年

21
@gbjbaanb「ソース管理がエラスティックバンドであった時代」と言った方が良いと思います。;)
JasonMArcher 14年

35

だから私の質問はこれです:私が逃したものはありますか?

はい:あなたの心はコンパイラではありません。コンパイラーは1秒あたりn個のコンテキスト切り替えを行うことができますが、あなたの心はできません。1日に思いつくことができるコンテキストスイッチの数は、コードベースの経験/知識、コードにどれだけ精神的に浸っているか、コードがどれだけきれいか、取り組む問題の複雑さなどの多くの要因に依存します。頻繁に中断されたり、騒がしい環境にいる場合など、あなたがどれだけ疲れているか。

コードベースをコンパイルする(すべて同時に)、初めて(「20ファイルのプロジェクト」を考える)、考えているものからコンテキストを切り替えることを強制します(たとえば、「この値は5に設定されてから、 forループblablabla、および複雑なアルゴリズムは、戻り時に正しい値を生成します」)、あなたが考えているもの(完全に異なるファイル/モジュール/関数/前提条件/構文/変数名、前提条件など)とはまったく関係のないコンパイル問題)。

一度にコンパイルするコードが多いほど、より多くのコンテキストを切り替える必要があります。これは小さなコードベースでは問題になりません。1時間以内に記述したコードがすべて記述されている場合です。ただし、既存のコードベースで作業する場合、相互に依存する複数の(多くの場合文書化されていない)大きな問題です。

実際にコンパイルする利点はありますか?

頭の中で行わなければならないコンテキストの切り替えを最小限に抑え、変更の影響と副作用にもっと集中できるようにします。また、疲れにくく(ミスも少なく)なり、出力の品質が向上します(つまり、10個のファイルをコンパイルして変更するときよりも、一度に1つのファイルを変更してコンパイルするときの副作用を最小限に抑えることができます)。

非常に短い反復でコンパイルする場合(これは、コンパイルプロセスが短時間で最適化されることを前提としています)、「ゾーン」から抜け出すことなくコンパイルエラーを修正することが可能です。

または、これはソフトウェアコミュニティによって伝播された神話のようなもので、コードを頻繁にコンパイルする必要がありますか?

ソフトウェアコミュニティによっても伝播されますが、その背後には正当な理由があります。

私の理解では、これは無効な引数です。なぜなら、特定の長さのコードに対して「コードをコンパイルする」には、通常、一定数のコンパイルエラーの修正が含まれ、かなり一定の時間がかかるためです。

中規模から大規模のレガシーコードベース(数百または数千のソースファイル)の保守に関して、ほとんど(まったく)経験がないように思えます。これは、この態度(つまり、「あなたが行くようにコンパイルする」)が最も役立つ場所であり、このような習慣を形成する場所です。

あなたの意見を聞いた人たちも同様の結論を下したと思います(「大規模なコードベースの経験がほとんどない、またはまったくない」)。


1
「10のコンパイルと変更」-これが試行する最小の意味のあるユニットである多くの状況。関数やそのすべての呼び出しサイトに新しいパラメーターを追加するなど。
pjc50 14年

7
コンテキストスイッチ。冗談でしょ?自動化されたバックグラウンドコンパイルについて話して、コードの構文エラーを示すときに、それで問題ありません。ただし、最速のコンテキストスイッチでは、アルゴリズムロジックが正しく実装されているか、アルゴリズムがまったく適切かどうかを判断できません。しかし、それがきちんと整理された、エラーのないコンパイルされた高速な、しかしまったく間違ったコードとは別に、実用的なソリューションを設定するものです。
JensG 14年

5
@JenS、いいえ、私は冗談ではありません。コンパイルエラーを修正するためにコード全体をジャンプする必要があるため、現在解決している問題について考える必要がなくなります(ゾーンから抜け出します)。代わりに、コードを記述するときにコンパイルできる場合は、構文ではなくアルゴリズムのチェックに取り組み続けることができます。コンテキスト切り替えを処理する最速の方法は、それらを必要としないことです。ただし、私の投稿では理想的な世界を想定しています(大規模なコードベースの高速C ++コンパイルと相互依存性の最小化)。
utnapistim 14年

1
論理的な誤fallのように見える@JensG:これは、コンパイルされたコードとくだらないコードを選択することではなく、複数回コンパイルすることの考えられる利点についてです。
ヨルグ14年

1
単一の構文エラーを修正するために短時間で集中を数十回中断するという主張は、一度中断して数回の構文エラーを修正する(実際のアルゴリズムを心配した後)よりも速いとは思いません。それは確かに、コンピューティングにおけるコンテキストスイッチの仕組みではありません(ここでは、スループットの最適化を試みています)。そして、私は10年以上にわたって進化してきた約50万のLoCのC ++コードを使用したプロジェクトに取り組んできたので、まだ経験の浅いカードを引き出さないことを望みますか?
VOO

26

ここには、ちょっとした専門的な索があります。その意味は、「定期的にコンパイルする必要がなかったなら、複雑なものを扱ったことは一度もなかったということです。私たちのやり方とまったく同じように働くことを学んだら、さらに経験を積んで戻ってきてください。」

しかし、明らかにこれには別の側面があります。一部のプロジェクトはコンパイルに時間がかかります。わずかな編集を行ってもコンパイルに30分以上かかるフレームワークを使用しました。ヘッダーファイルを編集する必要がある場合は、Heavenが役立ちます。通常、完全な再コンパイルは一晩で行われます。コンパイラを使用してミスを検出している場合、部分的なビルド中に検出されないまれなエラーがまだあります。これらの条件下では、5分ごとに再コンパイルする必要はありません- 怠feelingな気分でない限り

コンパイラは論理エラーまたはセマンティックエラーを解決することはできません。構文エラーは、コンパイルに1日の半分を費やす価値があることを回避するのが難しくありません。もちろん、時折タイプミスをすることもありますが、タッチ入力と読み取りの両方ができると仮定します。自由に選択できる場合は、レイアウトをうまく活用するコーディングスタイルを使用して、エラーを視覚的に強調表示し、ブレース、ブラケット、またはセミコロンを再びドロップしないようにします。それは少し練習し、ほとんどが慣れているよりも少し規律がかかりますが、それは可能です。プレーンテキストエディターで一度に2、3時間コードを記述し、10回中9回以上初めてコンパイルできます。確かに、もっと頻繁にコンパイルすることはできましたが、結果として修正しやすいエラーが最後にあったことを思い出せません。

あなたが絶え間ない再コンパイルのファンでないなら、あなたは良い仲間です。ドナルド・クヌースは次のとおりです。

あなたの本当の質問に関しては、完全に未知の環境で自分のやり方を感じており、何が機能し、何が機能しないかについてのフィードバックが必要な場合、即時コンパイルと「ユニットテスト」のアイデアは私にほとんど訴えません。そうしないと、実行する必要も考えもする必要のないアクティビティに多くの時間が無駄になります。


すべてのことは...言われているならば、あなたはコンパイルがなぜないだろう、フリー・アクションであるコンテキスト内で作業していますか?自宅では、個人的なプロジェクトで、コンパイラのフロントエンドを介してコードを常に実行してリアルタイムのエラーを強調表示するIDEで、ほぼ30秒に1回ctrl-Sと「コンパイル」ショートカットを押します。なぜ無料のランチを渡すのですか?


コンパイルは無料であり、注意散漫はコストがかかることに同意しません!しかし、そうでなければ、良い答え、ありがとう:)
CaptainCodeman 14年

たぶん「IFF」「場合」私は、大胆イタリック体を作っている必要があります代わりに...私は、プロジェクト、コンパイラや環境に応じて、それは考えることができます自由行動にかなりくそ近いもの。コンパイラー出力用の2番目のウィンドウまたは画面がある場合、停止するのとほぼ同じ頻度でコンパイルできます。あなたが本当に筋金入りの(私はそうではない)なら、あなたはあなたのコードから目をそらす必要さえありません-コンパイラがあなたの周辺視野に登録するのに十分な冗長なエラーを生成したなら。繰り返しますが、これはコンパイルがかなり速い場合に限ります。それ以外の場合は上記を参照してください。
DeveloperInDevelopment 14年

2
I hit ctrl-S about once every 30 seconds。おそらく2倍の頻度で保存します笑。それは本当に悪い習慣です。コード行の途中で保存し、最後にもう一度保存することもあります。入力するのではなく一瞬考えることをやめるたびに、保存します。
ランチャー14年

21

コンパイルすることにはメリットがあります。しかし、私は仕事にとどまることがOKのコーディング戦略であることに非常に同意します。

インクリメンタルコンパイルの最も重要な利点は、コンパイルとテストが終了するのを待つ場合に多くの人が参加するという考え方です。最終的には、その時点でコードを実行することに関心があります。この構文エラーが隠れている根本的なセマンティックエラーがあるかどうかを考えずに、「ああ、コンパイラが文句を言うのをやめるためにこのブラケットを追加するだけでいい」または「これを大文字にするだけでいい」と言います。私は本当に構文エラーがセマンティックエラーにしばしばネストすることを発見します(逆は真実ではありません)。

例として、変数の意味を変更し、その結果、名前を変更したとしましょう。名前の変更により、後のコードで構文エラーが生成されますが、名前を修正してコンパイラーを喜ばせただけであればそのエラーが発生した理由を無視しました。


5
セマンティックエラーと構文エラーの関連性を強調するために+1
Doc Brown

15

あなたがコードをテストする利点を理解していますが、なぜコンパイルするのですか?

しかし、それに応じてコンパイルしない場合、どのようにコードをテストしますか?

極端な場合は、テスト駆動開発(TDD)です。TDDは、書き込みテスト、コンパイル(失敗)、書き込みコード、再コンパイル、実行テスト、修正バグ、再コンパイル、リファクタリング、コンパイルの非常に短いサイクルを意味するため、TDDが戦略で機能しないことは明らかです。 -もう一度、実行テスト、そして...

だから、誰もがTDDをしているわけではなく、少なくとも常にそうではありません(私も認めます)。現在の戦略では、TDDを試すことさえできません。しかし、TDDを実行していない場合でも、コードをより定期的にテストすることは非常に役立ちます。定期的にコンパイルしないと不可能です。また、テストが失敗すると、デバッグを実行します(数分前に作成した見栄えの良いアルゴリズムが、思ったほどうまく動作しない理由を理解するのに役立ちます)。そして、コンパイルせずに書くコードが多いほど、テストせずに書くコードが増えるため、問題を修正する時間が「O(1)」であると予測できない場合に遭遇する可能性が高くなります。あなたが書いた。


1
私はあなたに同意しますが、実行したいのでプログラムをコンパイルすることと、テストする(またはコンパイルエラーを修正する)意味がない場合にコンパイルすることには違いがあると思います。
キャプテンコードマン14年

@CaptainCodeman:100行のコードを記述するとき、独自にテストできる小さな部品がほとんど常にあるはずです。通常、100行のコードは、4〜15の関数(またはBob Martinのスタイルでコーディングする場合は20を超える関数)を意味します。
Doc Brown 14年

5
@CaptainCodeman:TDDでは、テストする「意味のないもの」はありません。古典的な例は、新しいクラスを書きたい(Fooと呼びましょう)場合、最初に行うことはnew Foo();、クラス定義を書いていないために明らかにコンパイルに失敗する単体テストと書き込みを作成することです。TDDでは、コンパイラを実行する正当な理由です-単体テストが機能していることを(失敗することで)証明します。
スリーブマン14年

@slebetman:その有益なコメントをありがとう。私はこれがTDDに限定されないことを付け加えたいと思います。100行のコードを記述するとき、TDDを行うかどうかに関係なく、テストの間に意味のあるものが常にあります。
Doc Brown 14年

14

経験豊富な開発者にとって、コンパイラーのエラーは大した問題ではないはずだということに実際に同意します。それらを修正するためのコストは、時間をかけて心配するほど大幅に増加するとは思わない。プッシュの直前まですべてのコンパイラエラーの修正を延期することができた場合、はるかに小さく、より統合された中断が発生するため、私はそうします。

残念ながら、コンパイラが行うことはコンパイラエラーの検出だけではありません。明白なことを述べるリスクはありますが、プログラムを実行するにはコンパイルが必要であり、経験豊富な開発者でさえ作成する、より複雑で微妙で興味深いランタイムバグを見つけるには、プログラムの実行が必要です。そして、これらのタイプのバグより困難であり、したがって、デバッグを延期するほど修正がより高価になります。

ただし、インタビューの演習で、コンパイルを最後まで延期するために、必ずしも誰かをマークダウンするわけではありません。面接の練習は非常に簡単である傾向があり、経験豊富な開発者は通常、自分の限界を知っています。自分が書いたものについて自信があるほど、コンパイル間を長くすることになります。それはただの人間性です。

ただし、それを評価しないためには、自信を正当化する必要があります。あなたがコンパイルせずに何かを書くのに45分を費やし、それをデバッグするのにさらに45分を必要としたなら、私はあなたに対してそれを重く考えていただろう。


8

私が見る限り、他の回答から欠落していることが多い、しばしばコンパイルに関する重要なことは、これです:めったにコンパイルせずに大量のコンパイラエラーが発生した場合、それらのほとんどは最初のエラーによって生成されるため、無意味です。タイプ、タイプミス、または宣言を無効にする単純な構文エラーが原因である可能性があります。

常に最初のものを修正し、再コンパイルし、次の残りのものを修正することなどができますが、コードベースが大きい場合、これは遅くなる可能性があります。しかし、コンパイラエラーの長いリストと独立したエラーを特定しようとすると、無関係なメッセージを読んだり、二次的なエラースポットから実際の原因までコードをナビゲートしたりするのに多くの時間を費やします。

通常のビルドでは、コードの完全なブロックが作成されてすぐにコンパイルが開始されると、すぐにコンパイルが開始されます。コンパイルが終了するまで新しい編集内容を保存しない限り、コンパイルの進行中にさらにコードを書き続けることができます。そのため、ビルドを待つ時間はほとんどありません。その時点で書こうとしていることをすべて書き終えるまで待つ場合、何もせずにコンパイルを待つ必要があります。これは基本的に、最新のIDEがバックグラウンドで自動的に実行できることの手動バージョンです。


興味深いことに、これはコンパイルが遅い場合でも定期的にコンパイルする正当な理由です。いい視点ね。
sleske 14年

3

経験豊富なプログラマーにとって、コードのコンパイルがボトルネックになることはありません。

言語を十分に理解したら(つまり、構文について考える必要がなくなり、代わりに機能のためのコードだけを作成するとき)、単純な構文エラーを作成しない傾向があります。作成するのは通常、タイプミスまたはコピーペーストのバグであり、わずかなコンパイルパスで短時間でクリーンアップできます。

私はコンパイルせずに終日定期的にコードを書いてから、コンパイルして、コードをコミットする前にコンパイラーが報告する構文エラーと警告を修正します(「テストが必要です!」と書かれています)。わずか数分で1,000行以上のCまたはC ++コードをクリーンアップできます。

一方、デバッグとテストには時間がかかります。あらゆる種類の理由で論理エラーが発生しますが、書くのを完全に忘れたサブルーチンについて教えてくれるコンパイラーに会ったことがありません。またはnode->left、あるべき時に貼り付けたためにバイナリー・ツリーが機能しないことに気付きますnode->right

インタビュアーと戦うのは一般的に賢明ではないと思いますが、自分のスタイルを守る価値があると感じたら、書いたコードをデバッグするのに十分な時間を残したことを指摘しておかなければならないと思います。それは、優れたプログラマーが決して無視しないことです。

ps-コードを読んでコードをレビューするのを見ていたら、その場であなたを雇っていただろう。それは、プロが毎回行うことです。


4
「私が完全に書くのを忘れていたサブルーチンについて教えてくれるコンパイラにまだ会っていません。」広範囲にわたる変更を完了していない場合は、コンパイラーに完全に依存します。時々、変数の名前を変更して、使用法のすべてのインスタンスをチェックし、すべての新しい名前を付けるまで、コンパイルが成功しないようにします。何かが足りない場合に警告しないコンパイラに出会ったことがないと言う方法を理解できません。空のプレースホルダーサブルーチンを作成してからそれらを忘れない限り、天国はあなたを助けます。
イアンゴールドビー14年

@parご回答ありがとうございます。このようなコードを書いているのは私だけではないことを知っておくとよいでしょう!
キャプテンコードマン14年

3
@CaptainCodemanコンパイラエラーよりも論理エラーのほうが油断ならないことをよく知っています。しかし、私が異議を唱えたかったのは、コンパイラがミッシングコードについてあなたに話すことができないという彼の主張でした。意図的にコンパイルする間違った(または不完全な)コードを書いている場合を除きますが、それはむしろコンパイラーがキャッチできないエラーがIMOの本当の問題であるという議論を打ち負かします。ヘック、コンパイラを使用して、キャレットを次にコードを記述する必要がある行に移動します。しかし、多分私はとても怠け者です。
イアンゴールドビー14年

1
@IanGoldby:あなたはその点を完全に逃し、あなたは私の言葉をひねりだすことを選んだとさえ言いたいと思います。コンパイラは、明日朝食に何を食べるかを伝えることができないのと同じように、コードの欠落について警告することはできません。コンパイラーがプログラミング技術であることをユーザーに思い出させるために、意図的に構文エラーを導入します。エラーと見なされることも、コンパイラーに超能力を与えることもありません。
パー14年

1
@par私は明らかに私のコメントによって引き起こされた違反に対して謝罪します-それは意図されたものではなく、あなたが言ったことを偽って伝えようとはしませんでした。今でも、コンパイルする不完全なコードを書くときは、#warningまたはTODOを追加することで忘れられないようにする練習をすることがわかります。これは正当な手法です。両者が同意する重要なことは、コンパイルするが機能しないコードは、コンパイルしないコードよりもはるかに危険であることです。
イアンゴールドビー14年

3

いいえ、十分な量のコードを実行するまでコンパイルを延期するのは不合理ではありません(「十分な量」はコーダーと書き込まれているコードによって異なります)。

たとえば、あなたがそれを正しくするのに時間をかける素晴らしいコーダーであり、大量のコードや複雑なコードを書いていない場合、定期的にコンパイルすることは無駄であり、おそらく気が散ることもあります。そうでない場合は、すべての関数をコンパイルすることをお勧めします。それは人次第です。

反例として、JavaScriptコードを書いていると想像してください-コンパイラはありません。代わりに(ほとんどのJavaScriptコードの性質を考慮して)プログラムを実行(またはページを更新)して、コーディングの結果を確認します。今、あなたは理にかなった十分なコードを書かれるまでそれをすることができません。その結果、JavaScript開発者はできる限り頻繁に「コンパイル」する傾向がありますが、これは必ずしも頻繁ではありません。

要するに、ここには正しい答えはありません-インタビュアーは間違っていませんが、あなたもそうではありません。生産性を高めるものを実行し、誰かがあなたにすべきだと言っていることを忘れてください。コーディングには、F7定期的にヒットする(またはヒットしない)傾向がまったく影響しないことよりもはるかに重要な要素があります。


2番目の段落は不明瞭です。「すばらしいコーダー」を定期的にコンパイルするかどうかを明確にするために、編集することをお勧めします。(「t」を追加し、「no」を「not」に変更しましたか?)
DougM 14年

@DougM-多々。
gbjbaanb 14年

多くの場合、スクリプトコードは「ライブ」で開発されます。つまり、REPL環境で実行されます。そのため、実際には「コンパイル」が常に発生し、ソースファイルに書き込まれるほとんどのコードも1回実行されています。ないすべては、スクリプトコードをこのように書くが、私は誰がために使用し、不正なコードによって与えられた静的型付け言語とコンパイルエラーの相対的な「安全」のが好きと言うだろう、彼らがすべきスクリプト言語でこのように動作します。
ハイド14年

2

優れた開発環境では、実際にコードをテストする予定がない限り、コンパイルする理由はほとんどありません。バックグラウンドの構文チェックツールは、インタビュアーが話していると思われるほとんどすべてをキャッチしますが、常に完全に特定されているわけではない(ファイル全体に伝搬する変更を含む)いくつかのケースがあることは認めます。

そうは言っても、実際に結果を生成できるコードの最小単位をほとんどコンパイルして実行しようとします。30分前、私はいくつかの検索結果を印刷する手段を作成していましたが、結果をより良く見えるようにするために、10数回のコンパイルの速度で(紙ではなく.pdfに)半ダースのテスト印刷を行いました行。


1

私の意見と私の経験では、コードの一部がコンパイルされるかどうかは本質的にランダムであり、セミコロンが欠落しているかどうかなどが含まれており、基礎となるプログラムの正確性とはほとんど関係ありません。(私にとって、コンパイルに焦点を当てることは、文法をチェックするために校正せずに記事をスペルチェックに通すようなものです。)

私の経験は非常に異なります:私が得るコンパイルエラーの5%未満は構文に関するものです。私は言語をよく知っています。エラーが発生した場合、ほとんどは型エラーであり、セマンティクスが正しくないことを教えてくれます。

これが、コンパイラーのフィードバックから可能な限り迅速に利益を得られることを嬉しく思う理由です。コンパイルエラーをリアルタイムで強調するIDEの使用を経験したことがありますか?フィードバックループを短くすることは非常に有益です。

不完全なコードを教えてくれた場合、最初にすべきことはそれを読むことです。コードが何をしているのかがわかり、アルゴリズムが正しいことがわかるまで、コンパイルしようとはしません。

他の人が書いたコードで作業することが予想される場合、すべてを読む時間があるとは限りません。良いニュースは、うまく書かれたコードは結合度が低く、必要なコードの部分だけを独立して推論できるようにする必要があることです。

そのような場合、まだ読んでいないコードが正しいと仮定し、問題がある場合は遅延調査する必要があります。

一定のコード長の「コンパイルするコードを取得する」には、通常、一定数のコンパイルエラーの修正が含まれ、かなり一定の時間がかかります。コーディング時間と一緒に。

コンテキストの切り替えは脳にとってコストがかかるため、小さなエラーを修正したらすぐに修正する方が効率的です。

編集:チーム全体が同じソースで作業している場合、ソース管理との類似性を確認することもできます。コンパイルは、頻繁にコミットを行うようなもので、すべてをマージして整理する必要があるときに、最後に多くの苦痛を避けるのに役立ちます。

あなたはあなたのテキストの下に赤い線のようなものを無効にするという。メールを入力したり、技術文書を書いたりするときにもそうしますか?次に、間違いを修正する代わりに、すべてのページを再度校正する必要があります。

もう1つの利点は、コードの作業中に、常にコンパイルまたはほぼコンパイルを続けると、多くのセマンティックベースのIDE機能(安全な名前の変更、リファクタリング、シンボルの使用の検索など)を活用できることです。 。

これらの機能がどのように役立つかをより深く理解したい場合は、それらを有効にして練習し、自分自身の利点を体験してみてください。また、慣れ親しんでいる人とペアプログラミングを行って、それらの利点を確認することもできます。


1
私は通常、自動フォーマット、テキストの下に赤い線を描くなどの厄介なコンパイラーの「機能」をオフにします。
キャプテンコードマン14年

1

インタビュアーに何か非常に悪いことがあると感じ、それが何であるかを正確に指摘できなかったので、これについてもう少し考えました。ここに問題があります。過去20年間に書いたコードの場合、実行可能なアルゴリズムをコンパイルするコードに変えるのに必要な時間は最小限でした。その領域での効率の向上は、開発時間全体にほとんど影響を与えないため、まったく無視できるものであり、その領域で非効率であると思われる候補者を拒否するインタビュアーは、優れた開発者になる理由を知りません。

ほとんどの時間は、コードが行うべき情報の収集、使用する必要のある外部サービスに関する情報と仕様の収集、コードをハッキングする代わりに正確で保守可能なコードにつながるグローバル設計の作成、およびアルゴリズムの検索に費やすべきです。それは、動作するまで一緒にパッチが適用されるコードではなく、動作するコードにつながります(明らかにエラーのないコードと明らかなエラーのないコード)。

その後、コンパイルするコードを書くために少し時間がかかります。

その後、コードが機能することを確認し、コードが機能し、機能し続けることを確認するために、より多くの時間が費やされます。これは、最初に適切に設計されたコードを使用することにより、ユニットテストを作成し、コードをステップ実行し、大部分を実行することによって行われます。

このインタビュアーは、私の返信で10語でカバーされていることに集中しました。これは、実際の作業時間の10%以下を表します。そして、その開発者が信頼できる実用的なコードを作成する能力にほとんど影響を与えません。


それは理にかなっています。私の意見では、優れた開発者は一日中紙にコードを書き、その日の終わりにそれをタイプできるはずです。
キャプテンコードマン14年

1

「順を追ってコンパイルする」ことの利点は、一定のフィードバックが得られることであり、正しい方向に進む前に大した間違いをする可能性はありません。あなたのような有能なプログラマーにとって、それは大きな考慮事項ではありませんが、他の多くの人にとってはそうです。別の言い方をすれば、「場合に応じてコンパイルする」ことは、場合によっては潜在的な効率の損失がありますが、「最大損失を最小化する」方法です。

最近の企業は、完成品に興味があるだけではありません。彼らはそれがずっと「制御下にあった」ことを知りたいと思っています。彼らにとって、「そこに着くのは半分の楽しみです。」


これは前に16点の答えに掲載されたものに比べて大幅何かを提供していないようだ
ブヨ

2
感謝しますが、どのような損失について話しているのでしょうか?間違いなく、間違った言語で誤って書くような抜本的なことをしない限り、単にコンパイルエラーのためにコードを書き換える必要はありません。
キャプテンコードマン14年

@CaptainCodeman:企業の気分を良くし、「保険」の一形態です。それはお金がかかるものですが、ほとんどの人(マネージャーを含む)を「夜の眠りを良くします」。
トム・金

@gnat:私がやろうとしていたポイントは、ほとんどの利点が「企業」レベルの利点であり、プログラマが正しいか間違っていると思っているからではなく、上司が彼に言ったからです。
トム・金

「より短いフィードバックループ」を支持する適切なポイントはすでに作成されており、ここの最初の回答で詳しく説明されています。私は正直、スタッフィングはすでに述べたもの以上の価値がある何かを追加し、「これらの日が企業」について推測裸方法を見ていない
ブヨ

1

ここでの他の回答は、仕事で頻繁コンパイルするための良い防御策を講じていますが、あなたの質問はインタビューに集中しているので、その角度に取り組みたいと思います。

私のインタビューでは、正反対のことをします。候補者はコンパイラを使用できません。彼らはホワイトボードに短いプログラムを書いてから議論します。コンパイラー(またはインタープリター)を松葉杖として使用している開発者が多すぎることを発見しました。私があなたにたくさんのお金を提供していて、コンパイラなしでFizzBu​​zzを正しく書くことさえできないなら、あなたはおもちゃの運動よりも100倍難しい問題に取り組んで、長期的にそれを切ることは決してないでしょうインタビューで。それでも、これらの簡単な演習は、インタビューの他のどの部分よりも多くの候補者を除外しました。

面接の目的は、候補者とビジネスの相互適合性を評価することです。適切なインタビューの質問には、質問の目的とインタビュー対象者の評価方法を明記する必要があります。インタビュイーにトリックの質問を投げかけ、隠された答えを知らないとペナルティを課しても、インタビュアーまたはインタビュイーは役に立たない。残念ながら、ほとんどのプログラマー(上級者でも)は、他のプログラマーと面接する訓練を受けていないため、決まり文句に頼って、面接時に尋ねたのと同じタイプの質問をします。か否か。

私のアプローチが「真の方法」であると主張しているわけではありませんが、非常にうまく機能しています。大文字で始まる多くのソフトウェア方法論と同様に、面接には同じ数の「義務」があります。彼らはすべて二段です。あなたとあなたのビジネスのために働くことをする必要があります。


0

いくつかのサブルーチンを使用する大規模なプロジェクトでは、特定の部分が既に機能していることがわかっているとデバッグが簡単になるため、これらの部分をより大きなスキームで使用する前にテストする必要があります。

これらの小さい部分をテストするには、コンパイルする必要があります。

インタビュアーがこの状況を、この方法で設計されていない小さなプログラムと混同している可能性があります。


0

2回目のインタビューに関して、コンパイルの利点は、プログラムが実行する(または実行しない)ことをほんの数秒で確認できることです。そこから、コードを読み、関連する部分に努力を集中するのが簡単になります。おそらく、これはインタビュアーが期待していたことです。

このような未知のコードベースを最初から最後まで読むことは非常に非生産的です(あなたはコンパイラではありません)が、アプリケーションをコンパイル/実行するとすぐに全体像がわかります。


これは前に15点の答えに掲載されたものに比べて大幅何かを提供していないようだ
ブヨ
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.