Комментарии 9
Назвать статью «Как не наступать на грабли» стоило, если бы вы написали, как на них не наступать, а так это скорее «список граблей по инвентарному перечню», если вам прилетит в лоб, вы знайте, что действительно такие грабли есть. Статья хорошая, но очень в ней не хватает к каждому пункту, что же собственно нужно делать, чтобы на них не ступать, как создатели языка предполагали использовать все эти неочевидные моменты, видимо есть какие-то бестпрактис маневрирования между этими граблями, на мой взгляд эта информация очень лаконично дополняла бы список самих проблем и причин их появления.
<sarcasm Не использовать Go? sarcasm>
я честно говоря подумал тоже самое. Но обьясню. Если понаблюдать за развитием языков программирования, то одни появляются чтобы избавиться от недостатков других. Но и они не получаются без недостатков. Поэтому возникает резонный вопрос, а надо ли оно в таком количестве. На самом деле надо — потому что прийти к совершенству можно только через эволюцию или революцию. Но скорее через революцию, потому что при эволюции мы пользуемся знанием предыдущих поколений, а они не совершенны и максимум, что получится в конце эволюции — идеальная раскоряка :) А при революции создается что-то принципиально новое. Получается, продолжу рассуждение, что если посредством революции не получилось идеального результата, скорее всего нет смысла его улучшать, а нужно готовить следующую революцию.
По моему «грабли» лучше заменить на «подводные камни». И было бы вроде «Подводные камни в Go о которых мы должны помнить». Для меня это кажется, более наглядно и обыденно, т.к. подводные камни как раз то что вы описали — то чего не видно на поверхности и может причинить неприятности, если не знать, где они. И да — о них всегда узнаешь впервые, когда уже напоролся.
ошибочка небольшая:
cap(b) будет не 15, как указано на рисунке, а 31
(https://play.golang.org/p/jnzXdQTGSCJ)
a := make([]int, 32)
b := a[1:16]
a = append(a, 1)
a[2] = 42
cap(b) будет не 15, как указано на рисунке, а 31
(https://play.golang.org/p/jnzXdQTGSCJ)
в первом случае изменяя переменную
pв функцииFoo(), вы будете работать с копией и не измените значение оригинальной переменной (p1), а втором — измените, поскольку указатель будет ссылаться на оригинальную переменную.
Тут стоит упомянуть, что во втором случае не всегда, передавая указатель, мы изменим данные
В примере ниже будет выводиться Bob, так как мы передаём копию указателя в функцию, где затираем этот указатель (а не сами данные, так как не обращаемся напрямую к данным) новым
type Person struct {
Name string
}
func main() {
p := &Person{
Name: "Bob",
}
fmt.Println(p.Name) // Bob
changePerson(p)
fmt.Println(p.Name) // Bob
}
func changePerson(p *Person) {
p = &Person{
Name: "Vasya",
}
}Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как не наступать на грабли в Go