遵守这些规定,否则将被解雇。
大型语言模型的时代大型语言模型(LLMs)已不再只是科幻小说。deasadiqbal.medium.com随着无数的Python最佳实践在网上流传,每个人问到的观点可能会有所不同。互联网已经使专业知识民主化,任何人都可以分享他们的观点,包括我自己。然而,在这篇文章中,我们将重点介绍10个经久不衰的Python最佳实践,这些实践已经得到了广泛的认可,并被视为基础性的。
提示 1:函数应指定参数和返回类型
在定义函数时,你应该始终指定参数的类型以及函数返回的结果的数据类型。这将帮助你和团队中的开发人员了解可以期待什么,而无需总是使用 print 语句来获得直观的理解。
好:
def greet(name: str) -> None:
"""通过名字向用户问好."""
print(f"Hello, {name}!")
def calculate_area(length: int, width: int) -> int:
"""计算矩形的面积."""
area = length * width
return area
坏:
def do_something():
print("这个函数做了一些事情,但不清楚具体是什么!")
# 调用函数
do_something("这是一个错误!") # 这可能会导致错误
提示 2:函数应该处于相同的抽象层次
当我们谈到函数处于同一抽象层次时,我们指的是一个函数应该执行一个单一且明确的任务。这个任务在整个函数中应该保持一致的抽象层次。换句话说,函数应该专注于特定的细节或复杂度水平,并且函数的所有操作都应该在同一层次上进行。
好:
def calculate_average(numbers):
total = sum(numbers)
count = len(numbers)
average = total / count
return average
坏:
def 获取数字():
数字 = [2,3,4,1,4,1,416,6]
return 数字
def 计算平均值():
数字 = 获取数字()
数字加30 = [num + 30 for num in 数字]
总和 = sum(数字加30)
数量 = len(数字)
平均值 = 总和 / 数量
return 平均值
计算平均值()
提示 3:函数应该小巧
一个函数应该是可重复使用的。而函数越大,它被重复使用的可能性就越小。这也解释了为什么一个函数应该只做一件事情。如果它只做一件事情,那么它很可能会很小。
提示 4:开闭原则开放封闭原则(OCP)指出,一个类、方法或函数必须对扩展开放,但对修改封闭。这意味着任何定义的类、方法或函数都可以在不更改其代码的情况下轻松重用或扩展以适应多个实例。
让我们举个例子,假设我们有一个叫做 address 的类。
class Address:
def __init__(self, country):
self.country = country
def get_capital(self):
if self.country == 'canada':
return "ottawa"
if self.country == 'america':
return "Washington D.C"
if self.country == 'united Kingdom':
return "London"
address = Address('united Kingdom')
print(address.get_capital())
这违背了OCP原则,因为每当有新的国家时,我们都需要添加一个新的if
语句来处理它。这在目前看来可能很简单,但想象一下如果有100个或更多的国家需要考虑,那会是什么样子?
这就是 OCP 发挥作用的地方。
capitals = {
'canada': "Ottawa",
'america': "Washington D.C",
'united Kingdom': "London"
}
class Address:
def __init__(self, country):
self.country = country
def get_capital(self):
return capitals.get(self.country, "Capital not found")
address = Address('united Kingdom')
print(address.get_capital())
提示 5:尽量避免添加注释
评论有时会显得真实却误导。它们会引导读者的思维偏离代码实际在做什么,转而关注别人所说的代码在做什么。
这在时间的推移和代码接收更新或更改时会变得非常有问题。最终,注释变得不再准确,所有人都必须通过这个“谎言”的视角来理解真相。
必须不惜一切代价避免注释。注释迫使读者继承你的思维方式,而这最好的情况也是过去的想法。当一个函数或类发生变化时,通常它的注释并不会随之改变。更可能的是,它们阻碍了读者向前思考。
一个注释表明作者在精神上无法提供一个描述性良好的类、函数或变量名。这暴露了程序员敷衍的态度,并迫使团队继承这种态度。
提示 6:避免魔法数字魔术数字是指那些可能在后期发生变化但又难以更新的硬编码值。
例如,假设你有一个页面,显示“您的订单”概览页面中的最后50个订单。这里的50就是所谓的“魔术数字”,因为它不是通过标准或约定设置的,而是根据规格中所述的原因你自己设定的一个数字。
现在,你在不同的地方都有这个数字50——你的SQL脚本(SELECT TOP 50 * FROM orders
),你的网站(您的最近50笔订单),你的订单登录(for (i = 0; i < 50; i++)
),以及可能还有其他许多地方。
好:
NUM_OF_ORDERS = 50
SELECT TOP NUM_OF_ORDERS * FROM orders
坏:
SELECT TOP 50 * FROM orders
提示 7:避免深层嵌套
限制循环、条件语句或函数内的嵌套层次,以提高可读性。
好:
如果 x 和 y 都为真:
执行某操作()
坏:
如果 x:
如果 y:
do_something()
提示 8:避免硬编码路径
避免硬编码文件路径或URL;改为使用配置文件或环境变量。
好:
import os
file_path = os.getenv("FILE_PATH")
坏:
file_path = "/path/to/file.txt"
提示 9:类应该小巧
嗯!类应该尽可能小。就像函数一样。
唯一的区别在于,在函数中,大小是由该函数的行数决定的,而在类中,大小是由该类的责任数量决定的。
通常,类名代表了它可能拥有的职责,但当这个名字模糊或太泛泛时,很可能是我们赋予了它过多的职责。
这让我们回到了单一职责原则(SRP),它指出一个类应该只有一个变更的理由——一个职责。
小贴士 10:避免复杂的三元表达式避免使用过于复杂的三元表达式;优先考虑可读性而非简洁性,以使代码更易理解。
好:
如果 number % 2 == 0:
result = "even"
elif number % 3 == 0:
result = "odd"
else:
result = "neither"
坏:
result = "even" if number % 2 == 0 else "odd" if number % 3 == 0 else "neither"
感谢阅读✨
共同学习,写下你的评论
评论加载中...
作者其他优质文章