### Initializing EasyP Project (Bash)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/introduction/quickstart.md

Runs the initial setup command for EasyP in the terminal. This command prepares the project directory for EasyP usage.

```bash
easyp init
```

--------------------------------

### Installing gRPC-Gateway Plugins (Bash)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/generator/examples/grpc-gateway.md

These commands install the required protoc plugins for working with gRPC-Gateway and OpenAPIv2, including protoc-gen-go, protoc-gen-go-grpc, protoc-gen-openapiv2, and protoc-gen-grpc-gateway.

```bash
go install google.golang.org/protobuf/cmd/protoc-gen-go@latest
go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@latest
go install github.com/grpc-ecosystem/grpc-gateway/v2/protoc-gen-openapiv2@latest
go install github.com/grpc-ecosystem/grpc-gateway/v2/protoc-gen-grpc-gateway@latest
```

--------------------------------

### Downloading EasyP Dependencies (Bash)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/introduction/quickstart.md

Downloads the packages listed in the 'deps' section of the easyp.yaml file using the EasyP module command.

```bash
easyp mod download
```

--------------------------------

### Running EasyP Linter (Bash)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/introduction/quickstart.md

Executes the EasyP linter command to check protocol buffer files against the configured rules.

```bash
easyp lint
```

--------------------------------

### Configure Default Linter Rules (YAML)

Source: https://github.com/easyp-tech/site/blob/main/docs/ru/guide/introduction/quickstart.md

Example YAML configuration to use the default linter rules in your EasyP project.

```yaml
lint:
  use:
    - DEFAULT
```

--------------------------------

### Configuring Proto Generation (YAML)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/introduction/quickstart.md

Sets up the configuration for generating code from protocol buffer files in easyp.yaml. Defines plugins like 'go' and 'go-grpc' with output paths and options.

```yaml
lint:
  use:
    - DEFAULT
deps:
  - github.com/googleapis/googleapis
  - github.com/grpc-ecosystem/grpc-gateway@v2.20.0
generate:
  plugins:
    - name: go
      out: .
      opts:
        paths: source_relative
    - name: go-grpc
      out: .
      opts:
        paths: source_relative
        require_unimplemented_servers: false
```

--------------------------------

### Generating Proto Code (Bash)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/introduction/quickstart.md

Runs the EasyP generate command to produce code from protocol buffer files based on the configuration in easyp.yaml.

```bash
easyp generate
```

--------------------------------

### Installing gRPC Plugins with Go

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/generator/examples/go.md

Installs the necessary Go plugins (`protoc-gen-go` and `protoc-gen-go-grpc`) required for generating Go and gRPC code from Protocol Buffers using the `go install` command.

```shell
go install google.golang.org/protobuf/cmd/protoc-gen-go@latest
go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@latest
```

--------------------------------

### Configuring Default Linter Rules (YAML)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/introduction/quickstart.md

Defines the linter configuration in the easyp.yaml file to use the default set of linting rules.

```yaml
lint:
  use:
    - DEFAULT
```

--------------------------------

### Adding Package Dependencies (YAML)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/introduction/quickstart.md

Adds third-party package dependencies to the easyp.yaml configuration file under the 'deps' section. Specifies package paths and optional versions.

```yaml
lint:
  use:
    - DEFAULT
deps:
  - github.com/googleapis/googleapis
  - github.com/grpc-ecosystem/grpc-gateway@v2.20.0
```

--------------------------------

### Install EasyP CLI using Go Install (Bash)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/introduction/install.md

Installs the latest stable version of the EasyP CLI tool directly from the source repository using the Go `go install` command. This method requires Go 1.24 or later.

```bash
go install github.com/easyp-tech/easyp/cmd/easyp@latest
```

--------------------------------

### Install Protoc Plugins for gRPC and Validation (Shell)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/generator/examples/validate.md

These shell commands use `go install` to download and install the necessary `protoc` plugins: `protoc-gen-go`, `protoc-gen-go-grpc`, and `protoc-gen-validate`. These plugins are required by EasyP to generate Go code from `.proto` files, including validation logic.

```shell
go install google.golang.org/protobuf/cmd/protoc-gen-go@latest
go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@latest
go install github.com/envoyproxy/protoc-gen-validate@latest
```

--------------------------------

### Good Example: Consistent Java Package in bar.proto (Proto)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/package-same-java-multiple-files.md

This snippet shows the `pkg/bar.proto` file in a 'Good' example where its `java_package` option ('com.example.foo') is consistent with other files in the same `pkg` package, adhering to the rule. It matches `foo.proto` in the same good example.

```proto
// File: pkg/bar.proto

syntax = "proto3";

package pkg;

option java_package = "com.example.foo"; // [!code focus]
```

--------------------------------

### Initialize EasyP Project (Bash)

Source: https://github.com/easyp-tech/site/blob/main/docs/ru/guide/introduction/quickstart.md

Run this command in your terminal to initialize a new EasyP project.

```bash
easyp init
```

--------------------------------

### Bad Example: Different Java Package in bar.proto (Proto)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/package-same-java-multiple-files.md

This snippet shows the `pkg/bar.proto` file in a 'Bad' example where its `java_package` option ('com.example.bar') differs from other files in the same `pkg` package, violating the rule. It contrasts with `foo.proto` in the same bad example.

```proto

// File: pkg/bar.proto

syntax = "proto3";

package pkg;

option java_package = "com.example.bar";
```

--------------------------------

### Good Example: Same go_package (File 2)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/package-same-go-package.md

This snippet shows the second file in a good example. It declares the same 'pkg' package as the previous snippet and also specifies the *same* 'go_package' ('example.com/foo/bar'), demonstrating compliance with the rule.

```proto
// File: pkg/bar.proto

syntax = "proto3";

package pkg;

option go_package = "example.com/foo/bar"; // [!code focus]

```

--------------------------------

### Add easyp bash completion source - Bash

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/auto-completion/auto-completion.md

