Multi-Language Support

Relevant source files

• images/contributors.svg
• solution/0000-0099/0001.Two Sum/README.md
• solution/0000-0099/0001.Two Sum/README_EN.md
• solution/0000-0099/0001.Two Sum/Solution.cpp
• solution/0000-0099/0001.Two Sum/Solution.cs
• solution/0000-0099/0001.Two Sum/Solution.go
• solution/0000-0099/0001.Two Sum/Solution.java
• solution/0000-0099/0001.Two Sum/Solution.js
• solution/0000-0099/0001.Two Sum/Solution.nim
• solution/0000-0099/0001.Two Sum/Solution.php
• solution/0000-0099/0001.Two Sum/Solution.py
• solution/0000-0099/0001.Two Sum/Solution.rb
• solution/0000-0099/0001.Two Sum/Solution.rs
• solution/0000-0099/0001.Two Sum/Solution.swift
• solution/0000-0099/0001.Two Sum/Solution.ts
• solution/0100-0199/0125.Valid Palindrome/README.md
• solution/0100-0199/0125.Valid Palindrome/README_EN.md
• solution/0100-0199/0125.Valid Palindrome/Solution.cpp
• solution/0100-0199/0125.Valid Palindrome/Solution.cs
• solution/0100-0199/0125.Valid Palindrome/Solution.go
• solution/0100-0199/0125.Valid Palindrome/Solution.java
• solution/0100-0199/0125.Valid Palindrome/Solution.js
• solution/0100-0199/0125.Valid Palindrome/Solution.php
• solution/0100-0199/0125.Valid Palindrome/Solution.py
• solution/0100-0199/0125.Valid Palindrome/Solution.ts
• solution/0200-0299/0272.Closest Binary Search Tree Value II/README.md
• solution/0200-0299/0272.Closest Binary Search Tree Value II/README_EN.md
• solution/0200-0299/0272.Closest Binary Search Tree Value II/Solution.cpp
• solution/0200-0299/0272.Closest Binary Search Tree Value II/Solution.go
• solution/0200-0299/0272.Closest Binary Search Tree Value II/Solution.java
• solution/0200-0299/0272.Closest Binary Search Tree Value II/Solution.py

Purpose and Scope

This document describes the multi-language implementation system in the doocs/leetcode repository, covering how algorithmic solutions are consistently implemented across 10+ programming languages. Each problem includes solution files in Python, Java, C++, Go, TypeScript, Rust, JavaScript, and several other languages, all implementing identical algorithmic logic while following language-specific idioms and conventions.

For information about the overall problem organization structure, see Problem Organization. For details on code quality gates and CI/CD workflows, see Development Workflow.

Supported Languages and File Naming

The repository provides solution implementations in the following languages, each with standardized file naming conventions:

Language	File Extension	Example File	Formatter
Python	.py	Solution.py	Black
Java	.java	Solution.java	clang-format
C++	.cpp	Solution.cpp	clang-format
Go	.go	Solution.go	gofmt (implicit)
TypeScript	.ts	Solution.ts	Prettier
Rust	.rs	Solution.rs	rustfmt
JavaScript	.js	Solution.js	Prettier
C#	.cs	Solution.cs	-
PHP	.php	Solution.php	-
Swift	.swift	Solution.swift	-
Ruby	.rb	Solution.rb	-
Nim	.nim	Solution.nim	-
Kotlin	.kt	Solution.kt	-
Scala	.scala	Solution.scala	-
C	.c	Solution.c	clang-format
Cangjie	.cj	Solution.cj	-

Sources: solution/0000-0099/0001.Two Sum/Solution.py1-8 solution/0000-0099/0001.Two Sum/Solution.java1-13 solution/0000-0099/0001.Two Sum/Solution.cpp1-15 solution/0000-0099/0001.Two Sum/Solution.go1-12 solution/0000-0099/0001.Two Sum/Solution.ts1-12 solution/0000-0099/0001.Two Sum/Solution.rs1-16 solution/0000-0099/0001.Two Sum/Solution.js1-17 solution/0000-0099/0001.Two Sum/Solution.cs1-16 solution/0000-0099/0001.Two Sum/Solution.php1-18 solution/0000-0099/0001.Two Sum/Solution.swift1-14 solution/0000-0099/0001.Two Sum/Solution.rb1-14 solution/0000-0099/0001.Two Sum/Solution.nim1-12

Problem Directory Structure with Multi-Language Solutions

Each problem directory follows a consistent structure that accommodates all language implementations:

Directory Structure: Problem 0001 (Two Sum) as Example

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.swift # Swift implementation ├── Solution.rb # Ruby implementation ├── Solution.nim # Nim implementation ├── Solution.kt # Kotlin implementation ├── Solution.scala # Scala implementation └── Solution.c # C implementation 

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

