views:

138

answers:

6

Is there a standard way to name them or is it programmer's call?

Thank you.

A: 

It's a reason for the holy wars in the programmer's office. Kind of akin to the one true bracing style.

Stay away from Hungarian Notation. ;-)

DevSolar
+1: Yes, enforcing types is the compiler's job; names should rather inform about purpose and meaning. Hungarian notation is now widely reviled.
Carl Smotricz
-1: what's the point of warning about holy wars and then try to start one?
AAT
@ AAT: *Any* answer actually stating one style or the other is by very nature biased, and could be constructed to be "trying to start a holy war" by a suitably humorless individual. You voted me down; do you actually recomment Hungarian Notation, or are you miffed because I didn't get a LOL out of you this day? I quoted my pet peeve, the one I can't stand in *any* coding style. Have you downvoted everyone else who actually made a suggestion as well? That being said, I concur to MaxVT - he got the right answer here.
DevSolar
there's nothing wrong with apps hungarian: naming variables sensibly automatically leads to some kind of hungarian scheme, eg when you do things like `block_size` vs `block_count`, `dx = x1 - x2` you are using hungarian notation; I agree that systems hungarian is mostly useless (the compiler should check for type mismatches), but sometimes it's still useful (`foofunc_fn`, `type_t`)
Christoph
That is stretching the term "Hungarian Notation" a bit far. I agree that the *original* notation - referring to the *purpose* of a variable - has at least some theoretical value, while still being inferor in its "type wart" style to more verbose namings like you gave in your examples. But today (and "thanks" to Microsoft), HN mostly means people prefixing pointers with p and integers with i etc., which is *completely* pointless, nay, counterproductive.
DevSolar
@DevSolar: the original HN was created when BCPL (no type system!) was the langauge of choice; also, early linkers restricted the length of identifiers (think 8 character variable names), so it made sense to have a short type specifier either pre- or post-fixing names; today, these restrictions no longer apply, but the concept is still useful; I agree that MS interpretation of HN is an atrocity and if you don't consider what I described above HN but just common sense, fine with me, but it *is* in the spirit of the original idea
Christoph
A: 

Something very basic and pretty much universally accepted:

  • use nouns for variable names.

  • use verbs for function names.

This makes coding easier to understand.

Beyond that, there are lots and lots of "rules" - I suspect the other answers will provide a few.

Carl Smotricz
+5  A: 

Use your company's coding guidelines; challenge them if they are outdated (i.e. keep a list of changes at the top of the file despite using version control).

If you're the first programmer or doing it for yourself, decide on a set of coding guidelines that works for you, document it, and stick with it.

MaxVT
Good point. The worst thing you can do is changing the coding style in the middle of the project. Stick to whatever exists... there is nothing more you can do.
Andre
AAT
I completely agree. It's like asking what the correct type of power plug is to use in your home. There's not much difference at the end of the day but if every appliance used a different one you'd have lots of trouble!
PP
A: 

Here are the naming guidelines posted by the GNU folks; they're similar to many others and about as good:

http://www.gnu.org/prep/standards/html_node/Names.html#Names

Carl Smotricz
A: 

Well,

I usually name functions as:

MyFunctionToDoSomething();

variables/members as:

my_var_to_accept_something;

global variables:

MY_GLOBAL_VARIABLE;

Above all I try to keep all my naming to this standard. I really don't know what notation this follows, but I'm not a big fan of the Hungarian notation, so...

BTW, I see a lot of people going to some lengths to write small names which later on they wont understand... I learned to don't do that for the same reason. After all most IDE have auto-complete features so using long names isn't really an issue.

Cheers

Andre
Are there any major libraries or applications in C that use PascalCasedFunctionNames()?
mcl
Normally, all upper-case is reserved for macros, not for global variables.
Jonathan Leffler
mcl, I can remember IPP from intel and OpenCVJonathan, shure, I know ;) As I said, I really don't follow any strict convention. Obvisouly this can lead to problems when other people start working on my code, but I document how "I want" my code to look like, and they better do as I like (just kidding)
Andre
A: 

Name your variables in english.
Comment in english.

But if you must use a different language, then use it for all variables and comments. Don't mix english (other than keywords and library functions) with your language.

I hate to see code like:

void  FreeT( void* puntero ) {

    unsigned long size;

    size = *(long*) ( (char*)puntero - offset );
//    memcpy( &size ,, offset );
    if ( !size ) return; 
    total_bloques --;
    total_alocado -= size ;
    free( (char*)puntero - offset );
}
pmg