조기 리턴이라고 써주세요.

14908 단어 인코딩 규칙tech

자기 소개


나는 미디어 엔진의 암원github이다.대학 졸업 10년가량 제조업체의 사내 SE에서 코볼과 다양한 언어로 글을 쓰면서 사내의 다양한 시스템을 다루며 다양한 방법으로 미디어 엔진을 연결했다.버그를 잘 만드는 재능이 있기 때문에 수정하기 쉬운 코드의 작성법을 기억했다.

개시하다


조기 반격이나 보호절이라고 불리는 코딩 기교를 많은 사람들이 알고 있다고 생각한다.읽기 쉬운 코드를 쓰는 사람은 조기 리턴을 자주 사용하는 것은 아니지만 필요한 곳에서는 반드시 사용한다.
기본적으로 베테랑이라도 활용하지 못하는 경우가 있다.중요한 일이라고 생각해서 아직 못 보신 분들을 위해 썼어요.

조기 리턴


간단하게 말하자면 return를 사용하여 if의 끼워 넣는 기교를 줄이는 것이다.나는 예를 보는 것이 더 빠를 것이라고 생각한다.

조기 회차의 예


만약 함수가 사용자가 시스템을 사용할 수 있는지 조사하는 것이다. isActiveUser

적용 전


사용자가 시작일, 사용 기한 또는 정지 표지를 사용한 경우 아래 코드를 사용합니다.이번에는 예를 들어javascript로 씁니다.(개선된 것을 보시면 됩니다. 조건식은 건너뛰세요.)
const today = new Date(2021, 10, 9)

function isActiveUser(user) {
    if (user != null) {
        if (user.startDate <= today && (user.endDate == null || today <= user.endDate)) {
            if(user.stopped) {
                return false;
            } else {
                return true;
            }
        } else {
            return false;
        }
    } else {
        return false;
    }
} // isActiveUser -> 15行

const startDate = new Date(today);
startDate.setMonth(startDate.getMonth() - 1);

const user = {
    name: "iwa", 
    startDate: startDate,
    endDate: null,
    stopped: false
};

console.log(isActiveUser(user)); // -> true
이 조건식을 보니 어떤 조건에서 시스템을 사용할 수 있는지 알기 어렵다.

응용 후


이거 조기 반격으로 쓰면 이렇게 돼.
function isActiveUser(user) {
    if (user == null) { 
        return false;
    }
    
    if (today < user.startDate) { 
        return false;
    }
    
    if (user.endDate != null && user.endDate <= today) {
        return false;
    }
    
    if(user.stopped) {
        return false;
    }
    
    return true;
} // isActiveUser -> 18行
이렇게 하면 조건을 쉽게 다 읽을 수 있겠지.
(줄 수 증가...)

필법 의 비결


