我知道编程语言有许多短语,例如pep8
python
,但我从来没有遇到makefile
。 makefile
s有这样的短语吗?
随着我逐渐使用makefile
,它会变得越来越复杂和冗长,对我而言,使用linter来保持makefile
更具可读性是有意义的。
答案 0 :(得分:5)
唯一类似于lint
行为的是命令行选项--warn-undefined-variables
答案 1 :(得分:5)
我也不知道在哪里找到make文件lint(网络搜索“make file lint”让我在这里),但是这里有一个不完整的浅层思想片段列表,用于实现make文件lint实用程序...
空格是可读性的一个方面,因为制表文件中的制表符和空格具有不同的语义。当您尝试使用间隔较差的选项卡保存make文件时,默认情况下,Emacs makefile-mode
会警告您出现“可疑”行。也许以批处理模式运行emacs并从该模式调用解析和验证功能是可行的。如果有人要开始实现这样的make文件lint实用程序,那么emacs lisp模式可能是一个有趣的检查。
关于检查正确性,@ Mark Galeck在他的回答中已经提到--warn-undefined-variables
。问题是未定义但标准化的变量有很多输出。为了改进这个想法,可以添加一个简单的包装器来过滤掉有关这些变量的消息,以便发现真正的拼写错误。在这种情况下,可以使用选项make
(又名--just-print
或-n
)运行--dry-run
,以便不运行实际命令来构建目标。
使用--just-print
选项运行make时,执行任何更改都不是一个好主意。 grep $(shell ...)
函数调用并尝试确保从它们内部没有任何改变是有用的。我们可以检查的第一次迭代:$(shell pwd)
和其他一些常见的非破坏性使用是可以的,其他任何东西都应该调用手动检查的警告。
我们可以为$
而不是(
(可能类似[$][^$(][[:space:]]
用POSIX正则表达式表示)来抓住像$VARIABLE
那样解析为$(V)ARIABLE
并且可能不是作者想要的,也不是好的风格。
make文件的问题在于它们与$(shell)
,$(call)
,$(eval)
和规则评估等所有嵌套构造相当复杂;结果可以从环境或命令行的输入或调用make调用中改变;还有许多隐含的规则或其他定义使任何更深层次的语义分析成为问题。我认为所有罗盘制作lint实用程序是不可行的(除了可能内置在make实用程序中),但某些编码指南和启发式检查确实已经证明是有用的。
答案 2 :(得分:4)