2010-04-26 3 views
15

소스 코드 내의 ASCII 다이어그램 작성에 걸리는 시간은 얼마입니까?내 시간 가치가있는 ASCII 다이어그램이 있습니까?

훨씬 빠르게 비트 맵 다이어그램을 만들 수 있지만 이미지가 원본 파일 (until VS2010)에서 줄 서기가 훨씬 어렵습니다.

기록을 위해, 나는 decorative ASCII art에 대해서 이야기하지 않고있다.

다음은 MS Paint에서 절반 만에 작성한 코드에 대해 최근에 만든 다이어그램의 예제입니다.

  Scenario A: 

          v 
(U)____________(N)_______<--(P)     Legend: 
      ' /   |     J = ... 
      ' /   |     P = ... 
      ' /d    |     U = ... 
      '/    |     v = ... 
      '/    |     d = ... 
      '/     |     N = ... 
     (J)     | 
      |     | 
      |___________________| 
+4

개인적으로, 나는 별도의 Word (또는 무엇이든) 문서를 갖고 싶습니다. –

+1

+1 Neil, 물건을 뽑은 다음 별도의 파일에 넣어 두는 것이 좋습니다. 특히 코드만으로는보기 힘든 다이어그램/uml 등의 모듈 종속성에 대한 전체적인 그림을 제공 할 수 있다면 더욱 그렇습니다. –

+3

죄송합니다. 그러나 Word 문서를 열거 나 여기에 등록하는 것은 너무 느립니다. 주제가 광범위 할 때 좋습니다. 때로는 누군가가 RichC++, RichJava 등을 유용한 방식으로 구현하지 않는 한,이 작은 ASCII 드로잉이 가장 좋습니다. – MaR

답변

8

코드에서 Doxygen과 같은 문서를 생성하는 도구를 사용하는 경우 이미지 파일을 직접 참조하여 생성 된 문서에 표시하는 방법이 있어야합니다. Doxygen의 경우 관련 명령은 \image입니다. 이는 실제 이미지 다이어그램을 소스에서 쉽게 참조 할 수있는 이점 (Word와 같은 무거운 프로그램을 시작할 필요가 없음)과 자동 생성 문서와 결합됩니다.

6

설명을 이해할 필요가없는 설명 변수 및 함수 이름으로 명확하고 간결한 코드를 작성하는 것이 더 나을 것입니다. 주석이나 디자인 문서는 컴파일되지 않습니다. 결과적으로 코드와의 동기화가 빠져 나와 오도 된 내용이됩니다.

+6

그러나 그래픽 및 기하학적 알고리즘을 사용하면 그림에 실제로 천 단어 (또는 코드 줄) 이상이 표시됩니다. – Thomas

+2

단어를 사용하여 명확하게 표현하는 것이 어렵습니다. 예를 들어, 사소한 알고리즘과 그래픽 루틴은 종종 그래픽으로 더 잘 설명됩니다. – Kramii

+2

실제 생산 코드에서는 실제로는 거의 없습니다. 일반적으로 코드를 다루는 사람들은 문제 영역을 잘 알고있을 것으로 예상됩니다. 문제 영역을 가르치는 것은 의견이나 설계 문서의 책임이 아닙니다. 예를 들어, 2D 그래픽 변환이 작동하는 방식을 이해하기 위해 면책 라이브러리의 2D 그래픽 변환을 처리하는 코드의 독자를 기대합니다. 내 코드 또는 디자인의 일부로 설명하는 문서를 작성하지 않을 것입니다. –

1

다음을 시도해보십시오. 이들을 동적으로 묶는 멋진 라이브러리. http://code.google.com/p/clojure-textflow/

+0

소스 코드에 포함시키고 자하는 다이어그램의 일부분 만 다루고 있습니다. –

+4

다른 도구가 있습니다. http://www.jave.de/ – Kramii

+0

@Kramii, 매우 멋진 앱. 팁 –

1

그런 다음 MS 그림판 (또는 기타)을 사용하고 소스 컨트롤에 다이어그램을 포함시킵니다.

1

