Golang - Code-Organisation mit Strukturen, Variablen und Schnittstellen

Ich habe eine Codebasis, wo eine Datei enthält eine Menge Structs, Interfaces und Variables in der gleichen Datei wie Funktionen und ich bin mir nicht sicher, ob ich diese in separate trennen muss Dateien mit anhängendem Dateinamen. So wird zum Beispiel accounts.goaccounts_struct.go und accounts_interface.go mit Struktur bzw. Schnittstelle sein.Golang - Code-Organisation mit Strukturen, Variablen und Schnittstellen

Was wäre ein guter Ansatz für die Dateiorganisation, wenn Sie wachsende Codebasis für Strukturen, Variablen und Schnittstellen haben?

Quelle

2014-10-07 Passionate Developer

Ich denke, das ist zu breit ... aber mein Rat ist, darüber nachzudenken, was Sie wissen, was Ihr Code hat und sehen, ob Sie es in kleinere Stücke teilen können, die weniger Wissen haben. Entscheiden Sie sich nicht willkürlich, alle Strukturen in eine Datei zu schreiben, das ist seltsam. –

In fast allen Fällen (bis auf das eigentliche Frontend von Web-Apps) konnte ich viel Code in eigenständige, wiederverwendbare Pakete aufteilen. Sie sollten sehen, ob das auch mit Ihrem Code möglich ist. –

Ein gutes Modell, um zu überprüfen ist der Quellcode von Go selbst: http://golang.org/src/pkg/

Sie sehen, dass dieser Ansatz (Trennung basierend auf Sprache Elementen wie Struktur, Schnittstelle, ...) wird nie verwendet.

Alle Dateien basieren auf Features, und es ist am besten, ein Proximity-Prinzip zu verwenden, bei dem Sie in der gleichen Datei die Definition dessen finden, was Sie verwenden.
Im Allgemeinen werden diese Funktionen in einer Datei pro Paket gruppiert, mit Ausnahme von großen, in denen ein Paket von vielen Dateien besteht (net, net/http)

Wenn Sie etwas trennen wollen, trennen Sie die Quelle (xxx.go) aus die tests/benchmarks (xxx_test.go)

Quelle

2014-10-07 06:34:28 VonC

Großartig! Ist es am besten, Structs oben oder direkt über func zu platzieren? –

@ PassionateDeveloper Ich bevorzuge oben, definieren die verschiedenen Typen, die ich benutze (struct, func, aliases, ...), vor allem, wenn diese öffentlichen Typ (mit einem Großbuchstaben) sind. Aber für internen privaten Typ (Kleinbuchstaben) definiere ich sie in der Mitte des Codes, kurz bevor Sie sie verwenden. – VonC

@ PassionateDeveloper in jedem Fall, Golint (https://github.com/golang/lint) und gehen Sie Tierarzt sind Ihre Freunde. https://blog.splice.com/going-extra-mile-golint-go-vet/ – VonC

Hier ist mein geistiges Modell für die Gestaltung eines Pakets.

a. Ein Paket sollte eine Idee oder ein Konzept umfassen. http ist ein Konzept, HTTP-Client oder HTTP-Nachricht ist nicht.

b. Eine Datei in einem Paket sollte eine Reihe verwandter Typen umfassen. Eine gute Faustregel ist, dass wenn zwei Dateien den gleichen Satz von Importen teilen, diese zusammengeführt werden. Unter Verwendung des vorhergehenden Beispiels sind http/client.go, http/server.go ein gutes Körnigkeitsniveau

c. Mach keine Datei pro Typ, das ist kein idiomatischer Go.

Quelle

2014-10-07 07:41:43

+1. Ich stimme zu. Das erinnert mich an einige der Ratschläge, die ich zu der Zeit in http://stackoverflow.com/a/14870666/6309 fand. – VonC

Golang - Code-Organisation mit Strukturen, Variablen und Schnittstellen

Antwort

Verwandte Themen