글쎄요? 나쁜 습관으로 간주됩니까?

IMO, 읽기 어렵습니다. 나는 오른쪽으로 스크롤 한 다음 왼쪽, 오른쪽, 왼쪽 등으로 스크롤하는 것을 싫어합니다. 코딩이 더 고통스럽고 때로는 혼란 스럽습니다.

예를 들어, 긴 문자열을 코딩 할 때마다 다음을 수행합니다 ...

bigLongSqlStatement = "select * from sometable st inner join anothertable at" +
"on st.id = at.id" +
"and so on..." +
"and so on..." +
"and so on..."

그렇습니다. 문자적인 의미뿐만 아니라 일반적인 의미에서도 마찬가지입니다.

나란히 코드 차이를 좋아하고 너무 넓은 줄은 그것을 어렵게 만듭니다.

삼중 따옴표로 묶인 문자열이있는 스칼라와 같은 언어를 사용하면 런타임 비용,보기 흉한 따옴표 및 문자열의 일부를 결합하는 더하기 부호 (예에서 볼 수 있음)없이 많은 줄에서 문자열을 만들 수 있습니다.

예, 한 줄에 80자가 합리적이고 일반적으로 사용됩니다.

나에게 정말 중요한 질문입니다! 24 인치 데스크톱 모니터를 사용하는 동료와 13 인치 랩톱에서 7 개월 동안 일했으며, 읽을 수있는 줄로 줄이는 데 많은 시간을 소비한다는 것을 알게되었습니다.

80 열은 많은 경우에 약간 작지만 (vi 만 유일한 옵션으로 터미널에서 작업하는 경우 제외) ~ ~ 150 이상이 너무 큽니다 (아래 참조).

그것은 순수한 '가독성'질문입니다.

이제 '모범 사례'부분의 경우, 종종 긴 변수에 결함이있을 수 있습니다. 즉, 임시 변수에서 추출하거나 복제해야 할 부분이 있습니다 (예 : ObjectiveC, iPhone 프로그래밍의 공통 스 니펫). :

CGPoint point = CGPointMake(someOtherView.frame.origin.x + someOtherView.frame.size.width, someOtherView.frame.origin.x + someOtherView.frame.size.height);

3 차원 벡터 또는 행렬로 작업 할 때 훨씬 더 나쁠 수 있습니다.

재 작성된 예 :

CGRect frame = someOtherView.frame;
CGPoint origin = frame.origin;
CGSize size = frame.size;
CGPoint point = CGPointMake(origin.x + size.width, origin.x + size.height);

이제는 더 작은 화면에 적합하며 IDE를 사용하여 디버깅하기가 더 쉽고 표준 출력에 쓰기가 가능하며 메소드 / 프로퍼티 호출 비용에 따라 더 빠를 수도 있습니다. 이것은 물론 약간 강제적이며, 대부분의 실제 사례는 훨씬 더 복잡합니다 ...

항상 그런 것은 아닙니다.

대체보기를 추가하기 위해 코드를 읽을 때 전체 줄을 읽지 않고도 코드 줄이 무엇을하고 있는지 알 수 있습니다. 메서드 이름을 읽을 수 있지만 메서드 매개 변수가 화면에서 쏟아지면 메서드 이름만으로 해당 코드 줄의 의도를 알 수 있으므로 일반적으로 혼란스럽지 않습니다. 몇 줄의 코드가 화면에서 쏟아지면 때로는 가로로 스크롤해야한다는 단점이 더 컴팩트 한 코드에 가치가 있다고 생각합니다. 어떤 코드가 어떤 문장과 함께 진행되는지 정신적으로 구성해야하기 때문에 때로는 여러 줄의 단일 문장 코드가 산만 해집니다.

가로로 엎질러 진 코드 행은 왼쪽에 중요한 비트 (표시)와 오른쪽에 덜 중요한 비트 (화면 밖)가 있으므로 코드를 아래쪽으로 스캔 할 때 가독성이 향상됩니다. 다음 줄의 시각적으로 중요한 왼쪽 공간을 차지하는 너무 긴 줄의 덜 중요한 코드 비트를 갖는 대안과는 대조적으로 각 줄의 중요한 비트.

모든 것을 말했듯이, 나는 종종 가로로 스크롤하는 것을 원하지 않을 것입니다. 그러나이 와이드 스크린 모니터 시대에는 이것이 덜 문제가되고 있습니다.

그렇습니다.

부수적으로 팁. 여러 줄 문자열이있는 언어를 사용하고 (실제로 모든 스크립팅 언어에 포함 된) 긴 SQL을 포함하는 경우 SQL에 대해 일관된 형식 규칙을 사용하여 SQL을 여러 줄 문자열에 넣을 수 있습니다. 사용하는 서식 스타일 은 http://bentilly.blogspot.com/2011/02/sql-formatting-style.html 을 참조하십시오 .

아닙니다.

편집자가 있습니다. 줄 바꿈뿐만 아니라 줄 바꿈 들여 쓰기 가 있습니다 (화면의 너비가 100 자라고 말하면).

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.

로 표시

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut 
    labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco 
    laboris nisi ut aliquip ex ea commodo consequat.

또는 들여 쓰기 수준이 현재 언어의 기본값으로 설정되어 있습니다.

내 화면보다 넓은 선은 수동으로 줄 바꿈 된 코드보다 코드를 읽기 어렵게 만들지 않습니다.

편집 : ooooh, 나는이 대답이 인기가 없다는 것을 알았습니다 :)

확실히 그렇습니다. 신문과 잡지가 열을 사용하는 이유가 있습니다. 가독성은 중요한 요소입니다. 우리의 눈을 읽을 때 상대적으로 좌우 움직임이 적습니다. 그 결과 눈으로 우리가 읽고있는 것을 빠르게 스캔 할 수 있습니다.

화면이 넓은 기둥에 보일 때에도 눈이 앞뒤로 빠르게 스캔됩니다. 다시 스캔하는 동안 우리는 아무것도 이해하지 못합니다. 이로 인해 읽기와 이해력이 크게 느려집니다. 이 효과는 오래된 기계식 프린터와 유사합니다. 캐리지 리턴 후 캐리지 또는 프린트 헤드가 다음 라인의 위치를 ​​변경할 때까지 몇 개의 널 문자를 삽입해야하는 경우가 종종있었습니다.

또한 세로 레이아웃은 일반적으로 줄에서 내용의 그룹화를 명확하게하는 방식으로 수행됩니다. 일반적으로 복합 논리 조건에만 적용됩니다. 긴 수식은 일련의 진술로 더 잘 구성 될 수 있습니다. 옵티마이 저는 추가 오버 헤드를 수정하고 일부 옵티마이 저는 복잡한 수식을 포기하거나 성능이 저하됩니다.

큰 선이 ​​필요한 여러 개의 점이있는 식별자는 수정해야하는 코딩 기술을 나타냅니다.

마우스 휠을 사용하면 쉽게 세로로 빠르게 스크롤 할 수 있습니다. 가로로 스크롤하면 비용이 너무 많이 듭니다.

가로 스크롤을 피하십시오.

~ Windows 사용자 환경 상호 작용 지침 Pg 112

예.

영국인들은 왼쪽에서 오른쪽으로 읽음으로써 지속적인 스크롤링 = 비생산적

이런 이유로 나는 항상 IDE에서 시각적 줄 모양으로 단어 줄 바꿈 을 활성화 합니다.