c++編碼風格指南

by Jane Philipps

簡·菲利普斯

帶回家的編碼挑戰的基本指南 (The Essential Guide to Take-home Coding Challenges)

介紹 (Introduction)

Hi, I’m Jane. I wrote this guide because I want to help others with non-traditional backgrounds succeed on take-home coding challenges. Please read it, take notes, apply the material, and let me know about your results. You can reach me via email at jane@fullstackinterviewing.com.

嗨，我是簡。 我寫本指南的原因是，我想幫助具有非傳統背景的其他人成功應對帶回家的編碼挑戰。 請閱讀它，做筆記，應用材料，然后讓我知道您的結果。 您可以通過電子郵件jane@fullstackinterviewing.com與我聯系 。

This guide is intended for anyone who has received a take-home coding challenge as part of the technical interview process and wants to attack it in the best way. This Essential Guide is a distilled version of a longer Ultimate Guide to Take-home Coding Challenges, which goes into much more detail and walks through an example challenge from start to finish.

本指南適用于在技術面試過程中遇到帶回家的編碼挑戰并希望以最佳方式對其進行攻擊的任何人。 本基本指南是更長篇幅的《帶回家的編碼挑戰的終極指南 》的精簡版，其中包含更多細節，并從頭到尾逐步介紹了示例挑戰。

So, if you’ve just received a challenge and are anxious to get started, start here, and then check out the full guide when you want to learn the material more deeply. Good luck!

因此，如果您剛剛面臨挑戰并且渴望入門，請從這里開始，然后在想要更深入地學習該材料時查閱完整指南 。 祝好運！

在進行實戰編碼挑戰時要避免犯的錯誤 (Mistakes to avoid making when working on a take-home coding challenge)

There are several mistakes you can make with take-home challenges. Some of these are small mistakes that are easily correctable, while others will leave you frustrated and unable to finish your assignment. I want to address these mistakes first, so when you’re given a take-home challenge, you know exactly what not to do.

帶回家的挑戰可能會犯一些錯誤。 其中一些是容易糾正的小錯誤，而另一些則使您感到沮喪，無法完成任務。 我想首先解決這些錯誤，因此當您面臨挑戰時，您確切地知道該怎么做。

Here are four mistakes you can make:

您可能會犯以下四個錯誤：

1. Time management and scope creep

1.時間管理和范圍蔓延

2. Trying to learn too many new things at once

2.嘗試一次學習太多新事物

3. Making too many assumptions

3.做出太多假設

4. Starting to code right away

4.立即開始編碼

Let’s look at each one in detail.

讓我們詳細看看每個。

1. Time management and scope creep

1.時間管理和范圍蔓延

Time estimation is one of the hardest problems in programming, and even experienced engineers struggle with it. This plays into take-home challenges in a couple of ways.

時間估計是編程中最困難的問題之一，即使是經驗豐富的工程師也難以解決。 這以多種方式帶來了挑戰。

First, some challenges come with “estimated time.” I usually ignore these, as they are rarely based in reality. Second, some challenges are open-ended. Many people, especially newer developers, will want to add tons of features because they think it will be impressive. Actually, it’s more impressive if you keep the scope relatively narrow, but finish everything you set out to do. In this situation, it’s better to do one thing really well than to do a million things poorly.

首先，“估計時間”帶來了一些挑戰。 我通常會忽略這些，因為它們很少基于現實。 第二，一些挑戰是無限的。 許多人，尤其是新開發人員，會希望添加大量功能，因為他們認為這會給人留下深刻的印象。 實際上，如果您將范圍保持在相對狹窄的范圍內，但要完成您打算做的所有事情，就會給人留下深刻的印象。 在這種情況下，最好做一件事情要比做一百萬件事情做得差。

A good question would be: what counts as “going above and beyond” versus what counts as “scope creep?” My rule of thumb would be if your idea accomplishes or improves on the requirements of the assignment, that is likely a good idea, but if it seems tangentially related or “just cool,” it’s probably scope creep. But, as I describe later, always make it work first.

一個好問題是：什么算作“超越”，什么算作“范圍爬行”？ 我的經驗法則是，如果您的想法完成或改進了任務的要求，那可能是個好主意，但是如果它看起來與切線相關或“很酷”，則可能是范圍的蔓延。 但是，正如我稍后所述，請始終使其首先工作。

2. Trying to learn too many new things at once

2.嘗試一次學習太多新事物

While a take-home coding challenge can be an excellent opportunity for learning, it is possible to take on too much learning. If you’re given a challenge where you must use a specific language or framework, but you’re not familiar with it, don’t add additional complexity by setting out to learn something new on top of that. For example, if you are using a new backend framework for a full stack app, stick to a frontend framework that you’re already comfortable with.

雖然帶回家的編碼挑戰可能是學習的絕佳機會，但可能會進行過多的學習。 如果您遇到了必須使用特定語言或框架的挑戰，但又不熟悉它，則不要著手學習新的知識，以免增加額外的復雜性。 例如，如果您要為全棧應用程序使用新的后端框架，請堅持使用已經熟悉的前端框架。

If your challenge is language/framework agnostic, but you’ve been itching to try out some new technology, pick JUST ONE to experiment with. Between reading the docs, getting your challenge properly set up, and getting used to any new syntax, you will have your hands full. Even learning one thing will eat up a lot of your time, so I would highly suggest limiting yourself to one new piece of technology per challenge.

如果您的挑戰是與語言/框架無關的，但是您一直想嘗試一些新技術，請選擇“僅一者”進行試驗。 在閱讀文檔，正確設置挑戰以及習慣使用任何新語法之間，您會全神貫注。 即使學習一件事也會占用您很多時間，因此我強烈建議您將自己限制在每次挑戰中只能使用一項新技術。

3. Making too many assumptions

