05장. 표현식과 문

참고: 이웅모 《모던 자바스크립트 Deep Dive》 5장 · [MDN Grammar and types](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Grammar_and_types)

“값이 뭐고 문이 뭐지?”에서 멈추면 이후 연산·함수가 전부 흐리다. 리터럴로 값을 만들고, 표현식이 값을 낳고, 문은 그 위에서 완료를 만든다. ASI(세미콜론 자동 삽입)는 함정 보너스.

flowchart LR
  LIT[리터럴] --> VAL[값]
  EXP[표현식] --> VAL
  STMT[문] --> DONE[실행 완료]
  VAL --> STMT

5.1 값

값은 식이 평가되어 생성되는 결과. 메모리에 들어가는 실체. 변수는 값을 가리키는 이름.

5.2 리터럴

값을 생성하는 표기법. 1, 'hi', true, null, {}, [], /re/.

const n = 42;
const s = 'text';
const o = { a: 1 };

5.3 표현식

값으로 평가되는 문장 조각. 1+2, call(), x = 1(할당 표현식은 값으로 평가).

console.log(1 + 2);
const x = 3 * 4;

표현식은 값 → 다른 표현식에 끼워 넣을 수 있다.

5.4 문

프로그램을 구성하는 최소 실행 단위. 선언문·표현식 문·제어문·블록 등. 문은 “무엇을 하라”는 지시. 완료 값(completion)이 있지만 일상은 부수효과·흐름에 집중.

let a; // 선언문
a = 1; // 표현식 문
if (a) { console.log(a); }

5.5 세미콜론과 ASI

JS는 많은 경우 세미콜론을 자동 삽입한다. 규칙이 직관과 어긋나면 버그.

function f() {
  return
  { ok: true }
}
console.log(f()); // undefined — return 뒤에 ASI

a = b + c
(d + e).print()
// 한 줄로 붙어 해석될 위험

팀 규칙: 세미콜론 명시 또는 ASI-safe 스타일+린트.

5.6 표현식인 문 vs 아닌 문

표현식 문: foo(), a = 1 — 값이 있으나 문 자리에서 쓰임. 선언문·if/while/for 등은 표현식이 아님 → 값으로 안 넣음.

// eval/REPL에서 문의 완료 값이 찍히기도 함

예제

const score = 10 * 2 + 5; // 표현식들
function grade(n) {
  if (n >= 20) return 'A'; // 문 + 표현식
  return 'B';
}

const obj = {
  get value() { return 1; },
};
console.log(obj.value); // 접근도 표현식

헷갈리던 장면 / 함정