Idiomatic Implementation Patterns Across Languages

While implementing the same algorithmic logic, each language version follows language-specific idioms and uses native data structures:

Hash Table Pattern Example: Two Sum Problem

The Two Sum problem demonstrates how hash tables are implemented idiomatically across languages:

Python (Dynamic Typing, Dict):

Java (Static Typing, HashMap):

C++ (STL, unordered_map):

Go (Native map, ok idiom):

Rust (Ownership, Option types):

Sources: solution/0000-0099/0001.Two Sum/Solution.py1-8 solution/0000-0099/0001.Two Sum/Solution.java1-13 solution/0000-0099/0001.Two Sum/Solution.cpp1-15 solution/0000-0099/0001.Two Sum/Solution.go1-12 solution/0000-0099/0001.Two Sum/Solution.rs1-16

String Processing Pattern Example: Valid Palindrome

Character validation and case conversion demonstrate different standard library approaches:

Python (str methods): solution/0100-0199/0125.Valid Palindrome/Solution.py1-14 uses s[i].isalnum() and s[i].lower() for built-in character classification.

Java (Character utility class): solution/0100-0199/0125.Valid Palindrome/Solution.java1-18 uses Character.isLetterOrDigit() and Character.toLowerCase() static methods.

C++ (ctype.h functions): solution/0100-0199/0125.Valid Palindrome/Solution.cpp1-19 uses isalnum() and tolower() from the C standard library.

Go (custom implementations): solution/0100-0199/0125.Valid Palindrome/Solution.go1-26 implements custom isalnum() and tolower() functions using byte comparisons and arithmetic for explicit control.

Sources: solution/0100-0199/0125.Valid Palindrome/Solution.py1-14 solution/0100-0199/0125.Valid Palindrome/Solution.java1-18 solution/0100-0199/0125.Valid Palindrome/Solution.cpp1-19 solution/0100-0199/0125.Valid Palindrome/Solution.go1-26

Code Formatting and Quality Control System

The repository employs language-specific formatters to ensure consistent code style across all implementations:

Formatter Configuration Files

The formatters are configured through repository-level configuration files:

• .prettierrc: Configuration for JavaScript, TypeScript, SQL, and Markdown files
• .clang-format: Configuration for C, C++, and Java files
• Black: Invoked with -S flag to skip string normalization

Automated Linting Workflows

GitHub Actions workflows enforce formatting standards:

