I’ve noticed a trend lately among web developers. Certain practices are considered to be acceptable or even preferred, despite the fact that they yield no significant actual benefit to either the developer or the end user, and in fact often constitute at best inconsistency among the developer’s practices, and at worst, a complete bastardization of the language in question.

If I may rant for a bit, here are a few of these practices:

  1. Code that reads like a sentence.

    Too often I have seen PHP code like this:

    $someObject->load->thing('which_thing');

    $someObject here is an instance of a class (assume the name of $someObject gave you some idea what it was; I’m not complaining about variable names). This class has a property called “load” which is ostensibly some other object with a method called thing() whose responsibility is to load that thing. Since we are programmers who understand the syntax we are able to determine all of that and yet, the line of code reads like a sentence, so even non-programmers can read it! Clever, isn’t it?

    No, it isn’t. Stop it. Why do you think it is important that your code read like a sentence? Who exactly is going to read this and understand it only because you’ve written it this way? Ultimately what you are doing is causing the reader to ignore the programmatic constructs and read your code like a book. This might sound useful to you but actually could cause just as much confusion as it eliminates, particularly if you start using words that can be either nouns or verbs, like, oh, I don’t know… “load” or “view”.

    Consider this code fragment:

    $this->view

    What is it? If your approach to naming your class’s properties is to achieve the goal of having your code read like a sentence, then this property could be either an object that contains methods that allow you to view certain things, or it could simply contain data (either in object form or a primitive datatype) representing the “view” attribute of the current object. There is simply no way to know without documentation. Certainly I’m not advocating writing code without documentation, but wouldn’t it be preferable for the code and the documentation to just reinforce each other rather than always having to rely on comments?

    Perhaps a worse example is this:

    $this->view('something');

    Looking at this code, it really looks like we are going to view something. But using these silly naming conventions, it’s possible that the view() method doesn’t actually view anything; rather, it actually does whatever this class’s attribute is called in some other class (maybe it’s load, maybe it’s build, maybe it’s delete, maybe it’s sort… could be anything) and the object it acts upon is a view. If that sounds confusing, that’s because it is confusing.

    Fundamentally, properties should be things or measurables and methods should be instructions. If you want your class to provide access to the methods for loading this type of thing, then the code should look like this:

    $someObject->load_thing('which_thing')
    or…
    $someObject->load('thing', 'which_thing')

    Both of these are just as readable as the first line to anyone reading your code for the first time, and they have the added benefit that they don’t have the possibility to mislead you about what each step achieves.

    Of course this means those methods are muddying up your delightfully elegant class definition. You can still separate them if you feel you have a reason to, but you should be explicit about what you are doing:

    $someObject->loader->load_thing('which_thing')

    Yes, I know there is an extra word in there (“loader”) but for pete’s sake, you are a programmer, not an author. You don’t write sentences; you write code. If the property is a loader, then doggone it, call it a loader and not a load and have its methods named such that your methods make sense in every context, even contexts where you don’t think your code will ever be used.

  2. Overuse of OOP.

    Listen, I like pretty arrows and scope resolutions as much as the next guy, but when I’m building a web application that lives for about a tenth of a second each time it’s run, I don’t want the overhead of loading up objects with all their properties if I’m not going to use them. This is why I have rejected the MVC in favor of … VC. Yeah, just throw out the model. If there is a portion of code that you need to reuse, then reuse it! I’m not saying don’t have objects and I’m not saying don’t reuse code. You can create functions in PHP, namespace them if you want to, or just throw static methods into a helper class and don’t instantiate it.

    A model-based approach focuses on fail-safe retrieval and modification of attributes, and often pedantic adherence to your application’s specific requirements even when you can be 100% certain that no checks are necessary. The model probably always populates all of its attributes (I sound very certain, don’t I? Feel free to correct me). I very much prefer to have direct control over my interaction with my database. When you query directly, you retrieve exactly what you need (and yes, it makes a difference, especially if you are — or might ever be — dealing with a non-trivial quantity of data not on your local network). If the query fails, an exception is thrown which you can handle. If not, you have your data. It’s fast, effective, and since you have direct control over the actual SQL, very easily optimized.

    For a simple view, like displaying a user profile, it’s probably not a significant difference. But when you are displaying data joined from multiple tables, one of two things is going to happen:

    1. You use your basic class constructors to load the data separately from each table, or
    2. You write a custom method just for this view.

    The first has clear scaling issues and the second adds needless complexity or at least inconsistency to your application. Just retrieve data directly from your database whenever it is needed.

  3. Too much emphasis on semantic markup.

    This one probably sounds ironic since just a few paragraphs ago I was emphasizing a semantic approach to property naming. But that was in PHP where the only limit to your code’s functionality is your imagination and you are free to use any name you want. I would suggest a similar approach if you are transmitting data in XML or JSON formats: your variables’ names should be a fair representation of what they contain.

    But HTML? Come on. I challenge anyone to create an HTML document that contains all of the data needed for a page in pure semantic markup (feel free to include “class” attributes as you do this, but otherwise, all of the tags should serve no purpose but to describe the content they contain), then hire a third party designer to design a page containing those elements (no restrictions) and then create a stylesheet that will cause that document to be formatted in the way the designer intended, without any changes to the markup. Why can’t you change the markup? That would defeat your goal: to have the HTML be a semantically true representation of the data and the CSS to contain all of the information needed to display it in a browser (or on a page).

    As soon as you are forced to create a container div, a spacer gif, a line break, or any other change to your markup for any purpose other than describing what the content is, you admit that it is often necessary to include some elements in your markup exclusively for the purpose of forcing your page to be displayed properly in a browser, contrary to those elements’ semantic purpose. Whether those elements are the web-development-politically-correct DIVs or SPANs, or the downright-evil TABLE elements is irrelevant; you have used an element for something other than what it was originally intended to be used for.

    I don’t say this to fault designers or CSS purists; it is a fundamental fault (multiple faults, really) in HTML and CSS that should have been solved long ago by tossing CSS straight in the trash and coming up with something much more useful, more flexible, more powerful. Joe Hewitt tweeted a bit about something to this effect back in May, but I don’t believe anything has come of it yet. If and when it does, HTML will meet a very swift demise. Until then, we would be wise to accept that we cannot expect it to be simultaneously semantic and fully styleable; you can have one or the other and as long as you are delivering your content to browsers, I suggest you choose style.

Categories: Opinion

Leave a Reply