Moonpick은 Moonscript의 대체 린터입니다. Moonscript에는 Linter가 내장되어 있지만 현재는 감지할 수 있는 내용이 제한되어 있습니다. 예를 들어 내장된 linter는 사용되지 않은 변수를 감지하지만 사용되지 않은 모든 선언의 하위 집합에 대해서만 감지합니다. 사용하지 않는 가져오기 변수, 분해 변수, 사용하지 않는 함수 등은 감지하지 않습니다. Moonpick은 위와 그 이상을 감지하기 위해 탄생했습니다.
Moonpick은 Luarocks를 통해 설치할 수 있습니다.
$ luarocks install moonpick
그런 다음 명령줄에서 실행할 수 있습니다.
$ moonpick < path-to-file >
출력은 Moonscript에 내장된 linter의 출력과 매우 유사합니다.
또한 유일한 종속성은 Moonscript이므로 독립 실행형 애플리케이션에 쉽게 번들로 제공됩니다. 프로그래밍 방식으로 실행하는 방법에 대한 자세한 내용은 API 섹션을 참조하세요.
Moonpick은 할당을 통해 명시적으로 변수로 사용되거나 import
문, 테이블 분해 문 등의 일부로 암시적으로 생성되었는지 여부에 관계없이 모든 형식에서 사용되지 않는 변수를 감지합니다.
Moonpick은 선언되었지만 사용되지 않는 함수 매개변수를 감지하고 불만을 표시할 수도 있습니다. 사용되지 않는 매개변수가 있는 경우가 매우 일반적이므로 이는 기본적으로 활성화되어 있지 않습니다. 예를 들어, 함수가 외부 API를 따를 수 있으며 모두 사용되지 않더라도 여전히 사용 가능한 매개변수를 표시하려고 합니다. 이를 활성화하려면 report_params
구성 옵션을 true
로 설정하세요.
Moonpick은 '_'로 시작하는 모든 매개변수를 화이트리스트에 추가하는 기본 구성을 제공하여 함수에 대한 문서적 측면을 유지하면서도 linter를 만족시킬 수 있는 방법을 제공합니다.
사용되지 않은 루프 변수가 감지되었습니다. 구성에서 이를 완전히 비활성화하거나 루프 변수에 대해서만 명시적인 화이트리스트를 제공할 수 있습니다. Moonpick은 'i' 및 'j' 인수 또는 '_'로 시작하는 모든 변수를 화이트리스트에 추가하는 기본 구성과 함께 제공됩니다.
내장된 linter와 유사하게 Moonpick은 정의되지 않은 참조를 감지합니다.
선언 섀도잉은 선언이 동일한 이름을 가진 이전 선언을 섀도잉할 때마다 발생합니다. 다음 코드를 고려해보세요.
my_mod = require ' my_mod '
-- [.. more code in between.. ]
for my_mod in get_modules ( ' foo ' )
my_mod . bar!
위의 예에서는 루프에 선언된 my_mod
최상위 my_mod
와 다르다는 것이 분명하지만, for 선언과 나중에 사용하는 사이에 더 많은 코드를 삽입하면 금방 덜 명확해질 수 있습니다. 이 시점에서 코드는 모호해집니다. 선언 섀도잉은 각 변수가 모호하지 않은 방식으로 최대 한 번 정의되도록 보장하여 이를 수행하는 데 도움이 됩니다.
report_shadowing
구성 변수를 false로 설정하여 탐지를 완전히 끌 수 있으며, 화이트리스트 구성 목록은 whitelist_shadowing
구성 목록을 지정하여 구성할 수 있습니다.
0.5 이전 버전의 Moonscript에서는 이러한 종류의 섀도잉이 실제로 이전 선언을 재사용하므로 쉽게 간과되고 혼란스러운 버그가 발생할 수 있습니다.
함수 값을 보유하는 이전에 정의된 변수를 재할당하는 것은 거의 원하지 않으며 이전 선언을 잊어버린 결과인 경우가 많습니다.
-- with the following declaration and usage
done = ( x ) -> x . foo and x . bar
done ( {} )
-- one might mistakenly reuse the name further down
i = 1
-- [..]
done = i == 10
특히 항상 실행되지 않는 코드 경로에서만 재할당이 수행되는 경우 디버깅하기 어려운 문제가 발생할 수 있습니다.
report_fndef_reassignments
구성 변수를 false로 설정하여 탐지를 완전히 끌 수 있으며, 화이트리스트 구성은 whitelist_fndef_reassignments
구성 목록을 지정하여 구성할 수 있습니다.
함수나 메소드 내에서 최상위 변수를 재할당하면 때로는 명확하지 않고 이해하기 어려운 버그가 발생할 수 있습니다. 예:
module = require ' lib.module '
-- [..] much further down
get_foo = ( y ) ->
module = y match ( ' %w+ ' ) lower! -- mistakenly reusing the `module` var
return " #{module}_bar "
위의 get_foo
조건부로만 호출하면 심각한 버그가 눈에 띄지 않게 될 수 있습니다.
다른 탐지와 달리 이 탐지는 기본적으로 활성화되지 않습니다 . report_top_level_reassignments
구성 변수를 true로 설정하여 탐지를 활성화할 수 있으며, 화이트리스트 구성은 whitelist_top_level_reassignments
구성 목록을 지정하여 구성할 수 있습니다. 그러나 이 기능을 활성화하는 것이 좋습니다.
이것이 기본적으로 활성화되지 않은 이유는 하위 함수나 메서드 내에서 최상위 변수를 조작하는 합법적인 코드를 갖는 것이 일반적이기 때문입니다. Linter의 불만을 피하려면 화이트리스트를 구성해야 하거나 최상위 변수가 재할당되지 않는 다른 코딩 스타일을 채택해야 합니다(예를 들어 대신 모듈 상태를 유지하기 위해 테이블을 사용함).
Moonpick은 내장된 린터와 동일한 구성 파일 및 형식의 슈퍼 세트를 지원합니다.
함수 매개변수 및 루프 변수의 Linting 구성에 대한 지원을 추가하여 추가 구성 옵션을 제공하고 모든 화이트리스트에서 Lua 패턴을 허용합니다. Linter 구성 파일은 Lua 또는 Moonscript(각각 lint_config.lua
및 lint_config.moon
)로 작성할 수 있습니다.
아래 예를 참조하세요(lint_config.moon, Moonscript 구문 사용).
{
whitelist_globals : {
-- whitelist for all files
[ " . " ] : { ' always_ignore ' } ,
-- whitelist for files matching 'spec'
spec : { ' test_helper ' } ,
}
whitelist_params : {
-- whitelist params for all files
[ " . " ] : { ' my_param ' } ,
-- ignore unused param for files in api
api : { ' extra_info ' } ,
}
whitelist_loop_variables : {
-- always allow loop variables 'i', 'j', 'k', as well as any
-- variable starting with '_' (using a Lua pattern)
[ " . " ] : { ' i ' , ' j ' , ' k ' , ' ^_ ' } ,
}
-- general whitelist for unused variables if desired for
-- some reason
whitelist_unused : {
[ " . " ] : {} ,
}
-- below you'll see the boolean switches controlling the
-- linting, shown with the default value
-- report_loop_variables: true
-- report_params: true
-- report_shadowing: true
-- report_fndef_reassignments: true
-- report_top_level_reassignments: false
}
화이트리스트 항목이 영숫자 이외의 문자로 구성된 경우 패턴으로 처리됩니다.
local moonpick = require ( ' moonpick ' )
code
에서 주어진 코드를 린트하여 린트 검사 테이블을 반환합니다. config
파일에 사용할 Linting 구성이며 일반적으로 구성 파일에 있는 요소의 플랫 버전을 포함할 수 있습니다( whitelist_globals
, whitelist_params
, whitelist_loop_variables
, whitelist_unused
, report_params
, report_loop_variables
).
구성 테이블의 예(Lua 구문):
local moonpick = require ( ' moonpick ' )
local code = ' a = 2 '
moonpick . lint ( code , {
whitelist_globals = { ' foo ' , ' bar ' , }
whitelist_params = { ' ^_+ ' , ' other_+ ' }
})
위의 예에서 반환된 검사 테이블은 다음과 같습니다.
{
{
line = 1 ,
pos = 1 ,
msg = ' declared but unused - `a` ' ,
code = ' a = 2 '
}
}
주어진 file
Lint하고 Linting 검사 테이블을 반환합니다. opts
현재 구성을 로드할 구성 파일을 지정하는 lint_config
하나의 값이 포함될 수 있습니다.
local moonpick_config = require ( ' moonpick.config ' )
path
에 대한 관련 구성 파일의 경로를 반환하거나, 아무것도 발견되지 않은 경우 nil
반환합니다.
config_path
에 지정된 구성 파일에서 파일 file
에 대한 Linting 구성을 로드합니다. 반환된 구성은 file
에 대한 평면화된 구성 옵션 테이블이 됩니다.
주어진 린팅 옵션에 대한 평가자 인스턴스를 반환합니다(예: load_config_from
에 의해 반환됨). 평가자 인스턴스는 다음 함수를 제공합니다(이러한 함수는 일반 점 연산자를 사용하여 호출되는 함수입니다 .
).
allow_global_access
, allow_unused_param
, allow_unused_loop_variable
, allow_unused
, allow_fndef_reassignment
, allow_top_level_reassignment
.
이들 모두는 첫 번째 인수로 기호(문자열)를 취하고 기호가 Linting을 통과하는지 여부에 따라 true
또는 false
반환합니다.
Moonpick은 현 단계에서는 다소 초기 단계이며 대규모 코드 기반에서 성공적으로 실행되었지만 오탐지와 부정확한 보고서가 생성될 가능성이 매우 높습니다. 이 문제가 발생하면 잘못된 동작을 보여주는 코드 샘플로 문제를 열어주세요.
저작권 2016-2017 Nils Nordman
문픽은 MIT 라이선스로 출시됩니다(자세한 내용은 LICENSE 파일 참조).
테스트를 실행하려면 pl
모듈(Penlight - luarock install penlight
)이 필요 busted
. 프로젝트의 루트 디렉터리에서 busted
실행하면 됩니다.
로컬 src
디렉터리를 가리키는 지정된 LUA_PATH를 사용하여 실행합니다. ~/code/moonpick
결제 위치를 가정합니다.
LUA_PATH= " $HOME /code/moonpick/src/?.lua; $HOME /code/moonpick/src/?/init.lua; $( lua -e ' print(package.path) ' ) " ~ /code/moonpick/bin/moonpick * .moon