Except JSLint. JSLint barfs all over otherwise valid JavaScript and provides really unhelpful error messages. For a minute, I thought that I forgot how to write valid JavaScript.... Hate! Hate! Hate! You're teaching folks to program, not write syntactically pure JS.
But drop that and the experience is great.
Before I added in JSLint, if you misplaced one semicolon or forgot a parentheses, none of the tests would run and it would just say "program failed". That was incredibly frustrating to me. I figured that if I was getting frustrated, and I was the creator of the tests, then random users would be REALLY frustrated. So I added in JSLint. Now you get line and column numbers for exactly where the syntax broke down.
I'm actually happy following all of JSLint's suggestions. But my first test user, my wife, had other thoughts. She filled out her first answer, saw the whitespace errors, and said "hells no". So I turned off the whitespace checking. She seemed OK with it after that.
Which checks in particular are annoying? I can change the default parameters of JSLint to be less strict about some things. But I don't want to give up syntax checking entirely.
var x = 5
eqeq: true
I created a successful bothC function that looks more like the simplified version of seqC, calling fC first. But when I switch to calling gC first, I get the following failures. Am I missing something, or is this a bug in the unit test?
PASSED No JSLint errors
PASSED bothC(S, S, A, B) === undefined
PASSED output === "SSA"
PASSED bothC(S, F, A, B) === undefined
FAILED output === "SSASFB"
PASSED bothC(F, S, A, B) === undefined
FAILED output === "SSASFBFSB"
PASSED bothC(F, F, A, B) === undefined
FAILED output === "SSASFBFSBFFB"Interested in seeing how my solution was off, and if I was thinking about it the wrong way. Any luck?
f_success = function() { gC(success, failure); }; f_failure = function() { gC(failure, failure); }; fC(f_success, f_failure);
For me, the trick here was to forget about the words "success" and "failure" because they have too much semantics embedded. I had to re-word the problem like this: call f3, if first argument of f1 and f2 are called. All other roads lead to f4. Both f1 and f2 has to be called in the chain no matter what.
Also, this is the first time I've seen such a pattern. Is there a practical application of such pattern? I think it's ok to have a single level of closure to continue execution, but if it goes to that many levels like the sample problem, it'll be a nightmare to maintain for people who have not seen your code yet.
var f = function () { return 0 }
/*jshint asi:true, eqnull:true, laxbreak: true */