1. black-lint.yml: Validates Python code formatting using Black

   • Triggered on push events to solution/** paths
   • Ensures all .py files follow Black's formatting rules with -S flag

2. prettier.yml: Validates JavaScript, TypeScript, and related file formatting

   • Triggered on pull requests
   • Checks .js, .ts, .sql, and .md files

3. clang-format-lint.yml: Validates C/C++/Java formatting

   • Triggered on push events
   • Uses .clang-format configuration

Sources: Based on repository structure descriptions from the high-level diagrams showing formatters (Diagram 3) and CI/CD workflows (Diagram 4)

Documentation Integration with Multi-Language Code

The bilingual documentation system (Chinese and English) integrates seamlessly with multi-language code implementations:

README Structure for Multi-Language Solutions

Both README.md (Chinese) and README_EN.md (English) follow identical structures:

1. Frontmatter: Metadata including difficulty, tags, and edit URL
2. Problem Description: Complete problem statement with examples and constraints
3. Solution Explanations: Algorithm descriptions with time/space complexity analysis
4. Code Tabs: Embedded code snippets for each language using markdown tab syntax

Example: Two Sum Problem Documentation Structure

solution/0000-0099/0001.Two Sum/README.md1-410 demonstrates the structure:

Java

C++

 The English version <FileRef file-url="https://github.com/doocs/leetcode/blob/291f917b/solution/0000-0099/0001.Two Sum/README_EN.md#L1-L407" min=1 max=407 file-path="solution/0000-0099/0001.Two Sum/README_EN.md">Hii</FileRef> follows the same structure with translated content. **Sources:** <FileRef file-url="https://github.com/doocs/leetcode/blob/291f917b/solution/0000-0099/0001.Two Sum/README.md#L1-L410" min=1 max=410 file-path="solution/0000-0099/0001.Two Sum/README.md">Hii</FileRef> <FileRef file-url="https://github.com/doocs/leetcode/blob/291f917b/solution/0000-0099/0001.Two Sum/README_EN.md#L1-L407" min=1 max=407 file-path="solution/0000-0099/0001.Two Sum/README_EN.md">Hii</FileRef> ## Language-Specific Implementation Count While all major problems support the core languages (Python, Java, C++, Go, TypeScript, Rust, JavaScript), some languages have selective coverage: - **Core Languages** (near-universal coverage): Python, Java, C++, Go, TypeScript, Rust, JavaScript - **Secondary Languages** (extensive but not universal): C#, PHP, Swift, Ruby - **Specialized Languages** (selective coverage): Kotlin, Scala, Nim, Cangjie The implementation priority typically follows: 1. Python (highest coverage, often the first implementation) 2. Java, C++, Go (nearly complete coverage) 3. TypeScript, Rust, JavaScript (modern language focus) 4. Other languages (contributor-driven additions) **Sources:** <FileRef file-url="https://github.com/doocs/leetcode/blob/291f917b/solution/0000-0099/0001.Two Sum/README.md#L79-L404" min=79 max=404 file-path="solution/0000-0099/0001.Two Sum/README.md">Hii</FileRef> showing code tabs for 16+ languages, <FileRef file-url="https://github.com/doocs/leetcode/blob/291f917b/solution/0100-0199/0125.Valid Palindrome/README.md#L81-L302" min=81 max=302 file-path="solution/0100-0199/0125.Valid Palindrome/README.md">Hii</FileRef> showing similar coverage ## Cross-Language Consistency Mechanisms Several mechanisms ensure consistency across language implementations: ### 1. Identical Algorithm Structure Despite syntactic differences, all implementations follow the same logical flow: **Example: Two Pointers Pattern in Valid Palindrome** All language versions implement: - Two pointers `i` and `j` at string start/end - Skip non-alphanumeric characters - Compare lowercase versions - Move pointers toward center - Return true if pointers meet This is evident comparing <FileRef file-url="https://github.com/doocs/leetcode/blob/291f917b/solution/0100-0199/0125.Valid Palindrome/Solution.py#L1-L14" min=1 max=14 file-path="solution/0100-0199/0125.Valid Palindrome/Solution.py">Hii</FileRef> <FileRef file-url="https://github.com/doocs/leetcode/blob/291f917b/solution/0100-0199/0125.Valid Palindrome/Solution.java#L1-L18" min=1 max=18 file-path="solution/0100-0199/0125.Valid Palindrome/Solution.java">Hii</FileRef> <FileRef file-url="https://github.com/doocs/leetcode/blob/291f917b/solution/0100-0199/0125.Valid Palindrome/Solution.cpp#L1-L19" min=1 max=19 file-path="solution/0100-0199/0125.Valid Palindrome/Solution.cpp">Hii</FileRef> and <FileRef file-url="https://github.com/doocs/leetcode/blob/291f917b/solution/0100-0199/0125.Valid Palindrome/Solution.go#L1-L26" min=1 max=26 file-path="solution/0100-0199/0125.Valid Palindrome/Solution.go">Hii</FileRef> ### 2. Common Variable Naming Variable names remain consistent across implementations where language conventions allow: - `nums` for array inputs - `target` for target values - `d` for dictionary/map structures - `i`, `j` for index pointers - `x`, `y` for temporary values ### 3. Complexity Analysis Documentation Each solution in the README files includes time/space complexity analysis that applies to all language implementations, ensuring the algorithmic approach is universally understood regardless of implementation language. **Sources:** <FileRef file-url="https://github.com/doocs/leetcode/blob/291f917b/solution/0000-0099/0001.Two Sum/README.md#L67-L78" min=67 max=78 file-path="solution/0000-0099/0001.Two Sum/README.md">Hii</FileRef> <FileRef file-url="https://github.com/doocs/leetcode/blob/291f917b/solution/0100-0199/0125.Valid Palindrome/README.md#L64-L78" min=64 max=78 file-path="solution/0100-0199/0125.Valid Palindrome/README.md">Hii</FileRef> ## Contributing New Language Implementations When adding solutions in new languages or filling gaps in existing coverage, contributors should: 1. **Follow the naming convention**: `Solution.{ext}` where `{ext}` is the standard extension 2. **Match the algorithm**: Implement the same algorithmic approach as existing languages 3. **Use idiomatic patterns**: Employ language-specific idioms and standard libraries 4. **Format according to standards**: Apply appropriate formatters before submission 5. **Update README tabs**: Add code snippet to both `README.md` and `README_EN.md` with proper tab syntax For details on the contribution workflow and quality gates, see [Contributing Guide](#7.4). **Sources:** Based on existing multi-language solution patterns observed across <FileRef file-url="https://github.com/doocs/leetcode/blob/291f917b/solution/0000-0099/0001.Two Sum/" undefined file-path="solution/0000-0099/0001.Two Sum/">Hii</FileRef> and <FileRef file-url="https://github.com/doocs/leetcode/blob/291f917b/solution/0100-0199/0125.Valid Palindrome/" undefined file-path="solution/0100-0199/0125.Valid Palindrome/">Hii</FileRef> directories