I always follow the existing coding conventions of whatever language I am using and I have started doing C recently. I have noticed that some books display functions with the return value above the rest of the function signature, like this -
int
foo(int bar)
{
...
...
...
}
I haven't seen this in any other languages I've used. Is this the standard way of presenting C functions these days or is it some old convention that is not in general use anymore?
There are no universal conventions for code formatting in C. The popular styles are named by a project (such as "Linux kernel") or organization (GNU) or book (K&R), or stuff like that.
Wikipedia has a list of styles.
It is more to do with getting things like ctags to work effectively. Or, being able to find the function body itself (rather than any call to it) by simply doing a search for lines starting with funcname.
Ex: /^funcname
As long as you use any reasonable indenting style after that, it will be the only place (across an entire code base) where it appears at the very beginning of a line that way.
you can see this in the Indian Hill Style manual 1990 http://www.cs.arizona.edu/~mccann/cstyle.html.
It is just a matter of style and mostly habit. Compiler does not care about that. Use a style in which you are comfortable and something that others easily follow while reading your code.
Related
From Programming Language Pragmatics by Michael Scott
Modern versions of C and C++ include a namespace mechanism
that provides module-like data hiding
Does C have namespaces similar to C++?
Are the "identifier name spaces" mentioned in C in a Nutshell the "namespaces" mentioned in Scott's book, and similar to namespaces in C++?
Thanks.
No, C does not have a namespace mechanism whereby you can provide “module-like data hiding”.
book quality
I do not know anything about the book you cited, but the word “namespaces” is one of those that gets overloaded to a lot of different meanings, just like “window”. (I question the validity of anything the author says for getting such a major point about one of the world’s oldest and most widespread computer languages so brazenly wrong.)
name spaces in C
“Name spaces” in C are a completely different mechanism, working for a completely different purpose. These are the name spaces discussed in “C in a Nutshell”. The words mean something different than C++ namespaces. Since David Rankin bothered to lookup chapter and section referencing the C11 Standard, these are the name spaces used in C:
label names
struct/union/enum tags
struct/union members
everything else (including enum values)
a quick blurb about scope
Keep in mind that this says nothing about scope, which is a separate mechanism. For example, a global variable and a variable local to a function may have the same name; nevertheless they share the same name space. The difference is that the global’s visibility is obscured by the local variable.
value of namespaces in C++
It is still unclear whether namespaces were a very useful extension to C++, and the argument as to its righteousness continues. The C crowd (mostly) agrees that the headache that adding namespaces would involve doesn’t justify the ends. I couldn’t find anything particularly useful on the interwebs right off the top of my keyboard, except for a couple of bland blurbs about emulating them using structs or (even worse) using macro abuse. If you really want to dig, you could probably find some useful discussions archived on the comp.lang.c newsgroup.
No, C has nothing like C++ namespaces. Most people have to fake what C++ does using a kind of underscore notation at best. This is at least what I do instead of trying to pack things into structs. Your IDE will still help with code assists, you just have to get used to using the underscore instead of a . for everything
C++
MyNamespace::MyObject.myMethodOrVar ...
Ends up looking like this in C
MyNamespace_MyObject_myMethodOrVar
May not be as smooth as C++ or Java, but it works and still helps avoid name collision. It's just a pain in the ass.
And yes, this doesn't give you syntactic devices like use. It is what it is I'm afraid.
I'm interested in following the correct naming conventions when writing an extension for ruby in C. Specifically I'm referring things such adding _p to function names of predicates and prefixing variables with m for module, c for class etc.
For example, if we want to define a predicate method like the following in C, we should use _p as a suffix in the function that defines the method.
class MyClass
def awesome?
true
end
end
In C:
static VALUE my_extension_my_class_awesome_p(VALUE self) {
return Qtrue;
}
void Init_my_extension(void) {
VALUE cMyClass = rb_define_class("MyClass", rb_cObject);
rb_define_method(cMyClass,
"awesome?",
my_extension_my_class_awesome_p,
0);
}
Looking through the core Ruby source code I see suffixes for _p (predicate) and _m, which I'm not able to infer a meaning from. I'm sure there are a number of other conventions.
There are additional naming conventions, such as when to use underscores and when to use camel casing. It would be easy to create a mess without a guideline to follow when writing an extension with a substantial amount of C code.
Is there a definitive list somewhere? I never seem to turn up useful results when googling for Ruby C extension topics. Any quick examples that show the pure Ruby syntax and the equivalent C function named correctly?
Here are a couple more: http://geoffgarside.co.uk/2007/05/20/ruby-c-extensions-nested-modules-classes/
Geoff Garside has a couple dozens repos written in ruby/C. He's pretty credible IMO. https://github.com/geoffgarside
I will keep looking for more and edit this post when I do find more.
EDIT
It looks like it's hard to find someone who wants to talk about ruby extension naming conventions... Maybe you could try sending a tweet/email in M. Garside's direction. He looks pretty active on twitter.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
What are the most common naming conventions in C?
Is there a official (or widely used) naming convention for the C language after all? One like Java's naming convention (UpperCamelCase case for classes, lowerCamelCase for methods, etc)?
I've seen many different conventions, like variable_name, variableName, variablename, etc. Is there one that is used by most C programmers?
EDIT: Just to make it clearer, the question is if there is or there is not mostly used naming convention. Like one that programmers don't have to think about (like Java's, or C#'s).
In the style of the C standard:
Variable, function and struct naming schemes are undefined.
Use whatever style you prefer for your own new projects, keep consistent style within other codebases.
Personally I use camelCase - less use of shift and no annoying type encoding into variables, any decent IDE should be able to tell me what type a variable is.
Depends, e.g. if you write code in the linux kernel use snake_case.
See coding guidelines for the kernel.
If you're working on existing code, follow the existing naming convention used in that code. The only thing worse than a bad naming convention is a mixture of inconsistent naming conventions. (The same applies to brace styles, indentation level, and so forth.)
If you're writing new code, I'd personally recommend looking at the sample code in K&R and the C standard, but it's up to you.
One of the classes I'm taking in college is where we are doing a ton of programming in C. We are supposed to use 'C' style naming conventions in the assignments or get docked marks (eg a variable is named like int line_counter, a function clear_array() ) I find this convention really really annoying esp coming after a year of Java where such things are named more conviniently like lineCounter or clearArray(). Underscores are annoying, a hassle to type and increase the amount of syntax errors. Why should this convention be followed? Is there some logic to it or some point behind it? Or is it just another trick to make 'C' even harder to write code in?
Style naming conventions are a matter of tradition, local agreement and uniformity. You have to get used to a different style because there's no guarantee, once out in the job market, that you will use the code convention you like. In this sense, the point is that you have to learn that the Java style is not the only style you will ever deal with.
On regard if it's a good decision or not, it's hard to decide. I am annoyed by styling violations as you are, even if I have tens of year of experience in programming, but you cannot really pretend to reform an old code to new conventions. It takes a lot of non-productive time and screws everything for the other programmers.
You can mitigate the problem of slow-to-type-underscore using tab-completion in your editor (e.g. vim). Writing a method will just become typing a few letters and pressing tab. It's unlikely you will hit an underscore in the first letters.
Getting used to a specific style convention is just a question of the number of lines of code you have written. In this case, that that you find annoying in C because you were used to Java, is also a convention in Python: Contrarily to you (I program mostly in Python), I like better the underscored variable names (although I understand the java ones are also very clear to read)
On the other hand, and as a curiosity, you probably know that the difficulty to write a given character depends on the local distribution of your keyboard. Many of the symbols used in C are a hell to write with, for example, a Spanish keyboard.
What I think it is a really bad idea, is not to use the standard conventions for the language and develop a custom convention. This is really bad for others and also for you because all the documentation, code etc you have to study or interact with will be written in the standard style for the language
There is no such thing as "C-style naming conventions"; you will find quite a number of different styles both in C code and in C++ code. That said, you will just have to suck it up and go with the convention required by your professor. The purpose of style conventions, in general, is to reduce errors and to make it easy to infer information about a symbol without needing to look up its declaration. That said, there are many differences about which style or styles are best. Having a consistent style, though, is important for the understanding of the code base as a whole, and it is probably easier for your professor to grade and understand the homework if it is all written using the same, consistent style.
Pretty much any company you work for will require you to adhere to the company's coding convention, so it is not unreasonable for your professor to have similar requirements. Although it took some getting used to Google's C++ coding conventions when I first started, it is undoubtedly a boon to the code's readability to be in a consistent style. Nothing is more unintelligible than a mix of different styles.
I disagree with your teacher's decision to dock points for capitalization, but you're going to have to follow his or her instructions.
Grades are intended to reflect understanding of the material. I personally found it sufficient when teaching introductory C courses to grade on understanding. Beginners have enough difficulty mastering language constructs. It is unnecessary and cruel to dock points for trivialities.
The merits of your teacher's particular style, or of following a corporate style, are separate questions.
We are working on a game engine written in C and currently we are using the following naming conventions.
ABClass object;
ABClassMethod(object, args)
AB Being our prefix.
Our API, even if working on objects, does not have inheritance, polymorphism or anything. All we have is data types and methods working on them.
Our Constants are named alike: AB_ConstantName and Preprocessor macros are named like AB_API_BEGIN. We don't use function like macros.
I was wondering how this was fitting as a C API. Also, you may note that the entire API is wrapper into lua, and you can either use the API from C or lua. Most of the time the engine will be used from lua.
Whatever the API you'll come out with, for your users' mental sanity (and for yours), ensure that it's consistent throughout the code.
Consistency, to me, includes three things:
Naming. Case and use of the underscore should be regulated. For example: ABClass() is a "public" symbol while AB_Class() is not (in the sense that it might be visible (for whatever reason) to other modules but it's reserved for internal use.
If you have "ABClass()", you should never have "abOtherClass()" or "AbYet_anotherClass()"
Nouns and verbs. If something is called "point" it must always be "point" and not "pnt" or "p" or similar.
Standard C library, for example, has both putc() and putchar() (yes, they are different but the name doesn't tell which one writes on stdout).
Also verbs should be consistent: avoid having "CreateNewPoint()", "BuildCircle()" and "NewSquareMake()" at the same time!
Argument position. If a set of related function takes similar arguments (e.g. a string or a file) ensure they have the same position. Again the C standard library do a poor job with fwrite() and fprintf(): one has the file as the last argument, the other as the first one.
The rest is much up to your taste and any other constraint you might have.
For example, you mentioned you're using Lua: Following a convention that is similar to the Lua one could be a plus if programmers have to be exposed to both API at the same time.
This seems standard enough. OpenGL did it with a gl prefix, so you can't be that far off. :)
There is a lot of C APIs. If you are creative enough to invent a new one, there's no "majority" to blame you. On the other hand, no matter which way you go there are enough zealots of other standards to get mad at you.