Coding & Software

Translate Code to Another Language

Ports code to another language idiomatically, lists behavior that differs between the two and gives checks that prove the port matches.

Designed for general-purpose AI assistantsPublished November 2026

Customize

Fill in the fields and the prompt updates. What you type stays in this page and is never saved or sent.

Preview

Port the code below from {{source language}} to {{target language}}. It must behave the same way, and it should read like a native {{target language}} developer wrote it.

Target version, framework and libraries I am allowed to use: {{target environment}}
Why I am porting it (performance, platform, team skills, other): team skills
Style conventions to follow: the language's standard style

Source code:
{{source code}}

Before writing the port, list the behaviors in the source that are language-specific and could change silently in the target, such as integer overflow, division and rounding, string encoding, mutability and copying, null handling, sort stability, floating-point formatting, time zones, error handling, and concurrency. For each that appears in this code, say what the source does and what the target would do by default.

Then provide:
1. The ported code, using idiomatic constructs for the target. Do not translate line by line if the target has a clearer way, but keep the function names and the structure recognizable so I can compare them.
2. A mapping table: source construct or library call, the target equivalent, and a note where behavior differs.
3. Anything you could not port faithfully, with the reason and the closest alternative. Do not hide a difference in a comment buried in the code.
4. A set of test inputs, including edge cases, with the expected output from the source code, so I can run both versions and compare. Work out the expected output only by tracing the source code, and mark any you are not certain of.
5. Dependencies the port adds, and any I should avoid.

Rules: do not add features, remove validation or change public behavior. If a library call has no equivalent in the allowed libraries, say so instead of inventing a function. If the source behavior looks like a bug, port it faithfully and flag it so I can decide.

4 required fields are empty and will stay as a {{placeholder}} in the copied text.

How to use it

  1. Name the target version and the libraries you allow. A port that depends on a package you cannot add is not useful.
  2. Read the list of language-specific behaviors first. It is where silent bugs in ports hide, such as rounding, integer size and sorting.
  3. Run both implementations on the same test inputs and compare the outputs directly. Do not rely on reading the code.
  4. Port one module at a time and keep the original running until the comparison passes.

Example output

Illustrative only. Real answers depend on your input and the assistant you use.

Behaviors that differ (Python to Go):
- Integer size: Python integers have no fixed size; Go int may overflow. This code multiplies two prices, so use int64 or a decimal type.
- Division: Python // floors toward negative infinity; Go / truncates toward zero. This matters for negative inputs.
- Missing keys: Python dict returns KeyError; Go map returns the zero value silently.

Mapping:
| Python | Go | Note |
|---|---|---|
| round(x, 2) | math.Round(x*100) / 100 | banker's rounding in Python, half away from zero in Go |
| sorted(items, key=...) | sort.SliceStable | Python sort is stable; use the stable version |

Could not port faithfully: Python's round() uses banker's rounding; the closest option in Go needs a small helper, included below.

Test inputs: apply_discount(100, 15) expects 85.00; apply_discount(-5, 10) expects -4.50 (source traced by hand, certain); apply_discount(0.005, 0) expects 0.0 (uncertain: rounding).

Tips

Most bugs in a port come from differences nobody wrote down: rounding, integer limits, ordering, encoding. The first section is designed to write them down.

For a large codebase, port the pure functions first, compare them with a shared test suite, and only then move the code that does input and output.

Keep the assistant's mapping table. It becomes a mini style guide for the rest of the migration.

For a large file, check first that it fits the assistant you use with the AI Token Counter. A file that is silently cut off is ported only partly, and the result can look complete.

  • Coding & Software

    Refactor Code Without Changing Behavior

    Plans a refactor as small reversible steps, states the behavior to preserve and says what to test before each step.

    Customizable fields
    7 fields
  • Coding & Software

    Write Unit Tests for a Function

    Generates focused unit tests for one function, covering normal cases, boundaries and invalid input without mocking more than needed.

    Customizable fields
    3 fields
  • Coding & Software

    Debug a Flaky Test

    Finds why a test passes sometimes and fails other times, ranks the likely causes and gives an experiment to prove each one.

    Customizable fields
    8 fields