• return 다음 줄 객체
• ASI와 !/[로 시작하는 다음 줄
• “문은 값이 없다” 단순화 — completion은 있음
• 블록 { }를 객체 리터럴로 오해(문 맥락)

표

질문 → 자답

Q. 할당이 표현식? A. 예. a = b = 1 가능. 가독성 이유로 남용 비추.

Q. 블록도 문? A. 예. 블록 문. 객체 리터럴과 구분하려면 괄호 ({ a: 1 }).

웹 보강 메모

MDN ASI 규칙. ESLint semi/no-unexpected-multiline.

실무로 바로

• return과 반환값을 같은 줄 또는 괄호
• 표현식 중심 스타일(삼항·맵)과 문 중심을 섞을 때 가독성 우선
• 린트로 ASI 사고 예방

여기서 잠깐 💁‍♂️

6장 데이터 타입 — 값이 어떤 종류인지. 5의 용어 위에 타입을 얹는다.

보강 — 완료 값 감각

REPL에 if (true) { 1 } else { 2 }를 치면 1이 보이기도 한다. 문이 완료 값을 갖는 흔적. 모듈 코드에서는 보통 쓰지 않는다.

보강 — 빈 문

; 단독. for 등에 실수로 붙어 버그. 린트가 잡는다.

for (let i = 0; i < 3; i++);
  console.log(i); // 의도와 다른 구조

연습 체크리스트

• [ ] 핵심 표만 다시 그리기
• [ ] 함정 예제를 콘솔에서 재현
• [ ] MDN 링크 한 번씩 훑기
• [ ] 실무 코드에서 같은 패턴 검색
• [ ] 관련 장(앞뒤) 한 줄로 연결

일기 보강 — 헷갈림 → 찾아봄 → 정리

처음에 용어가 추상적으로 들렸다. 책을 덮고 한 줄 정의를 내 말로 다시 쓰고, 예제를 최소 세 개 쳐 보니 문제 유형이 보이기 시작했다. “외운 문장”이 아니라 “다시 설명 가능한 문장”이 남을 때까지 표를 줄였다 늘렸다.

추가 예제 블록

// 실험 1 — 기대 vs 실제를 주석으로 남긴다
console.log('실험');

// 실험 2 — 경계값
console.log('경계');

// 실험 3 — 실무 형태
function demo() { return true; }
console.log(demo());

웹·스펙 메모

MDN과 ECMA-262 용어가 다를 수 있다. 노트에는 내가 디버깅에 쓰는 말을 우선 적고, 면접용 키워드를 괄호로 병기한다. 원문 복붙 없이 “왜 이렇게 동작하나”만 남긴다.

실무 적용 한 스푼

PR 리뷰 때 이 장 키워드가 보이면 체크리스트를 붙인다. 버그 리포트에는 재현 코드와 기대/실제를 한 쌍으로 적는다. 팀 컨벤션이 없으면 이 노트 표를 초안으로 제안한다.

연습 체크리스트

• [ ] 핵심 표만 다시 그리기
• [ ] 함정 예제를 콘솔에서 재현
• [ ] MDN 링크 한 번씩 훑기
• [ ] 실무 코드에서 같은 패턴 검색
• [ ] 관련 장(앞뒤) 한 줄로 연결

일기 보강 — 헷갈림 → 찾아봄 → 정리

처음에 용어가 추상적으로 들렸다. 책을 덮고 한 줄 정의를 내 말로 다시 쓰고, 예제를 최소 세 개 쳐 보니 문제 유형이 보이기 시작했다. “외운 문장”이 아니라 “다시 설명 가능한 문장”이 남을 때까지 표를 줄였다 늘렸다.

추가 예제 블록

// 실험 1 — 기대 vs 실제를 주석으로 남긴다
console.log('실험');

// 실험 2 — 경계값
console.log('경계');

// 실험 3 — 실무 형태
function demo() { return true; }
console.log(demo());

웹·스펙 메모

MDN과 ECMA-262 용어가 다를 수 있다. 노트에는 내가 디버깅에 쓰는 말을 우선 적고, 면접용 키워드를 괄호로 병기한다. 원문 복붙 없이 “왜 이렇게 동작하나”만 남긴다.

실무 적용 한 스푼

PR 리뷰 때 이 장 키워드가 보이면 체크리스트를 붙인다. 버그 리포트에는 재현 코드와 기대/실제를 한 쌍으로 적는다. 팀 컨벤션이 없으면 이 노트 표를 초안으로 제안한다.

연습 체크리스트

• [ ] 핵심 표만 다시 그리기
• [ ] 함정 예제를 콘솔에서 재현
• [ ] MDN 링크 한 번씩 훑기
• [ ] 실무 코드에서 같은 패턴 검색
• [ ] 관련 장(앞뒤) 한 줄로 연결

일기 보강 — 헷갈림 → 찾아봄 → 정리

처음에 용어가 추상적으로 들렸다. 책을 덮고 한 줄 정의를 내 말로 다시 쓰고, 예제를 최소 세 개 쳐 보니 문제 유형이 보이기 시작했다. “외운 문장”이 아니라 “다시 설명 가능한 문장”이 남을 때까지 표를 줄였다 늘렸다.

추가 예제 블록

// 실험 1 — 기대 vs 실제를 주석으로 남긴다
console.log('실험');

// 실험 2 — 경계값
console.log('경계');

// 실험 3 — 실무 형태
function demo() { return true; }
console.log(demo());

웹·스펙 메모

MDN과 ECMA-262 용어가 다를 수 있다. 노트에는 내가 디버깅에 쓰는 말을 우선 적고, 면접용 키워드를 괄호로 병기한다. 원문 복붙 없이 “왜 이렇게 동작하나”만 남긴다.

실무 적용 한 스푼

PR 리뷰 때 이 장 키워드가 보이면 체크리스트를 붙인다. 버그 리포트에는 재현 코드와 기대/실제를 한 쌍으로 적는다. 팀 컨벤션이 없으면 이 노트 표를 초안으로 제안한다.

연습 체크리스트

• [ ] 핵심 표만 다시 그리기
• [ ] 함정 예제를 콘솔에서 재현
• [ ] MDN 링크 한 번씩 훑기
• [ ] 실무 코드에서 같은 패턴 검색
• [ ] 관련 장(앞뒤) 한 줄로 연결

일기 보강 — 헷갈림 → 찾아봄 → 정리

처음에 용어가 추상적으로 들렸다. 책을 덮고 한 줄 정의를 내 말로 다시 쓰고, 예제를 최소 세 개 쳐 보니 문제 유형이 보이기 시작했다. “외운 문장”이 아니라 “다시 설명 가능한 문장”이 남을 때까지 표를 줄였다 늘렸다.

추가 예제 블록

// 실험 1 — 기대 vs 실제를 주석으로 남긴다
console.log('실험');

// 실험 2 — 경계값
console.log('경계');

// 실험 3 — 실무 형태
function demo() { return true; }
console.log(demo());

웹·스펙 메모

MDN과 ECMA-262 용어가 다를 수 있다. 노트에는 내가 디버깅에 쓰는 말을 우선 적고, 면접용 키워드를 괄호로 병기한다. 원문 복붙 없이 “왜 이렇게 동작하나”만 남긴다.

실무 적용 한 스푼

PR 리뷰 때 이 장 키워드가 보이면 체크리스트를 붙인다. 버그 리포트에는 재현 코드와 기대/실제를 한 쌍으로 적는다. 팀 컨벤션이 없으면 이 노트 표를 초안으로 제안한다.