When you're learning to code, it can be easy to pick up some nasty habits along the way. Here are some tips to avoid common bad habits, and the good habits to keep in mind.

当您学习编码时，很容易在此过程中养成一些讨厌的习惯。 这里有一些技巧，可以避免常见的不良习惯和要记住的良好习惯。

好习惯 (The good habits)

Let's start with the positive shall we? These are the best habits that often impress me when working with Junior Developers (and all developers for that matter).

让我们从积极开始吧？ 这些是与初级开发人员(以及与此相关的所有开发人员)合作时经常给我留下深刻印象的最佳习惯。

经常提交/推送代码 (Commit/Push code often )

Chances are you'll have come across terms like "Git", and "GitHub", "source control" whilst on your coding journey. If you haven't:

在编码过程中，您很可能会遇到诸如“ Git”，“ GitHub”，“源代码控制”之类的术语。 如果您还没有：

1) Where have you been?!?

1)你去哪儿了？！？

2) You can learn about it here: https://www.freecodecamp.org/news/how-you-can-learn-git-and-github-while-youre-learning-to-code-7a592ea287ba/

2)您可以在这里了解它： https : //www.freecodecamp.org/news/how-you-can-learn-git-and-github-while-youre-learning-to-code-7a592ea287ba/

Source control is a marvellous thing. It's a backup of your code, allows you to track changes, and let's you quickly roll back when you have that "oh s***! everything is broken!" moment whilst coding.

源代码管理是一件了不起的事情。 它是代码的备份，可让您跟踪更改，让您在遇到“哦，s ***！一切都坏了！”的情况下快速回滚。 编码时。

Not to mention it makes life much, much easier when working as part of a team. I can't imagine working on code collaboratively without it - sharing code over email and slack?! *Quivers*.

更不用说它使工作变得更轻松，成为团队成员。 如果没有它，我无法想象协同工作代码-通过电子邮件和闲暇共享代码？ * 颤抖 *。

A good habit to have is to commit code often, even for your own side projects as practice. Personally I like to "check in" my code when I have a completed a small part of my project. For example, if I were creating a TODO list app, I would commit and push my code when I have added the 'new todo button', or when I've completed the 'checkbox functionality'.

一个好的习惯是经常提交代码，即使是自己实践的项目也是如此。 就个人而言，当我完成一小部分项目时，我喜欢“ 签入 ”我的代码。 例如，如果我正在创建TODO列表应用程序，则在添加“ 新的待办事项按钮”或完成“ 复选框功能”后 ，将提交并推送代码。

There are no hard and fast rules as to when to check in code. Other good times to commit code are:

关于何时检入代码没有严格的规定。 提交代码的其他好时机是：

• If you are about to finish up for the day (see a very important rule below)如果您要完成一天的工作(请参阅以下非常重要的规则)
• Before you do a major refactor or code change在进行重大重构或代码更改之前
• If there is a fire in the building (Just kidding, safety first)如果建筑物着火(开玩笑，安全第一)

There is only 1 important rule to follow when committing code.

提交代码时，仅遵循1条重要规则。

The code must build successfully and the tests must pass

代码必须成功构建并且测试必须通过

Does that count as 2 rules? Anyways, this is important. Something that is guaranteed to bring any development team to a halt is broken code. So before you commit your code, make sure the code builds and the tests pass!

那算作2条规则吗？ 无论如何，这很重要。 可以保证使任何开发团队停下来的都是断码。 因此，在提交代码之前，请确保代码已构建并且测试通过！

Lastly, make sure to use good commit messages. "Fixed bug" isn't as clear as "Fixed issue with 'save todo' button not calling onClick function correctly". This will not only be helpful for yourself but your teammates as well.

最后，请确保使用良好的提交消息 。 “已修复的错误”不如“已解决的“保存待办事项”按钮未正确调用onClick函数的问题”那么清晰。 这不仅对您自己有帮助，对您的队友也有帮助。

对变量，函数和文件使用明确的命名 (Use clear naming for variables, functions, and files)

Ah naming. The one thing in web development that we all thought was easy, is sneakily difficult at times. Naming is important though, as it makes our code easier to read and understand.

啊，命名。 我们都认为很简单的Web开发中的一件事有时很难做到。 但是命名很重要，因为它使我们的代码更易于阅读和理解。

When choosing a name for your variables, functions and files, try to make it as descriptive as possible. Why?

为变量，函数和文件选择名称时，请尽量使其具有描述性。 为什么？

• It makes it easy to quickly skim over code. If you see a method called getUsers() Without having to look at that method, you can be pretty sure that it's going to return a list of users.

  它使快速浏览代码变得容易。 如果您看到一个名为getUsers()的方法而不必查看该方法，则可以确定它会返回用户列表。

