-
May 31st, 2009
On the Challenge of Developing JavaScript Within a Team
I find one of the most challenging aspects of developing JavaScript in a team environment is cracking open someone else’s code and being able to work with it as if it was my own. Within the scope of a programming language we tend, often subconsciously, to define our own dialect to describe the things we build. This dialect is expressed in the names we give to the classes, functions and variables within our applications. The position of an underscore, the use of verbs, nouns and adjectives, whether something is singular or plural — all of these things (and so much more) affect our understanding of the intent of the original developer.
There can be vast differences between the dialects of two JavaScript developers on a single project, which is only amplified with each additional developer. Put together a team of five developers each working on different portions of the same application, or ten developers all working on various projects together, and without a set of coding standards and naming conventions, code quality and developer efficiency will quickly go down, replaced with a tangle of conflicting approaches that serve to undermine overall cohesion as developers inject their own dialect into the structures written in the dialects of other developers.
As JavaScript is a dynamic language, naming conventions become even more important as almost everything can become anything else at any time; this means that part of our job as developers within a team is to encourage the correct use of what we create through the subtleties of naming conventions and standards.
Aside: My biggest pet peeve is finding that a developer has named something “foo” in their application. Foo, an utterly meaningless word, describes nothing, and gives others absolutely no hint as to the purpose of that thing. The only way to figure out what “foo” might refer to is to follow that name back through the code, reading every single line, incrementally gaining insight into the intent of the original developer. Everything given a name should be named to expose the intent of that thing.
Over the next week or so I’ll be sifting through my code in an attempt to codify my dialect of JavaScript. I hope to better understand my current approach and illuminate any shortcomings and inconsistencies. I’ll post an overview of what I find, along with code samples for illustration.