is it ok to use capital letters for types, funcs, consts etc. in package main?

<p>is there any concern with the capital-beginning names used in &#39;first class citizens&#39; in package main?</p> <p>i don&#39;t know whether the package main is importable from outside but vscode shows green underlines when i set capital-beginning names for types, funcs, consts, vars etc. in package main.</p> <p>is that safe to use uppercased names there?</p> <hr/>**评论：**<br/><br/>peterbourgon: <pre><p>It’s safe in that nothing will break, but it’s pointless, because nothing can import package main and make use of those exported identifiers; and nonidiomatic for that reason. Best not to do it.</p></pre>TheMerovius: <pre><p>Also, golint will complain, if they are not documented (AFAIK), even if they&#39;re not importable.</p></pre>shovelpost: <pre><p>So now the question is, which tool is Vscode using that generates the green underlines?</p></pre>jackmott2: <pre><p>golint</p></pre>vorg: <pre><p>You might want to extract most of what&#39;s in your <code>package main</code> into its own separate library package later on, leaving only <code>func main()</code> in there. Using uppercase while developing the code makes that easier. Alternatively, you could change the name of <code>package main</code> to something else, and change the main function to <code>func init()</code>.</p></pre>Rivermind: <pre><p>I believe that if you are creating a c-archive or c-shared library from a Go main package that all exported symbols must not just have the //export directive but also be exposed by Go&#39;s naming rules.</p></pre>JackOhBlades: <pre><p>In terms of communicating the relative importance of a function I think it can be quite useful. </p> <p>If I&#39;m reading some random Go project and I see a capitalized function in main, it tells me that is a key function to look at. Since the linter complains it&#39;s also more likely to be documented. </p> <p>Marginal gains nonetheless. </p></pre>dlsniper: <pre><p>There are cases where you want to export identifiers, like types, if you have a simple app that reads a json and does things to it. Also for methods on types in order to satisfy interfaces. Functions/vars/consts alone probably not necessary, unless you want to document them in godoc.</p></pre>peterbourgon: <pre><p>There is no need to export a type name to deserialize JSON into it; only the fields need to be exported. Similarly, an unexported type can satisfy any interface.</p></pre>