Re:Outsmarting Go Dependencies in Testing Code
by radub on Friday June 17, 2016 @08:09AM
(#11922124)
Thank you!
Making everything public runs the risk of other modules using internal implementation details, and that entanglement makes changing things a lot harder.
For a small project where you can easily control this, it's likely not an issue. But we are big enough that no one person knows all the code changes that are going on in all modules.
Exported vs non exported also serves as implicit documentation, it makes understanding things easier when you can tell right away what is internal and what is not.
That said, to play devil's argument, why not just make all implementation details public? I will say I remember being pissed off by Go packages that don't publicize all of their types and interfaces, which made writing tests against their behavior (usually requiring mocking, hence the need for the publicized types/interfaces) to be painful/impossible.