[Info]Tags categorized posts and contents patterns..

[AJAX] Ajax Code E xamples.. [Book] About the book.. [CSS] CSS Code E xamples.. [DB] Sql Code E xamples.. [DEV] All development stor...

2017년 1월 20일 금요일

[JS] JSHint의 옵션 정리..


출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

JSHint는 자바스크립트 코드 검사도구이다. 컴파일언어가 아니다 보니 오류를 줄이거나 스타일 가이드를 위해서 이런 도구를 보통 사용하는데 이런 작업을 보통 Linting이라고 한다. 과거에는 더글라스 크록포드가 만든 JSLint를 대부분 쓰고 있었지만 JSLint가 현실에 맞지 않게 너무 엄격해서 JSHint가 등장하고 다른 Linting도구들이 많이 있지만, 일반적으로 JSHint를 가장 많이 쓰는 걸로 보인다.

자바스크립트를 사용할 때 거의 JSHint로 코드검사를 하고 있지만, 막상 필요할 때 그때그때 찾아서 해 버릇해서 딱 정해진 옵션을 가지고 있지도 않았고 잘 모르는 옵션이나 사용하는 옵션이더라도 어떤 내용을 검사해주는지 헷갈리는 경우가 많았다. 이는 이전의 JSHint의 문서화가 그렇게 좋지 못했던 이유도 있었는데 지금은 문서화도 어느 정도 되어 있고 매번 쓰다 보니 한번 정리해야 할 필요가 있다고 생각되어 옵션들을 정리해봤다. 간단히 어떤 옵션인지 내가 알아볼 수 있는 수준으로만 정리했으니 자세한 내용은 JSHint 문서를 참고하면 되고 좀 더 자세한 예제코드는 JSHint의 테스트코드에서 볼 수 있다.

금지(Enforcing) 옵션

아래의 옵션을 true나 특정 값으로 설정하면 JSHint가 해당 내용을 검사해서 더 많은 오류를 알려준다. (옵션을 지정하지 않으면 false로 설정한 것과 같다.)
  • bitwise: ^(XOR), | 같은 bit연산자를 금지한다.
  • camelcase: 변수를 카멜케이스(혹은 UPPER_CASE)로 강제한다(이름은 카멜케이스이지만 var testvar Test모두 가능하다.)
  • curly: if 문이나 while 문 등 중괄호({})를 생략해도 되는 곳에서 중괄호를 강제한다.
  • eqeqeq: 비교문에서 == != 대신 === !== 를 사용하도록 강제한다.
  • es3: 구형브라우저를 위해서 es3 명세를 사용한 경우에 필요하다.
  • forin: for-in 루프를 사용할 때 반드시 필터링을 사용하도록 강제한다. for (var key in obj) 식의 루프에서 프로토타입 체인을 사용한 키를 다 순회하므로 일반적으로 if (obj.hasOwnProperty(key)) {} 같은 조건문을 두는데 이러한 필터링이 없을 경우(꼭 hasOwnProperty여야 하는 건 아니다.) 오류가 나오도록 한다. (루프문안에 다른 실행문이 없으면 무시한다.)
  • freeze: Array, Date, String 같은 네이티브 객체의 프로토타입을 덮어쓸 수 없도록 막는다. Array.prototype.count = function() { }; 와 같이 사용하는 경우 오류 메시지가 나온다.
  • immed: var a = function() {}(); 와 같이 함수를 바로 실행하는 경우 함수를 괄호로 감싸도록 강제한다. 이는 가독성을 높이기 위함이다.
  • indent: 들여쓰기 크기를 정하고 숫자로 지정한다.
  • latedef: 변수를 사용하는 하는 부분 뒤에 정의하는 것을 금지한다. 자바스크립트는 hoisting 때문에 같은 스코프에서 나중에 선언된 변수를 앞에서 사용할 수 있는데 이 부분을 차단한다는 의미이다.
  • newcap: new로 생성자 함수를 사용할 때 대분자로 시작하도록 강제한다. new animal(); 대신 new Animal(); 와 같이 사용해야 한다.
  • noarg: 최적화가 어려워 폐기될 예정인 arguments.caller arguments.callee 의 사용을 막는다.
  • noempty: for (var i=0;i < 10;i++) { } 와 같이 for문 등에서 빈 블록을 금지한다.
  • nonew: new Animal(); 같은 생성자함수의 실행결과를 다른 변수 등에 할당하지 않고는 사용할 수 없게 한다.
  • plusplus: ++, -- 같은 단항연산자를 금지한다.
  • quotmark: 문자열 등에 사용하는 따옴표의 스타일을 강제한다. true 로 지정하면 쌍따옴표, 홑따옴표를 모두 쓸 수 있지만 섞어서 사용할 경우 오류가 나고 single 은 홑따옴표 double 는 쌍따옴표를 강제한다.
  • undef: 선언되지 않은 변수를 사용하면 오류가 발생한다.
  • unused: 변수를 선언하고 사용하지 않으면 오류가 발생한다.
  • strict: 함수에 ECMAScript 5의 strict mode를 강제한다. 이 옵션은 함수범위에만 강제하고 전역 strict mode는 허용하지 않는다.
  • trailing: 라인 끝에 불필요한 공백문자가 들어가면 오류가 발생한다.
  • maxparams: 값을 숫자로 지정하고 함수에서 파라미터의 최대 개수를 지정한다.
  • maxdepth: 제어문의 최대 중첩개수를 지정한다.
  • maxstatements: 한 함수내의 사용할 수 있는 최대 스테이트먼트 개수를 지정한다.
  • maxcomplexity: 코드의 사이클매틱 복잡도(cyclomatic complexity)를 지정한다.
  • maxlen: 한 라인의 최대 길이를 지정한다.

