Naming projects with multiple words

[Tong Sun]

Hi, 

What's the idiomatic way to name Go projects with multiple words? Would it be, 

- github.com/my-id/multiple-words, or

- github.com/my-id/multiple_words, or even

- github.com/my-id/does-not_care, or

- github.com/my-id/InOneWord

what's your preference and why? 

Thanks

[Jan Mercl]

On Wed, Apr 19, 2017 at 3:48 PM Tong Sun <sunto...@gmail.com> wrote:

> what's your preference and why? 

example.com/name/onenamenopunctutaionalllowercasetwotoninecharacters 

b/c ~ what POSIX recommends for utility names.

--

-j

[Tong Sun]

On Wed, Apr 19, 2017 at 9:59 AM, Jan Mercl <0xj...@gmail.com> wrote:

On Wed, Apr 19, 2017 at 3:48 PM Tong Sun <sunto...@gmail.com> wrote:

> what's your preference and why? 

example.com/name/onenamenopunctutaionalllowercasetwotoninecharacters 

 Hmm... does it meant to be sarcasm or actually recommendation? Honestly, I tried to figure out the words from that long name but gave up after several attempts. 

b/c ~ what POSIX recommends for utility names.

 

Any urls maybe? 

I was trying to find that myself, and found one page, 

Utility Conventions

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html

Which says, 

Within POSIX.1-2008..., The utility in the example is named utility_name, 

i.e., separated with an underscore. 

[Chris Manghane]

There's definitely no idiom here. Do what the octokittens do and probably use the first or second option, in that order. The third seems awkward, unless the underscore has some specific meaning (like how _unix is used to compile architecture-specific code). And I'm not really sure if the capitalization in the fourth actually matters.

Looking at the Go repos themselves, there are examples of both: gofrontend and sublime-build. It seems like go-frontend and sublimebuild would also be reasonable names for these as well so do whatever you feel like I guess.

Thanks,

Chris

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[jmont...@dyn.com]

I assume by "projects" you mean packages. I understand that multiple word package names are sometimes needed, but Effective Go: package-names from the official go website recommends:

"By convention, packages are given lower case, single-word names; there should be no need for underscores or mixedCaps."

So avoid them when possible.

- Jake

[Tong Sun]

Hi, 

Thanks you all that helped. 

I choose the first option, and am now facing a new problem -- when I run 

go test -v ./...

I got "no tests to run" even though I have a _test file:

https://github.com/go-cc/cc-table/blob/master/cc-pinyin-range/pinyin_test.go

For other directories, I got "no test files", which is obvious, but what does this "no tests to run" mean and how can I fix it? 

Is it because I'm using multiple words for my project name, and I use a different package name within it? 

I've defined a type "Pinyin" in that package, so "func ExamplePinyin()" or even "func ExamplePinyin_output()" is a good name for testing, right?

How can I make my above _test file work?

Thanks

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

[jmont...@dyn.com]

Yes, your tests should have the the same package name as your code, so in this case package pybr. They will not effect the package when built normally. They are only included when running go test. You also need to name your tests correctly, and they need a signature like:

func TestXxx(*testing.T)

See the testing package documentation.

- Jake

[Tong Sun]

I'm afraid that you are wrong at both points. 

- tests needn't have to use the the same package name, in this case package pybr is good, but package pybr_test is good as well. 

- func TestXxx is not the only signature allowed, see https://golang.org/pkg/testing/#hdr-Examples

but thanks for your input anyway. 

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/DbS8JFbdflE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts+unsubscribe@googlegroups.com.

[Ian Davis]

On Sat, 22 Apr 2017, at 02:51 AM, Tong Sun wrote:

I'm afraid that you are wrong at both points. 

- tests needn't have to use the the same package name, in this case package pybr is good, but package pybr_test is good as well. 

- func TestXxx is not the only signature allowed, see https://golang.org/pkg/testing/#hdr-Examples

The link says "Example functions without output comments are compiled but not executed."

You don't appear to have the necessary output comments.

[Tong Sun]

Ah!! Thanks a lot! (was planning to do next to get the correct output first, but get confused as the go output)