Code-wise:
var comedy;
comedy = function(){...};
comedy();
The first two lines can be simplified into var comedy = function(){...}. If you don't need the function to be anonymous, you can even use function comedy(){...};. If this is the only place you are using this function, you can even go for an immediately invoked function expression: (function comedy(){...})() (at which point the name only serves as documentation). Separating the definition from the call may serve code structuring purposes, but I don't see the need to separate the definition and the declaration here.
OOP classes should use UpperCase names, so function DragRacer(...){...}. If I see a function named dragRacer, I don't expect it to be a constructor.
Prototype definitions should be written just after the constructor. Logically, they both are parts of a class definition. Technically, instantiating a class before it is fully defined could be problematic - if the constructor calls some prototype functions, the prototype needs to be defined before the constructor is called.
I am not well-versed in the motor sport industry, but it seems to me the function names rt and et are not very descriptive. You can get away with single-lettered variables used in function bodies (especially if they are math-heavy), but not in public facing method names. The function body can be simplified as well. Clarity will be maintained by the function name:
DragRacer.prototype.reactionTime = function () {
return Math.random();
};
chrisRT = chrisRT.toFixed(2); -- at this point, you are changing the type of a variable. While the compiler can handle that, you could reduce the developer performance. First, the semantics of a variable are dependent on where it is used in code. While it is not unusual to have variables change their values, here the meaning of the variable changes dynamically. Second, you might need the float value after you need the string value. In this case, you need two separate variables anyways. If you need help naming variables that only differ in types, you could borrow the hungarian notation: strChrisRT = chrisRT.toFixed(2);. The variable name is still somewhat cryptic, but at least you don't have to worry when to convert from float to string.
I am wondering why a drag racer's cocktail is not considered a drink. Blueberry Vodka in lime soda is surely a drink as far as I can tell.
if (chrisRT <= tonyRT) {
chrisRT = tonyRT + 0.09;
}
console.log(chrisRT);//test
console.log(tonyRT);//test
if (chrisRT <= tonyRT) {
chrisRT = 0.19 + tonyRT;
}
Here you have some redundant code. After the first condition body executes, the second condition body will not. If the first condition body does not execute, the second condition body will not execute either, because the condition is the same. In effect, the second condition body is a piece of dead code, and can be removed altogether. As a side note, I'm wondering why the constant is the left argument once, and the right argument the second time.
I know the purpose is to cheat, but the business logic here is weird anyways. Let me demonstrate with the following table; especially note the discontinuity around 0.00:
chrisRT - tonyRT | -0.02 | -0.01 | 0.00 | 0.01 | 0.02 || 0.08 | 0.09 | 0.10 |
-----------------------------------------------------------------------------
chrisRT - tonyRT | 0.09 | 0.09 | 0.09 | 0.01 | 0.02 || 0.08 | 0.09 | 0.10 |
from the user interface standpoint, confirms are not very nice. Since you are not using the return value, you could use an alert instead, but, if you want a nice interface, you could turn the code into being event driven and communicating via HTML. confirm("hello") => $messages.append($("<p>").text("hello")) (I am using jQuery, but you don't have to). Especially the initial storyline could be present in the initial document as a plain paragraph with a button that runs the javascript part.
Chris' favorite drink is Nitro Metane and 83 and 0.19 and 0.09 . "
I know these are only debugging messages, but still... what?
