중괄호 배치에 대해 이미 논의한 공백에 대해서는 몇 가지 언급이있었습니다.

나는 "논리적"그룹으로 함께 모아지는 것들을 분리하기 위해 빈 줄로 내 코드를 뿌리는 경향이 있으며 다음 사람이 방금 생성 한 코드를 더 쉽게 읽을 수 있기를 바랍니다.

실제로, 나는 내가 작성한 것처럼 코드를 구성한다고 말할 것입니다. 단락을 몇 줄 (10 줄보다 짧지 않게)으로 만들고 각 단락을 독립적으로 만드십시오.

예를 들면 다음과 같습니다.

• 클래스에서는 다음 그룹에서 빈 줄로 구분하면서 함께 묶는 메서드를 그룹화합니다.
• 주석을 작성해야하는 경우 일반적으로 주석 앞에 빈 줄을 넣습니다.
• 방법에서, 나는 과정의 단계 당 하나의 단락을 만듭니다

대체로, 4/5 개 이상의 라인이 함께 클러스터링되는 경우는 거의 없습니다. 이는 매우 드문 코드입니다.

실제로이 공백을 사용하여 코드를 구성하는 데 실제로 사용하기 때문에 낭비하지는 않습니다 (실제로 들여 쓰기를 사용함에 따라).

예를 들면 다음과 같습니다.

for (int i = 0; i < 10; ++i)
{
    if (i % 3 == 0) continue;

    array[i] += 2;
}

나는 두 진술이 분명하고 뚜렷한 목적을 가지고 있기 때문에 그것을 명확히하기 위해 분리 될 가치가 있다고 생각한다.

그렇다면 실제로 코드에서 빈 줄을 어떻게 사용합니까?

항상

공백은 읽을 수있는 코드를 정리하는 데 중요합니다. 빈 줄 (또는 두 개)은 코드의 논리적 블록을 시각적으로 분리하는 데 도움이됩니다.

예를 들어, 레이아웃 및 스타일에 관한 Steve McConnell의 Code Complete, Second Edition 장에서 :

프로그램이 전혀 들여 쓰기가없는 경우보다 프로그램이 2-4 자리 공백 들여 쓰기 체계를 가질 때 이해력 테스트에서 20-30 % 더 높은 점수를 받았습니다.같은 연구에서 프로그램의 논리적 구조를 강조하거나 강조하지 않는 것이 중요하다는 것을 발견했습니다. 전혀 들여 쓰기되지 않은 프로그램에서 가장 낮은 이해 점수를 얻었습니다. 여섯 번째 공백 들여 쓰기를 사용한 프로그램에서 두 번째로 낮습니다. 이 연구는 2 ~ 4 개의 공간 들여 쓰기가 최적이라고 결론 지었다. 흥미롭게도, 실험에서 많은 피험자들은 점수가 낮더라도 6 칸 들여 쓰기가 작은 들여 쓰기보다 사용하기 쉽다고 생각했습니다. 6 개의 들여 쓰기가 만족스러워 보일 수 있습니다. 그러나 외관이 아무리 아름답더라도 6 칸 들여 쓰기는 읽기 어렵습니다. 이것은 미적 매력과 가독성 사이의 충돌의 예입니다.

명확성을 위해 예.

이 답변에서 한 것처럼.

나는하지만 나는 넣어서 그것을 문서화해야합니다

(This line intentionally left blank.)

줄에

예, 그러나 나는 그것을 남용하지 않습니다.

메서드 내부의 모든 코드 줄이 빈 줄로 구분되고 논리적 분리가 발생하는 곳에 두 개의 빈 줄이 사용되는 코드를 보았습니다. 그것은 내 의견으로는 읽기 쉽지 않습니다. 또한 다음과 같이 미친 정렬을하는 데 사용되는 공백을 보았습니다.

//Prot.   Return type                    Name                 Arg1        Arg2
//=====   ============================== ==================== =========== ========

private   int                            AMethodWithALongName(string s,   object o)
{
    ...
}

private   IDictionary<MyLongObject, int> SomethingCrazy      (string s)
{
    ...
}

protected void                           Foo                 (string str, object o)
{
    ...
}

수평 공백의 동일한 오용이 수직 공백에 적용될 수 있습니다. 다른 도구와 마찬가지로 현명하게 사용하십시오.

이런 식으로 코드를 작성하는 것에 대해 많은 비판을 받았습니다. 왜 아무도 이런 식으로하지 않는지 이해하지 못합니다.

가독성 긴 시간이 지난 후 프로젝트로 돌아 왔을 때 매우 중요하며 "코드를 읽는 다음 사람이 자신의 위치를 ​​알고있는 정신병자라면 항상 코드를 작성하십시오"라는 말을 들었습니다.

나는 항상 소프트웨어를 작성하지는 않지만 명확하게하기 위해 빈 줄을 사용합니다.

나는 코드를 최대한 명확하게하기 위해 노력하고 있으며, 공백은 종종 그 노력에 유용한 도구이다. 그러나 리팩토링을 잊지 마십시오.

• 클래스에서는 다음 그룹에서 빈 줄로 구분하면서 함께 묶는 메서드를 그룹화합니다.

여러 관련 멤버가 있으므로 새 클래스의 후보입니다.

• 주석을 작성해야하는 경우 일반적으로 주석 앞에 빈 줄을 넣습니다.

코드가 주석을 작성하기에 불분명 할 때마다 주석이 필요하지 않을 정도로 코드를 명확하게 만들기 위해 리팩터링 할 수 있는지 묻습니다.

• 방법에서, 나는 과정의 단계 당 하나의 단락을 만듭니다

각 "단락"에 대해 하나의 방법을 만들어 보시겠습니까?

수업에서 여러 가지 방법으로 끝나는 경우 새 클래스 추출에 대한 위의 참고 사항을 참조하십시오.

예. 파일을 시각적으로 쉽게 스캔 할 수 있습니다. 무엇보다도 주석이 어떤 줄과 함께 표시되는지가 더 명확 해집니다.

Some code here
// Which line does this comment go with?
More code here

// It's pretty clear which line this comment goes with
More code here

Still more code here

나는 빈 줄을 아껴서 일관되게 사용하며, 꾸준히하는 것보다 꾸준히 더 중요합니다. 하나:

• 모든 코드 줄이 빈 줄로 다음 줄과 구분되면 빈 줄이 너무 많습니다.
• 빈 줄이 어디에 있는지 쉽게 알아볼 수있는 운율이나 이유가 없다면, 산만하고 보통 너무 많습니다.
• 함수가 너무 커서 빈 줄이 많이 필요한 경우 너무 큽니다.
• 코드 블록 앞뒤에 빈 줄이 두 개 이상 필요한 경우 심각한 오류가 발생합니다.
• 함수 사이에 빈 줄이 둘 이상 있으면 빈 줄이 너무 많을 수 있습니다.

그것의 대부분은 끔찍하게 논쟁의 여지가 없습니다; 다음은 무엇 일지 모릅니다. 줄 끝에 열린 괄호가있는 K & R 표기법은 종종 빈 줄로 표시됩니다. 나는 개인적으로 줄 끝의 괄호를 싫어하고 괄호가 의미없는 의미 (IMNSHO)를 만든 후에 빈 줄과 혼합합니다. 열린 괄호를 다음 줄에 두십시오. 대부분 빈 줄이 있습니다 (그리고 더 읽기 쉬운 코드 인 IMNSHO). 줄 끝에서 K & R 버팀대를 사용해야하는 경우 빈 공간이없는 세로 공간을 낭비하지 마십시오.

// I don't like this
if (something == anotherthing) {
    print ...
    update ...
}

// I much prefer this
if (something == anotherthing)
{
    print ...
    update ...
}

