If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/TheAlgorithms/C-Sharp shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Slowing — last commit 6mo ago

• Last commit 6mo ago
• 30+ active contributors
• Distributed ownership (top contributor 12% of recent commits)
• GPL-3.0 licensed
• CI configured
• ⚠ Slowing — last commit 6mo ago
• ⚠ GPL-3.0 is copyleft — check downstream compatibility
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live TheAlgorithms/C-Sharp repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/TheAlgorithms/C-Sharp.

What it runs against: a local clone of TheAlgorithms/C-Sharp — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in TheAlgorithms/C-Sharp | Confirms the artifact applies here, not a fork | | 2 | License is still GPL-3.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 204 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of TheAlgorithms/C-Sharp. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/TheAlgorithms/C-Sharp.git
#   cd C-Sharp
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of TheAlgorithms/C-Sharp and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "TheAlgorithms/C-Sharp(\\.git)?\\b" \\
  && ok "origin remote is TheAlgorithms/C-Sharp" \\
  || miss "origin remote is not TheAlgorithms/C-Sharp (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(GPL-3\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"GPL-3\\.0\"" package.json 2>/dev/null) \\
  && ok "license is GPL-3.0" \\
  || miss "license drift — was GPL-3.0 at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "Algorithms.Tests/Algorithms.Tests.csproj" \\
  && ok "Algorithms.Tests/Algorithms.Tests.csproj" \\
  || miss "missing critical file: Algorithms.Tests/Algorithms.Tests.csproj"
test -f ".github/workflows/ci.yml" \\
  && ok ".github/workflows/ci.yml" \\
  || miss "missing critical file: .github/workflows/ci.yml"
test -f ".editorconfig" \\
  && ok ".editorconfig" \\
  || miss "missing critical file: .editorconfig"
test -f ".github/CODEOWNERS" \\
  && ok ".github/CODEOWNERS" \\
  || miss "missing critical file: .github/CODEOWNERS"
test -f "Algorithms.Tests/GlobalUsings.cs" \\
  && ok "Algorithms.Tests/GlobalUsings.cs" \\
  || miss "missing critical file: Algorithms.Tests/GlobalUsings.cs"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 204 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~174d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/TheAlgorithms/C-Sharp"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

TheAlgorithms/C-Sharp is an educational reference implementation of 100+ classic algorithms written in C#, spanning cryptography (Ascon digest, MD2), data compression (Huffman, Burrows-Wheeler), graph theory (Dijkstra, Bellman-Ford), and encoding schemes (Caesar, Vigenere, Blowfish). It serves as a learning resource with test coverage and CI validation for each algorithm, not a production library. Two-project structure: Algorithms/ contains implementation files organized by domain (Crypto/Paddings/, Encoders/, Graph/, DataCompression/, etc.), and Algorithms.Tests/ mirrors this structure with parallel test files (e.g., Algorithms.Tests/Encoders/CaesarEncoderTests.cs tests Algorithms/Encoders/CaesarEncoder.cs). GlobalUsings.cs provides shared using statements across all tests.

Computer science students, educators teaching algorithms, junior developers learning C# best practices, and interview prep candidates studying graph algorithms and cryptographic concepts. Contributors are volunteers adding educational implementations across math, crypto, and data structure domains.

Actively maintained with 1.85M lines of C# code, comprehensive test suite (Algorithms.Tests folder with 50+ test files), CI/CD via GitHub Actions (ci.yml, stale.yml), and Codacy/CodeCov integration. The project is stable for educational use but explicitly not for production—it prioritizes clarity over performance.

No external NuGet dependencies beyond xUnit/testing frameworks (low supply-chain risk). Test coverage is extensive but some newer algorithms lack documentation. Single-maintainer risk exists typical of educational open-source projects. No breaking changes expected since APIs remain stable for teaching purposes.

No specific recent changes visible in file list, but the active CI pipeline (workflows/ci.yml) and Codacy/CodeCov badges suggest ongoing quality checks. The stale.yml workflow indicates maintenance of open issues. Discord community link suggests active community engagement.

git clone https://github.com/TheAlgorithms/C-Sharp.git
cd C-Sharp
dotnet restore
dotnet test

Daily commands:

dotnet test Algorithms.Tests/Algorithms.Tests.csproj
dotnet test Algorithms.Tests/ --filter "NamespaceName"

No dev server—this is a testing-focused library run via test runner.

