Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

kelaklub

Hungarian or, anyone, anyone??..

This topic is 5327 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I am pleased to say that my skills as a programmer have gone beyond those of the intermediate user and I am really excited to be moving onto the more advanced (for lack of a better word) stuff. I hope. I find my code however lacking a certain consistency and am seriously thinking of writing my code to conform to a certain standard. But the only one I have heard about is the hungarian notation. Do any of you guys recommend this, or are ya''ll aware of anything else? Thank you for your time.

Share this post


Link to post
Share on other sites
Advertisement
I personally dislike Hungarian notation, and strongly recommend against it''s use in new projects. Here''s one article by authors who aparantly agree with that sentiment.

Also there''s more to coding standards than how you write your variables. I generally give out this link in any thread mentioning coding standards. It''s a perl script to write your own coding standard. It has explanations for many of the sections, to explain why anyone would bother codifying certain sections.

Share this post


Link to post
Share on other sites
I personally dislike Hungarian notation really, really badly. There was a thread about coding style not too long ago on this board if my memory serves me well. You could search for it to see what the different members of this forum use.

SiCrane: I love the article you linked to. I read it a while back(who knows you might of been the one who posted it then) and I loved it.

Share this post


Link to post
Share on other sites
As for what to use? I''d say try to think about what you want to use. What feels right and looks clean to you and use it. Just try to be consistent in your style/notation.

Share this post


Link to post
Share on other sites
I prefer exdented style (not as cramped as K&R), with CappedVariableNames, CappedMethodNames, and UndecoratedClassNames (no ''C'' or ''I'', due to the nature of inheritance and polymorphism). g_ for globals, m_ for member data, and no spaces around punctuation, except math operators. e.g.:

for(int ind = 0; ind < Num; ++ind)

y = (16 + e) & (er << 2) * 32;

Later,
ZE.

//email me.//zealouselixir software.//msdn.//n00biez.//
miscellaneous links

Share this post


Link to post
Share on other sites
I''ve worked with Hungarian a bit, and I really haven''t been able to convince myself that it''s an actual advantage.

Personally... I like clear and descriptive names, and to me, Hungarian, by putting a bunch of encoded, acronymed bull**** up front, is an eyesore.

At work, we used a very lightweight convention for variable naming:

prefix a class data member with "f" (for data Field)
prefix a global with "g"
prefix a static variable with "s"
prefix a member function with "m"
prefix a typedef or class name with "t" (for Type)

so a simple class def would look like

class tStupidClass
{
protected:
int fWorthlessInt;

int mGetWorthlessInt( void ) { return fWorthlessInt; }
};

We also had conventions, and I think these were very important, for naming constants and enums, so

typedef enum eEnum {
kOne,
kTwo
} eEnum;

so an group of enums was always prefixed with "e", and any constant, not just enums but #defined constants and other constants, got the "k" prefix.

without the Hungarian prefixes I had a tendancy to use long, descriptive names for the variables that might tell me something about them. Like fSomethingList or fSomethingVector... But sometimes I wouldn''t bother, like if there was a general tendency to default to ints to like, count simple quantities, then the type of fNumKillerRobots wasn''t exactly a mystery that required a secret Hungarian code to decypher.

To me the most immediately useful piece of info about a variable was it''s scope (is it global, part of this class, is a function global or a member?), and whether or not it was a #defined or enumerated constasnt, and this naming convention encoded that.

The argument for hungarian is that, at a glance, you can tell the exact type of a variable... I guess that''s useful (I mean seriously, it is) but in practice I did not find myself handicapped by a naming convention that did not encode this... Mostly it just wasn''t a problem, but seriously, with the class browsers built into modern development environments and whatnot, it''s not THAT big of a deal to just look at the freakin'' header to find the type of a variable, and before long you get used to the codebase and the classes.

Having worked with both, I just feel like Hungarian just ads lots of obtuseness, supposedly for the sake of clarity, but it really doesn''t work for me. I like to go for longish, usefully descriptive variable names, and to me using Hungarian hurts clarity.

Share this post