• Helps enforce separation of concerns. Oooh a fancy new term! Don't worry, this just means keeping related things together. For example in a Node.js app, if you have a /users endpoint and a /products endpoint, you might keep the users logic in the same file ( usersService.js for example ) and keep the products logic in another file. Wouldn't this make it easier to find things?

  帮助强制分离关注点。 哦，新名词！ 不用担心，这只是意味着将相关的东西放在一起。 例如，在Node.js应用程序中，如果您具有/users终结点和/products终结点，则可以将users逻辑保留在同一文件(例如usersService.js )中，并将products逻辑保留在另一个文件中。 这样会不会更容易找到东西？

Here's a simple function which is badly named (as are the parameter names) can you guess what it does?

这是一个命名错误的简单函数(参数名称也是如此)，您能猜出它的作用吗？

const function1 = (x, y) => {return x + y
}

This function could either add 2 numbers or concatenate 2 strings, but it's original intent is not clear. Let's say its intention was to add numbers, but another unsuspecting developer comes along and uses it to concatenate 2 strings. It might be ok for now, but later if we refactor this function to validate the numbers, then the code calling this function to concatenate strings will break. Oh no!

此函数可以添加2个数字或连接2个字符串，但是其原始意图尚不清楚。 假设它的目的是添加数字，但是另一个毫不客气的开发人员来了，并使用它来连接2个字符串。 现在可能还可以，但是稍后，如果我们重构此函数以验证数字，则调用此函数连接字符串的代码将中断。 不好了！

Here's the function with better naming:

这是命名更好的函数：

const addNumbers = (num1, num2) => {return num1 + num2
}

Now it's a bit clearer on what the function does, and what the parameters are.

现在，您可以更清楚地了解函数的功能以及参数的含义。

练习调试 (Practice debugging )

Would you believe that web developer's spend just as much time (if not more) fixing bugs? Yes, there will be bugs. And the best way to identify and fix a bug is to debug the code. Debugging is the process of "stepping" through your code, line by line, until you discover something you didn't expect.

您是否相信Web开发人员花费相同的时间(如果不是更多的话)来修复错误？ 是的，会有错误。 识别和修复错误的最佳方法是调试代码。 调试是逐行“逐步”执行代码的过程，直到发现意料之外的内容。

Luckily for us web developers, many IDE's come with built in debuggers that makes this really easy (here's a VS Code guide to setting up debugging for different languages. For other IDE's you can check out Google https://code.visualstudio.com/docs/editor/debugging)