Adds the easyp bash auto-completion script output as a source to the bash shell startup file (~/.bashrc). This enables command auto-completion for easyp in bash, requiring bash-completion to be installed.

```Bash
source <(easyp completion bash)
```

--------------------------------

### Good Example: Same Ruby Package (bar.proto)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/package-same-ruby-package.md

This snippet shows a 'good' example where the `ruby_package` option in `pkg/bar.proto` is also 'Foo'. This matches the other file (`pkg/foo.proto`) with the same package, ensuring compliance with the rule.

```proto
// File: pkg/bar.proto

syntax = "proto3";

package pkg;

option ruby_package = "Foo"; // [!code focus]
```

--------------------------------

### Good Example - DIRECTORY_SAME_PACKAGE - Proto

Source: https://github.com/easyp-tech/site/blob/main/docs/ru/guide/cli/linter/rules/directory-same-package.md

This example demonstrates compliance with the DIRECTORY_SAME_PACKAGE rule. The file `dir/foo/foo.proto` declares the package `dir.foo`, which correctly matches the expected package based on its directory structure.

```proto
// File: dir/foo/foo.proto

syntax = "proto3";

package dir.foo;

message Foo {
    string bar = 1;
}
```

--------------------------------

### Good Example: pkg/bar.proto with 'Foo' Swift Prefix (Proto)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/package-same-swift-prefix.md

This snippet shows the `pkg/bar.proto` file in a 'Good' example configuration for the PACKAGE_SAME_SWIFT_PREFIX rule. It defines the package 'pkg' and sets the Swift prefix to 'Foo'. Since this file is in the same package as `pkg/foo.proto` and uses the same prefix, this configuration complies with the rule.

```proto
// File: pkg/bar.proto

syntax = "proto3";

package pkg;

option swift_prefix = "Foo"; // [!code focus]
```

--------------------------------

### Install EasyP CLI using Homebrew (Bash)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/introduction/install.md

Installs the EasyP CLI tool on macOS using the Homebrew package manager from the official easyp-tech tap. This is the recommended installation method.

```bash
brew install easyp-tech/tap/easyp
```

--------------------------------

### Good Example: pkg/foo.proto with 'Foo' Swift Prefix (Proto)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/package-same-swift-prefix.md

This snippet shows the `pkg/foo.proto` file in a 'Good' example configuration for the PACKAGE_SAME_SWIFT_PREFIX rule. It defines the package 'pkg' and sets the Swift prefix to 'Foo'. When paired with other files in the same package using the same prefix, this configuration is compliant.

```proto
// File: pkg/foo.proto

syntax = "proto3";

package pkg;

option swift_prefix = "Foo"; // [!code focus]
```

--------------------------------

### Good Example: Service Name in PascalCase (proto)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/service-pascal-case.md

This example demonstrates a service definition where the service name 'FooBar' uses PascalCase, which conforms to the SERVICE_PASCAL_CASE rule. This is the recommended format.

```proto
syntax = "proto3";

service FooBar { // [!code focus]
    rpc GetFooBar (FooBarRequest) returns (FooBarResponse) {}
}
```

--------------------------------

### Bad Example: Different Java Package in foo.proto (Proto)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/package-same-java-multiple-files.md

This snippet shows the `pkg/foo.proto` file in a 'Bad' example where its `java_package` option ('com.example.foo') differs from other files in the same `pkg` package, violating the rule.

```proto
// File: pkg/foo.proto

syntax = "proto3";

package pkg;

option java_package = "com.example.foo";
```

--------------------------------

### Good Example: Same Ruby Package (foo.proto)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/package-same-ruby-package.md

This snippet shows a 'good' example where the `ruby_package` option in `pkg/foo.proto` is 'Foo'. When paired with another file in the same package also having 'Foo' as the `ruby_package`, this complies with the rule.

```proto
// File: pkg/foo.proto

syntax = "proto3";

package pkg;

option ruby_package = "Foo"; // [!code focus]
```

--------------------------------

### Good Example: Matching Package and Directory (proto)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/package-directory-match.md

This example shows the correct way to structure a proto file according to the PACKAGE_DIRECTORY_MATCH rule. The file is in the 'bar' directory, and the package name is also 'bar', satisfying the rule.

```proto
// File: bar/foo.proto // [!code focus]

syntax = "proto3";

package bar; // [!code focus]

message Foo {
    string bar = 1;
}

```

--------------------------------

### Good Example: Same go_package (File 1)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/package-same-go-package.md

This snippet shows the first file in a good example. It declares the 'pkg' package and a specific 'go_package'. When paired with another file declaring the same package and the *same* go_package, the rule is satisfied.

```proto
// File: pkg/foo.proto

syntax = "proto3";

package pkg;

option go_package = "example.com/foo/bar"; // [!code focus]

```

--------------------------------

### Defining Basic Proto Service (Proto)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/generator/examples/grpc-gateway.md

This is an initial proto file defining a simple Echo service with a request and response message. It serves as the base for adding gRPC-Gateway functionality.

```proto
syntax = "proto3";

package api.echo.v1;

option go_package = "github.com/easyp-tech/example/api/echo/v1;pb";

service EchoAPI {
  rpc Echo(EchoRequest) returns (EchoResponse);
}

message EchoRequest {
  string payload = 1;
}

message EchoResponse {
  string payload = 2;
}
```

--------------------------------

### Bad Example: pkg/foo.proto with 'Foo' Swift Prefix (Proto)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/package-same-swift-prefix.md

This snippet shows the `pkg/foo.proto` file in a 'Bad' example configuration for the PACKAGE_SAME_SWIFT_PREFIX rule. It defines the package 'pkg' and sets the Swift prefix to 'Foo'. When paired with another file in the same package having a different prefix, this configuration is non-compliant.

```proto
// File: pkg/foo.proto

syntax = "proto3";

package pkg;

option swift_prefix = "Foo";
```

--------------------------------

### Updating EasyP Dependencies (Bash)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/generator/examples/grpc-gateway.md

