this_is_my_variable_name

i really like "all lower letters and words separated by underscores" naming convention.
i don't want to start a flame war. every body knows that it depends on situation and other factors
which one is used/preferred etc.

but i really wish to stick to this style. i heard that most Linux coders hate this:
thisIsMyVariableName
but they prefer and love this:
this_is_my_variable_name

now if i choose the latter (which i really like), will i be hated by say windows coders now?

i think as far as i am consistent, no one will point a finger at me or force me to change my style!

can i assume that this is widely adopted style also?

Quote:

---

i think as far as i am consistent, no one will point a finger at me or force me to change my style!

---

If you happen to work on source written by someone else, you might be "forced" to temporarily change your style so as to retain consistency.

Quote:

---

can i assume that this is widely adopted style also?

---

Yes.

That's a bit stereotypical.

For example, I program at least on Windows and Linux. I use underscores for function names, but camel-style for variable names... Works for me.

thanks laser and zacs!
i find that underscore style is most readable (easy on my eyes) and camel style is most beautiful. it has a certain professional look to it.

as laser pointed, if working on a existing project, you have to follow what has been already decided upon.

i am also using camel style all through my project.
i thing this thread will go nowhere, just like my Linux vs Windows thread.

please do not post any more comments here.
i wish i could delete this thread (i wanted to, when no body replied, but was unable to do so).

I use camel-humps... don't know why... I just like it better and it makes me see things more clearly. Maybe it's because I have a strict spacing convention in my code and the underscores make me feel as though I'm looking at more variables than I am. Of course if you work in a project group, they generally define a naming convention for the whole team whether you prefer it or not... so I'd say get used to dealing with all of the popular styles.

MyPreferenceIsToNameVariablesAndStuffLikeThis
CClasses CAnd CStuff CGets CPrefixed CLike CThis

Code:

---

class CStuff
{
  public:
    void DoStuff();
  private:
    int StoreStuff;
};

struct SStuff
{
  int StoreStuff;
};

enum EStuff
{
  Stuffy,
  Stuffa,
};

SStuff StuffAndStuff1;
CStuff* StuffAndStuff2;

---

Quote:

---

Originally Posted by zacs7

That's a bit stereotypical.

For example, I program at least on Windows and Linux. I use underscores for function names, but camel-style for variable names... Works for me.

---

Same and same. I use underscores for everything except variables actually.

I've chewed my way through pretty much every style over the years - not working in teams or anything, I've just changed a lot seeing what I like best. The only thing I can't stand reading and would verbally complain about in a team environment is this:

Code:

---

void some_function(void)
        {
                // code
        }

---

Eww.

EDIT:

Or:

Code:

---

void another_function(void)
        {
        // oh my god
        }

---

What about this?

Code:

---

void MY_function(void) { /* A statement; Another statement; More statements; return; */ }

---

Oh my.

Mine's pretty much like Magos' with a few quirks...

I start names with lowercase

Code:

---

int thisVar;
int thatFunction();

// I wish I was consistent in adopting a verb-noun or noun-verb style, but I'm not.

---

I use underscores to identify private members;

Code:

---

class CClass { // I also use C to identify my user defined objects... almost always
public:
  /* ... */
private:
  int thisValue_;
  int thatFunction_();
}

---

Finally, my constants are all uppercase and I'm yet to be consistent around enumerations (can somebody suggest something I end up liking?).

As a last note. I break my own styles here and there. For instance, I find that on those rare instances where i have to name something with one of the known types, the underscore works better: std::string format_double(double val, const std::string &format);

In java I use the same style that everything else is coded in except I like to have the opening brace to a block of code sit on its own line. In other languges i have chopped and changed a bit. Generally for variable names I like lowercase + undercores, and for functions I like to capitalise each word. To me that makes functions stand out clearly.

edit: camel case is ugly :P

I like the java conventions. Camel all the way. I don't mind underscores but I detest the hungarian notation.

m_ptr_CXWTF?QRMyFuntion().... .bleh.

Quote:

---

Originally Posted by mike_g

In java I use the same style that everything else is coded in except I like to have the opening brace to a block of code sit on its own line.

---

