gcc 4.6.0
GNU Emacs 23.2.1
I have some c code and at some point I must have made a typing mistake. And now I am left with unbalanced curly braches or a parentheses.
I have about 2000 lines of code and I am just wondering is there any technique for finding them?
Emacs has some good features, so I am just wondering is there any way it can scan the code and tell me where they are. Currently I have a compile error related to this.
Many thanks for any suggestions,
In emacs you can use M-x check-parens . See http://www.gnu.org/software/libtool/manual/emacs/Parentheses.html
I would suggest adding "#ifdef 0 .... #endif" around blocks of code until the source compiles. Keep adjusting the size of the ifdef'd out code until you narrow down a chunk that compiles when ifdef'd out and doesn't otherwise. This chunk will contain the unbalanced brace.
Personally I'd start by ifdefing out almost the whole file and moving my "#ifdef 0" ahead each function until I started seeing compilation errors.
If you have crazy long functions then take the same sort of approach but within the function that's giving you trouble (once you've determined which function it is).
One good point to start is selecting all (M-x select-all) and then indenting the code (M-x indent-region). As emacs does a very good job indenting, you'll notice where the indentation failed.
Also, using show-paren-mode (M-x show-paren-mode) emacs will show you the matching paren of each ending paren (and vice-versa), so you can go through your code.
If you want something more fancy than plain highlighting, you could use rainbow delimiters: https://www.emacswiki.org/emacs/RainbowDelimiters
Here is a short blog post on it: http://emacs-fu.blogspot.com/2011/05/toward-balanced-and-colorful-delimiters.html
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.
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
At one point in time I was running Emacs with an option which auto-commented ending braces with the label for the block they were closing (function name, if (condition), etc). I have since lost said option, and have spent several days searching for it. Is anyone familiar with an option, minor mode, or elisp snippet that accomplishes this task?
Verilog mode does this. I'm not familiar with Lisp, but as far as I understood the code the magic is done in verilog-label-be.
There is someone in my team that swears by using some kind of GVim feature to do manually code folding.
As I'm using another editor and do not really need the folding feature, I think it only pollutes the source code with tags like:
/* {{{1 */
Convincing the person not to use this folding is not an option (got into some heated discussions before).
I'm not really a GVim guy, I'm wondering if there are not any other ways to do the folding without changing the team's code?
Maybe putting the folding directions in a separate file, or
Doing some kind of smart folding that takes the syntax of the programming language into account without changing the source code?
I would imagine he could just add the following to his .vimrc:
set foldmethod=syntax
Assuming he is using a version of VIM that supports that. :)
It only took a Google for "vim folding" to discover that Vim supports six fold methods.
syntax, indent and diff all mean that the user has little control over where the folding happens. That may or may not be a problem.
marker is a problem for you because you don't like the markers.
expr had a little of each of those problems, depending on the expression you create.
If your man wants to define his own fold points, and store them in an separate file, it seems like set foldmethod=manual combined with :mkview and :loadview would do the trick.
You should try it yourself. Once you start using foldmethod=marker there is just no going back. I am working on a project now where I can't use marker folding and it feels like washing clothes in a time before there were washing machines.