Как стать автором
Обновить

Комментарии 9

Логин и Пароль в querystring? Или мои глаза меня подводят?

Ну, это имеет значение только, если процесс происходит вне вашей инфраструктуры. Т.е. браузерная адресная строка и подобное
Все URL подключения к базам данных и любым другим сервисам внутри вашей инфраструктуры это нормально переносят. А те, что вне - подключаемся через TLS и снова все ок
Т.е., если грубо, то скажу так: на бэкэндщиков это правило не действует =)

Ведь фактически всем безразлично, где вы передаете логин и пароль - самое главное, чтобы это было защищено. А если это в адресной строке браузера - то это уже видно на экране (полагаю, что еще и HTTP прокси увидит, если он есть) - т.е. не секюрно

Короче, не угадали немного

Я понимаю, что это в угоду м-м-м тесту производительности, но вы немножечко привираете — вы взяли и зарезервировали 128 байт под строку в то время как другие функции увеличивают строки на лету. Сложно сравнивать алгоритмы в таком случае. Не удивлюсь, если вы придумаете кеш из параметров и заготовленных результатов строк, то количество аллокаций (в тесте) опять же снизится и превратится просто в поиск по ключу.

Не совсем понимаю, где тут "привирание" - Grow(128) - тут происходит выделение буфера памяти - да, это аллокация, а возможно, если не хватит этого буфера, то будет еще одна аллокация

Кешировать параметры никто не собирается - тема статьи не про то, как производительнее конкатенировать строки. А про то, что Sprintf - это плохой способ собрать URL

fmt.Sprintf - это плохой способ собрать URL!

Перепутанные параметры не заметил, но резануло глаз то что для аргумента password указан тип данных, а для остальных - не указан. Конкретно на Go не программирую, - там не будет связанных с этим проблем? - например если в host передать объект, массив, число, булев, нулл?

Нет, у нас все просто. Через запятую однотипные параметры, через пробел тип - это Ок

Передать случайно туда другой тип (булев или нулл) не получится - строгая типизация. Компилятор не даст

Когда ряд последовательно идущих параметров функции имеют одинаковый тип, то тип для них всех можно указывать 1 раз после последнего параметра.

А что мешает Вам ошибиться в порядке аргументов NewURLConnectionString?

Порядок следования параметров не важен, если значения связаны с параметрами. А вот если наименования параметров и передаваемые значения не имеют сцепки, тогда порядок становится важен. Только давайте я назову это "порядок передаваемых значений". Вот поглядите:

// мне не важно, вот так:
v.Set("server_name", serverName)
v.Set("database_name", databaseName)
// или вот так:
v.Set("database_name", databaseName)
v.Set("server_name", serverName)

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

// мне важно вот так
fmt.Sprintf("?database_name=%s&server_name=%s", serverName, databaseName)

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

Так что - глаза. Мой ответ "глаза мне мешают ошибиться в порядке передаваемых значений".

Зарегистрируйтесь на Хабре, чтобы оставить комментарий