<commit_before># Istio API Style Guide

This page defines the design guidelines for Istio APIs. They apply to
all proto files in the Istio project. Developers who create their APIs
using Istio may find these guidelines useful as well.

Since Istio APIs are based on _proto3_ and _gRPC_, we will use
Google's [API Design Guide](https://cloud.google.com/apis/design) as
the baseline. Because Envoy APIs also uses the same baseline, the
commonality across Envoy, Istio, proto3 and gRPC will greatly help
developer experience in the long term.

In addition to Google's guide, the following conventions should be
followed for Istio APIs.

## Naming

Having consistent naming improves understanding of the APIs and reduce
churns on the API design. Istio APIs should follow the following
naming convention:

* Package names must use `lowercase` without any `_`. Singular words
  are recommended to avoid mixture of plural and singular words in
  a package name. For example, `istio.network.config.v1`.

* Message/enum/method names must use `CamelCase` with embedded
  acronyms. For example, `HttpRequest`.

* Enum values must use `UPPERCASE_WITH_UNDERSCORE`. For example,
  `INT_TYPE`.

* Field names must use `lowercase_with_underscore`. For example,
  `display_name`.

* Avoid using postpositive adjectives. For example,
  `collected_items` is recommended over `items_collected`.

## Versioning

When defining Kubernetes Custom Resource Definition (CRD) using<commit_msg>Update STYLE-GUIDE.md (#337)<commit_after># Istio API Style Guide

This page defines the design guidelines for Istio APIs. They apply to
all proto files in the Istio project. Developers who create their APIs
using Istio may find these guidelines useful as well.

Since Istio APIs are based on _proto3_ and _gRPC_, we will use
Google's [API Design Guide](https://cloud.google.com/apis/design) as
the baseline. Because Envoy APIs also uses the same baseline, the
commonality across Envoy, Istio, proto3 and gRPC will greatly help
developer experience in the long term.

In addition to Google's guide, the following conventions should be
followed for Istio APIs.

## Naming

Having consistent naming improves understanding of the APIs and reduce
churns on the API design. Istio APIs should follow the following
naming convention:

* Package names must use `lowercase` without any `_`. Singular words
  are recommended to avoid mixture of plural and singular words in
  a package name. For example, `istio.network.config.v1`.

* Message/enum/method names must use `CamelCase` with embedded
  acronyms. For example, `HTTPRequest`.

* Enum values must use `UPPERCASE_WITH_UNDERSCORE`. For example,
  `INT_TYPE`.

* Field names must use `lowercase_with_underscore`. For example,
  `display_name`.

* Avoid using postpositive adjectives. For example,
  `collected_items` is recommended over `items_collected`.

## Versioning

When defining Kubernetes Custom Resource Definition (CRD) using
{'fraction_non_alphanumeric': 0.05870376654224635, 'fraction_numerical': 0.003053953172718018, 'mean_word_length': 4.76908023483366, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 2, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '7269027', 'n_tokens_mistral': 825, 'n_tokens_neox': 803, 'n_words': 387}