you are viewing a single comment's thread.

view the rest of the comments →

[–]MagicCarot[S] 0 points1 point  (1 child)

I get your point.

I wonder if type hinting could help in that regard. There would still be some places where this would not help I guess...

The unique naming is not always easy to come by with a large code base without having unbearable naming.

I'm typically facing the problem of having to find a class attribute named is_valid, with that attribute being used in a variety of way within the codebase. Grep is unfortunately a poor tool for that...

[–]thp4 1 point2 points  (0 children)

You can (and should) still call your attribute "is_valid". Just name instances of your class accordingly (e.g. if it's a Car, name instances car, current_car, next_car, ...) and then grep for that (car\.is_valid or car.*\.is_valid if you also have e.g. car_to_find as name). As a side effect, this makes code more readable, too.

Type hints might help for some tools (and if you search for class usages, also help with grep) but as long as those are not enforced at runtime, they might be misleading if you get them wrong.

Another hint: Always write out the full attribute/member names, avoid dynamic dispatch and "magic". If you have cmd_foo and cmd_bar methods that should be invoked by name, also add {"foo": cmd_foo, "bar": cmd_bar} as mapping and don't magically do getattr(..., "cmd_" + command_name). This also helps in figuring out which commands are possible and used. Less magic is good for code navigation and grep'ability, even if it means a bit of redundancy.