LINUX.ORG.RU

go переменные

 


0

5

Читаю про Go.

Поиск в Google выдает:
«В Go тип переменной ставится после имени из-за стремления к лаконичности и читаемости кода, а также для упрощения процесса вывода типов компилятором (синтаксис имя тип вместо тип имя), что делает код более понятным»

«Понятнее» конечно делает, если тип функции засунуть между аргументами функции и телом функции:

func CalculateDiscount(price float64, percentage float64) float64 {

Go поощряет использование коротких имен, особенно в случаях, когда их смысл легко понять из контекста.
Пример с habr.com (два варианта):

func countLines() int {
    // do stuff
    var linesCount int
    for i := 0; i < lines; i++ {
        linesCount += 1
    }
    return linesCount
}

func countLines() int {
    // do stuff
    var c int
    for i := 0; i < lines; i++ {
        c += 1
    }
    return c
}

★★

Последнее исправление: WinLin2 (всего исправлений: 5)
Ответ на: комментарий от kaldeon

Вроде у всех тип имя, здесь наоборот.
При описании функции вообще чёрте-что получилось :)

WinLin2 ★★
() автор топика
Последнее исправление: WinLin2 (всего исправлений: 1)
Ответ на: комментарий от PPP328

пришлось вводить отдельное ключевое слово var, потому что распарсить кашу компилятор иначе не смог бы

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

Darfin
()
Ответ на: комментарий от Darfin

Потому что иначе любая опечатка в переменной ведет к созданию новой переменной и удачи потом в отладке всего этого.

По какой-то магической причине языки, у который переменные объявляются как «тип имя» лишены такой проблемы.

PPP328 ★★★★★
()
Последнее исправление: PPP328 (всего исправлений: 1)
Ответ на: комментарий от WinLin2

Не у всех. У успешных языков программирования, к которым относится и Golang, синтаксис подходит к их назначению. Нет одного синтаксиса, лучшего лля всех языков. Поэтому при изучении нового языка важно понять, для,чего в нём такой синтаксис, а не обходитьс своим знанием других языковю

Partisan ★★★★★
()

(price float64, percentage float64)

По-моему сейчас на Go делают так

func CalculateDiscount(price, percentage float64) float64{}

Тогда price и percentage будут оба float64. Оно и читается проще, чем отдельно описанные оба аргумента

Tyse_EX
()
Последнее исправление: Tyse_EX (всего исправлений: 1)
Ответ на: комментарий от firkax

Но почему-то Pascal и все основанные на нём языки вышли из употребления. Это не значит, что они были плохие. Просто изменились требования и понадобились новые языки, в том числе Go. В общем,кто изучает Go, тому надо изучать Go, а не Pascal.

