4 ms·
I recently started learning go and I've been struggling with the lack of modularity across smaller codebases like this. For all of the great tooling around form
by save_ferris 7y ago
I recently started learning go and I've been struggling with the lack of modularity across smaller codebases like this. For all of the great tooling around formatting go, I'm kinda surprised by some of the code organization decisions I see.
- jerf 7y agoThere's some differences in style. I take a very aggressive stance on separating my modules; my thought is that it's relatively easy to understand what any given module is doing if it is small and focused and clearly pulls in its dependencies. But it's a non-trivial challenge to keep it all so nicely isolated and avoid loops. Worth it, I think, or I wouldn't do it, but non-trivial. There are also a lot of people who pretty much just punt and put everything in one module, so they don't have to deal with circular issues. I'm not sure I see a clear community consensus.
- w0uld 7y agoI found the advice in Brian Ketelsen's 2018 GopherCon talk[1] helped my Go code organization. It helped me reason about the optimal way to abstract my code. [1] https://www.youtube.com/watch?v=MzTcsI6tn-0 https://www.youtube.com/watch?v=MzTcsI6tn-0