怎么写出火爆GitHub的代码

这篇文章主要介绍“怎么写出火爆GitHub的代码”，在日常操作中，相信很多人在怎么写出火爆GitHub的代码问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”怎么写出火爆GitHub的代码”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！

创新互联成立于2013年，先为合阳等服务建站，合阳等地企业，进行企业商务咨询服务。为合阳企业网站制作PC+手机+微官网三网同步一站式服务解决您的所有建站问题。

1. 以一种容易被混淆的方式命名变量

如果我们键入的东西越少，那么就有越多的时间去思考代码逻辑等问题。如下图所以，将变量命名为「a」，谁也不知道代表什么意思，相反，命名为「age」，就是普普通通的一般货色了。

2. 变量/函数混合命名风格

为不同庆祝一下。一般人会把变量名称和函数名称设定为同一格式，但使用不同风格才能既体现我们的编码能力，还能体现出我们的起名能力，一举两得。

3. 不要写注释

这一点作者给了一个官方吐槽：反正没人会读你的代码，为什么要写注释?这一点我深以为然，写注释的人是对自己代码没有信心的体现，难道不是么?(手动狗头

4. 使用母语写注释

如果您违反了“无注释”原则，那么至少尝试用一种不同于您用来编写代码的语言来编写注释。

比如母语是英语的开发者，可以用日文、韩文或俄文来做注释，实现一边写代码，一边进行外语学习。我们国内的开发者也可以尝试用一些小语种来写注释，毕竟我们是神秘的一群人。

5. 尽可能混合不同的格式

为不同庆祝一下。在符合代码规范的情况下，尽可能的混合不同的格式，比如示例中的单引号和双引号。

6. 尽可能把代码写成一行

相信大家都看过那些“一行代码xxx”的铁子，为什么他们一行代码实现大家就觉得很酷，我们写成一行就不行呢?

7. 不要处理错误

无论何时发现错误，都没有必要让任何人知道它。没有日志，没有错误弹框。

8. 广泛使用全局变量

作者说这是为了符合全球化的原则，有道理，有格局。

9. 构建你用不上的变量

以防万一。虽然现在用不上，万一之后有用呢?abc 是铁三角，永远不能分割。

10. 如果语言允许，不要指定类型和/或不执行类型检查。

没有类型才是最好的类型。

11. 你应该要有运行不到的代码

作为「Plan B」，你需要有一些运行不到的代码，这表示你做了额外的思考。

12. 三角法则

如果写代码是一项艺术，那么三角法则显然是最有艺术设计感的了。

13. 混合缩进

避免缩进，因为它们会使复杂的代码在编辑器中占用更多的空间。如果你不喜欢回避他们，那就捣个乱，使用混合缩进策略。(这条实在洗不动了)

14. 不要锁住你的依赖项

以非受控方式更新每个新安装的依赖项。为什么坚持使用过去的版本，让我们使用最先进的库版本。

15. 长函数比短函数好

不要把程序逻辑分成一个个代码块。如果 IDE 的搜索停止，而您无法找到所需的文件或函数，该怎么办?

• 一个文件中 10000 行代码是 OK 的;

• 一个函数体 1000 行代码是 OK 的;

• 处理许多服务(第三方和内部，也有一些工具、数据库手写 ORM 和 jQuery 滑块)在一个' service.js ' ?也是 OK 的。

16. 不要测试你的代码

这是重复的并且不需要的工作。

17. 避免代码风格统一

编写您想要的代码，特别是在一个团队中有多个开发人员的情况下。这是一个“自由”的原则。不特殊一些，怎么体现自己的特立独行!

18. 构建新项目不需要 README 文档

从一开始我们就应该保持不写 README 的好习惯(这个 GItHub 项目就没有 README，作者也是知行合一了)。

19. 保存不必要的代码

不要删除不用的代码，最多是注释掉。毕竟写过的每一行代码都是我们曾经流过的汗水，删掉了别人怎么知道我们写过呢~

玩归玩，闹归闹，别拿工作开玩笑

有一句话流传的挺广：“代码是给人读的，顺便让机器执行。”

我觉得很有道理，虽然代码是机器语言，但使用和调试还是由人来进行的，所以仍然需要最大程度的满足人性化的需求和设计思路。

到此，关于“怎么写出火爆GitHub的代码”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注创新互联网站，小编会继续努力为大家带来更多实用的文章！