Source Insight怎么用正则替换 Source Insight正则替换后格式错乱怎么恢复

在做大批量代码修改的时候，很多人会想到用正则替换来省力气，不过这玩意儿虽然痛快，却也容易顺手把缩进、换行和注释一块儿搅乱，事后收拾格式常常要花掉几倍的时间，非常不划算，所以很有必要先把Source Insight里的正则替换怎么用对，以及万一改完之后格式变得一塌糊涂该从哪里下手恢复，这两个关键问题弄明白。在正式动手之前，一定要记住一个顺序：先尽量缩窄影响的范围，再把当前选用的正则类型确认清楚，最后才分批次一点一点地去替换，这样即便出了差错也来得及收手，不至于把整个项目都卷进去。Source Insight 4这个版本给我们提供了三种不同的正则引擎，分别是它经典的Source Insight正则、可以跨行匹配的正则，还有跟Perl兼容的正则，这三种格式在写法上有不少细微的差别，你直接把别的编辑器里用得顺手的表达式照搬过来，很有可能会因为语法对不上而导致匹配不到目标，或者更糟，匹配出一个你完全想不到的意外结果。

一、Source Insight里正则替换操作怎么跑起来

在Source Insight当中，正则替换能干很多实际的事情，比如批量调整变量名称、统一清理多余的空格、修整注释的书写格式，还有大段的文本内容转换等等，它都能处理得挺到位，但你必须一步一步来，不能一上来就对着整个项目发动。一个非常稳妥的习惯是，在真正按下替换按钮之前，先让搜索功能跑一次，把表达式的匹配结果一条一条看清楚，这样就能避免因为一次改动涉及太多文件而埋下隐患。

1、先打开搜索窗口，把匹配范围摸清楚

第一步要做的，是进入到搜索功能那个界面，在里面把你准备好的查找表达式填进去，接着把那个正则匹配的勾选项给勾上，这时不用急着去碰替换。如果你的目标是整个项目里的所有文件，那就要打开项目范围搜索；如果只是想改当前目录里的那几份代码，就千万别把项目范围的选项一同勾上，范围划得太宽是后面格式大乱的常见导火索。Source Insight自带的Search Files功能，能够帮助我们在项目文件列表里或者指定的某个目录下进行搜索，你还可以顺手加上文件通配符，比如限定只搜.c和.h，这样就能进一步把文件类型给圈住。

2、进到批量替换界面，核对一遍文件列表

等到搜索结束，结果窗口里跳出的那些匹配行你都一一确认过，发现没有误伤到注释、字符串或者无关的代码之后，再去打开Replace Files这个专门用于批量查找替换的窗口。在查找栏里写进你原来的表达式，在替换栏里填上新内容，这看上去没多复杂，但容易出错的地方是文件列表那一块。Replace Files会在你选中的多个文件里同步执行查找和替换，所以启动之前务必把文件列表拉出来看一遍，把那些你压根不想改的文件从选中列表里移走，不要图方便一把全选整个项目。

3、按照当前选定的正则类型，写对表达式

经典的那套Source Insight正则，在写分组的时候习惯用转义的小括号把内容圈起来，替换栏里再用1、2这样带序号的引用去取对应分组里的内容。比如说你要把abcxyz这种形式调换成xyzabc，可以照着下面的思路来组织：

查找栏填入：

按照Source Insight自己的帮助文档说明，分组会由左往右自动编号，替换栏里就可以用带反斜杠的数字把各个分组的结果重新搬过来，这种写法虽然跟别的编辑器里用$1不太一样，但只要记住这个对应关系，就不容易写歪。

4、先找一两个文件试替换，看清楚了再铺开

头一次运行替换的时候，千万别一上来就对着几十上百个文件发命令，更明智的做法是只挑一个文件，或者至多一个小目录来当试验田。替换动作完成之后，马上点开这个已经修改过的文件，仔仔细细地把缩进是不是还整齐、换行符有没有被吃光、注释的排布有没有乱掉以及整体的代码块结构是否完整，都过一遍眼。等你彻底确认表达式不会伤及无辜，代码也保持了原来的样子，再慢慢把范围扩大到更多文件上，这一层保险能替你挡掉大量事后返工的痛苦。

二、替换之后格式错乱，有什么恢复手段

