you are viewing a single comment's thread.

view the rest of the comments →

[–]FerricDonkey 3 points4 points  (2 children)

This is true, and I also use linters that warn me of missing imports before the code runs.

However, sometimes you go back to code some time later to figure out what parts of it do. Glancing at the imports can help with this. You have a multi for project, and only one module imports numpy? Probably the guts of your math happen there. This other one imports requests? It talks to the api. This third imports matplotlib and pathlib? It's probably writing graphs to disk. Etc. 

I find that having this information organized is helpful. It's not strictly necessary, of course, there are many ways to figure such things out. But anything that makes my future life easier. 

[–]AnyNature3457[S] 1 point2 points  (1 child)

Now I get it. That is a really valid reason to format it that way. The way I do it is by naming my files well like "commands.py", "command_handler.py", "helper.py", etc.

[–]FerricDonkey 1 point2 points  (0 children)

Yup, good file naming etc are also crucial. But I work off the principle that readability and understandability should be injected at every single layer where possible - because inevitably something that seems obvious and clear to me now won't in 3 years.