程序员应该避免的不良代码习惯

发表于 更新于 分类于
代码习惯对程序员来说是十分重要的，关系到你的工作效率。所以要尽量避免不良代码习惯

前言

代码习惯对程序员来说是十分重要的，关系到你的工作效率。如果你有很好的代码习惯，既可以减少代码出现问题的概率（间接减少回头debug的时间），也可以增加代码的可读性和可维护性。因为这篇文章标题是不良代码习惯，所以我在这一章简略提一下有哪些良好的代码习惯：

  1. 遵守google style guide 或者别的你们公司的style guide
  2. 不要重复代码
  3. 接口少暴露细节，代码注释也不要暴露不必要的细节

接下来我们谈谈有哪些不良的代码习惯吧

API设计避免误解

事例

假设我们现在有一个封装好的基础库，用于普罗米修斯上报，函数签名大概是

1
func Histogram(metricName string, data any)

你一定会以为这个函数的作用是往metricName这个指标上传数据是吧，但这个函数实现的时候，自动往metricName后面添加了histgram后缀。这样的实现会出现什么问题呢？

设计缺点

  1. 无文档无注释，但是实现却和大家想的不太一样，会造成误解。很有可能用户调用函数后，在监控面板上按照metricName怎么都找不到上传的指标数据。
  2. 设计者的解释是，添加指标类型后缀可以方便辨认指标类型。但是用户即然已经写了调用代码，自然是清楚自己写的是什么类型。退一步讲，如果用户真的有这种需求，提供一个原样上报的借口也可以实现一样的功能，还更灵活。
  3. 没有提供可选的原样上报API，用户没有选择
  4. 如果用户原本已经有些好的监控指标和面板，被迫使用这个API的话（因为没有原样上报的API），必须绕过这个API直接调用更底层的上报，或者手动更改面板，无缘无故的给用户添加工作量。

总结

所以我们应该清楚定位API的目标，作为提供基础能力的API，要么给用户更多更灵活的选择，要么尽量提供直接而简单的功能，让用户在简单的基础API之上搭建自己的应用，而不是自以为是的提供一些高级功能，却不提供底层功能。

避免Magic Number

Magic Number 是指在程序中出现没有注释或者变量名说明的独特数字。

比如说在程序中突然出现了一个hard code的数字169427362而且没有任何说明。后来者很难明白到底这个数字是有意为之还是任何一个数字都可以替换。这种写法对可读性毫无帮助，无端增加阅读难度，请尽量不要写Magic Number。

把Python里的常量当变量用

1
2
3
STRING_TEMPLATE = 'some text blabla %s'
some_str = STRING_TEMPLATE
some_str.replace('.')

这段代码只是一个示例。python中没有像c++那样的const关键字，可以靠编译器保证常量规则。一般在python中我们用全大写的变量名表示这是一个常量。

这段代码的问题就是打破了这个惯例，把常量赋值给别的变量并且对里面的值进行改变。

不要在工作中做这种打破惯例/contract的事情。

不要盲目优化性能，牺牲可读性

一个代码文件，时间单位都是统一的秒。
现在你可以有两种改法：

  1. 引入微秒为时间单位，也就是这个文件现在既有秒，也有微秒作为时间单位的变量。但是可以节省一个除法操作（微秒转化为秒的那个除法）。
  2. 保持整个文件的变量都使用秒为时间单位，缺点就是相对方案1，多了那一个微秒转化的除法。

那么我们到底应该用哪种写法呢？

如果这个除法操作是非常非常频繁的发生，比如是百万级别的触发，那么应该采取第一种方案，毕竟这个时候对性能会有非常大的影响。

但一般来说这种情况很少发生，那么这时候就应该以可读性为重，选择第二种方案。

所有这一切的决策目标，都是做正确的事，抓住当前的主要矛盾。