DEV Community: JW SOLUTIONS

Modern C# 12: Refactoring with Primary Constructors and XML Docs

JW SOLUTIONS — Sun, 15 Nov 2026 04:57:06 +0000

Simplifying Dependency Injection with C# 12 Primary Constructors

C# development has evolved significantly with .NET 8 and C# 12. Historically, dependency injection required declaring private read-only fields (private readonly), defining an explicit constructor, and manually assigning each parameter to those fields. This pattern produced considerable boilerplate code, making domain and service classes harder to read and maintain.

With the introduction of Primary Constructors in C# 12, parameters can be declared directly on the class definition, substantially reducing lines of code while retaining clarity and type safety.

Legacy Code: The Traditional Approach (Before)

In versions prior to C# 12, a standard service class with multiple dependencies was written as follows:

namespace JWDocs.Services;

/// <summary>
/// Service responsible for processing payments and customer receipts.
/// </summary>
public class PaymentProcessor
{
    private readonly IPaymentGateway _gateway;
    private readonly ILogger _logger;

    /// <summary>
    /// Initializes a new instance of <see cref="PaymentProcessor"/>.
    /// </summary>
    /// <param name="gateway">The primary payment provider.</param>
    /// <param name="logger">The audit logging service.</param>
    public PaymentProcessor(IPaymentGateway gateway, ILogger logger)
    {
        _gateway = gateway ?? throw new ArgumentNullException(nameof(gateway));
        _logger = logger ?? throw new ArgumentNullException(nameof(logger));
    }

    public async Task ProcessAsync(decimal amount)
    {
        _logger.LogInfo("Starting payment...");
        await _gateway.ChargeAsync(amount);
    }
}

Modern Refactoring in C# 12 (After)

By leveraging primary constructors and adapted XML documentation in C# 12, the class becomes significantly cleaner:

namespace JWDocs.Services;

/// <summary>
/// Service responsible for processing payments and customer receipts.
/// </summary>
/// <param name="gateway">The primary payment provider.</param>
/// <param name="logger">The audit logging service.</param>
public class PaymentProcessor(IPaymentGateway gateway, ILogger logger)
{
    public async Task ProcessAsync(decimal amount)
    {
        ArgumentNullException.ThrowIfNull(gateway);
        ArgumentNullException.ThrowIfNull(logger);

        logger.LogInfo("Starting payment...");
        await gateway.ChargeAsync(amount);
    }
}

Integration with .NET Analyzers and EditorConfig

To ensure consistency across enterprise teams, configure static analysis rules in your .editorconfig file. This forces the compiler and IDE to suggest refactoring toward primary constructors:

[*.cs]
dotnet_style_prefer_primary_constructors = true:suggestion

Automatic Documentation with Auto-Doc AI

When using primary constructors, the placement of XML documentation shifts: <param> tags are now attached directly to the class summary block instead of a separate constructor. Our Code Formatter & Auto-Doc AI tool automatically parses primary constructor parameters and builds missing <param> documentation, ensuring compliance with StyleCop rules (SA1600) and official Microsoft standards without manual overhead.

Conclusion and Best Practices

Adopting primary constructors in C# 12 reduces boilerplate and drastically improves code readability. Combining this modern language feature with EditorConfig settings and Auto-Doc AI automation yields a clean, maintainable, and thoroughly documented codebase.

Try it interactively: Format, validate, and auto-document your csharp directly in JW Solutions Code Formatter & Auto-Doc AI.
Originally published at jw-solutions.com.

Refactoring in Java 21+: Records and Pattern Matching for Readable Code

JW SOLUTIONS — Sun, 15 Nov 2026 04:57:02 +0000

Introduction to Legacy Code in Java

For years, Java developers have relied on extensive class hierarchies, multiple type checks using the instanceof operator, and explicit type casting to model data and handle complex conditional structures. This traditional approach not only increases the volume of source code but also introduces latent runtime risks, such as ClassCastException, while severely hindering long-term software maintainability.

With the release of Java 21, the language has matured significantly thanks to stable, high-impact features such as Records and Pattern Matching for switch. These modern tools allow architects and developers to write highly expressive, safe code aligned with Google Java Style standards. Below, we will analyze a real refactoring case from a legacy design to a modern, self-documenting design.

The Problem: Legacy Code with Verbose Checks

Let's consider a typical enterprise application processing network or database operation responses using abstract classes and multiple subclasses along with chained if-else blocks to determine the received response type:

// BEFORE: Verbose and error-prone legacy code
public abstract class Response {
}

public class SuccessResponse extends Response {
    private final String data;
    public SuccessResponse(String data) { this.data = data; }
    public String getData() { return data; }
}

public class ErrorResponse extends Response {
    private final String errorCode;
    public ErrorResponse(String errorCode) { this.errorCode = errorCode; }
    public String getErrorCode() { return errorCode; }
}