This command downloads the dependencies specified in the `deps` section of the `easyp.yaml` configuration file, such as `github.com/googleapis/googleapis`.

```bash
easyp mod update
```

--------------------------------

### Example EasyP Generator Configuration (YAML)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/generator/generator.md

Demonstrates a sample YAML configuration file for the EasyP generator, specifying input sources (local directory and remote Git repository) and plugins (go and go-grpc) with their output directory and options.

```YAML
generate:
  inputs:
    - directory: "proto"
    - git_repo:
        url: "https://github.com/acme/weather.git"
        branch: "main"
        sub_directory: "proto"
  plugins:
    - name: go
      out: .
      opts:
        paths: source_relative
    - name: go-grpc
      out: .
      opts:
        paths: source_relative
        require_unimplemented_servers: false
```

--------------------------------

### Configuring EasyP for gRPC-Gateway (YAML)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/generator/examples/grpc-gateway.md

This `easyp.yaml` configuration adds the `github.com/googleapis/googleapis` dependency for proto imports and includes the `grpc-gateway` and `openapiv2` plugins in the generate section with necessary options.

```yaml
version: v1alpha

deps:  # [!code ++]
  - github.com/googleapis/googleapis  # [!code ++]

generate:
  plugins:
    - name: go
      out: .
      opts:
        paths: source_relative
    - name: go-grpc
      out: .
      opts:
        paths: source_relative
        require_unimplemented_servers: false
    - name: grpc-gateway  # [!code ++]
      out: .  # [!code ++]
      opts:  # [!code ++]
        paths: source_relative  # [!code ++]
    - name: openapiv2        # [!code ++]
      out: .  # [!code ++]
      opts: # [!code ++]
        simple_operation_ids: false  # [!code ++]
        generate_unbound_methods: false  # [!code ++]
```

--------------------------------

### Bad Example - DIRECTORY_SAME_PACKAGE - Proto

Source: https://github.com/easyp-tech/site/blob/main/docs/ru/guide/cli/linter/rules/directory-same-package.md

This example demonstrates a violation of the DIRECTORY_SAME_PACKAGE rule. The file `dir/foo.proto` declares the package `foo`, which does not match the expected package based on its directory structure (`dir.foo`).

```proto
// File: dir/foo.proto

syntax = "proto3";
   
package foo;

message Foo {
    string bar = 1;
}
```

--------------------------------

### Good Example: Consistent Java Package in foo.proto (Proto)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/package-same-java-multiple-files.md

This snippet shows the `pkg/foo.proto` file in a 'Good' example where its `java_package` option ('com.example.foo') is consistent with other files in the same `pkg` package, adhering to the rule.

```proto
// File: pkg/foo.proto

syntax = "proto3";

package pkg;

option java_package = "com.example.foo"; // [!code focus]
```

--------------------------------

### Bad Example: Different Ruby Package (bar.proto)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/package-same-ruby-package.md

This snippet shows a 'bad' example where the `ruby_package` option in `pkg/bar.proto` is 'Bar'. This differs from 'Foo' in the other file (`pkg/foo.proto`) with the same package, violating the rule.

```proto
// File: pkg/bar.proto

syntax = "proto3";

package pkg;

option ruby_package = "Bar";
```

--------------------------------

### Good Example: Compliant File Name (proto)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/file-lower-snake-case.md

This example demonstrates a file name (`foo_baz.proto`) that correctly follows the lower_snake_case convention required by the rule.

```proto
// File: bar/foo_baz.proto // [!code focus]

syntax = "proto3";
```

--------------------------------

### Good Example: Used Import in Proto

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/import-used.md

This example shows a proto file that imports 'bar.proto' and uses a definition ('bar.Bar') from it, satisfying the IMPORT_USED rule.

```proto
syntax = "proto3";

package foo;

import "bar.proto"; // [!code focus]

message Foo {
    bar.Bar bar = 1; // [!code focus]
}
```

--------------------------------

### Bad Example: Using Weak Import in Proto

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/import-no-weak.md

This example demonstrates the incorrect usage of a weak import in a proto file, which violates the IMPORT_NO_WEAK rule.

```proto
syntax = "proto2";

package foo;

import weak "bar.proto";
```

--------------------------------

### Bad Example: Different go_package (File 2)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/package-same-go-package.md

This snippet shows the second file in a bad example. It declares the same 'pkg' package as the previous snippet but specifies a different 'go_package' ('example.com/foo/baz'), demonstrating the rule violation.

```proto
// File: pkg/bar.proto

syntax = "proto3";

package pkg;

option go_package = "example.com/foo/baz";

```

--------------------------------

### Good Example: Same java_package in Proto File 1

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/package-same-java-package.md

This snippet shows a `.proto` file (`pkg/foo.proto`) that declares `package pkg` and `option java_package = "com.example.foo";`. When paired with `pkg/bar.proto` having the *same* `java_package`, this satisfies the rule. The `[!code focus]` comment is part of the example, indicating the relevant line.

```proto
// File: pkg/foo.proto

syntax = "proto3";

package pkg;

option java_package = "com.example.foo"; // [!code focus]
```

--------------------------------

### Clone EasyP Repository (Bash)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/introduction/install.md

Clones the official EasyP CLI source code repository from GitHub to your local machine. This is the initial step required for building the CLI from source.

```bash
git clone https://github.com/easyp-tech/easyp.git
```

--------------------------------

### Bad Example: pkg/bar.proto with 'Bar' Swift Prefix (Proto)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/package-same-swift-prefix.md

This snippet shows the `pkg/bar.proto` file in a 'Bad' example configuration for the PACKAGE_SAME_SWIFT_PREFIX rule. It defines the package 'pkg' and sets the Swift prefix to 'Bar'. Since this file is in the same package as `pkg/foo.proto` (which has a different prefix), this configuration violates the rule.

```proto
// File: pkg/bar.proto

syntax = "proto3";

package pkg;

option swift_prefix = "Bar";
```

--------------------------------

### Good Example: Same java_package in Proto File 2

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/package-same-java-package.md