3.做出太多假設

As a developer, if you make too many assumptions, you are bound to build an application where the requirements are off, or the user experience is bad. When given a set of requirements for a take-home challenge, ALWAYS take the time to review the requirements and make sure you fully understand them. And, if you have any questions at all, always ask.

作為開發人員，如果您做出太多假設，那么您必然會在不滿足要求或用戶體驗不好的情況下構建應用程序。 當給定一些挑戰的要求時，總是花時間檢查這些要求并確保您完全理解它們。 而且，如果您有任何疑問，請務必提出。

First, this shows that you are willing to ask for help when you don’t quite understand something, an important trait for a developer to demonstrate. Second, many companies will intentionally give you product requirements that are vague or not fully fleshed out in order to see how you react in these situations. They are actually testing your ability to make sense of requirements that may have gaps in them.

首先，這表明您不太了解某些內容時便愿意尋求幫助，這是開發人員要展示的重要特征。 其次，許多公司會故意給您模糊或不完整的產品要求，以了解您在這種情況下的React。 他們實際上正在測試您了解可能存在差距的需求的能力。

So, when in doubt, ask questions. Asking questions is also a signal that you are engaged and interested in the challenge.

因此，如有疑問，請提問。 提問也是您對挑戰充滿信心的信號。

4. Starting to code right away

4.立即開始編碼

One last mistake you can make is to jump in and start coding right away. I guarantee if you do this, you will regret it. Why? Two reasons:

您可能犯的最后一個錯誤是立即開始編碼。 我保證如果您這樣做，您將后悔。 為什么？ 兩個原因：

Without proper planning, your code will suffer

沒有適當的計劃，您的代碼將遭受損失

Without first getting organized and making sure you fully understand ALL of the technical requirements, you may find yourself missing edge cases or rewriting parts of the functionality. I know it seems counter-intuitive, but you will actually SAVE yourself time if you plan ahead.

如果沒有先進行組織并確保完全了解所有技術要求，則可能會發現自己遺失了邊緣情況或重寫了部分功能。 我知道這似乎違反直覺，但是如果您提前計劃，您實際上會節省時間。

You will spin your wheels trying to get your app set up properly

您將旋轉輪子以嘗試正確設置應用程序

Especially for newer developers, initial app setup can be one of the hardest parts of a take-home coding challenge. It’s not something you do every day, so it often takes some research and reading documentation to get reacquainted with the process and ensure you’re going about it in the best way.

特別是對于新開發人員而言，初始應用設置可能是帶回家的編碼挑戰中最難的部分之一。 這不是您每天都要做的事情，因此通常需要一些研究和閱讀文檔來重新熟悉該過程，并確保以最佳方式進行操作。

So, there you have it — a summary of mistakes to avoid making. You’ll find that a lot of these are also applicable to your day to day work as a developer. In the next section, we’ll dive into further detail on how to get organized before you write a single line of code.

因此，您已掌握了要避免的錯誤摘要。 您會發現其中許多內容也適用于您作為開發人員的日常工作。 在下一節中，我們將深入探討如何在編寫一行代碼之前進行組織。

井井有條：編寫代碼行之前如何計劃 (Get organized: how to plan before you write a line of code)

Now it’s time to get to work! But, it’s NOT time to write any code YET.

現在是時候開始工作了！ 但是，還沒有時間編寫任何代碼。

Why?

為什么？

Because, as you’ll see, a lot of the work actually happens before you write a single line of code. This may seem counterintuitive, but again — the more time you spend up front planning, the less time you will spend writing code.

正如您將看到的，因為很多工作實際上是在編寫一行代碼之前完成的。 這似乎是違反直覺的，但同樣—您花在前期計劃上的時間越多，花費在編寫代碼上的時間就越少。

So, now you have your coding challenge in hand and you are ready to get started with the planning process. Here are my six suggested steps:

因此，現在您手頭的編碼難題已經準備就緒，可以開始進行計劃過程了。 這是我建議的六個步驟：

1. Understand the requirements and ask any questions

1.了解要求并提出任何問題

2. Identify technical decisions you need to make

2.確定您需要制定的技術決策

3. Technical design & whiteboarding

3.技術設計和白板

4. Test plan

4.測試計劃

5. App setup plan

5.應用設置計劃

6. Organize your tasks

6.組織任務

1. Understand the requirements and ask any questions

1.了解要求并提出任何問題

First, you need to make sure you completely, absolutely, 100% understand the requirements of the project. If any part of the requirements are unclear, it is up to you to reach out to your contact and ask questions.

首先，您需要確保完全，絕對地100％理解項目的要求。 如果要求的任何部分不清楚，則由您決定與您的聯系人聯系并提出問題。

Sometimes companies will purposefully make their requirements vague, in order to see how you approach the problem. In these cases, it is always best to ask questions as it shows you are thinking about the problem and not just making assumptions and building an app to a vague spec.

有時公司會故意使他們的要求含糊不清，以了解您如何解決問題。 在這些情況下，最好總是提出問題，因為這表明您正在思考問題，而不僅僅是做出假設并根據模糊的規范構建應用程序。

2. Identify technical decisions you need to make

2.確定您需要制定的技術決策

Your next step will be to identify the technical decisions that you need to make. Making a list of all of your technical decisions up front and thinking about them before you’re in the middle of building your app will help you immensely. Not only will it cut down on time figuring things out later, but it will allow you to make big picture decisions up front, as opposed to trying to focus on both the big picture and the small details at the same time.

下一步將是確定需要做出的技術決策。 預先列出所有技術決策，并在構建應用程序之前對其進行思考，將極大地幫助您。 它不僅可以節省時間，以后再進行查找，而且可以讓您提前做出大決策，而不是同時專注于大細節和小細節。

3. Technical design & whiteboarding

3.技術設計和白板

