Programming Idioms

A Programming Idiom is a conventional way to write relatively small code constructs within a specific programming language or programming context. In Korean, it is commonly translated as 관용구 (idiomatic expression).

An idiom is not part of the language definition itself, but forms within the range of expressions the language permits. This mirrors the structure of linguistic idioms, which exist within the rules of words and grammar yet cannot be derived from those rules alone.¹

Code that conforms to idioms is called idiomatic, while code that deviates from them is called idiosyncratic. Idiosyncratic code may be grammatically correct but reads as unnatural to someone familiar with the language.

패러다임 = 프로그램을 바라보는 사고방식
원칙     = 판단을 이끄는 추상 규칙
패턴     = 반복되는 설계 문제의 재사용 가능 해법
이디엄   = 그 언어/맥락에서 자연스러운 작은 표현 방식
문법     = 언어가 허용하는 표현 규칙

The five levels above represent an abstraction hierarchy from thought to expression. Idioms apply at a smaller unit than patterns and are more abstract than syntax.

Core Definition

A Programming Idiom satisfies the following conditions.

1. 특정 언어/생태계/프레임워크에 강하게 묶여 있다.
2. 비교적 작은 코드 구성요소(한 줄에서 수십 줄 수준)에 적용된다.
3. 문제 자체보다 표현 방식에 가깝다.
4. 코드 읽기와 유지보수의 기대값을 만든다.
5. 문법적으로 필수는 아니지만, 실무적으로는 사실상 표준처럼 작동한다.

In terms of scale, idioms are smaller than Design Patterns. Both are templates to follow rather than code to copy and paste, but Design Patterns typically deal with the interactions of multiple objects or modules, whereas idioms address expression at the level of one to a few dozen lines.[1] For example, the Singleton pattern is a Design Pattern, while releasing resources via a using block in C# is an idiom.

Why It Matters

The value of idioms is most clearly apparent in team settings. When multiple expressions are possible for the same task in a given language, following the idiomatic expression reduces the cognitive load on the reader.[1] It takes less time to read the code, there is no need to infer intent, and unexpected behavior can be ruled out more quickly.

Without knowing the idioms:

- 문법은 맞지만 어색한 코드가 나온다.
- 생태계의 표준 라이브러리와 충돌한다.
- 다른 개발자가 코드를 읽을 때 의도를 추론해야 한다.
- 언어가 제공하는 안전장치와 최적화 경로를 놓친다.
- 코드 리뷰에서 지속적으로 같은 지적을 받는다.

Conversely, when you know the idioms:

- 코드의 의도가 빨리 읽힌다.
- 언어의 기본 제약을 거스르지 않는다.
- 라이브러리와 도구가 기대하는 형태에 맞는다.
- 버그를 막는 관례를 자동으로 따른다.
- 협업 비용이 줄어든다.

Code frequently shared in crowdsourced environments such as StackOverflow and GitHub effectively becomes the medium through which idioms are learned, and this is known to play a key role in helping developers cross language barriers.²

Personal note: In that sense, being Korean is itself a kind of curse as a programmer. The gap between not being a native English speaker and thinking in Korean is significant.

Idioms vs. Design Patterns

Design Patterns address recurring design problems that transcend any particular language, while idioms are closer to the expressive conventions of a specific language. That said, the two form a continuous spectrum, and idioms can reasonably be viewed as small patterns.

디자인 패턴:
반복되는 설계 문제에 대한 추상적 해결 구조
여러 객체/모듈의 상호작용 수준
언어 독립적 (구현 형태는 언어별로 변형)

프로그래밍 이디엄:
특정 언어에서 자연스럽고 관례적인 구현 방식
한 줄에서 수십 줄 수준의 표현
언어 종속적

For example, the Strategy pattern can be implemented in many languages, but the form of the implementation varies from language to language.

Java:       interface + class
Python:     callable / duck typing
JavaScript: function object
C#:         interface / delegate
Rust:       trait / enum dispatch
Haskell:    함수 인자로 전달, 또는 type class

Even the same pattern must be expressed in a way that fits each language's idioms. Directly transcribing the UML structure from a pattern book may be grammatically correct but can produce code that feels awkward in the target language.

Idioms vs. Paradigms

A Programming Paradigm is a broad way of thinking about programs. Object-oriented programming, functional programming, and procedural programming all fall into this category.

Idioms are smaller in scope. If a paradigm addresses "how to think," an idiom is closer to "how to naturally express that thinking in this particular language."

Summarized as five levels of abstraction, they are as follows.

[큰 추상]
패러다임  : 사고방식          (객체지향, 함수형, 절차적)
원칙      : 판단 기준          (SOLID, DRY, KISS, YAGNI)
패턴      : 반복 문제의 해법    (전략, 옵저버, 팩토리)
이디엄    : 언어권의 자연 표현  (RAII, list comprehension)
문법      : 가능한 표현 규칙    (if, for, class 선언)
[작은 단위]

