답변:
따라야 할 몇 가지 지침이 있습니다.
_test.go
가 있는 파일 은 go test
도구에 의해서만 컴파일되고 실행됩니다 .name_linux.go
Linux name_amd64.go
에서만 빌드되고 amd64에서만 빌드됩니다. 이것은 //+build amd64
파일 맨 위에 줄 이있는 것과 같습니다.자세한 내용은 도구에 대한 문서를 go build
참조하십시오. https://golang.org/pkg/go/build/
unix
및 .NET 용으로 빌드하려면 어떻게해야합니까 others
? 예를 들어 두 개의 파일을 만들 수 file_windows.go
있고file_others.go
. 잘 작동합니다. 그러나 위해 file_unix.go
그리고 file_others.go
그것은 '작업을 does'n. 8 개의 파일을 만들고 싶지 않습니다 darwin freebsg linux openbsd netbsd dragonfly solaris android
.
JimB가 제공 하는 답변 외에도 일반 파일 이름은 소문자이고 짧으며 어떤 종류의 밑줄이나 공백도 없습니다. 일반적으로 파일 이름은 패키지 이름과 동일한 규칙을 따릅니다. Effective Go 의 패키지 이름 섹션을 참조하십시오 .
좋은 예 는 strconv 패키지 를 참조하십시오 .
mycommandsub1command.go
또는 my_command_sub1command.go
, 그리고 mycommandVO
Go는 패키지 내에서 코드를 구성하는 방법 측면에서 매우 자유 롭습니다. 일반적으로 코드의 가독성과 이해를 향상시키는 것은 무엇이든 상관 없습니다. 이것이 어떻게 수행되는지 배우는 가장 좋은 방법은 마스터를 연구하는 것입니다. 즉, 표준 라이브러리를 살펴 보는 것입니다.
그러나 생각할 수있는 두 가지 규칙이 있습니다. 다른 플랫폼 용으로 컴파일 할 코드를 지정할 때 플랫폼 이름을 접미사로 사용합니다.
mypkg_linux.go // only builds on linux systems
mypkg_windows_amd64.go // only builds on windows 64bit platforms
또한라는 server.go
파일이있는 경우 해당 파일에 대한 테스트는 server_test.go
.
_front
, _writer
또는 _bits
중요한 접미사를 사용하지 않을 것이라고 생각합니다 !
go
도구는 패키지 구조에 대해 매우 제한적입니다 (언어에 대해 제가 가장 좋아하는 것 중 하나입니다). 매우 구체적인 규칙을 선호합니다 (폴더 당 하나의 패키지 [적어도 하나의 예외 포함]), 폴더의 패키지는 폴더와 동일한 이름을 공유합니다 [최소한 하나의 예외 포함], 전체 패키지 가져 오기 경로가의 상대 경로와 일치하고 $GOPATH
, 일부 파일은 이름 형식 등에 따라 다르게 취급 됨)
Go is quite liberal in terms of how you organise your code within a package
. Go는 자유롭지 않고 매우 제한적입니다. 그러나 그것은 좋은 일입니다.
일반적으로 파일 이름의 밑줄은 플랫폼 / 아치 전용 코드를 할당하는 데 사용됩니다. 예를 들면 다음과 같습니다.
➜ cd $GOROOT/src/pkg/math/
➜ ls sqrt*s
sqrt_386.s sqrt_amd64p32.s sqrt_amd64.s sqrt_arm.s
sqrt_386.s
32 비트 프로세서, sqrt_amd64.s
amd64 등 의 컴파일러에서만 읽을 수 있습니다 .
그것의 유효한 값 중 하나 일 수있는 GOOS
및 / 또는 GOARCH
( 심판 .
file_windows_amd64.go
win64에서만 컴파일됩니다.