幸运的是，对于我们的Web开发人员而言，许多IDE都带有内置调试器，这使得调试变得非常容易(这是VS Code指南，用于设置不同语言的调试。对于其他IDE，您可以查看Google https://code.visualstudio.com/ docs / editor / debugging )

So how do you effectively debug your code? Here's a few pointers:

那么如何有效地调试代码？ 这里有一些提示：

• Replicate the issue - replicate the bug a few times so you understand exactly what it is that causes the bug

  复制问题 -复制错误几次，以便您完全了解导致错误的原因

• Think - before you dive into the code and start aimlessly scavenging around, stop and think. Why would this be happening? What area's of the code are related to this?

  思考 -在深入研究代码并开始漫无目的地进行清理之前，请停下来思考。 为什么会这样呢？ 代码的哪些区域与此相关？

• Investigate the code - once you've had an idea of what areas of the code this is likely to affect, start digging in. After reading over the code, you might spot the issue. Hurray! If not, time to get out debugger out.

  研究代码 -一旦您知道这可能影响代码的哪些区域，就可以开始研究。阅读完代码后，您可能会发现问题。 欢呼！ 如果不是，请抽空调试器。

• Debug - Fire up the debugger, and go through the code line-by-line. Keep an eye on variable values (and how they change) and which functions get called (and which don't). Are the correct branches in an if statement being called? Are events being triggered correctly? Are calculations being performed correctly?

  调试 -启动调试器，然后逐行浏览代码。 密切关注变量值(及其变化方式)以及调用哪些函数(哪些不调用)。 是否在if语句中调用了正确的分支？ 是否正确触发了事件？ 计算是否正确执行？

编码前计划 (Plan before coding )

You have just awoken from a good nights sleep. You're eating breakfast and all of a sudden an awesome new side project idea comes to you. What a fantastic idea it is! A revelation!

您刚刚睡个好觉就醒了。 您正在吃早餐，突然之间出现了一个很棒的新项目计划。 这是一个多么奇妙的主意！ 一个启示！

You burst out of your chair towards your laptop, cornflakes flying everywhere, and start frantically coding. (Or is this just me? OK moving swiftly along...)

您从椅子上冲出手提电脑，玉米片四处飞扬，开始疯狂地编码。 (或者这就是我吗？可以快速移动...)

While it is often tempting to jump straight into your IDE and start coding, a bit of planning can go a long way.

虽然通常很想直接进入您的IDE并开始编码，但是进行一些规划可能会很长的路要走。

• Reduces the amount of "wasted" code 减少“浪费”代码的数量
• Reduces code changes减少代码更改
• Gives you solid goals to work towards为您制定坚定的目标
• It's an impressive skill for junior developers to have - it shows your critical thinking!对于初级开发人员而言，这是一项令人印象深刻的技能-它显示了您的批判性思维！

I won't go into too much detail here, as I've written a more comprehensive article on this topic here: How Developers Think: A Walkthrough of the Planning and Design Behind a Simple Web App

我将在这里不再赘述，因为我在这里写了一个更全面的文章： 开发人员的想法：简单Web应用程序背后的规划和设计演练

Here's a quick summary from the above article for now:

这里是上述文章的快速摘要：

• "What does it do?" - write out the features you want your app to have

  “ 它是做什么的？ ”-写出您希望应用程序具有的功能

• "What does it look like?" - make a quick sketch or wireframe with what your app should look like

  “ 看起来像什么？ ”-用您的应用程序外观快速绘制草图或线框

• "How do I position and style the elements?" - once you have your wireframes, start thinking about how you will position everything on the page

  “ 如何定位和设置元素样式？ ”-一旦有了线框，就开始考虑如何将所有内容放置在页面上

• "How does it behave?" - next, start thinking about how your app behaves. Thinking about the features, and what happens when the user clicks and action

  “ 它的行为方式？ ”-接下来，开始考虑您的应用程序的行为方式。 考虑功能，以及用户单击并执行操作时会发生什么

• "What will my code look like?" - with your behaviours and features in mind, start planning your code. What components will you need? will you need event handlers? state objects?

  “ 我的代码将是什么样？ ”-考虑到您的行为和功能，开始计划代码。 您需要什么组件？ 您需要事件处理程序吗？ 状态对象？

• "What do I need to test? And what can go wrong?" - think about the tests, edge cases and the parts of your code that could go wrong

  “ 我需要测试什么？什么会出错？ ”-考虑测试，边缘情况以及代码中可能出错的部分

不太好的习惯 (The not so good habits)

Now let's look at some of not so good habits that are easy to pick up. If you do some of these now, don't panic. We all do at some point! With some practice you can overcome them - and I'll give you some pointers on how to do this.

现在，让我们看看一些不太容易养成的好习惯。 如果您现在执行其中一些操作，请不要惊慌。 我们都在某个时候做！ 通过一些练习，您可以克服它们-我将为您提供一些指导。

盲目复制和粘贴代码 (Blindly copying and pasting code)

Put your hand up if you've ever encountered an issue or got stuck while coding? *raises hand*. Obviously, we hit problems all the time whilst coding. It's part of the game and it's our job to figure out how to overcome these problems.

如果在编码时遇到问题或卡住了，请举起手来吗？ * 举手*。 显然，我们在编码时总是遇到问题。 这是游戏的一部分，弄清楚如何克服这些问题是我们的工作。

Most of the time we resort to using Google, StackOverflow, or similar in search of answers to our problems. Now, there is nothing wrong with this approach - arguably, it should be encouraged as it's one the best/quickest way for a developer to solve a problem themselves.

大多数时候，我们会使用Google，StackOverflow或类似工具来寻找问题的答案。 现在，这种方法没有什么问题-可以说，应该鼓励使用这种方法，因为它是开发人员自己解决问题的最佳/最快方法之一。

The problem is, when we copy/paste code blindly without understanding it.

问题是，当我们盲目地复制/粘贴代码而不理解它时。

But if it works, what's the problem?!

但是，如果有效，出了什么问题？

A valid point. Here's the reasons why this can cause issues:

一个有效点。 这可能导致问题的原因如下：

• What happens when the code has to be changed? It'll be difficult to change code we don't understand当必须更改代码时会发生什么？ 更改我们不理解的代码将很困难
• If we don't understand the code, how can we be sure it truly solves the problem?如果我们不理解代码，我们如何确定它真正解决了问题？
• Can we be sure it doesn't affect other parts of the codebase in a negative way?我们可以确定它不会以负面方式影响代码库的其他部分吗？

So, how can we avoid this?

那么，如何避免这种情况呢？

• Reading - read through it line by line, and take the time to understand the code

  阅读 -逐行阅读，并花一些时间来理解代码

• Type - type it out instead of copying and pasting. This will force you can read/analyse each line as you type

  键入-键入而不是复制和粘贴。 这将迫使您在键入时可以读取/分析每一行

There is nothing wrong with copying and pasting, as long as we understand exactly what the code does. If a senior developer is code reviewing our work, and we can't explain what is happening because the code was copy/pasted, that won't look too good.

只要我们完全了解代码的作用，复制和粘贴就没有错。 如果高级开发人员正在代码审查我们的工作，并且由于代码已被复制/粘贴而无法解释正在发生的事情，那么看起来就不会太好。

不写测试 (Not writing tests)

This is arguably the worst habit that can be picked up when learning to code. A lot of tutorials walk us through the "happy path" of creating an app, which makes it easy to neglect the test writing. Why are test's so important?

可以说，这是学习编码时最容易养成的最坏习惯。 许多教程为我们提供了创建应用程序的“ 快乐之路 ”，从而可以轻松忽略测试编写。 为什么测试如此重要？

• Test's prove your code works. Nobody can argue about functionality working if the test passes!

  测试证明您的代码有效 。 如果测试通过，没有人会争论功能是否正常工作！

• Makes it easy to check that new features haven't broken anything. While coding, run your tests regularly. A few tests broken? You know early in the development process where stuff went wrong. As opposed to, finding out tomorrow when you come across it by accident

  轻松检查新功能是否完好无损 。 编码时，请定期运行测试。 几项测试坏了？ 您知道在开发过程的早期哪里出了问题。 与之相反，发现偶然遇到的明天

• A seat belt for refactoring. Write your code. Write your tests. Refactor your code. Run the tests. Tests pass? Everything still works, happy days! Now try changing your code without having a suite of tests to run. How can you prove everything works as it should?

  重构用安全带。 编写您的代码。 编写测试。 重构您的代码。 运行测试。 测试通过了吗？ 一切仍然正常，快乐的日子！ 现在尝试更改代码，而无需运行一组测试。 您如何证明一切正常？

So make sure to test your code. You don't have to test things like small side projects all the time, but it's good to practice now an again. When you get a job, you'll be aiming to have test coverage for most of your functionality and features. Practice those tests!

因此，请确保测试您的代码。 您不必一直测试小型项目，但是现在再次练习是个好习惯。 找工作时，您的目标是要针对大多数功能和特性进行测试。 练习那些测试！

There are many great tutorials on how to test your code, depending on your current projects and tech stack, try Googling "testing with {insert language}" or "How to test {insert language} apps". Heres a good overview of testing JavaScript.

根据您当前的项目和技术堆栈，有很多很棒的教程介绍如何测试代码，请尝试使用Google搜索“使用{insert language}测试”或“如何测试{insert language}应用程序”。 这里很好地概述了测试JavaScript的方法 。

遗漏文档 (Leaving out documentation)

Documentation. The boring "red tape" that comes with all projects. As someone once said:

文档。 所有项目附带的无聊的“繁文tape节”。 正如有人曾经说过的：

All developers hate writing it, but all developers want it

所有开发人员都讨厌编写它，但是所有开发人员都希望编写它

Which is true. Have you ever returned to an old side project and forgotten what it did? How much harder would it be if you were trying to use a third party library and there was no documentation to explain how it worked? This becomes especially more apparent when working in a large product company. What if another team needs to integrate with your code, but is unsure of the API?

没错 您是否曾经回到过一个旧的项目并且忘记了它的工作？ 如果您尝试使用第三方库，而没有文档说明它的工作原理，那么要付出多少努力？ 在大型产品公司工作时，这一点尤其明显。 如果另一个团队需要与您的代码集成，但不确定API怎么办？

It's important stuff, so here's some tips to practice:

这是很重要的东西，因此这里有一些实践技巧：

• README's - GitHub lets you add a readme to your project. This is the perfect place to store documentation for the project, as it's easy to find自述文件-GitHub允许您向项目添加自述文件。 这是存储项目文档的理想场所，因为很容易找到
• Include what the app does and how to run it - This gives the read a good place to start包括应用程序的功能以及运行方式-这为阅读提供了一个很好的起点
• Explain other "important things" - such as complicated logic, third party libraries and API's, or configuration settings解释其他“重要事项”-例如复杂的逻辑，第三方库和API或配置设置

---

---

谢谢阅读！ 想要更多类似的文章吗？ (Thanks for reading! Want more articles like this?)

Hopefully this has given you an insight into one creating good coding habits. If you'd like to be updated when I release more articles like this, feel free to join the mailing list over at chrisblakely.dev! Or reach me over at Twitter if you fancy a chat :)

希望这可以使您深入了解如何养成良好的编码习惯。 如果您想在我发布更多此类文章时进行更新，请随时通过chrisblakely.dev加入邮件列表！ 或者，如果您喜欢聊天，请通过Twitter与我联系:)

翻译自: https://www.freecodecamp.org/news/good-habits-to-have-as-an-aspiring-junior-developer-and-those-to-avoid/