완화(Relaxing) 옵션

아래 옵션을 true 로 설정하면 더 적은 오류를 보여준다.
  • asi: 세미콜론이 빠졌을 때 발생하는 오류를 보여주지 않는다.
  • boss: if (a = 1) 처럼 비교문이 와야 할 곳에 할당문이 올 때 발생하는 오류를 보여주지 않는다.
  • debug: debugger; 문을 코드에 사용했을 때 발생하는 오류를 보여주지 않는다.
  • eqnull: == null 비교에 대한 오류를 보여주지 않는다.
  • esnext: ECMAScript 6 문법을 사용을 허용한다.
  • evil: eval 을 사용했을 때 발생하는 오류를 보여주지 않는다.
  • expr: 함수 호출이나 할당문이 아닌 표현식에 대한 오류를 보여주지 않는다. 주로 테스트에서 true.should.be.ok; 같은 표현식을 사용할 때 필요하다.
  • funcscope: if (true) { var a = 1; } 처럼 제어문 내에서 변수를 정의하는 경우 발생하는 오류를 보여주지 않는다. 자바스크립트는 펑션스코프를 사용하므로 동작에는 이상이 없지만, 오류를 발생할 여지가 있으므로 이 방법을 권장하지 않는다.
  • globalstrict: ECMAScript 5의 strict mode를 전역으로 사용하는 것을 허용한다.
  • iterator: __iterator__ 프로퍼티 사용에 대한 오류를 보여주지 않는다.
  • lastsemic: 한 줄짜리 블록에서 마지막 세미콜론이 빠진 경우에만 오류를 보여주고 블록 내부 등에서 세미콜론을 사용하지 않은 경우에는 오류를 보여주지 않는다.
  • laxbreak: 코드에서 안전하지 않은 줄 바꿈에 대한 오류를 보여주지 않는다. 이 오류는 콤마를 앞에 쓰는 형식에 대한 오류도 보여주지 않는데 이 경우에는 laxcomma를 사용해야 한다.
  • laxcomma: 객체 리터럴등에서 콤마를 앞에(마지막이 아니라) 쓰는 형식을 허용한다.
  • loopfunc: 루프 안에서 함수를 정의하는 경우 발생하는 오류를 보여주지 않는다.
  • moz: 모질라의 자바스크립트 확장 문법(JavaScript 1.7)을 사용하도록 허용한다.
  • multistr: \를 사용해서 문자열을 여러 라인에 걸쳐서 사용하는 경우 발생하는 오류를 보여주지 않는다.
  • notypeof: typeof 의 값을 비교할 때 typeof 의 값이 아닌 값과 비교하는 경우 발생하는 오류를 보여주지 않는다.
  • proto: __proto__ 프로퍼티 사용에 대한 오류를 보여주지 않는다.
  • scripturl: <a href="javascript:"> 처럼 스크립트를 타켓으로 한 URL(javascript:)에 대한 오류를 보여주지 않는다.
  • smarttabs: 탭과 스페이스를 섞어서 사용하는 경우 발생하는 오류를 보여주지 않는다.
  • shadow: 이미 선언된 변수를 재선언해서 발생하는 variable shadowing에 대한 오류를 보여주지 않는다.
  • sub: obj['key'] 대신 .을 사용하는 표기법을 권장하는 오류를 보여주지 않는다.
  • supernew: new function () {} new Object; 처럼 잘못 작성했을 가능성이 있는 생성자에 대한 오류를 보여주지 않는다.
  • validthis: strict 모드로 동작할 때 생성자가 아닌 함수에서 this를 사용하는 것에 대한 오류를 보여주지 않는다.

