для тех, кто задолбался создавать структуры под парсинг каждого типа json'а - https://github.com/valyala/fastjson

Приведение типов это то о чем я всегда мечтал, спасибо

на fasthttp пока забил - другими делами занимаюсь (

Ого, привет!

для тех, кто задолбался создавать структуры под парсинг каждого типа json'а - https://github.com/valyala/fastjson

Meaningful variable names

привет посоветуйте пожалуста найболее удобною библитеку для работы с тг ботами и где норм/более менее можно мокапить

привет посоветуйте пожалуста найболее удобною библитеку для работы с тг ботами и где норм/более менее можно мокапить

Что не понятно?

[] + []

Просто интересно зачем люди используют однобуквенные названия для переменных. Мне сложно понять что в них скрывается.

Просто интересно зачем люди используют однобуквенные названия для переменных. Мне сложно понять что в них скрывается.

спасибо

создал новый релиз https://github.com/valyala/fasthttp/releases/tag/v20180529

s = string p.b = parser.buffer p.c = parser.cache

создал новый релиз https://github.com/valyala/fasthttp/releases/tag/v20180529

Это ясно, но вы не должны это объяснять. Если бы переменная была нормально названна я бы понял сразу

Meaningful variable names

не люблю много писать :)

Друзья, а что почитать касаемо многопоточности golang, чтоб подробно со всем подводными камнями?

Я вас отлично понимаю :) Просто имейте ввиду, что будущим мейнтейнерам придётся не просто )

Я вас отлично понимаю :) Просто имейте ввиду, что будущим мейнтейнерам придётся не просто )

Да всё же очевидно, какие сложности?))

Кирилл разобрался с названиями за пару минут. Значит он будет мейнтейнером

короткие имена отсеивают потенциальных мейнтейнеров, которые хотят запутать код длинными идентификаторами )

Если что всплывёт - пиши, мигом поправлю

Ок, спс

Ничего. Просто сядь и пиши код

а примеров то нет))

Я новые идеи хочу

https://g.co/kgs/ixx1Ww

#вредныесоветы

Нет

Омлет. Сначала нужно азы самому понять, а потом, если не хватит, в крайнем случае лезть в книги

s = string p.b = parser.buffer p.c = parser.cache

Читабельность уровня го

да хорош наезжать) такого добра на любом другом языке навалом

видел только в го чтобы рекомендовали делать названия покороче :)

х.з. не слышал. вообще тут вроде выше правильно отметили, если область видимости маленькая, то и сэкономить не страшно.

это рекомендация которую не все гоферы прочитали полностью :)

и пишем

х.з. не слышал. вообще тут вроде выше правильно отметили, если область видимости маленькая, то и сэкономить не страшно.

И сделай его сначала максимально стабильным, а потом максимально быстрым

Страшно, ещё как, ибо при чтении вырывает читателя из потока и заставляет в уме подставлять вместо этих p.b нормальные названия. Я у себя в коде допускаю однобуквенные переменные только там, где у буквы есть общепринятый смысл, например x, y, z для координат и i, k, j для индексов, либо в однострочных лямбдах.

ну, например, for u := range users { u.DoSomeStuff() } мне кажется лучше чем for user := range users { user.DoSomeStuff() } потому как первое акцентирует внимание на DoSomeStuff, второе больше на user. но это все дело вкуса

Страшно, ещё как, ибо при чтении вырывает читателя из потока и заставляет в уме подставлять вместо этих p.b нормальные названия. Я у себя в коде допускаю однобуквенные переменные только там, где у буквы есть общепринятый смысл, например x, y, z для координат и i, k, j для индексов, либо в однострочных лямбдах.

ну поля структуры это конечно ппц. а вот если переменная объявлена и используется в двух трёх соседних строках, то не страшно я щитаю.

и получаем индекс в user

ну, например, for u := range users { u.DoSomeStuff() } мне кажется лучше чем for user := range users { user.DoSomeStuff() } потому как первое акцентирует внимание на DoSomeStuff, второе больше на user. но это все дело вкуса