You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .github/CONTRIBUTING.md
+17-12Lines changed: 17 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -88,17 +88,26 @@ Once a pull request has been opened, the Tempest team will:
88
88
* Install Composer
89
89
*[Fork the Tempest repository.](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/fork-a-repo)
90
90
91
-
Then in your terminal:
92
-
*`cd /path/to/your/clone`
93
-
*`composer update`
91
+
Then in your terminal run:
92
+
```shell
93
+
cd /path/to/your/clone
94
+
composer update
95
+
```
94
96
95
97
You're ready to get started!
96
98
97
-
---
99
+
### Styling Decisions
100
+
Tempest uses a modified version of PSR-12. We automate the entire styling process because we know everyone is used to different standards and workflows. To see some of the rules we enforce, check out our [CS-Fixer](https://github.com/tempestphp/tempest-framework/blob/main/.php-cs-fixer.dist.php) and [Rector](https://github.com/tempestphp/tempest-framework/blob/main/rector.php) configurations.
98
101
99
-
Please see below for some general guidelines relating to specific components of the framework.
102
+
The following outlines some other guidelines we have established for Tempest.
100
103
101
-
## Acronym Casing
104
+
#### Final and Readonly as a default
105
+
Whenever possible, classes should be `final` and `readonly`. This practice promotes immutability and prevents inadvertent changes to logic.
106
+
107
+
**Resources**
108
+
*[Why I use final](https://www.youtube.com/watch?v=HiD6CwWq5Ds&ab_channel=PHPAnnotated)
109
+
110
+
#### Acronym Casing
102
111
Tempest uses a modified version of the [.NET best practices](https://learn.microsoft.com/en-us/previous-versions/dotnet/netframework-4.0/ms229043(v=vs.100)?redirectedfrom=MSDN) for acronym casing. Please see below for our guidelines:
103
112
104
113
__Do capitalize all characters of two to three character acronyms, except the first word of a camel-cased identifier.__
@@ -110,12 +119,8 @@ A class named `UuidGenerator` is an example of a long acronym (Uuid) used as the
110
119
__Do not capitalize any of the characters of any acronyms, whatever their length, at the beginning of a camel-cased identifier.__
111
120
A class named `Uuid` is an example of a long acronym (Uuid) used as the first word of a camel-cased identifier. A parameter named `dbUsername` is an example of a short acronym (db) used as the first word of a camel-cased identifier.
112
121
113
-
## Validation Rules
114
-
Validation rules should be `final` and `readonly`. The message returned by a validation rule should not include ending
115
-
punctuation.
116
-
117
-
### Best Practices
118
-
1.__Use of `final` and `readonly`__: Ensure that validation rules are declared as final and readonly whenever possible. This practice promotes immutability and prevents inadvertent changes to the validation logic.
122
+
#### Validaton Class Formatting
123
+
1.__Use of `final` and `readonly`__: Ensure that validation rules are declared as [final and readonly](#final-and-readonly-as-a-default) whenever possible. This practice promotes immutability and prevents inadvertent changes to the validation logic.
119
124
2.__Error Message Formatting__:
120
125
-__Avoid Ending Punctuation__: When crafting error messages for validation rules, refrain from including ending punctuation such as periods, exclamation marks, or question marks. This helps in maintaining a uniform style and prevents inconsistency in error message presentation.
0 commit comments