# Extract a Shared Helper from Duplicated F# Code with Atlas in 2026 > Atlas helps F# developers in 2026 find and refactor duplicated logic into shared helpers, respecting F# idioms and integrating with `dotnet test (Expecto)`. In 2026, F# developers can efficiently extract shared helper functions from duplicated code using Atlas, which integrates directly with the F# toolchain, including `dotnet test (Expecto)` for verification, `NuGet (dotnet add package)` for dependencies, and `fantomas` for formatting. This process ensures that common logic, even with varying variable names, is consolidated into a single, tested module, improving maintainability and reducing errors. ## Key takeaways - Atlas uses semantic search to find F# code duplication, even with differing variable names. - New F# helper modules are created with `write`, respecting `.fsproj` file order. - Refactoring F# code is done with `apply_patch`, generating one reviewable patch per file. - F# test suites (`dotnet test (Expecto)`) are run via `bash` to verify changes. - F# code formatting is maintained with `fantomas` after modifications. - Atlas ensures F# code quality by integrating with the F# toolchain and providing granular control. ## How Atlas Finds Duplicated F# Logic Semantically Atlas in 2026 employs advanced semantic search capabilities to identify duplicated F# logic across your codebase, a task where traditional `grep` falls short. This is crucial because copy-pasted F# code often differs only in variable names, making exact text matching ineffective for refactoring efforts. When refactoring F# code, the challenge isn't just finding identical text, but identifying functionally equivalent blocks of code that have been duplicated. Atlas addresses this by indexing your F# codebase using AST declarations via tree-sitter, allowing it to understand the structure and meaning of your F# modules, discriminated unions, and computation expressions. The `codebase_search` tool leverages hybrid semantic and keyword retrieval, fused by reciprocal rank fusion, to surface near-duplicate implementations. For instance, if you have two functions, `calculateDiscount` and `computeRebate`, that perform the same mathematical operation but use different parameter names, Atlas can semantically link them, presenting them as candidates for consolidation into a single, shared F# helper function. This capability is vital for maintaining a clean F# codebase where logic is centralized and easily updated. ## Creating a New F# Shared Module with Atlas After identifying duplicated F# logic, creating a new shared module is the next logical step in 2026. Atlas's `write` tool facilitates this by generating a new `.fs` file, such as `SharedLogic.fs`, and populating it with the extracted helper function, ensuring proper F# module structure. Once you've confirmed that several F# code blocks are genuinely equivalent and suitable for extraction, Atlas assists in creating the new shared helper. Using the `write` tool, you can instruct Atlas to generate a new F# source file, for example, `MyProject/Shared/SharedHelpers.fs`. Atlas understands F# project structure, including the `.fsproj` file, which dictates file order for compilation. The `write` tool will draft the new module, complete with the extracted function, and present a unified diff for your approval before any changes are written to disk. This allows you to review the exact F# code Atlas proposes, ensuring it aligns with your project's conventions, such as module naming and function signatures. For instance, if the duplicated logic involved an `Option` pipeline, Atlas would draft the helper using F# `Option` types, respecting idiomatic F# practices. ## Replacing Duplicates with F# Helper Calls and Reviewing Changes Replacing each instance of duplicated F# code with a call to the new shared helper is a critical step in 2026, managed by Atlas's `apply_patch` tool. This tool generates one reviewable patch per file, ensuring granular control over every F# code modification. With the shared F# helper function now defined in its own module, the next task is to replace all original duplicated instances with calls to this new helper. Atlas's `apply_patch` tool is designed for this precise workflow. For each file containing a duplicate, Atlas computes a unified diff that shows the removal of the old, duplicated F# code and the insertion of the new call to your `SharedHelpers.myFunction`. This approach is highly beneficial for F# development because it creates one independent, reviewable patch per file. This means you can approve or reject each F# file's modification individually, making code reviews straightforward and minimizing the risk of introducing regressions. For example, if a duplicate was found in `Domain.fs` and another in `Service.fs`, Atlas would generate two distinct patches, allowing you to review `Domain.fs`'s change and then `Service.fs`'s change separately, ensuring each F# file's context is properly handled. ## Verifying F# Refactoring with `dotnet test (Expecto)` and `fantomas` After each F# code modification, verifying the changes is paramount in 2026. Atlas integrates directly with the F# toolchain, allowing it to run `dotnet test (Expecto)` to confirm functionality and `fantomas` to ensure consistent F# code formatting. A robust refactoring workflow for F# demands immediate verification after every change. Atlas facilitates this by allowing you to execute `bash` commands directly within its environment. After Atlas replaces a duplicated F# block with a helper call using `apply_patch`, you can instruct it to run `dotnet test` to execute your `Expecto` test suite. This ensures that the refactoring has not introduced any regressions and that the new helper function behaves as expected. Atlas will present the output of `dotnet test (Expecto)` for your review. Furthermore, to maintain F# code quality and consistency, Atlas can automatically run `fantomas` over any changed `.fs` files. This ensures that all new or modified F# code adheres to your project's formatting standards, preventing style drift and making the codebase easier to read and maintain for all F# developers. Atlas's permission-gated tool calls mean you always approve these actions before they run. ## Final Verification: Grepping for Remaining F# Duplicates The final step in 2026's F# refactoring workflow is a comprehensive check for any surviving duplicates. Atlas's `grep` tool provides a quick and reliable way to confirm that all instances of the original F# logic have been successfully replaced. Even after systematically replacing duplicated F# code with calls to a shared helper, a final verification step is crucial to ensure no instances were missed. Atlas's `grep` tool can be used to perform a final sweep of your F# codebase. By searching for a unique string or pattern from the original duplicated logic (or even the original function body if it's distinct enough), you can quickly confirm that all instances have been successfully refactored. This `grep` command acts as a safety net, providing confidence that the refactoring is complete and that your F# project is now free of the targeted duplication. This step is particularly useful for catching edge cases or instances that might have been overlooked during the initial semantic search, ensuring a thoroughly clean F# codebase. ## Steps 1. Ask Atlas's `codebase_search` tool to find semantically similar F# logic across your `.fs` files, focusing on behavior rather than exact text to catch variations in variable names. 2. Review each F# code hit surfaced by `codebase_search` to confirm that the duplicated logic is genuinely equivalent and suitable for extraction into a shared helper. 3. Use Atlas's `write` tool to create a new F# module file (e.g., `SharedHelpers.fs`) containing the extracted helper function, reviewing the full diff before creation. 4. For each duplicated F# code block, use Atlas's `apply_patch` tool to replace it with a call to the new shared helper, approving each file's patch individually for granular control. 5. After each `apply_patch` operation, run `bash` with `dotnet test` to execute your `Expecto` test suite and verify that the F# refactoring has not introduced regressions. 6. Once all duplicates are replaced, use `bash` to run `fantomas` over the modified `.fs` files to ensure consistent F# code formatting. 7. Perform a final check using Atlas's `grep` tool to search for any remaining instances of the original duplicated F# logic, confirming a complete refactoring. ## FAQ ### How does Atlas find F# code duplication that `grep` misses? Atlas indexes your F# codebase using AST declarations via tree-sitter, understanding the structural and semantic meaning of your F# code. Its `codebase_search` tool employs hybrid semantic and keyword retrieval, allowing it to identify functionally equivalent F# logic even when variable names or minor syntactic details differ, which `grep` cannot do effectively. ### Can Atlas handle F# specific constructs like discriminated unions or Option types during refactoring? Yes, Atlas is designed to pair with F# and respects its specific constructs. When building its code index, Atlas maps your discriminated unions, modules, and computation expressions. When drafting new F# code or refactoring existing logic, Atlas will propose idiomatic F# solutions, such as using `Option` pipelines instead of null checks, ensuring the generated code is high quality and F#-native. ### How does Atlas ensure my F# project's compilation order is respected? Atlas builds its code index by reading your `.fsproj` file, which explicitly defines the compilation order for F# source files. When Atlas creates new `.fs` files or modifies existing ones, it is aware of this order and can suggest appropriate placements or modifications to ensure your F# project continues to compile correctly without manual intervention regarding file order. ### What F# testing framework does Atlas support for verification? Atlas integrates direct with the standard F# testing workflow. It can run `dotnet test` to execute your test suite, specifically supporting `Expecto` as a common F# testing framework. After any code modification, Atlas can prompt to run these tests via a `bash` command, displaying the results for your review to confirm the refactoring's correctness. ### How does Atlas help maintain F# code style during refactoring? Atlas helps maintain consistent F# code style by integrating with `fantomas`, the F# code formatter. After Atlas makes changes to `.fs` files, it can be instructed to run `fantomas` over those modified files. This ensures that all refactored or newly generated F# code adheres to your project's predefined formatting rules, keeping the codebase clean and readable. ### Is it safe to let Atlas modify my F# codebase automatically? Atlas prioritizes safety and developer control. Every Atlas tool call is permission-gated, requiring your explicit 'allow', 'ask', or 'deny' approval before execution. For file edits, Atlas computes a unified diff and surfaces it for your approval before writing. This granular control, combined with the ability to run `dotnet test (Expecto)` after each change and review individual patches, ensures you maintain full oversight over all F# codebase modifications. --- Canonical HTML: https://runatlas.sh/resources/stacks/extract-a-shared-helper-from-duplicated-code-in-fsharp Source of truth: aeo_pages row `/resources/stacks/extract-a-shared-helper-from-duplicated-code-in-fsharp` (segment: Stacks) (this file is generated from it, never hand-edited). Licence: Atlas is proprietary with a free core. It is not open source and there is no public source repository.