Dive the web

On ne surfe plus, on plonge!

Tips for best practices

I’ve been working in the Web industry for about 12 years. During these years, I started to read about best practices in web development. I found a lot of them useful, both to ensure a better quality to my work, but also to make it easier - and sometimes quicker. I’m not claiming to have the best solutions to everything, the following tips are just a few of the things I try to do when coding. Some apply to (X)HTML or CSS, others are more appropriate to PHP or even JavaScript. Some are valid when working in a team, others when working alone.

  • Follow conventions.

    This is valid both for team and solo work. When working on your personal projects, pick a style and stick to it. When working with a team, either agree with a coding style with the team or, if one is already chose, use it - even if it’s different than yours. It will make it easier for both you and your team members to understand your code.

  • Validate HTML and use semantically correct markup.

    HTML tags have a meaning. A <p> indicates a paragraph. A <ul> indicates a list. Valid HTML has meaning, both to humans and machines.

    Validating HTML may help you find errors in your code. Not just markup errors, but also display errors. Something that may look great in a browser may look terrible in another. And most of the time, you have to support more than one browser.

  • Comment your code

    This one will never be repeated enough. Commenting helps you and team members. In six month, you may not remember what you did today. Comment! Comment! Comment!

  • Don’t commit incomplete or buggy code

    Except on rare occasions, it’s better to never commit incomplete or buggy code when using a source control tool. Stuff that goes into the common repository is supposed to work.

  • Keep team members informed

    Communication is important. You refactoring code, you need to let team members know. Email is useful. Documentation is better. When you create a new library, let team members know about it. If they don’t know about it, they may create something that does pretty much the same thing. Time wasted.

  • Be consistent when indenting.

    This is good for whatever language you use. Consistency in indentation helps finding your way around your code. By indenting, you can quickly see blocks of code or remove unused blocks.

  • White space is your friend

    Yes, this goes with the consistency in indentation. But white space also means inserting white lines between statements or functions. But don’t overuse it. There’s no need to put 10 carriage returns between blocks of code.

  • Google too

    Yep, Google is your friend. Your best friend. If you have a problem, chances are, you’re not the first one. It’s probably documented on mailing lists or Stack Overflow. Google knows, Google remembers!

  • IRC channels

    It’s amazing who you may run into on an IRC. Lots of people hang around on those channels and may help you. If you ask nicely and respect the channel’s rules.

  • Use available tools: good IDE, debugger, Firefox addons.

    A good IDE will help you in may ways: auto-complete built-in functions, sometimes a built in debugger or direct access to your version control tools.

    Firefox has great addons such as Firebug, the web developer tool bar or the regular expression tester that could save you lots of headaches.

  • Check logs

    Logs may indicate problems. Apache logs, PHP logs… The information you may find in these logs may prove useful. But you need to learn how to read them!

  • PHP Errors

    In a development environment, set your php.ini’s error reporting to E_ALL and display_errors to ON. This can help tracking errors and solving problems. But make sure you change this when going online.

What are your tips? What techniques do you use to ensure the quality of your code?

Tags: , , , , ,
June 10, 2009 - 12:50 PM No Comments

Usage correct des images dans un document HTML

L’article Balise <img> ou feuille de style ? publié par Raphaël sur Alsacréations (avec un S!!!) vaut le détour. En effet, ce n’est pas toujours évident de savoir si une image est porteuse de contenu (et doit donc être insérée dans le HTML) ou est uniquement décorative.

Dans un monde idéal, les rédacteurs devraient fournir aux intégrateurs les ALT et les descriptions longues des images quand ces dernières sont porteuses de sens. évidement, dans le vrai monde, ce n’est pas toujours le cas - dans l’agence où je travaille, on nous a dit que c’était aux intégrateurs de rédiger ces textes. D’accord quand il s’agit d’un bouton sur lequel on peu voir en belles lettres blanches le mot “recherche”. Mais dans la plupart des cas, ça peut devenir un réel problème. Imaginez un site web pour une compagnie de camionnage ayant une flotte de camions de la marque X. Personnellement, je n’y connais rien. Pour moi, un camion, c’est un camion. Si je dois mettre la marque du camion dans le ALT, il y a beaucoup de chances pour que je fasse de la publicité pour la marque Y.

Le métier est encore jeune, il y a beaucoup à faire pour avoir une méthode de travail vraiment efficace. Une équipe complète en agence devrait toujours avoir un rédacteur web (j’insiste sur le web).

Tags: ,
April 21, 2006 - 9:06 AM No Comments

L’attribut SUMMARY et la balise CAPTION

Pour rendre une table accessible, le World Wide Web Consortium recommande de faire un résumé du tableau (et de son contenu, me direz-vous). L’attribut SUMMARY (placez-le dans la balise TABLE) sert à cela. Il est un peu comme le ALT tag des tables. Les lecteurs d’écrans, browsers parlants et autres technologies assistives vont le lire - mais il ne sera pas visible sur l’écran.

La balise CAPTION doit être insérée après la balise TABLE et sert à identifier la table ainsi que sa fonction. Son contenu va apparaître sur l’écran, juste en haut de la table - un peu comme un titre.

Rappelez-vous: l’accessibilité d’une table, ce n’est pas sorcier!

Tags: ,
August 14, 2003 - 10:55 AM Comments: Closed