Naming variables

Even with the use of strict typing and inline type hints, there is still great value in consistent variable names. Not only does it make code easier to understand, but an easy-to-follow convention also helps me reserve my limited daily cognitive bandwidth for problems that matter. And let me tell you, spending a minute on coming up with the right name will never pay off.

Class instances

Naming an instance of a class is straightforward. Just change the case: field: Field. But what about long class names? Wouldn’t this introduce too much boilerplate? Like field_supporting_mathematical_operations for FieldSupportingMathematicalOperations. This seems excessive, right? Let’s just use field: FieldSupportingMathematicalOperations. But wait, what if in the same function we also have another type: FieldSupportingStringOperations? Then we cannot avoid using the full name, and don’t you dare try to half-ass it with field_math and field_string that will just introduce even more confusion over time. The other possible option you have is splitting the current function into two, each containing only one of the field types, where you can safely use field as a name. Reusing the same field name in the same function is to be avoided as it will lead to issues and more difficult debugging.

Class attributes

When you have an instance and you want to reuse some already calculated attribute of it, it’s just not worth it to store it as a variable. Instead of field_name just use field.name. For chained attributes, the convention should be variable_attribute_1...attribute_n so field_parent_name = field.parent.name.

Iterables

Just put an s at the end. I do not care that data is an uncountable word. You are not writing an essay for your Literary Studies PhD. You are adding an option to allow scheduled pizza deliveries, so we will name it order_datas: list[OrderData]. Some might say that at least order_data_items is better, congrats, you just reinvented Hungarian_notation.

Dict/Map

I’ve been a long fan of value_by_key, but I came to accept that key_to_value is much easier to pick up by others, so this is my recommendation: id_to_age: dict[str, int].

Function results

Nothing surprising here, just remove the verb from the function name: current_time = calculate_current_time().

Booleans

There is no single way to do this, you have to choose from these 4 prefixes: is_, has_, is_not_, has_no_, for example: is_valid, has_no_children.

Lengths

There are many ways to do this word_length, parent_count, ‘nr_of_parents’ but the clear winner is n_variable so n_texts = len(texts) and n_text = len(text)

Temporary variables

i is fine for the iteration index, but I do not want to see any j or k, use schema_i, and field_i instead, or even better write your code in a functional style, and you will have less temporary variables.

Closing thoughts

Consistent naming that needs no thinking saves time and makes collaboration easier. These rules are not set in stone, my opinion will change over time. But I want to urge you set a common guideline with your team on variable naming, it will pay off.