Cline

# State Management Standards for Zig This document outlines the recommended standards for managing state in Zig applications. It covers diverse approaches to application state, data flow, and reactivity, all tailored to Zig's unique features and philosophy. The focus is on maintainability, performance, and security, drawing upon the latest Zig versions and ecosystem tools. ## 1. Core Principles ### 1.1 Immutability and Data Flow * **Do This:** Favor immutable data structures and explicit data flow to minimize side effects and improve predictability. This greatly helps reasoning about the program's behavior. * **Don't Do This:** Avoid pervasive mutable global state. It makes debugging and reasoning about the program's behavior extremely difficult. * **Why?:** Immutability reduces the likelihood of unexpected state changes, leading to fewer bugs and easier debugging. Explicit data flow makes the flow of information through the application easier to understand, aiding maintainability. **Example:** """zig const std = @import("std"); const User = struct { id: u32, name: []const u8, }; fn createUser(id: u32, name: []const u8) User { return User{ .id = id, .name = name, // Note: this should typically be a copy, see data ownership section }; } fn updateUser(user: User, newName: []const u8) User { return User{ .id = user.id, .name = newName, // Again, consider a copy for proper ownership }; } pub fn main() !void { var arena = std.heap.ArenaAllocator.init(std.heap.page_allocator); defer arena.deinit(); const allocator = arena.allocator(); const initialUser = createUser(123, "Alice"); const updatedUser = updateUser(initialUser, "Alicia"); std.debug.print("Initial User: id={}, name={s}\n", .{initialUser.id, initialUser.name}); std.debug.print("Updated User: id={}, name={s}\n", .{updatedUser.id, updatedUser.name}); } """ ### 1.2 Explicit Memory Management and Ownership * **Do This:** Understand and manage memory ownership explicitly. Use "allocator" parameters judiciously and carefully consider the lifetime of allocated data. Use "defer" statements to ensure resources are released. * **Don't Do This:** Rely on implicit memory management or ignore potential memory leaks. * **Why?:** Zig's lack of garbage collection requires meticulous memory management. Explicit control reduces the risk of memory leaks and dangling pointers. Zig's powerful comptime features can aid with this (e.g. detecting unused resources). **Example:** """zig const std = @import("std"); pub fn main() !void { var arena = std.heap.ArenaAllocator.init(std.heap.page_allocator); defer arena.deinit(); const allocator = arena.allocator(); const message: []const u8 = "Hello, Zig!"; // Allocate memory for a copy of the message. Important for ownership! const buffer = try allocator.alloc(u8, message.len); defer allocator.free(buffer); @memcpy(buffer, message); // Copy the message into the allocated buffer std.debug.print("Message: {s}\n", .{buffer}); } """ ### 1.3 Error Handling * **Do This:** Use "try" and "catch" for explicit error handling. Leverage Zig's error union types to propagate errors gracefully. * **Don't Do This:** Ignore errors or use panics for non-exceptional situations. * **Why?:** Explicit error handling allows for graceful recovery and prevents unexpected program termination. Error unions enhance code clarity and guarantee that errors are handled appropriately. **Example:** """zig const std = @import("std"); fn readFile(allocator: std.mem.Allocator, filename: []const u8) ![]u8 { const file = try std.fs.openFile(filename, .{}); defer file.close(); const file_size = try file.getEndPos(); const buffer = try allocator.alloc(u8, file_size); try file.readAll(buffer); return buffer; } pub fn main() !void { var arena = std.heap.ArenaAllocator.init(std.heap.page_allocator); defer arena.deinit(); const allocator = arena.allocator(); const filename: []const u8 = "my_file.txt"; const result = readFile(allocator, filename) catch |err| { std.debug.print("Error reading file: {any}\n", .{err}); return; // Exit the function }; if (result != null) { defer allocator.free(result); std.debug.print("File content: {s}\n", .{result}); } } """ ## 2. Architectural Patterns ### 2.1 Data-Oriented Design (DOD) * **Do This:** Organize data in structures of arrays (SoA) format when performance is critical. Separate data from logic to improve cache utilization and SIMD optimization opportunities. * **Don't Do This:** Blindly use object-oriented principles where performance is paramount. Consider the memory layout implications of your data structures. * **Why?:** DOD maximizes data locality, leading to improved cache hit rates and enhanced SIMD parallelization capabilities. Zig's low-level control facilitates effective DOD implementation. **Example:** """zig const std = @import("std"); const MAX_ENTITIES = 1024; const Position = struct { x: [MAX_ENTITIES]f32, y: [MAX_ENTITIES]f32, }; const Velocity = struct { dx: [MAX_ENTITIES]f32, dy: [MAX_ENTITIES]f32, }; var position: Position = undefined; var velocity: Velocity = undefined; fn update(dt: f32) void { for (0..MAX_ENTITIES) |i| { position.x[i] += velocity.dx[i] * dt; position.y[i] += velocity.dy[i] * dt; } } pub fn main() !void { // Initialize data (simplified for demonstration) for (0..MAX_ENTITIES) |i| { position.x[i] = @floatFromInt(i); position.y[i] = @floatFromInt(i); velocity.dx[i] = 1.0; velocity.dy[i] = 0.5; } update(0.1); std.debug.print("Position (first entity): x={}, y={}\n", .{position.x[0], position.y[0]}); } """ ### 2.2 Finite State Machines (FSMs) * **Do This:** Utilize tagged unions or enums to represent distinct states in an FSM. Use switch statements for state transitions. Consider comptime evaluation to validate state transitions at compile time. * **Don't Do This:** Encode state transitions with complex if-else chains or rely on string comparisons. * **Why?:** FSMs provide a structured way to manage complex state transitions, enhancing code readability and maintainability. Tagged unions and switch statements provide type safety and facilitate compile-time checking. **Example:** """zig const std = @import("std"); const State = enum { Idle, Loading, Running, Error, }; var currentState: State = .Idle; fn transitionState(newState: State) void { std.debug.print("Transitioning from {s} to {s}\n", .{ @tagName(currentState), @tagName(newState) }); currentState = newState; } fn processState() void { switch (currentState) { .Idle => { std.debug.print("State: Idle\n", .{}); transitionState(.Loading); }, .Loading => { std.debug.print("State: Loading\n", .{}); // Simulate loading... transitionState(.Running); }, .Running => { std.debug.print("State: Running\n", .{}); // Simulate running... transitionState(.Idle); // loop back to idle }, .Error => { std.debug.print("State: Error\n", .{}); // Handle error... }, } } pub fn main() !void { for (0..3) |_| { processState(); } } """ ### 2.3 Actor Model * **Do This:** Consider the actor model for concurrent and distributed systems. Leverage channels (provided by the standard library or external libraries) for message passing between actors. Each actor should encapsulate its own state. * **Don't Do This:** Use shared mutable state and locks directly for concurrency when the actor model may be more appropriate. * **Why?:** The actor model simplifies concurrent programming by isolating state within actors and facilitating communication through asynchronous message passing. **Example (Conceptual - Zig's concurrency features are still evolving):** """zig // This is a simplified conceptual illustration of the actor model // Zig's concurrency features are under development so this may change in the future. // Placeholder for a channel implementation (using std.async when available, or a custom solution) const Channel = struct { // ... Implementation details hidden ... }; fn createChannel(comptime T: type) Channel { // Placeholder for channel creation logic return Channel{}; } fn send(channel: Channel, message: anytype) void { // Placeholder for sending a message on the channel } fn receive(channel: Channel) anytype { // Placeholder for receiving a message on the channel return undefined; } const ActorA = struct { state: i32, channel: Channel, fn run(self: *@This()) void { while (true) { const message = receive(self.channel); // Process the message and update the state accordingly self.state += 1; // Example update std.debug.print("ActorA - Received message, state = {}\n", .{self.state}); } } }; const ActorB = struct { channel: Channel, fn run(self: *@This()) void { // ... send(self.channel, "Hello from ActorB"); } }; pub fn main() !void { // In a real implementation, would need async/concurrency framework to actually run these concurrently. const channelA = createChannel(anyopaque); // create channel for ActorA const channelB = createChannel(anyopaque); // create channel for ActorB var actorA = ActorA{ .state = 0, .channel = channelA }; var actorB = ActorB{ .channel = channelB }; // Placeholder: Simulate running the actors concurrently (needs suitable Zig concurrency primitives) actorA.run(); actorB.run(); } """ ## 3. State Management Techniques ### 3.1 Function Parameters and Return Values * **Do This:** Pass state as function parameters and return updated state as return values. This promotes pure functions and explicit data flow. * **Don't Do This:** Rely on global variables or mutable function arguments for managing state unless absolutely necessary. * **Why?:** Function parameters and return values establish clear input-output relationships, making functions easier to test and reason about. **Example:** """zig const std = @import("std"); const CounterState = struct { count: u32, }; fn incrementCounter(state: CounterState) CounterState { return CounterState{ .count = state.count + 1 }; } pub fn main() !void { var state = CounterState{ .count = 0 }; state = incrementCounter(state); state = incrementCounter(state); std.debug.print("Counter: {}\n", .{state.count}); // Outputs 2 } """ ### 3.2 Context Objects * **Do This:** Group related state variables into context objects, especially when multiple functions need access to the same set of data. Use "*const" for read-only access and "*" for mutable access. Pass context objects as parameters. * **Don't Do This:** Pass a large number of individual parameters to functions. This reduces readability and increases the risk of errors. * **Why?:** Context objects improve code organization and reduce the number of function parameters. **Example:** """zig const std = @import("std"); const RenderingContext = struct { width: u32, height: u32, clearColor: u32, }; fn render(context: *const RenderingContext) void { std.debug.print("Rendering with width={}, height={}, clearColor={x}\n", .{context.width, context.height, context.clearColor}); } pub fn main() !void { const context = RenderingContext{ .width = 800, .height = 600, .clearColor = 0x0000FF, // Blue }; render(&context); } """ ### 3.3 Dependency Injection * **Do This:** Pass dependencies explicitly as function parameters or through context objects. This promotes testability and modularity. * **Don't Do This:** Hardcode dependencies within functions. * **Why?:** Dependency injection makes it easier to replace dependencies with mock objects for testing or to switch implementations. **Example:** """zig const std = @import("std"); const Logger = struct { log: fn ([]const u8) void, }; fn processData(logger: Logger, data: []const u8) void { logger.log("Processing data..."); logger.log(data); } fn defaultLog(message: []const u8) void { std.debug.print("LOG: {s}\n", .{message}); } pub fn main() !void { const logger = Logger{ .log = defaultLog }; const data: []const u8 = "Some important data"; processData(logger, data); } """ ## 4. Reactivity ### 4.1 Observer Pattern * **Do This:** Implement the observer pattern for decoupling components. Use a central subject that maintains a list of observers and notifies them of state changes. * **Don't Do This:** Tightly couple components that depend on each other's state. * **Why?:** The observer pattern allows components to react to state changes without being directly dependent on the component that owns the state. **Example (Simplified):** """zig const std = @import("std"); const Observer = struct { callback: fn (anyopaque) void, context: anyopaque, }; const Subject = struct { observers: std.ArrayList(Observer), allocator: std.mem.Allocator, fn init(allocator: std.mem.Allocator) Subject { return Subject{ .observers = std.ArrayList(Observer).init(allocator), .allocator = allocator, }; } fn deinit(self: *@This()) void { self.observers.deinit(); } fn attach(self: *@This(), observer: Observer) !void { try self.observers.append(observer); } fn detach(self: *@This(), observer: Observer) void { // ... (Implementation to remove an observer) ... } fn notify(self: *@This(), data: anyopaque) void { for (self.observers.items) |obs| { obs.callback(data); } } }; // Usage: Define a state, a subject, and observers that react to changes. """ ### 4.2 Signals and Slots (Conceptual) * **Do This:** Consider a signals and slots mechanism conceptually for event-driven architectures. This is similar to the observer pattern, but with a more explicit connection between signals (events) and slots (handlers). Create separate signal and slot types for each event. Zig itself doesn't have built-in support, so this would require custom implementation. * **Don't Do This:** Use global event handlers without a clear structure. * **Why?:** Signals and slots offer a structured, type-safe way to manage events and their corresponding handlers. **Example (Conceptual - needs custom implementation):** """zig // Conceptual example of signals and slots // Requires custom implementation in Zig // Define a Signal and Slot type for each specific event type. const ButtonClickSignal = struct { // ... }; const ButtonClickHandler = struct { callback: fn (ButtonClickSignal) void, }; // ... Implementation to connect signals to slots and emit signals ... """ ## 5. Persistent State ### 5.1 Serialization and Deserialization * **Do This:** Use libraries like "zig-json" or "c-ray" for serializing and deserializing state to/from persistent storage. Choose the appropriate format (JSON, MessagePack, etc.) based on requirements. * **Don't Do This:** Manually construct serialization/deserialization logic, especially for complex data structures. * **Why?:** Serialization allows for persisting state to files or databases. Using existing libraries reduces the risk of errors and improves efficiency. **Example (using "zig-json" - example needs confirmation of current library API):** """zig // Note: This example is illustrative and may need adjustments based on the current zig-json API // It's important to consult the library's documentation for accurate usage. const std = @import("std"); const json = @import("json"); // Assuming zig-json is available const User = struct { id: u32, name: []const u8, }; pub fn main() !void { var arena = std.heap.ArenaAllocator.init(std.heap.page_allocator); defer arena.deinit(); const allocator = arena.allocator(); const user = User{ .id = 123, .name = "Alice" }; // Serialize to JSON const serialized = try json.stringify(user, .{ .allocator = allocator }); defer allocator.free(serialized); // Important to free! std.debug.print("Serialized JSON: {s}\n", .{serialized}); // Deserialize from JSON (example, adjust according to zig-json API) const deserialized = try json.parse(User,serialized, .{ .allocator = allocator }); defer allocator.free(deserialized.name); // free any allocations made in deserialization std.debug.print("Deserialized User: id={}, name={s}\n", .{deserialized.id, deserialized.name}); } """ ### 5.2 Databases * **Do This:** Use a database library (e.g., SQLite, PostgreSQL) for persisting complex state that requires querying and indexing. Design your database schema carefully. * **Don't Do This:** Store large amounts of structured data in simple files without using a database. * **Why?:** Databases provide efficient storage, querying, and indexing capabilities for structured data. **Example (Conceptual - requires a Zig database library):** """zig // Conceptual example using a database - Requires a Zig database library // Placeholder - Needs integration with a Zig database library like zig-sqlite // const db = @import("zig-sqlite"); // Hypothetical import // ... (Example to connect to database, create tables, insert and query data) ... """ ## 6. Testing State Management ### 6.1 Unit Tests * **Do This:** Write unit tests to verify the correctness of state transitions and data transformations. Mock dependencies to isolate units of code. * **Don't Do This:** Neglect testing state management logic. * **Why?:** Unit tests ensure that state is managed correctly and prevent regressions. **Example:** """zig const std = @import("std"); const testing = std.testing; const CounterState = struct { count: u32, }; fn incrementCounter(state: CounterState) CounterState { return CounterState{ .count = state.count + 1 }; } test "incrementCounter increments the count" { var state = CounterState{ .count = 0 }; state = incrementCounter(state); try testing.expectEqual(state.count, 1); } """ ### 6.2 Integration Tests * **Do This:** Write integration tests to verify the interaction of different components that manage state. * **Don't Do This:** Only write unit tests and neglect integration testing. * **Why?:** Integration tests ensure that different parts of the system work together correctly. ## 7. Security Considerations * **Do This:** Validate and sanitize user input to prevent state corruption. Use appropriate access control mechanisms to protect sensitive state. * **Don't Do This:** Trust user input implicitly or expose sensitive state without proper protection. * **Why?:** Security measures are essential to protect against malicious attacks that could compromise the application's state. Input validation can prevent issues like buffer overflows or malicious code injection.

