제어문

1. [필수] 스위치 블록 내에서 각 케이스는 중단/반환 등으로 종료되거나 프로그램이 계속 실행될 경우를 나타내는 주석이 포함되어야 합니다. 는 코드가 없더라도 맨 마지막에 배치됩니다.

2. if / else / for / while / do 문에는 중괄호를 사용해야 합니다. 코드가 한 줄만 있어도

다음 형식은 사용하지 마세요. if(조건) 문;

3. else를 가능한 한 적게 사용하는 것이 좋습니다. if - else 메서드는 다음과 같이 다시 작성할 수 있습니다.

if(condition){
...
return obj;
}

// 그런 다음 else 비즈니스 논리 코드를 작성합니다.

if()... Else if()...else... 로직을 표현하기 위한 메소드를 사용해야 하는 경우, [필수] 3레벨을 초과하지 마세요.

3레벨을 초과하는 경우 상태 디자인 패턴을 사용하세요.

긍정적인 예: 3개 이상의 논리 수준이 있는 If-else 코드는 가드 문이나 상태 패턴을 사용하여 구현할 수 있습니다.

4. [권장] 일반적인 메소드(예: getXxx/isXxx)를 제외하고 조건부 판단에서 다른 복잡한 명령문을 실행하지 말고, 복잡한 논리적 판단의 결과를 의미 있는 부울 변수 이름에 할당하십시오. 가독성.

설명:

많은 if 문의 논리는 매우 복잡합니다. 그러면 독자는 어떤 어떤 종류의 조건이 어떤 명령문을 실행하는지 알기 위해 조건식의 최종 결과를 분석해야 합니다. 표현 오류는 어떻습니까?

긍정적 예:

//伪代码如下
boolean existed = (file.open(fileName, "w") != null) && (...) || (...);
if (existed) {
...
}

카운터 예:

if ((file.open(fileName, "w") != null) && (...) || (...)) {
...
}

5. [권장 사항] 루프 본문의 문은 성능을 고려해야 하며 다음 작업은 최대한 루프 외부로 이동해야 합니다. 객체, 변수를 정의하고

데이터베이스 연결을 가져오는 등 불필요한 try-catch 작업을 수행합니다(이 try-catch를 루프 외부로 이동할 수 있습니까).

6. [권장] 인터페이스 입력 매개변수 보호 이 시나리오는 일괄 작업에 사용되는 인터페이스에 일반적입니다.

7. [참고] 메소드에서 매개변수 확인이 필요한 시나리오:

1) 호출 빈도가 낮은 메소드.

2) 실행 시간이 많이 필요한 메소드의 경우 매개변수 검증 시간은 거의 무시할 수 있습니다. 그러나 매개변수 오류로 인해

중간 실행 롤백이나 오류가 발생하는 경우 이득이 손실보다 큽니다.

3) 매우 높은 안정성과 가용성이 요구되는 방법입니다.

4) RPC/API/HTTP 인터페이스 등 외부 세계에 제공되는 개방형 인터페이스입니다.

5) 민감한 권한 출입입니다.

8. [참고] 메소드에서 매개변수 검증이 필요하지 않은 시나리오:

1) 루프에서 호출될 가능성이 매우 높은 메서드에 대해서는 매개 변수를 확인하지 않는 것이 좋습니다. 그러나 외부 매개변수 확인은 메소드 설명에 기록되어야 합니다.

2) 기본 메서드는 자주 호출되며 일반적으로 확인되지 않습니다. 결국 이는 순수한 물 여과의 마지막 단계와 같습니다. 잘못된 매개변수는 바닥층에 도달할 때까지 문제를 노출할 가능성이 없습니다. 일반적으로 DAO 레이어와 서비스 레이어는 동일한 애플리케이션에 있고 동일한 서버에 배포되므로 DAO 매개변수 확인은 생략될 수 있습니다.

3) 비공개로 선언된 메소드는 자신의 코드에서만 호출됩니다. 메소드를 호출하는 코드에서 전달된 매개변수를 확인했거나 확실히 문제가 없다고 판단할 수 있는 경우에는 확인할 필요가 없습니다. 이때 매개변수.