Moving from top to bottom, language dependency increases and the unit of application becomes smaller.

Language-Specific Examples

Python

Python's idioms are commonly referred to as Pythonic.

# Less Pythonic
result = []
for i in range(len(items)):
    result.append(items[i].name)

# More Pythonic
result = [item.name for item in items]

Representative Python Idioms:

• list / dict / set comprehension

• context manager (with)

• iterator / generator

• enumerate, zip

• EAFP (Easier to Ask Forgiveness than Permission): exception-based control flow

• The contrasting concept, LBYL (Look Before You Leap): pre-check-based control flow. In Python, EAFP is considered more idiomatic.

• duck typing

• __init__.py-based module boundaries

with open("data.txt", "r", encoding="utf-8") as file:
    text = file.read()

The code above never calls file close directly. Having the with statement guarantee resource release is the standard idiom in the Python ecosystem.

C++

The defining idiom of C++ is RAII.

{
    std::lock_guard<std::mutex> lock(mutex);
    // critical section
}

Lock acquisition and release are tied to the object's lifetime. This approach guarantees that the lock is released even if an exception is thrown or an early return occurs.

Representative C++ Idioms:

Idioms are especially important in C++. Because the language provides many powerful but dangerous low-level features, idioms effectively serve as safety mechanisms.

For detailed C++ idioms, see here.

Personal note: Personally, I think C++'s biggest problem is that there are too many versions and it is heavily fragmented. I enjoy using programs written in C++, but I'd rather not encounter it in codebases I have to work on.

JavaScript / TypeScript

In JavaScript and TypeScript, asynchronous handling and object composition patterns are important idioms.

// Less idiomatic
fetch(url)
  .then((response) => response.json())
  .then((data) => {
    console.log(data);
  });

// More common form in modern TypeScript
const response = await fetch(url);
const data = await response.json();
console.log(data);

Representative JS/TS Idioms:

• async / await

• object destructuring, spread/rest

• immutable update

• discriminated union

• type guard

• optional chaining (?.)

• nullish coalescing (??)

• module boundary-centered design

In TypeScript, rather than simply attaching types, what matters is making types describe the runtime structure.

type Result<T> =
  | { ok: true; value: T }
  | { ok: false; error: string };

function handle(result: Result<number>) {
  if (result.ok) {
    return result.value;
  }

  throw new Error(result.error);
}

This kind of discriminated union is the representative TypeScript idiom for explicitly expressing error paths.

C#

In C#, LINQ, using, async/await, properties, and dependency injection all function as strong idioms.

using var stream = File.OpenRead(path);

Delegating the lifetime of IDisposable resources to using is the C# way.

Representative C# idioms:

• using / IDisposable

• LINQ

• property

• async/await + Task<T>

• extension method

• nullable reference type (string?)

• dependency injection

• record type

• pattern matching (switch expression)

Go

Go's idioms place a strong emphasis on explicitness and simplicity.

result, err := doSomething()
if err != nil {
    return fmt.Errorf("doing something: %w", err)
}

Representative Go idioms:

• explicit error return + err != nil check

• error wrapping with fmt.Errorf + %w

• goroutine + channel-based concurrency

• resource release scheduling with defer

