개발자들이 개발하면서 제일 싫어하는 것 중 하나가 바로 문서작업입니다.

그래서 문서작업을 따로 하지 않아도 되도록 Java 개발자들을 위한 JavaDoc 이라는게 있죠. JavaDoc 은 대충 다음의 형식을 따릅니다.

[code]
/**
* Sorts some Array
*
* @param arr the Array
* @exception SortArgumentException if arr is  null
*/
public void sort(Array arr) {
.....
}
[/code]

위와 같이 메소드를 정의하면서 특정 형식에 맞추어 주석을 표기하면 javadoc 이라는 실행파일이 알아서 문서로 만들어줍니다. 소스코드의 가독성도 늘리고, 문서작업도 한꺼번에 되고, 메소드나 함수의 내용을 기억하기도 쉬우니까 1석 3조가 되는거죠.JavaScript 쪽에도 비슷한 것으로 ScriptDoc 이라는게 있습니다. 공식 사이트는 http://www.scriptdoc.org/ 입니다.

스크립트 파일의 헤더쪽에 포함되는 내용은 @version, @author, @projectDescription, @sdoc, @namespace 등이 있으며 다음과 같이 사용합니다.

[code]
/**
* @projectDescription  Joe Smith’s wonderful  JavaScript library.
*
* @author Joe Smith jsmith@company.com
*  @version 1.1
* @sdoc scripts/snazzyLib/ajax.sdoc
*/
[/code]

@sdoc 은 현재의 자바스크립트 파일과 연결된 외부 scriptDoc 파일을 가리키며 절대/상대 경로가 모두 가능합니다.

클래스를 정의할 때에는 @classDescription, @memberOf, @constructor, @type, @method 등을 이용합니다.

@membefOf 는 어떤 함수가 특정 클래스의 멤버 임을 가리킵니다. javascript 의 특성상 외부에 함수를 지정하고 이를 클래스의 메소드로 링크할 수도 있기 때문에 이런 식의 표기가 생긴 것 같습니다.

@constructor 는 클래스의 생성자를 표시하고,
@type 은 프로퍼티의 객체 타입을 가리키며,
@exception 은 메소드에서 반환 가능한 예외를 표기합니다.
@method 는 함수가 어떤 클래스의 메소드인지 아닌지를 알려줍니다. 중괄호 안은 exception의 타입을 나타냅니다.

[code]
/**
* @memberOf fooBar
* @method
*/
function foo() {
...
}
[/code]

함수나 메소드를 정의할 때는 위에서 가리킨 몇가지 외에도 @alias, @deprecated, @exception, @param, @return, @since 등이 가능합니다.

@alias 는 외부 scriptdoc 문서에서의 별명 링크를 지정합니다.
@param 은 함수의 파라미터로 사용되는 파라미터의 타입과 설명을 표기하고,
@deprecated 는 말 그대로 과거에는 구현되었으나 지금은 지원하지 않는(혹은 삭제예정인) 프로퍼티 혹은 메소드/함수를 가리킵니다.
@exception 은 메소드/함수에서 일어날 수 있는 예외를,
@return 은 반환값을 가리키며,
@since 는 이 프로퍼티/속성/메소드가 지원되기 시작한 버전을 표기합니다.

[code]
/**
* Sum two numbers
*
* @param {Number} Num1 integer to sum (first)
* @param {Number} Num2 integer to sum  (second)
* @return {Number} Returns an result number
* @exception {ArgumentException} Throws a exception if  number of argument is not two.
* @since 0.4
*/
function sum(Num1, Num2) {
      return Num1 + Num2;
}
[/code]

언어 자체가 자바보다는 단순한 만큼 항목이 많지 않아서 금방 적용해볼 수 있으며, 표준의 방식을 따름으로서 얻어지는 이점이라면(그렇다고 표준기구에서 제정된 것은 아닙니다), 관련된 IDE 나 프로그램 등에서 이를 이용한 지원을 받기가 더 용이하다는 점과 상호 규약을 지킴으로써 작업자간의 커뮤니케이션이 더 원활하다는 점이 있습니다.

아직 scriptDoc 을 문서로 만들어주는 도구는 없지만 조만간 나올 것이라고 봅니다. ^^ 이미 Aptana 같은 IDE 에서도 지원하기 시작했구요. 지금부터 써보는 습관을 들여도 좋을 것 같습니다.

출처 : 행복한고니

IE Blog에 게시된 내용입니다. 원문은 이 글 마지막에 링크해두었으니 직접 살펴보세요. 이 글에선 간단히 요약만 합니다.

1. 변수는 로컬에 명시적으로 정의한다.
함수내에서 사용되는 지역 변수가 있다면 명시적으로 var 표시를 해주도록 합니다. 그렇지 않을 경우 브라우저는 상위 scope를 모두 뒤져서 상위에 해당 변수가 정의되어있는지 확인합니다.

2. 가능하다면 일단 캐싱한다.
DOM은 느리므로 가급적이면 DOM을 호출하는 횟수를 줄입니다. 반복적으로 document.body.all 등이 쓰여야 할 경우 document.body.all 를 다른 변수로 캐싱해둡니다. Array 등에서 array.length 같은 것을 반복문에서 사용해야 할 경우 var len = array.length 등과 같이 array.length 를 캐시해서 사용합니다. 함수 내에서 자주 사용되는 전역함수의 경우 지역 변수로 캐싱해서 사용하는 것이 좋습니다.

3. with 키워드의 사용은 피합니다.
JScript 에서의 with 키워드 사용은 scope를 하나 더 정의하는 것과 비슷한 비용이 듭니다.

4. 문자열을 많이 다루어야 할 경우에는 배열에 넣고 join 하는게 빠릅니다.
JavaScript에서는 자동으로 효율적인 코드로 변경하지만 JScript는 못합니다. 그래서 이런 식의 StringBuffer를 구현해줘야 빨라집니다.

5. eval은 무척이나 비용이 높은 명령입니다.
가급적이면 사용을 피하는게 좋습니다.

6. 가능하다면 closure를 피하세요.
closure는 매우 강력하기는 하지만 동시에 매우 위험하기도 합니다. 주의깊게 다루어야 할 뿐더러 최근에 패치가 되기 전까지 JScript는 DOM에 사용된 closure에 대해서 메모리 누수 현상이 있었습니다(패치 되지 않았거나 IE6 미만의 버전을 사용한다면 여전히 존재할 것입니다).

7. 프로퍼티 접근 함수는 사용하지 마세요.
객체지향 측면에서는 훌륭하지만 JScript로서는 끔찍합니다(헉… 이거 프레임웍에 썼는데…).

원문보기
IE + JavaScript Performance Recommendations - Part 1
IE+JavaScript Performance Recommendations Part 2: JavaScript Code Inefficiencies
IE+JScript Performance Recommendations Part 3: JavaScript Code Inefficiencies