>  기사  >  웹 프론트엔드  >  쉼표 연산자에 대한 매력적인 사례

쉼표 연산자에 대한 매력적인 사례

WBOY
WBOY원래의
2024-09-07 06:39:021161검색

A Compelling Case for the Comma Operator

쉼표 연산자는 JavaScript 및 C++와 같은 C 유사 언어에서 덜 알려진 연산자 중 하나입니다. 기본적으로 이는 일련의 표현식을 구분하고 최종 표현식의 결과만 반환합니다.

const a = 1;
const b = 2;
const c = 3;
const result = (a, b, c, 4, 5, 6, true);
console.log(result); // true
if (false, true) console.log('hello'); // hello

그렇다면 다음과 같이 묻는 것이 당연합니다. 한 줄에 여러 표현식을 집어넣는 것이 언제 유용할까요? 게다가 유용하더라도 쉼표로 구분된 일련의 표현식( 한 줄)은 세미콜론으로 구분된 일련의 명령문(여러 줄에 걸쳐)보다 더 읽기 쉽고 유지 관리하기 쉽습니까? 언제 다른 것보다 하나를 선호해야 합니까?

지난 몇 년 동안 답하기 위해 애썼던 질문들이었는데 이제 드디어 답을 얻은 것 같습니다. 이 기사에서는 쉼표 연산자에 대한 설득력 있는 사례(아마도 솔직하게 말하면 유일한 사례)를 제시합니다.

동기를 부여하는 예

먼저 조건부 삼항 연산자에 대해 이야기해 보겠습니다. 아래와 같이 조건이 참이면 값을 평가합니다. 그렇지 않으면 다른 것을 평가합니다. 여기서는 브랜치가 조건이 충족될 때만 실행되기 때문에 "평가"라는 키워드가 강조됩니다.

const result = condition ? value : another;

대부분의 경우 깔끔하고 예쁘네요. 그러나 조건부 값을 반환하기 전에 분기 사이에서 더 복잡한 논리를 수행해야 할 때 문제가 발생합니다. 이 시점에서 우리는 다음과 같은 불행한 왜곡에 의지합니다.

let result; // Uninitialized! Yikes!
if (condition) {
    // Do some complex stuff in between...
    doSomething();
    // ...
    result = value; // Actual Assignment
} else {
    // Do other complex stuff in between...
    doAnotherThing();
    // ...
    result = another; // Actual Assignment
}
// Hopefully we didn't forget to initialize `result`!

이제 이 공식에는 많은 문제가 있습니다.

  1. 처음에는 결과가 초기화되지 않았습니다. 이는 본질적으로 나쁜 것은 아니지만, 정의되지 않음으로 인한 버그를 피하는 쉽고 검증된 방법은 항상 변수를 초기화하는 것입니다.
  2. 결과 초기화는 문자 그대로 브랜치의 맨 아래에 있으며 선언과는 거리가 멀습니다.
  3. 조건문이 끝나면 결과가 확실히 초기화되기를 바랍니다. 우리가 아니라면 팀원들이 똑같이 이를 시행하기를 바랍니다. 지금은 그렇지 않더라도 미래의 개발자들도 이를 지지하기를 바랍니다!

조건부 삼항 표현식 사용을 고집하는 경우 이러한 제한을 피할 수 있는 방법이 있습니다. 코드를 함수로 리팩터링하면 됩니다. 말보다 확실히 쉽습니다. 이 특수 효과는 정말 빨리 낡아집니다!

function computeWrappedValue() {
    // ...
    return value;
}

function computeWrappedAnother() {
    // ...
    return another;
}

// How cumbersome!
const result = condition ? computeWrappedValue() : computeWrappedAnother();

(Rust와 같은) 표현 기반 프로그래밍 언어는 더 우아한 솔루션을 제공합니다. if 을 if 표현식으로 재분류하면 각 분기를 평가하여 나중에 변수에 저장할 수 있는 값을 반환할 수 있습니다.

// A conditional ternary operator thus looks like this. Each branch
// returns a value, which is captured by the `result` variable.
// We thus ensure that `result` is always initialized by construction.
let result = if condition { value } else { another };
// If we wanted to do something more complex, we use the same syntax.
let result = if condition {
    do_something();
    // In Rust, the last expression without a semicolon is the value
    // that will be "returned" by the overall `if` expression.
    result
} else {
    do_another_thing();
    another
};

이것을 C와 같은 언어로 에뮬레이션할 수 있나요? 아마도 제가 이 방향으로 나아갈 방향을 오랫동안 예상하셨을 것입니다. 하지만 그렇습니다!

설득력 있는 사례

우리가 원하는 것은 삼항 분기 내에서 값을 반환하기 전에 명령문을 임의로 실행하는 방법입니다. 다행스럽게도 이것이 정확히 쉼표 연산자의 용도입니다.

// Parenthesized for clarity.
const result = condition
    ? (doSomething(), value)       // evaluates to `value`
    : (doAnotherThing(), another); // evaluates to `another`

이 공식의 장점은 분기 표현식이 필요할 때만 평가된다는 점입니다. 우리는 표현 기반 프로그래밍 언어의 동작을 효과적으로 에뮬레이트합니다. 임시 래퍼 기능의 시대는 지났습니다!

하지만 아쉽게도 이 기술로는 여기까지만 갈 수 있습니다. 충분히 큰 n의 경우 n문장을 한 줄에 집어넣는 것은 이미 자체 기능으로 리팩토링되어야 한다고 상상할 수 있습니다. 개인적으로 나는 n >gt; 3. 그 이상은 가독성 측면에서 의심스러운 구성입니다.

// Maybe we should reconsider here?
const result = condition
    ? (x++, thing = hello(), doSomething(), value)
    : (++y, thing = world(), doAnotherThing(), another);
// Okay, stop. Definitely turn back now!
const result = condition
    ? (
        x++,
        thing = hello(),
        doSomething(),
        doMore(y),
        doEvenMore(thing),
        value,
    ) : (
        ++y,
        thing = world(),
        doAnotherThing(),
        doMore(y),
        doEvenMore(thing),
        another,
    );
// Unless, of course, you're fine with this. It kinda does
// look like a Rust `if` expression if you squint hard enough.

결론

마무리면서 우리는 쉼표 연산자에 대한 매력적인 사례인 복잡한 조건부 삼항 연산을 살펴보았습니다. 쉼표 연산자는 가지가 짧고 달콤할 때 빛을 발하지만 세 개의 인라인 문 이후에는 빠르게 유행에서 벗어납니다. 그 시점에서는 코드를 리팩토링하는 것이 더 나을 것입니다.

그럼 쉼표 연산자를 사용해야 할까요? 솔직히... 네! 읽기 쉬운 코드는 다음 독자를 염두에 두고 있으므로 쉼표 체인이 지나치게 길지 않는 한 나는 이 코딩 스타일을 받아들이고 장려할 것입니다. 대안(예: 초기화되지 않은 변수 및 리팩터링된 마이크로 함수)을 고려하면 결국 쉼표 연산자는 그렇게 나쁘지 않습니다.

실제로 나는 이미 이 재미있어 보이는 쉼표 연산자를 내 코드베이스에 뿌렸습니다. 공평하게 말하면 어쨌든 다중 문 삼항 조건문이 필요한 경우는 거의 없습니다. 하지만 그렇게 할 때 내 의도를 간결하게 표현하는 멋진 도구가 내 벨트에 있습니다.

그러므로 쉼표 연산자에 대한 설득력 있는 주장을 쉬겠습니다.

위 내용은 쉼표 연산자에 대한 매력적인 사례의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

성명:
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.