# Security Best Practices Standards for Zig This document outlines security best practices for Zig development. It aims to guide developers in writing secure, reliable, and maintainable Zig code, protecting against common vulnerabilities. These standards are tailored for the latest Zig version and emphasize modern approaches. ## 1. Input Validation and Sanitization ### 1.1. General Principles * **Do This:** Validate all external input rigorously, including command-line arguments, environment variables, network data, and file contents. * **Don't Do This:** Trust external input implicitly. Assume it might be malicious or malformed. **Why:** Failure to validate input can lead to vulnerabilities like buffer overflows, format string attacks, and injection flaws. ### 1.2. Validation Techniques * **Do This:** Use explicit checks and assertions to verify that input meets expected criteria. Employ size limits, range checks, and format validation. * **Don't Do

# Deployment and DevOps Standards for Zig This document outlines the coding standards for Deployment and DevOps aspects of Zig projects. It aims to provide clear guidelines for building, testing, deploying, and monitoring Zig applications in production environments. It emphasizes maintainability, performance, security, and modern best practices using the latest Zig features. ## 1. Build Processes and CI/CD Standardizing build processes is crucial for reproducible builds and enabling efficient CI/CD pipelines. ### 1.1. Build System: Zig Build **Standard:** Use the Zig build system ("build.zig") as the primary build tool. Avoid relying on external build systems unless absolutely necessary for integration with existing infrastructure. The "build.zig" file offers a standardized, Zig-native approach. **Why:** The Zig build system is tightly integrated with the compiler, ensuring correctness and enabling advanced optimizations. It also facilitates cross-compilation and dependency management. **Do This:** Construct your build using the "build.zig" file, defining executable, library, and test targets. **Don't Do This:** Rely on Makefiles or shell scripts for core build logic when the Zig build system can handle it. **Example:** """zig // build.zig const std = @import("std"); pub fn build(b: *std.Build) !void { const target = b.standardTargetOptions(.{}); const optimize = b.standardOptimizeOption(.{}); const exe = b.addExecutable(.{ .name = "my-zig-app", .root_source_file = .{ .path = "src/main.zig" }, .target = target, .optimize = optimize, }); b.installArtifact(exe); const run_cmd = b.addRunArtifact(exe); run_cmd.step.dependOn(b.getInstallStep()); if (b.args.len > 0 and std.mem.eql(u8, b.args[0], "test")) { const test_step = b.step("test", "Run tests"); const test_pkg = b.dependency("test_runner", .{ .target = target, .optimize = optimize, }); test_step.dependOn(&test_pkg.step); const test_exe = b.addExecutable(.{ .name = "tests", .root_source_file = .{ .path = "src/test.zig" }, .target = target, .optimize = optimize, }); test_exe.addPackage(test_pkg); const test_run_cmd = b.addRunArtifact(test_exe); test_run_cmd.step.dependOn(&test_step); } } """ **Anti-pattern:** Hardcoding compiler flags or paths within the "build.zig" file instead of using the " Build" API. ### 1.2. Continuous Integration (CI) **Standard:** Integrate your Zig project with a CI system such as GitHub Actions, GitLab CI, or CircleCI. **Why:** CI automates testing, linting, and building on every code commit, ensuring code quality and preventing integration issues. **Do This:** Define a CI pipeline that performs the following steps: * Fetches dependencies. * Builds the application for all supported targets. * Runs all tests. * Lints the code. (See Static Analysis section below) * Potentially deploys to staging environments. **Don't Do This:** Manually building and testing the application before committing. **Example (GitHub Actions):** """yaml # .github/workflows/ci.yml name: CI on: push: branches: [ "main" ] pull_request: branches: [ "main" ] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Set up Zig uses: actions/setup-zig@v1 with: zig-version: 0.12.0-dev.3157+79ad33f92 # Replace with the desired version. - name: Build run: zig build - name: Run Tests run: zig build test """ **Technology-Specific Detail:** The "actions/setup-zig" action simplifies installing specific Zig versions within GitHub Actions. Specify the desired Zig version explicitly. ### 1.3. Continuous Deployment (CD) **Standard:** Automate the deployment process to staging and production environments. **Why:** CD reduces the risk of human error, accelerates release cycles, and ensures consistent deployments. **Do This:** Use tools like Ansible, Terraform, or Docker to manage infrastructure and deployments. Implement blue/green deployments or rolling updates for minimal downtime. **Don't Do This:** Manually deploying applications to production. **Example (using Docker):** """dockerfile # Dockerfile FROM ubuntu:latest RUN apt-get update && apt-get install -y zig curl WORKDIR /app COPY . . RUN zig build -Doptimize=ReleaseSafe EXPOSE 8080 CMD ["./zig-out/bin/my-zig-app"] """ **Example (Docker Compose):** """yaml #docker-compose.yml version: "3.9" services: app: build: . ports: - "8080:8080" restart: always """ **Considerations:** Use multi-stage builds to keep your final Docker image small. Compile the Zig application in one stage and copy only the executable to the final image. Use ".dockerignore" files to exclude unnecessary files. **Technology-Specific Detail**: When building docker images of your applications, use the "ReleaseFast" or "ReleaseSmall" modes for optimal performance and size. ### 1.4. Cross-Compilation **Standard:** Explicitly consider cross-compilation during the build process, especially if targeting multiple platforms. **Why:** Zig excels at cross-compilation, allowing you to build binaries for different operating systems and architectures from a single development environment. **Do This:** Leverage the "-target" flag in the "zig build" command or the "target" field in the "build.zig" file to specify the target platform. **Don't Do This:** Assume that your application will only run on the platform you are developing on. **Example:** """bash zig build -Dtarget=x86_64-linux-gnu """ **Technology-Specific Detail:** Ensure that you have the necessary dependencies installed for the target platform (e.g., glibc for Linux). Zig usually handles this automatically via its built-in standard library, but be aware of external dependencies. ### 1.5. Version Control **Standard:** Use Git for version control. Tag releases and follow semantic versioning. **Why:** Provides a clear history of changes and facilitates collaboration. Versioning ensures compatibility and aids in dependency management. **Do This:** Tag each release using semantic versioning (e.g., "v1.2.3"). Use descriptive commit messages. **Don't Do This:** Committing directly to the "main" branch without code review. ## 2. Production Considerations Deploying Zig applications to production requires careful attention to performance, security, and monitoring. ### 2.1. Optimization **Standard:** Compile your application with optimization flags for production deployments. **Why:** Optimization flags significantly improve performance and reduce binary size. **Do This:** Use the "-Doptimize=ReleaseSafe", "-Doptimize=ReleaseFast", or "-Doptimize=ReleaseSmall" flags during compilation. Choose the appropriate level based on the performance requirements and binary size constraints. "ReleaseSafe" sacrifices some performance guarantees for safety, while "ReleaseFast" and "ReleaseSmall" provide maximum performance and minimal binary size, respectively, at the expense of potential safety checks. **Don't Do This:** Deploying applications compiled in debug mode to production. **Example:** """bash zig build -Doptimize=ReleaseFast """ ### 2.2. Logging **Standard:** Implement structured logging to facilitate debugging and monitoring in production. **Why:** Structured logs are easily parsed and analyzed, enabling efficient troubleshooting and performance analysis. **Do This:** Use a logging library like "std.log" or a custom logging solution. Log messages at appropriate levels (e.g., "debug", "info", "warn", "error"). Include relevant context in log messages (e.g., request ID, user ID). Structure your logs so they are easily machine-readable (e.g., JSON format). """zig const std = @import("std"); pub fn main() anyerror!void { std.log.info("Application starting...", .{}); const result = some_function() catch |err| { std.log.err("Error in some_function: {any}", .{err}); return err; }; std.log.debug("Result: {any}", .{result}); std.log.info("Application exiting...", .{}); } fn some_function() !i32 { return 42; } """ **Anti-pattern:** Using "print" or "stdout" for logging in production. Relying solely on unstructured text logs. **Technology-Specific Detail:** Consider using a logging aggregator like Fluentd or Logstash to collect and analyze logs from multiple instances. ### 2.3. Monitoring and Metrics **Standard:** Collect and monitor key metrics to track application health and performance. **Why:** Metrics provide insights into application behavior and help identify potential problems before they impact users. **Do This:** Expose metrics using a standardized format like Prometheus Exporter. Monitor CPU usage, memory usage, request latency, error rates, and other relevant metrics. Set up alerts to notify you of critical issues. """zig const std = @import("std"); const prometheus = @import("prometheus"); pub fn main() !void { // Initialize Prometheus client var registry = prometheus.Registry.init(); var http_server = std.http.Server.init(); // Define your metrics const request_counter = registry.makeCounter("http_requests_total", "Total number of HTTP requests."); const request_latency = registry.makeHistogram("http_request_duration_seconds", "HTTP request latency in seconds."); // Simulate a request const start_time = std.time.nanoTimestamp(); // ... handle the request ... const end_time = std.time.nanoTimestamp(); const duration = @intToFloat(f64, end_time - start_time) / 1_000_000_000.0; // Convert nanoseconds to seconds // Update metrics request_counter.inc(); request_latency.observe(duration); // Expose metrics endpoint http_server.route("/metrics", &registry.handlerFn); try http_server.listen("0.0.0.0:8080"); defer http_server.deinit(); defer registry.deinit(); } """ **Don't Do This:** Ignoring application metrics. Failing to set up alerts for critical issues. **Technology-Specific Detail:** Consider using a monitoring tool like Prometheus, Grafana, or Datadog to visualize and analyze metrics. ### 2.4. Error Handling **Standard:** Implement robust error handling to prevent crashes and provide informative error messages. **Why:** Proper error handling ensures application stability and helps diagnose issues quickly. **Do This:** Use "catch" blocks to handle errors. Log error messages with sufficient context. Consider using custom error types for specific error scenarios. Utilize "defer" and "errdefer" blocks for resource cleanup. **Don't Do This:** Ignoring errors or panicking in production code. Exposing sensitive information in error messages. **Example:** """zig const std = @import("std"); pub fn main() anyerror!void { const file = try std.fs.openFile("myfile.txt", .{ .read = true }); defer file.close(); const contents = try file.readAllAlloc(std.heap.page_allocator); defer std.heap.page_allocator.free(contents); std.debug.print("Contents of file: {s}\n", .{contents}); } """ In this example any error opening, reading or allocating will result in a panic, which is appropriate for a simple program and debug builds. In production "catch" should be used: """zig const std = @import("std"); pub fn main() anyerror!void { const file = std.fs.openFile("myfile.txt", .{ .read = true }) catch |err| { std.log.err("Unable to open file due to {any}", .{err}); return err; }; defer file.close(); const contents = file.readAllAlloc(std.heap.page_allocator) catch |err| { std.log.err("Unable to read file due to {any}", .{err}); return err; }; defer std.heap.page_allocator.free(contents); std.debug.print("Contents of file: {s}\n", .{contents}); } """ ### 2.5. Security **Standard:** Implement security best practices to protect your application from attacks. **Why:** Security vulnerabilities can lead to data breaches, service disruptions, and reputational damage. **Do This:** * Sanitize user input to prevent injection attacks. * Use HTTPS to encrypt communication between the client and server. * Store passwords securely using strong hashing algorithms. * Regularly update dependencies to patch security vulnerabilities. * Implement access control to restrict access to sensitive resources. * Use memory-safe practices to prevent buffer overflows and other memory-related errors. Zig helps a lot here, but you need to be conscious of safety builds, integer overflows and pointer arithmetic . **Don't Do This:** Storing sensitive information in plain text. Exposing unnecessary endpoints. **Technology-Specific Detail:** Leverage Zig's memory safety features to prevent memory errors. Use tools like static analyzers (see below) to identify potential vulnerabilities. ## 3. Static Analysis and Linting **Standard:** Use static analysis tools and linters to improve code quality and identify potential issues early in the development cycle. **Why:** Static analysis can detect errors, enforce coding standards, and improve code maintainability. **Do This:** * Integrate a linter into your CI pipeline (e.g., "zig fmt" to enforce code formatting). * Use static analysis tools like "zig build-obj --check" to detect potential issues. **Don't Do This:** Ignoring linter warnings or static analysis errors. **Example (using "zig fmt"):** """bash zig fmt src/main.zig """ **Technology-Specific Detail:** Explore community-developed linters and static analysis tools that may provide more comprehensive checks. ## 4. Configuration Management **Standard:** Externalize configuration data from the application code. **Why:** Allows you to change application behavior without recompiling, making deployments more flexible and manageable. **Do This:** Use environment variables, configuration files (e.g., YAML, JSON), or a dedicated configuration management service (e.g., Consul, etcd) to store configuration data. **Don't Do This:** Hardcoding configuration values in the application code. **Example (using environment variables):** """zig const std = @import("std"); pub fn main() anyerror!void { const port = std.os.getenv("PORT") orelse "8080"; std.debug.print("Listening on port: {s}\n", .{port}); } """ ## 5. Dependency Management **Standard:** Employ Zig's package manager for managing dependencies. Use specific version constraints to ensure reproducible builds. **Why:** Ensures consistent builds and facilitates collaboration. Explicit versioning avoids unexpected behavior from dependency updates. **Do This:** Declare dependencies in the "build.zig.zon" file (or the "dependencies" section of the "build.zig" file, for simpler projects). Specify version constraints that allow for bug fixes but prevent breaking changes (e.g., "~>1.2.0"). Run "zig build" to fetch dependencies. Use "zig fetch" to prefetch dependencies for offline builds. **Don't Do This:** Manually downloading and including dependencies. Failing to specify version constraints. """zig // build.zig.zon .{ .name = "my-zig-app", .version = "0.1.0", .dependencies = .{ .http = .{ .url = "https://github.com/lunatic-solutions/http/archive/v0.9.1.tar.gz", .hash = "1220a388ccefb27eef8a223404fc959f6efcf1afc28043648ffbcfb7f8096558f95d", }, }, .paths = .{ .root = ".", }, } """ ## 6. Tooling and Automation **Standard:** Automate repetitive tasks using scripting and tooling. **Why:** Automation reduces the risk of human error and improves efficiency. **Do This:** Use shell scripts, Zig scripts, or dedicated automation tools (e.g., Ansible, Terraform) to automate tasks such as building, testing, deploying, and monitoring. **Don't Do This:** Manually performing repetitive tasks. ## Conclusion By adhering to these Deployment and DevOps standards, Zig developers can build and deploy robust, scalable, and secure applications. This document guides the development process and serves as context for AI coding assistants, ensuring consistent and high-quality code. Regularly review and update these standards to reflect the latest Zig features and best practices.

