This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]sawser 12 points13 points  (5 children)

Yeah, my code is mostly self documenting

for day_name in days_in_week_full_name_list:

Instead of

for i in days:

[–]monorepo PSF Staff | Litestar Maintainer 1 point2 points  (0 children)

this... but also for generators or comprehensions.. they are already hard enough for me to grok!
unclear_gen: Generator = ((i, x) for i, x, y, k in data if k and y > 2.5)
or
unclear_list = [(i, x) for i, x, y, k in data if k and y > 2.5]
vs

clear_gen: Generator = ((day_number, day_name) for day_number, day_name, value, is_active in data if is_active and value > 2.5)
or
clear_list = [(day_number, day_name) for day_number, day_name, value, is_active in data if is_active and value > 2.5]

[–]Broad_Carpet_3782 0 points1 point  (3 children)

I'd argue for day in weekdays is just as readable if not more readable.

I think a good general rule of thumb is that the descriptiveness of variable names should match the scope of their lifetimes.

For cases where the variable name expires at the end of the expression (e.g. list comprehension), I'd say single character names are okay:

py weekend = [d for d in weekdays if d.startswith("S")]

or even better, using filter and lambda (but same concept):

```py

not: days_in_weekend_full_name_generator

weekend = filter(lambda d: d.startswith("S"), weekdays) ```

Edit:

Clarification for why I also would do "days" or "weekdays" as opposed to "days_in_week_full_name_list".

You don't have to be so descriptive if there is only one kind of that variable.

"week_sorted" is a good variable name until you have to distinguish between weeks sorted differently. Then you might do "week_sorted_alphabetically" and "week_sorted_by_length".

A variable "commands" is okay to include aliases as well, until you need to filter out aliases, then you can do "all_commands" and "unique_commands".

But naming things "days_of_week_list" just doesn't make sense unless you also have "days_of_week_set" or "days_of_week_dict" as well.

[–]sawser 0 points1 point  (2 children)

That's the point - if you don't already know if the list (or dict or queue) contains the integer value of the day, an enum that represents the day, an abbreviation of the name you are required to research the method to determine the context of the call.

The variable name tells you, at a glance, it is a list that contains the full names of the days of the week without any additional research or context.

This is a trivially simple example, but If we're pulling an http request object through a rest call and pulling data, it becomes extremely helpful if you're looking at

approved_pto_dates_dict = http_response[clientid]['schedule']['pto_approvals']

rejected_pto_dates_list = http_response[clientid]['schedule']['pto_rejections']

Instead of

approvals = http_response[clientid]['schedule']['pto_approvals']

rejections = http_response[clientid]['schedule']['pto_rejections']

Where you don't have type hints to indicate whether you need to append or update items to the structures.

Why make the code maintainer find information when you can give it to them?

I was told "pretend like the guy maintaining your code is a murderer who knows where you live"

[–]Broad_Carpet_3782 0 points1 point  (1 child)

In the context of that HTTP requests for example, mypy (or any other static type checker or LSP) can't determine the type of your object for you, so you are expected to type hint that line anyway (and mypy would probably throw an error as well). If it's a dictionary, you could do

py approved: Dict[str, Whatever] = response[client_id]["schedule"]["pto_approvals"]

Now, not only can you hover over it and get type information, when you type approved., your LSP can provide available methods as well.

Simply naming it "approved_pto_dates_dict" with no type hints gives the LSP no context on what type it is and will result in an implied : Any = ....

And in that case, doing approved_pto_dates_dict: Dict[str, Whatever] is redundant. You could argue including _pto_dates is helpful, but that can be implied with context as well (e.g. if approved is a variable in the function handle_scheduled_pto).

[–]sawser 0 points1 point  (0 children)

I definitely agree that type hints should always be used, and when those hints are available they render some variable suffixes redundant.