• Algorithms.Tests/Algorithms.Tests.csproj — Main test project configuration; defines build targets, dependencies, and test framework setup for all algorithm validations
• .github/workflows/ci.yml — CI/CD pipeline that runs all tests and quality checks on every commit; essential for understanding code validation flow
• .editorconfig — Enforces consistent code style and formatting rules across all C# implementations; critical for maintaining uniform codebase standards
• .github/CODEOWNERS — Defines ownership and review responsibilities for different algorithm categories; guides contribution routing
• Algorithms.Tests/GlobalUsings.cs — Global using statements for all tests; establishes shared namespaces and testing infrastructure across the entire test suite

• Graph Algorithms Layer (C# classes with adjacency list/matrix representations) — Implements BFS, DFS, Dijkstra, Floyd-Warshall, MST, topological sort, connectivity analysis
  • Failure mode: Incorrect shortest paths, cycle detection, or spanning tree selection; data structure corruption under large inputs
• Numeric Algorithms Layer (C# mathematical libraries, BigInteger support) — Implements GCD, primes, factorization, eigenvalue decomposition, polynomial operations, modular arithmetic
  • Failure mode: Arithmetic overflow, incorrect prime detection, convergence failures in iterative methods
• Cryptographic & Encoding Layer (Byte manipulation, bitwise operations, matrix math) — Implements classical ciphers (Caesar, Vigenere, Hill), Blowfish, and modern padding schemes
  • Failure mode: Incorrect cipher output, padding vulnerabilities, key expansion errors
• Compression Layer (Bit-level I/O, tree/trie data structures) — Implements Huffman, Burrows-Wheeler, Shannon-Fano compression algorithms
  • Failure mode: Data corruption, inefficient compression ratios, malformed output
• Machine Learning Layer (Numerical computation, distance metrics, linear algebra) — Implements K-Nearest Neighbors, Linear/Logistic Regression with gradient descent
  • Failure mode: Convergence failure, numerical instability, incorrect distance calculations
• Test Suite & Validation (xUnit/NUnit framework, assertion helpers, random test data generation) — Validates all algorithms with unit tests covering normal, edge, and adversarial cases
  • Failure mode: Insufficient coverage, flaky tests, missed edge cases allowing regressions

• Developer → GitHub Repository — Pushes C# algorithm implementations and corresponding unit tests
• GitHub Repository → GitHub Actions CI (ci.yml) — Triggers automated test execution on each commit
• GitHub Actions CI → Test Runner (dotnet test) — Executes all tests from Algorithms.Tests.csproj; tests load and execute algorithm implementations

Add a New Algorithm to a Category

1. Create a new C# file in the appropriate category folder (e.g., Algorithms/Graph/NewAlgorithm.cs) with a public class implementing the algorithm logic (Algorithms/Graph/NewAlgorithm.cs)
2. Add a corresponding test file in Algorithms.Tests following the same category structure (e.g., Algorithms.Tests/Graph/NewAlgorithmTests.cs) (Algorithms.Tests/Graph/NewAlgorithmTests.cs)
3. Implement test cases using xUnit/NUnit assertions, covering happy path, edge cases, and error conditions (Algorithms.Tests/Graph/NewAlgorithmTests.cs)
4. Ensure code follows .editorconfig formatting rules and passes CI pipeline (ci.yml will automatically run tests)

Add a New Algorithm Category

1. Create a new folder under Algorithms/ (e.g., Algorithms/DynamicProgramming/) with category-specific implementations (Algorithms/DynamicProgramming/)
2. Create a corresponding test folder under Algorithms.Tests (e.g., Algorithms.Tests/DynamicProgramming/) (Algorithms.Tests/DynamicProgramming/)
3. Update .github/CODEOWNERS to assign reviewers for the new category (optional but recommended)
4. Add implementations and tests; CI pipeline will automatically discover and run new tests

Update Test Coverage or Add Edge Cases

1. Open the relevant test file (e.g., Algorithms.Tests/Numeric/FactorialTests.cs) and add new [Fact] or [Theory] test methods (Algorithms.Tests/Numeric/FactorialTests.cs)
2. Use GlobalUsings.cs conventions and xUnit/NUnit assertions already established in the project (Algorithms.Tests/GlobalUsings.cs)
3. Run local tests via dotnet test and verify codecov integration on CI for coverage reports

• C# — Primary implementation language; enables cross-platform algorithm demonstrations and integrates with .NET ecosystem
• xUnit / NUnit — Industry-standard testing frameworks for C#; provides comprehensive assertion and test lifecycle capabilities
• GitHub Actions (ci.yml) — Automated CI/CD integration; runs tests on every commit and maintains code quality gates
• Codecov — Continuous coverage tracking; ensures algorithm implementations remain well-tested as repository evolves

• Single monolithic repository for all algorithm categories

  • Why: Simplifies navigation, contribution, and cross-category learning for students and educators
  • Consequence: Repository growth may become large; organizational discipline via folder structure is required to maintain clarity

• Educational-first implementation approach (clarity over performance optimization)

  • Why: Algorithms are meant to be learned and understood, not production-optimized
  • Consequence: Some implementations may not be suitable for high-performance production systems without refactoring

• Multiple implementations of same algorithm with different strategies

  • Why: Demonstrates algorithmic diversity (e.g., Euclidean vs. Binary GCD; Dynamic Programming vs. Naive Knapsack)
  • Consequence: Increases file count and potential for redundancy; requires good naming and documentation

• Production-grade performance optimization or benchmarking framework
• Real-time or distributed algorithm implementations
• Hardware acceleration or SIMD-specific optimizations
• Direct integration with external libraries for algorithm implementation (algorithms are implemented from first principles)

No hidden env vars or service dependencies—this is a pure C# library. Watch for: .editorconfig enforces strict style rules (run dotnet format before committing), xUnit requires [Fact] attributes on parameterless tests and [Theory] on parameterized ones (not [Test] like NUnit), test file naming must match *Tests.cs suffix for CI discovery, and mirror folder structure between Algorithms/ and Algorithms.Tests/ must stay in sync or tests won't be found.

• Cryptographic Padding Schemes (PKCS7, ISO 7816-4, X9.32) — Critical for securing block cipher implementations; this repo implements 5+ padding standards used in real-world encryption, teaching learners why padding length matters for AES/DES
• Huffman Coding & Burrows-Wheeler Transform — Foundation algorithms for lossless data compression; repo shows how to build practical compressors that reduce message size by exploiting character frequency and string structure
• Feistel Cipher Architecture — Underlying design pattern for DES and other symmetric ciphers; understanding Feistel teaches why historical encryption used reversible round functions without requiring an inverse operation
• Graph Shortest-Path Algorithms (Dijkstra, Bellman-Ford) — Essential for routing, GPS navigation, and network optimization; repo implements both greedy (Dijkstra) and dynamic-programming (Bellman-Ford) approaches for different graph properties
• Minimum Spanning Tree (Prim's, Kruskal's) — Algorithms for finding lowest-cost connected subgraphs; critical for network design and clustering; repo shows matrix (Prim) vs. greedy-union (Kruskal) trade-offs
• Polyalphabetic Ciphers (Vigenere, Autokey, Hill Cipher) — Historical encryption schemes showing evolution beyond simple substitution; teaches how matrix multiplication and periodic key scheduling improve security over Caesar cipher
• Phonetic Encoding (NYSIIS, Soundex) — Fuzzy string matching algorithms for handling misspellings in databases; repo implementations show practical NLP preprocessing for name matching and deduplication

• TheAlgorithms/Python — Parallel educational repo with same 100+ algorithms implemented in Python instead of C#; useful for cross-language algorithm comparison
• TheAlgorithms/Java — Companion repo with identical algorithm implementations in Java; C# learners often compare with Java implementations to understand language idioms
• dotnet/runtime — Official .NET runtime repo; reference for understanding C# language features and standard library algorithms used throughout TheAlgorithms/C-Sharp
• xunit/xunit — Test framework used by Algorithms.Tests.csproj; essential for understanding test attribute syntax and assertion APIs

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive test coverage for LinearAlgebra module

The file structure shows Algorithms.Tests/LinearAlgebra/Distances with only 3 distance metric tests (Chebyshev, Euclidean, Manhattan). The LinearAlgebra folder likely contains matrix operations, decompositions, and other linear algebra algorithms that lack corresponding test files. This is a high-value PR that ensures mathematical correctness of core algorithms.

• [ ] Examine Algorithms/LinearAlgebra/ directory to identify all implemented algorithms beyond the Distances subfolder
• [ ] Create corresponding test files in Algorithms.Tests/LinearAlgebra/ (e.g., MatrixOperationsTests.cs, EigenvalueTests.cs, etc.)
• [ ] Write unit tests covering edge cases (singular matrices, empty inputs, dimension mismatches)
• [ ] Ensure test coverage aligns with existing test patterns in the codebase (using xUnit based on GlobalUsings.cs)

Expand Financial algorithms test suite and add missing implementations

Currently only PresentValueTests.cs exists in Algorithms.Tests/Financial. Financial algorithms are commonly needed but appear severely under-tested. This PR would add tests for missing financial calculations (NPV, IRR, compound interest, amortization) and their corresponding test files.

• [ ] Review Algorithms/Financial/ to identify implemented algorithms beyond PresentValue
• [ ] Create test files for each financial algorithm (e.g., NetPresentValueTests.cs, InternalRateOfReturnTests.cs, CompoundInterestTests.cs)
• [ ] Add tests with realistic financial scenarios (loan calculations, investment returns)
• [ ] Verify test cases match standard financial formulas and industry examples

Add test coverage for Encoders and Crypto modules with edge case validation

While Algorithms.Tests/Encoders and Algorithms.Tests/Crypto have test files, the crypto padding and cipher implementations are security-sensitive and need rigorous edge case testing. This PR would enhance existing tests and add missing coverage for null inputs, boundary conditions, and encoding errors.

• [ ] Review existing test files in Algorithms.Tests/Crypto/Paddings/ (currently 5 padding tests) for coverage gaps
• [ ] Add tests for edge cases: empty byte arrays, maximum buffer sizes, invalid padding scenarios
• [ ] Review Algorithms.Tests/Encoders/ (currently 7 encoder tests) and add missing tests for malformed input handling
• [ ] Add tests validating encode/decode round-trip consistency for all encoder implementations

• Add xUnit tests for Algorithms/Crypto/Paddings/Iso10126D2Padding.cs and Iso7816D4Padding.cs (test files exist but may lack edge case coverage for block padding boundary conditions)
• Implement missing Algorithms/Graph/Dijkstra/DijkstraHeap.cs variant using PriorityQueue<T> (.NET 6+) alongside existing PrimMatrix.cs, then add Algorithms.Tests/Graph/Dijkstra/DijkstraHeapTests.cs
• Add README.md documentation section explaining the cryptographic padding schemes in Algorithms/Crypto/Paddings/ with examples (PKCS7, ISO 7816-4 are cryptographically critical and deserve learner-friendly docs)

The repository demonstrates reasonable security practices as an educational algorithms collection with no obvious critical vulnerabilities detected from visible file structure. However, the analysis is limited by missing dependency manifests and configuration file contents. The primary concerns are: (1) inability to verify NuGet dependency vulnerabilities, (2) custom cryptographic implementations requiring careful handling, and (3) need for formal security policy documentation. The low-risk nature is expected for an educational repository, but production use of contained algorithms (especially crypto) would require additional security review. Recommend implementing automated dependency scanning and documenting security usage constraints.

• Medium · Missing Dependency Manifest Analysis — Root level - Missing Algorithms.csproj or Algorithms.Tests.csproj content. No package dependency file (packages.config, .csproj, or paket.lock) content was provided for analysis. This prevents verification of known vulnerabilities in NuGet dependencies, which is critical for C# projects. Fix: Provide complete .csproj files and run 'dotnet list package --vulnerable' to identify vulnerable NuGet packages. Implement automated dependency scanning in CI/CD pipeline using tools like Dependabot or WhiteSource.
• Low · Missing Security Policy Documentation — Root directory. No SECURITY.md file is visible in the repository structure. This makes it unclear how security vulnerabilities should be reported. Fix: Create a SECURITY.md file with clear instructions for responsible disclosure of security vulnerabilities. Reference: https://docs.github.com/en/code-security/getting-started/adding-a-security-policy-to-your-repository
• Low · DevContainer Configuration Requires Review — .devcontainer/devcontainer.json. A .devcontainer/devcontainer.json file exists but its contents were not provided. DevContainer configurations can introduce security issues if they expose ports, mount sensitive volumes, or use untrusted base images. Fix: Review devcontainer.json to ensure: (1) No unnecessary ports are exposed, (2) No sensitive environment variables are hardcoded, (3) Base Docker image is from trusted source and regularly updated, (4) Volume mounts are restricted to necessary directories only.
• Low · Cryptographic Implementations Require Audit — Algorithms/Crypto directory (based on test files). The repository contains multiple cryptographic algorithm implementations (Ascon Digest, MD2, Blowfish, etc.) in the Crypto folder. Custom crypto implementations are high-risk for security flaws. Fix: Ensure cryptographic implementations are: (1) Based on published standards, (2) Reviewed by security experts, (3) Not used for production security purposes without formal audit, (4) Include clear warnings in documentation about educational vs. production use.
• Low · Test Data Exposure Risk — Algorithms.Tests directory (multiple test files). Multiple test files exist with potential test vectors and cryptographic test cases. If actual sensitive data is used in tests, it could be committed to version control. Fix: Review all test files to ensure: (1) Only synthetic/example data is used, (2) No real API keys, passwords, or sensitive information is in test data, (3) Use test fixtures from public standards (NIST, RFC) where applicable.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.