This snippet shows a `.proto` file (`pkg/bar.proto`) that declares the same `package pkg` as `pkg/foo.proto` and the *same* `option java_package = "com.example.foo";`. Having the same `java_package` for files with the same `package` satisfies the `PACKAGE_SAME_JAVA_PACKAGE` rule. The `[!code focus]` comment is part of the example, indicating the relevant line.

```proto
// File: pkg/bar.proto

syntax = "proto3";

package pkg;

option java_package = "com.example.foo"; // [!code focus]
```

--------------------------------

### Bad Example: Unused Import in Proto

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/import-used.md

This example shows a proto file that imports 'bar.proto' but does not use any definitions from it, violating the IMPORT_USED rule.

```proto
syntax = "proto3";

package foo;

import "bar.proto";
```

--------------------------------

### Defining a Service with Suffix (Good Example) - Proto

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/service-suffix.md

This example shows a service definition that complies with the SERVICE_SUFFIX rule by correctly appending the 'Service' suffix to the service name 'FooService'.

```proto
syntax = "proto3";

service FooService { // [!code focus]
    rpc Bar(BarRequest) returns (BarResponse); 
}
```

--------------------------------

### Good Example - Correct RPC Request Name (proto)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/rpc-request-standard-name.md

This example shows an RPC definition where the request message `GetFooRequest` follows the `MethodRequest` naming standard, complying with the rule.

```proto
syntax = "proto3";

service Foo {
    rpc GetFoo (GetFooRequest) returns (FooResponse) {} // [!code focus]
}
```

--------------------------------

### Good Example: Using Standard Import in Proto

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/import-no-weak.md

This example shows the correct way to import another proto file without using the 'weak' keyword, adhering to the IMPORT_NO_WEAK rule.

```proto
syntax = "proto2";

package foo;

import "bar.proto"; // [!code focus]
```

--------------------------------

### Adding HTTP Options to Proto Service (Proto)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/generator/examples/grpc-gateway.md

This updated proto file includes the `google/api/annotations.proto` import and adds HTTP options to the Echo RPC method using the `google.api.http` annotation, specifying the HTTP method, path, and body mapping for gRPC-Gateway.

```proto
syntax = "proto3";
import "google/api/annotations.proto";

package api.echo.v1;

option go_package = "github.com/easyp-tech/example/api/echo/v1;pb";

service EchoAPI {
  rpc Echo(EchoRequest) returns (EchoResponse) {
    option (google.api.http) = { // [!code ++]
      post: "/api/v1/echo"       // [!code ++]
      body: "*"                  // [!code ++]
    };                           // [!code ++]
  }
}

message EchoRequest {
  string payload = 1;
}

message EchoResponse {
  string payload = 2;
}
```

--------------------------------

### Example of Bad FIELD_LOWER_SNAKE_CASE in Proto

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/field-lower-snake-case.md

This example demonstrates a violation of the FIELD_LOWER_SNAKE_CASE rule, where the field name 'BarName' is not in lower_snake_case.

```proto
syntax = "proto3";

package foo;

message Foo {
    string BarName = 1;
}
```

--------------------------------

### Build EasyP CLI from Source (Bash)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/introduction/install.md

Builds the EasyP CLI executable from the cloned source code using the Go `go build` command. This command should be executed from the root directory of the cloned repository.

```bash
go build ./cmd/easyp
```

--------------------------------

### Bad Example: Non-Compliant File Name (proto)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/file-lower-snake-case.md

This example shows a file name (`FooBaz.proto`) that violates the lower_snake_case rule by using PascalCase instead.

```proto
// File: bar/FooBaz.proto

syntax = "proto3";
```

--------------------------------

### Complying with PACKAGE_SAME_PHP_NAMESPACE (Good Example)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/package-same-php-namespace.md

This example demonstrates compliance with the PACKAGE_SAME_PHP_NAMESPACE rule. Two separate `.proto` files (`pkg/foo.proto` and `pkg/bar.proto`) declare the same `package pkg` and correctly specify the identical `option php_namespace` value (`"Foo\\Bar"`) in both files.

```proto
// File: pkg/foo.proto

syntax = "proto3";

package pkg;

option php_namespace = "Foo\\Bar"; // [!code focus]

```

```proto
// File: pkg/bar.proto

syntax = "proto3";

package pkg;

option php_namespace = "Foo\\Bar"; // [!code focus]

```

--------------------------------

### Good Example: pkg/foo.proto with Foo.Bar namespace

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/package-same-csharp-namespace.md

This snippet shows a `.proto` file (`pkg/foo.proto`) using the `Foo.Bar` C# namespace option. It's part of a 'Good' example where all files in the package use the same namespace, complying with the rule.

```proto
// File: pkg/foo.proto 

syntax = "proto3";

package pkg;

option csharp_namespace = "Foo.Bar";
```

--------------------------------

### Example of Good FIELD_LOWER_SNAKE_CASE in Proto

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/field-lower-snake-case.md

This example demonstrates compliance with the FIELD_LOWER_SNAKE_CASE rule, where the field name 'bar_name' is correctly in lower_snake_case.

```proto
syntax = "proto3";

package foo;

message Foo {
    string bar_name = 1; // [!code focus]
}
```

--------------------------------

### Bad Example: Different Ruby Package (foo.proto)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/package-same-ruby-package.md

This snippet shows a 'bad' example where the `ruby_package` option in `pkg/foo.proto` is 'Foo'. When paired with another file in the same package having a different `ruby_package`, this violates the rule.

```proto
// File: pkg/foo.proto

syntax = "proto3";

package pkg;

option ruby_package = "Foo";
```

--------------------------------

### Bad Example: Different go_package (File 1)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/package-same-go-package.md

This snippet shows the first file in a bad example where two .proto files share the same 'pkg' package but define different 'go_package' options, violating the rule.

```proto
// File: pkg/foo.proto

syntax = "proto3";

package pkg;

option go_package = "example.com/foo/bar";

```