# Testing Methodologies Standards for Zig This document outlines the recommended testing methodologies and best practices for Zig projects. Adhering to these guidelines will lead to more robust, maintainable, and reliable software. ## 1. Testing Pyramid and Levels ### 1.1. General Testing Strategy * **Do This:** Follow the testing pyramid concept. Prioritize unit tests, have fewer integration tests, and a minimal number of end-to-end tests. * **Don't Do This:** Rely heavily on end-to-end tests while neglecting unit and integration tests. This approach leads to slow feedback cycles and makes debugging difficult. **Why:** The testing pyramid ensures that the majority of your test cases are fast, isolated, and cheap to run (unit tests), while still providing confidence in the system's overall functionality (integration and end-to-end tests). ### 1.2. Unit Testing * **Do This:** Write focused unit tests that verify the behavior of individual functions, methods, or modules in isolation. * **Don't Do This:** Create unit tests that depend on external systems, databases, or network connections. Use mocks or stubs to isolate the unit under test. **Why:** Unit tests should provide rapid feedback on the correctness of your code. Dependencies on external systems can make tests slow, flaky, and difficult to maintain. **Example:** Testing a simple function. """zig const std = @import("std"); const assert = std.debug.assert; const adder = struct { pub fn add(a: i32, b: i32) i32 { return a + b; } }; test "test adder.add" { assert(adder.add(2, 3) == 5); assert(adder.add(-1, 1) == 0); assert(adder.add(-5, -5) == -10); } """ ### 1.3. Integration Testing * **Do This:** Use integration tests to verify the interaction between different modules or components within your system. * **Don't Do This:** Attempt to test the entire system at once. Focus on specific, important interactions. **Why:** Integration tests ensure that individual modules work correctly together. These tests catch issues that might not be apparent from unit tests alone. **Example:** Testing interaction between two modules. For illustrative purpose, assume both "adder" and "multiplier" are modules defined in separate files. """zig const std = @import("std"); const assert = std.debug.assert; const adder = @import("adder"); const multiplier = @import("multiplier"); test "test adder and multiplier integration" { const sum = adder.add(2, 3); const product = multiplier.multiply(sum, 4); assert(product == 20); } """ ### 1.4. End-to-End (E2E) Testing * **Do This:** Limit E2E tests to critical user flows and scenarios that validate the overall system functionality. * **Don't Do This:** Overuse E2E tests. They are slow, brittle, and expensive to maintain. **Why:** E2E tests simulate real user interaction with the system. Use them sparingly to ensure that the most critical functionality is working as expected. ## 2. Test-Driven Development (TDD) ### 2.1. Red-Green-Refactor * **Do This:** Follow the Red-Green-Refactor cycle: 1. Write a failing test (Red). 2. Write the minimum amount of code to make the test pass (Green). 3. Refactor the code to improve its structure, readability, and maintainability. * **Don't Do This:** Write code without tests or write tests after the code is already complete. **Why:** TDD leads to better code design, reduces defects, and provides comprehensive test coverage. **Example:** TDD implementation 1. **Red (Failing Test):** """zig const std = @import("std"); const assert = std.debug.assert; const StringReverser = struct { // Placeholder - To be implemented }; test "test string reversal" { var reverser = StringReverser{}; const reversed = reverser.reverse("hello"); assert(std.mem.eql(u8, reversed, "olleh")); } """ 2. **Green (Passing Test):** """zig const std = @import("std"); const assert = std.debug.assert; const StringReverser = struct { pub fn reverse(self: *StringReverser, input: []const u8) []const u8 { var reversed = std.ArrayList(u8).init(std.heap.page_allocator); // Use ArrayList for dynamic allocation // Reverse the string for (input) |c| { errdefer reversed.deinit(); try reversed.insert(0, c); } return reversed.items(); } }; test "test string reversal" { var reverser = StringReverser{}; const reversed = reverser.reverse("hello"); defer std.heap.page_allocator.free(reversed); // Important: Free the memory assert(std.mem.eql(u8, reversed , "olleh")); } """ 3. **Refactor:** (Further refactoring, such as error handling and optimizations, can be applied here.) ### 2.2. Boundary Conditions * **Do This:** Test boundary conditions (e.g., empty strings, maximum values, minimum values) to ensure that your code handles edge cases correctly. * **Don't Do This:** Only test typical scenarios. Neglecting boundary conditions can lead to unexpected errors. **Why:** Boundary conditions are often where bugs lurk. Testing these cases explicitly improves the robustness of your code. **Example:** Boundary conditions for a function calculating the average of an array. """zig const std = @import("std"); const assert = std.debug.assert; const calculator = struct { pub fn average(items: []const f64) ?f64 { if (items.len == 0) { return null; // Handle empty array } var sum: f64 = 0; for (items) |item| { sum += item; } return sum / @floatFromInt(items.len); } }; test "average of empty array" { assert(calculator.average([]const f64{}) == null); } test "average of single element array" { const arr = [_]f64{5.0}; const avgOpt = calculator.average(&arr); assert(avgOpt != null); assert(avgOpt.? == 5.0); } """ ## 3. Mocking and Stubbing ### 3.1. Isolating Units * **Do This:** Use mocking and stubbing to isolate the unit under test from its dependencies. * **Don't Do This:** Directly use real dependencies in your unit tests. **Why:** Mocking and stubbing ensure that your unit tests are fast, predictable, and focused on the behavior of the unit itself. ### 3.2. Test Doubles * **Do This:** Use test doubles (mocks, stubs, spies) to control the behavior of dependencies and verify interactions. Zig does not have built-in mocking frameworks, so custom implementations or community libraries (if available) are used. * **Don't Do This:** Create overly complex mocks that replicate the entire behavior of the dependency. Focus on the specific interactions that are relevant to the test. **Why:** Test doubles allow you to simulate different scenarios and verify that the unit under test interacts with its dependencies as expected. **Example:** Custom stub implementation in Zig. """zig const std = @import("std"); const assert = std.debug.assert; // Assume this is an external service we don't want to call directly in tests. const ExternalService = struct { pub fn getData(self: *ExternalService, id: i32) ![]const u8 { _ = id; // Suppress unused variable warning // In a real implementation, this would make a network request or use a database. return error.NotImplemented; } }; // Stub for the ExternalService const StubExternalService = struct { data: []const u8, pub fn getData(self: *StubExternalService, id: i32) ![]const u8 { _ = id; return self.data; } }; const DataProcessor = struct { service: *ExternalService, pub fn processData(self: *DataProcessor, id: i32) ![]const u8 { const data = try self.service.getData(id); // Some kind of data processing... return data; } }; test "test DataProcessor with StubExternalService" { const allocator = std.heap.page_allocator; var stub_service = StubExternalService{ .data = "stubbed data" }; var processor = DataProcessor{ .service = &stub_service }; const processed_data = try processor.processData(123); defer allocator.free(processed_data); assert(std.mem.eql(u8, processed_data, "stubbed data")); } """ ## 4. Asynchronous and Concurrent Testing ### 4.1. Dealing with Async Code * **Do This:** Manage asynchronous operations and concurrency explicitly in tests. Use mechanisms to synchronize test execution with the completion of async tasks using a testing frameworks (if created) or manual synchronization with atomics and mutexes. * **Don't Do This:** Rely on timing or "std.time.sleep" to "wait" for asynchronous operations. Such approach leads to flaky and unreliable tests. **Why:** Asynchronous code presents unique challenges for testing. Proper synchronization is crucial to ensure that tests are deterministic and reliable. ### 4.2. Synchronization Primitives * **Do This:** Use synchronization primitives such as "std.Thread.Mutex" and "std.Thread.Semaphore" when testing concurrent code. * **Don't Do This:** Forget proper teardown of threads and disposal of synchronisation objects causing memory leaks or hangs. **Why:** Synchronisation primitive are critical to correctly test concurrent code. **Example:** Testing basic async operation with manual synchronization (without a testing framework). """zig const std = @import("std"); const assert = std.debug.assert; // A function that simulates an asynchronous operation with a channel fn asyncOperationWithChannel(tx: chan i32, result: i32) void { std.time.sleep(10 * std.time.millisecond); // Simulate some work tx <- result; } // A simple channel type const chan = @Vector(1, i32); test "test async operation with channel" { var channel: chan i32 = undefined; var thread: std.Thread = undefined; var result: i32 = undefined; // Launch the async operation in a separate thread thread = std.Thread.spawn(.{}, asyncOperationWithChannel, .{ &channel, 42 }) catch unreachable; // Read the result from the channel result = <-channel; // Wait for the thread to finish thread.join(); assert(result == 42); } """ ## 5. Error Handling and Failure Injection ### 5.1. Testing Error Paths * **Do This:** Explicitly test error paths and ensure that your code handles errors gracefully. * **Don't Do This:** Only test the happy path. Neglecting error handling can lead to unexpected crashes and data corruption. **Why:** Robust error handling is essential for reliable software. Testing error paths ensures that your code can recover from failures gracefully. ### 5.2. Failure Injection * **Do This:** Use failure injection techniques (e.g., simulating network outages, disk errors, or memory allocation failures) to test the resilience of your code. * **Don't Do This:**. Assume that external resources and dependencies will always be available. **Why:** Failure injection helps you identify and fix potential weaknesses in your code's error handling logic. **Example:** Injecting failure by intercepting allocation requests and returning "error.OutOfMemory". Note: this requires advanced Zig knowledge and should be used with caution. """zig const std = @import("std"); const assert = std.debug.assert; // Custom allocator that can simulate out-of-memory errors pub const FailingAllocator = struct { pub fn alloc(self: *@This(), len: usize, alignment: u29) ?[*]u8 { _ = alignment; // Suppress unused variable warning. if (self.should_fail) { self.should_fail = false; // Only fail once return null; } return self.backing_allocator.alloc(len); } pub fn free(self: *@This(), ptr: [*]u8, len: usize, alignment: u29) void { _ = alignment; // Suppress unused variable warning. self.backing_allocator.free(ptr, len); } backing_allocator: std.mem.Allocator, should_fail: bool, }; test "test with failing allocator" { var backing_allocator = std.heap.page_allocator; var failing_allocator = FailingAllocator{ .backing_allocator = backing_allocator, .should_fail = true, }; // Try to allocate some memory using the failing allocator const result = failing_allocator.alloc(1024, 1); assert(result == null); // Now try again, it should succeed failing_allocator.should_fail = false; const result2 = failing_allocator.alloc(1024,1) catch unreachable; defer failing_allocator.free(result2, 1024, 1); assert(result2 != null); } """ ## 6. Code Coverage ### 6.1. Measuring Coverage * **Do This:** Use code coverage tools to measure the percentage of your code that is executed by tests. Tools like "llvm-cov" can be integrated into the build system. * **Don't Do This:** Rely solely on code coverage metrics to assess the quality of your tests. High coverage does not necessarily mean that your tests are effective. **Why:** Code coverage provides insights into the areas of your code that are not being adequately tested. ### 6.2. Interpreting Results * **Do This:** Use code coverage reports to identify gaps in your test suite and write additional tests to cover those areas. * **Don't Do This:** Aim for 100% code coverage at all costs. Focus on testing the most critical and complex parts of your system. **Why:** Code coverage helps you prioritize your testing efforts and improve the overall quality of your code. ## 7. Property Based Testing ### 7.1 Using Generators * **Do This**: Use property-based testing frameworks to generate various input values to test different scenarios. Since there are no mature frameworks for zig, one might need to be built. * **Don't Do This**: Assume that providing a few fixed parameters covers the entire range of possibilities for the code being tested. Property-based testing helps discover unexpected edge cases. **Why:** Property-based testing automatically generates a large number of test cases based on predefined properties, which can uncover edge cases and unexpected behavior. **Example**: A rough example of property-based testing implementation(concept). """zig const std = @import("std"); const testing = @import("testing"); // Hypothetical testing framework const assert = std.debug.assert; /// Function to be tested fn add(a: i32, b: i32) i32 { return a + b; } test "add function always yields correct sum" { testing.property("Addition is commutative", struct { fn generate() testing.TestCase { const a = testing.random.int(i32); const b = testing.random.int(i32); return .{ .input = .{ .a = a, .b = b } }; } fn check(case: testing.TestCase) bool { const a = case.input.a; const b = case.input.b; return add(a,b) == add(b,a); } }); testing.property("Addition result is always larger", struct { fn generate() testing.TestCase { const a = testing.random.int(i32); const b = testing.random.int(i32); return .{ .input = .{ .a = a, .b = b } }; } fn check(case: testing.TestCase) bool { const a = case.input.a; const b = case.input.b; return add(a,b) >= a; } }); } """ This example demonstrates how using a purely hypothetical library, you'd define properties about the "add" function, such as commutativity. ## 8. Continuous Integration ### 8.1. Automated Testing * **Do This:** Integrate your tests into a CI/CD pipeline to automatically run tests on every commit or pull request. * **Don't Do This:** Rely on manual testing. Automated testing ensures that defects are detected early and often. **Why:** Continuous integration helps you maintain a high level of code quality and prevent regressions. ### 8.2. Reporting * **Do This:** Generate test reports and dashboards to track test results, code coverage, and other relevant metrics. * **Don't Do This:** Ignore failing tests. Failing tests should be addressed immediately to prevent further issues. **Why:** Test reports and dashboards provide visibility into the health of your codebase and help you identify areas that need improvement. ## 9. Performance Testing ### 9.1 Proper Tooling * **Do This:** Utilise Zig's built-in features for benchmarking code and conduct performance testing. Tools such as "zig build test -Drelease-safe" or "zig build test -Drelease-fast" with cycle counters allows you to accurately track the execution time of critical section of code. * **Don't Do This:** Trust premature optimisation results without confirming the true bottleneck in the system. **Why:** Performance testing is essential for optimising and ensuring that code is as efficient as possible. **Example**: """zig const std = @import("std"); const assert = std.debug.assert; // Function to benchmark fn calculateSum(n: usize) usize { var sum: usize = 0; for (0..n) |i| { sum += i; } return sum; } test "benchmark calculateSum" { const start = std.time.nanoTimestamp(); const result = calculateSum(1000000); // 1 million const end = std.time.nanoTimestamp(); const duration = end - start; std.debug.print("calculateSum(1000000) = {}\n", .{result}); std.debug.print("Time taken: {} ns\n", .{duration}); assert(result == 499999500000); // Verify correctness } """ ## 10. Security Testing ### 10.1 Common Vulnerabilities * **Do This:** Check for common vulnerability types, such as buffer overflows, use after free, and format string bugs. Use static analysis tools and fuzzing approaches to find security vulnerabilities. * **Don't Do This:** Assume that the code is secure without conducting security specific tests. ### 10.2 Fuzzing * **Do This:** For security sensitive code, integrating a fuzzer such as "z fuzz" will help uncover inputs that may crash or cause vulnerability within the system. * **Don't Do This:** Avoid fuzzing as part of the development lifecycle. **Example**: (Hypothetical usage with a future "z fuzz" tool) """zig // Example code to be fuzzed (potentially vulnerable to buffer overflow) fn copyString(dest: []u8, source: []const u8) void { for (source, 0..) |char, i| { dest[i] = char; // Potential buffer overflow if source is larger than dest } } // Fuzz test function export fn zig_fuzz(data: []const u8) void { var buffer: [10]u8 = undefined; // Perform test copy - will cause crash if overflow copyString(&buffer, data); } """ Running "z fuzz" on this example, the tool would generate various random inputs for the data parameter and attempt to find inputs that cause the "copyString" function to write past the end of dest (buffer), flagging a buffer overflow.

