2009-03-11 2 views
70

중괄호, 다음의 두 조각을 고려자바 스위치 케이스 : 중괄호가 있든 없든?

switch (var) { 
    case FOO: { 
    x = x + 1; 
    break; 
    } 

    case BAR: { 
    y = y + 1; 
    break; 
    } 
} 

중괄호없이 :

switch (var) { 
    case FOO: 
    x = x + 1; 
    break; 

    case BAR: 
    y = y + 1; 
    break; 
} 

나는 중괄호와 코드에서, 새로운 범위가 중괄호에서 각각의 경우를 둘러싸고하여 만든 것으로 알고 있습니다. 그러나 각 사례에 새로운 범위가 필요하지 않은 경우 (즉, 변수 이름을 다시 사용하지 않는 경우) 사례와 함께 중괄호를 사용하면 성능상의 불이익이 있습니까?

답변

78

사례와 함께 중괄호를 사용하면 어떤 종류의 성능 저하가 있습니까?

없음.

중괄호는 컴파일러가 변수, 조건, 함수 선언 등의 범위를 파악하는 데 도움이됩니다. 코드를 실행 파일로 컴파일하면 런타임 성능에 영향을주지 않습니다.

5

이 질문은 아마도 "논쟁의 여지가"(BRACE WAR!)로 끝날 것입니다. 나는 사실상 괄호를 좋아한다. 나에게 이것은 추악한 스위치 구문을 나머지 언어 구문과 비슷하게 보이게 만든다. (이 "중"의 경우 중괄호 사용에 대한 패널티는 없습니다.)

+0

나는 그것이 객관적인 질문이라고 생각한다. 나는 논쟁적인 것을 철회한다. –

+0

나는 중괄호없이 그것을 선호한다. 나는 중괄호가 불필요한 많은 잡음을 추가하는 것을 발견한다. – cdmckay

+0

그래,이게 더 좋을 것 같아. case (FOO) {x = x + 1} case (BAR) {y = y +1} –

5

변수 이름을 다시 사용하지 않기 때문에 중괄호를 생략 할 수 있습니다. 변수 이름을 재사용함으로써 동일한 유형의 새 변수를 선언한다는 것을 의미한다고 가정합니다.

실수로 다른 변수 case에 같은 변수를 재사용하지 않도록 중괄호를 사용하는 것이 가장 좋습니다. 그들은 현재 어떤 변수도 선언하지 않지만 누군가는 내일 그것을 추가 할 것이고 중괄호가 없으면 코드가 오류가 발생하기 쉽습니다.

21

이것은 조기 최적화의 극단 예입니다. 어떤 방법으로 읽고 디버그하기가 더 쉬운 지에 대해 걱정하는 것이 더 좋은 아이디어 일 것입니다.

+82

아니면 그냥 궁금한가요? – cdmckay

+14

동의. 최적화가시기 상조인지 여부를 확인하는 유일한 방법은 이러한 유형의 질문을하는 것입니다. –

+13

Yer, 너에게 발굴 될 의도가 아니야.그러나 나는 항상 가독성이 코드의 가장 중요한 측면이라는 것을 상기시킨다. – Travis

16

실행 시점에서 성능 저하는 없습니다.

가 구문 분석하는 데 더 많은,하지만 아무도 그것에 대해 실제로 걱정한다면 그들이 지금은

그리고 :-) 모두 한 줄에 자신의 코드를 작성해야하는 것처럼보기의 컴파일 지점에서

약간의 성능 저하 우리 포스트의 의견 부분 ... 저는 항상 {와}를 사용합니다. 왜냐하면 나중에 유지해야 할 가능성이 높기 때문에 관리성에 대한 벌칙이 있기 때문이며 나중에 사용하게되면 고통이 될 수 있습니다. ..하지만 그것은 103 % 개인 선호입니다.

+2

+1 고통에 대한 생각 – Travis

+0

나 자신이 대답을 볼 수 없기 때문에 약간 궁금해서 ... @ 토후 비어, 언제 중괄호를 추가해야합니까? 또한 유지 관리 요점에 완전히 동의합니다. 유지 관리 문제 ATM을 보지 못했습니다. 편집 : 신경 끄시 고. 나는 그저 아래 답변들을 읽었을 뿐이다. – nyaray

+0

C++에서 어떤 경우에는 그렇게합니다. 따라서 두 언어로 작업 할 경우 중대한 습관이 아닙니다. – TofuBeer

8

중괄호를 사용합니다.

내가 어디에 내가 할 수있는 그들을 피하려고 스위치 문으로 잘못 될 수있는 많은 일들이 기본 케이스를 잊어

  1. 잊어 휴식 따라서 가진 경우가 - 스루
  2. 즉,있다, 따라서 uncated 조건을 포착하지 않음
  3. 실수로 case 문 사이에서 변수를 재사용하거나 더 나쁜 것은 case 문 사이에 변수를 공유하는 변수에 영향을 미칩니다.괄호를 사용

