추가 범위를 위해 Curly Braces를 사용하십니까? [닫은

StackOverflow https://stackoverflow.com/questions/249009

  •  05-07-2019
  •  | 
  •  

문제

기능, 클래스, while, switch, try-catch에 필요할 때 사용하는 것 외에는 다른 것을 의미합니다.

나는 그것이 그렇게 할 수 있다는 것을 몰랐다 이것은 내가 이것을 볼 때까지 그렇게 질문합니다.

위의 링크에서 Eli는 "일반적으로 접는 기능, 클래스, 루프 등에 속하지 않는 논리 섹션에서 코드를 접는 데 사용합니다."

언급 된 것 외에 어떤 다른 용도가 있습니까?

Curly Braces를 사용하여 변수의 범위를 제한하고 필요한 경우에만 범위를 확장하는 것이 좋습니다 ( "접근 할 필요"기준으로 작업)? 아니면 실제로 바보입니까?

스코프를 사용하여 다른 스코프에서 동일한 변수 이름을 사용할 수 있지만 같은 범위에서 동일한 변수 이름을 사용할 수 있습니까? 아니면 동일한 변수를 재사용하는 것이 더 나은 관행 (동일한 변수 이름을 사용하려는 경우)과 거래 및 할당을 저장하는 것이 더 나은 관행입니까 (일부 컴파일러가이를 최적화 할 수 있다고 생각합니까?)? 아니면 다른 변수 이름을 모두 사용하는 것이 더 낫습니까?

도움이 되었습니까?

해결책

특정 시간에 자유롭게 자유롭게하고 싶은 리소스를 사용하는 경우 : 예를 들어 :

void myfunction()
{
  {
  // Open serial port
     SerialPort port("COM1", 9600);
     port.doTransfer(data);
  } // Serial port gets closed here.

  for(int i = 0; i < data.size(); i++)
     doProcessData(data[i]);
  etc...
}

다른 팁

나는 몇 가지 이유로 그 목적을 위해 곱슬 괄호를 사용하지 않을 것입니다.

  1. 특정 함수가 충분히 크면 다양한 범위의 트릭을 수행 해야하는 경우 기능을 더 작은 하위 기능으로 나눕니다.

  2. 변수 이름을 재사용하기위한 범위를 소개하는 것은 코드의 혼란과 문제로 이어질 것입니다.

단지 2 센트이지만 다른 모범 사례 자료에서 이러한 유형의 많은 것들을 보았습니다.

내가 정기적으로 사용하는 가장 일반적인 "비표준"사용은 스코프 뮤트를 사용하는 것입니다.

void MyClass::Somefun()
{
    //do some stuff
    {
        // example imlementation that has a mutex passed into a lock object:
        scopedMutex lockObject(m_mutex); 

        // protected code here

    } // mutex is unlocked here
    // more code here
}

이것은 많은 이점이 있지만 가장 중요한 것은 보호 된 코드에서 예외가 발생하더라도 잠금 장치가 항상 정리된다는 것입니다.

C ++:

때로는 의미가있는 경우 가변 이름을 재사용하기 위해 추가 브레이스 수준의 범위를 도입해야합니다.

switch (x) {
    case 0:
        int i = 0;
        foo(i);
        break;
    case 1:
        int i = 1;
        bar(i);
        break;
}

위의 코드는 컴파일되지 않습니다. 당신은 그것을 만들어야합니다 :

switch (x) {
    case 0:
        {
            int i = 0;
            foo(i);
        }
        break;
    case 1:
        {
            int i = 1;
            bar(i);
        }
        break;
}

다른 사람들이 말했듯이 가장 일반적인 용도는 소멸자가 원할 때 달리기를 보장하는 것입니다. 플랫폼 별 코드를 조금 더 명확하게 만드는 데 유용합니다.

#if defined( UNIX )
    if( some unix-specific condition )
#endif
    {
        // This code should always run on Windows but 
        // only if the above condition holds on unix
    }

Windows 용 코드는 IF가 표시되지 않습니다. 이것은 다음보다 훨씬 명확합니다.

#if defined( UNIX )
    if( some unix-specific condition ) {
#endif
        // This code should always run on Windows but 
        // only if the above condition holds on unix
#if defined( UNIX )
    }
#endif

코드 생성기의 혜택이 될 수 있습니다. 내장 된 SQL (ESQL) 컴파일러가 있다고 가정합니다. SQL 문을 로컬 변수가 필요한 코드 블록으로 변환 할 수 있습니다. 블록을 사용하면 별도의 이름으로 모든 변수를 만들지 않고 고정 변수 이름을 반복해서 재사용 할 수 있습니다. 물론, 그것은 너무 어렵지는 않지만 필요한 것보다 어렵습니다.

다른 사람들이 말했듯이, 이것은 전능 한 RAII (자원 획득은 초기화) 관용구/패턴으로 인해 C ++에서 상당히 일반적입니다.

Java 프로그래머 (및 C#, 모르겠지만)의 경우 힙 기반 객체와 GC가 RAII를 죽이기 때문에 이것은 외국 개념이 될 것입니다. IMHO, 스택에 객체를 넣을 수 있다는 것은 Java보다 C ++의 가장 큰 단일 이점이며 잘 작성된 Java 코드보다 훨씬 깨끗합니다.

나는 Raii를 통해 무언가를 풀어야 할 때만 사용하고 심지어 가능한 한 빨리 릴리스해야 할 때 (예를 들어 잠금 장치를 출시) 만 사용합니다.

Java로 프로그래밍 나는 종종 방법 내에서 범위를 제한하고 싶었지만 레이블을 사용하는 것은 결코 일어나지 않았다. 레이블을 중단의 대상으로 사용할 때 대문자이기 때문에, 당신이 제안한 것처럼 혼합 된 케이스 블록을 사용하는 것은 내가이 경우에 내가 원했던 것입니다.

종종 코드 블록이 너무 짧아서 작은 메소드로 나뉘어지고 종종 프레임 워크 메소드 (startup () 또는 shutdown ())의 코드가 종종 하나의 방법으로 코드를 유지하는 것이 좋습니다.

개인적으로 나는 평범한 떠 다니는/매달린 괄호를 싫어합니다 (우리는 엄격한 배너 스타일의 들여 쓰기 상점이기 때문입니다). 나는 댓글 마커를 싫어합니다.

// yuk!
some code
{
scoped code
}
more code

// also yuk!
some code
/* do xyz */ {
    scoped code
    }
some more code

// this I like
some code
DoXyz: {
    scoped code
    }
some more code

우리는 "if (true) {"를 사용하는 것을 고려했습니다. Java 사양은 구체적으로 편집에서 최적화 될 것이라고 말하기 때문에 (if (false)의 전체 내용이 디버깅 기능입니다). 나는 그것을 시도했다.

그래서 나는 당신의 아이디어가 바보 같은 것이 아니라 좋은 생각이라고 생각합니다. 나는 항상 내가 이것을하고 싶어하는 유일한 사람이라고 생각했다.

예, 저는 RAII 때문에이 기술을 사용합니다. 나는 또한이 기술을 평범하게 사용합니다 씨 변수가 더 가깝게 제공되므로. 물론, 나는 기능을 더욱 해체 할 생각을해야합니다.

내가하는 한 가지는 아마도 문체 적으로 논란의 여지가있는 것일 것입니다. 오프닝 곱슬 브레이스를 선언 라인에 두거나 바로 의견을 제시하는 것입니다. 낭비되는 수직 공간의 양을 줄이고 싶습니다. 이것은 Google C ++ 스타일 가이드 권장 사항을 기반으로합니다..

/// c++ code
/// references to boost::test
BOOST_TEST_CASE( curly_brace )
{
  // init
  MyClass instance_to_test( "initial", TestCase::STUFF ); {
    instance_to_test.permutate(42u);
    instance_to_test.rotate_left_face();
    instance_to_test.top_gun();
  }
  { // test check
    const uint8_t kEXP_FAP_BOOST = 240u;
    BOOST_CHECK_EQUAL( instance_to_test.get_fap_boost(), kEXP_FAP_BOOST);
  }
}

나는 Agartzke에 동의합니다. 가독성을 위해 더 큰 논리적 코드 블록을 분류해야한다고 생각되면 바쁘고 혼란스러운 회원을 정리하려면 리팩토링을 고려해야합니다.

그 자리가 있지만 $ foo가 하나의 변수가 될 수 있다고 생각하지 않습니다. 여기 그리고 다른 변수 거기, 동일한 함수 또는 다른 (어휘가 아닌 논리적) 범위 내에서 좋은 생각입니다. 컴파일러는 그것을 완벽하게 이해할 수 있지만, 인간이 코드를 읽으려고하는 삶을 어렵게 만드는 것 같다.

내가 일하고있는 회사는 지역 변수 선언을 함수의 시작 부분에 유지하기위한 정적 분석 정책을 가지고 있습니다. 여러 번 사용량은 함수의 첫 번째 줄 다음에 많은 줄이므로 화면에서 선언과 첫 번째 참조를 동시에 볼 수 없습니다. 정책을 '우회'하기 위해 내가하는 일은 선언을 참조 근처에 유지하지만 곱슬 괄호를 사용하여 추가 범위를 제공하는 것입니다. 그러나 그것은 들여 쓰기를 증가시키고 일부는 코드를 추악하게 만든다고 주장 할 수 있습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top