• implicit interface satisfaction (in contrast to explicit declaration in Java/C#)

• preference for small interfaces (io.Reader, io.Writer)

• simple import paths matching the package name

type Reader interface {
    Read(p []byte) (n int, err error)
}

Keeping interfaces small and letting implementations satisfy them implicitly reflects Go's expressive philosophy.

Rust

Rust's idioms are shaped around the ownership model and explicit error handling.

fn read_config(path: &Path) -> Result<Config, ConfigError> {
    let contents = fs::read_to_string(path)?;
    let config: Config = toml::from_str(&contents)?;
    Ok(config)
}

Representative Rust idioms:

• Result<T, E> + ? operator

• Option<T> + pattern matching

• ownership transfer (move) vs. borrowing (&, &mut)

• trait-based abstraction

• match with exhaustiveness checking

• builder pattern (StructBuilder::new().with_x().build())

• newtype wrapper for semantic separation

• avoiding gratuitous .clone() calls

match value {
    Some(x) if x > 0 => println!("positive: {}", x),
    Some(_) => println!("non-positive"),
    None => println!("missing"),
}

What reflects Rust's expressive sensibility is that pattern matching is used not merely as branching, but as a direct query against data structure.

Haskell

Haskell's idioms center on function composition and leveraging the type system.

processItems :: [RawData] -> [Result]
processItems = map transform . filter isValid

Representative Haskell idioms:

• function composition (.) and point-free style

• expressing monadic computation with do-notation

• ad-hoc polymorphism via type classes

• Maybe / Either for representing absence and failure

• pattern matching + guards

• infinite data structures leveraging lazy evaluation

• Functor / Applicative / Monad abstractions

readConfig :: FilePath -> IO (Either String Config)
readConfig path = do
    contents <- readFile path
    return (parseConfig contents)

In Haskell, idioms are often directly tied to mathematical abstractions such as monads and functors, making this the area where the most is lost in translation to other languages.

Anti-idioms: Expressions to Explicitly Avoid

Negative examples are often more effective than positive ones when teaching idioms. Each language ecosystem has a catalog of anti-idioms that are explicitly considered "do not write it this way."

Python:
- mutable default argument: def f(x=[]):
- bare except 절: except:  (예외 종류 명시 없이)
- 전역 변수 변경 (global 키워드)
- type hint 없는 공개 API

C++:
- 헤더에 using namespace std;
- raw new / delete (스마트 포인터 대신)
- C 스타일 캐스트 ((int)x)
- 가상 소멸자 없는 다형성 클래스

JavaScript / TypeScript:
- == (느슨한 비교, === 사용)
- var (let / const 사용)
- any로 타입 시스템 우회 (TypeScript)
- 직접 mutation으로 React 상태 변경

C#:
- async void (이벤트 핸들러 제외)
- .Result / .Wait() 동기 차단
- 빈 catch 블록
- IDisposable을 using 없이 사용

Go:
- 에러 무시 (_ = err)
- nil 채널/슬라이스에 대한 가정
- goroutine 누수 (context 없이 무한 대기)
- panic을 일반 에러 흐름에 사용

Rust:
- 무분별한 .clone()으로 borrow checker 우회
- unwrap() 남용 (Result/Option 직접 처리)
- unsafe 블록 남용
- 큰 enum variant를 Box 없이 사용

Anti-idioms are not merely style issues. Most have real impact on safety or performance, and they are actively detected by linters and static analysis tools.

The Temporal Nature of Idioms

Idioms are not fixed constants. They change across generations as language standards are revised, standard libraries evolve, and community consensus shifts. Therefore, when discussing idioms, a temporal coordinate of "which era's idioms" is needed alongside the discussion.

Generational Changes in C++

C++98 시대:
- std::auto_ptr
- raw new / delete
- 직접 작성한 컨테이너 순회

C++11 이후:
- std::unique_ptr / std::shared_ptr
- range-based for
- auto, lambda, move semantics

C++17 / C++20 이후:
- std::optional, std::variant
- structured bindings
- 컨셉(concepts), 모듈, 코루틴

C++98 code still works if left as-is, but from a modern C++ perspective, it is no longer idiomatic.

Generational Changes in Python

Python 2:
- print 문, unicode 명시 (u"...")
- xrange / range 구분
- new-style class 대 old-style class

Python 3:
- print 함수, 문자열 = unicode 기본
- f-string (3.6+)
- type hint (3.5+, 3.10+에서 |로 union)
- dataclass, asyncio
- 구조 분해와 match-case (3.10+)

Generational Changes in JavaScript

ES5 시대:
- var, function 선언
- prototype 기반 상속
- callback hell

ES6 이후:
- let / const, arrow function
- class 키워드, 모듈 import/export
- Promise, async/await
- destructuring, spread/rest
- optional chaining, nullish coalescing (ES2020)

Even within the same language, when writing or reviewing code, one should be conscious of "which generation's idioms this belongs to." When maintaining an older codebase, consistently preserving the idioms of that era may be preferable to mixing in newer-generation idioms.

Sources and Authority of Idioms

Who decides idioms? There is no single authority; they emerge from the interaction of multiple sources.

1. 언어 설계자 / 공식 제안
   - Python의 PEP, Rust의 RFC, JS의 TC39 proposal
   - 공식 권장 사항이 이디엄의 출발점

2. 표준 라이브러리의 자기 사용 방식
   - 표준 라이브러리가 자기 API를 어떻게 쓰는지가 사실상 표준
   - Python의 itertools, Go의 io 패키지, Rust의 std 모듈

3. 린터 / 포매터의 기본 규칙
   - rustfmt, gofmt, prettier, eslint, ruff, pylint
   - 자동 적용되므로 사실상 가장 강한 강제력

4. 유명 오픈소스의 사실상 표준
   - React 코드베이스, Django 프로젝트, Kubernetes 소스
   - 큰 프로젝트의 관례가 커뮤니티 전체로 확산

5. 권위 있는 책과 가이드
   - Effective C++, Effective Java, Fluent Python
   - The Rust Book, Real World Haskell
   - Google Style Guide

When these sources conflict (for example, when the style recommended by rustfmt differs from community practice), deciding which to follow is a matter of practical judgment. Generally, (3) linters/formatters > (2) standard library > (1) official proposals carry stronger enforcement, while the weight of (4) and (5) varies by context.

Idioms Reveal a Language's Philosophy

The reason idioms differ across languages is not merely that the syntax differs; it is that the mindset each language encourages is different.

Python:     명확함, 간결함, 동적 프로토콜
C++:        자원 수명, 값 의미, 비용 모델
Java:       명시적 타입, 인터페이스, 객체 모델
JavaScript: 함수 값, 비동기 이벤트, 객체 리터럴
Rust:       소유권, 빌림, 명시적 오류 처리
Go:         단순한 제어 흐름, 명시적 에러 반환
Haskell:    순수성, 타입, 합성

As a result, directly transplanting the idioms of one language into another produces awkward code.

Java식 class hierarchy를 Python에 그대로 옮기면 과하게 무겁다.
Python식 duck typing을 Java에 그대로 옮기면 타입 시스템과 충돌한다.
C++식 수명 제어 감각 없이 C++ 코드를 쓰면 자원 누수가 난다.
JavaScript식 동적 객체 감각을 Rust에 그대로 가져오면 소유권 모델과 충돌한다.
Haskell식 함수 합성을 Java에 그대로 옮기면 어색한 functional interface 폭증으로 끝난다.

What Makes a Good Idiom

A good idiom is not simply short code.

좋은 이디엄 =
언어가 제공하는 안전장치를 활용하고
생태계가 기대하는 형태를 따르며
코드의 의도를 빠르게 드러내는 표현

A good idiom has the following properties.

• The reader can immediately grasp the intent.

• It fits well with the standard library.

• It reduces hazardous points such as exceptions, resource release, and concurrency.

• It works well with tools, linters, type checkers, and formatters.

• It does not create unnecessary abstractions.

How to Learn Idioms

Idioms are difficult to learn from a grammar book alone. You need to read the standard code of the actual ecosystem and ask questions actively.

1. 공식 문서의 예제와 자기 사용 방식 보기
2. 표준 라이브러리 사용 패턴 분석
3. 유명 오픈소스의 작은 모듈 읽기
4. 린터와 포매터가 권장하는 형태 확인
5. Effective X, The * Book류 권위 있는 가이드 읽기
6. "Why Do We Write It This Way in This Language?"를 항상 질문하기

Key questions when learning idioms:

이 언어에서는 자원 수명을 어떻게 표현하는가?
오류를 어떻게 표현하는가? (예외, Result, errno, panic)
반복과 컬렉션 처리는 어떻게 쓰는가?
추상화 단위는 함수인가, 객체인가, trait인가, interface인가?
동시성과 비동기는 어떤 방식이 자연스러운가?
모듈 경계는 어디에 그어지는가?

Consistently applying these questions lets you absorb the idioms of a new language quickly.

Research Trends

Idioms are a qualitative concept, but recent efforts have attempted to extract them quantitatively through source code mining. Allamanis and Sutton (2014) published research on automatically extracting repeatedly occurring pattern fragments from large GitHub codebases using statistical methods, naming the approach "mining idioms from source code."[1]

Such automated extraction can be used to quickly identify idiomatic expressions in a language being newly learned, or as the basis for code review tools that detect anti-idioms. However, statistically frequent expressions cannot be assumed to be idiomatic without cross-validation against authoritative sources.

Cognitive research has also been conducted on how barriers to idiom learning operate in crowdsourced development environments.[2]

Summary

A Programming Idiom is a small code expression convention considered natural in a specific language.

패러다임은 사고방식을 정한다.
원칙은 판단 기준을 정한다.
패턴은 반복 문제의 해법을 정한다.
이디엄은 자연스러운 표현을 정한다.
문법은 가능한 표현 규칙을 정한다.

A good developer is not simply someone who knows the syntax, but someone who can naturally express problems through the idioms of the language. Idioms change over time, their sources are distributed, and they are paired with explicit negative examples (anti-idioms). Being conscious of all three dimensions significantly accelerates adaptation when encountering a new language.

See Also

• Design Pattern

• Software Design Patterns

• Object-oriented programming

• Programming Paradigm

• Functional Programming

• RAII

• Standard Idioms

• Idiomatic Code

• Pythonic

• Modern C++

• Idiomatic Rust

• Composition over Inheritance

• Linguistic Idioms

• Cognitive Load

• Algorithm Skeleton

• Embedded SQL

External Links

• Programming-Idioms.org - A comparative database of idioms by language

• Wikipedia: Programming idiom

Categories: Programming | Programming Languages | Software Engineering | WIKI