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:

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

• HTMLHTML
• CSSCSS
• 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++编码风格指南