Now it’s time to plan out the rest of your app. For anything that you need to draw out, now is the perfect time to do that. Thinking through these decisions at the start serves two purposes:

現在是時候計劃其余的應用程序了。 對于您需要提取的任何內容，現在是執行此操作的最佳時機。 從一開始就考慮這些決定有兩個目的：

• You’ll be able to reference these drawings and your original plan while you’re building your app. Then if you get stuck at any point, you can always come back to your notes.
  在構建應用程序時，您將能夠參考這些圖紙和原始計劃。 然后，如果您在任何時候遇到困難，都可以隨時返回筆記。
• Later, when you are having a discussion with an engineer about your coding challenge, you can use these notes as a reference when they ask you why you made certain design or architecture decisions.
  稍后，當您與工程師討論您的編碼挑戰時，當這些注釋詢問您為什么做出某些設計或體系結構決策時，可以將這些注釋用作參考。

Once you’ve thought through and answered some of the bigger design and architecture questions for your challenge, the next step is research. If you’re planning to use a new technology or something you’re a bit rusty with, use this time to search for documentation and other resources.

當您考慮并回答了一些較大的設計和體系結構問題后，下一步就是研究。 如果您打算使用新技術或有些生銹，請利用這段時間搜索文檔和其他資源。

4. Test plan

4.測試計劃

Another very important step to take before writing a line of code is developing a test plan. Although you won’t get peer feedback on this test plan, it will help you look at the challenge from a different angle, making sure you’re meeting all of the requirements. By thinking through and writing out a test plan before you start coding, you are able to brainstorm possible edge cases that you should account for in your code and you will use this as a basis for testing your app later.

編寫一行代碼之前要采取的另一個非常重要的步驟是制定測試計劃。 盡管您不會獲得有關該測試計劃的同行反饋，但是它將幫助您從不同的角度看待挑戰，確保您滿足所有要求。 通過在開始編碼之前仔細考慮并制定出測試計劃，便可以集思廣益，在代碼中應考慮的可能的極端情況，并將以此為基礎來稍后測試應用程序。

5. App setup plan

5.應用設置計劃

If you’re starting an app from scratch, figure out if there are any generators you can use to make your app setup easier and faster. Application setup is one of the hardest parts of take-home coding challenges, because it’s something that developers do rather infrequently. Best practices are always changing, so it’s easy to forget how to do. Also, when setting up an app with a specific combination of technologies for the first time, it can be challenging to get everything configured and working together properly.

如果您是從頭開始創建應用程序，請確定是否可以使用任何生成器來簡化和更快地設置應用程序。 應用程序設置是帶回家的編碼挑戰中最困難的部分之一，因為開發人員很少這樣做。 最佳實踐總是在變化，因此很容易忘記該怎么做。 此外，當首次使用特定技術組合設置應用程序時，對所有內容進行配置并正確協同工作可能會帶來挑戰。

If you are not using a generator, reading documentation and finding working examples are the two most important steps you can take. Being able to play with a working example and compare it to your own app will help you if you get stuck.

如果您不使用發電機，那么閱讀文檔和查找工作示例是您可以采取的兩個最重要的步驟。 如果遇到困難，能夠使用一個可行的示例并將其與自己的應用程序進行比較將對您有所幫助。

6. Organize your tasks

6.組織任務

The last step before you start coding is to break down and organize your tasks. Breaking down your tasks is essential because it will help you stay on track as you’re working on your challenge, and it will give you a game plan for execution. Note that you shouldn’t be a perfectionist here, because there will always be unexpected bumps in the road.

開始編碼之前的最后一步是分解并組織任務。 分解任務至關重要，因為這將幫助您在應對挑戰時保持步調一致，并為您提供執行游戲的計劃。 請注意，您在這里不應該是一個完美主義者，因為路上總是會出現意想不到的顛簸。

Here is an example task list for a classic Tic Tac Toe app:

這是經典的Tic Tac Toe應用程序的示例任務列表：

- Understand requirements- Choose technologies- Brainstorm test plan- Hello World app setup- Build board with HTML/CSS- Implement Tic Tac Toe gameplay with Javascript- Add reset button- Make board responsive- Add ability to add additional boards- Error handling & tests- Code cleanup- README

Some of these tasks can be broken down even further into smaller steps. For example, in order to implement the Tic Tac Toe gameplay with Javascript, here are some smaller tasks:

其中一些任務可以進一步細分為更小的步驟。 例如，為了用Javascript實現井字游戲，這里有一些較小的任務：

- Add a click handler to each square that logs a message- Get click handler to add an X to the square that is clicked- Get clicks to alternate between X and O- Don’t allow a square to be clicked more than once- Implement a function to find the winner and end the game- Handle a tie game

3.編寫測試：就做吧！ (3. Writing tests: just do it!)

Testing can be overwhelming, because there are so many different types of tests: acceptance tests, integration tests, and unit tests, not to mention test driven development vs. ad hoc testing.

測試可能是壓倒性的，因為存在許多不同類型的測試：驗收測試，集成測試和單元測試，更不用說測試驅動開發與臨時測試。

Why should you include tests in your take-home coding challenge? It’s simple: your tests will make your submission shine.

為什么要在家庭編碼挑戰中包括測試？ 很簡單：您的測試將使您的提交大放異彩。

First, adding tests shows that you know or are willing to learn another technology/framework. It also demonstrates that you take ownership of what you’re building, because you are taking responsibility to make sure it works. Testing also shows that you’ve considered edge cases, which many newer engineers often overlook.

首先，添加測試表明您知道或愿意學習另一種技術/框架。 它還表明您對所構建的內容擁有所有權，因為您有責任確保其有效。 測試還表明，您已經考慮了許多高級工程師經常忽略的極端情況。

