-
Notifications
You must be signed in to change notification settings - Fork 153
There's no real reason for this to be in a single file #278
Comments
This is not so true in you go to the documentation it says every method's source code line in the file also being single file is easier for people new to discord io/node to understand it :P |
Having documentation that shows where everything is located is helpful and does take you to where you need to go, but it requires you have an external resource rather than being able to explore the code itself. Code spread across multiple files is easier to have in side-by-side views, reduces the difficulty in exploring changes to a particular function/set of functions using version history, and naturally lends itself to how we expect to write code. I'd counter the point that it's easier for new people to understand it because if you need to cross-reference code or functions (as I've needed to do before), you have to leave where you're currently looking and scroll elsewhere, and then hope to find your way back to where you first were. It's possible to write complete, release-grade software and applications in a single file, but as an industry that isn't done anymore, and OP is just saying that now that the library has taken off and grown in size, the benefits of having the code spread across multiple files seemingly outweighs keeping it in a single file. |
Totally agree with @ahlec. If the components were fragmented into different source files, you would have to stop bragging that it's one file - not that that's a thing to brag about anyway, considering the size of the file has 3000 lines worth of code. If you were to apply this, you should remove the useless IIFEs. I could submit a PR with this change applied if this issue goes ahead. /cc @izy521 |
How is it easier to understand? I always go to the |
The intent of this project IS to have it be one file, if you don't like that it is one file feel free to use a less barebones library such as d.js or eris. This project's original intent was to be an incredibly barebones library with a specific set of deployment targets (fairly sure it was meant to be able to use in the browser, but unfortunately is not really plausible because of user-agent requirements for proper library support) |
psst This could easily be achieved by fragmenting the source files, then adding a |
3000 lines is far too long to be maintainable and since most people will use npm, it doesn't matter at all.
You could use a build process if you really wanted.
The text was updated successfully, but these errors were encountered: