Thread: this_is_my_variable_name

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.

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.

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;

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);

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 */