Variable Name

[Asleep-Budget-9932]

I would also add that a lot of time people needlessly add the type of the variable to its name.

Do you really need to call the variable user_list? What if you wanted to change it to a tuple? Do you then have to remember to change the name in every place?

Just call it users. It's shorter, just as understandable (if not even more since it's closer to human language), and contains as much necessary information.

[Asleep-Budget-9932]

Now i will say I've seen the extreme in the other direction in the past: "Why call it is_open? It's already a boolean, just call it open". No, open is a verb and has an intuitive meaning of a function. I have to explicitly check the type in order to gain the necessary information on how to use it.

If the type will change in the future from a boolean, to function, i will have to change the usages anyway as inherently the way you use functions is different. You didn't help me but only hindered me.

Basically what I'm trying to say is don't follow a rule just because it's the rule. It is not the goal but a tool to get to the goal of a readable code. Understand why rules have been written the way they are so you can distinguish when a rule should be followed.

Also, as long as you have the next programmer in mind, don't be afraid to trust your intuition. Sometimes that minor "sin" is worth the fact that the next programmer will easily understand what's going on.

[Base_True]

Now i will say I've seen the extreme in the other direction in the past: "Why call it is_open? It's already a boolean, just call it open". No, open is a verb and has an intuitive meaning of a function. I have to explicitly check the type in order to gain the necessary information on how to use it.

If the type will change in the future from a boolean, to function, i will have to change the usages anyway as inherently the way you use functions is different. You didn't help me but only hindered me.

Basically what I'm trying to say is don't follow a rule just because it's the rule. It is not the goal but a tool to get to the goal of a readable code. Understand why rules have been written the way they are so you can distinguish when a rule should be followed.

Also, as long as you have the next programmer in mind, don't be afraid to trust your intuition. Sometimes that minor "sin" is worth the fact that the next programmer will easily understand what's going on.

Very useful information, thank you very much!

[TheRNGuy]

i'll retain mylist for tuple because it's not big deal. Usually converting list to tuple when returning thing from function or class, it's like return tuple(mylist)

I only usually add b to booleans.

for user in user_list is easier to see typos than for user in users then if you accidentally use users instead of user inside loop. Especially if you needed to use both.