# Code Style and Conventions Standards for Zig This document outlines the code style and conventions standards for the Zig programming language. Adhering to these standards will ensure consistency, readability, and maintainability across all projects. These guidelines are designed for use with the latest version of Zig and promote modern best practices. ## 1. Formatting Consistent formatting is crucial for code readability. Zig benefits from a relatively simple syntax which, combined with clear formatting, results in highly readable code. ### 1.1. Indentation * **Standard:** Use 4 spaces for indentation. Tabs are strongly discouraged. * **Why:** Spaces provide consistent rendering across different editors and environments. Tabs can be interpreted differently based on editor settings. * **Do This:** """zig fn add(a: i32, b: i32) i32 { return a + b; } """ * **Don't Do This:** """zig fn add(a: i32, b: i32) i32 { return a + b; } """ ### 1.2. Line Length * **Standard:** Limit lines to a maximum of 120 characters. * **Why:** This improves readability, especially on smaller screens or when multiple files are open side-by-side. * **Do This:** Break long lines into smaller, more manageable segments. Use parentheses or operators to suggest continuation. """zig const very_long_variable_name = some_function_that_returns_something( argument1, argument2, argument3, ); """ * **Don't Do This:** """zig const very_long_variable_name = some_function_that_returns_something(argument1, argument2, argument3); """ ### 1.3. Vertical Spacing * **Standard:** * Use blank lines to separate logical blocks of code within functions. * Add a blank line between functions. * Avoid excessive blank lines. * **Why:** Vertical spacing improves readability by visually separating sections of code. * **Do This:** """zig fn processData(data: []const u8) !void { // Initialize variables var sum: u64 = 0; // Iterate through the data and calculate the sum. for (data) |value| { sum += @as(u64, value); } // Log the result std.debug.print("Sum: {}\n", .{sum}); } fn main() !void { const data = [_]u8{1, 2, 3, 4, 5}; try processData(&data); } """ * **Don't Do This:** """zig fn processData(data: []const u8) !void {var sum: u64 = 0;for (data) |value| {sum += @as(u64, value);}std.debug.print("Sum: {}\n", .{sum});}fn main() !void {const data = [_]u8{1, 2, 3, 4, 5};try processData(&data);} """ ### 1.4. Whitespace * **Standard:** * Use spaces around operators (e.g., "=", "+", "-", "*", "/"). * Use spaces after commas in argument lists. * Do not use spaces inside parentheses. * Do not use spaces before a colon in field declarations. * **Why:** Consistent whitespace enhances readability and prevents visual clutter. * **Do This:** """zig const result = a + b * c; fn myFunction(arg1: i32, arg2: f32) void {} const my_struct = struct { x: i32, y: f32 }; """ * **Don't Do This:** """zig const result=a+b*c; fn myFunction(arg1:i32,arg2:f32) void {} const my_struct = struct { x : i32, y : f32 }; """ ### 1.5. Braces * **Standard:** Opening braces should be on the same line as the statement. * **Why:** Consistent brace placement contributes to a uniform code appearance. * **Do This:** """zig fn myFunction() void { // Code goes here } if (condition) { // Code goes here } """ * **Don't Do This:** """zig fn myFunction() { // Code goes here } if (condition) { // Code goes here } """ ## 2. Naming Conventions Consistent naming conventions improve code understanding and reduce ambiguity. ### 2.1. General Naming Rules * **Standard:** * Use "snake_case" for variables, function names, and struct/enum fields. * Use "PascalCase" for struct, enum, union, and type names. * Use "UPPER_SNAKE_CASE" for constants. * Use descriptive and meaningful names. Avoid single-letter variable names except for loop counters (e.g., "i", "j", "k"). * **Why:** These conventions help distinguish between different kinds of identifiers and make the code easier to read and understand. ### 2.2. Variable Names * **Standard:** Use descriptive nouns or noun phrases. * **Do This:** """zig const user_name: []const u8 = "John Doe"; var current_index: usize = 0; """ * **Don't Do This:** """zig const x: []const u8 = "John Doe"; var i: usize = 0; // Acceptable as a loop counter. """ ### 2.3. Function Names * **Standard:** Use descriptive verbs or verb phrases. * **Do This:** """zig fn calculateArea(width: f32, height: f32) f32 { return width * height; } fn processInput(input: []const u8) !void { // ... } """ * **Don't Do This:** """zig fn area(width: f32, height: f32) f32 { return width * height; } fn foo(input: []const u8) !void { // ... } """ ### 2.4. Type Names (Structs, Enums, Unions) * **Standard:** Use descriptive nouns. * **Do This:** """zig const User = struct { name: []const u8, age: u32, }; const Color = enum { Red, Green, Blue, }; """ * **Don't Do This:** """zig const MyType = struct { name: []const u8, age: u32, }; const Options = enum { A, B, C, }; """ ### 2.5. Constant Names * **Standard:** Use "UPPER_SNAKE_CASE" for constants. * **Do This:** """zig const MAX_VALUE: i32 = 1000; const DEFAULT_NAME: []const u8 = "Anonymous"; """ * **Don't Do This:** """zig const maxValue: i32 = 1000; const defaultName: []const u8 = "Anonymous"; """ ### 2.6. Enum Values * **Standard:** PascalCase * **Do This:** """zig const HttpMethod = enum { Get, Post, Put, Delete, }; """ * **Don't Do This:** """zig const HttpMethod = enum { get, post, put, delete, }; """ ## 3. Stylistic Consistency Consistent style enhances code readability and reduces cognitive load. ### 3.1. Error Handling * **Standard:** Use "!" for error union returns and "try" to handle errors explicitly. Avoid using "catch" blocks unless absolutely necessary for dealing with specific errors. Prefer propagating errors up the call stack by returning error unions. * **Why:** Explicit error handling improves code reliability and prevents unexpected crashes. Zig's error sets allow for precise error management. * **Do This:** """zig const std = @import("std"); fn readFile(allocator: std.mem.Allocator, path: []const u8) ![]u8 { const file = try std.fs.cwd().openFile(path, .{}); defer file.close(); const file_size = try file.getEndPos(); var buffer = try allocator.alloc(u8, file_size); errdefer allocator.free(buffer); // ensures the buffer is cleanedup in case of an error during reading _ = try file.readAll(buffer); return buffer; } pub fn main() !void { var arena = std.heap.ArenaAllocator.init(std.heap.page_allocator); defer arena.deinit(); const allocator = arena.allocator(); const file_content = try readFile(allocator, "myfile.txt"); defer allocator.free(file_content); std.debug.print("File Content: {s}\n", .{file_content}); } """ * **Don't Do This:** (Using catch when not necessary) """zig const std = @import("std"); fn readFile(allocator: std.mem.Allocator, path: []const u8) []u8 { const file = std.fs.cwd().openFile(path, .{}) catch { std.debug.print("Error opening file\n", .{}); return ""; // Really bad return value that will cause headaches later. }; defer file.close(); const file_size = file.getEndPos() catch { std.debug.print("Error getting file size\n", .{}); return ""; // Really bad return value that will cause headaches later. }; var buffer = allocator.alloc(u8, file_size) catch { std.debug.print("Error allocating file buffer!\n", .{}); return ""; // Really bad return value that will cause headaches later. }; defer allocator.free(buffer); _ = file.readAll(buffer) catch { std.debug.print("Error reading file!\n", .{}); return ""; // Really bad return value that will cause headaches later. }; return buffer; } pub fn main() !void { var arena = std.heap.ArenaAllocator.init(std.heap.page_allocator); defer arena.deinit(); const allocator = arena.allocator(); const file_content = readFile(allocator, "myfile.txt"); defer allocator.free(file_content); std.debug.print("File Content: {s}\n", .{file_content}); } """ * **Don't do this:** (Ignoring errors) """zig const std = @import("std"); fn readFile(allocator: std.mem.Allocator, path: []const u8) []u8 { const file = std.fs.cwd().openFile(path, .{}) catch unreachable; defer file.close(); const file_size = file.getEndPos() catch unreachable; var buffer = allocator.alloc(u8, file_size) catch unreachable; defer allocator.free(buffer); _ = file.readAll(buffer) catch unreachable; return buffer; } pub fn main() !void { var arena = std.heap.ArenaAllocator.init(std.heap.page_allocator); defer arena.deinit(); const allocator = arena.allocator(); const file_content = readFile(allocator, "myfile.txt"); defer allocator.free(file_content); std.debug.print("File Content: {s}\n", .{file_content}); } """ ### 3.2. Optionals * **Standard:** Use optionals ("?T") when a value might be absent. Handle optional values explicitly, typically using "if (optional_value) |value| { ... } else { ... }". * **Why:** Optionals improve code clarity and prevent null pointer exceptions. * **Do This:** """zig const std = @import("std"); fn findUser(name: []const u8) ?User { if (std.mem.eql(u8, name, "John")) { return User{ .name = "John", .age = 30 }; } else { return null; } } const User = struct { name: []const u8, age: u32, }; pub fn main() !void { const user = findUser("John"); if (user) |u| { std.debug.print("User found: {s}, Age: {}\n", .{ u.name, u.age }); } else { std.debug.print("User not found\n", .{}); } } """ * **Don't Do This:** (Dereferencing without checking) """zig const std = @import("std"); fn findUser(name: []const u8) ?User { if (std.mem.eql(u8, name, "John")) { return User{ .name = "John", .age = 30 }; } else { return null; } } const User = struct { name: []const u8, age: u32, }; pub fn main() !void { const user = findUser("John"); std.debug.print("User found: {s}, Age: {}\n", .{ user.?.name, user.?.age }); // This will crash if user is null! } """ ### 3.3. Documentation * **Standard:** Document all public functions, structs, enums, and constants using doc comments ("///"). Doc comments should describe the purpose, arguments, and return values. * **Why:** Documentation is essential for code maintainability and usability. Doc comments can be extracted to generate API documentation. * **Do This:** """zig /// Adds two integers and returns the result. /// /// Parameters: /// a: The first integer. /// b: The second integer. /// /// Returns: /// The sum of a and b. fn add(a: i32, b: i32) i32 { return a + b; } """ * **Don't Do This:** """zig fn add(a: i32, b: i32) i32 { return a + b; } """ ### 3.4. Defer * **Standard:** Utilize "defer" for resource cleanup and ensuring consistent state, especially when dealing with memory allocation, file handles, or other external resources. Place the "defer" statement immediately after acquiring the resource. * **Why:** Ensures resources are released regardless of the execution path, preventing memory leaks and other resource-related issues. * **Do this:** """zig const std = @import("std"); pub fn main() !void { var arena = std.heap.ArenaAllocator.init(std.heap.page_allocator); defer arena.deinit(); const allocator = arena.allocator(); const file = try std.fs.cwd().createFile("temp.txt", .{}); defer file.close(); // Ensure file is closed when exiting the scope const data = [_]u8{ 'H', 'e', 'l', 'l', 'o' }; try file.writeAll(&data); std.debug.print("File created and data written\n", .{}); } """ * **Don't Do This:** (Forgetting to defer, which might cause memory leaks) """zig const std = @import("std"); pub fn main() !void { var arena = std.heap.ArenaAllocator.init(std.heap.page_allocator); defer arena.deinit(); const allocator = arena.allocator(); const file = try std.fs.cwd().createFile("temp.txt", .{}); // Oops! We forgot to defer file.close() ! const data = [_]u8{ 'H', 'e', 'l', 'l', 'o' }; try file.writeAll(&data); std.debug.print("File created and data written\n", .{}); } """ ### 3.5. Testing * **Standard:** Write unit tests for all functions and modules. Use Zig's built-in testing framework. * **Why:** Testing ensures code correctness and prevents regressions. * **Do This:** """zig const std = @import("std"); const assert = std.debug.assert; fn add(a: i32, b: i32) i32 { return a + b; } test "add function" { assert(add(2, 3) == 5); assert(add(-1, 1) == 0); assert(add(0, 0) == 0); } """ * **Don't Do This:** (Not writing tests) """zig fn add(a: i32, b: i32) i32 { return a + b; } """ ### 3.6. Compile-Time Safety * **Standard:** Leverage Zig's compile-time features ("comptime") for performing calculations, checking conditions, and generating code at compile time. Use "@compileError" for early detection of errors during compilation. * **Why:** Compile-time safety catches errors early, improves performance, and allows for highly optimized code generation. * **Do This:** """zig const std = @import("std"); fn factorial(comptime n: u64) u64 { if (n == 0) { return 1; } else { return n * factorial(n - 1); } } pub fn main() !void { const result = factorial(5); // Evaluated at compile time std.debug.print("Factorial of 5: {}\n", .{result}); // Trigger a compile error if a condition is not met const value: i32 = 10; if (value < 0) { @compileError("Value must be non-negative"); } const array: [factorial(3)]i32 = [_]i32{1, 2, 3, 4, 5, 6}; // array size is determined at compile time, thanks to comptime factorial! std.debug.print("Array len: {}\n", .{@TypeOf(array).len}); } """ * **Don't Do This:**(Performing calculations at runtime when they can be done at compile time) """zig const std = @import("std"); fn factorial(n: u64) u64 { if (n == 0) { return 1; } else { return n * factorial(n - 1); } } pub fn main() !void { const result = factorial(5); // Evaluated at runtime std.debug.print("Factorial of 5: {}\n", .{result}); } """ ### 3.7. Memory Management * **Standard:** Be mindful of memory allocation and deallocation. Prefer using allocators and "defer" statements to manage memory automatically within a defined scope to ensure that resources are released. * **Why:** Manual memory management can be error-prone. Zig provides mechanisms for safer memory management. * **Do This:** """zig const std = @import("std"); pub fn main() !void { var arena = std.heap.ArenaAllocator.init(std.heap.page_allocator); defer arena.deinit(); const allocator = arena.allocator(); const buffer = try allocator.alloc(u8, 1024); defer allocator.free(buffer); std.mem.set(buffer, 0, 1024); std.debug.print("Buffer allocated and initialized\n", .{}); } """ * **Don't Do This:** (Manual allocation/deallocation without proper error handling or cleanup) """zig const std = @import("std"); pub fn main() !void { const buffer = std.heap.page_allocator.alloc(u8, 1024) catch unreachable; // Oops! We forgot std.heap.page_allocator.free(buffer) std.mem.set(buffer, 0, 1024); std.debug.print("Buffer allocated and initialized\n", .{}); } """ ### 3.8. Slices * **Standard:** Use slices ("[]T") to refer to contiguous sequences of memory. When passing slices to functions, avoid taking ownership unless necessary. When slices are modified in place, document this clearly. * **Why:** Slices provide a flexible way to work with arrays and memory regions without unnecessary copying. * **Do This:** """zig const std = @import("std"); fn printSlice(slice: []const u8) void { std.debug.print("Slice: {s}\n", .{slice}); } pub fn main() !void { const data = [_]u8{ 'H', 'e', 'l', 'l', 'o' }; printSlice(&data); // Pass a slice of the array } """ * **Don't Do This:** (Unnecessary copying of data) """zig const std = @import("std"); fn printSlice(slice: []const u8) void { std.debug.print("Slice: {s}\n", .{slice}); } pub fn main() !void { const data = [_]u8{ 'H', 'e', 'l', 'l', 'o' }; var copied_data = data; // Copying the entire array! Unnecessary! printSlice(&copied_data); } """ ### 3.9. "inline" Keyword * **Standard:** Use "inline" keyword judiciously for small, frequently called functions to potentially improve performance. Avoid inlining large functions as it can increase code size. * **Why:** Inlining can reduce function call overhead but can also lead to code bloat. * **Do This:** """zig inline fn min(a: i32, b: i32) i32 { if (a < b) { return a; } else { return b; } } """ * **Don't Do This:** (Inlining large functions) """zig inline fn veryComplexAndLongFunction(a: i32, b: i32) i32 { // ... many lines of complicated code ... return a + b; } """ ### 3.10. "comptime" versus runtime * **Standard:** Always prefer comptime functionality where possible. * **Why:** Code that runs at compile time generally improves speed and safety. * **Do This:** """zig // GOOD const array = [_]u8{1,2,3,4,5}; const len = array.len; """ * **Don't Do This:** """zig // BAD const array = [_]u8{1,2,3,4,5}; fn getLen(arr: []const u8) usize { return arr.len; } const len = getLen(array); """ By adhering to these coding standards and conventions, Zig projects will benefit from increased readability, maintainability, and consistency, leading to higher-quality software. Continuous learning and adaptation to new Zig features and best practices are highly encouraged.