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.
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 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.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Can you write object oriented code in C?
Object oriented programming in C
So, as I get it, "objects" are basically just wrappers for values and methods. Can't you have the same functionality in C, with structs? A struct seems just like a simple class, but, of course, it doesn't have any methods. Here we get to the heart of my problem: I don't understand why methods are needed at all. Wouldn't it be simpler and more memory-efficient if we had an outside function, which just accepted a pointer to an instance of a struct? Or even have the structs have pointers to these functions, but this seems purely aesthetic...
Being object-oriented means being object-oriented out of the box. Sure you can simulate object orientation with C (and with many other non-OO languages), but if the language (and/or its standard library) does not help you with that in any way (special syntax, standard objects, etc) and does not encourage to write in OO style by default, it will not be called object-oriented.
Using c-style function pointers as struct members, you can indeed make C object oriented.
I like the concept of having a class with its attributes and methods all defined together. Its easier to see what the related entities are, as opposed to having separate functions that take pointers to the struct like you mention.
Here are 2 related SO questions:
Is there a simple way to code the strategy (or other) design pattern in ANSI C that would fit on the screen of an 11" MacBook Air?
How do function pointers in C work?
What you suggest is already used to implement OO features in C. But many people find easier to use dedicated languages where OO features are included.
This is the same trend as why people switched to C from assembly.
Object is real-world entity and it has state, behavior. In class(c++/java) we can define state as member variables and functions as behavior. In case of C: in struct, you may have state but not behavior. Therefore C is not object oriented. This is just a small e.g. Also C does not support OOPS principals like inheritance, function overloading, polymorphism etc.
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.
Does the FILE type used through standard C functions fopen, etc. have an object-oriented interface?
I'm looking for opinions with reasoning rather than an absolute answer, as definitions of OO vary by who you ask. What are the important OO concepts it meets or doesn't meet?
In response to JustJeff's comment below, I am not asking whether C is an OO language, nor whether C (easily or not) allows OO programming. (Isn't that a separate issue?)
Is C an object-oriented language?
Was OOP (object-oriented-programming) anything more than a laboratory concept when C and FILE were created?
Answering these questions will answer your question.
EDIT:
Further thoughts:
Object Oriented specifically means several behaviors, including:
Inheritence: Can you derive new classes from FILE?
Polymorphism: Can you treat derived classes as FILEs?
Encapsulation: Can you put a FILE inside another object?
Methods & Properties: Does a FILE have methods and properties specific to it? (eg.
myFile.Name, myFile.Size, myFile.Delete())
Although there are well known C "tricks" to accomplish something resembling each of these behaviors, this is not built in to FILE, and is not the original intent.
I conclude that FILE is not Object Oriented.
If the FILE type were "object oriented", presumably we could derive from it in some meaningful way. I've never seen a convincing instance of such a derivation.
Lets say I have new hardware abstraction, a bit like a socket, called a wormhole. Can I derive from FILE (or socket) to implement it. Not really - I've probably got to make some changes to tables in the OS kernel. This is not what I call object orientation
But this whole issue comes down to semantics in the end. Some people insist that anything that uses a jump-table is object oriented, and IBM have always claimed that their AS/400 boxes are object-oriented, through & through.
For those of you that want to dip into the pit of madness and stupidity that is the USENET comp.object newsgroup, this topic was discussed quite exhaustively there a few years ago, albeit by mad and stupid people. If you want to trawl those depths, the Google Groups interface is a good place to start.
Academically speaking, certainly the actual files are objects. They have attributes and you can perform actions on them. Doesn't mean FILE is a class, just saying, there are degrees of OO-ness to think about.
The trouble with trying to say that the stdio FILE interface qualifies as OO, however, is that the stdio FILE interface doesn't represent the 'objectness' of the file very well. You could use FILEs under plain old C in an OO way, but of course you forfeit the syntactic clarity afforded by Java or C++.
It should probably further be added that while you can't generate 'inheritance' from FILE, this further disqualifies it as OO, but you could argue that's more a fault of its environment (plain C) than the abstract idea of the file-as-object itself.
In fact .. you could probably make a case for FILE being something like a java interface. In the linux world, you can operate almost any kind of I/O device through the open/close/read/write/ioctl calls; the FILE functions are just covers on top of those; therefore in FILE you have something like an abstract class that defines the basic operations (open/read/etc) on an 'abstact i/o device', leaving it up to the various sorts of derived types to flesh those out with type-specific behavior.
Granted, it's very hard to see the OO in a pile of C code, and very easy to break the abstractions, which is why the actual OO languages are so much more popular these days.
It depends. How do you define an "object-oriented interface"? As the comments to abelenky's post shows, it is easy to construct an argument that FILE is object-oriented. It depends on what you mean by "object-oriented". It doesn't have any member methods. But it does have functions specific to it.
It can not be derived from in the "conventional" sense, but it does seem to be polymorphic. Behind a FILE pointer, the implementation can vary widely. It may be a file, it may be a buffer in memory, it may be a socket or the standard output.
Is it encapsulated? Well, it is essentially implemented as a pointer. There is no access to the implementation details of where the file is located, or even the name of the file, unless you call the proper API functions on it. That sounds encapsulated to me.
The answer is basically whatever you want it to be. If you don't want FILE to be object-oriented, then define "object-oriented" in a way that FILE can't fulfill.
C has the first half of object orientated.
Encapsulation, ie you can have compound types like FILE* or structs but you can't inherit from them which is the second (although less important) half
No. C is not an object-oriented language.
I know that's an "absolute answer," which you didn't want, but I'm afraid it's the only answer. The reasoning is that C is not object-oriented, so no part of it can have an "object-oriented interface".
Clarification:
In my opinion, true object-orientation involves method dispatch through subtype polymorphism. If a language lacks this, it is not object-oriented.
Object-orientation is not a "technique" like GTK. It is a language feature. If the language lacks the feature, it is not object-oriented.
If object-orientation were merely a technique, then nearly every language could be called object-oriented, and the term would cease to have any real meaning.
There are different definitions of oo around. The one I find most useful is the following (inspired by Alan Kay):
objects hold state (ie references to other objects)
objects receive (and process) messages
processing a message may result in
messages beeing sent to the object itself or other objects
a change in the object's state
This means you can program in an object-oriented way in any imperative programming language - even assembler. A purely functional language has no state variables, which makes oo impossible or at least awkward to implement (remember: LISP is not pure!); the same should go for purely declarative languages.
In C, message passing in most often implemented as function calls with a pointer to a struct holding the object's state as first argument, which is the case for the file handling api. Still, C as a language can't be classified as oo as it doesn't have syntactic support for this style of programming.
Also, some other definitions of oo include things like class-based inheritance (so what about prototypal languages?) and encapsulation - which aren't really essential in my opinion - but some of them can be implemented in C with some pointer- and casting magic.