4 ms·

I think this is the culture shock of not working with a compiled language. I mostly work in compiled, statically typed languages, and it can be a bit of a surp

by shubb 13y ago

I think this is the culture shock of not working with a compiled language. I mostly work in compiled, statically typed languages, and it can be a bit of a surprise in Javascript when you don't find out about a syntax error until execution just stops, half way through your application loading, because of some code in a function you didn't think was called. It's a surprise. But that doesn't mean it's wrong. We just aren't using the right tools - unit tests, JSLint, etc. Question to regular JS users - what do you do 'in place' of static checking?

kevincennis 13y ago
JSHint is helpful, especially (I think) for people who don't write a ton of JS. Unit tests are obviously important. I've been using Istanbul lately to check my test coverage, and that's made a big difference. It's awesome to be able to see, quickly, that "Oh. I'm not even testing half of this function." Sticking to some kind of style guide also helps. Idiomatic.js is a good starting point. Also, doing some basic checking on your own is often a good idea. Look at your arguments, make sure they're what you expect, and if now, throw an error. That'll make it a bit easier to see where your problems are, since you won't have to dig around stack traces as much.
oinksoft 13y ago
Some people use type-checking compilers like the Google Closure Compiler or Microsoft's TypeScript to perform static analysis.
MatthewPhillips 13y ago
jshint is static checking. It would have caught your syntax errors. Even catches when you do something stupid like define a new function inside of a for loop. As far as type checking, typically it's not needed and can be confined in functions that care about types, you just defensively cast to the type you need. Closure's also an option if you really make heavy use of types of your application.
twerquie 13y ago
Generally speaking, in dynamically typed languages, unit tests are the replacement for compile-time type checking. Type safety should not be a goal, duck typing is embraced and the correct behaviour is verified.
rgbrgb 13y ago
Yep, compilers turn out to be a pretty cool idea :). I don't think anyone's doing anything 'in place' of static type checking exactly. Oftentimes I'll check if a method exists on an object before calling it. Usually when I'm "type checking" I really just want to know if an object has a certain attribute. That gives a fair amount of flexibility because polymorphism is built in. I think by and large the errors that would be compile-time errors in a statically typed language are caught with unit tests (I use mocha). For front-end work, end-to-end testing has also gotten quite good and easy. Take a look at karma if you're interested in a good front-end testing workflow.

by shubb 13y ago

kevincennis 13y ago

JSHint is helpful, especially (I think) for people who don't write a ton of JS. Unit tests are obviously important. I've been using Istanbul lately to check my test coverage, and that's made a big difference. It's awesome to be able to see, quickly, that "Oh. I'm not even testing half of this function." Sticking to some kind of style guide also helps. Idiomatic.js is a good starting point. Also, doing some basic checking on your own is often a good idea. Look at your arguments, make sure they're what you expect, and if now, throw an error. That'll make it a bit easier to see where your problems are, since you won't have to dig around stack traces as much.

oinksoft 13y ago

Some people use type-checking compilers like the Google Closure Compiler or Microsoft's TypeScript to perform static analysis.

MatthewPhillips 13y ago

jshint is static checking. It would have caught your syntax errors. Even catches when you do something stupid like define a new function inside of a for loop. As far as type checking, typically it's not needed and can be confined in functions that care about types, you just defensively cast to the type you need. Closure's also an option if you really make heavy use of types of your application.

twerquie 13y ago

Generally speaking, in dynamically typed languages, unit tests are the replacement for compile-time type checking. Type safety should not be a goal, duck typing is embraced and the correct behaviour is verified.

rgbrgb 13y ago

Yep, compilers turn out to be a pretty cool idea :). I don't think anyone's doing anything 'in place' of static type checking exactly. Oftentimes I'll check if a method exists on an object before calling it. Usually when I'm "type checking" I really just want to know if an object has a certain attribute. That gives a fair amount of flexibility because polymorphism is built in. I think by and large the errors that would be compile-time errors in a statically typed language are caught with unit tests (I use mocha). For front-end work, end-to-end testing has also gotten quite good and easy. Take a look at karma if you're interested in a good front-end testing workflow.