public class ResponseProcessor {
    public static String process(Response response) {
        if (response instanceof SuccessResponse) {
            SuccessResponse success = (SuccessResponse) response;
            return "OK: " + success.getData();
        } else if (response instanceof ErrorResponse) {
            ErrorResponse error = (ErrorResponse) response;
            return "FAIL: " + error.getErrorCode();
        } else {
            throw new IllegalArgumentException("Unknown response type");
        }
    }
}

This traditional pattern presents several drawbacks: it requires writing manual constructors, getters, equals, hashCode, and toString methods, while duplicating unnecessary casting logic inside conditional structures.

The Solution: Records and Pattern Matching in Java 21

We can radically refactor this design using sealed interfaces, Records to model immutable data concisely, and Pattern Matching applied to the switch statement. This combination completely eliminates explicit casting and ensures exhaustiveness of analyzed cases.

// AFTER: Clean, modern, and safe code in Java 21
public sealed interface Response permits Response.Success, Response.Error {
    record Success(String data) implements Response {}
    record Error(String errorCode) implements Response {}

    /**
     * Processes the response safely using pattern matching.
     *
     * @param response the response received from the server
     * @return a formatted string with the processing result
     */
    static String process(Response response) {
        return switch (response) {
            case Success(var data) -> "OK: " + data;
            case Error(var code) -> "FAIL: " + code;
        };
    }
}

Architectural Advantages and Maintainability

Boilerplate Reduction: Records automatically generate the canonical constructor, accessors, string representations, and equality contracts.
Type Safety (Exhaustiveness): The Java compiler validates that all subtypes of a sealed interface are covered in the switch, preventing runtime errors from forgotten branches.
Extreme Readability: Deconstruction patterns allow direct access to internal record components inside the pattern itself.

Auto-Documentation with Artificial Intelligence (Auto-Doc AI)

Using modern standards like Java 21 drastically facilitates the task of Auto-Doc AI tools. Thanks to the clear semantics of sealed interfaces and records, automated documentation generators can infer precise contracts without requiring redundant annotations. By integrating automatic formatters under the Google Java Style standard, we guarantee that code structure remains uniform across the entire development team, reducing friction in code reviews and elevating the overall quality of the corporate repository.

Try it interactively: Format, validate, and auto-document your java directly in JW Solutions Code Formatter & Auto-Doc AI.
Originally published at jw-solutions.com.

Refactoring Legacy any Types in TypeScript with Type Guards and TSDoc

JW SOLUTIONS — Sun, 15 Nov 2026 04:51:09 +0000

The Problem with `any` in Legacy Codebases

During rapid migrations from JavaScript to TypeScript, developers frequently annotate complex data structures with any. While this allows the project to compile immediately, it completely disables TypeScript's static type checker, hiding potential runtime exceptions and breaking downstream automation tools like Auto-Doc AI.

Overusing any introduces technical debt that trickles down to modern pipelines. It destroys IDE IntelliSense support and prevents documentation engines from inferring true domain models.

Untyped Legacy Code (Before)

In the following snippet, an API payload is handled using an implicit or explicit any type. There is no runtime checking, type safety, or structured TSDoc metadata.

// ❌ Legacy untyped code susceptible to runtime errors
function processUserData(data: any) {
  console.log("User ID:", data.id);
  if (data.role === "admin") {
    return data.permissions.includes("write");
  }
  return false;
}

Strict Refactoring with Type Guards and TSDoc (After)

To align with TypeScript's strict mode requirements and enable Auto-Doc AI to generate automated API specifications, we replace any with unknown and implement a custom Type Guard alongside formatted TSDoc comments.

/**
 * Validated user permissions structure.
 */
export interface UserPayload {
  id: string;
  role: 'admin' | 'user';
  permissions: string[];
}

/**
 * Custom type guard predicate verifying object structure.
 *
 * @param data - Unstructured payload from remote API.
 * @returns `true` if payload conforms to {@link UserPayload}.
 */
export function isUserPayload(data: unknown): data is UserPayload {
  return (
    typeof data === 'object' &&
    data !== null &&
    'id' in data &&
    typeof (data as Record<string, unknown>).id === 'string' &&
    'role' in data &&
    ['admin', 'user'].includes((data as Record<string, unknown>).role as string) &&
    'permissions' in data &&
    Array.isArray((data as Record<string, unknown>).permissions)
  );
}

/**
 * Evaluates user write privileges with strict runtime validation.
 *
 * @param data - Raw unvalidated input object.
 * @returns True if user has active write permission.
 * @throws {TypeError} If payload structure validation fails.
 */
export function processUserDataStrict(data: unknown): boolean {
  if (!isUserPayload(data)) {
    throw new TypeError('Invalid payload structure: does not satisfy UserPayload');
  }
  if (data.role === 'admin') {
    return data.permissions.includes('write');
  }
  return false;
}

Prettier Integration and Auto-Doc AI Standards

Ensure code consistency across large scale enterprise applications by adding JSDoc/TSDoc formatting plugins to your .prettierrc configuration:

