问什么定义了代码的可读性？

EN

对我来说，可读性意味着代码在逻辑上很容易遵循。

1. 遵循缩进和格式化标准，以便代码及其结构清晰可见。
2. 变量的命名是有意义的，这样它们就可以交流意图。
3. 评论，只有在需要的地方，是简洁的，并遵循标准格式。
4. 使用卫士子句而不是嵌套的if语句。
5. 语言的功能是熟练地使用，利用迭代和递归，而不是复制和粘贴编码。
6. 功能是短暂的和重点，并做了一件事。
7. 间接性尽量减少，同时仍然保持灵活性。

不可读

        try:
          if item[1][2]=='1':
            qtytype='0'
            qty=str(item[1][0])
            items=item[1][0]
            amt='0.0'
            tot_amt=str(float(item[1][1])/100)
#              tot_amt=str(float(int(item[1][0])*int(item[1][1]))/100)
          else:
            qtytype='1'
            items=item[1][0]
            amt='0.0'
            tot_amt=str(float(item[1][1])/100)
            qty=0
            for entry in item[1][4]:
              qty+=entry[0]
        except TypeError:
          eType, eValue, eTraceback = sys.exc_info()
          print >> sys.stderr, time.strftime("%Y-%m-%d %H:%M:%S"), str(traceback.format_exception(eType,eValue,eTraceback))

可读性：

item_approved = (item['approved'] == '1' and item['active'] == '1')

if item_approved:
    try:
        db_item = item.get_db_record(item['id'])
    except DoesNotExist:
        db_item = item.create_db_record(**item)

    item.approve(db_item)
    db_item.save()

    publish_event(item.events.APPROVAL)

http://c0x.coding-guidelines.com/Introduction.pdf的第9节(pg 39)为C语言编码指南提供了一些背景知识。它是社会学和心理学研究的参考著作。它更多地解决了‘为什么代码应该是可读的’的问题，但它确实解决了可读性本身。我觉得它很有趣，虽然在一些地方有点“学术性”。

以前也曾回答过类似的问题。例如，请参见https://stackoverflow.com/questions/550861/improving-code-readability。

可读代码是将其意图清楚地传达给读者的代码。无法阅读的代码需要更长的时间才能理解并增加缺陷的可能性。

一些提高可读性的东西：

1. 使用空格分隔不同的代码区域。例如，缩进代码块，如"if“语句。在方法/函数中的方法/函数或相关代码行之间留空行。这使得大脑能够在字符被读取之前就将代码隔离开来。
2. 使用有意义的变量和方法/函数/类名。如果可能的话，遵循该语言的标准实践，并使用问题领域的术语。某物的含义和用途应从其名称中明显看出。名称也应该是一致的(GetX()、GetY()和GetZ()，而不是get_X()、LoadYFromDatabase()和getVar(Fields.Z))；
3. 有效的评论。避免明显的注释(“GetX()方法返回当前值x")。注释应该说明代码打算做什么，它如何与代码的其他部分和任何假设(“参数"a”不能为空，代码抛出异常，如果为空“)。
4. 遵循语言、库或问题空间的既定设计模式。例如，避免重复代码(称为DRY或不要重复自己)。当读者试图寻找差异或找到要修复的正确代码时，这会浪费时间。
5. 保持简单(接吻原则)。例如，避免过早或不必要的优化。优化有其位置，但代码通常可以在不影响可读性的情况下进行优化。

可以说，唯一最重要的方面是一致性。如果读者知道预期的内容和查看的位置，代码就更容易理解了。例如，如果项目使用了相互冲突的变量命名和注释样式，那么读者就不得不浪费精力学习新的样式和上下文切换。

代码的作者可能是可读性的糟糕判断者，因为他们可能被投入到代码中，或者在问题中太深，以至于不能后退一步，从别人的角度来看待它。代码评审在这里有帮助。

请记住，并不是所有的代码都是可读的。当开发人员使用不熟悉的库时，他们常常不得不匆忙编写代码。可读性差应视为技术债务和重构。