I work with a medium sized team of developers, with half being Linux developers using VIM on Ubuntu and MacVIM on OSX, and the other half being Windows developers using Visual Studio 2010 or later.
A fair bit of time has been wasted in the past when handling things like SVN operations failing due to mixed line endings, or changes to code reviews due to a mix of hard-tabs versus spaces-as-tabs (and sometimes of varying lengths, ie: 4 spaces vs 2 spaces vs 8 spaces, etc), and I would like to put an end to it.
The plan is to adapt a common coding style we've designed, which is almost identical to the Linux Kernel coding style. For all developers, we could require them to run their code through the checkpatch.pl script used by Linux kernel devs, but our code includes C, C++, and C#, so we would need to generalize the rule checker script beyond just ANSI C.
Is there a generic way to implement a rule set for VIM, and another for Visual studio? We'd like to generate a script that checks entire files, which could be hooked into our version control system so that it's run on code before commits complete, and perhaps as a run-time script to enforce the style as coders type?
Thank you.
EditorConfig seems to do exactly what you want in Vim, Visual Studio, and a lot of other editors and IDEs.
The run-time "script" is the best first-line of defense. In this case, it will be various Vim and Visual Studio settings to help enforce your code style. That alone will catch quite a few problems. Keep in mind, this won't catch everything, but will encourage the coding style you want.
I've worked across Linux & Visual Studio in a team before (and sometimes by myself). The whole Tabs/Spaces issue drove me nuts as there would be wholesale groups of lines that were either shifted WAY over or not enough. To solve this, I ended up using these three settings in Vim (also set similar values in Visual Studio), thus catching one class of issues at the root.
Vim
set expandtab
set shiftwidth=4 " Mainly for if/for/while/general {} block indentation. 4 spaces.
set softtabstop=-1 " Allows us to use the Tab key and have it act like shiftwidth.
Visual Studio
Insert spaces when Tab key is pressed.
Shift 4 spaces on indent inside code block
They key is getting rid of the Tab characters, or at least having both systems use the SAME SETTINGS (i.e. both using Tab with the same values or SPACEs substituting as Tabs)
Something to watch out for:
Someone copying a file from one Operating System to a different one and then checking the file into SVN on that machine. SVN will blindly commit, say, a DOS line-ending file from a UNIX system. You want to checkout/commit files on the same system only. Otherwise, checking out/editing/committing files all on the same OS should present no issues, as SVN can convert the line endings upon checkout. You can "fix" this by loading a file into Vim and then converting the line-endings to the particular OS you want by typing ":set fileformat=dos" (if you want to change to Windows-style), ":set fileformat=unix" (for unix style), or finally ":set fileformat=mac" for Mac.
As far as the code style goes, as you probably already know, both Vim and Visual Studio offer lots of flexibility there. While I cannot give you the specific settings for Vim, the options to look at are
autoindent
cindent
cinoptions (implied from cindent)
cinkeys (implied from cindent)
comments (default is probably fine, but here for thoroughness)
So, you will want
set autoindent
and cindent should be automatically set when editing a C or C++ file. The defaults for cinoptions and cinkeys are ok for me, but I have tweaked them in the past when working with a different group.
Don't forget about using the '=' command over a selected range of lines to reformat the code! This can be very handy!
I shy away from the completely automatic SVN backend method because it may take longer than you expect to get it right, and when it screws up, it will probably take more time out of your day than you expect as well. After all, you really just want to be productive, right?.
Discipline up front is key!
Related
I used VIM whole my life but recently I am a bit tired of it because I am lost in buffers, windows, and tabs when working simultaneously with 20 files or so in a big project (with 500k LOC, and hundreds files).
Whenever i do :make, :grep, etc, new buffers are jumping out in the current window.
The same happens for the tags. At some point this starts to be very confusing because I really have to focus where things are in a VIM.
What are a proven and easy ways to control this behavior?
Use :hide to get rid of all windows unless you really need them open.
I'm not sure why tags are creating a new window for you, CTRL+] should re-use the current window.
nnoremap + 4<C-W>+ and nnoremap - 4<C-W>- make it much easier to resize windows, along with the standard <C-W>_ and <C-W>|.
Get a 22" monitor (minimum) and use :vsplit to show files side by side. I find this is even more important than having two smaller monitors.
Use <C-W>L, <C-W>H etc to move windows around. Don't forget :tab sp to open the current file (or a new one) in a new tab.
:map <LEFT> <C-W>h and :map <RIGHT> <C-W>l, etc make it much easier to move between windows. :map <C-LEFT> :tabprev<CR> and :map <C-RIGHT> :tabnext<CR> make it much easier to move between tabs.
And finally, if you need to have 20 files open regularly, this could be a sign that your code is poorly organized. If possible, features should be contained within a single file, then you just need to focus work on one feature at a time.
I tested out Eclim http://eclim.org/ a while ago for a friend. Basically, it lets you run Eclipse in a headless mode while using vim for editing and so on. With the extension, it allows Vim to draw on all the strengths of both worlds, adding for instance Eclipse's project tree to your favourite editor!
Installation was a bit daunting back then, but once I had it up and running, it was really smooth and quite a brilliant solution. Try it out, I'm pretty sure you won't be disappointed. And the installation is probably easier now. :)
Oh, I should also mention that there are several Eclim-setups. You can have headless Eclipse with vim as your primary interface (as I first mentioned), you can have a headed Eclipse and Vim, so that you can easily switch back and forth (in the same project no less), or you can have Vim integrated into Eclipse itself.
Run multiple vims. I use "konsole" on my Linux machine. It allows me to open many tabbed linux terminal sessions in one window. I can double click the tabs to name them, e.g. "models", "views", "controllers", etc. In each of these tabbed linux terminals, I'll have a vim process running that has usually 2 or 3 files open at a time.
Another option is to find and IDE that has Vim mode, so you can still use most of your key commands.
As a longtime vim user, it pains me to say it, but--it might be time for you to graduate to a full-fledged IDE. You can still use vim as your editor in most cases, but the IDE will handle file management and navigation for you, and probably will simplify your make and grep workflows (e.g., structural search beats the pants off of grep). What language are you working on?
Vim-CtrlSpace lets you organize Tabs, Buffers, Sessions (workspaces) + fuzzy search.
It is quite suitable to work on large projects. That's how I actually come up with it.
Before, I used 'jlanzarotta/bufexplorer.git' and 'xolox/vim-session'
You can check the demo on YouTube.
MS Visual Studio editor highlights some non-keyword identifiers as keywords
in C++ files. Particularly "event" and "array" are treated as keywords.
That's very annoying to me, because they are not C++ keywords.
I know how to add my own keywords to the list of syntax-highlighted identifiers,
but how to remove existing built-in ones?
I'm aware that this may require patching some executable files.
So does anyone know how to do this?
Thanks to article mentioned by Steve Guidi, I was able to find executable file that contains Colorizer and IScanner classes. It is named vcpkg.dll and located in /Microsoft Visual Studio 8/VC/vcpackages. (I'm using Visual C++ 2005 Express Edition, things may be different in other versions.)
The vcpkg.dll contains null-terminated UTF-16 encoded strings. I've opened it with hex editor, and searched for "array". There is only one such string in the file, so I've replaced it with "arrry". (It is important to maintain relative alphabetical order with respect to other keywords.) Then I've searched for "event", it shows up in several places, but there is only one that isn't part of some longer string, so I've replaced this one with "evvvt". After starting Visual Studio, it turned out that "array" and "event" weren't any longer highlighted, but "arrry" and "evvvt" were!
Of course this is an ugly hack, and it will void your warranty,
and probably goes against Microsoft EULA, but what a relief for the eyes!
Anyway, if you want to do it, be careful and remember to backup the file.
It doesn't look like a disable-syntax-coloring feature is exposed in a user-friendly way.
The only way I can think of selectively disabling syntax coloring is to create a new syntax coloring plugin for the IDE, and list all of the keywords you want colored. Microsoft gives information in this article on how to accomplish this task.
The drawback to this approach is that your IDE will now have two C++ languages and I'm not sure how it will select which plug-in to choose from once it loads a .h or .cpp file. However, this article suggests that you can override the existing C++ plug-ins by rewriting some registry keys.
I think the only "semi-practical" way to accomplish this to create a Visual Studio package that uses Text Markers to selectively cover up the keywords you don't want colored. Even that is not a little one-day task. Edit: Probably not even a full week task for someone not intricately familiar with the Visual Studio API and all its quirks, especially not getting it bug-free.
In other words, you probably want to just ignore them.
I was going to create the C++ IDE Vim extendable plugin. It is not a problem to make one which will satisfy my own needs.
This plugin was going to work with workspaces, projects and its dependencies.
This is for unix like system with gcc as c++ compiler.
So my question is what is the most important things you'd need from an IDE? Please take in account that this is Vim, where almost all, almost, is possible.
Several questions:
How often do you manage different workspaces with projects inside them and their relationships between them? What is the most annoying things in this process.
Is is necessary to recreate "project" from the Makefile?
Thanks.
Reason to create this plugin:
With a bunch of plugins and self written ones we can simulate most of things. It is ok when we work on a one big "infinitive" project.
Good when we already have a makefile or jam file. Bad when we have to create our owns, mostly by copy and paste existing.
All ctags and cscope related things have to know about list of a real project files. And we create such ones. This <project#get_list_of_files()> and many similar could be a good project api function to cooperate with an existing and the future plugins.
Cooperation with an existing makefiles can help to find out the list of the real project files and the executable name.
With plugin system inside the plugin there can be different project templates.
Above are some reasons why I will start the job. I'd like to hear your one.
There are multiple problems. Most of them are already solved by independent and generic plugins.
Regarding the definition of what is a project.
Given a set of files in a same directory, each file can be the unique file of a project -- I always have a tests/ directory where I host pet projects, or where I test the behaviour of the compiler. On the opposite, the files from a set of directories can be part of a same and very big project.
In the end, what really defines a project is a (leaf) "makefile" -- And why restrict ourselves to makefiles, what about scons, autotools, ant, (b)jam, aap? And BTW, Sun-Makefiles or GNU-Makefiles ?
Moreover, I don't see any point in having vim know the exact files in the current project. And even so, the well known project.vim plugin already does the job. Personally I use a local_vimrc plugin (I'm maintaining one, and I've seen two others on SF). With this plugin, I just have to drop a _vimrc_local.vim file in a directory, and what is defined in it (:mappings, :functions, variables, :commands, :settings, ...) will apply to each file under the directory -- I work on a big project having a dozen of subcomponents, each component live in its own directory, has its own makefile (not even named Makefile, nor with a name of the directory)
Regarding C++ code understanding
Every time we want to do something complex (refactorings like rename-function, rename-variable, generate-switch-from-current-variable-which-is-an-enum, ...), we need vim to have an understanding of C++. Most of the existing plugins rely on ctags. Unfortunately, ctags comprehension of C++ is quite limited -- I have already written a few advanced things, but I'm often stopped by the poor information provided by ctags. cscope is no better. Eventually, I think we will have to integrate an advanced tool like elsa/pork/ionk/deshydrata/....
NB: That's where, now, I concentrate most of my efforts.
Regarding Doxygen
I don't known how difficult it is to jump to the doxygen definition associated to a current token. The first difficulty is to understand what the cursor is on (I guess omnicppcomplete has already done a lot of work in this direction). The second difficulty will be to understand how doxygen generate the page name for each symbol from the code.
Opening vim at the right line of code from a doxygen page should be simple with a greasemonkey plugin.
Regarding the debugger
There is the pyclewn project for those that run vim under linux, and with gdb as debugger. Unfortunately, it does not support other debuggers like dbx.
Responses to other requirements:
When I run or debug my compiled program, I'd like the option of having a dialog pop up which asks me for the command line parameters. It should remember the last 20 or so parameters I used for the project. I do not want to have to edit the project properties for this.
My BuildToolsWrapper plugin has a g:BTW_run_parameters option (easily overridden with project/local_vimrc solutions). Adding a mapping to ask the arguments to use is really simple. (see :h inputdialog())
work with source control system
There already exist several plugins addressing this issue. This has nothing to do with C++, and it must not be addressed by a C++ suite.
debugger
source code navigation tools (now I am using http://www.vim.org/scripts/script.php?script_id=1638 plugin and ctags)
compile lib/project/one source file from ide
navigation by files in project
work with source control system
easy acces to file changes history
rename file/variable/method functions
easy access to c++ help
easy change project settings (Makefiles, jam, etc)
fast autocomplette for paths/variables/methods/parameters
smart identation for new scopes (also it will be good thing if developer will have posibility to setup identation rules)
highlighting incorrect by code convenstion identation (tabs instead spaces, spaces after ";", spaces near "(" or ")", etc)
reformating selected block by convenstion
Things I'd like in an IDE that the ones I use don't provide:
When I run or debug my compiled program, I'd like the option of having a dialog pop up which asks me for the command line parameters. It should remember the last 20 or so parameters I used for the project. I do not want to have to edit the project properties for this.
A "Tools" menu that is configurable on a per-project basis
Ability to rejig the keyboard mappings for every possible command.
Ability to produce lists of project configurations in text form
Intelligent floating (not docked) windows for debugger etc. that pop up only when I need them, stay on top and then disappear when no longer needed.
Built-in code metrics analysis so I get a list of the most complex functions in the project and can click on them to jump to the code
Built-in support for Doxygen or similar so I can click in a Doxygen document and go directly to code. Sjould also reverse navigate from code to Doxygen.
No doubt someone will now say Eclipse can do this or that, but it's too slow and bloated for me.
Adding to Neil's answer:
integration with gdb as in emacs. I know of clewn, but I don't like that I have to restart vim to restart the debugger. With clewn, vim is integrated into the debugger, but not the other way around.
Not sure if you are developing on Windows, but if you are I suggest you check out Viemu. It is a pretty good VIM extension for Visual Studio. I really like Visual Studio as an IDE (although I still think VC6 is hard to beat), so a Vim extension for VS was perfect for me. Features that I would prefer worked better in a Vim IDE are:
The Macro Recording is a bit error prone, especially with indentation. I find I can easily and often record macros in Vim while I am editing code (eg. taking an enum defn from a header and cranking out a corresponding switch statement), but found that Viemu is a bit flakey in that deptartment.
The VIM code completion picks up words in the current buffer where Viemu hooks into the VS code completion stuff. This means if I have just created a method name and I want to ctrl ] to auto complete, Vim will pick it up, but Viemu won't.
For me, it's just down to the necessities
nice integration with ctags, so you can do jump to definition
intelligent completion, that also give you the function prototype
easy way to switch between code and headers
interactive debugging with breaakpoints, but maybe
maybe folding
extra bonus points for refactoring tools like rename or extract method
I'd say stay away from defining projects - just treat the entire file branch as part of the "project" and let users have a settings file to override that default
99% of the difference in speed I see between IDE and vim users is code lookup and navigation. You need to be able to grep your source tree for a phrase (or intelligently look for the right symbol using ctags), show all the hits, and switch to that file in like two or three keystrokes.
All the other crap like repository navigation or interactive debugging is nice, but there are other ways to solve those problems. I'd say drop the interactive debugging even. Just focus on what makes IDEs good editors - have a "big picture" view of your project, instead of single file.
In fact, are there any plugins for vim that already achieve this?
I work in a Unix environment with the typical Unix tools (emacs, vim, gvim, sunstudio, etc)
My project has huge gross boilerplate comments on every method. It makes the files thousands of lines long, with a couple hundred lines of actual code. I may be exagerrating a bit but you get the idea. I am looking for a way when viewing these files to hide (not remove) all comments so I can quickly go through the code. C++ comments '//' only.
It all depends on which editor you use. In vim, you can enable folding with :
set foldenable
Then, you'll be able to use different of folding methods, for mainstream languages, you can set :
set foldmethod=syntax
which will enable syntax folding.
There are half a dozen folding methods, I think the best would be to read
help folding
which should answer everything.
When I'm developing in C#, I heavily use GhostDoc to speed up the process of commenting my code. I'm currently working on a C++ project and I haven't found an equivalent tool. I know about Doxygen, but from what I know it is used to create documentation outside the code, not comments in the code. Are there any good equivalent tools? I would prefer one that runs in VS, but I could handle one that works in any IDE.
(Before someone brings it up, I don't rely solely on GhostDoc to create comments. I just use it to create the starting point for my comments.)
I've written an add-in, Atomineer Pro Documentation, which is very similar to GhostDoc (it generates/updates documentation comments to save a lot of time and effort when documenting), but it parses the code directly for itself and thus is able to handle C, C++, C++/CLI, C#, Java and Visual Basic code, and doesn't require the surrounding code to be in a compiling state before it will work. It will also automatically add/update documentation for more tricky things such as exceptions thrown within the body of a method.
It runs under Visual Studio 11, 2010, 2008 and 2005, and supports Documentation-Xml, Doxygen, JavaDoc and Qt commenting formats, as well as the format/style of comment blocks and the auto-doc rules used being highly configurable. It has a number of other handy features such as aiding conversions of legacy doc-comments to the above formats, and word wrapping in doc-comments and normal block comments.
The above is just a summary of some key features - This comparison of features with other products serves as a more complete list of the many other features available.
Visual Assist helps by providing custom scripts executed while typing (or on other).
For example, you can have a script for comments like this :
/************************************************************************/
/* My comment : $end$ */
/************************************************************************/
That would be suggested (via a combo-box exactly like intellisense) when you start typing "/**" for example.
When you select this suggestion (via Enter/Space/Click - customizable), it will insert the script where your cursor is and just replace markers that are between '$' characters by special values (like the current file name for example).
Here the $end$ marker will make the cursor be at this position when the script is executed. This way, you continue typing smoothly. For example with the previous script set, typing exactly :
/** this is a test comment to show you one of the many features Visual Assit!
will simply give :
/************************************************************************/
/* My comment : this is a test comment to show you one of the many features Visual Assit! */
/************************************************************************/
It's really easy to customize and the behavior of the suggestion (read : intellisense++) system is customizable.
Visual Assist might do the job, though I'm not absolutely sure.