We are getting into a discussion more related to pedagogics than any
factual problems in my text.
First of all, the text is not a lesson plan nor is it supposed toe be a
complete overview of every JavaScript quirk.
If anyone is interested, work has been progressing, with many good
suggestions on Githib by Raynos from this list:
https://github.com/itpastorn/programmering-1-med-js/blob/master/javascript-quirks.markdown
As for lint tools I do use them as well as the HTML and CSS validator in
class. It saves me as a teacher a ton of time. Whenever a student runs
into a problem I demand that they validate and/or lint their code first,
before they ask me for help. (not on day one, of course!)
In many cases this will help them fix the problem, which more often than
not is having something spelled badly or missing a semi-colon. Give me a
dollar for every semi-colon my students have missed and I'd be a rich
man indeed!
In some instances students do not know what the error means, but I will
as a teacher be abla to pinpoint the problem faster. And a learning
opportunity arises: "See how this code was fragile because you..."
In those cases where the error is not fixed by validation or linting at
least I get a better code to look at. It makes the next problem solving
step easier.
I even tell them to use the whitespace option in JSHint, even though
Crockford's rules are *not* according to my tastes. It has however two
benefits:
1. It forces them to indent their code. Many of my students really do
not think that indentation is necessary. It's just something "the
teacher says" or that they will "do later".
2. It enforces a visual difference between invocation of functions and
other usage of parenthesis. This too aids learning.
I used to be more relaxed about style rules, but having spent hundreds
of hours trying to chase down a problem in student code that is badly
indented, typed with no space[1] or mixes simple technical problems with
real functional ones has made me change my mind.
Lars Gunther
[1] Example of code that uses no white space at all:
if(foo<bar){baz=6*zoo;}
Read a few hundred lines like that daily and try to maintain your mental
health....
2012-01-14 01:31, Jared Hirsch skrev:
Hmm, at the risk of sounding a little flamey, I disagree. If you aren't
going to blow students away with something like SICP, you might as well
equip them to experience the joy and pain of building real products.
I'd even suggest you have them release code on day one of class via
heroku or no.de <http://no.de>, both of which host node apps in the
cloud and are generally awesome.
On Jan 13, 2012 3:39 AM, "gamera" <[email protected]
<mailto:[email protected]>> wrote:
I am against the use of linter in the context of teaching. Linters are
tools to aid production, in the context of teams with differently
skilled developers.
Teaching should be more about facts, and not shortcuts.
The ECMA-262 standard is a better source of information, IHMO, or the
excellent series by Dmitry Soshnikov.
see section #7.9.1/7.9.2 of ECMA-262 standard.
On Jan 13, 2012, at 12:57 AM, Lars Gunther wrote:
> Hi again
>
> It seems I have evangelized quit...
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/[email protected]/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/[email protected]/
To unsubscribe from this group, send email to
[email protected]
--
Lars Gunther
http://keryx.se/
http://twitter.com/itpastorn/
http://itpastorn.blogspot.com/
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/[email protected]/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/[email protected]/
To unsubscribe from this group, send email to
[email protected]
