Jakie są konwencje dotyczące nazw plików w Go?

114

Znalazłem konwencje nazewnictwa pakietów w Go: bez podkreślenia między słowami, wszystkie małe litery.

Czy ta konwencja dotyczy również nazw plików?

Czy umieszczasz również jedną strukturę w jednym pliku, tak jak w przypadku klasy Java, a następnie nazywasz plik po strukturze?

Obecnie jeśli mam struct WebServer, umieszczam go w pliku web_server.go.

go naming-conventions david
źródło
3
AFAIK nie ma konwencji, ale przyrostki _ mogą mieć w przyszłości specjalną semantykę, więc radzę ich unikać.
fuz

Odpowiedzi:

127

Jest kilka wskazówek, których należy przestrzegać.

  1. Nazwy plików zaczynające się od „.” lub „_” są ignorowane przez narzędzie go
  2. Pliki z przyrostkiem _test.gosą kompilowane i uruchamiane tylko przez go testnarzędzie.
  3. Pliki z przyrostkami specyficznymi dla systemu operacyjnego i architektury automatycznie podlegają tym samym ograniczeniom, np. name_linux.goBędą budować tylko na Linuksie, name_amd64.gobędą budować tylko na amd64. To jest to samo, co //+build amd64linia na początku pliku

Więcej informacji można znaleźć w dokumentacji go buildnarzędzia: https://golang.org/pkg/go/build/

JimB
źródło
3
Gdzie to jest udokumentowane? Dzięki!
Abhijeet Rastogi
2
@AbhijeetRastogi: golang.org/pkg/go/build and golang.org/cmd/go
JimB
3
Co powinienem zrobić, jeśli chcę budować dla unixi others. Np. Mogę zrobić dwa pliki file_windows.goi file_others.go. To działa dobrze. Ale dla file_unix.goi file_others.goto nie działa. Nie chcę tworzyć ośmiu plików darwin freebsg linux openbsd netbsd dragonfly solaris android.
Ivan Black,
3
@Fire: nazwy plików są generalnie pisane małymi literami, zarówno dla spójności, jak i dla systemów z systemami plików bez rozróżniania wielkości liter.
JimB
1
Dla każdego, kto ma takie samo pytanie jak @IvanBlack, można to zrobić za pomocą tagów kompilacji. Zobacz tutaj, aby uzyskać ładny przegląd, jak to zrobić: dave.cheney.net/2013/10/12/…
Ian Gustafson
30

Oprócz odpowiedzi udzielonej przez JimB , zwykłe nazwy plików są pisane małymi literami, są krótkie i bez podkreślenia ani spacji. Ogólnie nazwy plików są zgodne z tą samą konwencją, co nazwy pakietów. Zobacz sekcję nazw pakietów w Effective Go .

Dobry przykład można znaleźć w pakiecie strconv .

Zamicol
źródło
3
jak nazwałeś długie pliki? mycommandsub1command.golub my_command_sub1command.go, a co zmycommandVO
user2727195
9
Sugerowałbym podkreślenie długich nazw. Widziałem to w kilku dobrych projektach.
Avi,
17

Go jest dość liberalne, jeśli chodzi o sposób organizacji kodu w pakiecie, zwykle jest to wszystko, co poprawia czytelność i zrozumienie kodu. Najlepszym sposobem, aby dowiedzieć się, jak to się robi, jest przestudiowanie mistrzów, czyli przejrzenie standardowej biblioteki:

http://golang.org/src/pkg/

Są jednak dwie zasady, które przychodzą mi do głowy. Podczas określania kodu, który ma zostać skompilowany dla różnych platform, jako sufiksu należy użyć nazwy platformy:

mypkg_linux.go         // only builds on linux systems
mypkg_windows_amd64.go // only builds on windows 64bit platforms

Również jeśli masz plik o nazwie server.go, testy dla tego pliku będą w formacie server_test.go.

Matt Harrison
źródło
3
W podanym przez Ciebie linku znalazłem przypadki użycia z podkreśleniem: golang.org/src/pkg/compress/bzip2/move_to_front.go , golang.org/src/pkg/compress/flate/huffman_bit_writer.go , golang.org/ src / pkg / compress / flate / reverse_bits.go .
david
1
Myślę, że nie będzie używać _front, _writerlub _bitsjako istotnych przyrostków w przyszłości wtedy!
Matt Harrison,
Uwielbiam Go, ale gonarzędzie jest bardzo restrykcyjne jeśli chodzi o strukturę pakietu (jest to jedna z moich ulubionych rzeczy w języku). Preferuje pewne bardzo specyficzne konwencje (jeden pakiet na folder [z co najmniej jednym wyjątkiem], pakiet folderu ma taką samą nazwę jak folder [z co najmniej jednym wyjątkiem], pełna ścieżka importu pakietu odpowiada ścieżce względnej z $GOPATH, niektóre pliki są traktowane inaczej w zależności od formatu nazwy itp.)
weberc2
1
@ weberc2 Ograniczenia są analogiczne do Latex. Najpierw chciałem kontrolować mój układ i inne nieistotne szczegóły, dopóki nie zdałem sobie sprawy, że wszystko, co trzeba napisać, to dobra treść. Podobnie Go pozwala nam pisać dobry kod i obsługuje za nas inne szczegóły.
david
@david Zgadzam się. Z perspektywy czasu byłem niejasny: odpowiadałem na oświadczenie osoby odpowiadającej Go is quite liberal in terms of how you organise your code within a package. Go nie jest liberalne, jest dość restrykcyjne. Ale to dobra rzecz.
weberc2
8

Zwykle podkreślenia w nazwach plików są używane do przypisania kodu platformy / architektury, na przykład:

➜ cd $GOROOT/src/pkg/math/
➜ ls sqrt*s
sqrt_386.s  sqrt_amd64p32.s  sqrt_amd64.s  sqrt_arm.s

sqrt_386.sbędą odczytywane przez kompilator tylko na procesorach 32-bitowych, sqrt_amd64.sna amd64 itd.

Może to być dowolna z prawidłowych wartości GOOSi / lub GOARCH( ref .

file_windows_amd64.go zostanie skompilowany tylko na win64.

OneOfOne
źródło