환경

아래 옵션을 JSHint가 전역 변수들을 미리 정의하도록 한다.
  • browser: 최신 브라우저들의 document, navigator 같은 전역 변수를 정의한다. 이 옵션은 console, alert 은 노출하지 않는다.
  • couch: CouchDB의 전역변수를 정의한다.
  • devel: console, alert 등 개발용으로 사용하는 전역 변수/객체를 정의한다.
  • dojo: Dojo의 전역변수를 정의한다.
  • jquery: jQuery의 전역변수를 정의한다.
  • mootools: MooTools의 전역변수를 정의한다.
  • node: Node.js환경에 맞도록 브라우저 환경에만 어울리는 오류는 무시하고 Node.js에 맞는 전역변수를 정의한다.
  • nonstandard: escapeunescape처럼 표준은 아니지만, 범용적으로 쓰이는 전역변수를 정의한다.
  • phantom: PhantomJS에서 동작하는 환경에 맞는 전역변수를 정의한다.
  • prototypejs: Prototype의 전역변수를 정의한다.
  • rhino: Rhino 환경에 맞는 전역변수를 정의한다.
  • worker: Web Worker 환경에 맞는 전역변수를 정의한다.
  • wsh: Windows ScriptHost 환경에 맞는 전역변수를 정의한다.
  • yui: YUI의 전역변수를 정의한다.

레거시 옵션

아래 옵션들은 폐기되어서 앞으로는 제거될 예정이다. 사용하지 마라.
  • nomen: 변수의 앞이나 뒤에 언더스코어(_)를 사용한 경우 오류가 발생한다.
  • onevar: 함수 안에 var 선언을 하나만 해야 한다.
  • passfail: 이 옵션을 사용하면 첫 오류나 경고에서 멈춘다.
  • white: JSHint가 더글라스 크록포드(Douglas Crockford)의 코딩 스타일가이드에 따라 코드를 검사하도록 한다.

My Comment..
음.. 노상 JS 를 쓰면서도 실질적으로 이런 코드 검사를 해주는 도구가 있는줄은 몰랐다.. 끽해야 F12 를 통한 브라우저 자체제공 도구를 사용하는정도가 다였는데 말이지..

역시 햄 블로그를 찬찬히 보다보면 새로운 것들을 많이 알게 되는 것 같다.. 나 스스로도 정리하고 새로운것을 알아보고 해야되는데.. 아흠.. 그것까진 솔직히 잘 안된다.. ㅎㅎㅎ..

[UFC] UFC 마감뉴스..


출처 : SPOTV NEWS























[Book] 심플은 정답이 아니다..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

심플은 정답이 아니다 - 6점
도널드 노먼 지음
이지현 외 옮김
교보문고

