문제

Framemaker에서 다양한 프로그래밍 소스 코드를 설명하는 기술 문서를 작성해야합니다.

따라서 내 문서는 많은 텍스트로 구성되며, 소스 코드 (Java, XML)가 뒤 따른 다음 더 많은 텍스트 등이 있습니다.

이 질문은 내가 Framemaker를 사용해야하는지 또는 사용해서는 안되는 지에 관한 것이 아닙니다. 이것이 제가 사용해야하는 소프트웨어입니다. . .

내가 혼란스러워하는 것은 내 문서의 일부로 소스 코드를 포맷하는 방법입니다. 기술 문서를 위해이 작업을 수행하고 지침이나 팁을 발견 한 사람이 있습니까? 지금까지 내 인터넷 검색은 내가해야 할 일과 관련된 어떤 것도 생산되지 않았습니다.

도움이 되었습니까?

해결책

최소한 코드 샘플을위한 단락 스타일을 만들고, 좋은 모노 스케이스 글꼴을 사용하고, 하이픈을 끄는 것을 잊지 마십시오.

내가 이것을 할 때, 나는 테이블 스타일을 만들고 거기에 코드를 붙여 넣었으므로 그 위에 멋진 제목 헤더가 있었고, 약간 눈에 띄었습니다. 유일하게 Gotcha는 프레임 테이블 셀이 페이지 브레이크를 가로 질러 파손되지 않으므로 코드가 페이지보다 길거나 페이지 하단 아래로 이동하겠다고 위협하는 경우 테이블에서 여러 행을 생성해야합니다. 행에서 코드를 분해하십시오.

다른 팁

몇 년 전에 다음 주에 다시 온라인으로 제공 될 논문에서 다음 주에 다시 구입할 수 있습니다.

타이포 그래퍼는 주로 가독성에 관심이 있으며, 자연 언어로 텍스트를 설정할 때 의지 할 수있는 수백 년과 실제로 수천 년 전으로 거슬러 올라가는 도구, 관행 및 전통이 있습니다. 그러나 컴퓨터 프로그램은 자연어로 작성되지 않습니다. 그것들은 '프로그래밍 언어'로 작성됩니다. 인공 언어는 자체 구문 규칙, 프레젠테이션 규칙 및 자신의 가독성 기준을 갖는 인공 언어로 작성됩니다. 따라서 컴퓨터 코드는 음악, 수학 및 화학과 마찬가지로 조판을위한 특별한 영역입니다. 이 도메인에는 자체 규칙이 있으며,이 규칙은 자연어를 설정할 때 사용되는 규칙이 아닙니다.

