Ok, Here are my 2 cents worth...

( someone said this: although, big_yes() is kind of cool...)

Well, this is the proper way according to the Ansi C standards of my college years but now, It''s evolved a bit. My method of choice is:

int generalArbitraryValue;

I''ve always used the method mentionned above. The first word is in small and the rest of the words start with a capital. This is the way that I''m most comfortable with.

This is my 2 cents...



Cyberdrek
Headhunter Soft
DLC Multimedia

If it is a function specially for that project, I will use big_yes() style. If is part of a library which I made, i will put the name of the library in lower case letters, followed by the BigYes() style. Structure names are ALL CAPS, and so are macros. Variable names are in the big_yes style again, unless they are external, in which case they are Big_Yes.

------------------------------
#pragma twice

sharewaregames.20m.com

I am a C++ enthusiast more than C so maybe that generalization was right. I have a similar style to Quantum.

#defines : MAX_INVENTORY
global consts : MAX_INVENTORY
variables : InventoryIndex
functions : DisplayInventory()
classes : INVENTORY (or Inventory or inventory)

I like _ but they look weird with lower case



-=[ Lucas ]=-

quote:

Principal Two: Encapsulation
This is my primary argument against hungarian notation (which is the ONLY popular style I have a problem with). My contintion (for which I have run no experiments to prove) is that it is NOT a good idea to display type information in the code, as this is COMPLETELY CONTRARY TO OBJECT ORIENTED PROGRAMMING. The idea of object oriented programming is encapsulation and data hiding, the fundamental idea is ABSTRACTION (omiting of certain detials in order to see the wholistic structure better). The whole point of polymorphism is so that different derived classes may be treated the same, the whole point of classes is so that implementation details may be ignored, and FOR ME, the whole point of naming conventions is so that THE INTENDED USE of a variable / function / or class can be made clear. The header file and code itself will tell you what class an object is and the details of its use (in modern editors this pops up as TOOL TIPS, and there are also dozens of automated tools to generate this kind of documentation) so as a programmer, the only way you can add value is to use names that provide ADDITIONAL / DIFFERENT information than what the language syntax implies.

I don't understand this. You use hungarian notation on the variables HIDDEN in the class. Escapulation is not broken. The people using the class won't see the hungarian notation (except for parameters in public functions, which they'll NEED to know the types of anyways).

I can't begin to explain how important hungarian notation is when working on someone else's code on a large project. It's too easy to be in the middle of someone else's function, and see a variable called "minutes" and have NO clue if that is a string, int, byte, unsigned int, long, etc. If you want to find out you have to look to see if it's a local variable, or a class member, or a global, because you just don't know. Yes, if you DO use one of the editors that keeps track of that stuff (and not everyone does) then you can go through the minimal effort of recompiling to support that feature, and have the program take you to the spot where it is defined. Of course, this does you no good if you are looking at a hardcopy.

Working on your own code, it's hard to see the benifit (and sometimes there ISN'T any) of hungarian notation, but when you are trying to understand someone elses code it will save you lots of time.

Edited by - Houdini on September 13, 2000 2:40:59 PM