编码中统一更该变量的快捷键_更好编码的10个技巧

编码中统一更该变量的快捷键

Writing code can sometimes be the most difficult part of any software development process. If you don’t organize everything from the start – especially for big projects — the coding processes and code management afterwards may end up not just time consuming, but also a big headache.

有时，编写代码可能是任何软件开发过程中最困难的部分。 如果您从一开始就没有组织好所有事情，尤其是对于大型项目，那么随后的编码过程和代码管理可能不仅浪费时间，而且会很头疼。

Good code is maintainable, reusable, and testable. The following tips address how you and/or your development team can handle various coding tasks and how to keep everything as neat as possible. I will introduce you to some “best practices” that will help you write better code and help make you and your team happy and efficient.

好的代码是可维护，可重用和可测试的。 以下技巧介绍了您和/或您的开发团队如何处理各种编码任务，以及如何使所有内容保持尽可能整洁。 我将向您介绍一些“最佳实践”，这些最佳实践将帮助您编写更好的代码，并使您和您的团队快乐而高效。

1.使用编码标准 (1. Use a Coding Standard)

It’s easy to write bad, unorganized code, but it’s hard to maintain such code. Good code typically follows some standard for naming conventions, formatting, etc. Such standards are nice because they make things deterministic to those who read your code afterwards, including yourself.

编写不良的，无组织的代码很容易，但是很难维护这样的代码。 好的代码通常遵循一些有关命名约定，格式等的标准。此类标准非常好，因为它们使事后确定性的人员(包括您自己)可以确定。

You can create your own coding standard, but it’s better to stick to one with wider-acceptance. Publicly maintained standards like Zend Framework Coding Standard or soon to be PSR-1 Coding Style Guide instead, it will be easier for others to adapt.

您可以创建自己的编码标准，但是最好坚持接受更广泛的标准。 公共维护的标准(例如Zend Framework编码标准)或即将成为PSR-1编码样式指南的标准 ，其他人将更容易适应。

2.撰写有用的评论 (2. Write Useful Comments)

Comments are crucial. You won’t appreciate them until you leave your thousand-line script for a couple of days and return to and try and make sense of it. Useful comments make life easier for yourself and those after you who have to maintain your code.

评论至关重要。 您将不满意它们，直到您将数千行脚本离开几天，然后返回并尝试理解它。 有用的注释使您自己以及以后必须维护代码的人的工作变得更加轻松。

Write meaningful, single line comments for vague lines; write full parameter and functionality descriptions for functions and methods; for tricky logic blocks, describe the logic in words before it if necessary. And don’t forget, always keep your comments up to date!

为模糊的行写有意义的单行注释； 编写功能和方法的完整参数和功能描述； 对于棘手的逻辑块，如有必要，请在其之前用文字描述逻辑。 并且不要忘记，请始终保持您的评论最新！

3.重构 (3. Refactor)

Code refactoring is the eighth habit of highly effective developers. Believe it or not, you should be refactoring your code on a daily bases or your code is not in good health! Refactoring keeps your code healthy, but what should you refactor and how?

代码重构是高效开发人员的第八个习惯。 信不信由你，您应该每天重构代码，否则您的代码状况不佳！ 重构使您的代码保持健康，但是您应该重构什么以及如何重构？

You should be refactoring everything, from your architecture to your methods and functions, variables names, the number of arguments a method receives, etc.

您应该重构所有内容，从体系结构到方法和函数，变量名称，方法接收的参数数量等。

How to refactor is more of an art more than a science, but there are a few rules of thumb that can shed some light on it:

如何重构更多的是一门艺术，而不是一门科学，但是有一些经验法则可以阐明这一点：

• If your function or method is more than 20-25 lines, it’s more likely that you are including too much logic inside it, and you can probably split it into two or more smaller functions/methods.
  如果您的函数或方法超过20至25行，则很可能在其中包含过多的逻辑，并且您可能会将其拆分为两个或更多个较小的函数/方法。
