• (cs) in reply to Aaron
    Aaron:
    KattMan:
    Faxmachinen:
    Yeah, adding "the" to "position" really clears everything up.
    And you sir suffer dearly from the "I wanna make a post without reading the post I am responding to" disease. This, regretfully makes you a total idiot. Hopefully by responding you will overcome this disability and realize that I addressed this problem in the portion of the post you felt necessary to remove.
    Your original post didn't address that at all. It was just a general statement saying "in some situations it might be better".

    Okay then, give us an example of one situation where putting the word "the" in front of a variable name adequately describes what it holds without being overly verbose. I'll grant you that it makes sense with myPosition vs targetPosition (although I think a better choice for myPosition would be currentPosition, or even just position since most people would infer that it's the current position when compared to targetPosition). But even granted that, how does thePosition clarify anything, in any circumstances?

    As the person who you're calling an idiot pointed out, the word "the" adds no meaning. It could be "the current" position, "the target" position, or "the original" position.

    Case sensitivity isn't an argument here either; I know case differentiation makes a lot of VB coders squeamish, but not only is it part of many sets of established code style guidelines, it's actually baked right into the C++/C# specifications by virtue of the fact that static members of a class are accessible from an instance member of a container class with the same name.

    Simple, one line from my original posts explains it all:

    "The semantics of naming variables should follow one rule, do they adequately describe what they are representing without being overly verbose? If so then there is nothing wrong with a variable name."

    If adding "the" to the variable makes it overly verbose then it is a problem, but if taken in context it makes sense, then leave it. This is a soft rule that can easily be followed.

    I mentioned that anyone wanting hard rules will always be wrong follows this also. Once you set hard rules, like you can't use "the" or "my" as prefixes for variables, there will come a time when one of your hard rules causes unnecessary obfuscation of variable names.

    Following these two lines of thought, no you should not explicitly deny any type of prefix, but if that prefix is overly verbose within your current context then get rid of it.

    And this is exactly what my previous post said, only differently.

  • dave++ (unregistered) in reply to jim
    jim:
    dave:
    Once you see the confusion between pre- and post-increment, it's not worth even looking at the rest of the code.

    What confusion? Traditional increment operators are distinguished only by return value. Here, both increments return void, so they have exactly the same effect, as they should.

    Sure, but it's still a crime against humanity to define the pre-inc operator in terms of post-inc on a member. That says "sloppy for no reason".

  • theDave (unregistered) in reply to Aaron
    Aaron:
    Okay then, give us an example of one situation where putting the word "the" in front of a variable name adequately describes what it holds without being overly verbose.
    The sole object of a class that follows the 'singleton' pattern can be usefully and descriptively named something like 'theObj', as in 
    Obj theObj;
  • (cs) in reply to theDave
    theDave:
    Aaron:
    Okay then, give us an example of one situation where putting the word "the" in front of a variable name adequately describes what it holds without being overly verbose.
    The sole object of a class that follows the 'singleton' pattern can be usefully and descriptively named something like 'theObj', as in 
    Obj theObj;
    Thank you, I was trying to recall where this made sense. If he had asked what would you name an object in a singleton I would have said theObject, but trying to relate the reverse just wasn't making the connection in my head.
  • An apprentice (unregistered) in reply to mrprogguy
    mrprogguy:
    An apprentice:
    C is dangerous and C++ is evil. This code snippet actually combines the worst of both worlds.

    And what would your choice be, oh learned apprentice?

    (And I can see why you're still an apprentice.)

    Why, Python of course.

    Concerning "dangerous" and "evil" I meant that in these languages shooting yourself in the foot is easier than doing useful work (sure, it may be my lack of experience).

  • MikeCD (unregistered)

    Did you guys miss that the iterator doesn't work, and thus must be manually incremented within the for loop?

  • (cs) in reply to An apprentice
    An apprentice:
    mrprogguy:
    An apprentice:
    C is dangerous and C++ is evil. This code snippet actually combines the worst of both worlds.

    And what would your choice be, oh learned apprentice?

    (And I can see why you're still an apprentice.)

    Why, Python of course.

    Concerning "dangerous" and "evil" I meant that in these languages shooting yourself in the foot is easier than doing useful work (sure, it may be my lack of experience).

    Well, at least in C/C++ performance isn't usually an issue... explain to me how, as regards performance, Python's treatment of the global namespace (and namespaces in general) isn't both dangerous and evil?

    What was Guido thinking: "Oh, I don't know, if it fails in the current namespace, then we'll try the next higher one..."? What??? Whyyyyyyy?

  • Aaron (unregistered) in reply to KattMan
    KattMan:
    If adding "the" to the variable makes it overly verbose then it is a problem, but if taken in context it makes sense, then leave it. This is a soft rule that can easily be followed.

    I mentioned that anyone wanting hard rules will always be wrong follows this also. Once you set hard rules, like you can't use "the" or "my" as prefixes for variables, there will come a time when one of your hard rules causes unnecessary obfuscation of variable names.

    I understand that nothing is a hard rule (that's why it's called software - ha ha), but I asked a simple question: give me one example where "the" is not redundant.

    Someone else pointed out the Singleton pattern. Actually, the way it was described by that poster is not the correct way to implement a Singleton; it should be a static accessor of the class, and it's almost always called "Instance" or "Current" or sometimes "Default" depending on the context. For example, you might use "HttpContext.Current" or "Settings.Default" or "Application.Instance".

    If you're working with a language that doesn't support this, then you're working with a language that essentially isn't fully object-oriented and hence the Singleton pattern is meaningless. However, for argument's sake, let's say you want to mimic this pattern with a global variable, then fine; the accepted notation for this is either "SingletonClass" (if you're working with a language like Delphi where the class itself would be called "TSingletonClass"), or "SingletonClassInstance" in other languages. Or, again, depending on the context, you might choose a variation of the static accessor names like "CurrentSingletonClass" or "DefaultSingletonClass" - but never "TheSingletonClass", it's meaningless.

    So I ask again - please provide one valid example of where the word "the" is not redundant, irritating cruft.

  • maht (unregistered) in reply to Khanmots
    Khanmots:
    And if your class is called Position? I'd much rather see thePosition used than position (note case)

    Personally I'd try to describe what the position is of... so somethingPos, but that's just me.

    You shouldn't need to track in your var names what sort of variable it is, just what its name is. the "sort of thing" it is should be encapsulated in its type

    Position *p, *active, *the;

    which highlights the discomfort of using pronouns for most non Perl coders.

  • Spacey (unregistered) in reply to maht
    maht:
    Khanmots:
    And if your class is called Position? I'd much rather see thePosition used than position (note case)

    Personally I'd try to describe what the position is of... so somethingPos, but that's just me.

    You shouldn't need to track in your var names what sort of variable it is, just what its name is. the "sort of thing" it is should be encapsulated in its type

    Position *p, *active, *the;

    which highlights the discomfort of using pronouns for most non Perl coders.

    That makes no sense at all.

  • (cs)

    What. The. Fuck.

  • (cs) in reply to Aron
    Aron:
    Here is the real C-array as a STL container:

    template <class T, size_t N> struct c_array {

    typedef T value_type;

    typedef value_type* pointer; typedef const value_type* const_pointer; ... }

    Which amply demonstrates that you can be effective without being obscure. This was pure pleasure to read, so thank you, Aron.

  • NormalTed (unregistered) in reply to Aaron
    Aaron:
    So I ask again - please provide one valid example of where the word "the" is not redundant, irritating cruft.
    It's useful:
    1. Within the actual singleton class as the local name for the singleton instance.
    getInstance()
{
    return theObject;
}
    1. To improve readability, when you want to keep a pointer to a singleton object that is otherwise accessible only through a verbose accessor.
    theApp = Application.getInstance();

    (Pretending that "Application" is an extremely verbose class name.)

  • Jon (unregistered)

    The real wtf has to be the indentation. Please tell me that's some quirk of posting it, and not as per the original code. It's hideously inconsistent!

  • (cs) in reply to Richard
    Richard:
    pm:
    making the non const iter derive from const iter is dumb

    It's not totally dumb. It gives you conversion from non-const iter to const iter, and comparison between them, for free. It also means you only have to implement the guts of operator++ etc. once (although the non-const iter still has to override it so it gets the right return type, sadly). It's a neat trick, but certainly not one I'm putting in any of my code -- it's too obscure.

    The Real WTF is using const_cast. I'm generally of the opinion that once const, always const (and therefore, const_cast shouldn't even exist, neither should it be possible to cast const away C-style). It is much cleaner to have the base class variable be nonconst (you don't even have to change the type of operator* in your const iterator, and just because it's a nonconst var doesn't mean you have to write it at some point), that way nonconst iterator doesn't have to uglyhack-away const which can break things sometimes (compiler optimizing away reference to const, for example).

  • (cs) in reply to maht
    maht:
    You shouldn't need to track in your var names what sort of variable it is, just what its name is. the "sort of thing" it is should be encapsulated in its type

    Position *p, *active, *the;

    Why? How to I infer the type of something when I'm reading my code? Do I stick it under my pillow at night and learn it through osmosis?

    So I'm reading along and I see: for(i = 1 to 10) active++; the = active; if (p == george) the++; end for

    I don't know what an active is, nor a the, nor p or george. do p and george share the same type?

  • (cs) in reply to Quietust
    Quietust:
    That's one of the neat things about template classes - any functions in the class that you don't use don't actually get compiled. I got bitten by this particular fact in a programming course several years back.

    The C++ standard requires them to be syntactically correct.

    Some compilers make the 'optimisation' of never bothering to compile a template that isn't instantiated -- but that is not something that you should rely on if you are trying to write portable code.

    The standard supports compilers that compile a template which can later, behind the scenes, receive the template parameters as arguments. However, most compiler vendors have not implemented this because it is difficult and there is little customer demand. Look up 'export' in the context of C++.

  • eighties (unregistered)

    It looks as if this code is from the ROOT framework: http://root.cern.ch/ The ROOT framework used to be written in FORTRAN, and has recently been ported to C++. Oh yes, and it's mostly used for High Energy Physics (HEP) analysis.

    Oh, and most of the source code (available on the site) resembles the pseudo-crazyness that the post elucidates.

  • dkf (unregistered) in reply to An apprentice
    An apprentice:
    C is dangerous and C++ is evil. This code snippet actually combines the worst of both worlds.
    You know, I've been staring at the code (on and off) for most of a day and I still can't actually pick out the WTF-iness of it, even having read other people's explanations (unlike with most other CodeSOD WTFs). I suspect that this is a mark of what makes the use of C++ into The Real WTF!
  • The Priest whodunnit (unregistered)

    Hi,

    Being the one who submitted this code, let me give you the executive summary:

    The major wtf is that the ".begin()" and ".end()" methods return different types - rendering the use of well established algorithms from STL totally impossible since they all require that the iterators you give them are of the same type, irrespective of whether the algorithm was intended for forward, backward, bidi- or basically any sane type of iterator class.

    In order to be able to anything with these "iterators" they overloaded the comparison operators == and != on the type that ".begin()" returns so it would be comparable with whatever ".end()" returns.

    Other wtf indeed is the derivation of the non-const iterator of the const version.... Apparently that is considered "good practice" by the coders since that construction is found in more than one instance.

    As for the "the" and "its" stuff: yeah it sux0rs but a coding convention for the whole package was decided upon long ago so you just have to go with that. 's a bum deal but with multiple developers spread over multiple continents and developers coming in and going out over time it's the only way to maintain some form of consistency.

  • David V. (unregistered) in reply to Edowyth

    Two words: Koenig lookup.

    C++ loses right to whine about namespaces if only because of that hack.

    Captcha: pirates. Yarr.

  • Diego (unregistered)

    I can't figure out why so many people blame the languages due to the programmers mistakes

    captcha: kungfu - well appropriate. IT people need more of this

  • (cs) in reply to Aaron
    Aaron:
    KattMan:
    If adding "the" to the variable makes it overly verbose then it is a problem, but if taken in context it makes sense, then leave it. This is a soft rule that can easily be followed.

    I mentioned that anyone wanting hard rules will always be wrong follows this also. Once you set hard rules, like you can't use "the" or "my" as prefixes for variables, there will come a time when one of your hard rules causes unnecessary obfuscation of variable names.

    I understand that nothing is a hard rule (that's why it's called software - ha ha), but I asked a simple question: give me one example where "the" is not redundant.

    Someone else pointed out the Singleton pattern. Actually, the way it was described by that poster is not the correct way to implement a Singleton; it should be a static accessor of the class, and it's almost always called "Instance" or "Current" or sometimes "Default" depending on the context. For example, you might use "HttpContext.Current" or "Settings.Default" or "Application.Instance".

    If you're working with a language that doesn't support this, then you're working with a language that essentially isn't fully object-oriented and hence the Singleton pattern is meaningless. However, for argument's sake, let's say you want to mimic this pattern with a global variable, then fine; the accepted notation for this is either "SingletonClass" (if you're working with a language like Delphi where the class itself would be called "TSingletonClass"), or "SingletonClassInstance" in other languages. Or, again, depending on the context, you might choose a variation of the static accessor names like "CurrentSingletonClass" or "DefaultSingletonClass" - but never "TheSingletonClass", it's meaningless.

    So I ask again - please provide one valid example of where the word "the" is not redundant, irritating cruft.

    First thing to remember, I am not defending any form of prefix or method of naming, neither am I saying I will deny any. You are attempting to force me to break my own rule and that won't happen. In a certain context, it could be seen that using "the" as a prefix might be valid, the other side of my statement does say that if it is meaningless, then remove it.

    This is a very soft rule as it is up to personal interpretation at times. If I concede and say that "the" as a prefix should never be used, then it is a hard rule, that at some point might be wrong. There is no telling the context of a variable within these rules, and even as the technology changes we need rules that, by their very nature, change with them. My form of this rule does this and I won't deviate even if I can not find an example that satisfies you.

  • (cs) in reply to Aaron
    Aaron:
    Or, again, depending on the context, you might choose a variation of the static accessor names like "CurrentSingletonClass" or "DefaultSingletonClass" - but never "TheSingletonClass", it's meaningless.

    So I ask again - please provide one valid example of where the word "the" is not redundant, irritating cruft.

    Actually you just provided it yourself. The following names all have the same meaning: CurrentSingletonClass DefaultSingletonClass TheSingletonClass

    The prefixes all mean the same thing here. It is simply your aversion to using "the" that makes it different. I say that using "the" is just as appropriate via my rule as it does not "make it overly verbose" while still "representing its purpose." If you will allow "current" why not "the", this is simply personal choice which has no place in the formation of soft rules.

  • Yuyo (unregistered) in reply to The Priest whodunnit
    The Priest whodunnit:
    Hi,

    Being the one who submitted this code, let me give you the executive summary:

    The major wtf is that the ".begin()" and ".end()" methods return different types - rendering the use of well established algorithms from STL totally impossible since they all require that the iterators you give them are of the same type, irrespective of whether the algorithm was intended for forward, backward, bidi- or basically any sane type of iterator class.

    In order to be able to anything with these "iterators" they overloaded the comparison operators == and != on the type that ".begin()" returns so it would be comparable with whatever ".end()" returns.

    Other wtf indeed is the derivation of the non-const iterator of the const version.... Apparently that is considered "good practice" by the coders since that construction is found in more than one instance.

    As for the "the" and "its" stuff: yeah it sux0rs but a coding convention for the whole package was decided upon long ago so you just have to go with that. 's a bum deal but with multiple developers spread over multiple continents and developers coming in and going out over time it's the only way to maintain some form of consistency.

    You forgot the fact that the increment operators are also broken since the following wouldn't compile:

    while (iter++ != end) { /* foo */ }

    which is fairly common code found in standard library algorithms.

    I'm not sure how some people are saying that this is not WTF material. Surely it might have not been a decade ago (even then, this is some POS code) but I hope no one is writing code that looks like this today.

    To be absolutely clear (since some people were saying these operators should return references and others saying it should return T), the pre-increment operator should return a reference to itself after having incremented, while the post-increment returns a copy of itself before being incremented. This is why it's always better to use the pre-increment operator on class types rather than the post-inc operator.

  • Yuyo (unregistered) in reply to Yuyo

    Hmm, reading my own post I realized the stupid example I posted. A correct example would be something like:

    while (iter != end)
{
  Iterator prev = iter++;
  // do something with prev and iter
}

    Particularly something like this may be used when you need to iterate in pairs. I left out checking if 'iter' wasn't equal to 'end' after the increment (or in the while condition) as to not clutter the example, but you get the idea.

  • Worf (unregistered) in reply to Aaron
    Aaron:
    So I ask again - please provide one valid example of where the word "the" is not redundant, irritating cruft.

    Windows gives plenty of fodder. I use "the" to help separate my variables from the types (which can often have the same name.

    E.g., look up the definition of WinMain in the Windows SDK, can you'll probably have something like:

    HINSTANCE hInstance

    which to me is a bit... silly (at least UNIX seems to have standardized on appending "_t" for types) since they really differ only in capitalization. I'd prefer my variables to actually be a bit more distinct than just capitalization (because you can forget to check "Case sensitive" and need to search for uses of a variable rather than including a variable declaration also), so I might write:

    HINSTANCE theInstance

    Of course, everyone KNOWS what WinMain's definition looks like, but if you're buried deep within code...

    And sometimes, an unoriginal name is the type name. E.g., in a function prototype for graphics, I might want something that looks like:

    BOOL ColourRectangle(HDC dest, RECT rect, ...);

    I dislike "rect" because it differs from the type by case only (and you KNOW someone out there has typed RECT RECT...), so I'd probably call the variable theRect. Which also helps me find instances of it by searching within the function, should many other RECT's be declared.

    And people who write multiple variables using slightly different casing should be shot. hInstance, hINSTANCE, ...

  • P-Dit (unregistered) in reply to Richard
    Richard:
    ...The WTF here seems to be that this class clearly wasn't tested in its intended use case -- and this is code which really needs careful testing, because it's hard to get exactly right.

    What - are you inferring that we should do test-based development? How dare you!!? Anyone with half a brain knows that the best way to impliment systems is to slap them together as fast as possible and immediately move on to the next project! 'Improving' the code is the job of Junior Maintainers, and development is the domain of the vain and clever - too clever to be slaving over such minor details...

  • Larry (unregistered)

    Ok...i keep reading this as Standard temple Library....

    Damn thing reminds me of the Vatican with the secret vaults and all....course it is 5pm here so I think my brain has gone home already...

  • Chris (unregistered) in reply to theDave
    theDave:
    Aaron:
    Okay then, give us an example of one situation where putting the word "the" in front of a variable name adequately describes what it holds without being overly verbose.
    The sole object of a class that follows the 'singleton' pattern can be usefully and descriptively named something like 'theObj', as in 
    Obj theObj;

    The convention that I've seen most often for Singletons is:

    Obj INSTANCE;

    This is particularly in Java code, but the convention appears to be common in C++ code as well.

  • Marc (unregistered)

    holy s***

  • RogerWilco (unregistered) in reply to eighties
    eighties:
    It looks as if this code is from the ROOT framework: http://root.cern.ch/ The ROOT framework used to be written in FORTRAN, and has recently been ported to C++. Oh yes, and it's mostly used for High Energy Physics (HEP) analysis.

    Oh, and most of the source code (available on the site) resembles the pseudo-crazyness that the post elucidates.

    I know a project similar to ROOT from Astrophysics. It's called AIPS++. It's also from the early nineties, it has some of the most advanced C++ I have ever seen, some real gems, but very hard to understand at times.

    While ROOT has been able to switch most of the community to the newer software, AIPS++ has made all the software management mistakes you can think of. So 15 years down the line, almost no-one uses it, most people are still stuck with software like Miriad and AIPS, which are so old that they do not know file systems, put the graphics on your TV and have input/ouput and program discs.

    The AIPS++ is filled with WTFs, not so much at the code level, but in how it was designed and managed. Maybe a story for another time.

    I have one final question to all forum readers, just to stay on topic:

    What C++ Array library would you recommend?

    I know of seeral projects that have rolled their own Array class (and sub-classes like Vector, Matrix, Cube), and I know the STL only provides vector, which is not sufficient. Is boost what I should be looking at, or is there some other library?

  • Simmo (unregistered) in reply to Aaron
    Aaron:
    KattMan:
    Faxmachinen:
    Yeah, adding "the" to "position" really clears everything up.
    And you sir suffer dearly from the "I wanna make a post without reading the post I am responding to" disease. This, regretfully makes you a total idiot. Hopefully by responding you will overcome this disability and realize that I addressed this problem in the portion of the post you felt necessary to remove.
    Your original post didn't address that at all. It was just a general statement saying "in some situations it might be better".

    Okay then, give us an example of one situation where putting the word "the" in front of a variable name adequately describes what it holds without being overly verbose. I'll grant you that it makes sense with myPosition vs targetPosition (although I think a better choice for myPosition would be currentPosition, or even just position since most people would infer that it's the current position when compared to targetPosition). But even granted that, how does thePosition clarify anything, in any circumstances?

    As the person who you're calling an idiot pointed out, the word "the" adds no meaning. It could be "the current" position, "the target" position, or "the original" position.

    I sometimes use 'theSomething' to indicate a singleton member variable object, as there is indeed only one Something and it is theSomething. Life's too short to spend time trying to think of clever names sometimes. I think that qualifies as adding meaning
  • Yuyo (unregistered) in reply to RogerWilco
    RogerWilco:
    ----------------------------------------------------- I have one final question to all forum readers, just to stay on topic:

    What C++ Array library would you recommend?

    I know of seeral projects that have rolled their own Array class (and sub-classes like Vector, Matrix, Cube), and I know the STL only provides vector, which is not sufficient. Is boost what I should be looking at, or is there some other library?

    Yes, boost::array is a nice wrapper around a fixed-sized statically allocated array that provides a nice interface. It's also going to be in C++0x.

  • Someone (unregistered) in reply to Richard

    "For those who don't grok C++ or templates, the problem with the code here is that the begin and end iterators are of different type"

    That is not the only problem. "void operator++()" and "void operator++(int)" aren't reall helpful, either.

  • Peter Y (unregistered)

    Shudder.

    I think the author was just guessing what C++ code to put in. Trial and error until the thing vaguely looks like it might be working. I didn't read all of it, lest I be corrupted.

    captcha: dubya

  • Paolo (unregistered)

    hmmm, this is the reason why i left c++ for c-pound hahaha

  • ger (unregistered)

    I was amazed about the comments made on this WTF, which showed a piece of code without any context. And it's the context that is important. Only some people tried to look through the code and made useful comments.

    Performance of for loops iterating over a container can be very important. Therefore it is important how one deals with the end() function. Many people use end() directly in the for statement which can have severe performance penalties. Doing that on e.g. boost's multi_array takes twice as much time than doing 

    iterend=container.end()
    beforehand and using iterend in the for statement. Maybe the same was true for this Array class and the author tried to safeguard against this (mis)usage of end(). It's too bad that some text books teach this bad practice.

  • daozi (unregistered) in reply to KattMan

Leave a comment on “History++”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article