It happens sometimes to switch between codebases using different strategy for indentantion, in term of using pure tabs or spaces instead of tab. Since each codebase reasonably want to preserve the coding style, the developer has to remember to switch to the proper setting each time he change the project he's working on. Is there some way to do this automatically, or having the setting saved as a property on the project/solution ?
VS, out-of-the-box, only supports per-user-per-machine settings, including code formatting.
There are third-party add-ins that enable per-project settings. This example add-in provides support for VS2008.
Another option is to perform the formatting externally, one option is "Uncrustify", which is blogged about here.
Related
Visual Studio's auto-formatting feature is quite useful in itself. However, it changes line breaks, which makes it difficult to find significant changes when comparing different versions of a source file in version control.
Is there a way to set it to affect only inline indentation and whitespace (which are filtered by modern compare tools)? I found some settings in 'Tools / Options / Text Editor / C# / Formatting / New Lines', but those only change how the code is formatted, they don't disable the behavior altogether.
Cheers,
Sandor
Not sure if this is what you need, but in File - Advanced Save Options you can configure the line endings that Visual Studio will apply when saving files. Thus, you can at least get a consistent behavior when saving.
For several reasons we prefer Nullable<Int32> over int?. Wherever possible we prefer Types over keywords - as we do so since C#2 we have a large codebase already using that style.
I recently switched to VS2015 and got the annoying light bulbs all over my code. For Int32 and other related non-generic types I fixed that by using this answer. For Nullable<T> however I cannot find the option to disable nagging.
How do I disable the IDE0001 Name can be simplified. for Nullable<T>?
In your project properties, under the Build tab, in "Errors and warnings", add IDE0001 to the set of suppressed warnings. I know this isn't really a warning (just a suggestion) but it's the same infrastructure. That removes the suggestion.
There is a feature-request here: http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/9139204-option-to-disable-quick-action-squiggles
concerning disabling the light-bulb. Please add your votes to this if you agree that it is important.
The answer was finally given for another related question:
You can disable analyzers on a per-project basis.
To do it, right click on Project>References>Analyzers in the Solution Explorer and hit Open Active Rule Set
Here you'd need to disable IDE0001 Simplify Names under Microsoft.CodeAnalysis.CSharp.Features.
Additionally you can set Tools > Options > Text Editor > C# > Code Style > predefined type preferences for For locals, parameters and members and For member access expressions to Prefer framework type and Refactoring Only (default). This however is a machine specific config setting.
In VS, to use snippets (for example auto-implented property) I typed "prop", then hit TAB twice.
However R# (I'm using R#6) inserts the snippet after ONE tab, causing me to always mistype something.
Is there an option somewhere, where I can set it to use two tabs?
Unfortunately there's no way that I'm aware of that would let you reassign deployment of ReSharper live templates to two tab hits instead of a single hit.
However, until you've got used to the single-tab deployment, you can Shift+Tab to go back to the previous template hotspot, which prevents messing things up.
Another option would be to selectively turn off ReSharper live templates that conflict with Visual Studio snippets that you're used to deploy on a regular basis.
To do that, go to ReSharper > Live Templates, and in the Templates Explorer, under Live Templates, either deselect "Predefined templates" altogether or expand this category and turn off selected templates - in your example with "prop", you should turn off ReSharper's "prop" and propg (the latter is under "Imported Visual C# snippets")
How do I transfer the window layout in Visual Studio 2010 from design mode to debug mode? I have a window layout I am fairly happy with in design mode, and would prefer to not have to do all that work all over again just to change a few details in it.
I found some questions that were kinda-sorta about this, but not quite.
Any suggestions? I know about import/export settings and use it religiously (switching between single-monitor and dual-monitor window layouts) but that doesn't really help me in this particular situation, as far as I can tell.
VS shell's ViewManager serializes the window profiles in your %AppData%\Microsoft\VisualStudio\10.0 directory in *.winprf files (which are basically just XAML files).
There are 5 profiles: Debug, Debug-Fullscreen, Design, Design-Fullscreen and NoToolWin (when no solution is open). You can experiment with replacing your Debug*.winprf with your Design*.winprf.
Please note that any manual modification of these files is entirely unsupported, so if you break something, you're totally on your own here.
Export your settings:
Choose General Settings/Window Layouts (in VS 2013) and save the file.
Open the file in an XML editor (or whatever... it's an XML file)
Find /UserSettings/Category/Design/WindowProfile and copy the entire node.
-- This assumes your Design view is the one you want to use for both modes.
Find /UserSettings/Category/Debug/WindowProfile and replace it with the one you copied from Design.
Save and re-import.
I have one of these settings files for home, remote, and office.
For C# Visual Studio uses 4 spaces by default, whereas for C++ it is hard-tabs. Why is it so? Why is it different?
My project consists of both C# and C++ code and the difference really annoys me. I want to set a common standard for all the sources, but I wonder if this would have any drawbacks.
If you're looking for a completely logical, well reasoned justification for this difference I don't think you'll find one. Despite the many flame wars around tabs vs spaces there really isn't a real winner (otherwise the war would be over).
The way to get around this is via a .vssettings file. When I first started with VS 2005, I set the tabs/spaces default in each language. You can do this via Tools -> Options -> Text Editor -> (C#/C++). Then I export the tab settings into a .vsssettings file. Whenever I install VS on a new machine I just import that file and I have my happy space/tab settings.
PS: spaces rule :)
Of course tabs is the only right way. Tab can do everything spaces can do. Spaces cannot do much of what tab can do.
Tabs allow easy change of indentation and easy navigation without having to press arrow keys too many times, and would having to hold control.
The real solution is to have the editor be able to navigate and tab indented file as if it was space indented, if the user prefers so. The file would be saved with tabs. Very simple and accommodating everybody.
The problem in c# 2010 is that I cannot find any option to change it to tabs.
I doubt there are any drawbacks as C++ grammar doesn't distinguish between tabs and spaces.
By the way, I think the best way to set code style standards is to export VS settings and share it with the team.
The reason behind C#'s default 4 spaces is that whoever will open the file the indentation will be the same.
You are free to change it as you like in preferences.
Just go with whatever you prefer, I normally use tabs in C++. Those who view my code all use the default VS settings RE tabs anyway so there is no real pull to replace that with spaces. I'm not sure what its like now but when F# was in its infancy (i.e., pretty early release out of MSR) you needed to use spaces in #light code otherwise the compiler would complain as whitespace was important.
Different people have different preferences, I know some who religiously use spaces, on the other hand I know more that uses tabs.
For C# Visual Studio uses 4 spaces by default, whereas for C++ it is hard-tabs. Why is it so?
Why not?
Just change it if you're not happy.
Spaces make it more difficult to navigate through code with the keyboard.
With spaces, most people will use four spaces, but some will use two or three. With tabs, the people who want their code tabbed out with two spaces can simply set the tab character to display as wide as two spaces, and the coding style remains consistent.
If you're using spaces for tabs in any HTML, CSS, or JavaScript, you're doing it wrong. There's no tabs-vs-spaces debate for html/css/js - it's either tabs, or ignorance. Client-side code is not compiled, and IIS doesn't have compression turned on by default - excess white space = excess fat.
Way back when, VB6 didn't give us the choice to use tabs, but now we can and should - if you don't, your code makes it look like you're still clinging to old-school ways.
So stop coding like it's 1999. Use tabs. Do it for the children.
The tabs vs spaces argument has a simple answer: tabs. Tabs allow you to specify your indentation while not forcing others to live with it. Given that tab sizes are merely a personal preference, one user shouldn't be able to force others to follow his/her display options.
Why the difference between C++ and C#: no clue. However, knowing that tabs are logically a better option, just change the C# (and in fact, all languages) to tabs and voila.