--------------------------------

### Bad Example - Incorrect RPC Request Name (proto)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/rpc-request-standard-name.md

This example demonstrates an RPC definition where the request message `FooRequest` does not adhere to the `MethodRequest` naming standard, violating the rule.

```proto
syntax = "proto3";

service Foo {
    rpc GetFoo (FooRequest) returns (FooResponse) {}
}
```

--------------------------------

### Bad Example: Mismatched Package and Directory (proto)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/package-directory-match.md

This example demonstrates a violation of the PACKAGE_DIRECTORY_MATCH rule. The file is located in the 'bar' directory, but the package name is 'foo', causing a mismatch.

```proto
// File: bar/foo.proto

syntax = "proto3";

package foo;

message Foo {
    string bar = 1;
}

```

--------------------------------

### Good Example - RPC without Server Streaming - proto

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/rpc-no-server-streaming.md

This example shows an RPC definition that complies with the RPC_NO_SERVER_STREAMING rule by returning a single message type instead of a stream.

```proto
syntax = "proto3";

service Foo {
    rpc Bar (BarRequest) returns (BarResponse) {} // [!code focus]
}
```

--------------------------------

### Generating Code with EasyP Config (Bash)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/generator/examples/grpc-gateway.md

This command uses EasyP to generate code based on the configuration provided in the specified `easyp.yaml` file.

```bash
easyp -cfg easyp.yaml generate
```

--------------------------------

### Bad Example - RPC with Server Streaming - proto

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/rpc-no-server-streaming.md

This example shows an RPC definition that violates the RPC_NO_SERVER_STREAMING rule by using 'stream' in the return type, indicating server streaming.

```proto
syntax = "proto3";

service Foo {
    rpc Bar (BarRequest) returns (stream BarResponse) {}
}
```

--------------------------------

### Good Example - First Enum Value is Zero (proto)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/enum-first-value-zero.md

This example demonstrates an enum definition that conforms to the ENUM_FIRST_VALUE_ZERO rule by assigning the integer 0 to the first value, BAR.

```proto
syntax = "proto3";

package foo;

enum Foo {
    BAR = 0; // [!code focus]
    BAZ = 1;
}
```

--------------------------------

### Bad Example: pkg/foo.proto with Foo.Bar namespace

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/package-same-csharp-namespace.md

This snippet shows a `.proto` file (`pkg/foo.proto`) using the `Foo.Bar` C# namespace option. It's part of a 'Bad' example where another file in the same package uses a different namespace, violating the rule.

```proto
// File: pkg/foo.proto

syntax = "proto3";

package pkg;

option csharp_namespace = "Foo.Bar";
```

--------------------------------

### Proto Enum With Comment (Good Example)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/comment-enum.md

This example shows a Protobuf enum definition that complies with the COMMENT_ENUM rule by including a preceding comment, demonstrating the correct way to document enums.

```proto
syntax = "proto3";

// Foo enum for bar and baz logic // [!code focus]
enum Foo {
    BAR = 0;
    BAZ = 1;
}
```

--------------------------------

### Generating Code with Default EasyP Config (Bash)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/generator/examples/grpc-gateway.md

This command uses EasyP to generate code based on the configuration found in the default `easyp.yaml` file located in the current directory.

```bash
easyp generate
```

--------------------------------

### Good Example (Proto)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/package-version-suffix.md

This snippet demonstrates a correct package declaration with the `_v1` version suffix, adhering to the PACKAGE_VERSION_SUFFIX rule.

```proto
syntax = "proto3";

package foo.v1; // [!code focus]
```

--------------------------------

### Bad Example: Service Name Not in PascalCase (proto)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/service-pascal-case.md

This example shows a service definition where the service name 'foo_bar' uses snake_case, which violates the SERVICE_PASCAL_CASE rule. The rule requires service names to be in PascalCase.

```proto
syntax = "proto3";

service foo_bar {
    rpc get_foo_bar (FooBarRequest) returns (FooBarResponse) {}
}
```

--------------------------------

### Good Example: Unique RPC Request/Response Types (Proto)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/rpc-request-response-unique.md

This example demonstrates compliance with the RPC_REQUEST_RESPONSE_UNIQUE rule by ensuring that each RPC method, `GetFoo` and `GetBar`, uses unique request (`FooRequest`, `BarRequest`) and response (`FooResponse`, `BarResponse`) message types.

```proto
syntax = "proto3";

service Foo {
    rpc GetFoo (FooRequest) returns (FooResponse) {} // [!code focus]
    rpc GetBar (BarRequest) returns (BarResponse) {} // [!code focus]
}
```

--------------------------------

### Proto Enum Missing Comment (Bad Example)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/comment-enum.md

This example demonstrates a Protobuf enum definition that violates the COMMENT_ENUM rule by lacking a preceding comment, which would be flagged by the linter.

```proto
syntax = "proto3";

enum Foo {
    BAR = 0;
    BAZ = 1;
}
```

--------------------------------

### Bad Example - First Enum Value Not Zero (proto)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/enum-first-value-zero.md

This example demonstrates an enum definition that violates the ENUM_FIRST_VALUE_ZERO rule because the first value, BAR, is assigned the integer 1 instead of 0.

```proto
syntax = "proto3";

package foo;

enum Foo {
    BAR = 1;
    BAZ = 2;
}
```

--------------------------------

### Violating PACKAGE_SAME_PHP_NAMESPACE (Bad Example)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/package-same-php-namespace.md

This example demonstrates a violation of the PACKAGE_SAME_PHP_NAMESPACE rule. Two separate `.proto` files (`pkg/foo.proto` and `pkg/bar.proto`) declare the same `package pkg` but specify different `option php_namespace` values (`"Foo\\Bar"` and `"Foo\\Baz"`), which is not allowed by the rule.

```proto
// File: pkg/foo.proto

syntax = "proto3";

package pkg;

option php_namespace = "Foo\\Bar";

```

