Показаны сообщения с ярлыком Go стиль программирования. Показать все сообщения
Показаны сообщения с ярлыком Go стиль программирования. Показать все сообщения

вторник, 5 марта 2019 г.

Go Code Review Comments: Именованные параметры результата

При использовании именованных параметров результата учитывайте как это будет выглядеть в godoc. Например, именованные параметры результата, такие как:

func (n *Node) Parent1() (node *Node)
func (n *Node) Parent2() (node *Node, err error)

будут иметь проблемы в godoc; лучше использовать:

func (n *Node) Parent1() *Node
func (n *Node) Parent2() (*Node, error)

С другой стороны, если функция возвращает два или три параметра одного и того же типа или если значение результата неясно из контекста, добавление имен может быть полезно в некоторых контекстах. Не называйте параметры результата только для того, чтобы избежать объявления переменной внутри функции; это заменяет небольшую краткость реализации ценой ненужного многословия API.

func (f *Foo) Location() (float64, float64, error)

не так ясно как:

// Местоположение возвращает широту и долготу f.
// Отрицательные значения означают юг и запад соответственно.
func (f *Foo) Location() (lat, long float64, err error)

Безыменные возвраты это нормально, если функция состоит из нескольких строк. Как только это функция среднего размера, будьте явными со своими возвращаемыми значениями. Следствие: не стоит называть параметры результата только потому, что это позволяет вам использовать безыменные результаты. Ясность документов всегда важнее, чем сохранение одной или двух строк в вашей функции.

Наконец, в некоторых случаях вам нужно назвать параметр результата, чтобы изменить его в отложенном замыкании. Это всегда хорошо.


Читайте также:


Go Code Review Comments: Длина строки кода

В Go нет жесткого ограничения длины строки кода, но избегайте неудобно длинных строк. Точно так же не добавляйте разрывы строк, чтобы сохранять короткие строки, когда они более читабельны, например, если они повторяются.

В большинстве случаев, когда люди переносят строки «неестественно» (в середине вызовов функций или объявлений функций), перенос будет ненужным, если строка имеет разумное количество параметров и разумно короткие имена переменных. Длинные строки, обычно, идут с длинными именами, и избавление от длинных имен очень помогает.

Другими словами, разбивайте строки из-за семантики того, что вы пишете (как правило), а не из-за длины строки. Если вы обнаружите, что это приводит к слишком длинным строкам, измените имена или семантику, и вы, вероятно, получите хороший результат.

Это фактически такой же совет как и относительно того, какой длины должна быть функция. Нет правила «никогда не иметь функцию длиной более N строк», но определенно существует такая вещь, как слишком длинная функция и слишком запутанные крошечные функции, и решение состоит в том, чтобы изменить границы функций, а не начать считать строки.


Читайте также:


среда, 13 февраля 2019 г.

Go FAQ: Существует ли руководство по Go стилю программирования?

Нет явного руководства по стилю, хотя, безусловно, есть узнаваемый стиль Go.

Go установил соглашения для принятия решений о наименовании, шаблонах и организации файлов. Серия постов Эффективный Go содержит некоторые советы по этим темам. Также существует программа gofmt - это симпатичный принтер, чья цель - обеспечить соблюдение правил размещения; он заменяет обычный сборник того, что можно и чего нельзя делать. Весь код Go в репозитории и подавляющее большинство в open source мире, прошел через gofmt.

Документ Go Code Review Comments это коллекция очень коротких эссе о деталях идиом Go, которые часто пропускаются программистами. Это удобный справочник для людей, которые делают review кода для проектов Go.


Читайте также: