Update golang guidelines (#7457)

docs/golang/implementation.md

@@ -8,16 +8,14 @@ sidebar: general_sidebar
 
 ## API Implementation
 
-TODO
+This section describes guidelines for implementing Azure SDK client libraries. Please note that some of these guidelines are automatically enforced by code generation tools.
 
 ### The Service Client
 
-TODO
+Service clients are the main starting points for developers calling Azure services with the Azure SDK. Each client library should have at least one client, so it’s easy to discover. The guidelines in this section describe patterns for the design of a service client.
 
 #### Service Methods
 
-TODO
-
 ##### Using azcore.Pipeline
 
 Each supported language has an Azure Core library that contains common mechanisms for cross cutting concerns such as configuration and doing HTTP requests.
@@ -40,28 +38,16 @@ The HTTP pipeline consists of a HTTP transport that is wrapped by multiple polic
 
 ##### Using azcore.Policy
 
-TODO
-
 #### Service Method Parameters
 
-TODO
-
 ##### Parameter validation
 
-TODO
-
 ### Supporting Types
 
-TODO
-
 #### Model Types
 
-TODO
-
 ##### Serialization
 
-TODO
-
 #### Constants as Enumerations
 
 {% include requirement/MUST id="golang-enum-type" %} define the enumeration's type to match the type sent/received over-the-wire (string is the most common example).
@@ -91,8 +77,6 @@ func PossibleWidgetColorValues() []WidgetColor {
 
 ## SDK Feature Implementation
 
-TODO
-
 ### Configuration
 
 {% include requirement/MUST id="golang-config-global" %} use relevant global configuration settings either by default or when explicitly requested to by the user, for example by passing in a configuration object to a client constructor.
@@ -160,8 +144,4 @@ Client libraries must support robust logging mechanisms so that the consumer can
 
 ### Telemetry
 
-TODO
-
 ### Testing
-
-TODO

docs/golang/introduction.md

@@ -6,8 +6,6 @@ folder: golang
 sidebar: general_sidebar
 ---
 
-{% include draft.html content="The Go Language guidelines are in DRAFT status" %}
-
 ## Introduction
 
 The Go guidelines are for the benefit of client library designers targeting service applications written in [Go](https://golang.org/).
@@ -113,11 +111,11 @@ func NewWidgetClientFromConnectionString(connectionString string, options *Widge
 
 ##### Service Client Configuration
 
-TODO
-
 ##### Setting the Service Version
 
-TODO
+{% include requirement/MUST id="golang-api-service-client-versioning-highest-api" %} call the highest supported service API version by default.
+
+{% include requirement/MUST id="golang-api-service-client-versioning-select-api-version" %} allow the consumer to explicitly select a supported service API version when instantiating the service client.
 
 ##### Client Immutability
 
@@ -409,36 +407,24 @@ process(w)
 
 ##### Conditional Request Methods
 
-TODO
-
 ##### Hierarchical Clients
 
-TODO
-
 ### Supporting Types
 
 In addition to service client types, Azure SDK APIs provide and use other supporting types as well.
 
 #### Model Types
 
-TODO
-
 ##### Model Type Naming
 
-TODO
-
 #### Constants as Enumerations
 
 {% include requirement/MUST id="golang-const" %} use a `const` for parameters, fields, and return types when values are known.
 
 #### Azure Core Types
 
-TODO
-
 #### Primitive Types
 
-TODO
-
 ### Error Handling
 
 {% include requirement/MUST id="golang-errors" %} return an error if a method fails to perform its intended functionality.  For methods that return multiple items, the error object is always the last item in the return signature.
@@ -491,8 +477,6 @@ When implementing authentication, don't open up the consumer to security holes l
 
 ### Package Naming
 
-TODO (namespaces in other languages)
-
 ### Support for Mocking
 
 One of the key things we want to support is to allow consumers of the package to easily write repeatable unit-tests for their applications without activating a service. This allows them to reliably and quickly test their code without worrying about the vagaries of the underlying service implementation (including, for example, network conditions or service outages). Mocking is also helpful to simulate failures, edge cases, and hard to reproduce situations (for example: does code work on February 29th).
@@ -597,7 +581,9 @@ Packages should strive to avoid taking dependencies on packages outside of the s
 
 ### Native Code
 
-TODO
+Native dependencies introduce lots of complexities and should be avoided.
+
+{% include requirement/SHOULDNOT id="golang-problems-native-dependencies" %} use native dependencies.
 
 ### Doc Comments
 
@@ -617,7 +603,13 @@ As you write your code, *doc it so you never hear about it again.* The less ques
 
 ### README
 
-TODO
+{% include requirement/MUST id="golang-docs-readme" %} have a README.md file in the package root folder.
+
+An example of a good `README.md` file can be found [here](https://github.com/Azure/azure-sdk-for-go/blob/main/sdk/security/keyvault/azkeys/README.md).
+
+{% include requirement/MUST id="golang-docs-readme-consumer" %} optimize the `README.md` for the consumer of the client library.
+
+The contributor guide (`CONTRIBUTING.md`) should be a separate file linked to from the main component `README.md`.
 
 ### Samples