Partisan ★★★★★
()
Ответ на: комментарий от ugoday
<source>:2:11: warning: using the result of an assignment as a condition without parentheses [-Wparentheses]
    2 |     if (i = 0) {
      |         ~~^~~
<source>:2:11: note: place parentheses around the assignment to silence this warning
    2 |     if (i = 0) {
      |           ^  
      |         (    )
<source>:2:11: note: use '==' to turn this assignment into an equality comparison
    2 |     if (i = 0) {
      |           ^
      |           ==
Softwayer ★★
()
Ответ на: комментарий от Darfin

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

Не совсем так.

func main() {
	// все варианты валидны
	var a int
	var b int = 1
	c := 2

	fmt.Println(a, b, c) // 0, 1, 2
}

Поиграть тут: https://go.dev/play/p/naRoDyr-HHL

Первоначальное значение будет «нулевым» для типа (nil для ссылочного / интерфейса, zero value для простых типов). Тут намеренно упрощаю, но для целей комментария, думаю, ок.

Тут вам не плюСЫ, короч, где можно объявить что-то, и оно будет смотреть в кусок памяти, где что-то раньше валялось, пока ему не присвоишь значение.

paddlewan
()
Ответ на: комментарий от Partisan

Ты несколько манипулируешь фактами. Паскаль вышел из употребления потому что его заменил Си. Го тут вообще «вне конкуренции» в плохом смысле, то есть он даже не кандидат на занятие этой ниши.

А кто изучает го - он либо по неопытности выбрал не тот язык, либо вообще выбрал не ту сферу деятельности.

firkax ★★★★★
()
Ответ на: комментарий от ugoday

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

firkax ★★★★★
()
Ответ на: комментарий от Softwayer

Не надо -Wparentheses включать, этот варнинг для слабоумных и нормальным программистам он только мешает флудом при компиляции.

Разве что во время обучения он может быть иногда имеет смысл.

firkax ★★★★★
()

Ох, в Го есть столько много чего, что может раздражать/интриговать, но нет, блин, обсуждать будем type name vs name type. Скуууучно!

Waterlaz ★★★★★
()
Ответ на: комментарий от firkax

Но почему «нечаянно»?

Изначально люди были совершенными, обладали абсолютной зоркостью и внимательностью, и никогда не путали сравнение с присваиванием. Но потом одна подлая змеюка уболтала Еву сожрать яблоко (я надеюсь это было очень вкусное яблоко!). В результате грехопадения мы стали слабыми, рассеянными и невнимательными. Нуждаемся в одежде для прикрытия наготы и помощи компилятора для борьбы с ошибками. В конце-концов, это компьютер должен работать на нас, а не мы на него, не так ли?

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

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

firkax ★★★★★
()
Ответ на: комментарий от firkax

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

Ну, кто-то из нас дорос до мудрости, что люди делают очепятка, кто-то — нет.

Waterlaz ★★★★★
()
Ответ на: комментарий от Waterlaz

Опечатки разумеется бывают. Только вот опечататься и написать плюс вместо минуса (или наоборот) ничуть не сложнее чем написать присваивание вместо сравнения (а ещё - написать «a» вместо «s», например, эти буквы рядом). Присваивание - ничем не особенная операция по сравнению с остальной сишной арифметикой, не надо пытаться к нему какие-то индивидуальные костыли прицеплять или обвинять именно его в опечатках.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от firkax

Пони_маете ли коллега!

Нейман(ну тот который фон) ваще щитал использование чего либо окромя машкода растратой машины - ибо настоящий программист(ТМ) пишет оптимально в кодах цели а остальные только тратят дефицитный ресурс

однако в индустрии целенаправленно выбран(судьбой) путь подгонки инструментов под падающий общий уровень образованности всё приходящих поколений

qulinxao3 ★☆
()
Ответ на: комментарий от WinLin2

Если мысленно поставить двоеточие, будет понятнее смысл.

var foo: int

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

var foo *[]*int
var bar []func([]int) []int

Оба типа читаются естественно, слева-направо. А в C страшно представить как это будет выглядеть.

Ещё могу отметить вопрос типографики. Имя переменной гарантированно всегда стоит на определённой позиции, не плавает в зависимости от типа.

kaldeon
()
Последнее исправление: kaldeon (всего исправлений: 1)

Go поощряет использование коротких имен

У меня был старый пост про это, но на английском языке.

I support short names wholeheartedly. There is no better index name than “i.”

I have heard an idea that a good variable should be understood by just reading its name, out of context. That would make “ProductIndex” superior to “i.” But long lines make reading rhythm uncomfortable (long jumps, prolonged eye movements) and long words make the text too dense and slow down the reading. It’s bad typography. Why are typography standards recognized universally except for code? Is code really that special? I doubt it.

Short words are the essence of English as well. I’ve learned it on a grammar course and the whole passage is worth sharing:

“One can convey a natural, direct simplicity with Anglo-Saxon English that cannot be conveyed with Latin or with Latin derivatives. So if your intention in any passage is to be natural, direct, straightforward, which is, of course, crucial, it helps you to know some derivatives, some linguistic sources, the Anglo-Saxon components. In any case, the bulk of your style has to be Anglo-Saxon. Otherwise, it would be impossible for a reader to take it in. So if you find that you’ve got Latinate expressions, “transformation” and “ostentation” instead of “change” and “show,” if you’re going heavily into these Latin long-word formulas, or formulations, you have a true stylistic disease that wipes out the ability to communicate. Fowler describes this particular variant as “love of the long word,” which he regards as a separate sin.”

— Principles of Grammar by Leonard Peikoff https://a.co/dB7ByV7

kaldeon
()
Ответ на: комментарий от Darfin

Однако, никто не мешает автоматически выводить тип при объявлении с присваиванием. И потом ловить ошибки из-за того, что нельзя типу int64 присвоить значение int.

Но это тоже не то чтобы проблема.

2ТС: вопрос то в чём?

skiminok1986 ★★★★★
()
Ответ на: комментарий от kaldeon

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

однако краткосрочные выгоды обычно побеждают «идеальный дизайн»(который не факт что реально таков)

qulinxao3 ★☆
()
Ответ на: комментарий от kaldeon

жаль что понимание что в фортране идентификаторы(ограничены 6 символами были) не очевидно нонешним(в прочем и мне это открылось лишь недавно) ибо там были 36битные слова и 6битные символы

односимвольные идентификаторы это по сути служебные переменные с уже предварительной семантикой - ибо таковые сложно (простыми)регулярками

ваще комбинационно трёхсимвольных слов английского какого большого «Уэбстера» вполне достаточно для обогащённого комментариями в идентификаторах локальных {тем более при нынешних редакторах кода можно не длинный идентификтор везде упоминать а в балуне(али каком теневом комменте отображаемым чисто в режиме просмотра в конце строки а не зашитое в сам сырец} комент из места декларации сего локального короткого имени

зы/ жаль что идея известная через форт - когда код слова достаточный ключ для человеко_читаемого имени излишне технологична и не подходит для hairpoint java middle ...

qulinxao3 ★☆
()
Ответ на: комментарий от skiminok1986

Однако, никто не мешает автоматически выводить тип при объявлении с присваиванием. И потом ловить ошибки из-за того, что нельзя типу int64 присвоить значение int.

А можно использовать gopls, который удивительно быстр даже на в termux на телефоне, и обращать внимание на его предупреждения. Очень быстро избавляет от склероза.

anonymous
()
Ответ на: комментарий от skiminok1986

Так а зачем мучаться без них? Чай уже почти в 2026 живём, не в 1970-х. LSP практически в любом редакторе есть. Я не просто так про телефон писал.

autocmd BufWritePre *.go
   \ call execute('LspDocumentFormatSync') |
   \ call execute('LspCodeActionSync source.organizeImports')
anonymous
()
Ответ на: комментарий от WinLin2

Вроде у всех тип имя, здесь наоборот.

Не «у всех», а у си-подобных (C++, Java, C#, D). И это действительно кошмар, когда идёт тип, потом имя, и потом, наконец, ура, скобка! Теперь понятно, что это функция, а не переменная. Просто ты привык и не замечаешь.

А в Rust и JavaScript функции начинаются так же, как в Go, с отдельного ключевого слова. Так же было в Алголе, Паскале, Аде – по-настоящему красивых языках.

// Мимокрокодил писатель кода на C++

hobbit ★★★★★
()
Ответ на: комментарий от WinLin2

Это еще от Паскаля идет, дедушка Вирт, царство ему небесное, понимал как студенты будут код писать и сделал так, чтобы ошибок при этом было поменьше, в том числе и при чтении типа переменной.

LongLiveUbuntu ★★★★★
()
Последнее исправление: LongLiveUbuntu (всего исправлений: 1)
Ответ на: комментарий от kaldeon

I have heard an idea that a good variable should be understood by just reading its name, out of context. That would make “ProductIndex” superior to “i.” But long lines make reading rhythm uncomfortable (long jumps, prolonged eye movements) and long words make the text too dense and slow down the reading. It’s bad typography. Why are typography standards recognized universally except for code? Is code really that special? I doubt it.

Во, правильно пишет. Я ровно то же самое писал.

firkax ★★★★★
()
Ответ на: комментарий от firkax

out of context
That would make “ProductIndex” superior to “i.”

Всегда бесил этот подход. Без контекста код не понять, даже если там будет хоть целое предложение английским записано.

Из моей жаба-практики, длинна идентификаторов даже обратно коррелирует с качеством кода. Если в коде видишь listOfTopProductsOfTheCurrentMonth вместо topProducts (или даже просто top) то будь уверен, сам проект это хитросплетенная лапша.

Даже на собеседованиях сразу видно, если человек начали писать `int currentIndex` — 99% он задачу не решит.

urxvt ★★★★★
()
Последнее исправление: urxvt (всего исправлений: 2)