저는 Code Complete를 읽고 레이아웃과 스타일에 관한 장에서 코드 편집기가 일종의 서식있는 텍스트 형식을 사용할 것이라고 예측했습니다. 이는 다음과 같은 코드 대신에

Procedure ResolveCollisions
{ Performs a posteriori collision resolution through spatial partitioning algoritm }
(
  CurrentMap : SpriteContext,
  PotentialColliders: SpriteList
)
var Collider  : Sprite, 
    Collidee  : Sprite, 
    Collision : SpriteCollision
begin
  DoStuff();
end.

다음과 같이 보일 수 있습니다.

순서 ResolveCollisions

공간 분할 알고리즘을 통해 후부 충돌 해결을 수행합니다.

매개 변수

• CurrentMap : SpriteContext
• PotentialColliders : SpriteList

지역 변수

• Collider : Sprite
• Collidee : Sprite
• Collision : SpriteCollision

    DoStuff();

구문 색상 표시 및 강조 표시 및 괄호 색상 표시를 보았지만 실제 코드에서는 이와 같이 보이지 않았습니다. 나는 이런 종류의 것이 실제로 존재했는지, 아니면 그것이 충분한 이익을 얻지 못했거나 완전히 나쁜 생각이라고 결정했는지 궁금합니다.

이전에 이와 같이 풍부한 형식의 코드를 보았거나 아이디어가 고려되어 결국 거부되었는지 알고 있습니까?

당신이 할 수 없었던 기술적 이유는 없습니다. 텍스트 편집기가 구문 강조를 수행 할 수 있으면 코드를 강조 표시하기 위해 디스플레이의 다른 측면을 쉽게 변경할 수 있습니다.

그러나 편집기에서 입력하는 내용을 파악할 때 색상을 변경하는 것이 무엇보다 중요합니다. 입력하는 동안 텍스트의 크기가 갑자기 바뀌고 뛰어 다니는 것은 정말 불쾌합니다.

그러나 '정적'코드 표시의 경우 소스 코드를 쉽게 아름답게 만들 수 있습니다. 예를 들어 중간 정도의 소스-> HTML 변환기를 가져 와서 원하는 글꼴 크기와 스타일을 스타일 시트에 추가하면 서식있는 코드가 풍부합니다.

간단한 이유 : 에디터 / 툴 독립성.

"풍부한"코드를 작성하면 사용한 편집기 또는 서식있는 코드를 이해할 수있는 편집기에 연결됩니다. 풍부함을 처리 할 수없는 다른 모든 편집자는 횡설수설을합니다.

같은 맥락에서 리치 코드는 diff 도구와 잘 어울리지 않습니다. 예를 들어, 일부 서식을 변경 한 경우 차이에 차이가 표시되지만 가장 중요하지 않은 차이도 아닙니다.

버전 관리는 어떻습니까? 서식의 모든 변경 사항을 무시하고 "실제"변경이있을 때만 파일을 수정 된 것으로 보는 방법은 무엇입니까?

마지막으로, 풍부한 코드의 요점은 가독성이라고 생각합니다. 더 나은 의견, 논리적 식별자 이름 및 일관된 들여 쓰기만으로 충분하다고 생각합니다.

본질적으로 프로그래밍 텍스트는 일반 텍스트로 가장 잘 처리됩니다. 현재보고있는 것은 실제 내용입니다. ( 또한 암시 적보다 명시 적 낫다는 Pythonic 아이디어와 일치합니다 )

풍부한 형식의 코드는 그렇게 멋진 아이디어가 아니기 때문에 따라 잡지 않았을 것입니다. 개인적으로, 나는 당신이 제시 한 예에서 보는 것을 좋아하지 않습니다. 구문 색상 표시 및 강조 표시를 사용하지만 서식이 너무 어려워서 코드를보고 쓰는 데 익숙하지 않은 방식과 너무 다릅니다.

왜 존재하지 않습니까? 수요 / 필요가 없습니다.

현재 편집자는 구문 강조 및 기타 사소한 스타일 옵션을 사용하여 프로그래머의 요구를 충족시킬 수 있습니다. "리치 텍스트"가 아닙니까?

