Quote:Original post by nullsquared

Quote:Original post by Giedrius
saves you the time of going to see their declarations,

You mean the 0.2 second mouse-over tool-tip delay? Or the 0.2 second right-click -> go to declaration/definition?

Sorry for the late reply. If you know the right keystrokes (for me F12 under MSVC (at work!), F2 in QtCreator, e.g.), it is just 0.036 seconds.

Quote:Original post by AristeOr:

final = ballVel.Dot(dir);
final = ballVel.Cross(dir);
final = ballVel * dir;

And this way I don't have to backwards-deduce the nature of the operation by means of its return type. The only place where ambiguity might arise is in the last line (where ballVel could be either a float or a vector), but this is easily fixed by properly naming the variable:

final = ballSpeed * dir.

Speed vs. velocity is exactly what I meant by misleading names.
Basically, the problem boils down to people not being reliable. You can’t trust them to write meaningful names, lots of comments, non-ambiguous code, etc.
These are real-world examples that people commonly do, like it or not.

Even with naming conventions, people will be unreliable and make mistakes, but naming conventions are concrete in that the “what to do” can be clearly and explicitly defined. That is, “use meaningful and non-misleading names on variables” is a lot harder to follow than, “put a ‘p’ in front of pointers”. Aside from “misleading” being a relative term, some people simply don’t know about or think about the differences between “speed” and “velocity”.
If a person is likely to make mistakes on simply following a naming convention, he or she is probably more likely to also make mistakes related to improper naming, ambiguous overloading, etc.
Combine these mistakes with no naming conventions for a brew that will knock you off your feet in seconds.


L. Spiro

Quote:Original post by Ariste

Quote:Original post by YogurtEmperor
...

Or:

final = ballVel.Dot(dir);
final = ballVel.Cross(dir);
final = ballVel * dir;

And this way I don't have to backwards-deduce the nature of the operation by means of its return type. The only place where ambiguity might arise is in the last line (where ballVel could be either a float or a vector), but this is easily fixed by properly naming the variable:

final = ballSpeed * dir.

Or perhaps better still:

final = dot(ball_velocity, direction);
final = cross(ball_velocity, direction);
final = ball_velocity * direction;

Member functions don't always make for the most readable APIs IMO -- In general, I only use member functions when I'm modifying the internal state of the invoking instance, and everything else is a non-member, non-friend inside the same namespace as the class it operates on -- which makes it as much a part of the class interface as a member function.

I just want to be clear.

Revisions to my sample are not unwelcome, but I don’t want the point of the code to be lost.
There are millions of ways to write code when you are in control, but, as Grafalgar reiterated, reading code is usually hardest when looking at code someone else wrote, which was the context of my example(s).
Without a doubt, you should be able to read your own code, regardless of any bad practices you may have used (ambiguous operators or not) or not used.

My examples are what you really may encounter when browsing other peoples’ code, if you are a professional game developer. And yes I threw in that misleading name (speed vs. velocity) on purpose as a compound example of mistakes people make. It’s common. People do that all the time, and you can’t always go by names to clarify code.


[EDIT]
I also want to reiterate the purpose of naming conventions in the first place. Naming conventions are first and foremost for the benefit of other people who have to read your code.
It is assumed that you yourself can read any style you use, and you can look at code and recall the idea you were expressing at that time, with or without name prefixes.
Additionally, code that “reads like prose” is subjective. Everyone thinks his or her code is clear and beautiful. A clear name to one may not be a clear name to another (speed vs. velocity comes to mind again here). What is prose to you may be nails on a chalk board to another.
And this applies to art, music, and everything else. We can’t grade our own code. We can’t rate ourselves.

Forget the fact that you are writing the code. Think about others who are going to read it later. Other people may not have the same IDE as you. Other people might not be as fast as you at clicking this or that. Other people don’t hold an encyclopedia of variable names + types in their heads as well as you do, and may end up having to re-check the type information of a variable several times.
[/EDIT]


L. Spiro

[Edited by - YogurtEmperor on April 28, 2010 6:27:23 AM]

Quote:Original post by DevFred
so the entire discussion becomes rather meaningless.

It should be clear now for sure.

I mean this shit always goes this far. At least once in every months. Aren't you bored of this already? (You means everybody, even the 'veteran' users participate it these meaningless flamewars. All the time...)