// I loathe this - not least for its inconsistent spacing
if (something == anotherthing) {

    print ...
    update ...
}

// I loathe this too, for its absurd waste of vertical space
if (something == anotherthing) {

    print ...
    update ...

}

가장 읽기 쉽고 가장 놀라운 것을 쓰십시오.

function validEmail($addr) {
    $regex = "/.../";   
    return preg_match($regex, $addr);
}

이 함수는 12 줄의 문서 주석이 필요하지 않습니다.

실제로 주석이 필요하지 않습니다.

또는 빈 줄.

그들은 본질을 떨어 뜨릴 것입니다.

함수 안에서? 드물게

명확한 다른 블록이 있으면 새로운 기능으로 리팩토링됩니다. 가치가없는 경우가 거의 없습니다.

나를 위해 함수 내부의 빈 줄은 가장 잘못된 "모범 사례"중 하나입니다.

자주

유사하게 처리되는 논리적 코드 블록에 사용하십시오. 다른 단계를 수행하고 있음을 나타 내기 위해 주석을 추가하면 추출 방법입니다.

좋은 공백

{
    int x = computeX();
    x += ADJUSTMENT_FACTOR_X;

    int y = computeY();
    y += ADJUSTMENT_FACTORY_Y;

    setPosition(x, y);
}

잘못된 공백

{
    //Open a connection
    String serverAddress = lookupAddress();
    Connection connection = openConnection(serverAddress);
    connection.login(user, password);


    //Go get stuff from the server
    item1 = connection.get(1);
    item2 = connection.get(2);

    //Close connection
    connection.close();

    //log data
    log(item1);
    log(item2);

    //Update client
    gui.updateView(item1, item2);        
}    

vs

{
    Connection connection = openConnection();
    updateData(connection);
    closeConnection(connection);
    logUpdate();
    updateGui();
}

vs

{
     updateDataFromServer();
     logUpdate();
     updateGui();
}

공백을 사용할뿐만 아니라 명확성을 위해 중괄호를 사용합니다.

이것들이 잠재적으로 기능적이라고 말할 때 사용하는 괄호.

code
{
    code
    code
    code
    code
}
{
    code
    code=code
    code
    code

    code()
    code()
}

한 번에 코드 전체에 빈 줄을 자유롭게 뿌렸습니다. 요즘에는 좀 더 아끼는 경향이 있습니다. 나는 이것이 스티브 Yegge가 여기 에서 말한 것의 일부라고 생각합니다 .

내가 지금까지 그린 장면이 왜 때때로 코드를보고 즉시 싫어하는지 이해하는 데 도움이되기를 바랍니다. n00b라면 경험 많은 코드를 살펴보고 현대 소프트웨어 엔지니어링의 필수 요소를 전혀 배우지 않은 사람이 작성한 흠 잡을 데없는 헛소리라고 말할 수 있습니다. 당신이 베테랑이라면 n00b 코드를보고, 술을 마시고 밤새 인턴이 쓸 수있는 지나치게 주석 처리 된 장식용 보풀이라고 말할 것입니다.

고착 점은 압축 공차입니다. 경력을 통해 코드를 작성할 때, 특히 매우 다른 언어와 문제 영역에 걸친 코드 인 경우 코드 압축에 대한 내성이 증가합니다. 큰 글로 된 어린이 책을 읽는 것에서부터 더 작은 글씨와 더 큰 단어를 가진 점점 더 복잡한 소설에 이르기까지 진보와 다르지 않습니다.

...

압축에 대한 내성이 높은 프로그래머는 실제로 많은 스토리 텔링에 방해가됩니다. 왜? 코드베이스를 이해하려면 가능한 많은 코드를 머리에 넣을 수 있어야합니다. 복잡한 알고리즘 인 경우, 베테랑 프로그래머는 화면에서 모든 것을보고 싶어합니다. 즉, 빈 줄 수와 인라인 주석 (특히 코드가하는 일을 단순히 반복하는 주석)의 수를 줄입니다. 이것은 n00b 프로그래머가 원하는 것과 정확히 반대입니다. n00bs는 한 번에 하나의 문장이나 표현에 중점을 두어 모든 코드를 시야 밖으로 이동시켜 집중할 수 있도록 소리를 크게 내고자합니다.