Many companies take tests very seriously. Some will not tell you that they expect tests for your coding challenge, but will automatically reject you if you leave them out. Therefore, my recommendation is to write tests no matter what when given a take-home challenge. Not only will it make you a better developer, but for companies that were not expecting tests, you will stand out even more!

許多公司非常重視測試。 有些人不會告訴您他們希望對編碼挑戰進行測試，但是如果您不進行測試，則會自動拒絕您。 因此，我的建議是無論遇到什么挑戰都要編寫測試。 它不僅可以使您成為更好的開發人員，而且對于那些不希望測試的公司，您將脫穎而出！

How do you go about writing a tests? First, create a plan. Here’s my 80/20 suggestion for how to come up with the right test cases:

您如何編寫測試？ 首先，制定計劃。 這是我關于如何提出正確的測試用例的80/20建議：

1. Test the happy path

1.測試幸福的道路

For the classic Tic Tac Toe example, the happy path is starting with an empty board and playing a game until X wins.

對于經典的井字游戲示例，幸福的道路是從一個空局開始，然后玩游戲直到X獲勝。

2. Think about variations on the happy path

2.考慮幸福道路上的變??化

A variation on the happy path would be if O wins, or if there is a tie game.

如果O獲勝或出現平局，則幸福道路上的變??化會是。

3. Think of edge cases

3.考慮邊緣情況

An edge case would be if a player tries to play a move in the same square more than once.

一個極端的情況是，如果玩家嘗試在同一方塊中進行多次移動。

4. Test anything that is complex

4.測試任何復雜的事物

The algorithm to find the winner is the most complex part of this example.

尋找獲勝者的算法是此示例中最復雜的部分。

Here’s a sample test plan:

這是一個示例測試計劃：

- Test that the initial state of the board is correct (i.e. board is visible and empty)- Test that a move can be played- Test that moves alternate between X and O- Test that a move can be played to a square only once- Test that a winner can be found in a row- Test that a winner can be found in a column- Test that a winner can be found in a diagonal- Test that a draw can be found

So, now it’s your turn. Think about your app and, as a baseline, think of 5–10 tests that you can write.

所以，現在輪到您了。 考慮一下您的應用程序，并以基線為基準，考慮可以編寫的5-10個測試。

4.使它工作，然后使其漂亮，然后使其快速 (4. Make it work, then make it pretty, then make it fast)

The title of this section sums it up pretty well, but when you’re working on building out your challenge, you should follow these 3 steps IN THIS ORDER:

本節的標題很好地總結了這一點，但是當您著手應對挑戰時，請遵循以下3個步驟：

1. Make it work

1.使其工作

2. Make it pretty

2.使其漂亮

3. Make it fast

3.快速

1. Make it work

1.使其工作

When you’re given a take-home coding challenge, no matter what you do, the most crucial part of the challenge is to make it work. If you submit an app that has a nice UI, that will not matter if your app does not work or meet all of the requirements. Because building features to spec is a key aspect of your future job as a developer, you first and foremost need to focus on the functionality of your app and prioritize that above all else.

當您面臨實實在在的編碼挑戰時，無論您做什么，挑戰中最關鍵的部分就是使其發揮作用。 如果您提交的應用程序具有良好的用戶界面，則不管您的應用程序不能正常工作還是滿足所有要求都沒關系。 由于按規范構建功能是開發人員未來工作的關鍵方面，因此您首先需要重點關注應用程序的功能，并將其放在首位。

This is also key if you are low on or run out of time. Coding challenges can be a lot of work, especially if you want to go above and beyond to ensure that you make it to the next interview round. But, I can guarantee that you will not make it to the next round if your app doesn’t function properly or is missing some key components.

如果您的時間不多或時間用完，這也是關鍵。 編碼挑戰可能需要大量工作，尤其是如果您想超越并確保進入下一輪面試時，尤其如此。 但是，我可以保證，如果您的應用無法正常運行或缺少一些關鍵組件，您將不會進入下一輪。

So, if you’re building a front-end app, this means focusing on making it work first, and styling/UI last. If you are building a back-end or full-stack app, focus on making it work before trying to refactor your code into the most elegant solution, and only then worry about optimization.

因此，如果您要構建前端應用程序，則意味著著重于使其首先運行，最后是樣式/ UI。 如果要構建后端或全棧應用程序，則在嘗試將代碼重構為最優雅的解決方案之前，請先使其工作正常，然后再擔心優化。

Even if you end up without any time to go back and refactor your code or style your UI, having a working app to present is more important. You can always talk to the interviewer about how you would improve your app, and refactoring some of your code might even be part of the next round of interviewing.

即使最終沒有時間返回并重構代碼或為UI設置樣式，擁有可運行的應用程序也顯得更為重要。 您可以隨時與面試官討論如何改進您的應用程序，并且重構某些代碼甚至可能是下一輪面試的一部分。

2. Make it pretty

2.使其漂亮

Make it pretty has two interpretations here. One is making the code pretty, and the other is making the UI pretty. Making the code pretty can be done in several ways. First, ensure indentation is consistent and your code is readable. Second, if you got something to work in a quick, hacky way, think about how you can refactor it to be a more elegant solution without overcomplicating it.

使它變得漂亮在這里有兩種解釋。 一種是使代碼漂亮，另一種是使UI漂亮。 使代碼漂亮可以通過多種方式完成。 首先，確保縮進一致并且代碼可讀。 其次，如果您可以快速，輕松地進行操作，請考慮如何將其重構為更優雅的解決方案，而不會過于復雜。

If you’re doing a front-end or full-stack challenge, you can also make the UI pretty as part of this step. Whether you use a library or write your own custom styles for your app, making the UI look good will show your interviewer that you’re taking the user experience into consideration when building a feature.

