<commit_before># Graze Coding Standards

This document describes the coding standards of Graze across its common languages to be adhered to and enforced by the Graze tech team, any violation of standards must be justified by the developer and exceptions are allowed for cases where it is unavoidable, such as in the case of third-party integrations.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](http://www.ietf.org/rfc/rfc2119.txt).

## General

1. Indent size MUST be 4 space characters and MUST NOT be the tab character.
2. All files MUST end with a blank new line (the new line character).
3. All files MUST use the Unix LF (linefeed) line ending.
4. There MUST NOT be trailing whitespace.

## PHP

1. All PHP code MUST adhere to the [PSR-2 Coding Standard](http://www.php-fig.org/psr/psr-2/) (which MUST follow the [PSR-1 Coding Standard](http://www.php-fig.org/psr/psr-1/)).
2. Short array syntax (`[]` instead of `array()`) SHOULD be used.
3. All PHP code MUST adhere to the [PSR-4 Autoloading](http://www.php-fig.org/psr/psr-4/) Standard.
4. Variable names MUST be camelCase and not snake_case or StUdLyCaSe or UpperCamelCase.
5. Scripts MUST be named in camelCase describing their primary function.
6. Non-static functions MUST NOT be called statically.
7. Static functions MUST NOT be called non-statically.
8. Comments SHOULD be used to provide explanation for “why” rather than “how” and SHOULD be used when there isn’t a way to make the code simpler or self-documenting.
9. Docblocks for functions / methods MUST exist where the function / method has arguments or a return value and MUST use the appropriate tags (@param, @return) to denote that. Developers making modifications to a function / method are tasked with ensuring that the docblock is up-to-date.
10. Functions / methods / classes that are sufficiently complex (i.e. not self-documenting) SHOULD have a docblock explaining how to use the function / method / class.
11. Code ‘hacks’ (code that is intended to be temporary and handles very specific cases) SHOULD NOT exist but should they have to occur with no way around them then the code that is ‘hacky’ MUST be accompanied with a comment explaining that it is a hack and explaining why it has to be there, including a @todo tag to explain what the developer needs to do to resolve the hack.
12. Standard library code MUST be as generic as possible and not application-specific.
13. Nested ternary operators MUST NOT be used.
14. PHP file encoding must be UTF-8.
15. If statements which need to span multiple lines should be split as follows:

```php
if ($longVariableNameNumber1
  && $longVariableNameNumber2
  && $longVariableNameNumber3
  && $longVariableNameNumber4
  || $longVariableNameNumber5) {
  // body of control structure
}
```

## Views

1. MUST use the .phtml extension.
2. MUST be named in camelCase.
3. SHOULD be named after the controller action that they are the view for. E.g. the view for graze.com/account/payments must be in views/graze/en/account/payments.phtml.<commit_msg>Adding a clause to prevent variable assignment in if statement expressions<commit_after># Graze Coding Standards

This document describes the coding standards of Graze across its common languages to be adhered to and enforced by the Graze tech team, any violation of standards must be justified by the developer and exceptions are allowed for cases where it is unavoidable, such as in the case of third-party integrations.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](http://www.ietf.org/rfc/rfc2119.txt).

## General

1. Indent size MUST be 4 space characters and MUST NOT be the tab character.
2. All files MUST end with a blank new line (the new line character).
3. All files MUST use the Unix LF (linefeed) line ending.
4. There MUST NOT be trailing whitespace.

## PHP

1. All PHP code MUST adhere to the [PSR-2 Coding Standard](http://www.php-fig.org/psr/psr-2/) (which MUST follow the [PSR-1 Coding Standard](http://www.php-fig.org/psr/psr-1/)).
2. Short array syntax (`[]` instead of `array()`) SHOULD be used.
3. All PHP code MUST adhere to the [PSR-4 Autoloading](http://www.php-fig.org/psr/psr-4/) Standard.
4. Variable names MUST be camelCase and not snake_case or StUdLyCaSe or UpperCamelCase.
5. Scripts MUST be named in camelCase describing their primary function.
6. Non-static functions MUST NOT be called statically.
7. Static functions MUST NOT be called non-statically.
8. Comments SHOULD be used to provide explanation for “why” rather than “how” and SHOULD be used when there isn’t a way to make the code simpler or self-documenting.
9. Docblocks for functions / methods MUST exist where the function / method has arguments or a return value and MUST use the appropriate tags (@param, @return) to denote that. Developers making modifications to a function / method are tasked with ensuring that the docblock is up-to-date.
10. Functions / methods / classes that are sufficiently complex (i.e. not self-documenting) SHOULD have a docblock explaining how to use the function / method / class.
11. Code ‘hacks’ (code that is intended to be temporary and handles very specific cases) SHOULD NOT exist but should they have to occur with no way around them then the code that is ‘hacky’ MUST be accompanied with a comment explaining that it is a hack and explaining why it has to be there, including a @todo tag to explain what the developer needs to do to resolve the hack.
12. Standard library code MUST be as generic as possible and not application-specific.
13. Nested ternary operators MUST NOT be used.
14. PHP file encoding must be UTF-8.
15. If statements which need to span multiple lines should be split as follows:

```php
if ($longVariableNameNumber1
  && $longVariableNameNumber2
  && $longVariableNameNumber3
  && $longVariableNameNumber4
  || $longVariableNameNumber5) {
  // body of control structure
}
```

16. There MUST NOT be any assignment or modification of variables in the expressions of `if` statements.

```php
if ($nutritionPlan = NutritionPlan::get(NutritionPlan::ID_NIBBLE)) {
  // not allowed
}
```

## Views

1. MUST use the .phtml extension.
2. MUST be named in camelCase.
3. SHOULD be named after the controller action that they are the view for. E.g. the view for graze.com/account/payments must be in views/graze/en/account/payments.phtml.
{'fraction_non_alphanumeric': 0.07495844038083724, 'fraction_numerical': 0.01511258878645912, 'mean_word_length': 4.134212567882079, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 8, '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': '51074', 'n_tokens_mistral': 1961, 'n_tokens_neox': 1810, 'n_words': 968}