Multi-Language Support

Relevant source files

This page documents the multi-language implementation strategy used throughout the doocs/leetcode repository, covering the architecture, file organization, and integration of 12+ programming language solutions. For language-specific idioms and data structure conventions, see Language Coverage and Conventions. For automated code formatting configuration, see Code Formatting System.

Overview

The repository provides functionally equivalent solutions for each problem in multiple programming languages, enabling developers to study algorithm implementations in their preferred language. Each solution follows a three-layer architecture:

Problem Specification Layer: Bilingual (Chinese/English) problem descriptions with metadata
Algorithm Layer: Language-agnostic solution approaches with complexity analysis
Implementation Layer: Language-specific code implementations

This architecture allows the repository to serve both as an algorithm learning resource (focusing on approaches) and as a practical code reference (providing multi-language implementations).

Sources: High-level diagrams (Diagram 5)

Supported Languages

The repository currently supports 12+ programming languages, organized into three categories:

Category	Languages
Compiled Languages	Java, C++, Go, Rust, C#, Swift, C
Interpreted Languages	Python, JavaScript, TypeScript, PHP, Ruby
Special Purpose	SQL (for database problems), Nim

Sources: High-level diagrams (Diagram 5), solution/0000-0099/0001.Two Sum/README.md78-337

File Organization Structure

Solution File Naming Convention

Each problem directory contains solution files named according to the pattern Solution.<ext>, where <ext> is the language-specific file extension:

Problem Directory Structure Example

For problem 0001 (Two Sum), the directory structure is:

solution/0000-0099/0001.Two Sum/
├── README.md              # Chinese problem description and solutions
├── README_EN.md           # English problem description and solutions
├── Solution.py            # Python implementation
├── Solution.java          # Java implementation
├── Solution.cpp           # C++ implementation
├── Solution.go            # Go implementation
├── Solution.ts            # TypeScript implementation
├── Solution.rs            # Rust implementation
├── Solution.js            # JavaScript implementation
├── Solution.cs            # C# implementation
├── Solution.php           # PHP implementation
├── Solution.rb            # Ruby implementation
├── Solution.swift         # Swift implementation
├── Solution.nim           # Nim implementation
└── Solution.c             # C implementation (when applicable)

This pattern repeats for all ~4000+ problems across the solution/, lcof/, lcci/, lcp/, and lcs/ directories.

Sources: solution/0000-0099/0001.Two Sum/README.md1-410 High-level diagrams (Diagram 3)

Language Implementation Architecture

Code Entity Mapping

The following diagram maps the natural language concepts to actual code entities in the repository:

Sources: solution/0000-0099/0001.Two Sum/README.md71-77 solution/0000-0099/0001.Two Sum/Solution.py1-7 solution/0000-0099/0001.Two Sum/Solution.java1-12 solution/0000-0099/0001.Two Sum/Solution.cpp1-14 solution/0000-0099/0001.Two Sum/Solution.go1-11

Language-Specific Data Structure Equivalence

Each language uses idiomatic data structures to implement the same algorithm. The following table shows equivalent constructs across languages for the Two Sum hash table solution:

Concept	Python	Java	C++	Go	Rust	TypeScript
Hash Map Declaration	`d = {}`	`Map<Integer, Integer> d = new HashMap<>()`	`unordered_map<int, int> d`	`d := map[int]int{}`	`let mut d = HashMap::new()`	`const d = new Map<number, number>()`
Check Key Exists	`y in d`	`d.containsKey(y)`	`d.contains(y)`	`j, ok := d[y]`	`d.get(&y)`	`d.has(y)`
Insert Key-Value	`d[x] = i`	`d.put(x, i)`	`d[x] = i`	`d[x] = i`	`d.insert(x, i)`	`d.set(x, i)`
Get Value	`d[y]`	`d.get(y)`	`d[y]`	`d[y]`	`d[&y]`	`d.get(y)!`
Return Type	`List[int]`	`int[]`	`vector<int>`	`[]int`	`Vec<i32>`	`number[]`

Sources: solution/0000-0099/0001.Two Sum/Solution.py3-7 solution/0000-0099/0001.Two Sum/Solution.java3-11 solution/0000-0099/0001.Two Sum/Solution.cpp4-13 solution/0000-0099/0001.Two Sum/Solution.go2-10 solution/0000-0099/0001.Two Sum/Solution.rs4-14 solution/0000-0099/0001.Two Sum/Solution.ts2-10

Bilingual Documentation System

README File Structure

Each problem contains two parallel README files that provide identical technical content in different languages:

Sources: solution/0000-0099/0001.Two Sum/README.md1-17 solution/0000-0099/0001.Two Sum/README_EN.md1-17

Markdown Tab Syntax for Language Solutions

Both README files use a special markdown syntax ( and ) to embed multi-language code snippets. The syntax structure is:

Java


