--- layout: post title: Collaboration in development tags: [ development ] published: true --- I usually write after something big approaches me. This could be no bigger: _collaboration is not considered when developing_. Well, at least not lately. Here's what happened: [Roger Byrne](http://styl.eti.me) asked me to check a plugin and help him in a submission form. Roger said to me that the Javascript inside the wordpress instalation he already had was obtrusive and he needed to render the form with CSS only. So I did it; I delivered. He asked me why the form wasn't submitting. I didn't know because I didn't make the plugin. In either way, the plugin was kind of a mess. Between lack of standards and lack of a plugin workflow, me and Roger didn't figure out what was happening. So what do I mean with all of this? Again, collaboration is not considered when developing. Developers assume their code is flawless and it will work. However, they don't take a look at crucial guidelines of development: (Note: I'm thinking of plugins as I write this, but any situation is perfectly suitable.) Logical separation ------------------ Logic, content, generated content (different than just content), presentation and behaviour all set apart. Logic goes to one PHP file, content goes to one markup file, presentation in a CSS file, special behaviour in a JS file. Generated content can be either part of the CSS or the JS, depends on what's its purpose. Concerning classes… ------------------- _Concerning markup, please don't drown it in classes!_ Keep it with an all-around div with an id, most likely you won't need more, you'll most likely style the children elements from that single id. Also, don't flood it with unnecessary div's, it hardens its understanding and ... it really might be just clutter. Are they for IE? Use a [script](http://code.google.com/p/ie7-js/) instead. The client doesn't have Javascript? Get [Firefox](http://firefox.com). If neither, then you don't need any div's at all. Meta-information for each feature and a short glance at the top; easy to read and above all, summarize every major feature, so a thrown in developer knows what a certain code does. Comments, --------- In the right place. Don't just write a comment line before every single line. Only some guidelines. One practice I really like is split the logic of a function into blocks like this: {% highlight php %} do_something(); # } # Semantic block 2 { $this->object->do_something(); # } ?>{% endhighlight %} Some text editors like [Textmate](http://macromates.com) have the ability to fold these kinds of blocks, which is a great visual aid in developing and first-hand comprehension. End of story ------------ _Use web standards, separate each component, take advantage of semantics in comments and talk it easy._ Better than a developer is one that knows how to explain what he's done. I'm sure Roger will appreciate it as well as me.