D IDE

[Ecstatic Coder]

> Except that you don't have projects or solutions with something 
> like vim or emacs. There is no structure specific to them. You 
> can set them up to do the build from inside them, and with 
> emacs, you can run gdb inside it if you're on an appropriate 
> platform, but you're not going to have a "vim" project or an 
> "emacs" project. That whole concept is an IDE thing. They edit 
> files, and they can do that perfectly fine regardless of what's 
> being used to run the build or whatever other tools are 
> necessary for the development process.
>
> If I'm in a situation like you describe, then I usually set it 
> up so that I can just run the build and tests from the command 
> line and not even bother opening up Visual Studio. VS projects 
> actually have a way to do that. You don't actually have to open 
> up VS to do any building. And if I really need to open up VS to 
> run the debugger, then I'll do that, but I won't use VS for 
> anything that I don't have to use it for. And in my experience, 
> the debugger is pretty much the only thing that would typically 
> require actually opening up VS.
>
> There is no reason to muck with the build process or source 
> control stuff in order to use vim or emacs. That stuff can 
> pretty much always be done from the command-line using all of 
> the standard tools that everyone else is using. Just because 
> most developers would use the IDE to run the build doesn't mean 
> that it's actually required for it. If it were, then stuff like 
> automated builds wouldn't be possible.
>
> Regardless, I use vim for editing code. And if I'm actually 
> forced to have an IDE like VS or Eclipse open because of some 
> tool that has to be run from inside for some reason (which 
> aside from the debugger is rarely the case), then I'll have the 
> IDE open for whatever it has to be open for. But I don't use 
> the IDE for editing code, because that would be a horribly 
> inefficient way to do go about it.
>
> - Jonathan M Davis

+1

What must be absolutely standardized is what is *shared* across 
the members of the team (code presentation, tabs, naming 
conventions, build process, versioning, test and deployment 
procedures, etc etc).

But as long as the coding standard is followed, obviously any 
code editor should be fine if it makes you more productive.

For instance, even for contract work, I use Geany for all my 
developments.

And a portable IDE like Geany is especially useful when 
developping *crossplatform* C++ multimedia applications which 
must be edited and tested both on Windows, MacOS and Linux.

It is the perfect companion to cmake, behaving exactly the same 
whatever the platform (editing, find and replace, find in files, 
macros, settings, etc).

And indeed you can still open your project in Visual Studio when 
you need to use a Windows debugger.

Personally I use Geany even for Unity game development, as Unity 
allows to define which editor should be used to show the 
erroneous line of C# code when double clicking onto an error 
message.

Geany is great for that too, as it opens often much faster than 
other IDE...

So my point is, as long as all the shared team standard 
procedures are respected, I fon't see why any company should 
decide which code editor *must* be used by all its developers...