이것은 Emacs 용 AucTeX 모드의 LaTeX에 이미 존재합니다. 섹션 제목은 크기가 크며 하위 및 위첨자는 적절하게 크기가 조정되며 수학 미리보기 (및 알고리즘과 같은 다른 환경)를 거의 볼 수 없습니다.

코드에서 출력으로의 매핑은 일반적으로 다른 프로그램보다 훨씬 간단 하기 때문에 LaTeX에 적합 합니다. 좀 더 일반적인 언어에 대해서는 전혀 마음에 들지 않습니다.

이맥스이 할 수있는 또 다른 것은 같은 기호를 대체 할 것입니다 ->와 forall와 →와 ∀각각 하스켈을. Haskell에서 전혀 필요하지 않다는 점을 제외하고는 이러한 종류의 작업을 제안하는 것처럼 확장 할 수없는 이유는 거의 없습니다.

얼마 전에 프로그래머가 입력 한 코드의 형식을 원하는지 묻는 코드 형식에 대해이 질문을 했습니다.

내 질문은 형식화의 들여 쓰기 측면 만 다루었지만 일부 답변은 일반적으로 코드 형식화에 적용될 수 있습니다. 답변에 대한 전반적인 감정은 프로그래머가 코드가 표현되는 방식을 절대적으로 통제하지 못하는 것에 반대합니다.

내 개인적인 경험은 상당히 달랐습니다. 일반적으로 공개적으로 사용 가능한 도구를 사용하기도하지만 때로는 자체 맞춤형 편집기에서 XSLT를 작성해야합니다. 이 편집기는 왼쪽 여백을 들여 써서 입력 할 때 코드 형식을 지정하므로 원치 않는 공백 (XSLT에서는 중요)에 문제가 없으며 코드를 자동 줄 바꿈하면서도 형식을 유지할 수 있습니다. 필자는 경험이 상당히 자연스럽고 형식 지정 스타일이 줄 바꿈의 컨텍스트와 위치에 의해 제어된다는 것을 알게되었습니다 (터치 감지 입력 장치를 사용할 때 특히 경험이 좋습니다).

XSLT의 균형이 맞지 않으면 실제로 서식이 문제의 위치를 ​​표시하는 데 도움이됩니다. 입력 할 때 가로로 코드 이동을 조정하는 데 시간이 걸렸지 만 더 이상 방해가되지 않습니다. 그러나 XSLT의 세로 간격에 영향을 미치는 서식 기능이 편집기를 거의 사용할 수 없게 만들었으므로 이러한 기능을 비활성화했습니다.

귀하의 질문으로 돌아가려면 풍부한 코드 형식이 더 일반적이지 않은 이유는 프로그래밍 세계에서 인식이 변경되는 데 시간이 오래 걸리기 때문이라고 생각합니다. 키보드없이 코드를 편집하는 시간과 일치 할 가능성이 있습니다.

또한 몇 개 이상의 언어 (Haskell, Ruby, Python, Erlang, CoffeeScript 등)에서 들여 쓰기가 중요합니다. 따라서 글꼴 크기를 변경하면 파악하기가 매우 어려울 수 있습니다.

주로 전통. 나는 거의 20 년 동안 전문적으로 프로그래밍을 해왔고 그것이 나에게 불쾌감을 줄 것으로 생각된다. 나는 교과서와 함께 Emacs 또는 VI로 책을 썼으므로 WYSIWIG 팬이 아닙니다.

Knuth의 CWEB가이를 수행하지만 C / C ++ 및 Pascal에서만 작동합니다. — 그래도 살펴 봐야합니다 ... 매우 깔끔합니다. : 두 가지 프로그램입니다 ctangle및 cweave각각 텍 C에 별도의 CWEB 파일은 / 결합한다.

이전에 이와 같이 풍부한 형식의 코드를 보았거나 아이디어가 고려되어 결국 거부되었는지 알고 있습니까?

확실한. Xcode는 다양한 구문에 대해 간단한 색상 이외의 스타일을 지원합니다.

내가 사용한지 오래되었지만 Metrowerks CodeWarrior는 스타일이 적용된 텍스트도 지원했으며 10 년 이상 전에 그랬습니다.

