Is it necessary to start function names within main package with capitalized letter?

[Alvin Cao]

Hello everyone.

My program has just one package, i.e., main package. But the functions still might be different. Some are supposed to be interfaces while others are just ‘internal’. In this case, should I start these interfaces with capitalized letters just for clearness? Thank you.

[Axel Wagner]

Personally, I tend to do it. Note that it doesn't actually make a difference from a technical perspective - main can't be imported, so it makes no real sense to export any identifiers. As such, the boundaries of what I "export" are somewhat more fluent than usual. But yeah, as you said, for clarity, I tend to emphasize the most important functions this way. Also, I usually *intend* to factor more stuff out of the main package over time, as it makes sense (so I start with main and then split it up further and further) and the same functions then end up being the natural API points to make that split and it's nice to ear-mark them ahead of time.

At the end of the day, it's just preference and so there's even less of a "right" or "wrong" answer than usual. Just do it like you prefer, as long as your team is fine with it :)

On Wed, Jun 24, 2020 at 6:05 PM Alvin Cao <alvi...@gmail.com> wrote:

Hello everyone.

My program has just one package, i.e., main package. But the functions still might be different. Some are supposed to be interfaces while others are just ‘internal’. In this case, should I start these interfaces with capitalized letters just for clearness? Thank you.

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/abc571c5-0319-4c49-af1a-6a9bd5c91838o%40googlegroups.com.

[Ronny Bangsund]

I tend to do it too, because at some point I often find that I might as well create packages (internal or not) from some of the functionality. For example, my latest little tool wraps some AWS functionality with pretty-printing and progress bars, and I suspect I may find use for those in other programs later. I write comments and exportable funcs no matter what.

And like Axel Wagner implied, team consistency is important too. If there isn't a linter which could help enforce a policy, that's an idea for a tool I'd use…

[K Richard Pixley]

I generally do the reverse.

Everything is internal, lower case, until and unless I need it
elsewhere.  Then I reevaluate where the boundaries should be at that time.

I often find that as an exported API, I need/want different things out
of it than I did when it was internal.

[Jake Montgomery]

On Wednesday, June 24, 2020 at 12:46:42 PM UTC-4, Axel Wagner wrote:

Personally, I tend to do it. Note that it doesn't actually make a difference from a technical perspective - main can't be imported, so it makes no real sense to export any identifiers.

 

There is a case where main can be imported. You can import main from a test in the same directory, but with a different package name. AFAICT, this allows 'external' testing of executable code. In that case what identifiers are exported does matter. But since most of us will probably never use this feature, it probably does not matter much in practice.