Wiki.Quizz.vn

User Tools

Site Tools

Trace:
go:architecture:coding_convention

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
go:architecture:coding_convention [2026/01/30 01:53] – [2.5 General Naming Guidelines] phong2018go:architecture:coding_convention [2026/01/30 01:56] (current) – phong2018
Line 46: Line 46:
  
 ===== 2. Naming Conventions ===== ===== 2. Naming Conventions =====
-<anchor naming_conventions /> 
  
 Identifiers starting with an uppercase letter are **exported**.   Identifiers starting with an uppercase letter are **exported**.  
Line 52: Line 51:
  
 ==== 2.1 Package Names ==== ==== 2.1 Package Names ====
-<anchor package_names /> 
  
-  * Use lowercase +  * Use lowercase names 
-  * No CamelCase +  * Do not use CamelCase 
-  * Avoid underscores+  * Avoid underscores unless absolutely necessary
  
 Examples: Examples:
Line 69: Line 67:
  
 ==== 2.2 Variables, Functions, and Methods ==== ==== 2.2 Variables, Functions, and Methods ====
-<anchor variables_functions_and_methods /> 
  
 Use **camelCase** for unexported identifiers. Use **camelCase** for unexported identifiers.
Line 86: Line 83:
  
 ==== 2.3 Structs, Interfaces, and Exported Symbols ==== ==== 2.3 Structs, Interfaces, and Exported Symbols ====
-<anchor structs_interfaces_and_exported_symbols /> 
  
 Use **PascalCase** for exported identifiers. Use **PascalCase** for exported identifiers.
Line 105: Line 101:
  
 ==== 2.4 Constants and Acronyms ==== ==== 2.4 Constants and Acronyms ====
-<anchor constants_and_acronyms /> 
  
 Constants typically use PascalCase. Constants typically use PascalCase.
Line 117: Line 112:
 </code> </code>
  
-Acronyms should be all caps:+Common acronyms should be all caps.
  
 <code go> <code go>
Line 129: Line 124:
  
 ==== 2.5 General Naming Guidelines ==== ==== 2.5 General Naming Guidelines ====
-<anchor general_naming_guidelines /> 
  
-Types+; Types
 : Should be nouns or noun phrases   : Should be nouns or noun phrases  
 : Examples: ``User``, ``Order``, ``UserService`` : Examples: ``User``, ``Order``, ``UserService``
  
-Functions and methods+; Functions and methods
 : Should be verbs or verb phrases   : Should be verbs or verb phrases  
 : Examples: ``CreateUser``, ``ValidateToken`` : Examples: ``CreateUser``, ``ValidateToken``
  
-Interfaces+; Interfaces
 : Should, where appropriate, end with ``-er``   : Should, where appropriate, end with ``-er``  
 : Examples: ``Reader``, ``Writer``, ``UserRepository`` : Examples: ``Reader``, ``Writer``, ``UserRepository``
  
-Short-lived or small scopes+; Short-lived or small scopes
 : Used in loops or short blocks   : Used in loops or short blocks  
 : Examples: ``i``, ``j``, ``n``, ``err`` : Examples: ``i``, ``j``, ``n``, ``err``
  
-Longer-lived or wider scopes+; Longer-lived or wider scopes
 : Should use meaningful names   : Should use meaningful names  
 : Examples: ``userID``, ``ctx``, ``cfg`` : Examples: ``userID``, ``ctx``, ``cfg``
  
 ===== 3. Formatting ===== ===== 3. Formatting =====
-<anchor formatting /> 
  
-  * Always use ``gofmt`` or ``goimports`` +  * Always format code using ``gofmt`` or ``goimports`` 
-  * Tabs for indentation +  * Tabs are used for indentation 
-  * Opening brace on the same line+  * Opening braces must be on the same line
  
 <code go> <code go>
Line 177: Line 170:
  
 ===== 4. Project Structure ===== ===== 4. Project Structure =====
-<anchor project_structure /> 
  
 <code> <code>
Line 197: Line 189:
  
 Guidelines: Guidelines:
-  * ``cmd``: application entry points+  * ``cmd``: application entry points and wiring
   * ``internal``: non-public application code   * ``internal``: non-public application code
-  * ``pkg``: reusable libraries+  * ``pkg``: reusable libraries (if needed)
  
 ===== 5. Functions and Methods ===== ===== 5. Functions and Methods =====
-<anchor functions_and_methods /> 
  
-  * Single responsibility +  * Functions should have a single responsibility 
-  * Avoid >100 lines +  * Avoid very long functions (over ~100 lines) 
-  * Prefer ≤3 parameters+  * Prefer no more than 3 parameters
  
 Options struct example: Options struct example:
Line 217: Line 208:
 } }
  
-func (s *UserService) CreateUser(ctx context.Context, opts CreateUserOptions) (*User, error) {+func (s *UserService) CreateUser( 
 +    ctx context.Context, 
 +    opts CreateUserOptions, 
 +) (*User, error) {
     // ...     // ...
 } }
Line 231: Line 225:
  
 ===== 6. Error Handling ===== ===== 6. Error Handling =====
-<anchor error_handling /> 
  
 Always handle errors immediately. Always handle errors immediately.
Line 242: Line 235:
 </code> </code>
  
-Use ``errors.Is`` / ``errors.As``:+Use ``errors.Is`` and ``errors.As``:
  
 <code go> <code go>
Line 251: Line 244:
  
 Error message rules: Error message rules:
-  * lowercase +  * Start with a lowercase letter 
-  * no period +  * Do not end with a period 
-  * descriptive+  * Be short and descriptive
  
 <code go> <code go>
Line 260: Line 253:
  
 ===== 7. Comments and Documentation ===== ===== 7. Comments and Documentation =====
-<anchor comments_and_documentation /> 
  
 ==== 7.1 Doc Comments ==== ==== 7.1 Doc Comments ====
Line 273: Line 265:
 ==== 7.2 Comment the Why ==== ==== 7.2 Comment the Why ====
  
-Avoid repeating code logic.+Avoid comments that repeat code behavior.
  
 Bad: Bad:
Line 288: Line 280:
  
 ===== 8. Configuration, Context and Logging ===== ===== 8. Configuration, Context and Logging =====
-<anchor configuration_context_and_logging /> 
  
 ==== 8.1 Configuration ==== ==== 8.1 Configuration ====
  
-Centralize configuration in ``internal/config``.+Centralize configuration loading and validation in ``internal/config``.
  
 ==== 8.2 context.Context ==== ==== 8.2 context.Context ====
  
 Rules: Rules:
-  * First parameter +  * Must be the first parameter 
-  * Never stored in structs +  * Must not be stored in struct fields 
-  * Never nil+  * Must never be nil
  
 <code go> <code go>
-func (s *UserService) GetByID(ctx context.Context, id string) (*User, error) {}+func (s *UserService) GetByID( 
 +    ctx context.Context, 
 +    id string, 
 +) (*User, error) { 
 +    // ... 
 +}
 </code> </code>
  
 ==== 8.3 Logging ==== ==== 8.3 Logging ====
  
-Use ``log/slog``.+Use ``log/slog`` for structured logging.
  
 <code go> <code go>
 slog.InfoContext(ctx, "user created", "user_id", userID) slog.InfoContext(ctx, "user created", "user_id", userID)
-slog.ErrorContext(ctx, "failed", "error", err)+slog.ErrorContext(ctx, "failed to create user", "error", err)
 </code> </code>
  
 ===== 9. Batch Coding ===== ===== 9. Batch Coding =====
-<anchor batch_coding /> 
  
-Batch jobs implement:+Batch jobs must implement:
  
 <code go> <code go>
Line 335: Line 330:
  
 ===== 10. Testing ===== ===== 10. Testing =====
-<anchor testing /> 
  
-  * Use ``testing`` package +  * Use the ``testing`` package 
-  * Table-driven tests +  * Prefer table-driven tests 
-  * ``testify/assert`` +  * Use ``testify/assert`` for assertions 
-  * ``gomock`` for mocks+  * Use ``gomock`` for mocking
   * Suppress logs in tests   * Suppress logs in tests
  
Line 346: Line 340:
  
 <code go> <code go>
-func NewPointAddUsecase(repo IAddPointRepository, crm IYappliCRMClient) *PointAddUsecase {}+func NewPointAddUsecase( 
 +    repo IAddPointRepository, 
 +    crm IYappliCRMClient, 
 +) *PointAddUsecase { 
 +    return &PointAddUsecase{ 
 +        repo: repo, 
 +        crm:  crm, 
 +    } 
 +}
 </code> </code>
  
 ===== 11. Tools and Static Analysis ===== ===== 11. Tools and Static Analysis =====
-<anchor tools_and_static_analysis /> 
  
 ==== 11.1 gofmt ==== ==== 11.1 gofmt ====
Line 360: Line 361:
 ==== 11.2 goimports ==== ==== 11.2 goimports ====
  
-Formats code and manages imports.+Formats code and manages imports automatically.
  
 ==== 11.3 go vet ==== ==== 11.3 go vet ====
go/architecture/coding_convention.1769737997.txt.gz · Last modified: by phong2018