Most people seem to like this, however, I've always been more fond of keeping the opening brace on the same line as the definition (or statement, as the case may be) and no indentation on the closing brace.

Code:

---

if (true) {
    /* Code Body */
}

void myFunction(void) {
  /* Code Body */
}

---

Constants are generally written in full caps with underscores between words (if it is several words, which my constants usally aren't), variables are camel case, function and class definitions are the same way... pointers generally will have "ptr" somewhere in its identifier (the exception being obvious pointers like the *child member of a BST class). I guess that's about it... easy rules to follow and I haven't had any trouble reading my code, nor has anyone else that's read it. I am in work so I don't have any modern C code to show... however, I found an old little snake game I wrote on the internet that should give an idea of my style. Here is a sample (nevermind the poor coding (like not checking the result of malloc)):

Code:

---

void initGame(snakeGame *game) {
    HANDLE hOut;
    CONSOLE_CURSOR_INFO ConCurInf;
    SMALL_RECT DisplayArea = {30, 0, 72, 23};
   
    /* Initialize the game window */
    hOut = GetStdHandle(STD_OUTPUT_HANDLE);
    ConCurInf.dwSize = 1;
    ConCurInf.bVisible = FALSE;
    SetConsoleCursorInfo(hOut, &ConCurInf);
    SetConsoleWindowInfo(hOut, TRUE, &DisplayArea);
    SetConsoleTitle("Snake");
   
    srand(time(0));  /* rand() is used in generating the apple location */

---

I use lowercase letters with underscores for word separation. The primary reason is that it matches the coding style of STL. It is also easier for my eyes to pick out the individual words of the identifier.

Quote:

---

Originally Posted by SlyMaelstrom

Most people seem to like this, however, I've always been more fond of keeping the opening brace on the same line as the definition (or statement, as the case may be) and no indentation on the closing brace.[CODE]if (/*condition*/) {

---

The downside to this is that many automated tools scan for function definitions by looking for a opening curly brace in the first column. So in many projects where the style is, "put the brace on the same line," there is a special exception for function definitions, just to keep these tools happy.

I wouldn't trust an automated tool that can't properly parse code, eh. Besides K&R is widely used.

Quote:

---

Originally Posted by Mario F.

I wouldn't trust an automated tool that can't properly parse code, eh. Besides K&R is widely used.

---

Yeah, honestly... can you imagine if the compiler couldn't parse the code unless the open brace was in the first column? O_O

That's just lazy design. Why make a tool designed to parse through C code that doesn't conform to C's standard on whitespace?

Quote:

---

Originally Posted by SlyMaelstrom

Yeah, honestly... can you imagine if the compiler couldn't parse the code unless the open brace was in the first column? O_O

That's just lazy design. Why make a tool designed to parse through C code that doesn't conform to C's standard on whitespace?

---

Lots of tools do it. The reasons are speed and flexibility. You can do a lot of useful source indexing without having to actually parse the language. The benefit gained is that the tool will automatically work on ANY language which is "C-like," including C++, Java, JavaScript, C#, and PHP -- provided the code being processed adheres to a single, simple rule.

It's not lazy -- it's deliberate.

EDIT: Also, you should try writing a parser which can recognize the beginning of a function definition... In C++. Just wait until templates get involved. By the end of this task you'll essentially have written a compiler, when all you wanted to do was a little source indexing. It is not a bad choice to ignore the entire issue and specify that the input must conform to a simple rule, a rule which isn't even that onerous.

Dunno brewbuck, maybe you are right. But even the poor-man refactoring tool I sometimes uses properly recognizes K&R.

I insist. If you are being forced to use these tools you are talking about, get into a strike.

I dunno. Have you ever seen Doxygen's yacc/bison parser? It handles C, C++, Java, and I think ML and other languages all in one parser. Let me tell you, it's ugly.

Besides, if your code doesn't conform to this rule, whatever it is, you can always pass the code through indent. Let indent do the full parsing, not you. ;)

Code:

---

cat code.c | indent - | program_that_assumes_curly_braces_on_separate_lines

---

As you can probably tell from the above command, I use "underscore notation". I also put opening curly braces on the previous line.

Quote:

---

Originally Posted by Mario F.

and I'm yet to be consistent around enumerations (can somebody suggest something I end up liking?).

---

Just that enum values should always have a prefix. I use all capitals for them on the grounds that they're constants as well. But whatever you use, do use a consistent prefix. Nothing annoys me more than code like

Code:

---

enum { clubs, diamonds, hearts, spades } suit;

---

because it's hard to tell what "clubs" is. What do you know -- I must partially subscribe to the ideals of camel notation, in putting information about a symbol into its name. :)

But no, I prefer not to use camel notation on the grounds of readability. It's simply easier for the eye to separate_this_into_words thanThisIntoWords.

I don't hate camel notation, though -- I use the SDL frequently, and I've never considered writing a layer to re-defined its camel-notation names into underscore notation. ;)

(Note that I invented the term "underscore notation". I'm sure it's not very widespread, so don't use it without explaining what it means first! :p )

[edit] Did manav just get banned? I could have sworn that his/her user title wasn't "Banned" when I loaded this thread for the first time . . . . [/edit]
[edit=2] Aha! It wasn't on the 28th of March. http://72.14.253.104/search?q=cache:...lnk&cd=2&gl=ca [/edit]

Quote:

---

Originally Posted by Mario F.

Dunno brewbuck, maybe you are right. But even the poor-man refactoring tool I sometimes uses properly recognizes K&R.

I insist. If you are being forced to use these tools you are talking about, get into a strike.

---

But what if the code is syntactically incorrect? That's no reason not to be able to index it.

"Why on earth would you have code that is syntactically incorrect" -- because it might be hiding inside an #ifdef, currently disabled, so you don't notice it's broken. Again, no reason not to index it.

At work the only indexing tool I really use is cscope. Its parser is a little more complex/robust that just "look for opening curly brace on column 1," but it still doesn't fully parse the language, because that would be too restrictive. You want your indexing tools to work properly even when you use non-standard language extensions or other oddities which would completely confuse a "real" parser.

Quote:

---

Originally Posted by brewbuck

It is not a bad choice to ignore the entire issue and specify that the input must conform to a simple rule, a rule which isn't even that onerous.

---

Except that it is, what if I wanted to use the parser on existing code?

Its not that difficult to write a parser that properly parses every style of C/C++ code. Its certainly less invovled that writing a whole compiler.

Quote:

---

Originally Posted by abachler

Except that it is, what if I wanted to use the parser on existing code?

---

Obviously, if you have some other use for a parser, why not write one? It still doesn't solve the problem of how to deal with malformed code.

Quote:

---

Its not that difficult to write a parser that properly parses every style of C/C++ code. Its certainly less invovled that writing a whole compiler.

---

I think the writers of C++ compilers would disagree on the level of difficulty. Look how long it has taken just to get basic template support in most of the compilers.

Quote:

---

Originally Posted by brewbuck

Lots of tools do it. The reasons are speed and flexibility. You can do a lot of useful source indexing without having to actually parse the language. The benefit gained is that the tool will automatically work on ANY language which is "C-like," including C++, Java, JavaScript, C#, and PHP -- provided the code being processed adheres to a single, simple rule.

It's not lazy -- it's deliberate.

---

I'm for the opinion that a good program should minimize demand on the end-user. I'd rather a slower program that allows greater flexibility in my input than a quicker program that demands I conform to a standard I wouldn't normally follow. It might even be more time consuming to use the quicker parser if I have to waste time double-checking myself to make sure I didn't conform to my own natural habits. The ability to parse several languages should only make a program more robust in size and not significantly slower in operation. It should generally be a quick enough procedure for a program to identify the language it is parsing. All languages have unique attributes that can be searched for to identify this.

Quote:

---

Originally Posted by brewbuck

EDIT: Also, you should try writing a parser which can recognize the beginning of a function definition... In C++. Just wait until templates get involved. By the end of this task you'll essentially have written a compiler, when all you wanted to do was a little source indexing. It is not a bad choice to ignore the entire issue and specify that the input must conform to a simple rule, a rule which isn't even that onerous.

---

I'm not about to be convinced as to whether something is worth doing or not based on how easily I could achieve it myself... I am still a very young programmer and would expect better from a team of developers. Besides, I so no reason for this to be as slow as a compiler, because you'd be skipping most of the lexical analysis and all of the optimization and rewriting. Look, I don't have a fraction of the experience that you have programming, so I'm not going to bash you ideas down with my simple opinions... however given that abachler and Mario (both who have nearly the experience you have) seem to have similar opinons to mine, I feel as though I'm at least making an acceptable stance on the issue. Who knows... I could be wrong.

Quote:

---

Originally Posted by SlyMaelstrom

I'm for the opinion that a good program should minimize demand on the end-user. I'd rather a slower program that allows greater flexibility in my input than a quicker program that demands I conform to a standard I wouldn't normally follow.

---

My point is that by implementing a real parser, you DO reduce flexibility, by making it impossible to handle malformed code, code with extensions, or code written in other languages.

I'm not arguing that the curly-brace-column-1 rule isn't overly simplistic, because it is. A slightly better algorithm that does not require a full-blown parser is to just count the brace nesting level.

In reality, you will find numerous tools which rely on this for proper functioning, and you'll find numerous development teams which implement this style rule specifically so that these tools will work correctly.

Hell, you'll even find mention of it in the GNU coding standard itself. Careful as you read this -- they don't state it explicitly, but they do state the contrapositive, which is equivalent. In fact, they apply even more stringent requirements, by requiring that the first character of the function name occur in column 1 -- in other words, you put the return type on a line by itself. I do find that particular rule to be overly restrictive:

http://www.gnu.org/prep/standards/ht...tml#Formatting

Quote:

---

Originally Posted by GnuCodingStandard

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.

---

Quote:

---

I am still a very young programmer and would expect better from a team of developers.

---

My experience, functioning on various development teams, is that complexity often looks "worth it" but rarely is.

Quote:

---

Look, I don't have a fraction of the experience that you have programming, so I'm not going to bash you ideas down with my simple opinions... however given that abachler and Mario (both who have nearly the experience you have) seem to have similar opinons to mine, I feel as though I'm at least making an acceptable stance on the issue. Who knows... I could be wrong.

---

Your opinion is perfectly valid, no need to apologize for it.

Quote:

---

Originally Posted by brewbuck

My point is that by implementing a real parser, you DO reduce flexibility, by making it impossible to handle malformed code, code with extensions, or code written in other languages.

---

I can see your point here brewbuck. It begs a rebuttal, though :)

Malformed code should be flagged as malformed code. I don't think it is the task of an automated tool (from indexers, to refactors, to code beautifiers even) to try and make some sense of it and guess as to what the coder wanted.

I would agree that macros, for instance, may force the user as to specific styles in order to make them work on their tool of choice (if the tool even considers them). But other than that, I find it extremelly limiting any tool that forces me to adapt my code to it. If an attempt hadn't been made by parsers to overcome these limitations in the past, we all would be still formating our code to run our refactoring program, then format it again to run our indexer, then format it again to run our document generator.

All in all, this is becoming less and less of a problem. Every run-of-the-mill code editor these days come with powerful indexing tools. Commercial ones ranging on the hundreds of dollars (which everyone uses anyways) come with even more powerful tools. I would wager those recommendations from the GNU Project are not only old (very), but also plain wrong even for when they were valid; simply because they take the burden of the tool and put it on the user of the tool. This is mal practice.

Despite that, they probably only apply these days mostly to legacy systems and tools. You can't expect to take anything of that seriously (and judging from GNU recent code no one does) in a world where bison and yacc, for instance, are no longer infants and widely accessible to anyone wanting to code their own tools.

Quote:

---

Originally Posted by brewbuck

Obviously, if you have some other use for a parser, why not write one? It still doesn't solve the problem of how to deal with malformed code.

---

Define malformed, if its not properly formatted int eh first place, then any parser will have problems, if you mean you just dont like the style, then pshaw who cares.

Quote:

---

I think the writers of C++ compilers would disagree on the level of difficulty. Look how long it has taken just to get basic template support in most of the compilers.

---

You dont have to write a whole compiler to write a parser. The parser is only one part fo the compiler, and unless it is parsing in preperation fro compilation, you dont need to do as thorough of a job as in a compiler.