1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
|
---
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
<abbr title="Cascading Style Sheets">CSS</abbr> 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 <acronym title="PHP: Hypertext
Preprocessing">PHP</acronym> file, content goes to one markup file,
presentation in a <acronym title="Cascading Style Sheets">CSS</acronym> file,
special behaviour in a <acronym title="Javascript">JS</acronym> 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 %}
<?php
# Semantic block 1 {
$this->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.
|
