This commit is contained in:
github-actions[bot] 2023-06-27 14:44:51 +00:00
parent 32bab894bd
commit 619d6d3117
4 changed files with 4 additions and 4 deletions

View File

@ -197,7 +197,7 @@ Hello, 世界
<p><code>import</code> 声明必须跟在文件的 <code>package</code> 声明之后。随后,则是组成程序的函数、变量、常量、类型的声明语句(分别由关键字 <code>func</code><code>var</code><code>const</code><code>type</code> 定义)。这些内容的声明顺序并不重要(译注:最好还是定一下规范)。这个例子的程序已经尽可能短了,只声明了一个函数,其中只调用了一个其他函数。为了节省篇幅,有些时候示例程序会省略 <code>package</code><code>import</code> 声明,但是,这些声明在源代码里有,并且必须得有才能编译。</p>
<p>一个函数的声明由 <code>func</code> 关键字、函数名、参数列表、返回值列表(这个例子里的 <code>main</code> 函数参数列表和返回值都是空的)以及包含在大括号里的函数体组成。第五章进一步考察函数。</p>
<p>Go 语言不需要在语句或者声明的末尾添加分号,除非一行上有多条语句。实际上,编译器会主动把特定符号后的换行符转换为分号,因此换行符添加的位置会影响 Go 代码的正确解析(译注:比如行末是标识符、整数、浮点数、虚数、字符或字符串文字、关键字 <code>break</code><code>continue</code><code>fallthrough</code><code>return</code> 中的一个、运算符和分隔符 <code>++</code><code>--</code><code>)</code><code>]</code><code>}</code> 中的一个)。举个例子,函数的左括号 <code>{</code> 必须和 <code>func</code> 函数声明在同一行上,且位于末尾,不能独占一行,而在表达式 <code>x+y</code> 中,可在 <code>+</code> 后换行,不能在 <code>+</code> 前换行(译注:以+结尾的话不会被插入分号分隔符,但是以 x 结尾的话则会被分号分隔符,从而导致编译错误)。</p>
<p>Go 语言在代码格式上采取了很强硬的态度。<code>gofmt</code>工具把代码格式化为标准格式译注这个格式化工具没有任何可以调整代码格式的参数Go 语言就是这么任性),并且 <code>go</code> 工具中的 <code>fmt</code> 子命令会对指定包,否则默认为当前目录中所有go 源文件应用 <code>gofmt</code> 命令。本书中的所有代码都被 gofmt 过。你也应该养成格式化自己的代码的习惯。以法令方式规定标准的代码格式可以避免无尽的无意义的琐碎争执(译注:也导致了 Go 语言的 TIOBE 排名较低,因为缺少撕逼的话题)。更重要的是,这样可以做多种自动源码转换,如果放任 Go 语言代码格式,这些转换就不大可能了。</p>
<p>Go 语言在代码格式上采取了很强硬的态度。<code>gofmt</code>工具把代码格式化为标准格式译注这个格式化工具没有任何可以调整代码格式的参数Go 语言就是这么任性),并且 <code>go</code> 工具中的 <code>fmt</code> 子命令会对指定包否则默认为当前目录中所有go 源文件应用 <code>gofmt</code> 命令。本书中的所有代码都被 gofmt 过。你也应该养成格式化自己的代码的习惯。以法令方式规定标准的代码格式可以避免无尽的无意义的琐碎争执(译注:也导致了 Go 语言的 TIOBE 排名较低,因为缺少撕逼的话题)。更重要的是,这样可以做多种自动源码转换,如果放任 Go 语言代码格式,这些转换就不大可能了。</p>
<p>很多文本编辑器都可以配置为保存文件时自动执行 <code>gofmt</code>,这样你的源代码总会被恰当地格式化。还有个相关的工具:<code>goimports</code>,可以根据代码需要,自动地添加或删除 <code>import</code> 声明。这个工具并没有包含在标准的分发包中,可以用下面的命令安装:</p>
<pre><code class="language-shell">$ go get golang.org/x/tools/cmd/goimports
</code></pre>

