Closed n10v closed 7 years ago
No thank you, I'm find with all the logic being in one file. Once we move to two files, the temptation will be to parcel every function into their own file and I do not want that.
We can revisit this issue once/if main.go passes say 2000 lines.
It's very inconvenient to hold all logic in one file. Contributors have to solve merge conflicts after merged PRs and it's really annoying. If there would several files, the count of conflicts will be reduced.
In general I agree with you, but in this case this is a small project that will be pretty much done by next week.
I'm sorry for the merge conflicts, I don't believe they will be sufficiently alleviated by splitting the project across many files to warrant the reduction in readability.
The cause of the merge conflicts occurs when changes to the main.main
method are made. I believe this can be solved by refactoring that code into multiple functions. It is not necessary to place those functions to gain the benefit of this.
Yes, the functions could stay in one file, but obviously types could be in separate files. E.g. type headers []string
and all methods of this type could be in file header.go
and it will be more convenient to navigate the code
As I said above, when main.go grows to 2,000 lines we can have this discussion. Until then I feel confident that the single file nature of this project has made it readable and approachable to contributors.
Ok
I think, one should move all
headers
type logic to separate file for convenience.