22
33Please follow coding conventions and guidelines described in the following documents:
44
5+ * [ Go proverbs] ( https://go-proverbs.github.io/ ) - highly recommended read
56* [ CodeReviewComments] ( https://github.com/golang/go/wiki/CodeReviewComments )
67* [ Effective Go] ( https://golang.org/doc/effective_go.html )
8+ * [ How to Write a Git Commit Message] ( https://chris.beams.io/posts/git-commit/ )
79
8- ### Some more conventions
10+ Here's a list of some more specific conventions that are often followed in
11+ the code and will be pointed out in the review process:
912
10- ** General: **
13+ ### General
1114* Keep variable names short for variables that are local to the function.
1215* Do not export a function or variable name outside the package until you
1316 have an external consumer for it.
@@ -16,7 +19,7 @@ Please follow coding conventions and guidelines described in the following docum
1619* Do not use named return values in function definitions. Use only the type.
1720 Exception: defer()'d functions.
1821
19- ** Imports: **
22+ ### Imports
2023
2124We use the following convention for specifying imports:
2225
@@ -48,22 +51,22 @@ import (
4851)
4952```
5053
51- ** Error Handling: **
54+ ### Error Handling
5255
5356* Use variable name ` err ` to denote error variable during a function call.
5457* Reuse the previously declared ` err ` variable as long as it is in scope.
5558 For example, do not use ` errWrite ` or ` errRead ` .
56- * Do not panic().
59+ * Do not panic() for errors that can be bubbled up back to user. Use panic()
60+ only for fatal errors which shouldn't occur.
5761* Do not ignore errors using ` _ ` variable unless you know what you're doing.
5862* Error strings should not start with a capital letter.
5963* If error requires passing of extra information, you can define a new type
60- * Error types should end in ` Error ` and error variables should have ` Err ` as
61- prefix.
64+ * Error types should end with ` Error ` .
6265
63- ** Logging: **
66+ ### Logging
6467
6568* If a function is only invoked as part of a transaction step, always use the
66- transaction's logger.
69+ transaction's logger to ensure propagation of request ID and transaction ID .
6770* The inner-most utility functions should never log. Logging must almost always
6871 be done by the caller on receiving an ` error ` .
6972* Always use log level ` DEBUG ` to provide useful ** diagnostic information** to
@@ -75,3 +78,56 @@ import (
7578 or retry for it and/or is fully recoverable.
7679* Use log level ` ERROR ` when something occurs which is fatal to the operation,
7780 but not to the service or application.
81+
82+ ### Use of goto
83+
84+ Use of ` goto ` is generally frowned up on in higher level languages. We use
85+ ` goto ` statements for the following specific uses:
86+ * Ensure RPCs always return a reply to caller
87+ * Getting out of nested loops
88+ * Auto-generated code
89+
90+ Please use ` defer() ` for ensuring that relevant resource cleanups happen when a
91+ function/method exits. Also use ` defer() ` to revert something on a later
92+ failure.
93+
94+ Developers with significant experience in C should be careful not to
95+ excessively use ` goto ` just to ensure single exit point to a function. Unlike
96+ C programs, there is no memory to be free()d here. Care must be taken when one
97+ ports code from glusterd1 (c) to glusterd2 (go).
98+
99+ ### glusterd2 specific conventions
100+
101+ ** Do not log at the caller of ` txn.* ` methods:**
102+
103+ Certain patterns repeat very often in codebase. For reducing clutter, we have
104+ moved some of the logging at the caller to inside the function. One such
105+ instance are the methods of ` transaction.Context ` interface, which are used at
106+ so many places. They log internally and caller shouldn't be logging. For
107+ example:
108+
109+ ``` go
110+ if err := txn.Ctx .Set (" req" , &req); err != nil {
111+ // do NOT log here
112+ restutils.SendHTTPError (ctx, w, http.StatusInternalServerError , err)
113+ return
114+ }
115+ ```
116+
117+ ** Use log.WithError() to log errors**
118+
119+ It is common pattern to log the error received as a field in the log entry.
120+ Please use ` WithError ` for the same:
121+
122+ Do this:
123+ ``` go
124+ log.WithError (err).WithField (" path" , path).Error (" Failed to delete path" )
125+ ```
126+
127+ Do NOT do this:
128+ ``` go
129+ log.WithFields (log.Fields {
130+ " error" : err,
131+ " path" : path,
132+ }).Error (" Failed to delete path" )
133+ ```
0 commit comments