• If your method/function name is more than 20 characters, you should either rethink the name, or rethink the whole function/method by reviewing the first rule.
  如果您的方法/函数名称超过20个字符，则应重新考虑名称，或通过查看第一条规则重新考虑整个函数/方法。
• If you have a lot of nested loops then you may be doing some resource-intensive processing without realizing it. In general, you should rethink the logic if you are nesting more than 2 loops. Three nested loops is just horrible!
  如果您有很多嵌套循环，那么您可能正在做一些资源密集型处理而没有意识到。 通常，如果嵌套两个以上的循环，则应重新考虑逻辑。 三个嵌套循环简直太可怕了！
• Consider if there are any applicable design patterns your code can follow. You shouldn’t use patterns just for the sake of using patterns, but patterns offer tried-and-true ready-thought solutions that could be applicable.
  考虑您的代码是否可以遵循任何适用的设计模式。 您不应该仅仅为了使用模式而使用模式，而是模式提供了可以应用的久经考验的现成的解决方案。

4.避免使用全球法规 (4. Avoid Global Code)

Global variables and loops are a mess and can prove problematic when your application grows to millions of lines of code (which most do!). They may influence code elsewhere that is difficult to discern, or cause noisy naming clashes. Think twice before you pollute the global namespace with variables, functions, loops, etc.

全局变量和循环是一团糟，当您的应用程序增长到数百万行代码时(大多数情况！)，这可能会成为问题。 它们可能会影响难以识别的其他地方的代码，或引起嘈杂的命名冲突。 在使用变量，函数，循环等污染全局名称空间之前，请三思。

In an ideal case, you should have no blocks defined globally. That is. all switch statements, try-catch, foreach, while-loops, etc. should be written inside a method or a function. Methods should be written inside class definitions, and class and function definitions should be within namespaces.

在理想情况下，您应该没有全局定义的块。 那是。 所有switch语句，try-catch，foreach，while循环等都应写在方法或函数内部。 方法应在类定义内编写，而类和函数定义应在名称空间内。

5.使用有意义的名称 (5. Use Meaningful Names)

Never use names like $k, $m, and $test for your variables. How do expect to read such code in the future? Good code should be meaningful in terms of variable names, function/method names, and class names. Some good examples of meaningful names are: $request, $dbResult, and $tempFile (depending on your coding style guidelines these may use underscores, camelCase, or PascalCase).

切勿对变量使用$k ， $m和$test类的名称。 将来如何期望阅读此类代码？ 好的代码在变量名，函数/方法名和类名方面应该是有意义的。 有意义的名称的一些很好的例子是： $request ， $dbResult和$tempFile (取决于您的编码样式准则，它们可能使用下划线，camelCase或PascalCase)。

6.使用有意义的结构 (6. Use Meaningful Structures)

Structuring your application is very important; don’t use complicated structures, always stick to simplicity. When naming directories and files, use a naming convention you agree upon with your team, or use one associated with your coding standard. Always split the four parts of any typical PHP application apart from each other – CSS, HTML Templates/Layouts, JavaScript, PHP Code – and for each try to split libraries from business logic. It’s also a good idea to keep your directory hierarchy as shallow as possible so it’s easier to navigate and find the code you’re looking for.

构建应用程序非常重要； 不要使用复杂的结构，始终坚持简单性。 在命名目录和文件时，请使用您与团队达成一致的命名约定，或使用与您的编码标准关联的命名约定。 始终将任何典型PHP应用程序的四个部分(CSS，HTML模板/布局，JavaScript，PHP代码)彼此分开，并且每次尝试将库与业务逻辑分开。 保持目录层次尽可能浅也是一个好主意，这样可以更轻松地导航和查找所需的代码。

7.使用版本控制软件 (7. Use Version Control Software)

In the old days, good development teams relied on CVS and diff patches for version control. Nowadays, though, we have a variety of solutions available. Managing changes and revisions should be easy but effective, so pick whatever version control software that will work best with the workflow of your development team. I prefer using a distributed version control tool like Git or Mercurial; both are free software/open source and very powerful.

