你见过最烂代码是什么?
GitHub上有个特别的项目，主要是教授你如何写出一个”让人窒息“的代码。这样在别人接手你的项目代码时，可以充分恶心一下他。 这个项目截止到目前为止，已经有2.5K的星星数。看来很多人都在努力学习，如何写出令人狗血不止的亮眼代码了。 该项目一共提供了19个准则，项目地址如下，读者们可以根据自己的实际情况看看自己是否有中招了。https://github.com/trekhleb/state-of-the-art-shitcode| 变量命名越少字越好 如果我们在编写代码的时候输入的东西越少，那么就有越多的时间去思考代码逻辑等问题。其中Good表示写出了好代码。 Good Bad | 变量/函数混合命名风格 变量和函数命名时进行混搭，把多种命名法混合在一起，显示自己的学识渊博。 Good Bad | 不要写注释 没人看你的注释，为什么要多此一举呢？ Good Bad 更多时候，评论应该包含一些“为什么”，而不是一些“是什么”。如果“什么”在代码中不清楚，那么代码可能太混乱了。 | 使用母语写注释 如果的一定要写注释，尽量使用母语作为注释，比如可以使用阿拉伯语，法语等作为注释 Good Bad | 尽可能混合不同的格式 混合多种不同的格式，比如可以使用多个双引号，打乱读者的阅读逻辑 Good Bad | 尽可能把代码写成一行 代码有多长写多长，这样能够充分说明你写代码的时候“文思泉涌” Good Bad | 不要处理错误 不需要让别人发现代码的错误，只要没有错误，就没有bug。 Good Bad | 广泛使用全局变量 使用全局变量，让你的代码更加适应全球化 Good Bad | 创建你不会使用的变量 多创建几个变量，以防万一你会使用到它，这样的代码才叫做未雨绸缪 Good Bad | 如果语言允许，不要指定类型和/或不执行类型检查。 如果对自己的代码有信心，就不需要去检查变量的类型，这充分说明了你的胸有成竹。 Good Bad | 有存在不执行的代码函数 多构造不需要执行的函数，者能充分说明你有多个plan b。 Good Bad | 三角法则 多嵌套条件语句，写起来就很顺手 Good Bad | 混合缩进 避免缩进，因为它们会使复杂的代码在编辑器中占用更多的空间。这样代码会变得不简洁 Good Bad 不要锁住你的依赖项 频繁更新依赖项，为什么坚持使用过去的版本，让我们使用最先进的库版本。 Good Bad | 函数长的比短的好 代码写得越长，说明你的逻辑思维能力也越厉害。所以不要把程序逻辑分成可读的部分。 | 不要测试你的代码 测试你的代码是很愚蠢的动作，说明你对自己的代码没有信心 | 避免代码风格统一 编写您想要的代码，风格不一定要统一，特别是在一个团队中有多个开发人员的情况下。这是“自由”的味道。 | 构建新项目不需要 README 文档 不需要readme文档，只需要看代码内容就知道功能了。这样会使得项目更加简洁。 | 保存不必要的代码 不需要的代码，肯定是需要删除的，不然会占空间  一夜之间收到这么多赞，受宠若惊。 另外我自己开了公众号，更多的精彩内容，可以关注我的公众号：算法一只狗