On Thursday, April 11, 2019 at 6:20:33 AM UTC-4, Dumitru Ungureanu wrote: > > It helps a lot! Thanks. > > I now have two things to moan about. > > If I was to pass c around, I would added it to the params list. If I had > more others, I'd built a struct. But now, if somehow I lose track of who's > passing what and where, hard times debugging ahead. Having them declared at > package level, it seems to cut short the list of things to add, do and > track. > Grouping parameters in a struct (or any kind of aggregate data structure) should actually make it easier to reason about them, e.g. you are now reasoning about "configuration" instead of individual configuration options, making "zoom-in" distinctions only where necessary at the point of use.
Passing data around, whether as function arguments or closed-over variables, increases data locality, reducing the mental scope that you need to keep active when working on a given piece of code. Having everything you care about right in front of your eyes makes it easier to keep track of what's what, compared to having to remember where and why was that identifier defined. Of course, that is assuming functions are kept reasonably short. > > > If I was to use a init func to initialize w and c, how do I pass them to > main? Or any initialization, really? > > > I have yet to see a good reason to use init funcs in a main package. Not saying there can never be, just that I haven't encountered any situation where the contents of init could not be just added to the beginning of the main func, without any change in behaviour. At least in your example, you could do just that and not need to pass anything into main. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