如果您要進行前端或全棧挑戰，則還可以在此步驟中使UI變得漂亮。 無論您是使用庫還是為應用程序編寫自己的自定義樣式，使用戶界面看起來都不錯，這將使您的面試官知道在構建功能時要考慮用戶體驗。

For some more front-end-focused challenges, you’ll be given a specific mockup to match. In these cases, making sure you’re detail oriented down to the last pixel is incredibly important. Part of your role may involve translating mockups from designers into user interfaces, so companies want to get a sense of how you approach those types of tasks.

對于一些面向前端的挑戰，將為您提供一個特定的模型以進行匹配。 在這些情況下，確保您的細節面向最后一個像素非常重要。 您的部分角色可能涉及將模型從設計師轉換為用戶界面，因此公司希望對您如何處理這些類型的任務有所了解。

3. Make it fast

3.快速

Once you’ve made your app work, made it pretty (in the code, UI, or both), it may be time to make it fast! This is where understanding performance and BigO notation comes in handy.

一旦使您的應用程序正常工作，使其變得漂亮(在代碼，UI或同時在兩者中)，就可能是時候讓它變得更快了！ 在這里，了解性能和BigO標記很方便。

You should take a look at your code and see if there are any areas where increasing the scale might be an issue. For example, are you using a double for loop somewhere? What if the arrays you’re looping over become super long?

您應該看一下代碼，看看是否存在增加規模的問題。 例如，您是否在某處使用double for循環？ 如果您要遍歷的數組變得超長怎么辦？

If you think about these kinds of edge cases, you can then come up with plan to improve your code. Taking something that would have been running O(n) and making it O(1) will show that you’re thinking about performance when you’re building things.

如果考慮到這些極端情況，則可以提出改進代碼的計劃。 取一個本可以運行O(n)并將其O(1)將表明您在構建事物時正在考慮性能。

如何使您的代碼大放異彩 (How to make your code shine)

When given a take-home coding challenge, many people think about how to build an app that works, but stop there. In this section, I’ll go over things an engineer reviewing your code will look for, so you can take your challenge to the next level and make your code shine.

當面對帶回家的編碼挑戰時，許多人都在考慮如何構建可以運行的應用程序，但是到此為止。 在本節中，我將介紹工程師審查您的代碼所需要的內容，以便您將挑戰提高到一個新的水平，并使代碼更光彩。

When an engineer is reviewing your code, they will look for several different things. They will likely try to run your app to play around with it and see it working. After that, they will delve into the actual code, looking to see how you organized your app architecture and reading code in individual files.

工程師查看您的代碼時，他們會尋找幾種不同的東西。 他們可能會嘗試運行您的應用程序以使其運行并查看其運行情況。 之后，他們將深入研究實際的代碼，以了解您如何組織應用程序架構并讀取單個文件中的代碼。

There are several things you can do to make your code stand out. You want your code to be:

您可以做一些事情來使您的代碼脫穎而出。 您希望您的代碼為：

• Readable
  可讀的
• Easy to follow
  易于遵循
• Well organized
  井井有條
• Clean (properly indented, free of syntax errors and unnecessary whitespace)
  干凈(縮進正確，沒有語法錯誤和不必要的空格)

These are the basics that don’t take much effort outside of mindfulness to get right. Now let’s talk about three of the more involved code style considerations:

這些是在正念之外不需要付出太多努力的基本知識。 現在，讓我們談談涉及代碼風格的三個方面的注意事項：

1. How to name things

1.如何命名事物

2. How to use comments effectively

2.如何有效使用評論

3. How to format your code as you write it

3.如何在編寫代碼時格式化代碼

1. How to name things

1.如何命名事物

Naming is one of the hardest problems in programming. One of the keys to naming things is to make sure you’re naming them in a way that another developer who is unfamiliar with the code can easily jump in and understand.

命名是編程中最困難的問題之一。 命名事物的關鍵之一就是確保以一種不熟悉代碼的開發人員可以輕松進入并理解的方式來命名它們。

For functions, think about what exactly the function is doing. Is the function checking whether there is a winner on a row of a Tic Tac Toe board? Then a great name would be checkRow. Is your function handling a click on a square of the Tic Tac Toe board? Then a great name would be handleClick.

對于函數，請考慮該函數到底在做什么。 該功能是否正在檢查Tic Tac Toe板的一排中是否有贏家？ 那么一個好名字將是checkRow 。 您的功能是否正在處理Tic Tac Toe板的正方形的單擊？ 那么一個好名字將是handleClick 。

One quick tip: if you find yourself losing your flow because you keep stopping to think of the perfect name, split your process into two steps. First, write working code with any names (like foo, bar, and baz). Then take a second pass through to improve them.

一個快速提示：如果您因為停下來想出一個完美的名字而發現自己流失了自己的流程，請將您的流程分為兩個步驟。 首先，使用任何名稱(例如foo ， bar和baz )編寫工作代碼。 然后再進行一次改進。

2. How to use comments effectively

2.如何有效地使用評論

Adding comments can be a great way to capture what you were thinking at the time you wrote a specific piece of code. This can be useful to you, or anyone else who comes across your code in the future and needs to understand it, tweak it, or rewrite it.

添加注釋可能是捕獲編寫特定代碼時的想法的好方法。 這對您或將來遇到您的代碼并且需要了解，調整或重寫它的任何人來說可能都是有用的。

Think of comments as adding clarity to your code. But, pay attention, because there is such a thing as too many comments.

將注釋視為可以增加代碼的清晰度。 但是，請注意，因為有太多評論。

Here is where you most likely do not need comments:

這是您最可能不需要評論的地方：

• When you declare a variable
  聲明變量時
• When you declare a function
  聲明函數時

Don’t do this:

不要這樣做：

The variable or function name should be enough to explain exactly what it does. If you need a comment to explain it, then you need to give it a better name!