그러나 스타일이 너무 다양 할 때 텍스트, 소스 코드 등을 읽기 어려울 수 있습니다. 특히, 혼합 크기는 산만하고 열이 정렬되지 않는 것은 성가신 것으로 생각합니다. 대부분의 프로그래머가 여전히 고정 폭 글꼴을 사용하는 이유가 있습니다.

다른 질문은 스타일 텍스트를 언어 구문 자체의 일부로 사용해야하는지 여부입니다. 예를 들어, 컴파일러는 텍스트가 함수 선언인지 확인하기 위해 특정 텍스트에 특정 방식으로 스타일이 지정되어 있다는 사실을 사용해야합니까? 처음에는 미치게 들릴지 모르지만 Python 및 Fortran과 같은 언어는 이미 들여 쓰기를 구문으로 사용합니다. 그럼에도 불구하고, 우리는 스타일을 다른 방식으로 보지 않고 구문에 의해 계속해서 볼 가능성이 높다고 생각합니다. 일반 텍스트 (단순한 컴파일러, 플랫폼 독립성, 프로그래머 기본 설정)를 사용할 수 있다는 이점이 있으며, 다른 전통은 스타일 (들여 쓰기, 빈 줄, 마커 문자 및 코드 접기 및 탐색 메뉴와 같은 편집기 기능).

소스 코드의 서식은 구조와 의미가 훨씬 더 중요하고 타이핑하기 쉬운 정보 입력을 목적으로하기 때문에 널리 사용되지 않는다고 생각합니다. 글꼴 화, 추가 특수 기호 및 공백은 불필요한 시각적 노이즈를 추가합니다. 그래도 생성 된 문서에 적합 할 수 있습니다.

MS Word와 같은 WYSIWYG 편집기와 TeX (LaTeX)와 같은 시스템을 선호하는 사람들 사이에서 조판 세계에서 동일한 주제에 대해 화염 전쟁이 끝나지 않습니다.

일반적으로 명확한 답은 없습니다. 그것은 모두 도구, 사용 사례 및 개인 취향에 달려 있습니다.

Doxygen 또는 JavaDoc과 같은 도구는 이미 서식있는 텍스트 코드 형식을 수행합니다. 브라우징 목적으로 코드 하이퍼 텍스트를 추가합니다. 기본 서식을 지정하기 위해 특수 태그를 삽입 할 필요는 없습니다.

그러나 이것은 WYSIWYG가 아닙니다.

이것이 존재한다고 말하는 것이 두렵습니다.

과거에는 Centura (Gupta 또는 SQL / Windows라고도 함) (이전의 " 4GL ") 코드에서 작업했습니다. 메모장과 같은 표준 편집기에서 Centura 코드를 필요한 수준의 서식으로 편집하는 것은 실제로 불가능했습니다.

소스 파일을 이와 같은 형식으로 만드는 것이 좋은 생각 인 것 같지만 개발이 상당히 제한적이고 고통 스러웠습니다.

또한 소스 제어에서 병합 할 때 형식화로 인해 종종 문제가 발생했습니다.

다른 답변 외에도 풍부한 서식을 사용하는 기술적 인 어려움 외에도 개인적인 취향의 대상이라는 점을 지적하고 싶습니다.

일반 텍스트를 편집하면 원하는 글꼴과 색상을 선택할 수 있으며 자동으로 설정됩니다. 서식있는 텍스트를 편집하는 경우 수동으로 설정 한 특정 색상 및 글꼴이 마음에 들지 않으면 어떻게합니까?

아무도 아직 코드 읽기와 코드 쓰기를 분리하지 않았기 때문이라고 생각합니다. 최소한 주류가되지는 않습니다. 때로는 오래 전에 만졌던 코드 나 다른 개발자가 만든 코드를 읽어야 할 때가 있습니다. 이 소스에서 단일 바이트를 변경할 준비가 될 때까지 많은 시간을 소비해야 할 것입니다. 이것은 쉽게 이해하기 위해 필요한 모든 것을 할 수있는 "읽기"모드 일 수 있습니다 (글꼴 크기, 형식 재 지정, 하위 스크립트, 수퍼 스크립트 등). 준비가되면 편집기는 "쓰기"모드로 전환 할 수 있고 덜 제한적이며 "최소한의 놀람 규칙"을 준수 할 수 있습니다