인지과학의 대부인 도널드 노먼 교수의 책으로 난 UX에도 관심있고 디자인에도 관심(관심만..)은 있지만 UI나 UX를 설계하는 업무가 주업은 아니기 때문에 이쪽에 대한 사전지식이 깊지 않은 가운데 읽었기 때문에 읽고 받아들이는 수준도 그리 높지는 않았다.(이쪽도 점점 관심을 더 깊게 가져야 해서...) 디자인(웹에 대한 얘기도 나오지만 전체적으로는 모든 분야를 다루고 있다.)에서 단순함을 추구하는 경향가운데 단순함과 복잡함을 어떻게 봐야하는지를 자세히 설명하고 있다. 웹사이트들에 대한 얘기도 좀 나오긴 하지만 전체적으로는 길이나 건물, 길거리등 다양한 사례를 들면서 설명하고 있어서 이해하기가 어렵지는 않고 설명이 좋아서인지 너무 당연하게 느껴질 정도이다.(평소에는 이렇게 생각하기 어렵겠지만.) 이 책을 읽으면서 왠지 Martin Odersky의 Simple or Complicated?이라는 글이 생각났다.

우리가 사용하는 제품들이 복잡하므로 "단순하게 만들어라"라는 해결책이 그럴듯해 보이지만 실제 단순한 제품에 대해서 사람들은 "핵심" 기능이 없다고 불평한다는 것이다. 여기서 사람들이 생각하는 단순함이란 좋아하는 모든 기능이 들어있으면서 버튼 하나로 조작할 수 있는 단순함을 의미하는데 이는 불가능하다고 보는 것이 맞다다. 사람들이 향샹된 기량과 쉬운 사용을 원한다고 이를 더 많은 기능, 단순한 디자인으로 생각해서는 안되고 사람들이 정말 원하는 것은 이해하기 쉬운 제품이다. 그래서 인간 중심 디자인의 핵심은 복잡한 도구를 최적화하고 이해가 쉽고 즐거운 제품으로 바꾸어 복잡함을 길들이는 것이다.

사람들은 단순함을 원하지만 많은 멋진 기능을 포기하고 싶어하지도 않는다. 그래서 너무 단순하면 금세 지루해지고 너무 복잡하면 혼란스러우므로 결국 사람들은 중간 수준의 적절한 복잡함을 원하게 된다. 단순함은 복잡함의 반대가 아니다. 복잡함은 세상의 모습이고, 단순함은 마음의 상태다. 그래서 기술을 길들이는 것은 물리적인 문제가 아니라 심리적인 문제이다.

아무리 똑똑하고 의도가 좋더라도 엔지니어와 프로그래머는 기계의 관점에서 바라볼 수밖에 없고 평범한 사용자들이 아니다. 엔지니어들이 기계에 더 높은 지능을 주려고 노력하고 있지만 지금 상황에서 신경써야 할 것은 지능이 아니라 매너이고 이 책임은 디자이너에게 있다. 그래서 당황스런 사용자 행동에 대해서 짜증을 내기 보다는 이런 반응을 유도한 자신의 사회성을 반성해야 한다. 인간중심 디자인과 사회적 디자인에는 그 사물을 이용하는 사람이 진정으로 필요로 하고 원하는 것을 고려해 그들에게 도움을 줘야 한다는 철학이 깔려 있다. 한때는 "디자인"이 외관을 가리키던 적이 있었지만 지금은 좋은 상호작용이 좋은 디자인의 중요한 요소중 하나가 되었다. 그래서 내가 가진 디자인 원칙 중 하나는 오류 메시지를 없애서 오류가 아니라 도움이 필요한 상황으로 간주하고 스스로 설명할 수 있게 하는 것이다.

복잡함을 단순하게 만드는 가장 좋은 방법은 핵심 문제에 대한 개념을 새로 세우는 것이다. 디자인적 사고란 가장 먼저 진짜 문제가 무엇인지를 규정하는 것이다. 나는 이를 두고 "클라이언트가 해결해 달라고 하는 문제는 절대로 해결하지 마라"고 바꾸어 말한다. 클라이언트는 증상에만 반응하기 때문이다. 모든 과정에서 가장 어려운 일이기도 하면서 디자이너가 가장 먼저 해야 할 일은 정말로 해결되어야 하는 문제가 무엇인지를 찾는 것이다.