Hungarian notation on steroids: semantic types & suffixes

Hungarian notation

Joel on Software’s latest bewildering article advocates correct use of the – often misunderstood – Hungarian notation: “Making Wrong Code Look Wrong“.

Basically, calling a variable unBorder because it’s an unsigned int is pointless. What’s useful is to call it xwBorder because it’s an horinzontal “x” coordinate (versus a bytecount for example) that refers to the window “w” (versus the screen or the document for example). If this doesn’t feel a 100 times better to you, go read the article now! :)

I really agree with the fact that knowning the system type of a variable when you read it is pretty much useless most of the time – especially in the age of typeless scripting languages like PHP. Knowing the semantic type of the variable is much more interesting.

As I have written before in my coding standard guidelines, there’s a situation, though, where I still like to use system types in my variable names: when I deal with Objects. For example I might use variable names like source_File and destination_File!

First, because if the Objects are properly named, then the variable names refering to them will make sense.

But there’s more: as you might have noticed, I used the object name “File” as a suffix, not as a Hungarian prefix. The reason is that if I have a method called File::rename() that I want to refactor for some reason (like merge it with File::move() ), I might need to check every place where it’s called. Actually, as I have learned from b2evolution development, these things happen all the time on larger projects…

Now, by suffixing vars with the object name, I can easily do a project wide search for File->rename( and I’ll find all calls to the method, in various contexts such as source_File>rename(), destination_File->rename(), temp_File->rename(), log_File->rename() … you get the idea…

If I have one variable misnamed as in list->rename() for example, I would not find it… unless I decide to search on just ->rename(… but I wouldn’t want that! It would get me a lot of noise like: some_Collection->rename(), some_User->rename(), some_Group->rename(), etc…

Quel avenir pour Dreamweaver?

Dreamweaver A mon avis, même si Adobe garde la marque "Dreamweaver" ainsi que la base de code de ce logiciel, ils ne le garderont pas tel quel. Ils procèderont à un remaniement sensible pour l'adapter à leur "culture" et leur "phylosophie de l'interface utilisateur".

Il n'y a qu'à regarder les suites applicatives de Adobe d'un côté et de Macromedia de l'autre. Toutes les applications, au sein de chacune des deux suites, partagent des menus communs, des outils communs, des icônes communes et des palettes flottantes communes.

Pour faire la même chose dans les deux cultures, on procède différemment... parfois très différemment!

Adobe ne gardera certainement pas une interface Macromedia au sein de sa "suite graphique". S'ils tuent GoLive au profit de DW, ce sera avec un remaniement profond... et donc ce ne sera plus vraiment DW...

M'enfin, on peut toujours rêver que l'interface de DreamWeaver en sorte bonifiée! A vrai dire, je suis pas franchement fan des interfaces Macromedia...

Les menus Modifier/Commandes/Site.. c'est hyper confus!! On ne sait jamais vraiment où chercher... Et d'ailleurs on ne se poserait pas la question s'il ne manquait pas plein d'options essentielles dans les menus contextuels/clic-droit...) |-|

Et surtout, avec un peu de bol, Adobe va rajouter un p>:XXg de bouton <div> dans l'interface. Franchement, un outil qui se vante de faciliter l'édition de pages XHTML+CSS qui ne prévoit pas de bouton facilement accessible pour insérer des DIV, ça rime à quoi!?? >:-[

PHP Variable names, Member names, Class names

I have just extended my PHP coding standard guidelines with these rules about variable naming:

  • Remember this is PHP, not Microsoft Visual C++. There is actually little value in naming variables something like strFullTitle . Something like full_title is definitely enough and much easier to read!
  • As an exception to the previous rule, we'll preferably prefix private or protected member variables of a class with an underscore as in _full_title. This serves as an easy reminder that the variable is not designed to be called in any other ways as in $this->_full_title .
  • Class names should start with a capital, as in Book .
  • Variable names should be all lowercase, as in $title = 'A brand new day'; except when they are object references as in:

    $a_Book = & new Book( 'A brand new day' );
  • When naming object references, always end their name with the name of the class as in $a_Book or $another_Book instead of Book_to_read for example. This allows to easily search & find all calls to a given method of a given class. You could for exampel easily search on this string: "Book->get_title(" .

Adobe engloutit Macromedia: pas glop!

Si vous avez un job en rapport avec le web et que vous n’êtes que modéremment-ou-pas-du-tout catho, il y a eu un évènement ces derniers jours qui risque d’impacter votre futur légèrement plus que l’élection d’un nouveau pape: Adobe s’est mis d’accord avec Macromedia pour les racheter

Il y a une FAQ à propos de ce rachat, pleine de formules ampoulées, de langue de bois et de blagues tellement énormes qu’on a du mal à imaginer qui peut y croire. Exemple:

Are there areas of duplication in product line? […]
[…] The companies are largely complementay, and thus the amount of competition between us is limited.

Pas de compétition entre GoLive et Dreamweaver? Pas de competition entre Photoshop/Image Ready et Fireworks? Mais bien sûr…

Ce qui commençait vraiment à titiller Adobe c’est qu’après l’écrasante domination de Dreamweaver sur GoLive, Macromedia Flash commençait vraiment à faire de l’ombre à Adobe Reader dans le domaine des contenus web propriétaires, pardon: “riches"! :crazy:

Ca me rappelle une histoire où Macromedia engloutissait Allaire parce que leur petit produit de complément – HomeSite – faisait de l’ombre à leur DreamWeaver et où leur plus gros produit: – ColdFusion, alors leader sur son marché – a été relégé au second plan (pour ne pas dire “euthanasié") car il ne faisait pas partir de la stratégie de développement de Macromédia.

Rappelons aussi qu’à ce jour, DreamWeaver MX 2004, même s’il est très bien et qu’il a évolué suite au rachat de Allaire, ne remplace toujours qu’incomplètement HomeSite/ColdFusion Studio dont une vieille version qui n’évolue plus vous est gracieusement offerte pour tout achat d’un Dreamweaver…

Résignons nous: si les actionnaires acceptent de se faire manger ainsi, on peut se préparer à pas mal de remous sur le player Flash, et surtout on peut d’ores et déjà ranger nos Fireworks au musée des produits disparus. Pour Dreamweaver, je ne suis pas encore très sûr si ils oseront… mais franchement, ça me déprime de penser qu’on risque de se retrouver contraints à GoLive, faute de mises à jour du vieux Dreamweaver qui nous sera gracieusement offert pour tout achat d’un GoLive à jour… :’(
Mise-à-jour: A lire également: Translation From PR-Speak to English of Selected Portions of Adobe’s ‘FAQ’ Regarding Their Acquisition of Macromedia

PNG alpha transparency in IE

Here are a few solutions to the same old IE/PNG issue, all revolving around the same hack: using JavaScript to replace IMG tags containing PNGs with a SPAN or a DIV into wich the PNG is filled using the IE proprietary AlphaImageLoader image filter.

It works... in a very disgraceful manner (try it with 200 PNG icons on the same page!)... and I don't think it degrades correctly to the ALT text display if images don't get loaded for some reason. (Not to mention CSS side effects an the rest which is usually documented along with each hack).