Posts Tagged ‘tip’
虽然从很久前就开始用 VIM 了，但一直都是半调吊 子，翻来覆去只用自己会的命令。最近为了提高书写代码的效率，还有 coding 时候的乐趣，又重新钻研了一下 VIM，发现了一篇很好的 VIM 入门的文章，原文是英文版的，我觉得非常适合 VIM 使用入门，所以翻译了过来。这里是简单的介绍了 VIM 的操作方式，并没有说为什么要用 VIM，如果你想知道答案可以去 Google，VIM 被誉为编辑器之神。 这篇教程写了在不同工作模式下使用 VIM 的一些基本技巧——即插入模式（insert mode）， 命令模式（command mode）， 存取文件等。目的是帮助刚刚接触 VIM 的新手更加有效率的使用这个出色的编辑器。 说明：在这篇文章里面，<C-X> 代表 Ctrl + X——就是按住 Ctrl 键然后再按 X。而且你可以在很多情况下使用 :help command 来获得大部分命令的帮助，这个是 VIM 的内部帮助文件命令。 高效率移动 在插入模式之外 基本上来说，你应该尽可能少的呆在插入模式里面，因为在插入模式里面 VIM 就像一个“哑巴”编辑器一样。很多新手都会一直呆在插入模式里面，因为这样易于使用。但 VIM 的强大之处在于他的命令行模式！你会发现，在你越来越了解 VIM 之后，你就会花越来越少的时间使用插入模式了。 使用 h、j、k、l 使用 VIM 高效率编辑的第一步，就是放弃使用箭头键。使用 VIM，你就不用频繁的在箭头键和字母键之间移来移去了，这会节省你很多时间。当你在命令模式时，你可以用 h、j、k、l 来分别实现左、下、上、右箭头的功能。一开始可能需要适应一下，但一旦习惯这种方式，你就会发现这样操作的高效之处了。 [...]
非常好用,而且速度很快 首先, 用vi打开一个文件 然后,在命令模式下输入: :%!xxd vi打开文件的模式就转变成二进制的模式了,!!! via:http://my.donews.com/minjun/2006/08/09/uLwEYfucCXTNtFPGiPYvGrspGVlRukAAsjlJ/
vim小技巧 打开文件后，不用任何鼠标、菜单，只须在键盘上按下“ggguG”就行了。 极品软件就是这样：唯有功能强到极致，操作才能简到极致！ 解释一下：ggguG分作三段gg gu G gg=光标到文件第一个字符 gu=把选定范围全部小写 G=到文件结束 Vim 正则匹配次数需要 a/{2} 而不仅仅是 a{2} 单独使用guu将当前行转小写。 单独使用gUU将当前行转大写。 光标控制命令 命令 光标移动 h或^h 向左移一个字符 j或^j或 ^n 向下移一行 k或^p 向上移一行 l或空格 向右移一个字符 G 移到文件的最后一行 nG 移到文件的第n行 w 移到下一个字的开头 W 移到下一个字的开头，忽略标点符号 b 移到前一个字的开头 B 移到前一个字的开头，忽略标点符号 L 移到屏幕的最后一行 M 移到屏幕的中间一行 H 移到屏幕的第一行 e 移到下一个字的结尾 E 移到下一个字的结尾，忽略标点符号 ( 移到句子的开头 ) 移到句子的结尾 { [...]
首先，我们先来看看Code Reivew的用处： Code reviews 中，可以通过大家的建议增进代码的质量。 Code reviews 是一个传递知识的手段，可以让其他并不熟悉代码的人知道作者的意图和想法，从而可以在以后轻松维护代码。 Code reviews 也鼓励程序员们相互学习对方的长处和优点。 Code reviews 也可以被用来确认自己的设计和实现是一个清楚和简单的。 你也许注意到了在上面的Code Reivew中的诸多用处中，我们没有提到可以帮助找到程序的bug和保证代码风格和编码标准。这是因为我们认为： Code reviews 不应该承担发现代码错误的职责。Code Review主要是审核代码的质量，如可读性，可维护性，以及程序的逻辑和对需求和设计的实现。代码中的bug和错误应该由单元测试，功能测试，性能测 试，回归测试来保证的（其中主要是单元测试，因为那是最接近Bug，也是Bug没有扩散的地方）。 Code reviews 不应该成为保证代码风格和编码标准的手段。编码风格和代码规范都属于死的东西，每个程序员在把自己的代码提交团队Review的时候，代码就应该是符合规 范的，这是默认值，属于每个人自己的事情，不应该交由团队来完成，否则只会浪费大家本来就不够的时间。我个人认为“meeting”是奢侈的，因为那需要 大家在同一时刻都挤出时间，所以应该用在最需要的地方。代码规范比起程序的逻辑和对需求设计的实现来说，太不值得让大家都来了。 10年前，上面这两件事会是理所当然的（10年前的中国的软件开发还没有Code Reivew呢）。今天，在中国的很多公司上面这两件事依然被认为是Code Reivew最重要的事。所以，我能够看到很多开发Team抱怨Code Review就是一个形式，费时费力不说，发现的问题还不如测试，而评审者们除了在代码风格上有些见术，别的也就没什么用了，长而久之，大家都会开始厌烦 这个事了。 所以，在今天，请不要把上面的那两件事分散了Code Review的注意力，取而代之的是，对于Bug，程序的作者要在Review前提交自己的单元测试报告（如：XUnit的测试结果），对于代码规范，这 是程序作者自己需要保证的，而且，有一些工具是可以帮你来检查代码规范的。 当然，上述这些言论并不是说，你不能在Code Review中报告一个程序的bug或是一个代码规范的问题。我只是说，那并不是Code Review的意图。 下面是我们认为的几个小提示可以让你更好进行Code Review这项最有价值的活动。 1. 经常进行Code Review 以前经历过几个相当痛苦的Code Review，那几次Code Review都是在程序完成的时候进行的，当你面对那近万行的代码，以前N多掺和在一起的功能，你会发现，整个Code Review变得非常地艰难，用不了一会儿，你就会发现大家都在拼命地打着哈欠，但还是要坚持，有时候，这样的Review会持续3个小时以上，相当的夸 张。而且，会议上会出现相当多的问题和争论，因为，这就好像，人家都把整个房子盖好了，大家Review时这挑一点那挑一点，有时候触动地基或是承重墙 体，需要大动手术，让人返工，这当然会让盖房的人一下就跳起来极力地维护自己的代码，最后还伤了团队成员的感情。 所以，千万不要等大厦都盖好了再去Reivew，而且当有了地基，有了框架，有了房顶，有了门窗，有了装修，在各个时候循序渐进地进行 Review，这样反而会更有效率，也更有帮助。 下面是一些观点，千万要铭记： 要Review的代码越多，那么要重构，重写的代码就会越多。而越不被程序作者接受的建议也会越多，唾沫口水战也会越多。 程序员代码写得时间越长，程序员就会在代码中加入越来越多的个人的东西。 程序员最大的问题就是“自负”，无论什么时候，什么情况下，有太多的机会会让这种“自负”澎涨开来，并开始影响团队影响整个项目，以至于听不见别人的建 议，从而让Code [...]
