In Visual Studio, I have a block of code. I highlight it and use Ctrl+k+c to comment out the block. That adds "//" at the start of every line I highlighted. I then try to submit my code... and I run into StyleCop rule "SA1005" that requires all // to be followed by a space or be changed to ////. I would really like to modify Visual Studio so that ctrl+k+c adds "// ". I have not found any extensions or options that make that happen. Does anyone know of a way to do that change (short of writing my own new VS extension)?
My coworker tells me that you can also just hit Ctrl+K+C Ctrl+K+C (that is, apply commenting twice), and it will do ////code. That will pass StyleCop. Do the uncomment shortcut key twice to undo. Apparently, StyleCop doesn't care if there's a space after four slashes, only after two.
It seems some people really like this rule behavior. People will comment out code with a single set of // if they are playing around with stuff but do not want to forget and check it in that way. SA will fail and the code will not go in. Once you really mean to comment out of the code and check it in, then you comment it out again and you are good to go. This, they claim, has saved many from a bad check-in.
You don't need to write your own VS extension, there is already plugin GhostDoc that we are offering - you are welcome to use the free version - and it will generate StyleCop compliant XML Comment templates (which you can tweak too). GhostDoc also generate the comments on triple-slash (///) just like the VS does.
Related
I can't seem to be able to suppress warnings in my solution in Visual Studio 2017 by going into Project Settings > Build > Suppress warnings:
Even when I clean - build, rebuild, etc... the solution, Visual Studio keeps bringing up these warnings for me.
I brought this up with a visualstudio.com report yesterday and it's "triaged" at the moment. Is there an alternative way to suppress warnings in the solution, without marking every single reference?
Version: 15.6.2
Update:
This is wierd.
Visual Studio 2017 uses a semicolon by default, but comma worked.
The way I do it solution-wide is to create a specific suppression file, for instance GlobalSuppressionsForTestProjects.cs, in a convenient solution-level location.
Then for each project of the solution where I want the suppression definitions applied, I add a link to the suppression file:
right-click on project -> Add -> Existing Item
in selection dialog, navigate to the suppression file
click on Add as Link
I learned this trick from this post where the same way was applied for AssemblyInfo.cs files.
I usually use pragma directives:
#pragma warning disable 1591
// whatever member is lacking xml comments, or even the whole file
#pragma warning restore 1591
Verbatim from the link above:
disable: Do not issue the specified warning message(s).
If you really want to disable warnings solution-wide, there's no way to do it.
All compilation options are specified on the project level. MSBuild exists below the level of solutions.
But it can be done project-wise, just like you were doing above; the only thing I would change is separating those codes using a comma and not a semicolon like in your picture (and without a comma in the end), e.g.:
1591,1701,1702,1705
That's because compiler options use a comma.
You may just need to restart Visual Studio. This worked for me, and FYI we do not need to include the CS part of the error in your textbox (it would still work as written though, but you only need the number for this.) You have certainly restarted VS in the years since first asking the question, but for anyone having this problem today, I hope this helps.
I had the same issue with the same warning (CS1591). So for "Suppress warnings" in the properties to actually work (rather than the #pragma solution which is a legitimate work-around but might be unnecessary keyboard time after a restart) you might just need to restart Visual Studio.
I would like to have a way to auto-format specific code in Web Essentials to suit our internal design rules. So, for example, when a user types a hex code with lower case letters, it will automatically set all letters in the code to upper case. I've been searching around for a solution to this but I can't seem to find anything or know if it's even possible.
For clarity, I would like to "write" a set of rules (ideally to a file that could be distributed) that people could use to auto-format their code.
In addition to this, is it possible to output a block of code from a smaller, pre-defined string of text. So, for example, instead of writing out:
/*------------------------------------*\
Tables
\*------------------------------------*/
the user could write:
section Tables
and have it output like above.
Thank you in advance.
JetBrains Resharper is my opinion the best tool for Visual Studio that can help with all of this (and much more). Some find it expensive and might slow down Visual Studio somewhat if you're using an older computer.
https://www.jetbrains.com/resharper/
Case: One source file has a comment in it that is directly linked to a comment in another source file (it says see line 315 in xxx.cs for more information). The problem with this approach is that the comment on line 315 may not be at that line number in the future. Is there a way to link comments together in an IDE? (currently using Visual Studio 2010, but use other IDEs from time to time)
You can try this addin (I haven't used this):
http://hyperaddin.codeplex.com/
Besides this addin, the only thing I can think of is using a file link to directly go to the linked file; something like:
// ...
// See file://path_to_file
//...
The link will be converted to an actual link that you can click using Ctrl+Left Click but it won't take you to a given line number - it just opens the file.
The path can be a relative file path or a full file path - full paths work best if all team members use the same folder structure in the project. For example:
// file://w:/projects/GUI/frmMain.cs
Referring to a particular source file and line number is never a good idea, because someone might move things around in the other file without being aware that something is pointing at it. It's better to point at the particular type/method, for example See DoThings() in the MyThing class..
In Java, using Javadoc, you can use #link to do this, for instance See {#link MyThing#doThings()}. Eclipse will automatically update these when using its refactoring tools (e.g. renaming the class or the method). If the change is done manually, Eclipse will still warn that the target of the #link is invalid. (There is also #see which is more appropriate in some situations.)
I'm not sure about C# and Visual Studio, but it's likely that its XML-based doc format offers similar functionality.
The only way to handle this is to put the comment in the same file. Duplicating a comment is not the same as duplicating code, although ideally the code wouldn't need too much explanation in comments.
There are many, many reasons why the comment being in another file will cause pain. As you have stated, the line number may change but also it could be deleted (as they won't know another comment references it), updated in a way that changes its meaning and it is annoying to have to open another file in any case.
During step-by-step debugging, I often use "step into" to halt at every line in the section that I am debugging, to see all my code that's executed.
But library calls can disrupt this work flow: The debugger will jump into some STL file and continue there. I then have to press "jump out" to go back to my own code.
Is there a way to prevent the debugger from opening STL source files? A blacklist or a setting somewhere? I work with native C++ code. The "only my code" debugger setting unfortunately only works for managed code.
good question, the debugger constantly jumping into everything is indeed a huge slowdown and distraction during debugging. Luckily there's a solution:
open your registry editor, navigate to
HKLM\SOFTWARE\Microsoft\VisualStudio\10.0\NativeDE\StepOver
(add \Wow6432Node after SOFTWARE if you're on a 64bit machine, this casued me headaches in the past).
Add a new String Value (REG_SZ). The name is not so important, I used NoSTL for clarity and set it's value to
std\:\:.*=NoStepInto
This tells the debugger to not step into anything matching that regex so it will skip every function (global and class level) in the std namespace.
By using StepInto you can add overrides for specific methods, and you can still use breakpoints off course. It's also handy to add some of your own methods that get stepped into often but of which you know the result by head.
Here is a more detailed explanation, google on NoStepInto for more scattered information.
The answer is as above mentioned, but in case you use VisualStudio 2017 or it didn't work for you, then try the following:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\Packages\Debugger\Visualizers
Open the following file with notepad or whatever you have:
default.natjmc
and add this line:
<Function><Name>std\:\:.*</Name><Action>NoStepInto</Action></Function>
The 'name' means the value of the registry key in that file and 'action' is self-explanatory.
If you want to add the registry key too, (not sure if it is necessary), then you will find it here:
\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VSTA\8.0\NativeDE\StepOver
At least, that was the path in my case. It took a good hour to find these, so I hope that it will help somebody.
Remove the 'Wow6432Node' if you have 32bit machine, as above mentioned.
You don't use F10/F11/Shift+F11??? Those are "step over", "step into", "step out", and there are many more that are useful. Much more usable than hunting for buttons, and you never have to take your eyes off the source code.
In general you're well served by using keyboard shortcuts in Visual Studio instead of the mouse. Not just for debugging, but everything. Learn 'em, you'll love 'em! You probably can't learn them all at once, just pick a few functions you use often, get used to them, then start on a different set. It becomes second nature over time.
Sorry that this is off-topic, but your original question was beautifully answered by the previous poster already, and I thought I'd help with something else :)
I'm interesting with statistic and motivation of using task list in VS. Why are you use it or not? Some people i asked even want a tool, that can synchronize VS ToDo with Outlook. What do you think?
IMO you can use Todos for:
Remember that you must do something like "Todo: implement this interface"
To mark a line/block of code as instruction for another coder if your are code in a team like "Todo: you can use foo instead of bar because ..."
If you review your code you can mark any code that he can be improved like "Todo: use Linq instead of foreach"
You can replace the default tasklist-window from visual studio with plugins:
Tasklist replacement for Visual Studio
http://genne-develop.com/
I used TODO for two purposes:
To mark enhancements that can be
done at a later stage. So whenever,
there is slack time, you can pick
one of them out of your pending TODO
list.
Things that are still need to be done while I am coding - so that I can re-visit those places and fix them. This is something like bookmarks except they are visible to other folks even if I forgot to fix them.
I use TODO comment syntax - it's there in code and not in .suo file as mentioned by Benjol.
I use TODO sparingly - only when I have something that I'm not the master of (something another team-member is working on etc.). I treat it as I treat bugs - max 5 at any time.
If I need scaffolding - I create temporary classes with Fake as a prefix in the class-name.
I guess, I don't want my production code to also act as my scrum-board/task-list.
One thing to be wary of about Task Lists in VS is that they are stored in the .suo file, which (I believe) most people tend to exclude from source control.