quote: Original post by null_pointer

(Besides, code is formed from "statements" (<-- anyone see a relation to English!), and we don''t talk like anything else.

Well, if we''re gonna get pedantic and compare with English, lines of code are more like directives than statements

For the record, I use the same conventions as Xai (capitalised functions, mixed case variables, uppercase with underscores constants) and don''t agree with Hungarian notation or global/member prefixes mainly because I don''t think they are needed in well encapsulated code, and therefore just adds clutter and hampers readability. (Give me ''name'' over ''m_lpcstrName'' any day.)

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 was reading this and came up with a new simple way of naming items.
functions: CWindowText
variables: b_text_active

Very simple. Hungarian can still apply.
Now in my code if I see this CWindowText, not only do I know it''s a class vs. a variable, I also note the missing ().
This means I could possible be using the wrong constructor.

Perhaps this already exists, but I personally have never seen it.

I have a theory, that the C enthusiest''s use more lower case names, than the C++''ers(or poeple who ONLY use C++), use more Caps, just my theory,
later,(Im going cruzin in a 2001 Camero now, C U later)

Weird. Jansic, I seem to have about the exact same style as you do. How freaky is that?

Anyway, the Hungarian thing came up in another post before, along with the argument that it shouldn''t be part of the variable name because it''s part of the type. I heartily disagree; while hungarian notation doesn''t help the compiler at all, it DOES help people who are reading your code (be they others or yourself after a long absence).

To answer the original poster:
Generally, BigYes should be avoided because it can be confused with win32 functions. big_yes uses one more character, but that''s not a big deal to me and won''t be to most. What it comes down to is conforming to the group of programmers you work with (if you work with others). In that case, it''s absolutely imperative that there be a convention for that project and that everybody follow it. What you decide on is not really important; what''s important is that a style decision is made and followed.

BigYes() for functions
BigYes for variables
BIG_YES for macros

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