新手vs老手：Python 代码风格差距在哪

判断条件：elif还是多个if

处理多条件分支时，新手容易写出这样的代码：

status = "pending"
if status == "pending":
    print("等待处理")
if status == "approved":
    print("审核通过")
if status == "rejected":
    print("审核拒绝")
if status == "completed":
    print("已完成")

这段代码当然能跑，但问题也很明显：即便第一个条件已经匹配了，程序还是会傻乎乎地把后面所有的if都检查一遍。这纯粹是浪费计算资源。正确的姿势，应该是使用if-elif-else链：

status = "pending"
if status == "pending":
    print("等待处理")
elif status == "approved":
    print("审核通过")
elif status == "rejected":
    print("审核拒绝")
elif status == "completed":
    print("已完成")
else:
    print("未知状态")

一个elif，就清晰地告诉阅读者：这些条件是互斥的，匹配到一个就到此为止。代码的意图瞬间明朗，执行效率也上去了。

列表操作：循环还是推导式

比如，要筛选一个列表中所有偶数并乘以2：

numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
result = []
for n in numbers:
    if n % 2 == 0:
        result.append(n * 2)
print(result)  # [4, 8, 12, 16, 20]

功能没问题，但不够“Pythonic”。Pythonic的写法，往往只需要一行：

numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
result = [n * 2 for n in numbers if n % 2 == 0]
print(result)  # [4, 8, 12, 16, 20]

列表推导式堪称Python的标志性语法，不仅简洁优雅，执行速度通常也比显式循环快。一旦用惯了推导式，你大概就再也不想回头去写result = []然后循环append那种模板代码了。

字典也有类似的推导式，转换起来同样顺手：

users = [
    {"name": "张三", "age": 25},
    {"name": "李四", "age": 30},
    {"name": "王五", "age": 22}
]
name_to_age = {user["name"]: user["age"] for user in users}

交换变量：temp中间变量还是元组解包

交换两个变量的值，教科书式的做法是引入一个临时变量：

a = 10
b = 20
temp = a
a = b
b = temp
print(a, b)  # 20 10

但在Python里，有更优雅的方式——元组解包，一行搞定：

a = 10
b = 20
a, b = b, a
print(a, b)  # 20 10

元组解包的妙用远不止于此，在函数返回多个值、循环遍历键值对等场景下，它都能让代码更清晰：

def get_stats(numbers):
    return min(numbers), max(numbers), sum(numbers) / len(numbers)

low, high, a vg = get_stats([1, 5, 3, 9, 2])

pairs = [("a", 1), ("b", 2), ("c", 3)]
for key, value in pairs:
    print(f"{key}: {value}")

函数参数：位置参数还是命名参数

调用一个参数较多的函数时，如果全用位置参数，代码可读性会大打折扣：

def create_user(name, age, city, email, phone):
    return {"name": name, "age": age, "city": city, "email": email, "phone": phone}

user = create_user("张三", 25, "北京", "zhang@example.com", "13800138000")

你看，这一串字符串堆在一起，谁能一眼分清“北京”对应的是哪个参数？这时候，命名参数的优势就体现出来了，它让调用代码几乎可以自文档化：

user = create_user(
    name="张三",
    age=25,
    city="北京",
    email="zhang@example.com",
    phone="13800138000"
)

不仅每个参数的含义一目了然，顺序也变得灵活了——命名参数可以打乱顺序传递：

user = create_user(
    email="li@example.com",
    name="李四",
    phone="13900139000",
    age=30,
    city="上海"
)

异常处理：裸except还是精确捕获

新手在处理异常时，常常会图省事，用一个“裸”的except捕获所有错误：

try:
    result = risky_operation()
    print(result)
except:
    print("出错了")

这种做法隐患很大，因为它会连KeyboardInterrupt（用户按Ctrl+C）和SystemExit（程序退出）这类异常也一并吞掉，这不是好的工程实践。正确的做法是精确捕获你预期中可能发生的异常类型：

try:
    result = json.loads(user_input)
except ValueError as e:
    print(f"JSON格式错误: {e}")
except KeyError as e:
    print(f"缺少必要字段: {e}")
except Exception as e:
    print(f"未知错误: {e}")
    raise  # 重新抛出，让上层处理

同时，要避免在异常处理中默默地吞掉错误，至少应该记录日志，让问题有迹可循：

import logging
logger = logging.getLogger(__name__)

try:
    process_data()
except DataFormatError as e:
    logger.warning(f"数据格式错误，跳过处理: {e}")
except DatabaseError as e:
    logger.error(f"数据库错误，需要关注: {e}")
    raise  # 数据库问题通常不能忽略，重新抛出
except Exception as e:
    logger.exception("Unexpected error")  # 记录完整堆栈
    raise

字符串拼接：+号还是f-string

拼接字符串时，如果用传统的加号连接，代码会显得很凌乱：

name = "张三"
age = 28
city = "深圳"
message = "姓名: " + name + ", 年龄: " + str(age) + ", 城市: " + city

又是类型转换，又是引号嵌套，看着就头疼。好在Python 3.6引入了f-string，让字符串格式化变得无比优雅：

message = f"姓名: {name}, 年龄: {age}, 城市: {city}"

f-string的强大之处在于，它直接支持表达式和丰富的格式化选项：

price = 99.8
f"总价: {price * 1.13:.2f}元"  # 计算并保留两位小数
f"比例: {0.258:.1%}"           # 格式化为百分比
f"宽度: {42:05d}"              # 补零至5位宽度
f"大写: {name.upper()}"        # 直接调用方法

None检查：== None还是is None

检查一个变量是否为None，用==似乎很直观：

value = None
if value == None:
    print("值为空")

但这里有个坑：==操作符调用的是对象的__eq__方法，如果某个类重写了这个方法，可能会产生意想不到的结果。而is比较的是对象的身份（即内存地址），对于None这种单例对象来说，is判断更准确，也更符合Python社区的约定：

if value is None:
    print("值为空")
if result is not None:
    print(f"结果: {result}")

这不仅仅是个人偏好，更是PEP 8风格指南的明确规范，算是Python开发者的一项基本功。

写在最后

说到底，代码风格绝非吹毛求疵的表面功夫。它直接关系到代码的可读性、可维护性和团队协作的效率。上面这些例子，表面看是语法选择的不同，背后反映的其实是思维方式的差异——有经验的开发者会习惯用“Python的方式”去思考，而不是简单套用其他语言的习惯。Python哲学里有一句“Simple is better than complex”（简单优于复杂），这些风格上的最佳实践，正是这句哲学在具体编码中的鲜活体现。