Replies: 2 comments 1 reply
-
I've voted to split only because my coding style is to have many files. Granted this means a bit of mucking about finding things and absorbs time moving things around, renaming etc. But it also means that when editing it's easier to have lots of files open without scrolling about and it's also cleaner contextually in that when you look at a file it (generally) only contains stuff relevant to it's name. You could also consider a hybrid approach where you break the code up, but only down to contextually related things. So container related stuff in one file, registration stuff in another, etc. One thing that might also occur as a result of splitting is that you find yourself having to code some things just because things are split. For example after splitting you might find that some functions feel like they should be in seperate files because of what they do so you pull them out into various extensions. It doesn't hurt the code or functionality and would probably help with clarity, but it will create more boilerplate and thus probably increase the LOC count. In the end you are the author and it comes down to what you feel the most comfortable with. Everyone else (including me :-) can go jump. |
Beta Was this translation helpful? Give feedback.
-
Split into a more traditional structure. |
Beta Was this translation helpful? Give feedback.
-
Since inception Factory, like Resolver, was implemented as one single code file. This made it somewhat easier to work with and, as mentioned in the installation notes, also made it easy to drag the one file over and add it to a project.
Factory currently floats around 500 lines of code, but actually the file is about 1,400 or so lines with all of the DocC comments and whitespace.
Which leads me to the question:
6 votes ·
Beta Was this translation helpful? Give feedback.
All reactions