Assuming I am only using Visual Studio Code as the editor, is there an advantage to include a .editorconfig file in a project if I already have workspace settings saved?
Or, a disadvantage: such as .editorconfig potentially overwrite my Visual Studio Code settings or vice versa?
TL;DR;
Basically, .editorconfig has advantages when:
you're working in a team
or
a way to preserve your settings, so you can easily use them in other projects in case you lose your existing IDE settings (e.g., customise stuff in your IDE but then format your computer)
More information
The .editorconfig file is usually committed into the code repository, so it can be used by multiple people working on the same repository. This enables you to have code consistency across all team members. You might like using tabs, but the rules are set to use spaces. Sorry, team rules override your personal rules. Consistency wins.
Visual Studio Code workspace settings (or any built-in IDE workspace settings) can be individually configured (per person) and thus could be different and make the files in the repository, inconsistent. You might use tabs while other people use spaces and it messes things up for everyone, because now you're all fighting on coding style(s).
.editorconfig files might require a third-party extension to work with your IDE (which is the case with Visual Studio Code) while IDE workspace settings are baked in to the IDE (no extra download(s) required). Note: Visual Studio (as opposed to Visual Studio Code) has this baked in.
IDEs usually allow you to 'back up' your IDE settings ... so it's true you can back up your settings and use them later on.
Not everyone in a team always uses the same IDEs. Again, means nothing if you're just working solo on something.
First off, .editorconfig only works in Visual Studio Code using a plugin. The advantage for .editorconfig is that other editors also recognize it. The advantage for Visual Studio Code workspace settings is that it doesn't require a plugin and can include more settings.
From what I can tell, .editorconfig takes precedence over user and workspace settings. Although I couldn't find an official statement on this (but also one hint is that they mention this not being true for one of the settings as a bug).
I would use .editorconfig for what I can and include the Visual Studio Code workspace configuration for the remaining settings. I'd avoid conflicting settings.
Related
I suddenly got this notification when open a flutter project in vs code:
Do you want to exclude the Visual Studio Code Java project settings files (.classpath, .project. .settings, .factorypath) from the file explorer? (options: Exclude Globally, Exclude in Workspace, Never)
I chose Never for the time being, but I was wondering what it even implies?
This is a prompt that comes from the Java extension from VS Code:
https://github.com/redhat-developer/vscode-java/blob/06793b174437fee55985c62917f08da926f37058/src/settings.ts#L73
I guess it's asking whether you want those java-related project files to show up in the VS Code explorer side bar, or be hidden (if you choose to exclude, it will write exclusions into your VS Code settings so they are hidden).
Can't find an simple, basic solution anywhere for this problem so I figured it was worth posting it here.
When I go to run my code as a task, I get the following message: "Tasks are only available on a workspace folder" - I can't find a solution anywhere and I'm a beginner at Visual Studio Code so I might need the answer / solution explaining in more simpler terms.
VSC Version = 1.17.0
Visual Studio Code treats the folder containing your program file as a workspace folder.
Your tasks created will be contained in a file tasks.json within a hidden folder .vscode inside your project or workspace folder.
So instead of opening the file directly to create a task, you need to open the folder as a project.
The "Workspace launch configuration" section of VSCode mentions:
With multi-root workspaces, VS Code searches across all folders for launch.json debug configuration files and displays them with the folder name as a suffix.
Additionally VS Code will also display launch configurations defined in the workspace configuration file.
Example of settings: vscode-tslint/vscode-tslint.code-workspace
As an alternative, you can have User level tasks to share them across projects since VSCode 1.42 (Jan. 2020).
But regarding workspace tasks, since VSCode 1.57 (May 2021), said tasks will have to be "trusted" by anyone opening the same workspace, assuming you have versioned and pushed the .vscode folder.
Safe code browsing
It's great that there is so much source code available on public repositories and file shares. No matter the coding task or problem, there is probably already a good solution available somewhere.
However, using open-source code and tools does have risks and you can leave yourself open to malicious code execution and exploits.
Workspace Trust provides an extra layer of security when working with unfamiliar code by preventing automatic code execution when a workspace is open in Restricted Mode.
When I programmed in Visual Studio, I used to open a Solution, then Solution Explorer showed me only projects contained in that Solution.
When I work in Eclipse, instead, Package Explorer always shows to me all the projects into workspace, which, often, is not what I want.
Is it normal? Or should it appear like Visual Studio? In the latter case how can I achieve it? Should I treat Eclipse Workspace the same as Visual Studio Solution? (e.g. one workspace for each multi-library project).
Yes, by default the Packages View shows everything.
You can change the view to arrange the top level by Working Set to split up the view.
You can also use Eclipse Mylyn to arrange things by task (Mylyn is included in some Eclipse downloads or can be installed separately).
I'm new to Eclipse, having done a lot of development in Visual Studio and XCode.
When I create a C++ project in my source tree the project explorer shows all the files in that folder and sub-folders. However there are lots of unrelated files that I don't want to see.
In Visual Studio and XCode I have to manually link source code to the project. This allows me to control the clutter of the project. Non-project files are "hidden" by default, because they aren't added to the project. In Eclipse everything is added by default. It seems that you can't decouple the file system's storage from the view you see in the project explorer.
Also I have a bunch of source in my tree that I don't want to compile as part of this project. Because it's for a different platform. I can't see how to remove these files from the compile list without also removing them from the file system.
Reading the docs hasn't helped much. What am I missing here?
There are 2 parts to this solution. First file name filters can be defined as described in this post:
Eclipse: how to hide custom files in Project Explorer
2nd the remaining files that I don't want compiled can be excluded by right clicking on them and Properties -> C++ build -> Exclude resource from build.
So it's more a negative space thing. In traditional systems, you have to explicitly add code to the project. In Eclipse you have to explicitly REMOVE code from the project. I prefer the old way because sometimes you want to include code from disparate regions on the disk and that just makes the all inclusive model of eclipse break. But I guess I'll cross that bridge when I get to it. sigh
Whenever I switch workspaces/Eclipse installs I need to copy/redo the preferences:
compiler settings;
font sizes/families;
code formatter;
java code templates;
editor templates;
code clean-ups;
I would like to maintain these settings in an unitary way, preferrably under source control. How can I do that?
I know about 'copy settings' when creating a new workspace, but it does not keep updated copies.
You could of course export/import those settings.
The other approach is to enable project specific settings for some settings.
We have a very small Git repository with those kind of files:
.settings/org.eclipse.jdt.core.prefs (compiler problem settings and formatter rules)
.settings/org.eclipse.jdt.ui.pref (cleanup rules, common code templates)
The common settings are just copied/merged in each projects .settings directory, ensuring common rules amongst all projects, whatever the workspace.
You could also try Workspace Mechanic. It works perfect for this.
http://code.google.com/a/eclipselabs.org/p/workspacemechanic/
Eclipse now ships with a tool called Oomph Setup. This tool can be used to record the preference changes that happen in your workspace, synchronize those preferences across multiple machines using an online service, and apply the preferences to both new and existing workspaces.
"Oomph" is actually a broader set of tools and low-level frameworks that are used throughout the Eclipse installation process, and it provides for very powerful automation possibilities, so the documentation is sometimes hard to follow for an end user who's just interested in simple preference synchronization. Here are a collection of links about Oomph Setup that I found helpful:
Oomph: A Matter of Preference -- Blog post providing overview of preference tool
Oomph Setup Documentation -- Official documentation
Automating Project-specific Eclipse Setups with Oomph -- Walks through how to set up Eclipse to have default settings for new workspaces and automatically update the settings for existing workspaces
You now have a good example of a separate project maintaining Eclipse preferences, as plugin.
See the saneclipse project from Lars Vogel.
You also have the associated vogellacompany/com.vogella.saneclipse repo, which will tweak and fine-tune the settings of:
com.vogella.saneclipse.preferences/.settings/org.eclipse.jdt.core.prefs
com.vogella.saneclipse.preferences/.settings/org.eclipse.core.runtime.prefs
com.vogella.saneclipse.preferences/.settings/org.eclipse.core.resources.prefs
com.vogella.saneclipse.templates/.settings/org.eclipse.jdt.core.prefs
com.vogella.saneclipse.fileextensions/.settings/org.eclipse.jdt.core.prefs
com.vogella.saneclipse.fileextensions/.settings/org.eclipse.pde.core.prefs
Check out Pulse Freelance Edition. It has the ability to sync workspaces (commercial).