Size: a a a

Kotlin Community

2020 October 14

AL

Alexander Levin in Kotlin Community
саша сок #KotlinGang
ну я о такой регулярке и говорю. была бы она сложная, сплитами думаете лучше было бы ?
Наверное тут больше о общей практике - не сколько конкретно сплит, скорее просто пытаться избегать регексов и проверять, какие функции для работы со строками могут подходить лучше.
источник

с#

саша сок #KotlinGang... in Kotlin Community
я стараюсь сплита избегать, потому что не всегда понятна искомая структура
источник

D

Denys in Kotlin Community
саша сок #KotlinGang
я стараюсь сплита избегать, потому что не всегда понятна искомая структура
А вы данные не валидируете?
источник

D

Denys in Kotlin Community
Без валидации и (.*):(.*)@(.*):(.*) вот такое пропустит: ab:cd@ef:gh
источник

с#

саша сок #KotlinGang... in Kotlin Community
Denys
Без валидации и (.*):(.*)@(.*):(.*) вот такое пропустит: ab:cd@ef:gh
у меня в прокси листе будет где-нибудь такое значение ?
источник

с#

саша сок #KotlinGang... in Kotlin Community
после выбора прокси я потом гружу сайт через него, чтобы проверить, всё ли с ним хорошо
источник

D

Denys in Kotlin Community
Там уж регулярка ближе к (.+):(.+)@(.+):(\d+) получается :)
источник

D

Denys in Kotlin Community
Основная претензия к ним в коде, что их сложно документировать. А так инструмент хороший, да. Но и абюзят его слишком часто. :)
источник

с#

саша сок #KotlinGang... in Kotlin Community
Denys
Там уж регулярка ближе к (.+):(.+)@(.+):(\d+) получается :)
зачем мне такое, когда у меня валидный прокси лист)
источник

с#

саша сок #KotlinGang... in Kotlin Community
Denys
Основная претензия к ним в коде, что их сложно документировать. А так инструмент хороший, да. Но и абюзят его слишком часто. :)
я вообще столько с ними работал, когда делал подсветку синтаксиса. и там же можно просто назвать правильно переменную, в которой лежит регех и проблем с документацией не будет
источник

с#

саша сок #KotlinGang... in Kotlin Community
я их в переменные всегда выношу, потому что напрямую Regex("...").find("...") выглядит страшно
источник

s

std::mpa in Kotlin Community
саша сок #KotlinGang
ну там тогда надо делать
split(Regex("[@:]")) потому что данные делятся и тем и тем

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

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

с#

саша сок #KotlinGang... in Kotlin Community
std::mpa
нестрашно. имо, оверхедик такой.
ок придёт человек и будет смотреть по моему коду и думать, что же там за линии в файле
источник

с#

саша сок #KotlinGang... in Kotlin Community
а так просто на регулярку посмотрел

(.+):(.+)@(.+):(.+)

и с подсветкой понятно, что там просто 4 группы
источник

s

std::mpa in Kotlin Community
fun parseAddress(...) {}
источник

с#

саша сок #KotlinGang... in Kotlin Community
std::mpa
fun parseAddress(...) {}
умно)

fun parseProxyCredentials(raw: String) = raw.split("@", ":")
источник

с#

саша сок #KotlinGang... in Kotlin Community
не понятно из чего состоят эти credentials или address
источник

с#

саша сок #KotlinGang... in Kotlin Community
он и без парольный может быть в теории
источник

с#

саша сок #KotlinGang... in Kotlin Community
а, и если мне понадобится добавить такие прокси, то я просто сделаю

((.+):(.+)@)?(.+):(.+)
источник

с#

саша сок #KotlinGang... in Kotlin Community
и тут всё тоже вполне очевидно для тех, кто с регулярками работает
источник