어리석은 코드: 복잡한 표현식 추출

Clever code is for ninjas. Write stupid code for stupid computers (and people)...

영리한

영리한 사람은 여기에서 무슨 일이 일어나고 있는지 명확하게 볼 수 있기 때문에 모든 표현식을 인라인으로 배치해야 합니다.

if (
    e.clientWidth < MAX_WIDTH 
    && e.clientHeight < MAX_HEIGHT
    && isVisible({ e, isFullyVisible: true})
) { 
    // OMG so many clever :-O
}

현실을 직시하자. 만약 어떤 사람이 너무 멍청해서 이것이 무엇을 의미하는지 이해하지 못한다면 그들은 처음부터 그것을 이해할 사업이 없다. 오른쪽?

심지어 영리한 사람

모든 것을 한 줄에 입력하고 자신이 얼마나 영리한지 보여주는 여러 줄 주석을 제공하면 더욱 좋습니다.

/** 
 * If the element is fully visible and its 
 * dimension are within the allowed range, 
 * then we should do something. 
 */
if (e.clientWidth < MAX_WIDTH && e.clientHeight < MAX_HEIGHT && isVisible({ e, isFullyVisible: true})) { 
   // Stupidly clever :-S
}

이렇게 하면 덜 똑똑한 사람들이 당신의 논리에 대해 추론할 수는 없지만 당신의 논리에 감탄할 수 있습니다.

평균

복잡한 표현을 추출하는 것은 평범한 사람들과 작업해야 하는 경우에만 필요합니다.

const isElementInRangeAndFullyVisible = (
    element.clientWidth < MAX_WIDTH
    && element.clientHeight < MAX_HEIGHT
    && isVisible({ element, isFullyVisible: true})
);

if (isElementInRangeAndFullyVisible) {
    // Now I can has understand B-)
}

그러나 누가 평균 시간이 있습니까? 분명히 최고의 코드만 받아들여야 합니다. 그리고 이 코드는 가장 영리한 사람들만 작업하도록 유도하기 위한 반영이어야 합니다. 일반 엔지니어가 코드를 이해할 수 있다면 잘못하고 있는 것입니다.

멍청한

어리석은 사람만이 무슨 일이 일어나고 있는지 이해하기 위해 일반 텍스트 설명과 어리석게도 구체적인 이름이 필요합니다.

/**
 * The `element` is within the max width and height and is
 * currently visible in the viewport.
 * 
 * @param element
 */
function isElementInRangeAndFullyVisible(element: HTMLElement) {
  const isWidthInRange = element.clientWidth < MAX_WIDTH;
  const isHeightInRange = element.clientHeight < MAX_HEIGHT;

  return isWidthInRange && isHeightInRange && isVisible({
    element,
    isFullyVisible: true,
  });
}

if (isElementInRangeAndFullyVisible(element)) {
    // I am five ;-P
}

내 말은, 누가 툴팁이 필요한가요?



당신이 약간의 횡설수설을 읽고 싶지 않다면 그게 전부입니다 ...

멍청한 설명

A marginally less sarcastic explanation for the above rationale.

abstact e 문자 변수의 이름을 설명 요소로 바꿉니다.

DOM 내에서 작업하는 경우 이것이 HTMLelement이라는 것이 매우 분명해 보입니다.

대부분의 JavaScript 개발자는 e가 이벤트를 나타낸다고 가정합니다.

특정 유형의 요소로 작업하는 경우 더 명시적일 수 있습니다. 이 변수들이 무엇을 나타내는지 맞춰보세요?

textarea

script

a

li

조건이 무엇인지 이해하기 위해 변수 이름을 읽으면 되기 때문에 Stupid가 더 좋습니다.

이 코드가 클래스/객체의 일부인 경우 접근자에게 각각을 추출하는 것이 더 나을 것입니다.

interface SomeElement {
  isHeightInRange: boolean;
  isWidthInRange: boolean;
  isInRange: boolean;
  isFullyVisible: boolean;
  isInRangeAndFullyVisible: boolean;
}

명시적으로 명명된 isElementInRangeAndFullyVisible 변수로 복잡한 조건을 추출합니다.

응용 프로그램 컨텍스트 내에서 이것이 무엇을 하는지 어리석게도 분명합니다.

이 변수의 이름을 바꾸려면 더 길게 만들어야 합니다. 예를 들면 다음과 같습니다.

wasElementInRangeAndFullyVisible

isElementInRangeAndFullyVisibleRightNow

isElementInRangeAndFullyVisibleAfterUpdatingProfile

조건식의 내용에 대해 걱정할 필요조차 없기 때문에 여기에서는 Stupid가 더 좋습니다. 요소가 범위 내에 있고 완전히 표시되면 어떤 일이 발생한다는 것을 알 수 있습니다.

우리가 상태에 대해 걱정해야 하는 유일한 시간은 그 일이 일어나지 않을 때입니다. 그러면 상태를 보고 그 이유를 알 수 있습니다.

이 경우 다음 두 가지 중 하나일 가능성이 높습니다.

조건이 잘못되었으므로 해당 이름을 정확하게 반영하도록 내용을 업데이트해야 합니다.

조건이 우리가 생각하는 대로 작동하지 않으므로 이름을 더 정확한 이름으로 업데이트해야 합니다.

복잡한 조건을 명시적으로 명명된 함수로 캡슐화합니다.

현실을 ​​직시하자, 당신보다 더 멍청한 누군가가 미래에 똑같은 일을 해야 할 수도 있습니다.

운이 좋다면 덜 멍청한 사람이 가정을 증명하는 몇 가지 테스트를 작성할 수도 있습니다.

방금 조건을 재사용할 수 있도록 구현했기 때문에 Stupid가 더 좋습니다.

if (isInRangeAndFullyVisible(header) {
  // ...
}

const visibleElements = [...elements].filter(isInRangeAndFullyVisible);

const result = isInRangeAndFullyVisible(header) ? doSomething(element) : doNothing(element);

그리고 당신의 어리석음은 테스트할 수 있다는 추가적인 이점이 있습니다.

it('should fail check if not in range and fully visible', () => {
  const element = document.querySelector('.not-visible');

  expect(isInRangeAndFullyVisible(element))
    .toBe(false);
});

it('should fail check if in range and partially visible', () => {
  const element = document.querySelector('.in-range.partially-visible');

  expect(isInRangeAndFullyVisible(element))
    .toBe(false);
});


it('should pass check if in range and partially visible', () => {
  const element = document.querySelector('.in-range.fully-visible');

  expect(isInRangeAndFullyVisible(element))
    .toBe(true);
});