前段时间我发现了一个(相当古老的)C编译器,它以这种方式扫描宏(伪代码):

 if line.startswith("#include") or line.startswith("#define"):
     ...

..哪一种问题对我来说应该放置宏的位置,在一行的开头,如下所示:

void stuff()
{
#if defined(WIN32) || defined(_WIN32)
    ...
#else
#if defined(__GNUC__)
    ...
#else
    ...
#endif
#endif
}

或者更像是这样(因为我这样做,为了提高可读性):

void stuff()
{
    #if defined(WIN32) || defined(_WIN32)
    ...
    #else
    #   if defined(__GNUC__)
    ...
    #   else
    ...
    #   endif
    #endif
}

是一种缩进预处理器代码标准化的方式,也就是说,无论我如何缩进它,它总是以相同的方式工作？

基本信息

(注意:请一直阅读,因为我花了一些时间来组织它,确保我解决了我遇到的每个问题以及为什么一个提议的解决方案对我不起作用.)

我在vim中使用cindent来自动进行缩进.它大部分时间都很好用.但是,cindent做了三个坏事(在我看来)涉及C预处理器指令(以哈希('#')开头的语句).

如果它是相关的,我使用标签进行缩进,我的.vimrc包含filetype indent on.

坏事1

只要我输入一个预处理器指令,vim就会将它放在第1列(它完全取消缩进).例如,这是我输入代码时vim对我的代码所做的事情:

int main(void)
{
    while(1) {
        /* normal things */
#ifdef DEBUG
        printDebugInfo();
#endif
        /* normal things */
    }
}

但是,我希望它看起来像这样:

int main(void)
{
    while(1) {
        /* normal things */
        #ifdef DEBUG
        printDebugInfo();
        #endif
        /* normal things */
    }
}

换句话说,我更喜欢vim像任何其他C/C++语句一样处理预处理程序指令.

坏事2

当我使用预处理器指令使用==(或[movement]=跨越)一行时,vim将其放回第1列.(这与Bad Thing 1一致,但仍然存在问题.)

坏事3

如果(由于Bad Thing 1或2或使用<<)预处理程序指令最终在第1列中,它会在那里"卡住"并且不受影响>>.增加缩进的唯一方法是I<Tab>或 …