```proto
// File: pkg/bar.proto

syntax = "proto3";

package pkg;

option php_namespace = "Foo\\Baz";

```

--------------------------------

### Defining a Service without Suffix (Bad Example) - Proto

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/service-suffix.md

This example demonstrates a service definition that violates the SERVICE_SUFFIX rule because the service name 'Foo' does not end with the required 'Service' suffix.

```proto
syntax = "proto3";

service Foo {
    rpc Bar(BarRequest) returns (BarResponse);
}
```

--------------------------------

### Bad Example: Duplicate RPC Request/Response Types (Proto)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/rpc-request-response-unique.md

This example shows a violation of the RPC_REQUEST_RESPONSE_UNIQUE rule where two different RPC methods, `GetFoo` and `GetBar`, use the same request (`FooRequest`) and response (`FooResponse`) message types.

```proto
syntax = "proto3";

service Foo {
    rpc GetFoo (FooRequest) returns (FooResponse) {}
    rpc GetBar (FooRequest) returns (FooResponse) {}
}
```

--------------------------------

### Good Example: Matching Package and Directory (Proto)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/package-same-directory.md

Shows a correct implementation of the PACKAGE_SAME_DIRECTORY rule where the package name 'bar' matches the file's directory 'bar'. This configuration adheres to the rule and passes the lint check.

```proto
// File: bar/foo.proto // [!code focus]

syntax = "proto3";

package bar; // [!code focus]

message Foo {
    string bar = 1;
}
```

--------------------------------

### Good Example - Message Name Pascal Case - Proto

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/message-pascal-case.md

Demonstrates a Protocol Buffer message definition where the message name 'FooBar' follows the PascalCase rule.

```proto
syntax = "proto3";

package foo;

message FooBar { // [!code focus]
    string bar_name = 1;
}
```

--------------------------------

### Bad Example: Different java_package in Proto File 2

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/package-same-java-package.md

This snippet shows a `.proto` file (`pkg/bar.proto`) that declares the same `package pkg` as `pkg/foo.proto` but a different `option java_package = "com.example.bar";`. This difference violates the `PACKAGE_SAME_JAVA_PACKAGE` rule.

```proto
// File: pkg/bar.proto

syntax = "proto3";

package pkg;

option java_package = "com.example.bar";
```

--------------------------------

### Good Example: Valid Package Name (Proto)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/package-lower-snake-case.md

Demonstrates a package name ('foo_bar') that correctly follows the lower_snake_case format, adhering to the linting rule.

```proto
// File: bar/foo.proto
syntax = "proto3";

package foo_bar; // [!code focus]
```

--------------------------------

### Good Example: pkg/bar.proto with Foo.Bar namespace

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/package-same-csharp-namespace.md

This snippet shows a `.proto` file (`pkg/bar.proto`) using the `Foo.Bar` C# namespace option. This matches `pkg/foo.proto` in the same package, demonstrating compliance with the PACKAGE_SAME_CSHARP_NAMESPACE rule.

```proto

// File: pkg/bar.proto

syntax = "proto3";

package pkg;

option csharp_namespace = "Foo.Bar"; // [!code focus]
```

--------------------------------

### Good Example - RPC Names in PascalCase - Proto

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/rpc-pascal-case.md

This snippet shows the correct way to name an RPC service and method using PascalCase, adhering to the RPC_PASCAL_CASE linter rule.

```proto
syntax = "proto3";

service FooBar {
    rpc GetFooBar (FooBarRequest) returns (FooBarResponse) {} // [!code focus]
}
```

--------------------------------

### Example EasyP Configuration File

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/package-manager/package-manager.md

This YAML snippet shows the basic structure of an EasyP configuration file, specifically the 'deps' section used to list proto repositories and their optional versions (Git tag or commit hash).

```yaml
# example.easyp.yaml
deps:
  - github.com/googleapis/googleapis@common-protos-1_3_1
```

--------------------------------

### Bad Example: Mismatched Package and Directory (Proto)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/package-same-directory.md

Demonstrates a violation of the PACKAGE_SAME_DIRECTORY rule where the package name 'foo' does not match the file's directory 'bar'. This configuration is flagged as incorrect by the linter.

```proto
// File: bar/foo.proto

syntax = "proto3";

package foo;

message Foo {
    string bar = 1;
}
```

--------------------------------

### Bad Example (Proto)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/package-version-suffix.md

This snippet shows a package declaration without the required `_vX` version suffix, violating the PACKAGE_VERSION_SUFFIX rule.

```proto
syntax = "proto3";

package foo;
```

--------------------------------

### Non-compliant Protobuf Package - Bad Example

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/directory-same-package.md

This snippet shows a Protobuf file where the package name ('foo') does not match the directory structure ('dir/foo'), violating the DIRECTORY_SAME_PACKAGE rule.

```proto
// File: dir/foo.proto

syntax = "proto3";
   
package foo;

message Foo {
    string bar = 1;
}
```

--------------------------------

### Bad Example: Invalid Package Name (Proto)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/package-lower-snake-case.md

Illustrates a package name ('FooBar') that does not follow the required lower_snake_case format, violating the linting rule.

```proto
// File: bar/foo.proto
syntax = "proto3";

package FooBar;
```

--------------------------------

### Compliant proto file with package declaration

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/package-defined.md

This example demonstrates a .proto file that complies with the PACKAGE_DEFINED rule by including a package declaration (package foo;).

```proto
syntax = "proto3";

package foo; // [!code focus]

message Foo {
    string bar = 1;
}
```

--------------------------------

### Define Example Echo Service with Validation (Proto)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/generator/examples/validate.md

This `.proto` file defines a simple Echo service with two RPC methods: `Echo` and `EchoStream`. It imports `validate/validate.proto` and applies `(validate.rules)` options to the `payload` fields of the request messages, setting a maximum length constraint.