很多时候，格式错乱并不是界面显示上出了什么毛病，根源几乎都是正则表达式被圈定得太宽，或者是在跨行匹配的模式下，换行符被当成普通符号一起吞掉了，导致代码大片大片地挤成一行，非常难看。一旦觉察到这种异常，先不要继续去保存文件，而是立刻停下手里的动作，冷静判断一下影响面到底有多大。

1、用撤销操作把操作按回去

刚完成替换的那一小会儿，最直接的办法就是点一下Undo也就是撤销，Source Insight在撤销这件事情上做得算是比较宽松的，就算你在替换之后已经按了保存，它依旧允许你一路撤销到保存之前的某个状态，只是当你的撤销动作真的跨过保存那一个节点时，软件会弹出一个提醒让你再次确认一下，照做就行。

2、碰到只改乱一小段的情况，用Restore Lines恢复

如果倒霉的只是少量代码段被改得不成样子，大可不必为了这几行去把整个文件的操作都撤销掉，你只需用鼠标把那些走了样的行选中，再去左侧的行号区域按右键，在弹出的菜单里找到并执行Restore Lines，这个命令的作用是把这些被选中的行恢复到文件刚被打开时候的原始内容，而且它本身也支持再撤销，用起来很灵活。

3、重点检查一下跨行表达式

Source Insight 4提供的跨行正则会让点号也把换行符当成匹配对象，碰到那种以.打头的写法，风险尤其大，它甚至可能直接覆盖掉整份文件，把好端端的代码压成平塌塌的一整行。发现这种大面积格式问题时，应该第一个去怀疑是不是在操作的时候误选了跨行正则模式，或者你写的那个表达式里面，碰巧用上了过于宽泛、几乎不设边界的匹配范围。

4、实在不行就靠版本库把文件退回去

如果错误替换之后你已经保存了，还顺手关闭了文件，或者更倒霉一些，好几个目录下的文件全部被错误改写，这时候再靠手工一点一点补空格、调换行就非常愚蠢了，不光耗费时间，还特别容易漏掉更深层次的隐蔽错误。明智的应对是利用版本控制系统，直接把有关的文件或者整个目录回退到替换前的那一次提交，再精细补救也抵不过版本库一键复位来得干净。

三、替换之前该怎样做，才能少走回头路

在Source Insight里要执行批量替换，真正需要花心思去控制的其实是操作的边界，一次改它几百个文件，看上去速度惊人，但事后你得一个文件一个文件地去排查有没有误匹配的地方，加起来耗费的时间反而更让人头疼。

1、先把文件类型牢牢框住

假如你只是想动C语言源码，那就把搜索和替换的过滤类型限定为.c和.h；要是等到换另一种语言了，再相应地改成别的后缀。像什么自动生成的目录、拿来备份的历史版本，还有从外面直接拉进来的第三方库，都不该随随便便放进替换的范围里，一开始就框好边界，能避免一大半的麻烦。

2、始终坚持“先搜后换”这个次序

一定要先跑一次纯粹的查找，也就是只搜不换，然后把结果窗口里的匹配行挨个浏览一遍，看看是不是每一条都打在了你期望的地方，如果你发现搜索结果里混进了注释里的内容、字符串常量的片段，或者干脆是你压根没想碰的无关目录下的文件，这就说明你的表达式还不够收紧，还要继续打磨。

3、正式替换前，先把手头代码提交一次

最好在正式动刀做大批量替换之前，先在版本库里把当前已经稳定的状态提交上去，保存成一个节点，替换的命令执行完，马上调出版本差异去观察变化的文件数量、修改的行数，还有换行方面的变化，一旦发现改动的范围比你预想的要大出一截，或者文件数量明显不对劲，无需犹豫，直接回退到刚才提交的那个版本，再重新调整表达式，这才是最稳的流程。

总结

Source Insight的正则替换到底怎么操作才对路，以及替换过后的格式乱成一团了该怎么恢复，归根结底要靠一个平稳的操作顺序，先把范围圈小、用搜索方式确认匹配结果，再把正则的类型核对清楚，只挑少量文件做初期试验；万一样式出错，优先按Undo和Restore Lines来救急，波及范围已经太大的话，就别再手动修补，果断通过版本库退回去。这样一套组合动作，既能留下批量替换带来的效率，又不会把代码的格式搅得没办法收拾。