變量或函數名應足以解釋其作用。 如果您需要評論來解釋它，則需要給它起一個更好的名字！

Here are some examples of where comments can be useful:

以下是一些注釋可能有用的示例：

• HTML
  HTML
• CSS
  CSS
• Technically tricky lines of code
  技術上棘手的代碼行

First, let’s talk about HTML. Markup seems pretty self-explanatory, right? So, why would you need comments? Let’s say you have a really long HTML file with A LOT of <div>s. Comments can be a good way to signal which </div> tags close which sections.

首先，讓我們談談HTML。 標記看起來很不言自明，對嗎？ 那么，為什么需要評論？ 假設您有一個非常長HTML文件，其中包含許多<d iv> s。 注釋可以很好地表明which </ div>標簽關閉了哪些部分。

In CSS, comments are a good way to divide up your styles if you have a lot of styles in one file. This way, when you come back to the code later and want to make a change, it’s easier to find the styles for that one section you need to update.

在CSS中，如果一個文件中包含很多樣式，則注釋是一種很好的方式來劃分樣式。 這樣，當您稍后返回代碼并想要進行更改時，可以輕松找到需要更新的那一部分的樣式。

Comments in CSS are also very useful whenever you are hard-coding any math or adding an arbitrary number of pixels as margin, padding, and so on. Comments can be useful to explain things like this that are specific to your application.

每當您對任何數學運算進行硬編碼或添加任意數量的像素作為邊距，填充等時，CSS中的注釋也非常有用。 注釋對于解釋此類特定于您的應用程序的內容很有用。

One of the best uses for comments is when you’ve written code that is technically difficult or just not intuitive. You should always strive for simple, understandable code as much as possible. However, sometimes you will have confusing code — maybe you’ve chained a bunch of methods together or are using a complex regular expression — and it would help to explain what is happening in a comment.

注釋的最佳用途之一是在編寫技術上困難或不直觀的代碼時。 您應該始終爭取盡可能簡單的代碼。 但是，有時您會遇到混亂的代碼-也許您已經將一堆方法鏈接在一起或使用了復雜的正則表達式-它將有助于解釋注釋中發生的事情。

You are almost done learning how to make your code shine! Just one more step.

您幾乎完成了學習如何使代碼發光的工作！ 僅一步之遙。

3. How to format your code as you write it

3.如何在編寫代碼時格式化代碼

I’m a STICKLER about formatting when it comes to code. And, it’s not just me. You’ll find that the best engineers also care about well-formatted, clean code. Why? First, it’s much easier to read! Coding can be really challenging, so when code is easier to read, it makes our jobs as developers that much easier. Also, writing clean code sends a message to your interviewers that you take pride in the craft of writing code, and for many teams, this is a big deal.

我是代碼方面的格式化專家。 而且，不僅僅是我。 您會發現最好的工程師也關心格式正確的干凈代碼。 為什么？ 首先，它更容易閱讀！ 編碼確實非常具有挑戰性，所以當代碼更易于閱讀時，它使我們作為開發人員的工作變得更加容易。 此外，編寫簡潔的代碼還會向您的面試官傳達一條信息，即您以編寫代碼的技巧為榮，對于許多團隊來說，這很重要。

So, how do you make sure the code style sticklers will approve of your code? There are a few simple tricks you can use as you’re working through your coding challenge to ensure the end result comes out clean and you don’t have to spend time at the end reformatting everything.

那么，如何確定代碼風格貼紙會批準您的代碼？ 在解決編碼難題時，可以使用一些簡單的技巧，以確保最終結果清晰無誤，并且不必在最后花時間重新格式化所有內容。

• Choose tabs or spaces and be consistent across your entire application (i.e. no 2 spaces in some files, 4 spaces in others)
  選擇選項卡或空格，并在整個應用程序中保持一致(即某些文件中沒有2個空格，其他文件中沒有4個空格)
• Indent your code properly as you go so that it stays readable and isn’t all over the place
  在執行過程中適當縮進代碼，以使其保持可讀性，并且不會在各處出現
• Get rid of trailing whitespace! Whitespace can sometimes wreck havoc, so it’s best to just get rid of it as you write your code.
  擺脫尾隨空格！ 空格有時可能會造成破壞，因此在編寫代碼時最好將其消除。
• Keep your syntax consistent throughout your entire app. If you’re using a linter, this will be easier, but requires setting one up. If you don’t have time to set one up, pay attention. Don’t use ES5 in some places in your app and ES6 in others. Pick one and stick with it!
  在整個應用程序中保持語法一致。 如果您使用的是皮棉機，這會比較容易，但是需要進行設置。 如果您沒有時間進行設置，請注意。 不要在應用程序的某些地方使用ES5，在其他地方不要使用ES6。 選擇一個并堅持下去！
• Remove unnecessary logging and debug statements when you’re done using them! Unless logging is part of your application, you’ll want to remove any temporary statements you were using while building your app.
  使用完不必要的日志和調試語句后，請刪除它們！ 除非日志記錄是應用程序的一部分，否則您將希望刪除在構建應用程序時使用的所有臨時語句。
• Always leave a newline at the end of every file
  始終在每個文件的末尾保留換行符

That’s it! It’s pretty simple, and once you’re in the habit of doing this, not only will your code be easier for you to read, but it will also be easier for others to read and maintain. Many new developers haven’t been exposed to very much code maintenance, but trust me, when you have to clean up code someone else has written, you will be more thankful if it was neatly organized to start. Pay it forward!

而已！ 這非常簡單，一旦習慣了這樣做，不僅使您的代碼更易于閱讀，而且他人也更易于閱讀和維護。 許多新開發人員并沒有進行過多的代碼維護，但是請相信我，當您必須清理別人編寫的代碼時，如果代碼組織得井井有條，您將更加感激。 向前付款！