```proto
syntax = "proto3";

package api.echo.v1;

import "validate/validate.proto";

option go_package = "github.com/easyp-tech/example/api/echo/v1;pb";

service EchoAPI {
  rpc Echo(EchoRequest) returns (EchoResponse);
  rpc EchoStream(EchoStreamRequest) returns (EchoResponse);
}

message EchoRequest {
  string payload = 1 [(validate.rules).string = {max_len: 200}];
}

message EchoResponse {
  string payload = 2;
}

message EchoStreamRequest {
  string payload = 1 [(validate.rules).string = {max_len: 200}];
}

message EchoStreamResponse {
  string payload = 2;
}
```

--------------------------------

### Add easyp zsh completion source - Bash

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/auto-completion/auto-completion.md

Adds the easyp zsh auto-completion script output as a source to the zsh shell startup file (~/.zshrc). This enables command auto-completion for easyp in zsh.

```Bash
source <(easyp completion zsh)
```

--------------------------------

### Compliant Protobuf Package - Good Example

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/directory-same-package.md

This snippet shows a Protobuf file where the package name ('dir.foo') correctly reflects the directory structure ('dir/foo'), adhering to the DIRECTORY_SAME_PACKAGE rule.

```proto
// File: dir/foo/foo.proto

syntax = "proto3";

package dir.foo;

message Foo {
    string bar = 1;
}
```

--------------------------------

### Bad Example: pkg/bar.proto with Foo.Baz namespace

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/package-same-csharp-namespace.md

This snippet shows a `.proto` file (`pkg/bar.proto`) using the `Foo.Baz` C# namespace option. This conflicts with `pkg/foo.proto` in the same package, illustrating the violation of the PACKAGE_SAME_CSHARP_NAMESPACE rule.

```proto
// File: pkg/bar.proto

syntax = "proto3";

package pkg;

option csharp_namespace = "Foo.Baz";
```

--------------------------------

### Proto: oneof with comment (Good example)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/comment-oneof.md

Demonstrates a 'oneof' field definition in Protocol Buffers that includes a preceding comment, satisfying the COMMENT_ONEOF rule.

```proto
syntax = "proto3";

message Foo {
    // bar oneof for baz and qux logic // [!code focus]
    oneof bar {
        string baz = 1; 
        string qux = 2; 
    }
}
```

--------------------------------

### Bad Example: Different java_package in Proto File 1

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/package-same-java-package.md

This snippet shows a `.proto` file (`pkg/foo.proto`) that declares `package pkg` and `option java_package = "com.example.foo";`. When paired with `pkg/bar.proto` having a different `java_package`, this violates the rule.

```proto
// File: pkg/foo.proto

syntax = "proto3";

package pkg;

option java_package = "com.example.foo";
```

--------------------------------

### Good RPC Response Naming (Proto)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/rpc-response-standard-name.md

Example of an RPC service definition where the response message follows the MethodResponse standard, using GetFooResponse for the GetFoo RPC.

```proto
syntax = "proto3";

service Foo {
    rpc GetFoo (GetFooRequest) returns (GetFooResponse) {} // [!code focus]
}
```

--------------------------------

### Protobuf RPCs With Comments (Good Example)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/comment-rpc.md

This snippet shows a Protobuf service definition where the RPC methods 'Bar' and 'Baz' include comments, adhering to the COMMENT_RPC rule.

```proto
syntax = "proto3";

service Foo {
    // Bar rpc for bar logic // [!code focus]
    rpc Bar (BarRequest) returns (BarResponse) {}
    // Baz rpc for baz logic // [!code focus]
    rpc Baz (BazRequest) returns (BazResponse) {}
}
```

--------------------------------

### Bad Example - Message Name Snake Case - Proto

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/message-pascal-case.md

Demonstrates a Protocol Buffer message definition where the message name 'foo_bar' violates the PascalCase rule by using snake_case.

```proto
syntax = "proto3";

package foo;

message foo_bar {
    string bar_name = 1;
}
```

--------------------------------

### Compliant proto oneof name

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/oneof-lower-snake-case.md

Example demonstrating a 'oneof' name ('bar_name') that complies with the 'ONEOF_LOWER_SNAKE_CASE' rule by being in lower_snake_case.

```proto
syntax = "proto3";

package foo;

message Foo {
    oneof bar_name { // [!code focus]
        string bar_name = 1;
    }
}
```

--------------------------------

### Non-compliant proto file without package declaration

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/package-defined.md

This example shows a .proto file that violates the PACKAGE_DEFINED rule because it lacks a package declaration.

```proto
syntax = "proto3";

message Foo {
    string bar = 1;
}

```

--------------------------------

### Defining a Protobuf Message with Comments (Good Example)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/comment-message.md

This protobuf snippet demonstrates the correct usage of comments for the `Foo` message and its fields (`bar`, `baz`), adhering to the COMMENT_MESSAGE rule for better code documentation.

```protobuf
syntax = "proto3";

// Foo message for bar and baz logic // [!code focus]
message Foo {
    // bar field for bar logic 
    string bar = 1; 
    // baz field for baz logic
    string baz = 2; 
}
```

--------------------------------

### Good Example: Enum Values With Comments (Proto)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/comment-enum-value.md

Shows a Protocol Buffer enum definition that complies with the COMMENT_ENUM_VALUE rule by providing comments for each enum value.

```proto

syntax = "proto3";

enum Foo {
    // BAR value for bar logic // [!code focus]
    BAR = 0; 
    // BAZ value for baz logic // [!code focus]
    BAZ = 1; 
}
```

--------------------------------

### Non-compliant proto oneof name

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/oneof-lower-snake-case.md

Example demonstrating a 'oneof' name ('BarName') that violates the 'ONEOF_LOWER_SNAKE_CASE' rule by not being in lower_snake_case.

```proto
syntax = "proto3";

package foo;

message Foo {
    oneof BarName {
        string bar_name = 1;
    }
}
```

--------------------------------

### Bad Example - RPC Names Not in PascalCase - Proto

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/rpc-pascal-case.md

This snippet demonstrates an RPC service and method name that violate the RPC_PASCAL_CASE rule by using snake_case instead of PascalCase.

