I use iNum, sNum, isNum, hasNum, lNum, dNum, fNum, etc. which are C & C++ common naming conventions... camel case and all.... I am sure most of you looking at those have NO trouble figuring out what TYPE each of them would hold...
I stopped using those conventions when I started using object orientated languges... iNumber, etc, works ok for numbers, strings etc, but when you're using references to custom types/classes; what's correct?
Something like objReference is always going to work; but it's as bad as just 'reference', I suppose it's always possible to abbreviate a class: vctMyVector, lstMyList etc, but it's harder when using custom types/classes that have very literal names, I have an anecdotal 'box' class for example, that draws boxes ( as a classic example ) - so all references to objects of the box type can start with the prefix box - a'la boxTheBox; but I might have another class that acts as a 'box' of variables ( maybe a 3D array ), we have boxForDrawing, boxOfVariables, or drwboxMyBox, memboxMyBox... ahh... I like not...
So, I stick with short, unprefixed names that describe the context of an object within another; memoryPool for the memory box, drawObject for the drawing box. Heck I don't like camel notation either : so it'd be memory_pool and draw_object. Then, if I change the type of a memory pool to some 8 dimensional structure, it can still be a memory_pool, if I decide circles are nicer than boxes, it can still be a draw_object. I suppose I could have made it a shpDraw and a memPool to begin with; but it's seems like an uneccessary convolution - starting to use a convention that I don't believe is going to hold out indefinately - and because of my nature, if a convention doesn't work in one circumstance, it can't be the convention anywhere. So, for that reason alone, I divorced type prefixing very shortly after we first got acquainted...
I often find that names used in one component of an OOP large scale project may be completely different from those used on another... So they are not common throughout... but as long as they are reasonable & well commented and each person is consistent, it is not too difficult to pickup someone elses code, when they have a different style than you, read it, and understand it...
This demonstrates, or perhaps at least allows me to draw attention to, one of the key principles of component programming. As long as the component works - it shouldn't matter what's going on inside it. That is, a 'component' implies a well encapsulated object or static library that provides a small - to - moderate, and very specific functionality. Public documentation for a component should be written from an external perspective, and external usages of that component should rely on exposed methods and interfaces... I suppose it's important for those methods and interfaces to follow some kind of convention; get_something( ), set_something( ), is_something( ), do_something( ) et cetera [ although the do is probably unneccessary there ].
-
On the subject of indentation... tabs or spaces ? =P I hate system tabs in program code ( because program/os one might say a tab is 2 columns, program/os 2 might say a tab is 8 columns ), but I don't mind them in XML/HTML/CSS/etc.. Perhaps that's because you can load up XML in document explorers, and they don't care about tabwidth..
