I'm customizing the standard "c.vim" syntax file in order to tune the visualisation of my C code.
I would like to distinguish the color of the "called functions" from the one of the "declared functions".
Exemple:
int declared_function()
{
int m;
m = called_function();
return (m)
}
I read in depth the VIM documentation, and millions of forums and google results, but all the solutions I tried didn't work.
To resume, I did this:
I defined a region in a recursive way in order to consider all the code within the braces:
syn region Body start="{" end="}" contains=Body
Then I defined through VIM patterns a general function syntax:
syn match cFunction "\<\h\w*\>\(\s\|\n\)*("me=e-1 contains=cType,cDelimiter,cDefine
I did this because I thought I could combine the two in a "if else" condition in the .vimrc file... but after a whole day of failing tests I need the help of someone, who can tell me if it's possible and how to do it.
Thanks everybody.
You're very close. First, you don't need the recursive definition, but contain all other top-level C syntax elements in it, plus the special group you'll define for called functions:
:syn region Body start="{" end="}" contains=TOP,cFunctionUse
Actually, scratch that, the default $VIMRUNTIME/syntax/c.vim already defines a cBlock syntax group.
Then, define a different syntax group that is contained in the cBlock group.
:syn match cFunctionUse "\<\h\w*\>\(\s\|\n\)*("me=e-1 contained containedin=cBlock contains=cType,cDelimiter,cDefine
Finally, link or define a different highlight group for it, so that it actually looks different:
:hi link cFunctionUse Special
You can put those into ~/.vim/after/syntax/c.vim, so that they'll be added automatically to the default C syntax.
Related
I want to compare c and XML files with Beyond Compare. But I want to detect if there are differences within a Block to the corrosponding on the other file and if there is a difference in a block I dont want Beyond Compare to Show the difference in the block, but handle it like this block is not in the other file. I Need this because in my files are certain Code blocks which are nearly the same but do have different Signalnames in it.
So for example i got a c file that Looks like this:
//1
functioncall(
Singalname1,
Singalname2,
Singalname3,
Singalname4,
Singalname5,
Singalname6);
//2
functioncall(
Singalname31,
Singalname32,
Singalname33,
Singalname34,
Singalname53,
Singalname36);
And a second file which Looks like this:
//1
functioncall(
Singalname1,
Singalname2,
Singalname3,
Singalname4,
Singalname5,
Singalname6);
//2
functioncall(
Singalname371,
Singalname372,
Singalname373,
Singalname374,
Singalname573,
Singalname376);
If I compare those two files with BeyondCompare it determines the difference within the second function call because the signalnames all contain a 7. But i want Beondcompare compare the whol functioncall an if there are differences in the functionCall to Show the functioncall beside empty space so i can add it eaily to the second file.
So not like this:
I want it like this:
I tried to add some comments with a begin comment and an end comment with a incrementing number in it something like this:
//begin1
functioncall(
Singalname1,
Singalname2,
Singalname3,
Singalname4,
Singalname5,
Singalname6);
//end1
And then adding a specific rule in beyond compare. Unfortnatly i did not manage to add this rule to beyond compare.
Furthermore Ithink the Code is not good with this comments in it.
Beyond Compare doesn't provide a method to do this. The best workaround is to use the right click Align With command to shift the function alignment.
Did you try the "Never align differences" checkbox in the Alignment tab of the session settings?
New to Doxygen and wondering can it be used to draw a graph showing what functions use a given global variable. I have been able to get call/caller graphs working for functions and want to do something similar for a hand full of variables.
REFERENCED_BY_RELATION = YES: In a Variable description it documents all functions which have used the variable and generates a hyperlink to these functions in the code. In the function documentation, this documents all functions being used in that particular function and also generates a hyperlink to the actual code.
REFERENCES_RELATION = YES: In a function documentation, this documents all functions that have called the function being described and also generates a hyperlink tot he code.
Although this is not a graphical solution (which would be way better), this is something one can definitely work with.
Following #DimitreNovatchev's article Programming in XPath 3.0, and using BaseX GUI as the test environment, I tried some of the examples that define functions that accept functions as parameters. E.g. with
let $compose :=
function($f as function(), $g as function())
(The rest of the code isn't relevant to this error, but you can see it as the third example under Function Composition.)
I get this error from BaseX:
Error:
Stopped at 43-compose.xpath, 2/39:
[XPST0003] Expecting 'as', found ','.
The point where the error was detected was on the second line, just before the comma. Apparently, the processor expects the $f parameter declaration to say not just that $f should be a function, but also the return value of the function.
I don't know whether it's right for BaseX to expect that or not. Presumably, Dimitre's examples tested successfully before he made that presentation at Balisage. Maybe something changed in the XPath 3.0 spec between that article and when BaseX was released?
OK, found the answer. I got an evaluation key for Saxon EE, so I was able to try another processor. For future reference, this was the command line:
C:\Program Files\Saxon>java -cp saxon9ee.jar net.sf.saxon.Query -s:"input.xml" -
q:"ex5.xpath" -qversion:3.0
Note that -qversion:3.0 is currently required in order to get any 3.0 functionality.
Saxon throws an error at the same point, but gives a helpful suggestion on how to fix it:
Error on line 2 column 39 of ex5.xpath:
XPST0003 XQuery syntax error near #... function($f as function(), $#:
function() is no longer allowed for a general function type: must be function(*)
I changed function() to function(*) wherever a general function type was wanted, and the errors went away, both in BaseX and in Saxon.
So apparently BaseX was correct (but Saxon's error message was more helpful, as is often the case!). Sounds like something did change in the spec recently. I haven't been able to figure out what the relevant change was, from the change log. But regardless of what changed, the spec currently says that a FunctionTest must have either a * within the parentheses, or an as after them. (This applies to declarations of parameters that are functions, but does not apply to inline functions themselves.)
An Example
Suppose we have a text to write and could be converted to "uppercase or lowercase", and can be printed "at left, center or right".
Specific case implementation (too many functions)
writeInUpperCaseAndCentered(char *str){//..}
writeInLowerCaseAndCentered(char *str){//..}
writeInUpperCaseAndLeft(char *str){//..}
and so on...
vs
Many Argument function (bad readability and even hard to code without a nice autocompletion IDE)
write( char *str , int toUpper, int centered ){//..}
vs
Context dependent (hard to reuse, hard to code, use of ugly globals, and sometimes even impossible to "detect" a context)
writeComplex (char *str)
{
// analize str and perhaps some global variables and
// (under who knows what rules) put it center/left/right and upper/lowercase
}
And perhaps there are others options..(and are welcome)
The question is:
Is there is any good practice or experience/academic advice for this (recurrent) trilemma ?
EDIT:
What I usually do is to combine "specific case" implementation, with an internal (I mean not in header) general common many-argument function, implementing only used cases, and hiding the ugly code, but I don't know if there is a better way that I don't know. This kind of things make me realize of why OOP was invented.
I'd avoid your first option because as you say the number of function you end up having to implement (though possibly only as macros) can grow out of control. The count doubles when you decide to add italic support, and doubles again for underline.
I'd probably avoid the second option as well. Againg consider what happens when you find it necessary to add support for italics or underlines. Now you need to add another parameter to the function, find all of the cases where you called the function and updated those calls. In short, anoying, though once again you could probably simplify the process with appropriate use of macros.
That leaves the third option. You can actually get some of the benefits of the other alternatives with this using bitflags. For example
#define WRITE_FORMAT_LEFT 1
#define WRITE_FORMAT_RIGHT 2
#define WRITE_FORMAT_CENTER 4
#define WRITE_FORMAT_BOLD 8
#define WRITE_FORMAT_ITALIC 16
....
write(char *string, unsigned int format)
{
if (format & WRITE_FORMAT_LEFT)
{
// write left
}
...
}
EDIT: To answer Greg S.
I think that the biggest improvement is that it means that if I decide, at this point, to add support for underlined text I it takes two steps
Add #define WRITE_FORMAT_UNDERLINE 32 to the header
Add the support for underlines in write().
At this point it can call write(..., ... | WRITE_FORMAT_UNLDERINE) where ever I like. More to the point I don't need to modify pre-existing calls to write, which I would have to do if I added a parameter to its signature.
Another potential benefit is that it allows you do something like the following:
#define WRITE_ALERT_FORMAT (WRITE_FORMAT_CENTER | \
WRITE_FORMAT_BOLD | \
WRITE_FORMAT_ITALIC)
I prefer the argument way.
Because there's going to be some code that all the different scenarios need to use. Making a function out of each scenario will produce code duplication, which is bad.
Instead of using an argument for each different case (toUpper, centered etc..), use a struct. If you need to add more cases then you only need to alter the struct:
typedef struct {
int toUpper;
int centered;
// etc...
} cases;
write( char *str , cases c ){//..}
I'd go for a combination of methods 1 and 2.
Code a method (A) that has all the arguments you need/can think of right now and a "bare" version (B) with no extra arguments. This version can call the first method with the default values. If your language supports it add default arguments. I'd also recommend that you use meaningful names for your arguments and, where possible, enumerations rather than magic numbers or a series of true/false flags. This will make it far easier to read your code and what values are actually being passed without having to look up the method definition.
This gives you a limited set of methods to maintain and 90% of your usages will be the basic method.
If you need to extend the functionality later add a new method with the new arguments and modify (A) to call this. You might want to modify (B) to call this as well, but it's not necessary.
I've run into exactly this situation a number of times -- my preference is none of the above, but instead to use a single formatter object. I can supply it with the number of arguments necessary to specify a particular format.
One major advantage of this is that I can create objects that specify logical formats instead of physical formats. This allows, for example, something like:
Format title = {upper_case, centered, bold};
Format body = {lower_case, left, normal};
write(title, "This is the title");
write(body, "This is some plain text");
Decoupling the logical format from the physical format gives you roughly the same kind of capabilities as a style sheet. If you want to change all your titles from italic to bold-face, change your body style from left justified to fully justified, etc., it becomes relatively easy to do that. With your current code, you're likely to end up searching through all your code and examining "by hand" to figure out whether a particular lower-case, left-justified item is body-text that you want to re-format, or a foot-note that you want to leave alone...
As you already mentioned, one striking point is readability: writeInUpperCaseAndCentered("Foobar!") is much easier to understand than write("Foobar!", true, true), although you could eliminate that problem by using enumerations. On the other hand, having arguments avoids awkward constructions like:
if(foo)
writeInUpperCaseAndCentered("Foobar!");
else if(bar)
writeInLowerCaseAndCentered("Foobar!");
else
...
In my humble opinion, this is a very strong argument (no pun intended) for the argument way.
I suggest more cohesive functions as opposed to superfunctions that can do all kinds of things unless a superfunction is really called for (printf would have been quite awkward if it only printed one type at a time). Signature redundancy should generally not be considered redundant code. Technically speaking it is more code, but you should focus more on eliminating logical redundancies in your code. The result is code that's much easier to maintain with very concise, well-defined behavior. Think of this as the ideal when it seems redundant to write/use multiple functions.
This question already has answers here:
Closed 13 years ago.
Possible Duplicates:
Formatting of if Statements
Is there a best coding style for identations (same line, next line)?
Best way to code stackoverflow style 'questions' / 'tags' rollover buttons
public void Method {
}
or
public void Method
{
}
Besides personal preference is there any benefit of one style over another? I used to swear by the second method though now use the first style for work and personal projects.
By readability I mean imagine code in those methods - if/else etc...
Google C++ Style Guide suggests
Return type on the same line as function name, parameters on the same line if they fit.
Functions look like this:
ReturnType ClassName::FunctionName(Type par_name1, Type par_name2) {
DoSomething();
...
}
WebKit Coding Style Guidelines suggests
Function definitions: place each brace on its own line.
Right:
int main()
{
...
}
Wrong:
int main() {
...
}
They suggest braces-on-same-line for everything else, though.
GNU Coding Standards suggests
It is important to put the open-brace that starts the body of a C function in column one, so that they will start a defun. Several tools look for open-braces in column one to find the beginnings of C functions. These tools will not work on code not formatted that way.
Avoid putting open-brace, open-parenthesis or open-bracket in column one when they are inside a function, so that they won't start a defun. The open-brace that starts a struct body can go in column one if you find it useful to treat that definition as a defun.
It is also important for function definitions to start the name of the function in column one. This helps people to search for function definitions, and may also help certain tools recognize them. Thus, using Standard C syntax, the format is this:
static char *
concat (char *s1, char *s2)
{
...
}
or, if you want to use traditional C syntax, format the definition like this:
static char *
concat (s1, s2) /* Name starts in column one here */
char *s1, *s2;
{ /* Open brace in column one here */
...
}
As you can see, everybody has their own opinions. Personally, I prefer the Perl-ish braces-on-same-line-except-for-else, but as long as everybody working on the code can cooperate, it really doesn't matter.
I think it is completely subjective, however, I think it is important to establish code standards for your team and have everyone use the same style. That being said I like the second one (and have made my team use it) because it seems easier to read when it is not your code.
In the old days we used to use the first style (K & R style) because screens were smaller and code was often printed onto this stuff called paper.
These days we have big screen and the second method (ANSI style) makes it easier to see if your brackets match up.
See HERE and HERE for more information.
First one is smaller in terms of number of lines (maybe that is why development -Java- books tend to use that syntax)
Second one is, IMHO easier to read as you always have two aligned brackets.
Anyway both of them are widely used, it's a matter of your personal preferences.
I use the if statement as something to reason on in this highly emotive subject.
if (cond) {
//code
}
by just asking what does the else statement look like? The logical extension of the above is:-
if (cond) {
//code
} else {
//more code
}
Is that readable? I don't think so and its just plain ugly too.
More lines is != less readable. Hence I'd go with your latter option.
Personally I find the second one more readable (aligned curlys).
Its always easiest for a team to go with the defaults, and since Visual Studio and I agree on this, thats my argument. ;-)
Your lines of code count will be considerably less with the first option. :)