컴퓨터 프로그래밍 자체는 최근에 출발했으며, 유형으로 설정하는 관행은 약 45 년 이상 되돌아 가지 않습니다. 지난 20 년 이하의 상당한 양의 컴퓨터 코드가 게시되었습니다. 관련된 인쇄상의 징계는 미숙하거나 실제로 존재하지 않으며, 많은 무역 서적을 검사함으로써 볼 수 있듯이 현장에서 실무자들의 인쇄상의 기대도 낮습니다. 더 잘하려고 할 이유가 없습니다.

  1. Sans Serif 글꼴을 사용하십시오. 내 책 중 하나에서 나는 같은 글꼴 패밀리, 텍스트에 FF Scala와 코드에 FF Scala Sans를 사용했습니다. 나는 그것이 멋지게 보이지만 반대 의견이 있다고 생각합니다. 이것은 당신이 당신이 당신이 당신이 당신이 당신이 단일 글꼴을 사용하도록 강요 할 수도 있지만, 개인적으로는 이것이 매우 구식이라고 생각합니다. 택배를 피하면 아무것도 섞이지 않습니다.

  2. 들여 쓰기는 표기법의 일부입니다. 기존의 왼쪽 계약을 존중해야합니다. 소스 코드는 이미 탭이 있습니다. 각 탭을 최대 하나 또는 두 개의 공간으로 줄이면 수평 실이 떨어집니다.

  3. 가능한 한 많은 수직 공간을 잃어 버리십시오. 예를 들어 빈 줄을 억제합니다. 전체 샘플을 한 페이지로 켜십시오. 그것을 달성하는 데 필요한 경우 떠 다니십시오.

  4. 라인 브레이크는 표기법의 일부입니다. 저자와상의하지 않고 라인 브레이크를 추가하지 마십시오.

  5. 따옴표는 표기법의 일부입니다. 싱글을 두 배나 그 반대로 변경하지 마십시오.

  6. 정당화 : 컴퓨터 프로그램은 항상 쓰고,보고, 왼쪽 정당화되고, 오른쪽에 정해집니다.

  7. 페이지 브레이크. 책에서 컴퓨터 코드를 설정할 때 Page Breaks는 자연 언어를 조립 할 때 사용되는 간단한 고아/과부 원리를 따를 수 없습니다. 대신, 가능한 경우 코드의 논리적 '블록'을 함께 유지해야합니다. 빈 줄은 일반적으로 페이지 브레이크를위한 허용 가능한 지점이지만, 타이포미 터가 코드의 블록 경계를 결정하는 것은 일반적으로 불가능합니다. '블록 댓글'은 다음 코드 블록으로 유지해야합니다. 이것이 무엇인지 모른다면 저자에게 문의하십시오.

  8. 하이픈. 프로그래밍 언어는 자연 언어가 아니며 일반적인 하이픈 규칙을 관찰하지 않습니다. hypenate가 필요한 경우 저자에게 문의하십시오. 프로그램 텍스트의 단어는 저자의 지시에 따라 하이픈을 사용하거나 줄을 끊어서는 안됩니다.

  9. 대문자와 소문자. 프로그램 코드의 사례는 일반적으로 컴퓨터에 중요하며 실제로는 항상 작가와 독자에게 중요합니다. 단어 쌍은 종종 다른 것을 나타내는 경우에만 다른 경우에만 사용됩니다. 프로그래머, 특히 저자-프로그래머는 일반적으로 타이포 그래퍼 (또는 다른 프로그래머!)에게 반드시 의미가없는 방식으로 사례에 대해 매우 체계적입니다.

실제 권장 사항

  • EM 단위로 들여 쓰기. 컴퓨터 프로그램을 조립하는 많은 문제에 대한 해결책은 EM입니다. 저자의 탭은 8 개의 공백 중 다음 배수 (1, 9, 17,…)에있을 가능성이 높습니다. 프로그램 코드의 타이포그래피 탭은 1 또는 2 EMS의 배수로 이루어져야합니다. 들여 쓰기가 스크린이나 인쇄물에서 보는 것보다 훨씬 좁을 수 있기 때문에, 들여 쓰기 단위로서 EM을 처음에는 저자에게 '재미있게 보이게'할 수 있습니다. 그러나 탭 정지의 수직 정렬이 보존되는 한 저자의 의도는 완전히 보존됩니다.
  • 라인 브레이크는 MS에 따라야합니다.
  • 페이지 브레이크 : 프로그램 코드 중간에서 페이지 브레이크가 발생할 수있는 경우 저자는 선호하는 페이지 브레이크 포인트와 상담해야합니다. 일반적으로 이것은 짧은 예에서 완전히 피해야합니다. 더 긴 프로그램에서 저자는 MS에서 가능한 모든 페이지 브레이크를 표시해야합니다.
  • 따옴표 : 기존, '직선'인용문은 타이포그래피 인용문이 아닌 사용됩니다. 이것은 역사적으로 인쇄물 인용문 (예 : Courier, Helvetica)이없는 컴퓨터 코드에서 글꼴을 사용하여 결정됩니다. 표기법의 속성에는 필요하지 않습니다. 단일 따옴표가 단일 및 이중 따옴표가 두 배로 유지되는 한 컴퓨터 프로그램을 설정할 때 타이포그래피 인용문을 사용하는 것에 대한 이유가 없습니다. 즉, 저자의 인용문이 표준 타이포그래피 실습에 '수정'하는 대신 보존되는 한.
  • 숫자 : 일반적으로 라이닝 숫자는 항상 프로그램 코드에 사용되었습니다. 프로그램 코드에서 구식 숫자를 사용하거나 글꼴이 제작 된 경우 그 이유를 알 수 없습니다. 1, i 및 l (하위 케이스 L)가 0 (0) 및 O와 같은 글꼴을 선택해야합니다.
라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top