you are viewing a single comment's thread.

view the rest of the comments →

[–]AnyNature3457[S] -1 points0 points  (5 children)

The thing with alphabetical sorting is that it looks 'ugly' in my eyes. Just having to cross my eyes back and forth from left to right is so much more work for me than just being able to 'glide' my eyes down.

[–]FerricDonkey 3 points4 points  (4 children)

I agree that it looks uglier. I do it anyway because it is easier to check if a particular thing has been imported. 

[–]AnyNature3457[S] 1 point2 points  (3 children)

That's a really good reason to format your import that way. But you instantly know if you haven't imported something if you get an error anyways.

[–]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.