```proto
syntax = "proto3";

service foo_bar {
    rpc get_foo_bar (FooBarRequest) returns (FooBarResponse) {}
}
```

--------------------------------

### Protobuf RPCs Without Comments (Bad Example)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/comment-rpc.md

This snippet shows a Protobuf service definition where the RPC methods 'Bar' and 'Baz' lack comments, violating the COMMENT_RPC rule.

```proto
syntax = "proto3";

service Foo {
    rpc Bar (BarRequest) returns (BarResponse) {}
    rpc Baz (BazRequest) returns (BazResponse) {}
}
```

--------------------------------

### Proto: oneof without comment (Bad example)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/comment-oneof.md

Demonstrates a 'oneof' field definition in Protocol Buffers that lacks a preceding comment, which violates the COMMENT_ONEOF rule.

```proto
syntax = "proto3";

message Foo {
    oneof bar {
        string baz = 1;
        string qux = 2;
    }
}
```

--------------------------------

### Configuring EasyP for Go and gRPC Generation

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/generator/examples/go.md

Configures the EasyP code generation tool using a YAML file. Specifies the version and lists the plugins to use (`go` and `go-grpc`), their output directory (`.`), and options like `paths: source_relative` and `require_unimplemented_servers: false`.

```yaml
version: v1alpha

generate:
  plugins:
    - name: go
      out: .
      opts:
        paths: source_relative
    - name: go-grpc
      out: .
      opts:
        paths: source_relative
        require_unimplemented_servers: false
```

--------------------------------

### Good Example: Enum Name PascalCase (Proto)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/enum-pascal-case.md

This snippet shows an enum definition that complies with the ENUM_PASCAL_CASE rule. The enum name 'FooBar' correctly uses PascalCase.

```proto
syntax = "proto3";

package foo;

enum FooBar {
    BAR = 0;
    BAZ = 1;
}
```

--------------------------------

### Bad RPC Response Naming (Proto)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/rpc-response-standard-name.md

Example of an RPC service definition where the response message is not named according to the MethodResponse standard, using just the message type name instead.

```proto
syntax = "proto3";

service Foo {
    rpc GetFoo (GetFooRequest) returns (Foo) {}
}
```

--------------------------------

### Compliant RPC definition (no client streaming) in Proto

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/rpc-no-client-streaming.md

This example shows a Protocol Buffer service definition with an RPC method that does not use client streaming (`BarRequest`), which complies with the RPC_NO_CLIENT_STREAMING rule.

```proto
syntax = "proto3";

service Foo {
    rpc Bar (BarRequest) returns (BarResponse) {} // [!code focus]
}
```

--------------------------------

### Good Example: Enum Value With Prefix (Proto)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/enum-value-prefix.md

Demonstrates a Protocol Buffer enum definition where the value 'FOO_BAR' is correctly prefixed with the enum name 'Foo', adhering to the ENUM_VALUE_PREFIX rule.

```proto
syntax = "proto3";

enum Foo {
    FOO_BAR = 0; // [!code focus]
}
```

--------------------------------

### Good Example - With Field Comments (Proto)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/comment-field.md

Shows a compliant Protocol Buffer message definition where each field has an associated comment, satisfying the requirements of the linter rule.

```proto
syntax = "proto3";

message Foo {
    // bar field for bar logic // [!code focus]
    string bar = 1; 
    // baz field for baz logic // [!code focus]
    string baz = 2; 
}
```

--------------------------------

### Bad Example: Enum Values Without Comments (Proto)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/comment-enum-value.md

Demonstrates a Protocol Buffer enum definition that violates the COMMENT_ENUM_VALUE rule by not including comments for its values.

```proto
syntax = "proto3";

enum Foo {
    BAR = 0;
    BAZ = 1;
}
```

--------------------------------

### Non-compliant RPC definition (client streaming) in Proto

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/rpc-no-client-streaming.md

This example shows a Protocol Buffer service definition with an RPC method that uses client streaming (`stream BarRequest`), which violates the RPC_NO_CLIENT_STREAMING rule.

```proto
syntax = "proto3";

service Foo {
    rpc Bar (stream BarRequest) returns (BarResponse) {}
}
```

--------------------------------

### Bad Example: Enum Value Missing Prefix (Proto)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/enum-value-prefix.md

Demonstrates a Protocol Buffer enum definition where the value 'BAR' is not prefixed with the enum name 'Foo', violating the ENUM_VALUE_PREFIX rule.

```proto
syntax = "proto3";

enum Foo {
    BAR = 0;
}
```

--------------------------------

### Good Example: Using Regular Import in Proto

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/import-no-public.md

This snippet shows the correct way to import another proto file (`import "bar.proto";`) without using the `public` keyword. This adheres to the IMPORT_NO_PUBLIC linter rule.

```proto
syntax = "proto3";

package foo;

import "bar.proto"; // [!code focus]
```

--------------------------------

### Bad Example - Missing Field Comments (Proto)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/comment-field.md

Illustrates a Protocol Buffer message definition that violates the rule by not including comments for its fields, which would be flagged by the linter.

```proto
syntax = "proto3";

message Foo {
    string bar = 1;
    string baz = 2;
}
```

--------------------------------

### Bad Example: Using Public Import in Proto

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/import-no-public.md

This snippet demonstrates the incorrect usage of a public import (`import public "bar.proto";`) which violates the IMPORT_NO_PUBLIC linter rule. Public imports are disallowed by this rule.

```proto
syntax = "proto3";

package foo;

import public "bar.proto";
```

--------------------------------

### Defining a Protobuf Message without Comments (Bad Example)

Source: https://github.com/easyp-tech/site/blob/main/docs/guide/cli/linter/rules/comment-message.md

This protobuf snippet defines a simple message `Foo` with two fields, `bar` and `baz`, but lacks any comments explaining the message or its fields, violating the COMMENT_MESSAGE rule.

```protobuf
syntax = "proto3";

message Foo {
    string bar = 1;
    string baz = 2;
}
```