You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Packages that build up a large list of files can become rather cumbersome to work with. For example an entity package for a game server could start to become frustrating to navigate after enough entities are created e.g.:
Since the files under the __packet folder are still part of the entity package they are able to use the data structures and functions stored in the parent folder and the parent folder files are able to call the functions in the __packet folder without causing cyclical dependency issues.
The text was updated successfully, but these errors were encountered:
The difficulty of navigating a package with many source files has come up before.
In #27876@yjiangnan reported:
when reading Go code of others [esp. on Github], names undeclared in the current file often come up ... Those names ... declared in another file in the package, would be much more easily understood [if their origin were available].
In that issue, I suggested letting go/doc output a "package internals manifest" -- essentially a human-readable index of identifiers from the package, with source file and line number for each.
Perhaps I should file a separate proposal along those lines?
Isn't this solved with an IDE and using the corresponding jump-to-function or jump-to-struct feature ? With just a couple of keystrokes, I can go to any func/method/struct I want without looking for anything else.
I think is up to the user to decide when to split code into separate files or include them in a single one. And it is the IDE's job to help the user in finding the appropriate code.
@agnivade this would create a somewhat unreasonable overhead on github projects, as you would have to clone every repo you wanted to inspect.
Being able to group files in a package using a folder (beginning with __) would provide a non intrusive way of organising files allowing anyone irrespective of their development/viewing environment to navigate larger packages more easily.
@networkimprov that sounds like an interesting idea. However, I don't think it quite solves the issue of navigating large packages (especially on github) in an intuitive manner.
@ianthehat whilst I disagree somewhat to just using filenames I do agree that the effort to add this in to the current tooling is probably not worth the benefit it might provide as it would only be used sparingly I imagine.