나는 그에게 기본적으로 동의합니다. 너무 많은 공간을 확보하는 것보다 한 화면에서 가능한 많은 코드를 얻을 수 있도록 코드를 압축하는 것이 훨씬 좋습니다. 결코 빈 줄을 사용 해서는 안된다는 말은 아닙니다 . 그것은 당신이 만들려고하는 그룹화가 가독성을 엄청나게 높이 지 않는다면 좋은 것보다 더 해를 끼치 지 않는다고 생각합니다.

명예 교수가 훌륭한 조언 두 가지를 주었다

1. 공백은 무료입니다
2. 용지 앞쪽으로 튀어 나온 스테이플을 사용하지 마십시오.

내 경험 법칙은 다음과 같습니다.

1. 어제 작성한 코드를 읽는 데 어려움이 있다면 아마도 방법을 추출해야합니다.

2. 클래스 정의가 읽기에 너무 길면 모듈 / 인터페이스 / 개체를 추출해야합니다.

3. 메소드 정의 : 라인 추가

4. 모듈 / 클래스 정의 : 두 줄 추가

나는 공백을 단락과 같은 방식으로 생각하고 싶다. 하나의 아이디어에 기여하는 선을 함께 그룹화합니다.

새로운 아이디어 나 같은 아이디어의 새로운 측면을 시작한다면, 새로운 단락을 시작합니다.

명령형 코드에서는 하나의 응집 된 작업을 수행하는 작업을 그룹화합니다. 선언적 코드에서 아이디어에 대한 하나의 응집력있는 설명을 설명하는 코드를 그룹화합니다.

영어로하는 데 아무런 문제가 없습니다 (일부 사람들은 단락에 끔찍합니다).

빈 줄은 필자의 의견으로는 필수입니다. 나는 그것들을 사용하여 다른 논리적 코드 블록을 분리합니다. 코드를 읽을 수있게 만듭니다. 읽을 수있는 코드는 좋은 코드입니다.)

이상적인 코드 조각은 각 논리 블록이 빈 줄로 구분되고 주요 논리가있는 각 블록 위에 주석이 있습니다.

물론 사람들이 여러 곳에서 빈 줄을 여러 개 추가하여 그것을 끝내면 매우 자극적입니다.

선언과 코드를 분리하기 위해 함수 / 메소드 내에서 공백 만 사용합니다.

일부 로직을 구현하는 코드의 서브 블록을 분리하기 위해 일부 라인이 필요하다고 생각되면 다른 기능 / 개인 메소드에 있어야합니다. 너무 큰 오버 헤드를 만들지 않는 것은 컴파일러에 달려 있습니다.

일반적으로 peusdo 코드에서 :

def function(arg1, argn, ...)
    INITIALIZERS

    CODE
    BLOCK_START
        INITIALIZERS

        CODE
    BLOCK_END
    CODE
end

쓸모없는 공백이 보이면 나는 보통 울었습니다.

공백은 매우 중요합니다.

E = MC ² 와 같은 복잡한 코드를 작성하는 괴상한 사람들은 그들의 프로그래밍 기술을 잘 보여줍니다.

이제 6 개월을 앞당기 고 오전에는 오전 2시이며 6 개월 동안 보지 못한 시스템은 E = MC ² 의 바로 그 라인에서 깨졌습니다 . 이것은 디버깅이 거의 불가능합니다 ... 모두가 놀라워합니다.

코드가 다음과 같다고 가정 해 봅시다.

See Dick
See Jane
See Dick and Jan

오전 2시이고 코드가 손상된 경우 한 눈에 세 번째 줄은

See Dick and Jane

문제 해결됨.

