thanks for the advice
for those bottom lovers like me, I have a PR out on ZLS to support bottom imports with the “organize imports” action. it works pretty well, but is not quite perfect. I was having difficulty with keeping whitespace under control, since it is kind of modifying itself in place in certain cases.
I think fixing that will take more time than I have for this at the moment. I’m not sure if ZLS maintainers will accept my PR as is, but if there’s a bottom enthusiast out there who could help me take this action over the finish line, I’d surely appreciate it!
4 Likes
I am a little skeptical about the requirement of “reading the core part of the code immediately when opening a file” because I rarely read the code from top to bottom by opening a file. When I need to read the code, I usually jump directly through the IDE to read the part I am interested in, most of the time it is in the middle of the code, because of this I even often use the style of temporarily importing modules in the middle of the file when using it, I think it is more readable to put the import near the part related to it. If you want to read the code from top to bottom, I feel that it is not feasible to get the key part in most cases. Common engineering codes, even if there is no import related information, are full of lengthy copyright information at the beginning. Since the beginning is destined to be lengthy, why bother to deliberately avoid adding some lengthy import information?
1 Like
Imports don’t need to follow the pattern of:
const some_module = @import("some_module");
You can also have something like:
const q = @import("some_module");
Maybe it’s not commonly seen, but depending on how the module is used, it can make sense to assign a different (usually shorter, maybe even in some cases longer) alias to it.
Afterall, both cases above are aliases (for @import("some_module")).
I feel like aliases should generally be defined before they are used.
3 Likes
IMHO reading the code top-to-bottom is still important (to me at least), but I often prefer a bottom-up approach to reading code instead of top-down (e.g. first read and understand the basic building blocks before moving on to how those building blocks are combined).
And I definitely want to immediately see what other modules the current module depends on, that’s why the idea of ‘imports at the bottom’ baffles me a bit tbh.
5 Likes
Well, I always put my imports first, even after noticing the changes in compiler source. I don’t think the cost of scrolling a bit is that high. Further more, when working with in a file/project with files/imports/declarations whose names are similar to known ones like “debug” “meta” “math”, it useful to note that at the start.
Nearly all other languages do that, not just C, even those who have order independent declarations.
It would do more harm than good to make it a requirement or even an official “convention”. I consider this a matter of taste just like having constants upper-cased or not.
Concerning the analogy with papers, imports/declarations are much more important for the understanding/semantic/execution of the code than are “appendix” for papers. Appendix are the side notes, for reference; declarations are the statements, (part of) the actual meat of the paper.
Personally, to solve this kind of issue, I would rather resolve to add code folding capabilities to editors. It make no sense to read the imports only after reading (top->down) through hundreds (perhaps thousands) lines of code. And If I was handed a piece of unknown code on a paper, I would prefer the imports at the top, even if that means turning a page or two.
4 Likes