In the company we are using WebStorm for React, and for the last 3 years I have been working in VS Code.
Is there a way to get exact code formatting for all languages in VS Code as in WebStorm on default settings, and how to achieve that in order to prevent unnecessary diffs in git?
I can only tweak VS Code settings, I must not touch WebStorm.
To get the same formatting/functionality as Webstorm, I suggest using VS Code extensions. You will find an extension for almost every language/framework available on the VS Code marketplace.
Here is a list of recommended extensions that makes VS code behave as Webstorm.
For your particular case, I suggest you to use and configure Prettier.
Note that you might not want to install too many extensions but only the ones you need because loading too many extensions will probably slow down your IDE.
I've been going nowhere but in circles trying to understand the odd relationships between and varying levels of "standalone-ness" of these tools.
I've been using Aptana Studio on OSX for about 4 years and been happy with it, however my recent update to 3.6 blew up so many things I ended up rolling back to 3.4 just so I could work.
For better or worse, I do like Aptana, but I'm not bound to it and am now very frustrated with the latest version, specifically that all the python stuff went haywire. Searching for help is painful, as threads and advice are many years old.
So, in way of questions:
can anyone explain the relationship between Eclipse, Aptana, PyDev, and LiClipse? And more importantly:
a recommendation that meets the following criteria
What I need/want is:
something free and open source
with a current and active community
easily themeable with dark colors so I'm not staring at the sun 8 hours a day
tight python features (pep, pylint, ability to jump to references with a keypress, etc)
tight html/css/javascript features
Like I said, I do like Aptana, just frustrated in the apparent lack of a current community and how it seems to be falling apart.
Well, I'm not sure this is a good question for stackoverflow... anyways, I'll try to explain how it goes:
Aptana Studio 3 is an IDE which is currently supported by Appcelerator. Their main focus is currently on supporting the Appcelerator mobile platform (actually that's Titanium Studio, but Aptana Studio 3 is the basis for it -- the languages they aim for are html/css/javascript, which is what's needed for Titanium)... Although they do integrate a pretty old version of PyDev too (as PyDev requires a newer java whereas they're still on an older version of Java, so, I guess it's currently hard for them to keep it up to date).
Back in the day, they supported the development of PyDev, but decided to stop that support some time ago -- there's a bit more history at: http://pydev.blogspot.com.br/2013/03/keeping-pydev-alive-through-crowdfunding.html.
After that, LiClipse (http://www.liclipse.com/) was created out of my frustration to support dark themes and have support for more languages (it was a crowdfunded project -- it should've been an open source project, but didn't reach its goals for that, so, in the end it's closed source, and its revenue is a part of what keeps the PyDev development going on).
And at last, Eclipse is the basis for both platforms -- so, external plugins should integrate nicely into any of those.
Now, on the recommendation front:
LiClipse should meet your dark/python/html/css/javascript issues (its focus on the editors front is on being dark-themed/lightweight and easy to add support for new languages), but it's not completely open source (some parts of it have been made open source though: http://www.liclipse.com/text).
Aptana Studio 3 should still work and give support for the dark/python/html/css/javascript too, but given that they have to convert some things from the PyDev Java to its own version, Python support is always a bit outdated (as for the current community/support, I can't really comment, but I guess you should be able to report problems to them to try to solve the issues you have).
And the other choice (which may be a bit more work to configure) would be using a bare Eclipse and installing PyDev and separate plugins for html/css/javascript (it seems there are multiple available, but I can't really comment on any of those).
I am looking for a easier way to manage my eclipse code snippets. I know and have used Eclipse's template and snippets features. But as far as I have found, they can only be exported and imported as XML files.
Since I use many versions of eclipse and I keep migrating between machines managing the snippets is a hassle. I am looking for a UltiSnips like method to manage these snippets/templates. Is there one?
I also looked at snip2code, but it didn't appeal to me because I sometime work offline. Also, I want to have much greater control over the snippets using version control.
Oh well! I couldn't find anything that matched the set of requirements I had. So, I've ended up creating my own.
Few weeks ago I tried Intellij and I found it really awesome. Now, at my project there are two programmers (including me) using Intellij and few other programmers who are going to keep using Eclipse. Since this project is already very large and it's going to grow a lot, we need to use compatible Code Style and Code Formatting between Intellij and Eclipse. We do not want to have problems when one user edits some file and reformats it before saving. With Eclipse "alone" we used to have some exported configuration, and before anybody starts to work, the first step is just to import this configuration. We already tried to use External Code Formatter, but it didn't work on Intellij 9.
So, I have a bunch of questions here:
Is there any way to import eclipse formatting configuration on Intellij 9?
Anybody could share their experience managing this kind of situation? Do you guys have any other suggestion to manage this situation?
There is an updated plugin for IDEA, called Eclipse Code Formatter:
http://plugins.intellij.net/plugin/?idea&id=6546
I would recommend someone spends the time to configure their IntelliJ's code style to be the same as Eclipse. This will take a little time and effort but once it is done, you can export it just like in eclipse so that any other IDEA users can import it.
You could also search online to see if anyone has already done this and you can simply download the code style config and use it.
The only alternative I can think of would be to find a standardized code style template that is available for both eclipse and IntelliJ, like the Recommended Sun Java Code Style.
There seems to be a plugin for that (emerged from this discussion).
I was always wondering why it is a big deal having version control support inside an IDE.
I always preferred to use a command-line/standalone version of the version control of choice and never found IDE integration helpful.
I know it can be helpful sometimes, for example to automatically keep track of renames, but I was bitten by version control plugins a couple of times (especially the ClearCase Eclipse plugin) that I'm now finding it counter productive compared to the command-line version, where I have better control.
What is your opinion?
Integrated Source Control also helps to only keep the important files under Source control. For example, when I add a new File in Visual Studio, the Plugin (visualSVN) will allow me to add it easily without me having to remember to go outside of my IDE and run the command to add it to the repository. On the other hand, it will automatically ignore temporary files, like the obj/ and bin/ Folders.
Essentially: Integrated Version Control that actually works is a great way to keep the repository clean and complete.
I like how some IDE's implement this. Ankh-SVN for Visual Studio is not that great and is a bit buggy, however Subeclipse I find to work exceedingly well when I'm using Eclipse.
I think it really depends on the IDE you're using and the quality of that plug-in. It's going to work well for some setups and terrible for others.
That's why I like Subversion with Tortoise SVN so much. I can choose to use the IDE integration when and where it makes sense, otherwise, just like you said, I can simply use the command line or in my case, the windows explorer based client!
Integration of the IDE with version control and, in particular, software change management (SCM) helps bringing together the philosophies of the IDE and the source control system.
One example is temporary files and binaries, that should not be checked-in and, e.g. in Visual Studio, end up within the source directory if you're not carefully creating new project and solution templates with a non-default directory configuration.
Another could be tracking of work items and complex bug fixes.
Also it saves some ceremony and context-switching when editing files.
Advanced integrations may also allow to push the change management system's concept of "configuration" ("branch", "tag", "view") into the IDE.
ClearCase integration, however, is clearly not "advanced".
A lot of it is simply the preference and comfort level of the user. Some folks are comfortable with the command line. Some prefer a GUI.
I wouldn't make generalized assumptions that all version control within the IDE is bad or buggy based on experiences with a particular plugin which had issues.
Why even have an IDE? Why not just do everything with a command line? ;)
The answer is that having it integrated with the IDE is "better".
My #1 reason:
You can visually see if a file is checked out or not, and if you need to edit a file, you can take the action right there where you are working.
There are more, but that is the big one.
It's depend on your IDE and the way you work with VCS.
Me and my team using VSS plugin-ins inside Delphi IDE, it gives a lot of flexibable feature when working together for example, All our forms are check-in when you start to write a letter or move components it asked if you want to check-out the code file or form.
also when some one change any code in other forms, it pop up and telling you it's already update by someone else and asking you to update current files in your H.D.
and you just get everything while you are in the IDE, you don't need to move to other external file, or command prompt to do a simple task.
I find most people who like to deal with command prompt working mostly in code without GUI IDE or may I be wrong.
Nearly all of my subversion needs can be handled by the IDE interface. It's a lot faster to do 2 quick clicks than pop up a command line, cd to the right place, issue the command, etc.
Command line has it's place, but with the current crop of IDEs, that place continues to shrink.
I have battle scars from using a buggy implementation of an IDE/VCS integration. In all honesty, if it was not buggy it would have been great. As long as there are great tools like TortoiseSVN, I don't see a need for IDE/VCS integration. I'd rather have more tools that do their job well than a few buggy tools.
Version control support in an IDE generally gives you a better view. The IDE actually knows what type of file you are looking at when doing a diff, which means it can do context highlighting and help you do merges more effectively.
I also think it saves setup time. In stead of installing all kinds of tools, a developer can download the IDE, do a checkout an be on it's way. If every developer on a project uses the same IDE, they can help eachother.
"Counterproductive" is a large word. If you have serious CVS/SVN problems maybe once a month, it's still way to few to have complicated clients installed on all your dev machines.
I have both systems where there is an integrated IDE (Microsoft FrontPage against an IIS Development Web site with Visual Source Safe on all of the web content) and where there is not (java command-line development, Visual Studio Express Editions). An intermediate case that I use is jEdit 4.x with VSS integration via plug-in.
I think the integrated case is valuable for the reason it always is -- you don't have to leave your application to interact with source-control functions and you don't have to worry about remembering to add new files and to check out files before editing them. The ability to have a smooth work process and to minimize the risk of oversights is powerful, as far as I am concerned. Even when the IDE-plugin integration is less than perfect (the jEdit 4.x case), I still prefer it over not having it.
I also agree that having explorer integration on Windows, the case for Tortoise SVN, is also a great capability, even when IDE integration is available. This allows convenient operation without having to launch the IDE while also being able to launch from the explorer window into the IDE (depending on file type) or editor or make or whatever while operating in Windows Explorer.
And yes, the command-line interfaces remain valuable, especially for scripting of recuring-operation patterns.
I operate in many contexts. Having low barriers and fluidity of operation in all of them is to be prized.
I'm not sure I understand the question. IDEs by definition are integrated, meaning that they're supposed to help you avoid the need to get out of the environment for anything project-related. Version control obviously fits the bill.
If you're looking for more practical reasons, one is that IDEs can offer you awareness by the nature of their graphical presentation. Eclipse, for example, will present files and directories that have changed. With additional plugins or suites, you can ever get real-time awareness as soon as another user is editing the same file, helping you predict a merge conflict before it occurs. I'm not familiar with a commandline based mechanism.
I use intellij integrated with cvs on a regular basis and by far the best feature of the integration of version control inside the IDE is line-by-line indications of what is added, edited, or deleted along with easy access (mouse hover/tool tip) to the pre-edit changes.
This is all within the source code in a non-obtrusive way.
For the nuts and bolts of version control (checkin/checkout/update/etc) I sometimes use the IDE and sometimes use the command line.
The number 1 reason for an SCM integrated with the IDE is that it makes it more effortless to use it and eliminates the need to REMEMBER to check things out. Through experience I have seen that steps that developers construe as extraneous, which often encompases anything other than writing code, don't get done. Making them do extra steps increases the odds that developers won't bother with it and will work around the source control system