Использование «этого» на Голанге

12

На ближайшей вещи Golang имеет к руководству по стилю нашла здесь , под ресивером имен это написано:

Имя получателя метода должно отражать его идентичность; часто достаточно одной или двух буквенных аббревиатур этого типа (например, «c» или «cl» для «Client»). Не используйте универсальные имена, такие как «я», «это» или «я», идентификаторы, типичные для объектно-ориентированных языков, в которых больше внимания уделяется методам, а не функциям. Имя не обязательно должно быть таким же описательным, как и у аргумента метода, так как его роль очевидна и не имеет никакой документальной цели.

Лично я всегда использовал «this» в качестве идентификатора, потому что «this» - это то, над чем я работаю, когда пишу и редактирую функцию. Это звучит правильно, и (по крайней мере для меня) это имеет смысл.

Если имя не обязательно должно быть описательным, его роль очевидна и не имеет никакой документальной цели , с какой стати следует осуждать использование «этого»?

Адам
источник
3
Подобный вопрос с большим количеством ответов: stackoverflow.com/questions/23482068
Трентон

Ответы:

11

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

По сути, когда вы пишете такой метод:

func (m *MultiShape) area() float64 {
  ...
}

Это почти то же самое, что написать такую ​​функцию:

func area(m *MultiShape) float64 {
  ...
}

Единственная разница - небольшое изменение синтаксиса в том, как мы вызываем функцию / метод.

В других языках this/ self/ любая переменная обычно имеет некоторые специальные свойства, такие как магическое предоставление языка или специальный доступ к закрытым методам (помните, что у Go нет закрытых полей / методов). Хотя «получатель» все еще «магически предоставляется» в некоторой степени, он настолько похож на аргумент обычной функции, что, вероятно, не считается.

Кроме того, в «традиционных» языках ООП все методы struct / class поставляются с определением struct / class, так что больше нельзя добавлять извне. Насколько мне известно, в Go каждый может добавить больше методов к чему угодно (конечно, в рамках своего собственного кода).

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

Ixrec
источник
Это хорошее объяснение, я полагаю, что я привык к C # и другим языкам ООП, поэтому я возвращаюсь к соглашениям, которые я знаю.
Адам
1
@ Адам я бы избегал, thisесли бы не по какой-либо другой причине, кроме как напомнить себе, что я не на традиционном языке ООП.
Майкл Хэмптон
4
Нет никакой реальной разницы между «этим» и «получателем» (и, пожалуйста, прекратите злоупотреблять словом «магия» - каждую функцию языка программирования высокого уровня можно назвать «магией», это не делает ее чем-то негативным, ваша попытка выбирать "это" как "магию" не имеет смысла).
mvmn
6

Я не убежден в этом стиль руководства , и я не думаю , что это лучше , чем this, meили self. Потому что this, meили selfпроясняет, что переменная является экземпляром структуры контекста. Я не говорю, что переменная структурного имени в нижнем регистре - плохая идея, мне просто нравится способ, который thisделает это супер ясным.

Цянь Чен
источник
без объяснения этот ответ может стать бесполезным в случае, если кто-то постит противоположное мнение. Например, если кто - то разместил требование , как «Я убежден , что в данном руководстве стиль , и я думаю , что это лучше , чем this, meили self» , как бы этот ответ поможет читателю выбрать из двух противоположных мнений? Подумайте о том, чтобы изменить его в лучшую форму, чтобы соответствовать рекомендациям « Как ответить»
gnat
Я думаю, что я четко объяснил, что я хотел сказать.
Цянь Чен
1
Согласен. Я думаю, что слишком много мозгов отравлено контекстом javascript. Если вы отложите это в сторону. То, что это относится к текущему контексту, намного проще. И проще, если вы переименуете структуры позже или скопируете вставку части реализации. Гонг для коротких загадочных имен линии hl и т. Д. Не делает это легче, чем это.
Sentient
0

Это с точки зрения JavaScript, где thisфактическое ключевое слово имеет значение для компилятора, но, насколько я понимаю, если они в порядке с двухбуквенными аббревиатурами для типа объекта, его должно быть достаточно просто использовать вместо этого. Причина различия заключается в том, что в прилично большом блоке постепенно более глубокого асинхронного кода может быть очень легко неверно истолковать, что означает «это» или получатель, в более глубоком контексте; и возможно это не будет тот же объект.

Например, в JavaScript модуль управления может запустить диалог и объявить onLoadдля него встроенную функцию. Но в этот момент другому кодировщику может быть очень легко неправильно интерпретировать thisвнутреннюю часть, onLoadссылаясь на модуль управления, а не на диалог; или наоборот. Этого можно было бы избежать, если бы элемент управления упоминался как, ctrlа диалог - как dg.

Katana314
источник
3
Я не плохой пользователь, но большинство запутанного поведения thisв Javascript просто не применимы к Go, поэтому я предполагаю, что именно поэтому.
Ixrec
@Ixrec Хм ... ладно. Я пытался распространить его на ситуации, когда вы могли выбрать thisимя; например, часто JS-кодеры пишут var self = thisдля того, чтобы сохранить одну и ту же ссылку; но, согласно руководству по проектированию Go, в этом случае могут возникнуть те же проблемы путаницы, и теоретически следует использовать более описательную ссылку.
Katana314