{
  "singleQuote": true,
  "trailingComma": "all",
  "printWidth": 100,
  "tsdoc": true
}

Key Refactoring Best Practices:

Replace any with unknown: Forces developers to narrow types safely prior to accessing properties.
Leverage Type Predicates (data is Type): Enables the TypeScript compiler to infer types inside validated conditional blocks.
Standardize with TSDoc: Explicit @param, @returns, and @throws tags empower Auto-Doc AI to generate complete API documentation automatically.
Enforce Rules via CI/CD: Run Prettier and strict TypeScript compilation checks on every pull request.

Try it interactively: Format, validate, and auto-document your typescript directly in JW Solutions Code Formatter & Auto-Doc AI.
Originally published at jw-solutions.com.

SQL and DAX: three habits for fast, readable queries

JW SOLUTIONS — Sun, 15 Nov 2026 04:51:05 +0000

Tip of the week

In SQL, select only the columns you need and filter early. In DAX, store intermediate results in variables (VAR) so they are evaluated once.

SELECT o.id, o.total, c.name
FROM orders AS o
JOIN customers AS c ON c.id = o.customer_id
WHERE o.created_at >= DATE '2026-01-01'
ORDER BY o.total DESC;

Ventas YTD Margen =
VAR Ventas = [Ventas Totales]
VAR Costo = [Costo Total]
RETURN DIVIDE(Ventas - Costo, Ventas)

Quick rules

Avoid SELECT * in production.
Use DIVIDE in DAX to avoid division-by-zero errors.
One measure, one responsibility: compose measures instead of duplicating logic.

Try it interactively: Format, validate, and auto-document your sql directly in JW Solutions Code Formatter & Auto-Doc AI.
Originally published at jw-solutions.com.

Modern TypeScript: ?., ?? and satisfies without formatting errors

JW SOLUTIONS — Sun, 15 Nov 2026 04:41:58 +0000

Tip of the week

Three operators cut defensive code: optional chaining ?., nullish coalescing ?? and TypeScript 4.9+'s satisfies operator, which checks the type without widening the value.

const config = {
  retries: 3,
  endpoint: "https://api.example.com",
} satisfies Record<string, string | number>;

const timeout = options?.timeout ?? 5000;
const city = user?.address?.city ?? "Sin ciudad";

Quick rules

Use ?? (not ||) when 0 or "" are valid values.
Avoid ?. chains longer than three levels: a sign of a poorly designed model.
Prefer satisfies over as so type errors are not silenced.

Try it interactively: Format, validate, and auto-document your javascript directly in JW Solutions Code Formatter & Auto-Doc AI.
Originally published at jw-solutions.com.

PEP 8 in Python 3.12: writing readable match/case blocks

JW SOLUTIONS — Sun, 15 Nov 2026 04:41:54 +0000

Tip of the week

Python's match/case (3.10+) is powerful, but poorly indented it becomes hard to read. PEP 8 recommends indenting each case one level inside match, keeping lines within 79 characters and using short if guards.

match command.split():
    case ["go", direction] if direction in {"north", "south"}:
        move(direction)
    case ["quit" | "exit"]:
        shutdown()
    case _:
        print("Comando desconocido")

Quick rules

One case per pattern; avoid guards with more than one condition.
Use | to group alternatives instead of repeating branches.
Always end with case _: so unexpected input is not silently ignored.

Paste this snippet into the formatter with the button above and check the indentation instantly.

Try it interactively: Format, validate, and auto-document your python directly in JW Solutions Code Formatter & Auto-Doc AI.
Originally published at jw-solutions.com.

DEV Community: JW SOLUTIONS

Modern C# 12: Refactoring with Primary Constructors and XML Docs

Simplifying Dependency Injection with C# 12 Primary Constructors

Legacy Code: The Traditional Approach (Before)

Modern Refactoring in C# 12 (After)

Integration with .NET Analyzers and EditorConfig

Automatic Documentation with Auto-Doc AI

Conclusion and Best Practices

Refactoring in Java 21+: Records and Pattern Matching for Readable Code

Introduction to Legacy Code in Java

The Problem: Legacy Code with Verbose Checks

The Solution: Records and Pattern Matching in Java 21

Architectural Advantages and Maintainability

Auto-Documentation with Artificial Intelligence (Auto-Doc AI)

Refactoring Legacy any Types in TypeScript with Type Guards and TSDoc

The Problem with any in Legacy Codebases

Untyped Legacy Code (Before)

Strict Refactoring with Type Guards and TSDoc (After)

Prettier Integration and Auto-Doc AI Standards

Key Refactoring Best Practices:

SQL and DAX: three habits for fast, readable queries

Tip of the week

Quick rules

Modern TypeScript: ?., ?? and satisfies without formatting errors

Tip of the week

Quick rules

PEP 8 in Python 3.12: writing readable match/case blocks

Tip of the week

Quick rules

The Problem with `any` in Legacy Codebases