Type check is a code smell

Will try to be brief, so it might not be clear unless you are experienced, will add more references at the end to make things clearer and maybe revise this subject later… - Time is a very limited resource nowadays.

How I got into this conclusion?

JavaScript is a dynamic (and confusing), language, the way inheritance and typeof and instanceof works is not clear to most developers:

typeof [1, 2] // 'object'
typeof null // 'object'
typeof 'foo' // 'string'
typeof new String('foo') // 'object'
'foo' instanceof String // false
new String('foo') instanceof String // true
new String('foo') instanceof Object // true

And things gets way more complicated when you have objects that come from different documents/frames (they are created using different constructors, so instanceof doesn’t work)… So because of that I started to avoid typeof and instanceof and ended up realizing how cleaner the code becomes when you avoid type checking.

PS: I know that we can use Object.prototype.toString.call() for type checking, I’m mainly saying that most type checks are a bad idea, doesn’t matter what is the implementation.

Read more…


Constructors should not cause side effects

Going to talk about something simple that took me a while to figure out I was doing it wrong. Don’t know when I realized it was a big mistake, I just know that it is something I’ve been trying to avoid for a while.

To begin, I’m not the first one to get into this conclusion. Many people before thought about the same thing, it is even one of the JSLint rules (“Do not use ‘new’ for side effects”). The thing is, I don’t think most people know the reason why this should be avoided; so let me explain why.

Constructors are not verbs

I believe that methods should be named as verbs, to make it clear that they perform actions.

new XMLHttpRequest doesn’t fire the request, new HTMLDivElement() shouldn’t append it to the document, … – Elliott Sprehn

Read more…


Callbacks, Promises, Signals and Events

Sometimes I get involved in discussions on twitter and Facebook related to development. This week I ended up sending a link to an old(ish) twitter thread explaining when to favor Promises/Callbacks and when to use Signals/Events for asynchronous operations. I think this topic deserves further explanation.

Read more…


Linked Lists for Dummies

On high-level languages like JavaScript we usually don’t care about how the objects are stored in the memory, we let the VM handle it for us, and since the language contains Arrays most users never find a need for Linked Lists even tho it’s a very powerful and useful data structure.

Like most front-end developers I don’t have a Computer Science degree and started to program using high level languages, it took me a while to stumble into Linked Lists, that’s why I’m going to explain the basic use cases, pros/cons of this simple data-structure and why it’s widely used. - You probably used it before without knowing.

This post was motived by this tweet:

Read more…


Mout & Modularity

Discussions about modularity are recurrent. Some people say that each function should be a separate module/file/package; others say that methods should be contained by a package and grouped by similarity/concerns; and there is still a 3rd group that thinks that a single namespace is the way to go. I will try to explain the design decisions that influenced the creation and current structure of moutjs and why single function packages are not always the best solution.

Read more…

  1. 1
  2. 2
  3. 3
  4. ...
  5. 9