This syntax is processed by the MkDocs build system (see [Documentation Site Generation](#2.3)) to create interactive tabbed code displays on the published website.

**Sources:** <FileRef file-url="https://github.com/doocs/leetcode/blob/ae35e0ed/solution/0000-0099/0001.Two Sum/README.md#L79-L406" min=79 max=406 file-path="solution/0000-0099/0001.Two Sum/README.md">Hii</FileRef> <FileRef file-url="https://github.com/doocs/leetcode/blob/ae35e0ed/solution/0000-0099/0001.Two Sum/README_EN.md#L76-L402" min=76 max=402 file-path="solution/0000-0099/0001.Two Sum/README_EN.md">Hii</FileRef>

### Frontmatter Metadata

Each README file begins with YAML frontmatter that defines:

- `comments`: Always `true` to enable comments on the website
- `difficulty`: Problem difficulty level (简单/Easy, 中等/Medium, 困难/Hard)
- `edit_url`: Direct GitHub link to edit the file
- `tags`: Array of topic tags in the appropriate language

Example from problem 0001:

```yaml
---
comments: true
difficulty: 简单
edit_url: https://github.com/doocs/leetcode/edit/main/solution/0000-0099/0001.Two%20Sum/README.md
tags:
    - 数组
    - 哈希表
---

Sources: solution/0000-0099/0001.Two Sum/README.md1-8 solution/0000-0099/0001.Two Sum/README_EN.md1-8

Integration with Documentation Site

MkDocs Processing Pipeline

The multi-language solution files are processed by the MkDocs build system to generate the static website. The pipeline flow is:

The actual solution code files (Solution.py, Solution.java, etc.) are embedded directly into the README markdown files as code blocks within language tabs. During the build process, MkDocs renders these tabs as interactive elements on the website.

Sources: High-level diagrams (Diagram 2), solution/0000-0099/0001.Two Sum/README.md79-406

Language Selection and Reference Implementations

Primary Reference Languages

Python and Java serve as the primary reference implementations for most problems, as evidenced by their consistent presence and completeness across the solution set. These languages are typically the first to be implemented and most thoroughly documented.

For algorithmic patterns, the implementations prioritize:

Python: Concise syntax, clear expression of algorithm logic
Java: Type safety, explicit data structure usage
C++: Performance optimization, STL usage patterns
Go: Simplicity, idiomatic Go patterns

Sources: High-level diagrams (Diagram 5), solution/0000-0099/0001.Two Sum/Solution.py1-7 solution/0000-0099/0001.Two Sum/Solution.java1-13

Coverage Across Languages

While the repository aims for comprehensive multi-language coverage, not all problems have implementations in all 12+ languages. The most complete coverage exists for:

Core LeetCode problems (0001-3799)
Classic algorithm patterns
Interview preparation problems (LCOF, LCCI series)

Less common languages like Nim or language-specific problems (SQL) have more selective coverage based on problem applicability.

Sources: High-level diagrams (Diagram 3, Diagram 5)

Example: Two Pointers Pattern Across Languages

To illustrate multi-language equivalence, here's how the two-pointers pattern is implemented in problem 0125 (Valid Palindrome):

Algorithm Description (Language-Agnostic)

The solution uses two pointers i and j pointing to both ends of the string, moving inward while:

Skipping non-alphanumeric characters
Comparing lowercase forms of characters
Returning false if mismatch found, true if pointers meet

Time complexity: O(n), Space complexity: O(1)

Sources: solution/0100-0199/0125.Valid Palindrome/README.md67-78 solution/0100-0199/0125.Valid Palindrome/README_EN.md64-76

Implementation Comparison

Language	Character Check	Case Conversion	Loop Condition
Python	`s[i].isalnum()`	`s[i].lower()`	`while i < j:`
Java	`Character.isLetterOrDigit(s.charAt(i))`	`Character.toLowerCase(s.charAt(i))`	`while (i < j)`
C++	`isalnum(s[i])`	`tolower(s[i])`	`while (i < j)`
Go	`isalnum(s[i])` (custom)	`tolower(s[i])` (custom)	`for i < j`
TypeScript	`/[a-zA-Z0-9]/.test(s[i])`	`s[i].toLowerCase()`	`while (i < j)`

Sources: solution/0100-0199/0125.Valid Palindrome/Solution.py2-13 solution/0100-0199/0125.Valid Palindrome/Solution.java2-17 solution/0100-0199/0125.Valid Palindrome/Solution.cpp3-18 solution/0100-0199/0125.Valid Palindrome/Solution.go1-25 solution/0100-0199/0125.Valid Palindrome/Solution.ts1-17

Quality Assurance Across Languages

Automated Code Formatting

Each language has automated formatting enforced through CI/CD workflows (see Code Formatting System):

Python: Black formatter with --skip-string-normalization
C++/Java: Clang-format with version 16
JavaScript/TypeScript/PHP: Prettier via lint-staged
Rust: Rustfmt (implicit)

These formatters ensure consistent code style across all language implementations.

Sources: High-level diagrams (Diagram 4), related page reference Code Formatting System

Functional Equivalence Testing

While the repository does not include explicit test suites in the source tree, each solution is validated against LeetCode's official test cases. The solutions are designed to be copy-pasteable into the LeetCode online judge, where they must pass all test cases to be considered correct.

For detailed language-specific conventions and idioms, see Language Coverage and Conventions
For code formatting configuration and CI/CD integration, see Code Formatting System
For overall architecture and build process, see Documentation Site Generation
For contribution workflow including multi-language submissions, see Contributing Guide