예는 부울 값을 되돌려주고 더 복잡한 논리가 있으면 똑같이 진행한다.
  • 초보자가 조건식 반전을 하는 훈련(<=의 반전은> 등)
  • 이상 시스템의 처리가 가능한 한 접근하기 전에 되돌아오기
  • 반대로 정상적인 시스템의 처리는 끝까지 남겨두는 것이 비교적 이해하기 쉽다
  • if 많더라도 조건을 최대한 분리해서 쓰는 것이 읽기 좋다
  • 조건이 어쨌든 복잡한 상황에서 조건 판단을 하는 방법 추출
  • return 이전에 써야 할 처리가 많은 경우 추출 방법이 있으면 1행
  • 으로 쓴다
  • 읽기 어렵지 않으면if~return 한 줄로 묶을 수 있다(코딩규약에서 허용되는 경우)
  • 예를 들어 예제의 물품에 적용될 때 이렇게 된다.return의 값 편집 방법은 사용되지 않았습니다.)
    function isActiveUser(user) {
        if (user == null) return false;
        if (today < user.startDate) return false;
        if (terminated(user)) return false;
        if (user.stopped) return false;
    
        return true;
    } // isActiveUser -> 8行
    
    function terminated(user){
        if (user.endDate == null) return false;
        if (today < user.endDate) return false;
        
        return true;
    } // terminated -> 6行
    // 計15行 = 8行 + 1行 + 6行
    
    terminated는 조건판단 방법에 조건판단을 덧붙여 과잉감을 느낄 수 있지만 사용자 유형을 정의해 처리한다면 조화롭지 못한 느낌이 들지 않을 수 있다.

    장점


    조기 반격은 플러그를 줄이는 것 외에 여러 가지 장점이 있다

    or 및 and


    조기 반격은 플러그를 줄이는 것 외에도 다양한 장점이 있다.

    처리가 가벼워짐:


    논리의 정리도 쉬우나 여분의 논리를 집행하기 전에 논리를 먼저 낼 수 있다.사용 순환 등 처리에 특별한 효과가 있다.

    행 수가 감소하고 전망이 밝습니다.


    이번 팩스 과정에서 줄 수가 조금 늘었지만 일반적으로 미리 리셋하면 줄 수가 줄어든다.행수로 읽기 쉬운 정도를 측정하는 것은 좋지 않지만, 많이 굴러가야 하는 방법보다는 굴리지 않아도 읽을 수 있는 방법이 좋다.디버깅의 간단성은 효과에서도 쉽게 알 수 있는 것 중의 하나이다.

    쓰기 쉬운 테스트:


    복합 조건의 경우 조합 테스트를 하지 않으면 안심할 수 없지만, 초기에 되돌려준 소스가 뒤쪽부터 순서대로 조건을 망라하면 이해하기 쉽다.조건망라가 간단하면 테스트 범위도 높아진다.(시험은 역시 정상과부터 쓰는 게 이해하기 쉬워요. 언제 쓰고 싶었던 장르예요.)

    조건을 쉽게 추가할 수 있습니다.


    적당한 부분에 삽입if만 하면 조건을 추가하기 쉽다.반대로 플러그 조건식의 적당한 부분을 찾기는 어렵다.

    명확한 방법의 목적:


    조기 반격에 사용할 수 없는 경우는 방법의 분할이 너무 달콤한 경우가 많다.방법의 분할 방법은 여러 가지가 있지만 조기 귀환을 위해서는 명확한 귀환 값이 필요하다.
    반환값이 명확해지면 방법의 목적도 명확해진다.

    인코딩 기본 기능 향상:


    방법의 분할은 인코딩의 기초이다.방법의 목적을 명확히 한 후에 적당한 명명을 할 수 있다.또 대상을 대상으로 프로그래밍하는 장점을 누리려면 방법 분할 능력을 갖추어야 한다.
    이의가 있을 수 있지만 개인적으로는 회귀 처리도 조기 회수로 쓰지 않기 어렵다.

    이의


    코드 스타일에 관한 화제에도 반대 의견이 많다.실제로 하면 기본적으로 상대방의 인정을 받을 수 있다.
    이전에 보고 들은 이의를 열거하다.

    한 곳만 사용하는 방법을 정의하면 보기 어렵다.


    방법 분할을 싫어하는 사람들의 의견이다.방법의 분할에 익숙하지 않을 수도 있다.또한 방법명과 반환값이 일치하지 않는 프로그램을 자주 보는 사람이라고 생각합니다.

    "return이 여러 개 있으면 보기 어려워요."


    깊게 박히지 않은 상태에서 조기 반격을 사용하지 않아도 된다.깊이 박힌 상태에서는 하나든 여러 개든 보기 힘들다.곳곳에 return를 설치하여 미리 돌아오는 팩스를 진행하세요.팩스(2단계까지의 끼워넣기 기준)를 잘 할 수 있다면 원래보다 이해하기 쉬운 코드일 것이다.

    "미리 되돌아오지 않도록 파라미터를 미리 검사해야 한다."


    그런 인코딩 스타일도 있을 것 같아요.다만, 이것은 이 화제와 별개의 일이다.조기 영수증으로 써 보고 미리 검사해 보면 알 수 있다.

    비정상적인 시스템보다 정상적인 시스템을 먼저 쓰고 싶습니다.


    잘 알고 있습니다.그러나 이를 위해 끼워 쓰면 조건의 결과가 분리돼 끝나는 이상계는 읽기 어렵다.이 단점은 대부분 정상과에서 쉽게 읽을 수 있는 장점을 넘어섰다.또 결과return와 조건이 정상적인 시스템 앞에 남아 있다.
    방법을 활용하여 추출하고 조건을 포함하여 일행으로 해결하고자 합니다.

    이동하는 와이어를 만지면 안 됩니다.


    아마도 다른 화제일 것이다. 비록 그 코드가 실행되고 있지만, 매번 변경할 때마다 많은 오류가 발생합니까?조기 보상과 방법의 추출을 통해 잠재적인 오류를 더욱 심각하게 하고 재발을 방지하는 경험이 많다.

    자원 개방의 누락을 초래하다.


    확실히 그런 상황에서는 주의가 필요하다.다행히 그런 경우는 많지 않으니 그쪽에서 사용하세요.
    또 언어에 따라 if~try처럼 자원을 잘 쓰는 방법도 있다.추상류와 함수 교부 등 기교도 존재한다.이런 것들을 사용하면 조기 리베이트를 사용해도 자원의 개방이 누락되지 않는다.

    "인코딩 규칙에 의해 결정된다는 것을 알립니다.":


    어쩔 수 없어.다른 직장에서는 다른 일이지만 나도 비슷한 경험이 있다.규칙의 결정권자가 그렇게 말하면 설득이 안되죠.(결정권자가 누군지 몰라서 몇 층을 떠났어요.)

    「 구조화된 프로그램 설계에서 중도 귀환을 금지하다 」:


    완전 오해야.존재하지 않는 언어 문제에서 서브루틴 끝부분final을 사용하여 서브루틴의 독립성을 확보하는 기술.이제 그 걱정은 사라졌다.

    끝말


    아무래도 그때나 각 팀에는 정답이 있으니 기교라는 것을 이해해 주셨으면 좋겠습니다.
    마지막으로 우리 회사는 엔지니어와 디자이너 등의 직업을 적극적으로 채용하고 있습니다!
    우리 회사 팀의 소개 페이지가 있으니 꼭 보러 오세요!
    https://mediaengine.notion.site/ba128c5708fc480198f5d8c9440a7062

    좋은 웹페이지 즐겨찾기