VS Code seems to understand what it means to wrap multi-line comments differently from what other IDEs understand. For instance if I set Intellij to wrap multi-line comments at column 100, it breaks the line for me. But if I ask VS Code to do the same, it visually wraps the line but if I later open the same file in a simple text editor, I get one long line.
How do I get VS Code to auto break long comment lines?
Intellij:
/**
* Intellij will break this line
* at the correct location
* because I asked it to break
*/
VS Code
/**
* VS Code will wrap this line
at the correct location
but it's really one very
long line.
*/
I don't think VS Code provides native support for this.
There is an extension in the marketplace for this though: https://marketplace.visualstudio.com/items?itemName=stkb.rewrap.
Related
When writing a comment in Visual Studio code for Ruby code (e.g. simple text after #), hitting the Enter key does not automatically continue comment on next line.
Example:
# This is a comment I am writing. Now I hit 'Enter'.
I end up on this line without automatic `#` sign added.
Is there a standard way to have the comment continue automatically ? As in Typescript mode when using TSDoc format.
Note: I already use Ruby, Rubocop, Solargraph, Yard documenter, Better comments and Rewrap extensions. Rewrap is the closest since it moves to next line automatically. But still not the best for several paragraphs comments.
There are multiline comments in Ruby.
You can do them between =begin and =end.
Note: =begin and =end should come in the beginning of line. They don't work inside of text.
But according to the codestyle, the use of such comments is not recommended.
I typically work in another text editor and simply copy and paste my work into Stata's command prompt. However, I have noticed a difference between the way the command prompt and the do file editor handle comments.
The code below reproduces the things I have discovered:
mata
//test comment
/* test comment 2 */
end
//test comment 3
*test comment 4
/* test comment 5*/
When run from the do file editor, the code runs without issue.
But when I run it after copying and pasting into the command prompt, I receive a number of r(3000) errors in mata and r(199) errors in Stata.
The sole exception is that the * comments in regular Stata work fine in both interfaces.
I also see that the // comment in mata gives an "expression invalid" error message along with the r(3000) notification, but I only receive the r(3000) message when I use the /* text */ comment. In regular Stata, both comment types that are not * give "/ is not a valid command name" messages along with the r(199).
My main question is:
What is the reason behind this difference? Is there anything I can do to suppress these errors?
Also, this is something like a red flag for me:
Are there other behaviors that differ when I run things via the command prompt rather than the do file editor?
The following Technical Note from the 16th Stata manual about Do-files explains:
"...The /* */, //, and /// comment indicators can be used in do-files and ado-files only; you may not use them interactively. You can, however, use the ‘*’ comment indicator interactively..."
So there is nothing surprising here. You can easily prevent errors like these by following the conventions. Just read the relevant section of the aforementioned manual for more details.
Only StataCorp knows for sure, but such differences probably arise from how Stata interprets the code internally when this is parsed from a do file or the command prompt.
See the following post for another (unrelated) example of an inconsistent behaviour:
Stata axis labels off-center when broken over multiple lines
Personally, after using Stata extensively for years, i have not noticed any other major differences when running code from do files and interactively.
Similar to this question. I would like to find all commented files. But in my case /* */ is a possibility.
Apparently when you write changes to a database project, dropped objects are only commented out instead of deleting the file. I would like to remove all of these commented out files from the project.
Is is possible to find all files which start with /* and end with */?
Using Visual studio
Your regex is:
/\*([^*]|[\r\n]|(\*+([^*/]|[\r\n])))*\*+/
Use the following options in "find in files" (Ctrl-Shift-F)
This reference has even more options ostermiller.com/findcomments.html
I'm sure you could mod this to find the /// comment as well
Studio allows you to search with regular expressions so you could write a regular expression to find /* at the beginning and */ at the end of any file. I'm no regex wizard so I'm not sure of the exact syntax. Maybe something like /*.*/ would work?
Any regex gurus know the proper expression here?
I am refactoring a C++ codebase in Visual Studio 2005. I'm about half way through this process now and I've commented out a lot of old code and replaced or moved it. Now I'm searching to see that I have to change next but the search function keeps bringing me the old commented out stuff I no longer care about. I don't really want to delete that old code yet, just in case.
Is there any way I can search all files in the solution and get results ignoring what is commented out? I don't see a way in visual studio itself, is the perhaps a plug-in that would do it?
As the other provided solutions didn't work for me, I finally discovered the following solution:
^~(:b*//).*your_search_term
Short explanation:
^ from beginning of line
~( NOT the following
:b* any number of white spaces, followed by
// the comment start
) end of NOT
.* any character may appear before
your_search_term your search term :-)
Obviouly this will only work for // and ///-style comments.
You must click "Use Regular Expressions " Button (dot and asterisk) on your find window to apply regex search
In newer versions of visual studio .net regex is used which has a slightly different syntax:
^(?![ \t]*//).*your_search_term
My take:
yes you can use regular expressions, those tend to be too slow and thinking about them distracts from focusing on real stuff - your software.
I prefer non-obtrusive semi-inteligent methods:
Poor man's method:
Find references if you happen to use intelisense on
Or even better:
Visual assist and it's colored "Find all References" and "Go To" mapped to handy shortcuts. This speeds up navigation tremendously.
If you comment your old code with // you can use regular expressions while searching for something in your codebase. Something like this for example: ^[^/][^/].*your_function_name.*.
Previous answer gave a false-positive on cases where otherwise matching lines were placed on lines containing other source:
++i; // your_search_term gets found, don't want it found
So replaced the :b* with .* and added the <> so only entire words are found, and then went after some of the older C-style comments where there's a /* on the line:
^~(.*//)~(.*/\*).*<your_search_term>
In my case I was hunting for all instances of new, not amenable to refactor assistance, and boatloads of false-positives. I also haven't figured out how to avoid matches in quoted strings.
Just to add on, as I was doing a "find all" for division operator used in the code, used the below to exclude comments as well as </ and /> from aspx files:
^~(.*//)~(.*/\*)~(.*\<\/)~(.*/\>).*/
In Visual Basic within Visual Studio 2015, I was able to search for text outside of comments by adapting glassiko's comment from the most upvoted answer
^(?![ \t]*[']).*mysearchterm
And in C# you would use glassiko's comment exactly as it was
^(?![ \t]*//).*mysearchterm
Better use \s I think. ^(?![\s]*//).*your_search_term
delete the commented out code, it is in source control right? there is no need to keep it in the file as well.
I want to understand if code snippets are what I am looking for here.
I wind up writing the same line of code over and over during a refactoring.
Is there anyway I can create a shortcut that will spit out a line of code that I need?
Another easier option is to drag the code blocks that you re-use frequently onto the general tab of your toolbox area. You could even organize them with their own tab name and all.
alt text http://blogs.telerik.com/Libraries/MetaBlog/WindowsLiveWriter-VisualStudioTooltipsunpluggedDragandDro_EF10-generalTabDragged.sflb
Are you repeating the same line of code over and over on many different days?
Or are you encountering a situation where you have the same line to write many times as a part of a single task, but today's line of code will be different to tomorrows?
If you have the same line/block of code that you use often, a snippet is a good way to capture that in a reusable form (better, IMHO, than copy/paste because you can parameterise them).
However, if you're just looking for a quick way to repeat the same line that's come up now, check out Visual Studio's ability to record keystrokes.
Try this:
Put your cursor on a blank line inside a C# method.
Select Tools|Macros|Record Temporary Macro (often this is Control-Shift-R)
Type "example();" and press return
Select Tools|Macros|Stop Recording
You've just created a temporary macro that you can play back at any time - usually the keystroke for this is Control-Shift-P.
The key to this technique is that the macro records everything you do - with some practise, you can record edits to a line of code and repeat those edits on other lines.
I've used this in the past to create repetative code blocks - like assigning sets of properties from one object to another.
Depending on the code snippet, it would almost always be arguable that this line of code belongs in a util method, rather than copypasta.. But otherwise, yeah - a snippet is probably the best place.
Code Snippets sound like the right approach, although you could investigate Macros inside Visual Studio, which can be very powerful.
One advantage of a code snippet over adding it to the toolbox is that you can define the parts of the code that you want to change. I wrote a code snippet that generated something like the following code:
public class *className*Collection : List<*className*>
Where I only typed className once and it was automatically filled into the other parts.