Here’s an example of badly formatted code:

這是格式錯誤的示例：

Here’s an example of the same code, but cleanly formatted and MUCH more readable:

這是相同代碼的示例，但格式干凈，可讀性強：

如何將挑戰提升到新的水平 (How to take your challenge to the next level)

Here are 3 ideas for how you can take your coding challenge to the next level:

這里有3個想法，可以幫助您將編碼挑戰提高到一個新的水平：

1. Bonuses

1.紅利

2. UI/UX design (for front-end or full-stack challenges)

2. UI / UX設計(用于前端或全棧挑戰)

3. Data validation and error handling

3.數據驗證和錯誤處理

1. Bonuses

1.紅利

Not all coding challenges come with bonuses, but if yours does and your goal is to get a job offer, do them! Why? It’s pretty simple. If you go above and beyond in your coding challenge, it will show that you will go above and beyond once you’re hired at this company. Completing bonus requirements is a high competence trigger for the interviewer.

并非所有的編碼挑戰都附帶獎金，但是如果您這樣做并且您的目標是獲得工作機會，那就去做吧！ 為什么？ 很簡單 如果您在編碼方面的挑戰超越，這將表明您一旦被這家公司錄用，就會超越您。 完成獎金要求對于面試官來說是一個很高的能力觸發條件。

2. UI/UX design (for front-end or full-stack challenges)

2. UI / UX設計(用于前端或全棧挑戰)

Some front-end or full-stack challenges will mention UI/UX design as a bonus, but if they don’t, putting in some effort to make the UI look nice and be easy to use will go a long way. You can either go the route of adding your own custom CSS or plugging in a library or two to help make your styling even more painless. If you use a library, just make sure that you understand how it works enough to explain how you’ve used it.

一些前端或全棧挑戰將提到UI / UX設計作為獎勵，但是，如果不這樣做，則付出一些努力使UI外觀美觀且易于使用將有很長的路要走。 您既可以添加自己的自定義CSS的方法，也可以插入一兩個庫來幫助使樣式更加輕松。 如果您使用的是庫，只需確保您了解它的工作原理足以解釋您的使用方式。

3. Data validation and error handling

3.數據驗證和錯誤處理

Data validation and error handling are key components in production apps. Adding either one of these (or both!) to your challenge will help make it stand out. Many developers who are new to coding and haven’t worked in a production codebase before don’t have a ton of exposure to either of these, so if you add error handling for edge cases it will show that you thought through a lot of different situations.

數據驗證和錯誤處理是生產應用程序中的關鍵組件。 將其中一個(或兩個！)添加到您的挑戰中將有助于使其脫穎而出。 許多對編碼不熟悉的開發人員之前都沒有在生產代碼庫中工作過，因此他們對這兩種情況都不了解很多，因此，如果為邊緣情況添加錯誤處理，則會表明您考慮了很多不同的問題情況。

如何編寫出色的自述文件 (How to write an awesome README)

You may be done writing code, but you’re not done writing yet — it’s time to write your README.

您可能已經完成了編寫代碼的工作，但是還沒有完成編寫-是時候編寫您的自述文件了。

Why you should include a README

為什么要包含自述文件

READMEs are incredibly important, both for professional developers and for job seekers working on take-home challenges. Including a README shows that you care about documentation.

自述文件對于專業開發人員和應對實戰挑戰的求職者都至關重要。 包含自述文件表明您關心文檔。

Documentation helps spread knowledge across teams and serves as a supplement to your code. Having documentation for your take-home challenge ensures that anyone else (or future you) can jump into your code with a clear understanding of what you’ve built without any guessing games.

文檔有助于在團隊之間傳播知識，并作為代碼的補充。 擁有應對挑戰的文檔，可確保其他任何人(或將來成為您)可以清楚地了解您所構建的內容而跳入您的代碼，而無需進行任何猜測。

Your README is also the KEY to making sure that everyone reviewing your challenge has the most painless experience possible. Finally, your README is a way of proving to your reviewer that you successfully met the requirements of the challenge.

您的自述文件也是確保每個審閱您的挑戰的人都擁有最痛苦的體驗的關鍵。 最后，自述文件是一種向審核者證明您已成功滿足挑戰要求的方法。

How to write your README

如何編寫自述文件

Writing a great README is not hard, and you will stand out a great deal from the other applicants with one. Here are the five sections I’d recommend you include:

編寫出色的自述文件并不難，您將與其他申請人脫穎而出。 這是我建議您包括的五個部分：

1. Installation instructions

1.安裝說明

2. Discussion of technologies used

2.討論使用的技術

3. A section demonstrating that you met the requirements

3.顯示您符合要求的部分

4. If there are bonuses, a section demonstrating that you met them

4.如果有獎金，則顯示您已達到獎金的部分

5. For algorithms and data structures, time and space complexity

5.對于算法和數據結構，時間和空間復雜度

1. Installation instructions

1.安裝說明

When writing your README, don’t make any assumptions. Write out all of the steps to run your app locally and test them yourself. This includes cloning the repo from Github, running installation commands, and starting up a server. Also, make sure to include versions of software that you are using. This will ensure that the developer reviewing your code has a seamless experience setting up and running your app, and if they do happen to run into any trouble due to versioning, they will have all of the information they need right there in the README.

在編寫自述文件時，請勿做任何假設。 寫下所有步驟以在本地運行您的應用并自己進行測試。 這包括從Github克隆存儲庫，運行安裝命令以及啟動服務器。 另外，請確保包括正在使用的軟件版本。 這將確保檢查您代碼的開發人員具有無縫的設置和運行您的應用程序的經驗，并且如果由于版本控制而碰巧遇到任何麻煩，他們將在README中獲得所需的所有信息。

2. Discussion of technologies used

2.討論使用的技術

