• March 9th, 2010

    JavaScript Naming Conventions For People With Beards

    When developing in a team environment, coming to an agreed-upon set of naming conventions is incredibly important. The speed at which we as developers can come to comprehend the thought-processes and intentions of our peers greatly depends on our ability to look straight to their intentions, rather than having to first read the code line by line, mentally translating it into our own dialect, before truly understanding.

    In short, Aaron Cruz, here is a quick summary of the naming conventions which I adhere to:

    var MyClass = Class.create({
  initialize: function(arg1, arg2) {
    this.publicProperty = "'Public' property";
    this._privateProperty = "'Private' property";
    var localVariable = null;
  },

  publicMethod: function() {
    return "'Public' method";
  },

  isBooleanMethod: function() {
    return true;
  },

  _privateMethod: function() {
    return "'Private' method";
  },

  __eventHandlerMethodClick: function(e) {
    return "Click-event handler method";
  }
});

MyClass.classProperty = "Class-level property";

MyClass.classMethod = function() {
  return "Class-level method";
}

MyClass.MY_CLASS_CONSTANT = "CONSTANT's should never change";

MyClass.ClassEnumOrSubType = {
  value0: 0,
  value1: 1,
  value2: 2,
  value3: 4,
  value4: 8
}

    While the above example uses the Prototype class structure, none of the principles themselves are Prototype-specific.

    Posted in Code/Projects, JavaScript | No Comments »

  • Hatin’ on textContent and innerText

    June 1st, 2009

    It’s surprisingly annoying to get just the text content of an html element in a cross-browser friendly way. I wrote Element#getTextContent() to take care of this simple operation for me.

    The Prototype Version:

    Element.addMethods({
  /**
   *  Element#getTextContent(@element) -> String
   *  Cross-browser means of getting Element#textContent or Element#innerText
   **/
  getTextContent: function(element) {
    if (!Object.isUndefined(element.textContent)) {
      return element.textContent;
    }
    return element.innerText;
  }
});

    The Procedural Version

    /**
 * Gets the text content of the specified element.
 * @param element {HTMLElement} The html element
 * @return {String} The string content of the specified element.
 */
function getTextContent(element) {
  if (typeof element.textContent != "undefined") {
    return element.textContent;
  }
  return element.innerText;
}

    Posted in Code/Projects, JavaScript | 6 Comments »

  • On the Challenge of Developing JavaScript Within a Team

    May 31st, 2009

    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.

    Posted in JavaScript | 4 Comments »

Un-Dumbify