View File

@ -286,7 +286,7 @@ Hello, 世界
<p><code>import</code> 声明必须跟在文件的 <code>package</code> 声明之后。随后,则是组成程序的函数、变量、常量、类型的声明语句(分别由关键字 <code>func</code><code>var</code><code>const</code><code>type</code> 定义)。这些内容的声明顺序并不重要(译注:最好还是定一下规范)。这个例子的程序已经尽可能短了,只声明了一个函数,其中只调用了一个其他函数。为了节省篇幅,有些时候示例程序会省略 <code>package</code><code>import</code> 声明,但是,这些声明在源代码里有,并且必须得有才能编译。</p>
<p>一个函数的声明由 <code>func</code> 关键字、函数名、参数列表、返回值列表(这个例子里的 <code>main</code> 函数参数列表和返回值都是空的)以及包含在大括号里的函数体组成。第五章进一步考察函数。</p>
<p>Go 语言不需要在语句或者声明的末尾添加分号,除非一行上有多条语句。实际上,编译器会主动把特定符号后的换行符转换为分号,因此换行符添加的位置会影响 Go 代码的正确解析(译注:比如行末是标识符、整数、浮点数、虚数、字符或字符串文字、关键字 <code>break</code><code>continue</code><code>fallthrough</code><code>return</code> 中的一个、运算符和分隔符 <code>++</code><code>--</code><code>)</code><code>]</code><code>}</code> 中的一个)。举个例子,函数的左括号 <code>{</code> 必须和 <code>func</code> 函数声明在同一行上,且位于末尾,不能独占一行,而在表达式 <code>x+y</code> 中,可在 <code>+</code> 后换行,不能在 <code>+</code> 前换行(译注:以+结尾的话不会被插入分号分隔符,但是以 x 结尾的话则会被分号分隔符,从而导致编译错误)。</p>
<p>Go 语言在代码格式上采取了很强硬的态度。<code>gofmt</code>工具把代码格式化为标准格式译注这个格式化工具没有任何可以调整代码格式的参数Go 语言就是这么任性),并且 <code>go</code> 工具中的 <code>fmt</code> 子命令会对指定包,否则默认为当前目录中所有go 源文件应用 <code>gofmt</code> 命令。本书中的所有代码都被 gofmt 过。你也应该养成格式化自己的代码的习惯。以法令方式规定标准的代码格式可以避免无尽的无意义的琐碎争执(译注:也导致了 Go 语言的 TIOBE 排名较低,因为缺少撕逼的话题)。更重要的是,这样可以做多种自动源码转换,如果放任 Go 语言代码格式,这些转换就不大可能了。</p>
<p>Go 语言在代码格式上采取了很强硬的态度。<code>gofmt</code>工具把代码格式化为标准格式译注这个格式化工具没有任何可以调整代码格式的参数Go 语言就是这么任性),并且 <code>go</code> 工具中的 <code>fmt</code> 子命令会对指定包否则默认为当前目录中所有go 源文件应用 <code>gofmt</code> 命令。本书中的所有代码都被 gofmt 过。你也应该养成格式化自己的代码的习惯。以法令方式规定标准的代码格式可以避免无尽的无意义的琐碎争执(译注:也导致了 Go 语言的 TIOBE 排名较低,因为缺少撕逼的话题)。更重要的是,这样可以做多种自动源码转换,如果放任 Go 语言代码格式,这些转换就不大可能了。</p>
<p>很多文本编辑器都可以配置为保存文件时自动执行 <code>gofmt</code>,这样你的源代码总会被恰当地格式化。还有个相关的工具:<code>goimports</code>,可以根据代码需要,自动地添加或删除 <code>import</code> 声明。这个工具并没有包含在标准的分发包中,可以用下面的命令安装:</p>
<pre><code class="language-shell">$ go get golang.org/x/tools/cmd/goimports
</code></pre>

File diff suppressed because one or more lines are too long

File diff suppressed because one or more lines are too long