DOCUMENTATION: Upgrade V2.10.3

Abstraction at the operational levels
Readability over Optimization

Closes: #288
Closes #290

0. Introduction/0.2 Principles.md

@@ -92,4 +92,23 @@ The Standard shall be taught man to man, not machine to man. No stylecops or ana
 The Standard shall be taught at no cost as it arrived to you at no cost. It should also be passed forward to the next engineer at no cost, regardless of their financial, social, or educational status. The Standard is pure knowledge given by the selfless to the selfless. There shall be no profiteering off of it; neither shall it be a reason for someone to belittle others or make them feel less. Teaching The Standard for profit violates it and denies the beneficiary (the violator) any further guidance from The Author.
 
 ## 0.2.8 All-In/All-Out
-The Standard must be fully embraced or entirely rejected. Any system incorporating only some aspects of The Standard will not be recognized as a Standardized system. Any system that continues to adhere to previous versions of The Standard will be obligated to elevate its standards to reclaim its status of standardization.
+The Standard must be fully embraced or entirely rejected. Any system incorporating only some aspects of The Standard will not be recognized as a Standardized system. Any system that continues to adhere to previous versions of The Standard will be obligated to elevate its standards to reclaim its status of standardization.
+
+## 0.2.9 Readability over Optimization
+Systems adhering The Standard must be written with readability in mind. Optimization is a byproduct of readability. The Standard does not enforce premature optimization. It encourages engineers to write code that is easy to read, understand, and maintain. Optimization can be done later, but readability is a must from the start.
+
+In the development of Standard complaint systems, readability should take precedence over performance optimization. While optimized code can offer slight performance gains, it often comes at the cost of complexity and reduced maintainability. Readable code, on the other hand, aligns with the foundational principles of The Standard, including Rewritability, and Level 0 principles as examples.
+
+**Key Points:**
+- Readability: Readable code is easier to understand, review, and modify, ensuring long-term maintainability.
+
+- Maintainability: Readable code is easier to understand, review, and modify, ensuring long-term maintainability.
+
+- Collaboration: Clear and concise code enhances team collaboration, allowing developers to quickly grasp and contribute to the project.
+- Error Reduction: Code that is easy to read and understand reduces the likelihood of introducing errors during maintenance and extension.
+
+- Resource Management: Performance optimizations should be handled by allocating more system resources rather than compromising code clarity.
+
+`"Programs must be written for people to read, and only incidentally for machines to execute."` This saying emphasizes the importance of writing code that is easy for humans to understand, rather than focusing solely on optimization for machines.
+
+Prioritizing readability ensures that the codebase remains approachable and manageable, supporting the project's overall quality and longevity.

1. Brokers/1. Brokers.md

@@ -208,7 +208,11 @@ You can find real-world examples of brokers in the OtripleS project [here](https
 ## 1.5 Implementation
 Here's a real-life implementation of an entire storage broker for all CRUD operations for `Student` entity:
 
-###### For IStorageBroker.cs:
+## 1.5.1 Asynchronization Abstraction
+In order to abstract at an operational level all example implementations in this section will utilize the ValueTask type to provide an asynchronization abstraction.
+This approach encourages a consistent handling of asynchronous operations across all method implementations, promoting a clean and efficient abstraction that aligns with Standard principles.
+
+##### For IStorageBroker.cs:
 ```csharp
 namespace OtripleS.Web.Api.Brokers.Storages
 {
@@ -219,7 +223,7 @@ namespace OtripleS.Web.Api.Brokers.Storages
 
 ```
 
-###### For StorageBroker.cs:
+##### For StorageBroker.cs:
 ```csharp
 using System;
 using System.Linq;
@@ -249,7 +253,8 @@ namespace OtripleS.Web.Api.Brokers.Storages
             return @object;
         }
 
-        private IQueryable<T> SelectAll<T>() where T : class => this.Set<T>();
+        private ValueTask<IQueryable<T>> SelectAllAsync<T>() where T : class =>
+            await ValueTask.FromResult(this.Set<T>());
 
         private async ValueTask<T> SelectAsync<T>(params object[] @objectIds) where T : class =>
             await this.FindAsync<T>(objectIds);
@@ -294,7 +299,7 @@ namespace OtripleS.Web.Api.Brokers.Storages
     public partial interface IStorageBroker
     {
         public ValueTask<Student> InsertStudentAsync(Student student);
-        public IQueryable<Student> SelectAllStudents();
+        public ValueTask<IQueryable<Student>> SelectAllStudentsAsync();
         public ValueTask<Student> SelectStudentByIdAsync(Guid studentId);
         public ValueTask<Student> UpdateStudentAsync(Student student);
         public ValueTask<Student> DeleteStudentAsync(Student student);
@@ -319,7 +324,8 @@ namespace OtripleS.Web.Api.Brokers.Storages
         public async ValueTask<Student> InsertStudentAsync(Student student) =>
             await InsertAsync(student);
 
-        public IQueryable<Student> SelectAllStudents() => SelectAll<Student>();
+        public async ValueTask<IQueryable<Student>> SelectAllStudentsAsync() =>
+            await SelectAllAsync<Student>();
 
         public async ValueTask<Student> SelectStudentByIdAsync(Guid studentId) =>
             await SelectAsync<Student>(studentId);
@@ -375,6 +381,14 @@ Partial classes are a feature in the C# language, but it should be possible to i
 #### 1.7.4 Are brokers the same as providers (Provider Pattern)?
 No. Providers blur the line between services (business logic) and brokers (integration layer). Brokers target particular disposable components within the system, but providers include more than just that.
 
+#### 1.7.5 Why is ValueTask preferred over Task in the implementations outlined in this section?
+ValueTask is a struct that is used to represent a task that returns a value.
+It is a value-based representation of a task that can be used to avoid allocations in the case where a task completes synchronously.
+
+In order to abstract at an operational level, all example implementations in this section utilize the ValueTask type to provide an asynchronization abstraction.
+This approach encourages a consistent handling of asynchronous operations across all method implementations, promoting a clean and efficient abstraction that aligns with the Standard principles.
+By using ValueTask, we reduce memory allocations in scenarios where the result is often available immediately, thereby enhancing performance while maintaining code clarity.
+
 
 [*] [Implementing Abstract Components (Brokers)](https://www.youtube.com/watch?v=6NlgSskQXSo)