Add files via upload

Author: brandonhimpfen

f.md

@@ -0,0 +1,50 @@
+# F# Style Guide
+
+[![Buy Me A Coffee](https://srv-cdn.himpfen.io/badges/buymeacoffee/buymeacoffee-flat.svg)](https://tinyurl.com/2h9aktmd)   [![Ko-Fi](https://srv-cdn.himpfen.io/badges/kofi/kofi-flat.svg)](https://tinyurl.com/d4xnrptz)   [![PayPal](https://srv-cdn.himpfen.io/badges/paypal/paypal-flat.svg)](https://tinyurl.com/mr22naua)   [![Stripe](https://srv-cdn.himpfen.io/badges/stripe/stripe-flat.svg)](https://tinyurl.com/e8ymxdw3)
+
+## Naming Conventions
+- Use PascalCase for module names and type names.
+- Use camelCase for function names, method names, and variable names.
+- Use uppercase abbreviations for acronyms in names (e.g., HTTP, XML).
+
+## Indentation and Formatting
+- Use 4 spaces for indentation (no tabs).
+- Limit line length to 100 characters.
+- Break long lines with appropriate indentation.
+- Put opening braces on the same line as the declaration.
+
+## Commenting
+- Use `///` for XML documentation comments.
+- Use `//` for single-line comments.
+- Use `(* ... *)` for multi-line comments.
+
+## Pattern Matching and Discriminated Unions
+- Use pattern matching instead of `if-then-else` chains whenever possible.
+- Define discriminated union cases in uppercase.
+- Use indentation to make the pattern matching code readable.
+
+## Immutable Data and Immutability
+- Prefer immutability whenever possible.
+- Use `let` bindings for immutable values.
+- Avoid using mutable variables.
+
+## Function Composition
+- Use the `|>` operator for function composition.
+- Prefer function composition over nested function calls.
+
+## Error Handling
+- Use the `Result<'T, 'TError>` type for error handling.
+- Use `Option<'T>` for optional values.
+- Avoid throwing exceptions for normal control flow.
+
+## Concurrency and Asynchronous Programming
+- Use `async` and `await` for asynchronous programming.
+- Use `Task<'T>` for asynchronous computations.
+- Use `Async<'T>` for asynchronous workflows.
+
+## Miscellaneous
+- Avoid unnecessary type annotations.
+- Use meaningful names for variables and functions.
+- Write concise and readable code.
+- Follow functional programming principles.
+- Use whitespace to improve code readability.

julia.md

@@ -0,0 +1,70 @@
+# Julia Programming Style Guide
+
+[![Buy Me A Coffee](https://srv-cdn.himpfen.io/badges/buymeacoffee/buymeacoffee-flat.svg)](https://tinyurl.com/2h9aktmd)   [![Ko-Fi](https://srv-cdn.himpfen.io/badges/kofi/kofi-flat.svg)](https://tinyurl.com/d4xnrptz)   [![PayPal](https://srv-cdn.himpfen.io/badges/paypal/paypal-flat.svg)](https://tinyurl.com/mr22naua)   [![Stripe](https://srv-cdn.himpfen.io/badges/stripe/stripe-flat.svg)](https://tinyurl.com/e8ymxdw3)
+
+## Naming Conventions
+
+- Use lowercase letters and underscores for variable and function names: `my_variable`, `my_function`.
+- Use descriptive and meaningful names.
+- Avoid single-character variable names except for loop counters or generic iterators.
+- Use camel case for struct and type names: `MyStruct`, `MyType`.
+- Prefix boolean variables with "is" or "has": `is_ready`, `has_data`.
+
+## Formatting
+
+- Use 4 spaces for indentation (no tabs).
+- Limit lines to 80 characters or less.
+- Use spaces around operators and after commas, e.g., `x = 10 + y`, `my_function(arg1, arg2)`.
+- Put a space after a comma in function arguments list.
+- Use consistent and clear spacing for function calls and definitions.
+
+## Comments
+
+- Use comments to explain complex logic or clarify code.
+- Write comments in complete sentences.
+- Avoid obvious or redundant comments that merely repeat the code.
+
+## Function and Macro Definitions
+
+- Add a space between function or macro name and opening parenthesis: `my_function(arg1, arg2)`.
+- Use lowercase for function and macro names.
+- Separate arguments with commas and align them vertically if they span multiple lines.
+- Use a single space after the comma separating a function argument.
+
+## Control Flow
+
+- Use `if`, `elseif`, and `else` for conditional statements.
+- Put spaces around operators within conditions: `if x > 0`.
+- Use `end` to close conditional blocks.
+- Use `for` and `while` loops for iteration.
+- Use `break` to exit loops prematurely.
+- Use `continue` to skip the current iteration in a loop.
+
+## Error Handling
+
+- Use `try`, `catch`, and `finally` for error handling.
+- Be specific with error types when catching exceptions.
+- Avoid using `catchall` unless absolutely necessary.
+
+## Documentation
+
+- Use docstrings to document functions, macros, and types.
+- Write clear and concise descriptions of the purpose, arguments, and return values.
+- Include examples and provide explanations for complex behaviors.
+- Use Markdown formatting in docstrings for formatting and readability.
+
+## Testing
+
+- Write tests for your code using the `Test` module or a testing framework.
+- Separate tests into logical sections and provide descriptive names.
+- Include both positive and negative test cases.
+- Ensure tests are reproducible and independent of each other.
+
+## Miscellaneous
+
+- Follow the official Julia style guide unless specified otherwise.
+- Use type annotations for function arguments and return types when it improves clarity.
+- Use whitespace to improve code readability.
+- Refactor code to improve clarity and maintainability.
+- Keep lines of code concise and avoid excessive nesting.
+

python.md

@@ -0,0 +1,64 @@
+# Python Programming Style Guide
+
+[![Buy Me A Coffee](https://srv-cdn.himpfen.io/badges/buymeacoffee/buymeacoffee-flat.svg)](https://tinyurl.com/2h9aktmd)   [![Ko-Fi](https://srv-cdn.himpfen.io/badges/kofi/kofi-flat.svg)](https://tinyurl.com/d4xnrptz)   [![PayPal](https://srv-cdn.himpfen.io/badges/paypal/paypal-flat.svg)](https://tinyurl.com/mr22naua)   [![Stripe](https://srv-cdn.himpfen.io/badges/stripe/stripe-flat.svg)](https://tinyurl.com/e8ymxdw3)
+
+This style guide provides guidelines for writing Python code that is readable, maintainable, and consistent.
+
+## Table of Contents
+1. [Introduction](#introduction)
+2. [Naming Conventions](#naming-conventions)
+3. [Code Formatting](#code-formatting)
+4. [Comments](#comments)
+5. [Function and Method Definitions](#function-and-method-definitions)
+6. [Imports](#imports)
+7. [Exceptions](#exceptions)
+8. [Whitespace](#whitespace)
+9. [Miscellaneous](#miscellaneous)
+
+## Naming Conventions
+- Use `lowercase_with_underscores` for variable and function names.
+- Use `CAPITALIZED_WITH_UNDERSCORES` for constants.
+- Use `CamelCase` for class names.
+- Avoid single-character names, unless they have a well-defined meaning.
+- Avoid using reserved keywords as names.
+
+## Code Formatting
+- Use 4 spaces for indentation (avoid tabs).
+- Limit lines to a maximum of 79 characters.
+- Use a single space around operators and after commas.
+- Use blank lines to separate logical sections of code.
+
+## Comments
+- Use comments to explain non-obvious code behavior.
+- Write self-explanatory code that reduces the need for comments.
+- Use complete sentences and proper grammar in comments.
+
+## Function and Method Definitions
+- Use descriptive names for functions and methods.
+- Add a docstring to describe the purpose, inputs, and outputs of the function.
+- Limit the number of arguments to keep functions concise.
+
+## Imports
+- Import modules on separate lines, grouped in the following order:
+    1. Standard library imports.
+    2. Third-party library imports.
+    3. Local application imports.
+- Avoid using wildcard imports (`from module import *`).
+
+## Exceptions
+- Catch specific exceptions instead of using a bare `except` clause.
+- Avoid catching and swallowing exceptions silently.
+
+## Whitespace
+- Use a single blank line to separate logical sections of code.
+- Use blank lines sparingly within functions to improve readability.
+- Avoid excessive whitespace at the end of lines or empty lines at the end of files.
+
+## Miscellaneous
+- Be consistent with the style guide within a project.
+- Write code that is easy to understand and maintain.
+- Refactor code to improve readability and eliminate code duplication.
+
+---
+
+This style guide is inspired by the [PEP 8](https://www.python.org/dev/peps/pep-0008/) style guide with a few additional recommendations.

swift.md

@@ -0,0 +1,40 @@
+# Swift Style Guide
+
+[![Buy Me A Coffee](https://srv-cdn.himpfen.io/badges/buymeacoffee/buymeacoffee-flat.svg)](https://tinyurl.com/2h9aktmd)   [![Ko-Fi](https://srv-cdn.himpfen.io/badges/kofi/kofi-flat.svg)](https://tinyurl.com/d4xnrptz)   [![PayPal](https://srv-cdn.himpfen.io/badges/paypal/paypal-flat.svg)](https://tinyurl.com/mr22naua)   [![Stripe](https://srv-cdn.himpfen.io/badges/stripe/stripe-flat.svg)](https://tinyurl.com/e8ymxdw3)
+
+## Table of Contents
+1. [Naming Conventions](#naming-conventions)
+2. [Formatting](#formatting)
+3. [Comments](#comments)
+4. [Control Flow](#control-flow)
+5. [Error Handling](#error-handling)
+
+## Naming Conventions
+- Use descriptive names for variables, functions, and types.
+- Follow camel case for variable and function names (e.g., `myVariable`, `calculateResult()`).
+- Use uppercase camel case for type names (e.g., `MyClass`, `PersonModel`).
+- Prefix class properties with `self` to differentiate from method arguments and local variables.
+
+## Formatting
+- Indent using 4 spaces.
+- Use spaces around operators and after commas.
+- Place opening braces on the same line as the associated statement or declaration.
+- Place `else` statements on the same line as the closing brace of the previous `if` statement.
+
+## Comments
+- Use `//` for single-line comments and `/* ... */` for multi-line comments.
+- Write descriptive comments that explain the purpose of the code.
+- Avoid excessive commenting for obvious or self-explanatory code.
+
+## Control Flow
+- Use `if` and `guard` statements for conditions and early exits.
+- Prefer the `for-in` loop for iterating over collections.
+- Use `switch` statements for multiple conditions with associated values.
+- Use `defer` to clean up resources or perform actions before exiting a scope.
+
+## Error Handling
+- Use Swift's `try-catch` mechanism for handling errors.
+- Avoid using exceptions for flow control.
+- Create custom error types for specific error cases.
+- Use `throws` in function declarations to indicate that it can throw an error.
+

typescript.md

@@ -0,0 +1,87 @@
+# TypeScript Style Guide
+
+[![Buy Me A Coffee](https://srv-cdn.himpfen.io/badges/buymeacoffee/buymeacoffee-flat.svg)](https://tinyurl.com/2h9aktmd)   [![Ko-Fi](https://srv-cdn.himpfen.io/badges/kofi/kofi-flat.svg)](https://tinyurl.com/d4xnrptz)   [![PayPal](https://srv-cdn.himpfen.io/badges/paypal/paypal-flat.svg)](https://tinyurl.com/mr22naua)   [![Stripe](https://srv-cdn.himpfen.io/badges/stripe/stripe-flat.svg)](https://tinyurl.com/e8ymxdw3)
+
+This guide provides a set of guidelines and best practices for writing TypeScript code. Adhering to these standards will improve code readability, maintainability, and collaboration within your project.
+
+## Table of Contents
+
+1. [General Guidelines](#general-guidelines)
+2. [Naming Conventions](#naming-conventions)
+3. [Types](#types)
+4. [Interfaces](#interfaces)
+5. [Classes](#classes)
+6. [Functions](#functions)
+7. [Variables](#variables)
+8. [Modules](#modules)
+9. [Error Handling](#error-handling)
+10. [Formatting](#formatting)
+
+## General Guidelines
+
+- Always use strict mode by enabling the `strict` compiler option.
+- Use meaningful and descriptive names for variables, functions, classes, etc.
+- Keep lines of code short and concise. Aim for a maximum of 80 characters per line.
+- Comment your code to explain complex logic or any non-obvious behavior.
+
+## Naming Conventions
+
+- Use camelCase for variables, functions, and class members.
+- Use PascalCase for classes, interfaces, and type names.
+- Use uppercase snake case for constants and enum values.
+- Prefix interfaces with `I`.
+- Use clear and descriptive names, even if it results in longer names.
+
+## Types
+
+- Prefer TypeScript's built-in types (`string`, `number`, `boolean`, etc.) over their JavaScript counterparts (`String`, `Number`, `Boolean`, etc.).
+- Use union types (`|`) and intersection types (`&`) when appropriate.
+- Avoid using the `any` type whenever possible. Instead, be explicit about the types.
+- Use type inference when the type is obvious and doesn't harm readability.
+
+## Interfaces
+
+- Define interfaces for objects or classes that share a common structure.
+- Name interfaces using PascalCase.
+- Use optional properties (`?`) or default values sparingly.
+- Prefer readonly properties where applicable.
+
+## Classes
+
+- Use classes to represent complex data structures or encapsulate behavior.
+- Use the `public` modifier explicitly for clarity, as it's the default access modifier.
+- Keep the number of properties and methods in a class to a minimum for better cohesion.
+- Prefer composition over inheritance, unless there's a strong need for inheritance.
+
+## Functions
+
+- Use arrow functions (`() => {}`) for short, concise functions and when lexical scoping is required.
+- Use regular functions (`function () {}`) for methods and when dynamic scoping is needed.
+- Prefer explicit return types for functions to enhance readability.
+- Use default parameters to provide optional arguments when it makes sense.
+
+## Variables
+
+- Use `const` for values that should not be reassigned.
+- Use `let` for variables that can be reassigned.
+- Avoid using `var` unless you have a specific reason to use it.
+
+## Modules
+
+- Use ES modules (`import`/`export`) for managing dependencies.
+- Prefer named exports over default exports to encourage explicit imports.
+- Organize imports in alphabetical order and group them by third-party dependencies and local modules.
+
+## Error Handling
+
+- Use proper error handling techniques, such as `try-catch` blocks, for handling expected errors.
+- Throw specific error types instead of generic `Error` objects.
+- Avoid swallowing errors by using empty `catch` blocks.
+
+## Formatting
+
+- Use two spaces for indentation. Do not use tabs.
+- Use single quotes (`'`) for string literals, unless escaping is necessary.
+- Use semicolons at the end of each statement.
+- Put spaces around operators (`+, -, *, /, =, ===, etc.`) for improved readability.
+- Break long statements or expressions into multiple lines for better readability.