Link to post
Share on other sites
Oh, I forgot to mention. If you feel you are at the point where you want to think about things like coding style, pick up a copy of Code Complete by Steve McConnell. This will tell you more about good coding practice than I or probably anyone else on this forum can.

This is like The One True Software Engineering Book that''s of actual value to people out there writing code, not teaching software engineering courses.

Here''s it''s page on Amazon
http://www.amazon.com/exec/obidos/tg/detail/-/1556154844/103-2101245-6527868?v=glance

[Edited by - The_Incubator on June 14, 2006 2:15:29 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by The_Incubator
This will tell you more about good coding practice than I or probably anyone else on this forum can.

This is like The One True Software Engineering Book that's of actual value to people out there writing code, not teaching software engineering courses.



To be taken with a grain of salt though - C++ was not standardized in 1993 (and I don't think people here use much Ada or Pascal), and advice valid for C isn't necessarily valid for today's C++. "Industry best practices" have changed in 10 years. Still a good book though, so long as you remain critical.


“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”
— Brian W. Kernighan (C programming language co-inventor)


[edited by - Fruny on January 14, 2004 3:31:23 AM]

Share this post


Link to post
Share on other sites
Use the ALF coding standard. Mostly the prefixes and suffixes in the ALF coding standard let you know what the variable can do. Few reminders on what you have to do. Like some virtual functions that Must call their base class version will be prefixed with V, anyway, here. See for yourself...


Coding conventions used

- All class and struct names start with capital letters.

class Graphics;
struct Vertex;

- All variable names start with lower case (unlessed prefixed) and no spaces

int myVariable;
Graphics graphics;

- All member variables of classes start with m_

class Class { int m_privateVar; }

- All global variables start with g_

int g_globalVar;

- typedefs have a _t postfixed at the end of them

typedef float Time_t;

- Function pointer typedefs have a _pfn postfixed to the end of them

typedef void (*MessageHandler_pfn)(Message*);

- A class that starts with s_ means that it is a static class

class s_Math { public: static int Random() { } };

- A class that starts with the letter I means it is an iterface

class INode { virtual void F1() = 0; virtual void F2() = 0; };

- All enums start with ''e''

enum eObjectTypes { };

- All enum members are capital with underscores between words

class eObjectTypes { OT_EXPLODABLE, OT_BENDABLE };

- A solid base class (a class that should be derived from but has not vertual methods) starts with sb_

class sb_Movable { Vertex_t m_pos; void Method1() {} void Method2() {} };

- All static member vars start with ms_

template< typename T > class Singleton{ T* ms_pSingleton; };

- All static vars start with s_

static int s_dumbo;

- All pointers start with p

int* pInt;
Graphics* pGraphics;

- All smart pointer types have a <TypeName> with Ptr prefixed at the end. Example: Smart pointer
version of the Graphics class is called GraphicsPtr

typedef boost::shared_ptr<Graphics> GraphicsPtr;

- All macros are capital

#define NUM_OF_ENEMIES 30

- All global functions/macro functions start with some abbreviation specific to your project (This is preferable).

#define msAssert( p1 ) /* ms for Microsoft */

- Virtual functions have a V prefixed to the start ONLY if the abse virtual function has to be called

class Base{ VCallMe() { // do stuff } };

class Derived : Base { VCallMe() { // do stuff; Base::VCallMe(); } };


- Classes that should be derived from for a little extended functionalitybut are not interfaces start
with a V

class VTimer{ virtual GetTime() { return 0; } // Otehr functions };

class QueryTimer : VTimer { GetTime() { QueryPerformanceCounter(); } };
class MediaTimer : VTimer { GetTime() { timeGetTime(); } };

- Use consts instead of macros when possible so they maintain namespace qualification

namespace Name { const int NUM_OF_ENEMIES = 30; }

- Everything goes inside a custom namespace


| C++ Debug Kit :: GameDev Kit :: DirectX Tutorials :: 2D DX Engine | TripleBuffer Software |
| Plug-in Manager :: System Information Class :: D3D9 Hardware Enum | DevMaster :: FlipCode |

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!