Comments 28
Не "Биксоджей", а "Биксодж".
он в конце говорит «джей», ну а с корпорацией добра спорить…
Странно, но мне нравятся все вариации чтения названия, уже предложенные )
Осталось спросить, а что думают по этому поводу носители языка
— Моя фамилия Ге, — сказал француз китайцу.
— В китайском языке два иероглифа Ге, но, к сожалению, ни один из них не подходит для фамилии.
— Почему?
— Потому что один имеет значение «колесо», а другой передает звук, с которым лопается мочевой пузырь осла.
— А что плохого в колесе?
— Мужское имя не может быть круглым. Для твоего имени мы возьмем иероглиф Шэ, означающий «клавиатура», «корнеплод», «страница», а также прилагательное «бесснежный» и дополним его иероглифом Нгу, означающим мужской род. В конце я пишу иероглиф Мо — «девственный».
— Но это, мягко говоря, не совсем…
— Никто не будет считать тебя девственником, просто без иероглифа Мо иероглифы Ше-Нгу означают «сбривающий мамины усы».
— Хорошо, теперь я напишу твое имя.
— Моя фамилия Го.
— Отлично, я начну твою фамилию с буквы G.
— Что означает буква G?
— У нас, европейцев, сами по себе буквы ничего не значат, но чтобы проявить к тебе уважение, я поставлю перед G букву H — во французском она все равно не читается.
— Отлично! Дальше O?
— Нет, чтобы показать, что G — произносится как Г, а не как Х, надо после G поставить букву U, а также H — чтобы показать, что U не читается сама по себе, а только показывает, как правильно читать G, и буквы EY, показывающие, что слово не длинное и скоро закончится.
— Hguhey… дальше O?
— Нет, О во французском произносится как А или Ё, в зависимости от стоящих по соседству букв, ударения и времени года. Твое чистое О записывается как AUGHT, но слово не может кончаться на T, поэтому я добавлю нечитаемое окончание NGER. Вуаля!
Русский лингвист поставил бокал на стол, взял листочек и написал «Го» и «Ге».
— И всё?
— Да.
Француз с китайцем почесали в затылке.
— Хорошо, а какая у тебя фамилия?
— Щекочихин-Крестовоздвиженский.
— А давайте просто выпьем? — первым нашёлся китаец.
Русский кивнул и француз с облегчением поднял тост за шипящие дифтонги.
deleted
Название мне стало напоминать не безызвестный фильм Джуманджи.
When in Go, do as Gophers do.
Не следует тесты в другой репозиторий отправлять. Они мешать не будут. Достаточно, чтоб имя у них подходило под маску *_test.go
. По этой теме можно ещё документацию пакета go/build почитать.
Кроме того не принято использовать CAPS_CASE для констант. Effective Go #mixed-caps.
Тип Node не используется нигде, кроме внутренностей. Можно его скрыть из видимости. Достаточно написать node. Аналогично с Section, Index и внутренними константами. Кстати golint вам об этом укажет.
Ещё по можно почитать CodeReviewComments.
Мааленький момент. Не документируйте файлы. Документируйте сущности. Неплохо было бы добавить либеральную лицензию и заодно убрать из файликов упоминание о себе любимом. Ну или по возможности сократить в одну строчку и написать её перед package main. Не забудьте пустую строку после такого комментария, иначе оно уже как документация будет.
По мимо прочего неплохо иметь ссылку на документацию прямо сверху README. Вот она: https://godoc.org/github.com/claygod/Bxog
Не следует тесты в другой репозиторий отправлять. Они мешать не будут. Достаточно, чтоб имя у них подходило под маску *_test.go. По этой теме можно ещё документацию пакета go/build почитать.
Знаю, это я из своих соображений.
Кроме того не принято использовать CAPS_CASE для констант. Effective Go #mixed-caps.
Как-то не обращал внимания. В принципе, поправить можно, хотя привычно большими буквами.
Тип Node не используется нигде, кроме внутренностей. Можно его скрыть из видимости. Достаточно написать node. Аналогично с Section, Index и внутренними константами. Кстати golint вам об этом укажет.
Кстати да, собирался убрать из области видимости, но хотел оставить в названиях большие буквы.
Впишется ли в норму вариант вместо Node -> bNode?
Мааленький момент. Не документируйте файлы. Документируйте сущности. Неплохо было бы добавить либеральную лицензию и заодно убрать из файликов упоминание о себе любимом. Ну или по возможности сократить в одну строчку и написать её перед package main. Не забудьте пустую строку после такого комментария, иначе оно уже как документация будет.
Написание подробной документации впереди, но по сути, давая по строке описания в каждом файле, я описывал сущности, поскольку их-то я и раскидал для удобства по разным файлам.
Посмотрел как на документацию влияет расположение комментариев в коде. Спасибо за подсказку, буду поправлять.
По мимо прочего неплохо иметь ссылку на документацию прямо сверху README. Вот она: https://godoc.org/github.com/claygod/Bxog
Добавил.
lain8dono, спасибо за комментарий, побольше бы таких!
Впишется ли в норму вариант вместо Node -> bNode?
Не особо, но лучше. Это будет выглядеть странновато для читающих код, хотя чуть лучше для читающих только документацию. Кстати node не на столько уж большая структура для того, чтоб выделять её в отдельный файл. Лично я оставил бы её в файле index.go.
Кстати нижнего подчёркивание в именах вообще следует избегать.
`
$ golint -min_confidence 0 config.go:3:1: should have a package comment, unless it's in another file for this package config.go:8:6: don't use underscores in Go names; type type_hash should be typeHash config.go:12:2: don't use ALL_CAPS in Go names; use CamelCase config.go:13:2: don't use ALL_CAPS in Go names; use CamelCase config.go:20:2: don't use ALL_CAPS in Go names; use CamelCase config.go:24:2: don't use ALL_CAPS in Go names; use CamelCase config.go:27:2: don't use ALL_CAPS in Go names; use CamelCase config.go:30:2: don't use ALL_CAPS in Go names; use CamelCase config.go:33:2: don't use ALL_CAPS in Go names; use CamelCase config.go:36:2: don't use ALL_CAPS in Go names; use CamelCase config.go:39:2: don't use ALL_CAPS in Go names; use CamelCase config.go:44:2: don't use ALL_CAPS in Go names; use CamelCase config.go:45:2: don't use ALL_CAPS in Go names; use CamelCase config.go:46:2: don't use ALL_CAPS in Go names; use CamelCase config.go:47:2: don't use ALL_CAPS in Go names; use CamelCase index.go:1:1: should have a package comment, unless it's in another file for this package index.go:12:6: exported type Index should have comment or be unexported index.go:26:2: don't use underscores in Go names; var c_hashes should be cHashes index.go:28:6: don't use underscores in Go names; var c_node should be cNode index.go:45:10: if block ends with a return statement, so drop this else and outdent its block index.go:73:3: don't use underscores in Go names; var c_node should be cNode index.go:80:3: don't use underscores in Go names; var c_hash should be cHash index.go:102:5: don't use underscores in Go names; var new_node should be newNode index.go:123:57: don't use underscores in Go names; method parameter c_hashes should be cHashes node.go:3:1: should have a package comment, unless it's in another file for this package node.go:7:1: comment on exported type Node should be of the form "Node ..." (with optional leading article) node.go:14:2: don't use underscores in Go names; var new_node should be newNode route.go:1:1: should have a package comment, unless it's in another file for this package route.go:13:6: exported type Route should have comment or be unexported route.go:40:9: if block ends with a return statement, so drop this else and outdent its block route.go:46:1: exported method Route.Method should have comment or be unexported route.go:51:1: exported method Route.Id should have comment or be unexported route.go:51:17: method Id should be ID route.go:56:17: method parseUrl should be parseURL route.go:57:6: don't use underscores in Go names; var array_sec should be arraySec router.go:3:1: should have a package comment, unless it's in another file for this package router.go:14:1: comment on exported type Router should be of the form "Router ..." (with optional leading article) router.go:21:1: comment on exported function New should be of the form "New ..." router.go:26:1: comment on exported method Router.Add should be of the form "Add ..." router.go:31:9: if block ends with a return statement, so drop this else and outdent its block router.go:36:1: comment on exported method Router.Start should be of the form "Start ..." router.go:52:1: comment on exported method Router.Params should be of the form "Params ..." router.go:55:5: don't use underscores in Go names; var c_route should be cRoute router.go:66:1: comment on exported method Router.Create should be of the form "Create ..." router.go:81:1: comment on exported method Router.Test should be of the form "Test ..." section.go:3:1: should have a package comment, unless it's in another file for this package section.go:7:1: comment on exported type Section should be of the form "Section ..." (with optional leading article) section.go:10:2: don't use underscores in Go names; struct field type_sec should be typeSec section.go:13:29: don't use underscores in Go names; func parameter type_s should be typeS server.go:3:1: should have a package comment, unless it's in another file for this package server.go:16:9: if block ends with a return statement, so drop this else and outdent its block (move short variable declaration to its own line if necessary)
`
Кстати go vet
тоже ругается. Недостижимый код в файлах route.go:42 и router.go:30.
Знаю, это я из своих соображений.
Если вы о том, что там другое имя пакета, то это не аргумент. Попробуйте. Всё заработает. http://stackoverflow.com/a/31443271 Плюсом будет возможность сделать так:
$ go get github.com/claygod/Bxog
$ cd $GOPATH/src/github.com/claygod/Bxog
$ go test
....
Кстати, а у вас есть бенчмарк на костыль с хешированием? На сколько это лучше/хуже чем map[string]T
?
Кстати, а у вас есть бенчмарк на костыль с хешированием? На сколько это лучше/хуже чем map[string]T?
Прямого нет, делал две версии поиска и сравнивал по общему бенчмарку. Но однозначно могу сказать, что сгенерировать хэш дешевле. Если бы вернуть старый алгоритм со строками, то думаю, сотня ns/op тут же набежала бы. И ещё я заметил, что с строками результат какой-то менее стабильный (больший разброс), хотя возможно это сугубо субъективно.
Но однозначно могу сказать, что сгенерировать хэш дешевле.
Однозначно об этом может сказать ТОЛЬКО правильно написанный бенчмарк. Более того. Вы заменяете стандартную функциональность языка собственным костылём. Следовательно далеко не лишним будет описание вашего алгоритма хеширования и объяснения, почему так лучше/быстрее/сильнее/выше и т.д. Желательно ещё и минусы (которые в любом случае есть) такого подхода обозначить.
Споры без бенчмарков о производительности можно приравнять к разговорам о политике.
Если очень хочется посоревноваться, то можно начать с https://github.com/gin-gonic/go-http-routing-benchmark
$ go test -v # github.com/claygod/BxogTest bxog_test.go:22:2: cannot find package "github.com/claygod/bxog" in any of: /usr/lib/go/src/github.com/claygod/bxog (from $GOROOT) /home/lain/gocode/src/github.com/claygod/bxog (from $GOPATH) FAIL github.com/claygod/BxogTest [setup failed]
Ваши тесты не заработают практически везде, кроме винды
Не соображу сразу… из-за того, что bxog в импортах написан с маленькой буквы? Плз, подскажите.
Если очень хочется посоревноваться, то...
Нет, я сделал бенч только для того, чтобы показать, что роутер не тормозной.
Следовательно далеко не лишним будет описание вашего алгоритма хеширования и объяснения, почему так лучше/быстрее/сильнее/выше и т.д. Желательно ещё и минусы (которые в любом случае есть) такого подхода обозначить.
Согласен, ключевой момент стоит осветить.
Тип Node не используется нигде, кроме внутренностей. Можно его скрыть из видимости. Достаточно написать node. Аналогично с Section, Index и внутренними константами. Кстати golint вам об этом укажет.
Поправил, в https://godoc.org/github.com/claygod/Bxog теперь только публичные функции роутера для API
Settings
Necessary changes in the configuration of the multiplexer can be made in the configuration file config.go
ссылка с config.go ведёт в никуда.
Роутер на Golang