Adding content to 100-clean-code-principles

src/roadmaps/software-design-architecture/content/100-clean-code-principles/101-be-consistent.md

@@ -1 +1,7 @@
-# Be consistent
+# Be Consistent
+
+Being consistent in system design architecture refers to maintaining a consistent pattern or structure in the design of a system. This can include using consistent naming conventions, data structures, and interfaces throughout the system, as well as adhering to established design principles and best practices. Consistency can help to make the system more maintainable, understandable, and extendable.
+
+Learn more from the following links:
+
+- [Strongly Consistent vs Eventually Consistent for System Design](https://medium.com/double-pointer/strongly-consistent-vs-eventually-cosistent-for-system-design-interview-f67f9c1882ed)

src/roadmaps/software-design-architecture/content/100-clean-code-principles/102-meaningful-names.md

@@ -1 +1,7 @@
-# Meaningful names
+# Meaningful Names
+
+Meaningful names in system design architecture refer to the practice of giving clear and descriptive names to different components of a system, such as variables, functions, and classes. This can help to make the system more understandable and maintainable by clearly communicating the purpose of each component and its intended usage.
+
+Learn more from the following links:
+
+- [What’s in a Name? - Architecture](https://www.innoq.com/en/blog/whats-in-a-name-architecture/)

src/roadmaps/software-design-architecture/content/100-clean-code-principles/103-indentation-and-code-style.md

@@ -1 +1,9 @@
-# Indentation and code style
+# Indentation and Code Style
+
+Indentation and code style in system design architecture refer to the way that code is structured and formatted. Indentation is the practice of using whitespace to visually group related lines of code together, making it easier to read and understand the structure of the code. Code style refers to the conventions and guidelines used to format and structure code, such as naming conventions, commenting, and use of whitespace.
+
+Having a consistent indentation and code style can help to make the code more readable and understandable, which can improve the maintainability of the system.
+
+Learn mor from the following links:
+
+- [Coding Standards and Guidelines](https://www.geeksforgeeks.org/coding-standards-and-guidelines/)

src/roadmaps/software-design-architecture/content/100-clean-code-principles/104-keep-it-small.md

@@ -1 +1,3 @@
-# Keep it small
+# Keep it Small
+
+Keep it small in system design architecture refers to the practice of designing and implementing small, focused components that serve a specific purpose, rather than large, monolithic components that try to do everything. This can help to improve the maintainability and scalability of the system by making it easier to understand, test, and modify individual components.

src/roadmaps/software-design-architecture/content/100-clean-code-principles/105-pure-functions.md

@@ -1 +1,10 @@
-# Pure functions
+# Pure Functions
+
+A pure function is a specific type of function that meets the following criteria:
+
+1. It takes some input, known as arguments, and returns a value or output.
+2. It does not cause any observable side effects, such as modifying the state of the system or interacting with external resources.
+3. Given the same input, it will always return the same output.
+4. It does not depend on any state or variables that are outside of its scope.
+
+Pure functions are considered to be more predictable and easier to test, as their behavior is determined solely by the input they receive and their internal logic. They also make it easier to reason about the behavior of a program, since the output of a pure function is not affected by any external factors. Pure functions are often used in functional programming, where they are considered a key principle. They are also useful in concurrent and parallel programming, as they are less prone to race conditions and other concurrency-related issues.

src/roadmaps/software-design-architecture/content/100-clean-code-principles/106-minimize-cyclomatic-complexity.md

@@ -1 +1,18 @@
-# Minimize cyclomatic complexity
+# Minimize Cyclomatic Complexity
+
+Cyclomatic complexity is a measure of the structural complexity of a program, which is determined by the number of linearly independent paths through a program's control flow. High cyclomatic complexity can make a program difficult to understand, test, and maintain, so it's often desirable to minimize it in system architecture.
+
+Here are some ways to minimize cyclomatic complexity in system architecture:
+
+- Break down complex functions into smaller, simpler functions that perform specific tasks.
+- Use control structures, such as if-else statements and loops, in a consistent and predictable way.
+- Use functional programming concepts and techniques, such as immutability and pure functions, to reduce the need for complex control flow.
+- Use design patterns, such as the state pattern, to simplify complex control flow.
+- Regularly review the code and refactor it to simplify the control flow.
+- Use static code analysis tools that can detect and report high cyclomatic complexity in the code.
+
+By following these best practices, the system architecture will be more maintainable, testable, and less error-prone.
+
+Learn more from the following links:
+
+- [How to reduce cyclomatic complexity?](https://kasp9023.medium.com/how-to-make-your-code-more-readable-focus-on-the-happy-path-and-reduce-cyclomatic-complexity-66802b8897b5)

src/roadmaps/software-design-architecture/content/100-clean-code-principles/107-avoid-passing-nulls-booleans.md

@@ -1 +1,11 @@
-# Avoid passing nulls booleans
+# Avoid Passing Nulls Booleans
+
+Passing nulls or Booleans can lead to unexpected behavior and difficult-to-debug errors in a program. Here are some ways to avoid passing nulls or Booleans in system architecture:
+
+- Use Optionals or Maybe types instead of nulls to indicate the absence of a value. This makes it clear when a value is missing and prevents null reference exceptions.
+- Use a default value for function arguments instead of allowing them to be null or Boolean. This eliminates the need to check for null or Boolean values and reduces the potential for errors.
+- Use the Null Object pattern to replace null values with a special object that has a defined behavior. This eliminates the need to check for null values and makes the code more readable.
+- Use the Ternary operator (?:) instead of if-else statements when working with Booleans. This can make the code more concise and easier to read.
+- Use the assert function to check the validity of function arguments and throw an exception if they are invalid.
+
+By following these best practices, the system architecture will be more robust and less error-prone.

src/roadmaps/software-design-architecture/content/100-clean-code-principles/108-keep-framework-code-distant.md

@@ -1 +1,17 @@
-# Keep framework code distant
+# Keep Framework Code Distant
+
+Keeping framework code distant refers to separating the application's code from the framework's code. By doing so, it makes it easier to maintain, test, and upgrade the application's codebase and the framework independently.
+
+Here are some ways to keep framework code distant in system architecture:
+
+1. Use an abstraction layer to separate the application code from the framework code. This allows the application code to be written without the need to know the specifics of the framework.
+2. Use dependency injection to decouple the application code from the framework code. This allows the application code to use the framework's functionality without having to instantiate the framework objects directly.
+3. Avoid using framework-specific libraries or classes in the application code. This makes it easier to switch to a different framework in the future if needed.
+4. Use a standard interface for the application code to interact with the framework. This allows the application code to be written without the need to know the specifics of the framework.
+5. Keep the application and the framework code in separate projects and/or repositories.
+
+By following these best practices, the system architecture will be more maintainable, testable, and less error-prone, and it will be easier to upgrade or switch the framework if needed.
+
+Learn more from the following links:
+
+- [Clean architecture](https://pusher.com/tutorials/clean-architecture-introduction/)

src/roadmaps/software-design-architecture/content/100-clean-code-principles/109-use-correct-constructs.md

@@ -1 +1,18 @@
-# Use correct constructs
+# Use Correct Constructs
+
+Using the correct constructs in system architecture is important for ensuring that the code is clear, maintainable, and efficient. Some common constructs include variables, loops, conditionals, and functions.
+
+Here are some ways to use correct constructs in system architecture:
+
+1. Use variables to store and manipulate data in a clear and organized manner.
+2. Use loops to repeat operations on a set of data.
+3. Use conditionals to control the flow of the program based on certain conditions.
+4. Use functions to encapsulate specific functionality and make the code more reusable.
+5. Use appropriate data structures such as arrays, lists, maps, and sets to organize and manage data.
+6. Use exception handling to handle and recover from errors in a predictable and consistent manner.
+
+By following these best practices, the system architecture will be more maintainable, testable, and less error-prone, and it will be easier to read and understand the code.
+
+Learn more from the following links:
+
+- [Architecture Constructs](https://csrc.nist.gov/glossary/term/architecture_constructs)

src/roadmaps/software-design-architecture/content/100-clean-code-principles/110-keep-tests-independent.md

@@ -1 +1,18 @@
-# Keep tests independent
+# Keep Tests Independent
+
+Keeping tests independent is important in system architecture because it ensures that the tests are reliable, repeatable, and easy to maintain. When tests are independent, a change in one test will not affect the results of other tests.
+
+Here are some ways to keep tests independent in system architecture:
+
+1. Use dependency injection to decouple the test code from the application code. This allows the tests to be run without the need to instantiate the application objects directly.
+2. Use mocks or stubs to isolate the test from external dependencies such as databases, APIs, or other services.
+3. Use test data that is self-contained and does not rely on external data or state.
+4. Use a test framework that supports running tests in parallel, so that the tests can be run independently of each other.
+5. Use test-driven development (TDD), which involves writing tests before writing the application code. This ensures that the tests are independent and that the code is written with testability in mind.
+6. Avoid global state and shared mutable state as it may cause unexpected results.
+
+By following these best practices, the system architecture will be more maintainable, testable, and less error-prone, and it will be easier to run and manage the tests.
+
+Learn more from the following links:
+
+- [Independent Testing in Software Engineering](https://www.geeksforgeeks.org/independent-testing-in-software-engineering/)

src/roadmaps/software-design-architecture/content/100-clean-code-principles/111-use-meaningful-names.md

@@ -1 +1,18 @@
-# Use meaningful names
+# Use Meaningful Names
+
+Using meaningful names in system architecture is important for making the code clear, readable, and easy to understand. Meaningful names can help to convey the intent and function of variables, functions, classes, and other elements of the code.
+
+Here are some ways to use meaningful names in system architecture:
+
+1. Use descriptive and meaningful names for variables, functions, classes, and other elements of the code.
+2. Use consistent naming conventions throughout the codebase, such as camelCase for variables and PascalCase for functions and classes.
+3. Use abbreviations and acronyms sparingly and only if they are widely understood.
+4. Use meaningful prefixes or suffixes to indicate the type or purpose of a variable or function, such as "is" or "get" for boolean variables or "list" for array variables
+5. Avoid using single letter variable names or generic names, such as "temp" or "x" that do not convey any meaning.
+6. Avoid using overly long or complex names that make the code harder to read.
+
+By following these best practices, the system architecture will be more maintainable, testable, and less error-prone, and it will be easier to read and understand the code.
+
+Learn more from the following links:
+
+- [How to Write Meaningful Variable Names?](https://workat.tech/machine-coding/tutorial/writing-meaningful-variable-names-clean-code-za4m83tiesy0)

src/roadmaps/software-design-architecture/content/100-clean-code-principles/112-code-by-actor.md

@@ -1 +1,7 @@
-# Code by actor
+# Code by Actor
+
+"Code by Actor" is a software development technique that encourages developers to organize their code around the actors or entities that interact with it. Actors can be users, systems, or processes that perform a specific role or function within the application. This approach helps to create a clear separation of concerns, making the code more modular, reusable, and easier to understand.
+
+Learn more from the following links:
+
+- [Actor Model Architecture](https://awesome-architecture.com/actor-model-architecture/actor-model-architecture/)

src/roadmaps/software-design-architecture/content/100-clean-code-principles/113-command-query-separation.md

@@ -1 +1,7 @@
-# Command query separation
+# Command Query Separation
+
+Command-Query Separation (CQS) is a software design principle that separates the responsibilities of a method or function into two categories: commands and queries. Commands are methods that change the state of the system, while queries are methods that return information but do not change the state of the system.
+
+Learn more from the following links:
+
+- [CQRS Pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/cqrs)

src/roadmaps/software-design-architecture/content/100-clean-code-principles/114-avoid-hasty-abstractions.md

@@ -1 +1,19 @@
-# Avoid hasty abstractions
+# Avoid Hasty Abstractions
+
+Creating abstractions is an important part of software development, but creating too many abstractions or creating them too early can lead to unnecessary complexity and make the code harder to understand and maintain.
+
+Here are some ways to avoid hasty abstractions in system architecture:
+
+1. Understand the problem that needs to be solved before creating an abstraction.
+2. Start with a simple solution and only create an abstraction when it becomes clear that the solution is becoming too complex.
+3. Use code refactoring techniques to simplify the code before creating an abstraction.
+4. Avoid creating abstractions for the sake of creating abstractions.
+5. Use established design patterns and practices when creating abstractions, but do not force them into the code.
+6. Use automated testing to ensure that the abstraction does not introduce new bugs or break existing functionality.
+7. Create abstraction in a way that it's easy to test, debug, and reason about.
+
+By following these best practices, the system architecture will be more maintainable, testable, and less error-prone, and it will be easier to read and understand the code.
+
+Learn more from the following links:
+
+- [Avoiding Hasty Abstractions (AHA programming)](https://dev.to/cher/avoiding-hasty-abstractions-aha-programming-3d3b)

src/roadmaps/software-design-architecture/content/100-clean-code-principles/index.md

@@ -1 +1,21 @@
-# Clean code principles
+# Clean Code Principles
+
+Clean code is code that is easy to read, understand, and maintain. It follows a set of principles that are designed to make the code more readable, testable, and less error-prone. Some of the key principles of clean code include:
+
+1. Clarity: The code should be easy to read and understand.
+2. Simplicity: The code should be as simple as possible, avoiding unnecessary complexity.
+3. Comments: Comments should be used sparingly and only when necessary to explain complex or non-obvious code.
+4. Naming: Variables, functions, and classes should have meaningful and descriptive names.
+5. Formatting: The code should be consistently formatted to improve readability.
+6. Functionality: The code should be organized into small, single-purpose functions and classes.
+7. Error handling: The code should handle errors in a consistent and predictable way.
+8. Testing: The code should be testable and have a high test coverage.
+9. Reusability: The code should be designed to be reusable and modular.
+10. Performance: The code should be designed to be efficient and performant.
+
+By following these principles, the system architecture will be more maintainable, testable, and less error-prone, and it will be easier to read and understand the code.
+
+
+Learn more from the following links:
+
+- [Introduction to Clean Code & Software Design Principles](https://workat.tech/machine-coding/tutorial/introduction-clean-code-software-design-principles-nwu4qqc63e09)