It would seem to be in the spirit of the community to just fork one and make changes, but I won’t. The conclusion I’ve come to is that there is no one perfect style guide and the existing ones don’t seem to address the things that really make code hard to understand.

The idea is that adopting a single coding style will ease the development in a large team. Each team member will supposedly find it easier to maintain other team members’ code because they use the same “style” of coding. What does “style” even mean though?

an elegant, fashionable, or luxurious mode of living: to live in style.

That doesn’t sound right. Maybe it’s this one:

a particular kind, sort, or type, as with reference to form, appearance, or character: the baroque style; The style of the house was too austere for their liking. [src]

So, it seems to be concerned with the appearance, the visual form, the aesthetic etc.

Like everyone, I have my preferences when it comes to variable declarations and whitespace between operators but I will readily admit that what makes code easier to read for me might do the very opposite for someone else.

And I could get ridiculously pernickety about it too:

for ( ; i < l; i++ ) {  ...

You see the first semi-colon? Well, it doesn’t agree with me, aesthetically. I don’t like it. It’s given too much weight, nestled between so much whitespace. I think I’d prefer it to immediately follow the opening parenthesis. But, No! I cannot, for it doesn’t comply with the style guide! This isn’t the first time a style guide has bitten me.

That was petty, I know. Musing over an operator like an eccentric art critic would. I shouldn’t take these guides so seriously perhaps. After all, Style guides are “guides” only. They’re not commandments. But that’s just it! They’re not, and so why do we impress them upon our peers so religiously?

Just to repeat something: what makes code easier to read for me might do the very opposite for someone else!

Addy Osmani recently posted a very good overview of JavaScript style guides. To demonstrate one of the styles he took a piece of code and transformed it to comply with the guide. I found the resulting code to be harder to read than the former. This is just me, of course, but surely I can’t be the only one? In fact, the sheer amount of different style guides proves that I’m not the only one.

What style guides do a good job at is promoting conformance to something. It doesn’t matter what. At the end of the day what they aim for is consistency.

But, surely, code can still be consistently awful and difficult to understand. No style guide can help me understand how you think — how your mind forms algorithms — how you go about solving a problem using the path of least resistance. Reading other peoples’ code is eased only slightly by their conformance to a style guide. Only slightly…

A style guide will merrily slap your hand when you misplace a comma or semi-colon, but nothing will slap you when you form an incoherent API, or don’t put enough thought into your module’s design, or when you use DOM nodes to store program state. No. Nothing will stop you in these cases.

I know this isn’t a strong argument against style guides. And that’s fine. I don’t want to rid the world of them. I just want to say that they do not uniformly solve all problems and may sometimes make it harder to understand code.

In my opinion a style guide should be more liberal and steer clear of the realm of subjectivity. It should ensure an overall consistency and that’s all. Don’t tell me where to place something so tiny as a piece of punctuation, unless it has actual ramifications (like with the semi-colon debate). I will place the parenthesis as my mind instructs me — as my best judgement deems most understandable to the reader of my code. Otherwise I’m just a code monkey punching away as per instructed by sub-section 4.3 of that “style guide” you’re waving around.

I haven’t looked at Google’s source so I’m not sure how they chose to do it, but for me there was no other route more obvious than elementFromPoint, a DOM method that returns the element at any defined coordinate within the current viewport.

So, I create a bunch of little Zergling instances. Each Zerling searches for “targets”, i.e. any DOM element nearby. A Zergling instance will begin by looking in its close proximity, calling elementFromPoint at eighth-degree turns around a steadily increasing radius:

// (Zergling.prototype.findTarget)
 
for (radius = 10; radius < Zergling.VISION; radius += 50) {
  for (degree = 0; degree < 360; degree += 45) {
 
    x = this.x + halfWidth + radius * cos(PI/180 * degree) - scrollLeft;
    y = this.y + halfHeight + radius * sin(PI/180 * degree) - scrollTop;
 
    if (Zergling.isSuitableTarget(el = doc.elementFromPoint(x, y))) {
      // We have a viable target
      // ...
      break;
    }
  }
}

Any random element might not be a suitable target though. For example, we want to avoid other Zergling instances on the page. We also want to avoid anything too big, like the BODY element. I also added in an antiZerg feature so elements on the page can protect themselves from the zergs:

Zergling.isSuitableTarget = function isSuitableTarget(candidate) {
 
  var targetData;
 
  if (!candidate) {
    return false;
  }
 
  // Make sure none of its ancestors are currently targets:
  for (var parent = candidate; parent = parent.parentNode;) {
    if ($.data(parent, Zergling.DATA_KEY) || /antiZerg/i.test(parent.className)) {
      return false;
    }
  }
 
  targetData = $.data(candidate, Zergling.DATA_KEY);
 
  candidate = $(candidate);
 
  return !/zergling/i.test(candidate[0].nodeName) &&
    !/antiZerg/i.test(candidate[0].className) && 
    // Make sure it's either yet-to-be-a-target or still alive:
    (!targetData || targetData.life > 0) &&
    // Make sure it's not too big
    candidate.width() * candidate.height() < Zergling.MAX_TARGET_AREA;
 
};

Once we have a viable target we begin moving towards it.

calcMovement: function() {
 
  var target = this.target,
      // Move towards random position within the target element:
      xDiff = (target.position.left + random() * target.width) - this.x,
      yDiff = (target.position.top + random() * target.height) - this.y,
      angle = atan2(yDiff, xDiff);
 
  // Assign deltaX/Y (i.e. how much we move {x,y} on each step)
  this.dx = this.speed * cos(angle);
  this.dy = this.speed * sin(angle);
 
}, //...

On every step the Zergling needs to check whether it’s reached the target yet:

hasReachedTarget: function() {
 
  var target = this.target,
      pos = target.position;
 
  return  this.x >= pos.left &&
          this.y >= pos.top &&
          this.x <= pos.left + target.width &&
          this.y <= pos.top + target.height
}, //...

When a Zergling reaches its target it begins killing it:

if (this.hasReachedTarget()) {
  this.isKilling = true;
  return;
}

And the actual killing:

if (this.isKilling) {
  if (target.life > 0) {
    // It's still alive! Pulsate and continue to kill:
    target.life--;
    this.pulsate();
    target.dom.css('opacity', target.life / Zergling.LIFE);
  } else {
    // It's DEAD! 
    target.dom.css('visibility', 'hidden');
    this.pulsate(0);
    this.isKilling = false;
    this.target = null;
  }
  return;
}

Setting this.target to null means that the Zergling will begin searching for a new target on its next step.

To manage all the Zerglings I put together a ZergRush class:

function ZergRush(nZerglings) {
 
  var me = this,
      zerglings = this.zerglings = [],
      targets = this.targets = [];
 
  for (var i = 0; i < nZerglings; ++i) {
    zerglings.push(
      new Zergling(
        Math.random() * 100,
        Math.random() * 100,
        this
      )
    );
  }
 
  this.intervalID = setInterval(function() {
    me.step()
  }, 30);
 
}

All Zerglings start at random positions in the top-left of the page (anywhere from {0,0} to {100,100}).

As I said, it’s not very polished. The Zerglings are currently just little red dots, made like so:

// (in Zergling constructor):
 
// <zergling> element used to avoid CSS conflicts and because its cool..
this.dom = $('<zergling>').css({
  width: this.width,
  height: this.height,
  position: 'absolute',
  display: 'block',
  background: 'red',
  left: x,
  top: y,
  borderRadius: '5px',
  zIndex: 9999
}).appendTo(body);

Please visit the demo, see the source on Github, or save this bookmarklet for the future.

If I’m honest, I prefer long strategy but once in a while rushing is fun!

So, when one encounters an exception — someone that, for whatever reason, didn’t have X and Y knocked out of them, it comes as a shock and offence. Did nobody teach that guy not to pee while on public transport? Did they not tell you it’s wrong to make decisions based on race?

I think to myself: What’s abhorrent to me? What offends me deeply? Is it war, incest, racism, bigotry, apathy, rape? I know I’m right about my position on these things. I know it. My heart of hearts tells me it’s so. So I am right.

And if I’m wrong: will I let myself believe it?

We each believe we have a monopoly on the truth. We’re never willingly wrong. But what if you are wrong? An excellent quote from Kathryn Schulz’s TED talk “on being wrong“:

This is a catastrophe. This attachment to our own rightness keeps us from preventing mistakes when we absolutely need to, and causes us to treat each other terribly.
What’s most baffling and most tragic about this is that it misses the whole point of being human.
It’s like we want to imagine that our minds are these perfectly translucent windows and we just gaze out of them and describe the world as it unfolds… and we want everyone else to gaze out of the same window and see the exact same thing.

We hear opinions that we believe to be wrong; they may even offend us deeply. We can accept this though — we shrug it off as an opinion. “It’s just someone’s opinion. It’s fine. People can believe what they want.“

But when someone does something we see as terrible — when they enact the feelings and desires in their heads, this is when we get mad! “How dare he!”

What did he do wrong though? Was it the opinion, the feeling, the desire that was wrong, or was it simply acting on it that made it a sin?

This relativism and doubtfulness is unnerving.

Maybe that’s why it’s so soothing to work with absolutes: like the obvious truth that you should use semi-colons and stop relying on ASI… kidding! You see, even here, in our cushy little world there are still offensive beliefs.

EDIT: made it simpler. (Now mixin: jQuery.eventEmitter instead of jQuery.EventEmitter.prototype.)

(function(jQuery) {
 
  jQuery.eventEmitter = {
    _JQInit: function() {
      this._JQ = jQuery(this);
    },
    emit: function(evt, data) {
      !this._JQ && this._JQInit();
      this._JQ.trigger(evt, data);
    },
    once: function(evt, handler) {
      !this._JQ && this._JQInit();
      this._JQ.one(evt, handler);
    },
    on: function(evt, handler) {
      !this._JQ && this._JQInit();
      this._JQ.bind(evt, handler);
    },
    off: function(evt, handler) {
      !this._JQ && this._JQInit();
      this._JQ.unbind(evt, handler);
    }
  };
 
}(jQuery));

It’s a mixin, and you can use it like so:

function App() {
  // do stuff
}
 
jQuery.extend(App.prototype, jQuery.eventEmitter);
 
var myApp = new App();
 
// myApp supports events!
 
myApp.on('someEvent', function() {
  alert('someEvent!');
});
myApp.emit('someEvent'); // 'someEvent' alerted

Feel free to change the property/method names. The stuff prefixed with _JQ should not be accessed publicly and should avoid conflicts with your objects. I guess you could use jQuery’s expando to hide them better. Or, alternatively, if performance is less of a concern, you can re-construct the jQuery object on each method-call instead of saving it.

When destroying your object be sure to call jQuery.removeData(myObj) too.

A response from the Mozilla CTO, who recently underwent criticism for his support of Proposition 8, concludes with the following:

So I do not insist that anyone agree with me on a great many things, including political issues, and I refrain from putting my personal beliefs in others’ way in all matters Mozilla, JS, and Web. I hope for the same in return.

This seems like an agreeable statement but the matter at hand is crucial here. Regardless of the specific reasons Brendan had for supporting Proposition 8, the fact is, nonetheless, that he did.

And this particular constitutional amendment would come to define marriage as only between a man and a woman. This is seen as freedom-inhibiting and discrimanotory by many opponents.

So, it is but with a touch of irony that Brendan’s closing remark comes across. He states that he doesn’t want his “personal beliefs in others’ way”. Granted, he is referring to Mozilla, JS and Web, but the irony still reeks.

It seems like a lot of logical footwork for Brendan to maintain this ideology with web-related topics, but an entirely different ideology with issues of equaity and politics.

I find it funny how it’s now politically correct to entirely avoid politics in almost all matters. A person would be labelled as immature, perhaps, if they were to let their political beliefs get in the way of other more “productive” things.

It is a huge double standard to silence political dialogue with one hand yet sing the praises of an open, free, and just web with the other. And this is what Brendan seems to be doing.

Yes, fine. You can have your opinions. You can have your community where peoples’ opinions do not get in the way. But you can’t proclaim this principle and at the same time seek refuge behind it for previous actions that are entirely incompatible with this very principle.

It is logically inconsistent. That is all I wish to point out.

Robert Merton, a well-known sociologist, established a set of norms that characterised the scientific community. One of these norms was communalism — communal ownership and willing sacrifice of intellectual property for the betterment of the field and humanity.

This is a good principle to follow. It furthers humanity’s progress via a method of sharing based on equal say and equal access. It is, at the very least, a respectable and ethically sound principle to aim for.

The open source movement follows this very principle. We, in the web development community, are not strangers to the strengths of open source.

The programming book publication machine, another thing well accepted and prevalent in this community, runs in opposition to the tenets of open source that we should be striving for. Why do we allow this?

In an ideal world — and there is no good argument for heading in any other direction than ideal — knowledge should not have a single barrier to access, including money. Why should we be so accepting of passively discriminating against those without the means to know what we know?

Yes, we live in a world of dollars and euros, but has that stopped the open source movement from gaining popularity and wide acceptance? No. And since when was it acceptable to forgo progress for the sake of an unfair and unequal status quo?

We should continue, in the same fashion as we have with FOSS, by making the idea of paid-for knowledge abhorrant. The best place to start is in what we do day-to-day.

There are always excuses and some of them are reasonable. There are people who make a living selling knowledge. For such people it would be a fight between principle and survival/comfort. We know which one wins. For many of us though we have the luxury of abiding by the principle in the vast majority of what we do.

We should continue to pursue free and equal access to all knowledge.

So, before you write your next book and put it behind a pay-wall, consider the principles you wish to live by.

It was not a shock to discover that most people that received word of the survey and took it are knowledgeable in JavaScript. In fact, 81% of people that answered the survey know JavaScript to a high level.

Here’s the rundown of the first question, “What languages do you know to a high level?”:

And here’s the second, “What languages do you want to learn?”:

People could select more than one checkbox, e.g. Bobby wants to learn C++ and Ruby…

Also, “high level” is ill-defined, so is liable to subjective modesty and vanity alike.

Overall there were 77 people that took the survey, and from the survey results plus various other comments it seems that there is interest for *something* to help us pick up alien programming languages/platforms, but we’re just not sure what.

If you’re interested in further pursuing this speck of an idea, please feel free to go ahead. Right now I’m limited on time. I would be very interested in a platform enabling such an exchange. I am sure that it would garner some interest within the community too. I can’t promise anything though.

I am personally looking for someone with an immense knowledge of Perl to tutor me via Skype. But this person should also be yearning to learn JavaScript to a high level. If such a person exists, please contact me.

The idea: You know language X and you want to know language Y. So, this platform/community enables you to “pair up” with someone that knows language Y and wants to know language X. I’m surprised nothing like this exists yet. If you’d be interested please fill out this form.

So the convention requires that instead of this:

var ccc;
var aaa;
var bbb;

… you do this:

var aaa;
var bbb;
var ccc;

By ordering the variables alphabetically we have supposedly made it easier to find variable names.

I should probably use a real world example to demonstrate its true benefit, so here’s a chunk of variables from jQuery:

var rformElems = /^(?:textarea|input|select)$/i,
    rtypenamespace = /^([^\.]*)?(?:\.(.+))?$/,
    rhoverHack = /(?:^|\s)hover(\.\S+)?\b/,
    rkeyEvent = /^key/,
    rmouseEvent = /^(?:mouse|contextmenu)|click/,
    rfocusMorph = /^(?:focusinfocus|focusoutblur)$/,
    rquickIs = /^(\w*)(?:#([\w\-]+))?(?:\.([\w\-]+))?$/;

They’re using some quasi-hungarian notation which, it could be argued, negates the benefits of alphabetical ordering, so let’s remove all of the r prefixxes so that we’ve got a good example to work with:

var formElems = /^(?:textarea|input|select)$/i,
    typenamespace = /^([^\.]*)?(?:\.(.+))?$/,
    hoverHack = /(?:^|\s)hover(\.\S+)?\b/,
    keyEvent = /^key/,
    mouseEvent = /^(?:mouse|contextmenu)|click/,
    focusMorph = /^(?:focusinfocus|focusoutblur)$/,
    quickIs = /^(\w*)(?:#([\w\-]+))?(?:\.([\w\-]+))?$/;

Okay, now let’s re-order according to the convention:

var focusMorph = /^(?:focusinfocus|focusoutblur)$/,
    formElems = /^(?:textarea|input|select)$/i,
    hoverHack = /(?:^|\s)hover(\.\S+)?\b/,
    keyEvent = /^key/,
    mouseEvent = /^(?:mouse|contextmenu)|click/,
    quickIs = /^(\w*)(?:#([\w\-]+))?(?:\.([\w\-]+))?$/,
    typenamespace = /^([^\.]*)?(?:\.(.+))?$/;

Did you notice the difference? The convention suggests that it is now easier for programmers to come along and find the variable focusMorph because it is within an alphabetically sorted list. I have doubts about this though.

For me, this variable list is no easier to navigate than before. I’m probably below average in “alphabet skill” though. Sometimes I find myself reading out the alphabet internally so I can try to remember if K really does come before M. It’s sad but true.

It could very well be that this is just one of those things that only affects me. And that’s fine. I still would like to continue with my exploration of this convention though.

This convention can become a problem when, for example, one variable depends on a previous variable’s assignment. For example:

var radians = foo.getRadians(),
    angle = radians / Math.PI * 180, // we need radians to be defined
    ...;

With the convention applied:

var angle = radians / Math.PI * 180,
    radians = foo.getRadians(),
    ...;

But that doesn’t work anymore. When the first line runs, radians is undefined. Of course, in this example, I could just get rid of the radians variable and use foo.getRadians() straight off. Yes, I could do that. But this is just an example, and I have battled with this quandary many times without such simple solutions.

So, strictly, how does one solve this, supposing it was a trickier case? Actually, wait — let’s explore why we’re solving this. Is this a programming problem? Nope, this is an issue born from tireless compliance to standards and conventions.

Is it worth fixing? Shall I? –

var angle,
    radians = foo.getRadians(),
    ...;
 
angle = radians / Math.PI * 180;

I fixed it! The variable declarations are in order. But at what cost? I’ve moved down the actual assignment of angle to after the declarations.

But doing this would not serve the convention’s purpose because we haven’t made it easier to find angle = ....

Okay, so I guess the correct thing to do would be to rename one of the variables so that they’re ordered correctly. Now, I’m sitting here thinking of what I should name a variable. I’m looking for a word that means the same as angle but starts with a letter beyond r. This is starting to feel less like programming and more like a game.

Let’s be honest though. Nobody is going to have trouble finding either of these variables. There are only two. And I would argue that the jQuery variable block is also easily navigable.

As programmers, surely it is our responsibility to ensure that our code is well abstracted and that we separate our concerns. If we do this effectively we should rarely end up with lists of more than five variables in each function/method, give or take a few.

If you have a list of variables that is difficult to navigate then you’re problem isn’t going to be fixed by applying a convention — it’s going to be fixed by abstracting code and separating concerns.

Also, more often than not, the way in which I order variables is governed by the way in which they relate to each-other, semantically, and the functional story that is told through their assignments, e.g.

var data = getData();
var id = data.id;
var base = getBaseById(id);
 
// [rest of the function]
// usage of `data`, `id` and `base` etc.

A story is told through variable assignment, just like it is through flow control.

At least in my personal code I make it a policy to not let conventions have undue authority. I don’t code for conventions. I didn’t make this website so that it would pass HTML validation. I don’t worry about JSLint. I don’t lie awake at night wondering where I’ll find that lost semi-colon!

What I do worry about is creating functional and readable code. Sometimes it’s difficult and I end up with a mess. But that mess isn’t going to be fixed by stringent coding standards — it’s going to be fixed by repeated application of my programming abilities to abstract and separate.

Perfecting my route only took a week of practice and within no time I had it down to a ninety-minute sprint, but bad days could lengthen it to a full two hours. A potential four-hour commute each day is huge, especially if the destination is neither friendly nor enjoyable. Of course, I shouldn’t complain. At any time I had the luxury of leaving with little or no repercussions. A minimal-commitment contract is a great thing when you’re working in a thankless technical role in an office not made for comfort, but for new-age openness. At any time you can see and hear twenty-odd people tapping away, sipping at their vices, and mindlessly badgering on about something that has nothing to do with anyone else in the room. I craved an office of my own so badly.

Everything about the layout of the office, the facilities, the chairs, the decor, the agency culture… all of it screamed a wretched ignorance of ideal working conditions. It’s painfully wonderful to watch as my very own passion for something as seemingly dull as JS is sucked dry by idiotic requests, mundane tasks and a socially hostile working environment. It’s invisible most of the time, but the really tiny things make a difference. I am almost entirely sure that I wouldn’t have lasted the full two months if not for having a desk (or rather, a contemporary-styled bar and bar-stool setup) next to a window.

You see, the window is what reminded me, every few minutes, that this thing I’m tapping away on isn’t the world, and neither are the people around me. A frequent dose of perspective enabled me to keep my sanity. The window overlooked a hostel so I could distract myself by peering at the comings and goings of guests, each from different cultures, walks-of-life, and each leading lives, at those moments, far more interesting than the one I was silently avoiding as it sat baring bugs and browser inconsistencies before me.

I can only introspect or guess at what other people tell me. I, for one, find that my motivation fluctuates. It doesn’t sit still for eight hours as I’m required to. Most days commuting home were spent wondering why on earth we still make things so unbelievably difficult for ourselves. Actually, it’s no wonder at all. It’s not us. It’s them. The ones who decide that you should have to come in and work at the desk, live at the desk, eat at the desk, be the desk. You may as well be, because to “them”, in traditional (but still widely pervasive) business-management models, you are just an occupier of a desk and a fixer of bugs.

I said no to what seemed like a collective silent social contract which required everyone to eat at their desks while continuing work or forgo lunch and opt instead for the seventh red bull. It felt liberating just to leave for lunch everyday. This feeling never faded over time. I loved the first breath of fresh air at lunch and when leaving to go home in the evening. Freedom!

So, the two months did eventually finish and I felt giddy from the relief. I knew that this wasn’t normal. It shouldn’t be such a struggle, I thought, surely! This commute, this work, everything was dry and spent in my mind. I didn’t want any of it.

With time I realised that the mental grief of the daily haul to work could be eradicated by working at home. This had an unbelievably huge array of added benefits. The big struggle would be finding a job that would allow me to work at home while pursuing the passions that, thankfully, I still held.

After some time I got that very job I was looking for. Uxebu, an entirely-JavaScript company, based in Munich, employed me. I’m able to work completely at home. The benefits of working from home included:

• I gained X hours every day from not having to commute!
• I can stand up and stretch at any time without creating a spectacle
• I can change my working environment whenever I please. I can sit on the chair, lie on the floor, go outside (a laptop does help with this).
• I can wear what I want.
• I can model my entire environment to suit me. The music, the light, the decor, everything.
• I can crawl out of bed on a bad morning and still not be late for work.
• I can take a long cycle through London parks, tasting fresh air, instead of spending hours in the stuffy London underground.
• I can spend more time with my family while not commuting.
• The list goes on…

The benefits so vastly outweigh the cons that I am in no doubt that as long as I do this for a living I will favour this setup. Not everyone is like me though. For some, the office environment suits. For me, though, working from home seems to suit.

The key thing about the list above is that every one of those items enables me to be a better worker, a happier person, a healthier person and a more passionate person because there are less things sucking my motivations dry.

A giddy and hopefully long-lasting farewell to the London commute!