결론 ... 공백을 사용하십시오.

많은 사람들이 언급했듯이 빈 줄은 코드를 더 쉽게 읽을 수 있도록합니다. 그러나이 표준을 적용하는 일부 언어가 있습니다. 내 머리 꼭대기에서 생각할 수있는 것 (빈 줄이 아니라 적절한 들여 쓰기)은 Python입니다.

동의합니다. 공백을 같은 방식으로 사용합니다. 그러나 공백을 사용하여 메소드를 너무 많은 부분으로 나누는 것을 발견하면 해당 코드를 여러 메소드로 리팩터링해야 할 수도 있습니다. 메소드에 논리 섹션이 너무 많으면 메소드를 테스트하기가 더 어려울 수 있습니다.

나는 그것들을 사용하여 코드를 논리 단위로 분리합니다. 나는 빈 줄을 사용하지 않은 코드 샘플을 거의 보지 못했습니다. 물론 난독 화는 제외됩니다.

Psychopath의 답변이 가장 좋지만 다음 사람이 바보라고 가정하고 그 사람을 당신이 있다고 가정하고 잘못된 것을 증명하고 싶을 것으로 대체합니다.

가독성에 중요한 것은 주석을 사용하는 것입니다. 주석 블록을 사용하여 각 함수 또는 서브 루틴을 열고 일반 텍스트, 기능, 기능, 인수 및 예상 결과 (오류 조건 목록 포함)를 설명합니다. 그렇다면 무엇을 의도하고 /하거나 설계했는지에 대해서는 의문의 여지가 없습니다. 그것이 달성하는 것은 다를 수 있지만, 그것은 더 아래로 내려갑니다.

저는 너무 많은 코더들이 코드에서 "수리"를 할 것이라고 생각하거나 단순히 신경 쓰지 않을 것이라고 생각합니다.

빈 줄이 중요합니다. 그러나 여는 중괄호에 전체 빈 줄을 낭비하면 화면에서 볼 수있는 코드의 양이 줄어 듭니다. 해야한다:

for (int i; i < 10; ++i)
{  if (i % 3 == 0) continue;

   array[i] += 2;
}

(중괄호 '{'를 'for'와 같은 줄에 넣는 것을 시작하지 마십시오.

예. 가독성을 위해. 때로는 작성하지 않은 코드에 빈 줄을 넣기도합니다. 빈 줄을 통해 논리적으로 그룹화 할 때 코드를 이해하는 것이 더 쉽다는 것을 알게되었습니다.

문자를 쓸 때와 마찬가지로 코드 블록 사이에 빈 줄을 사용해야합니다.

예를 들어, 함수 사이 또는 루프를 완료 할 때 함수 내부에서 ...

유지 보수를 해야하는 사람들은 깨끗한 코드에 감사드립니다.)

Microsoft StyleCop에서 권장하는 공백을 사용합니다. 가독성과 일관성을 제외하고 (소규모 클래스와 함께) 코드를 올바르게 배치하면 팀의 여러 사람들이 같은 영역에서 작업 할 때 병합을 훨씬 쉽게 관리 할 수 ​​있습니다.

그것이 내 상상인지 확실하지 않지만 diffing 도구는 깔끔하게 배치 할 때 병합 할 때 동등한 코드가 시작되고 끝나는 위치를 인식하는 데 더 나은 작업을하는 것처럼 보입니다. 코드를 멋지게 배치하는 것은 합병하는 기쁨입니다. 좋아, 그것은 거짓말이었다. 그러나 최소한 고통은 관리 할 수있는 수준으로 유지된다.

전체 파일이 아닌 빈 줄은 절대 사용하지 마십시오. 코드에 중단이 없다고 말하는 것은 아닙니다.

 code;
 //
 morecode;

빈 줄은 작업 할 코드 섹션을 여는 데 사용되며 편집기에 이전 / 다음 빈 줄로 이동하는 몇 개의 단축키가 있습니다.