This section is as simple as it sounds — make a list of all of the technologies you used including frameworks and libraries. If you had to find a library for a specific piece of functionality in your take-home challenge, mention it here and include a link to the docs.

這部分聽起來很簡單-列出您使用的所有技術，包括框架和庫。 如果您必須在實戰挑戰中找到某個特定功能的庫，請在此處進行提及，并提供指向文檔的鏈接。

3. A section demonstrating that you met the requirements

3.顯示您符合要求的部分

Usually your take-home challenge will come with some sort of requirements spec, so make sure to include a section in your README where you describe the requirements and how you met them. In some cases, you can take the product spec you were given and write a short explanation of how you met each requirement in a list. In other cases, you can simply include a short paragraph explaining how you satisfied the requirements. It’s totally up to you how you do it, just make sure you include it.

通常，帶回家的挑戰會附帶某種要求規范，因此請確保在自述文件中包括描述要求以及如何滿足要求的部分。 在某些情況下，您可以使用給出的產品規格，并在列表中寫下如何滿足每個要求的簡短說明。 在其他情況下，您可以僅包含一小段說明您如何滿足要求。 完全取決于您的操作方式，只需確保將其包括在內即可。

4. If there are bonuses, a section demonstrating that you met them

4.如果有獎金，則顯示您已達到獎金的部分

Similar to the requirements section above, you’ll want to highlight any bonuses you completed while working on the take-home challenge. If you attempted a bonus, but couldn’t quite get something to work, then the README is also a good place to address that. You can discuss the approach or approaches you tried and what worked or didn’t work.

與上面的要求部分類似，您需要突出顯示在完成實地挑戰時完成的所有獎金。 如果您嘗試獲得獎金，但又無法完全解決問題，那么自述文件也是解決此問題的好地方。 您可以討論您嘗試過的一種或多種方法以及什么有效或無效。

5. For algorithms and data structures, time and space complexity

5.對于算法和數據結構，時間和空間復雜度

If you had to write any algorithms or data structures as part of your take-home challenge, it’s helpful to include the space-time complexity of your final algorithm. This can be done in Big O notation.

如果您需要編寫任何算法或數據結構來應對挑戰，那么將最終算法的時空復雜度包括在內會很有幫助。 這可以用Big O表示法完成。

One final word of advice: write your README in markdown so it looks nice! This will demonstrate that you know (or are willing to learn) another language that will come in handy as a full-time developer.

最后的建議是：在markdown中編寫自述文件，這樣看起來不錯！ 這將表明您知道(或愿意學習)另一種可以作為專職開發人員使用的語言。

Here is an example README for a Tic Tac Toe app:

這是井字游戲應用程序的自述示例：

點擊發送之前的最后步驟 (Final steps before you hit send)

Now that you’ve written your README, you’re almost ready to hit send! Before you do that, take the time to double check all of your work using the following checklist:

既然您已經編寫了自述文件，那么您幾乎可以開始發送了！ 在執行此操作之前，請花點時間使用以下清單仔細檢查所有工作：

• Re-read the take-home challenge instructions to make sure you didn’t miss any requirements
  重新閱讀帶回家挑戰說明，以確保您沒有錯過任何要求
• Review your app’s code to ensure that it shines
  查看您的應用程序代碼以確保其閃亮
• Run your app’s automated tests and make sure they are all passing
  運行應用程序的自動化測試，并確保它們都通過了
• Test your app manually and make sure everything is working properly
  手動測試您的應用，并確保一切正常
• Test your app installation instructions from your README
  根據自述文件測試應用安裝說明
• Start an email draft and copy your README into it for convenience
  啟動電子郵件草稿并將您的自述文件復制到其中，以方便使用
• If requested, make sure to attach a zip file of your code
  如果需要，請確保附加代碼的zip文件
• Write an email to your contact at the company
  給您公司的聯系人寫一封電子郵件

Your email can be short and sweet — I always like to highlight something I enjoyed about the challenge or something I learned. Here’s an example:

您的電子郵件簡短而甜美-我總是喜歡強調我對挑戰感到滿意的東西或我學到的東西。 這是一個例子：

Hi <NAME>,

I hope you had a great week! I had fun diving back into React with this challenge. Here is my Github repo and I’ve included my README below. Please let me know if you have any questions.

Just so you know, I’m interviewing with a few other companies and I just received an offer yesterday — I need to get back to them next week. Of course, I am excited about the opportunity at <COMPANY NAME>, so I’m looking forward to hearing from you!

Thanks,<NAME>

Note that you should only mention interviewing with other companies or offer deadlines if either is actually the case. I feel you should be honest and candid about your situation and maintain leverage for a potential future compensation negotiation at the same time.

請注意，您只應提及與其他公司的面試，或在實際情況中提供截止日期。 我認為您應該對自己的情況誠實并坦率，并同時為將來可能的賠償談判保持杠桿作用。

Now, finally, hit send!

現在，最后，點擊發送！

結論 (Conclusion)

I hope this Essential Guide was helpful and you learned something that you can apply to a take-home challenge or in your day-to-day work. If you have any comments, questions, or other feedback, please don’t hesitate to reach out. You can reach me at jane@fullstackinterviewing.com.

希望本基本指南對您有所幫助，并且您學到了一些可以應用于實戰挑戰或日常工作中的知識。 如果您有任何意見，問題或其他反饋，請隨時與我們聯系。 您可以通過jane@fullstackinterviewing.com與我聯系 。

Also, if you enjoyed this guide and want to learn more, feel free to sign up for my email list:

另外，如果您喜歡本指南并想了解更多信息，請隨時注冊我的電子郵件列表：

翻譯自: https://www.freecodecamp.org/news/the-essential-guide-to-take-home-coding-challenges-a0e746220dd7/

c++編碼風格指南