디자인 문서는 디자인 문서에 속합니다. 왜 그림, 매뉴얼, 소스, 예제 데이터 파일, 테스트 케이스, 희망 목록, 변경 로그 등을위한 하위 폴더가있는 프로젝트 폴더가 없습니까? 각 문서 유형마다 별도의 디렉토리가 필요하다고 말하지는 않지만 논리적으로 구성되어야합니다. .

외부 파일을 여는 시간은 ASCII 아트를 만들 때 낭비되는 시간과 다른 사람이 다른 편집기 나 글꼴을 사용할 때 얼마나 빨리 떨어지는 지 문제가되지 않습니다.

1

청중을 알 수 있습니다. 잠재 고객 (앞으로 다른 개발자)이 처분 할 수있는 도구로 간단하고 쉽게 비트 맵에 액세스 할 수 있습니까? 다이어그램이 유용합니까/도움이됩니까?

코드 주석의 ASCII 다이어그램은 거의 항상 쉽게 볼 수 있습니다. (예, 확장 ASCII 문자가 사용되거나 개발자가 고정 폭 글꼴을 사용하는 경우 몇 가지 문제가있을 수 있습니다.)

+2

을 주셔서 고맙습니다. 고정 폰트로 코딩한다면 이상하게도 이상하게 보일 것입니다. P –

+0

@ Lo'oris, 나는 동의해야 할 것입니다. 그러나 고정 너비 글꼴로 코드를 보는 것이 일반적 일 수 있습니다. ClearCase의 비교 도구 버전은 기본적으로 고정되지 않은 글꼴을 사용합니다. 이것은 모든 것을 죄악으로 추악하게 만듭니다. –

0

나는 대부분의 다른 포스터에 동의합니다. 코드가 아니며 댓글은 너무 길지는 않지만) 위키 또는 문서가 있어야합니다.

나는 과거에 겪었던 여러 사고로 인해 Word를 피하고 싶지만 개인적인 취향 일 수 있습니다. 한 가지 더 : 물건의 이름을 잘 지정하고 코드와 문서 간의 링크로 사용하십시오. 예를 들어 보여준 것과 같은 시나리오를 다루는 클래스 (또는 루틴 또는 모듈)가 있다면 SquareBisector 또는 이와 비슷한 이름으로 호출하고 해당 메소드를 시나리오 A (Point a, Point b), 시나리오 B (포인트 a, 라인 l1) 등을 작성한 다음 일관된 용어를 사용하여 문서에 많은 다이어그램과 함께 더 높은 수준의 용어로 설명하는 문서를 작성하십시오.

문서의 시나리오 A ""코드와의 bisectWithTwoPoints (포인트 firstPoint, 포인트 secondPoint) "당신의 방법 ...

6

당신이 거기에 다양한 ASCII 아트 컨버터로 봤어를 호출하지 마십시오? 그렇게하면 페인트 나 다른 것으로 빨리 그려 질 수 있으며 ASCII 아트를 내보낼 수 있습니다.

1

VS2010을 사용하고 embed actual images만을 소스 파일에 포함시킬 수 있습니다.

+0

예 그 awesomeness 잘 알고 있어요. 슬프게도 이것은 현재 우리에게는 선택 사항이 아니지만 우리는 그것을 향해 노력하고 있습니다. –

2

때때로 ASCII 다이어그램은 천 단어의 가치가 있습니다. 그러나 그렇게 자주는 아닙니다. 모든 소스 파일을 검색하지는 않겠지 만, 20,000 줄의 코드 당 하나의 다이어그램이 옳을 수도 있습니다 (또는 적어도 두 가지 요소 이상으로는 벗어나지 않을 수도 있음).

코드를 한 곳에 넣고 다른 다이어그램에 넣으라고 제안하는 사람은 을 두 개씩 일치시키지 말고입니다. 잘못된 Word 문서보다 다이어그램이나 잘못된 ASCII 다이어그램을 사용하는 것이 좋습니다.

4

http://www.asciiflow.com을 사용하면 매우 간단한 클래스/플로우 다이어그램 등을 그릴 수 있습니다. 자바 스크립트를 사용하여 전적으로 웹 기반입니다. Chrome/Firefox 권장.

0

Python Wiki에 ASCII 다이어그램을 그리기위한 링크 목록과 작은 자습서가 있습니다. 텍스트를 읽는 데 시간을 절약 해주는 모든 그림은 확실히 가치가 있습니다.