Podczas pisania pojedynczego pakietu, który ma być używany jako polecenie, które jest idiomatyczne: nazwać wszystkie identyfikatory jako prywatne lub nazwać wszystkie identyfikatory jako publiczne?

Question

W Go, nazwy publiczne zaczynają się od dużej litery, a prywatne nazwy zaczynają się od małej litery.

Piszę program, który nie jest biblioteką i jest pojedynczym pakietem. Czy istnieje idiom Go, który określa, czy moje identyfikatory powinny być publiczne czy wszystkie prywatne? Nie planuję używać tego pakietu jako biblioteki lub czegoś, co powinno zostać zaimportowane z innego programu Go.

Nie mogę wymyślić żadnego powodu, dla którego chciałbym mieszankę. To "czuje", że wybór jest właściwy.

---

Nie sądzę dostałem żadnej odpowiedzi beton, ale Nate był najbliżej ze każe mi myśleć o „eksporcie vs zakaz eksportu” zamiast „publicznych i prywatnych”.

To prowadzi mnie do przekonania, że ​​nie eksportowanie niczego jest najlepszym podejściem. W najgorszym przypadku, jeśli w końcu sprowadzę kod z mojej aplikacji do innego pakietu, będę musiał ponownie przemyśleć, co należy wyeksportować, a co nie. Co jest dobrą rzeczą, IMO.

Answer 1

Jeśli próbujesz zmienić swój sposób myślenia, aby był bardziej idiotyczny, przestań myśleć o zmiennych, funkcjach i metodach jako publicznych lub prywatnych. Bardziej trafny termin jest eksportowany lub nie eksportowany. Zdecydowanie bardziej przypomina to C.

Jak powiedzieli inni, eksportowanie naprawdę nie jest potrzebne dla kodu programu użytkowego. Jeśli z przyczyn organizacyjnych zdecydujesz się rozbić swój program na pakiety, możesz użyć podpakietów. W pracy postanowiliśmy to zrobić. Mamy:

projectgopath/src/projectname 
        projectname/subcomponent1 
        projectname/subcomponent2 

Do tej pory bardzo podoba mi się ta struktura. Pomaga w oddzieleniu problemów, ale nie idzie w takim stopniu, aby stworzyć pakiet poza głównym projektem. Intencja jest jasna. Zastosowanie tego podpakietu jest przeznaczone tylko dla tego programu ...

Nowe komendy go-build i go-install wydają się z nim współpracować. Grupujemy komponenty razem w pakietach i eksponujemy tylko niezbędne bity poprzez eksport.

Answer 2

W opisanej sytuacji oba podejścia są jednakowo ważne, więc jest to mniej więcej kwestia osobistych preferencji. W moim przypadku używam identyfikatorów camelCase dla pakietu main, głównie z przyzwyczajenia.

Answer 3

Wiele moich plików rozpoczęło życie w odosobnionych poleceniach i zostały przeniesione do paczek, ponieważ mogły zostać ponownie użyte przez kilka poleceń dotyczących tego samego tematu.

Myślę, że powinieneś zrobić wszystko, czego nie można nazwać z innego źródła (zakładając, że pewnego dnia zrobisz z niego pakiet do importowania) i upublicznić duże funkcje, które można zrozumieć z innych pól (jeśli istnieją) i struktur. gdy są one ortogonalne (mam na myśli, gdy zmiana wartości jednego pola nie narusza spójności wartości struct).