I still can't get over the imperative of naming the receiver by the first letter of its name. First of all, it's much cleaner when you see a consistent name for a receiver and don't have to think about what that `t` stands for. Second, what happens if I want to rename my struct? Do I have to go over the whole file and change those letters? Why do I have to do that useless work and why do I have to put my code reviewers through the task of looking through the modified lines that didn't have to change anyway? What if there's already another var `t` in that function, especially considering that 1 letter names are considered good practice in Go? It makes me so irritated that I write youtube comments about it.
Your comment about where interfaces needs clarification because I think what u r claiming only applies to a specific use case. If a component requires a callback then the interface has to be defined with the component. However, if the interface is for facade purposes then it can be left to the client to define
Great talk, thank you! A code example would really facilitate understanding in my opinion. Majority of enterprise Go projects I've worked with look like this: ./internal ./internal/api ./internal/models ./internal/services (the actual application logic) ./internal/db Would this storytelling approach encourage the developer to put HTTP handlers, specific database queries and domain logic in one package?
I still can't get over the imperative of naming the receiver by the first letter of its name. First of all, it's much cleaner when you see a consistent name for a receiver and don't have to think about what that `t` stands for. Second, what happens if I want to rename my struct? Do I have to go over the whole file and change those letters? Why do I have to do that useless work and why do I have to put my code reviewers through the task of looking through the modified lines that didn't have to change anyway? What if there's already another var `t` in that function, especially considering that 1 letter names are considered good practice in Go?
It makes me so irritated that I write youtube comments about it.
Your comment about where interfaces needs clarification because I think what u r claiming only applies to a specific use case. If a component requires a callback then the interface has to be defined with the component. However, if the interface is for facade purposes then it can be left to the client to define
Great talk, thank you! A code example would really facilitate understanding in my opinion.
Majority of enterprise Go projects I've worked with look like this:
./internal
./internal/api
./internal/models
./internal/services (the actual application logic)
./internal/db
Would this storytelling approach encourage the developer to put HTTP handlers, specific database queries and domain logic in one package?