는 내가 전에 그것에 대해 생각해 본 적이 없는데

+6

포인트 1과 2를 포함하면이 질문에 대한 오해의 소지가있었습니다 (나를 위해); 클로징 라인은 명시 적으로 중괄호가 3을 해결한다고 말해야합니다 - 중괄호가 중단의 필요성을 배제한다는 것을 의미한다고 생각했습니다. – ataulm

+0

포인트 3은 의미가 없습니다. 변수가 switch 문의 부모 범위에서 선언되지 않은 한 변수를 다시 사용할 수 없습니다. 즉, 변수를 사례 안에 선언하면 다른 사례 문에서 변수를 사용할 수 없습니다. switch 문 (부모 범위 내) 위에 변수를 선언하면 중괄호를 사용하는지 여부는 중요하지 않지만 case 문은 변수에 액세스 할 수 있습니다. – dsingleton

1

경우 문 사이에 변수의 의도적 인 실수로 공유를 모두 방지 할 수있는 한 가지 방법입니다. case 절에 중괄호를 쓸 필요가 없으므로 왜 필요하다고 생각하는지 정말로 알 수 없습니다. 개인적으로는 "유지 관리가 더 쉬울 것"이라고 생각하지 않습니다. 단지 쓰레기 일 뿐이므로 코드가 이해되고 문서화되면 유지 관리가 더 쉬울 것입니다.

중괄호 없음 ... 구문이 적습니다.

+0

{및}을 사용하면 더 쉽게 읽을 수 있습니다 (IMO). – TofuBeer

+1

모두 의견이 있습니다 –

+0

예. 한 번 수정해야했던 방법에 대한 이야기를 들려 주려고했는데 (한 줄의 코드를 추가하는 데 약 4 시간이 걸렸습니다) 코드가 미친 듯 (약 10 페이지 길이와 4 페이지 넓이로 인쇄되었을 때) 전형적인 경우. 그러나 만약에 {}을 사용했다면 그것을 추가하는데 1 분이 걸렸을 것입니다. – TofuBeer

3

스위치 케이스에는 중괄호를 사용하지 않습니다.

  • switch 문은 이미 중괄호없이 바로크 식으로 보입니다.

  • 스위치 케이스는 매우 짧아야합니다. 변수를 선언해야하는 경우 잘못하고 있다는 표시입니다. 스위치의 경우에

    스포츠 500 개 라인의 경우 스위치 일부 기존 C 코드를 유지 오프 이제

...

12

우리가 알다시피 중괄호가 필요하지 않습니다. 중괄호를 사용하면 사례의 범위에 혼란을 야기 할 수 있습니다.

여는 중괄호는 일반적으로 함수의 시작이나 루프 시작 또는 클래스 선언 시작 또는 배열 초기화 시작과 같은 의미있는 항목과 관련이 있습니다. 스위치 블록에서 break 문을 만나게됩니다. 따라서 중괄호를 사용하는 것은 무지한 독자에게 사례에 대한 다른 범위의 아이디어를 암시하는 것처럼 보입니다. 따라서 프로그래밍 가독성을 높이기 위해 중괄호를 사용하지 않는 것이 좋습니다.

나는 "1 안녕"과 같은,

switch(i) 
{ 
    case 1 : 
    { 
    //do something 
    } 
    System.out.println("Hello from 1"); 

    case 2: 
    .... 
} 

이있을 때 즉 인쇄됩니다. 그러나 중괄호를 사용하면 무의미한 독자에게 '}'로 끝나는 것을 알 수 있습니다. 이미 중괄호가 일반적으로 루프, 메서드 등의 경우에 무엇을 의미하는지 알 수 있습니다.

'C 컨트롤이 사건으로 이동하고 실행을 계속합니다. 따라서, 스위치를위한 사례를 작성할 때 중괄호를 사용하는 것은 잘못된 생각입니다.

기술적으로 말하면 유효한 구문과 함께 사용하면 코드 블록을 중괄호로 둘러 쌀 수 있습니다. 스위치에 중괄호를 사용하는 것은 내가 위에서 말한 것처럼 다른 느낌을 줄 것으로 보이는 것처럼 나에게 너무 나빠 보인다.

내 제안 : 스위치 케이스에는 주변의 괄호를 사용하지 마십시오.

+0

이에 동의하지 마십시오. 중괄호를 사용하고 중괄호 외부에 코드를 작성하는 것은 매우 나쁜 형식이 될 수 있지만 그렇다고해도 중괄호를 사용하는 것은 의심의 여지가 없습니다. – caseif