Recently I've been working on some legacy code of some coworkers, using visual studio code I've been able to convert it so sane and readable C formatting. However, I'd like to fold some control statements as the ones written by my coworkers are at times larger than 100 lines.
In these lines I've added preprocessor control statements to enable and disable my changes.
In visual studio code I'm able to fold the code nicely, but it stops once it hits a preprocessor statement, at least the #ifdef and #ifndef.
As there is about 1 every 10 lines to fold one control statement I need to fold 10 times, kind of beats the idea behind it right?
I've tried looking for fold and collapse within the settings and some googling, but I can't find anything that might resolve my issues.
For example I have this snippet
if(true)
{
Some functions();
#ifdef DEBUG
Functions with debugging only();
#else
Functions without debugging only();
#endif
Some other functions();
}
I expect, whenever I fold if(true) that everything within this control statement is folded. This is what I'm used to and what will happen in vs2017 in Eclipse. This doesn't happen in VSCODE! Instead only Some functions(); is folded.
How can I get the VSCODE folding behavior to be similar to other IDE's?
It sounds like your editor is using indentation-level folding.
According to https://code.visualstudio.com/docs/editor/codebasics#_folding:
Folding ranges are by default evaluated based on the indentation of
lines. A folding range starts when a line has a smaller indent than
one or more following lines, and ends when there is a line with the
same or smaller indent.
Since the 1.22 release, folding ranges can also be computed based on
syntax tokens of the editor's configured language. The following
languages already provide syntax aware folding:
Markdown, HTML, CSS, LESS, SCSS and JSON
It's possible that there are plugins to support syntax folding for other languages. If not, as a workaround you can indent the preprocessor lines.
This is handled by C/C++ extension ms-vscode.cpptools.
You can force folding mark in options:
"editor.showFoldingControls": "always"
But unfortunately, there doesn't seem to be an option to fold and mask inactive code when opening source file like on Eclipse or on visual studio.
Related
I am new to C. I encountered an error message which involves unexpected "}". However, I checked the number of "}" with an editor and indeed they pair up.
Then I wonder if there is a compiler command, so the compilation can stop whatever I want? It will be convenient to have such tool as debug help.
Thank you.
(Edited in 29-10-2015)
I typically write my code with gedit. Nonetheless, since my work is mostly done on cluster, it will be troublesome to transport the files up and down. I must turn to nano, vi or vim which causes difficulty in debugging.
Stopping compilation partway through is rarely a useful feature. You'll want to see all of the errors that may exist in your code so you can fix more that just one at a time.
That said, an error such as a misplaced brace or parenthesis can cascade down and cause several more errors to appear. So if you see a long list of errors that don't seem to make sense when you look at the code, start at the top and fix that, then recompile to see if it took care of any others.
The answer is no compilers are all or nothing.
However, a good editor is recommended. For example, you can match brackets with the % command in vi, or if you have a color editor, you can visually see what's going on. A better IDE would even allow you to hide/show blocks of code, format it with proper indentation, and flag any compilation issues from static rules without actually compiling your code.
Does anyone know if Vim has any way to implement C Conditional Parsing like Source Insight?
comment out or gray out disabled branch?
remove cscope or ctag symbol that in disabled branch?
I've using cscope and ctag with vim to crawl C code. There are a lot of macros, and some code snippets have been disabled by macros. But Vim displays these snippets in the same color as the others. If the disabled code snippet could be shown greyed-out, that would be more convenient to read.
Also, when I search for a symbol or define with cscope, there are a lot of results, but many of them were already disabled by a macro. Is there any way to filter out disabled results?
With the ancient ifdef highlighting plugin, you can :Define or :Undefine preprocessor defines, and the corresponding blocks with be highlighted or not. Apart from that, I'll second #FDinoff's comment: Vim is a text editor, and there are no provisions for extending the tags handling and other lookups. Vim only has a basic understanding of a programming language via syntax scripts, not an entire compiler infrastructure like an IDE.
I am looking through some proprietary source code: sample programs in using a library.
The code is written in C and C++, using make for build system.
Each and every file ends in a commented out []: /*[]*/ for source files and #[]# for makefiles. What could be the reason for this?
The code is compiled for ARM with GCC, using extensions.
It is most likely a place holder for some sort of automatic expansion.
Typically something like macrodef (or one of the source code control filters) would expand such items to contain some relevant text. As typically only the comment-protected brackets would expand, the comments would remain in place, protecting the source code from actual expanded items at compilation time.
However, what you are currently looking at is probably the outer containing brackets with all of the internal expansions removed. This may have been done during a code migration from one source code control system to another. Although such an idea is highly speculative, it does not appear that they took the effort to migrate expansion items, instead of just removing them.
On one project I used to work, every C source file contained a comment at the very end:
/* End of file */
The reason for that was the gcc warning
Warning : No new line at end of file
So we had this comment (with a new line after it) to be sure people do not write after the comment :)
A project I'm working on (in C) has a lot of sections of code that can be included or omitted based on compile-time configuration, using preprocessor directives.
I'm interested in estimating how many lines of code different configurations are adding to, or subtracting from, my core project. In other words, I'd like to write a few #define and #undef lines somewhere, and get a sense of what that does to the LOC count.
I'm not familiar with LOC counters, but from a cursory search, it doesn't seem like most of the easily-available tools do that. I'm assuming this isn't a difficult problem, but just a rather uncommon metric to measure.
Is there an existing tool that would do what I'm looking for, or some easy way to do it myself? Excluding comments and blank lines would be a major nice-to-have, too.
Run it through a preprocessor. For example, under gcc, use the option -E, I believe, to get just the kind of output you seem to want.
-E Stop after the preprocessing stage; do not run the compiler proper.
The output is in the form of preprocessed source code, which is sent
to the standard output.
You could get the preprocessor output from your compiler, but this might have other unwanted side effects, like expanding complex multi-line macros, and adding to the LOC count in ways you didn't expect.
Why not write your own simple pre-processor, and use your own include/exclude directives? You can make them trivially simple to parse, and then pipe your code through this pre-processor before sending it to a full featured LOC counter like CLOC.
This question asks about a coding style checker, but the focus seems to be on indentation and brace placement. GNU indent deals with indentation (which isn't a problem in this code base, amazingly enough).
I'm working with a pile of code that is full of various naming schemes: camelCase, everythingruntogetherinlowercase, underscores_as_separators, SomeStructsEndWithT, etc.
I'd like to be able to pick a convention and at least have an automatic check that new changes are in line with the convention.
Is there a good tool for checking naming in C? Something like Python's pep8 checker tool, I don't want a beautifier.
Thanks.
It looks like Google's cpplint (a C++ style checker) can be hacked into submission for checking C like I want.
(I'm still interested in knowing if there are any better checkers out there.)
It is an unorthodox choice, but I'd go with cxref, if you are willing to put in half a days work. It is a cross referencer, comes with the source code, it has a clean parser and doesn't build a parse tree. Yet, with a few lines of code you can dump all the variables to examine them, or rewrite them to your favoured style (or if you are as lazy as I am instead of rewriting you could generate replace commands for emacs/sed). I only managed to build it for Mac.
This one has a number of answers already in this thread Coding style checker for C
from which Vera++ might be the most promising, since most of the other suggestions are formatters not validators. There's a webpage about running vera++ at
https://bitbucket.org/verateam/vera/wiki/Running.
There's a download from https://bitbucket.org/verateam/vera/downloads/vera++-1.1.1.tar.gz
Compiling presents a few issues:
sudo apt-get install libboost-dev tcl-dev
An include of tcl.h that should have been tcl/tcl.h
Need a full boost src tree, like that from http://sourceforge.net/projects/boost/files/boost/1.53.0/boost_1_53_0.tar.gz/download
The build command becomes something like: make BOOST_DIR=/home/fluffy/tmp/boost_1_53_0
vera++ needs a ~/.vera++/profiles/ but doesn't autocreate a default (it can be copied from the one in the distribution, however)
Finally, running it on a C++ file produced output like (with duplicate errors omitted for brevity):
../dllist.c:1: no copyright notice found
../dllist.c:4: horizontal tab used
../dllist.c:10: horizontal tab used
../dllist.c:10: closing curly bracket not in the same line or column
../dllist.c:29: horizontal tab used
../dllist.c:38: keyword 'if' not followed by a single space
../dllist.c:38: negation operator used in its short form
../dllist.c:40: horizontal tab used
../dllist.c:40: full block {} expected in the control structure
../dllist.c:42: horizontal tab used
../dllist.c:71: keyword 'if' not followed by a single space
../dllist.c:71: negation operator used in its short form
../dllist.c:72: horizontal tab used
../dllist.c:72: full block {} expected in the control structure
../dllist.c:73: horizontal tab used