在过去，优秀的开发团队依靠CVS和diff补丁进行版本控制。 但是，如今，我们提供了多种解决方案。 管理更改和修订应该容易但有效，因此，请选择最适合您开发团队工作流程的任何版本控制软件。 我更喜欢使用Git或Mercurial等分布式版本控制工具； 两者都是免费软件/开源软件，功能非常强大。

If you don’t know what version control software is, I’d recommend reading Sean Hudgston’s series Introduction to Git.

如果您不知道什么是版本控制软件，建议您阅读Sean Hudgston的系列Git简介 。

8.使用自动构建工具 (8. Use Automated Build Tools)

Try to use tools like Ant or Phing to get your source prepared, compressed, and deployed. Building your whole application with a single command is a marvelous way to prevent errors and omissions that are inherent when performing repetitive tasks, and is a generally core pre-requisite for automated testing strategies. I recommend using Phing, it’s a well-supported build tool for PHP written to mimic Ant; if you aren’t familiar with it, check out Shammer C’s article Using Phing, the PHP Build Tool and Vito Tardia’s article Deploy and Release Your Application with Phing.

尝试使用Ant或Phing之类的工具来准备，压缩和部署源。 使用单个命令构建整个应用程序是防止执行重复任务时固有的错误和遗漏的绝妙方法，并且通常是自动化测试策略的核心先决条件。 我建议使用Phing，它是为模仿Ant而编写的受支持PHP构建工具。 如果您不熟悉它，请查看Shammer C的“ 使用Phing”一文 ，PHP Build Tool和Vito Tardia的“ 使用Phing 部署和发布应用程序” 。

9.使用代码记录器 (9. Use Code Documenters)

For large applications spanning several classes and namespaces, you should have automatically generated API documentation. This is very useful and keeps the development team aware of “what’s what.” And if you work on several projects at the same time, you will find such documentation a blessing since you may forget about structures switching back and forth between projects. One such documenter you might consider using is DocBlox.

对于跨越多个类和名称空间的大型应用程序，您应该具有自动生成的API文档。 这非常有用，并使开发团队知道“什么”。 而且，如果您同时从事多个项目，您会发现这样的文档是一件幸事，因为您可能会忘记在项目之间来回切换的结构。 您可能会考虑使用的一种此类文档记录器是DocBlox 。

10.使用测试框架 (10. Use a Testing Framework)

There are a plenty of tools that I really appreciate, but by far the ones I appreciate the most are the frameworks that help automate the testing process. Testing (particularly systematic testing) is crucial to every piece of your million dollar application. Good testing tools are PHPUnit and SimpleTest for unit testing your PHP Classes. For GUI testing, I recommend SeleniumHQ tools.

我真的很喜欢很多工具，但是到目前为止，我最欣赏的是帮助自动化测试过程的框架。 测试(特别是系统测试)对于百万美元应用程序的每一部分都至关重要。 良好的测试工具是PHPUnit和SimpleTest，用于对PHP类进行单元测试。 对于GUI测试，我建议使用SeleniumHQ工具 。

摘要 (Summary)

In this article you saw an overview of some of the best practices for writing better code, including using a coding standard to unify code formatting across the whole team, the importance of refactoring and how to embrace it, and using professional tools like testing frameworks, code documenters, and version control to help manage your codebase. If you’re not following these tips already, it’s worth the effort to adopt them and get your team on track.

在本文中，您概述了一些用于编写更好的代码的最佳实践，包括使用编码标准来统一整个团队的代码格式，重构的重要性以及如何接受它，以及使用诸如测试框架之类的专业工具，代码记录器和版本控制来帮助管理您的代码库。 如果您还没有遵循这些技巧，那么值得采用这些技巧并使您的团队步入正轨。

Image via DJTaylor/Shutterstock

图片来自DJTaylor / Shutterstock

翻译自: https://www.sitepoint.com/10-tips-for-better-coding/

编码中统一更该变量的快捷键