The examples numbered 2 and 3 under the section "Ruff Formatting" are identical. It is unclear which one is good and which one is bad practice for clear 2) "Error Handling" and 3) "Function Calls with Named Parameters". The affected examples are listed below:
# Example 2: Error Handling
# Bad - Exception types are hard to read and modify
try:
process_data()
except (
ValueError,
TypeError,
KeyError,
DatabaseError,
NetworkTimeout,
ValidationError,
) as e:
log_error(e)
# Good - Each exception is clear and git diffs will show exactly what changed
try:
process_data()
except (
ValueError,
TypeError,
KeyError,
DatabaseError,
NetworkTimeout,
ValidationError,
) as e:
log_error(e)
# Example 3: Function Calls with Named Parameters
# Bad - Parameter names and values are hard to scan
create_user(
username="johndoe",
email="john@example.com",
role="admin",
department="engineering",
active=True,
send_welcome_email=True,
)
# Good - Each parameter is clearly visible and self-documenting
create_user(
username="johndoe",
email="john@example.com",
role="admin",
department="engineering",
active=True,
send_welcome_email=True,
)
The examples numbered 2 and 3 under the section "Ruff Formatting" are identical. It is unclear which one is good and which one is bad practice for clear 2) "Error Handling" and 3) "Function Calls with Named Parameters". The affected examples are listed below: