Archive

Posts Tagged ‘programming’

Camel case: comment gérer les acronymes et abréviations en majuscules ?

juillet 23, 2010 2 commentaires

[Article also available in English.]
Rapide article à propos d’un sujet qui s’est présenté plusieurs fois dans l’équipe: les acronymes doivent ils rester en majuscules lorsqu’ils font partie d’un nom en camel case ? Autrement dit, faut il écrire XMLFileName ou XmlFileName ?

Pareillement, que faire des abréviations? Si un composant concerne le Front Office, et que ce même Front Office est souvent référé en tant que FO (ou Fo), ce composant doit il être nommé FoFileName ou FOFileName ? Et un autre SomeDataFODisplay ou SomeDataFoDisplay ?

Bon, je l’avoue, ça parait un peu inutile comme discussion. On développe des logiciels, le choix des noms n’est pas forcément le plus critique. Ceci dit, avec Eclipse et son auto complétion prenant en compte le camel case, comme le dialogue d’ouverture de type, il est requis de savoir quelle est la convention retenue. Aussi, il suffit de se mettre d’accord au niveau de l’équipe et, à priori, basta.

Ceci dit, nous ne nous sommes pas penchés pleinement sur le sujet, vu qu’il est limite accessoire, et la solution retenue, frisant l’arbitraire, n’a convaincu personne. Aussi, je me suis dit que je devrai creuser un poil le sujet 🙂

Aussi, armé d’un redoutable éditeur de code, voici ce que je constate:

  • tout garder en majuscules:
    + colle au plus près des acronymes. C’est XML et pas xml après tout.
    – devient illisible quand des acronymes sont combinés. FOXMLRMIConfig est plutôt confus par exemple.
    – inapproprié pour les noms de variables. Comment gérer le commun « private Foo foo » ? Aller pour « private FOXMLData FOXMLData » ? Arg. « private FOXMLData fOXMLData » ? Encore pire ! « private FOXMLData foXMLData » ? Un peu mieux, mais toujours pas génial AMHA.
  • ne garder que la première lettre en majuscule:
    + les noms de variables deviennent naturels. « private FoXmlData foXmlData » a tout simplement l’air comme il devrait être.
    + Peut être combiné à volonté. FoXmlRmiConfig est lisible.
    – étrange au premier regard. Comme dit plus haut, c’est HTML et PDF, pas Html et Pdf !

Aussi, il semblerait que ne garder que la première lettre en majuscule soit la bonne solution.

Vu que je ne voulais pas ignorer l’état de l’art, j’ai essayé de trouver des recommandations officielles sur le sujet. Ma pêche a été maigre, seul Microsoft en fourni sur le sujet, à la page Capitalization Conventions, dans le paragraphe « Capitalization Rules for Acronyms ».

En quelque mots, le contenu peut être traduit et résumé à:

  • Abréviations:
    ne pas en utiliser sauf pour ID et OK, qui « dans des identifiant Pascal-cased devraient apparaitre en tant que Id et Ok. Utilisés en tant que premier mot d’un identifiant camel case, ils devraient apparaitre en tant que id et ok. »
  • Acronymes:
    – si longs de 2 caractères: les laisser en majuscules, « excepté pour le premier mot d’un identifiant camel case ». Ce qui veut dire d’écrire « private IOFile ioFile ».
    – si plus de 2 caractères, ne garder que la première lettre en majuscule, excepté pour le premier mot d’un identifiant camel case. Ce qui revient à « private XmlFile xmlFile ».

Cette règle des 2 caractères m’a pas mal surpris en fait. Cela peut sans doute aider à satisfaire tout le monde, ceux pour le tout majuscule et ceux pour l’autre option. Ceci dit, je trouve cela un peu exagéré. Et, franchement, « private DBXml dbXml » ne me semble pas des plus naturels.

Si vous avez la version Java/Sun/Oracle sur le sujet, je suis preneur 🙂

Au final, cette règle des 2 caractères me semble bien superflu. Perso, je reste sur la règle du « seule la première lettre en majuscule ».

Je suis preneur de toute opinion différente.

Allez, suffisamment dit (voir trop) sur le sujet: direction dodo !

++
joseph

Étiquettes : , , ,

Camel case: trying to clear the matter of uppercase abbreviations/acronyms

juillet 16, 2010 1 commentaire

[Article aussi disponible en français.]
Small entry about an issue which showed up already a few times in our team: shall acronyms be uppercases or not when part of a camel case name ? To put it differently, would you go for XMLFileName or XmlFileName ?

And then, what about abbreviation, like a component for some Front Office, with this Front Office being often referred to as FO (or Fo ?). Should this component be named FOFileName or FoFileName ? SomeDataFODisplay or SomeDataFoDisplay ?

Sounds pointless isn’t it ? We’re there to produce working software, and it doesn’t matter how you call your components. Yet, when using IDE like Eclipse which allows « camel case aware file name completion », like the open type dialog, one has to know which way to go. Basically, you have to agree on some team wide convention and be done.

But then, due to this kind of « pointlessness » aspect of the topic, we never dealt properly with it, rather quickly agreeing for one way and then the other, based on « quick guts feeling ». And each way I felt like some were disagreeing with the choice, with no argument given to convince anyway.

As I hate this kind of groundless discussion, I took my nice editor and tried out.

For me, it looks like that:

  • keeping all upper case:
    + in line with the acronyms themselves, it’s XML not Xml.
    – becomes unreadable when combined, FOXMLRMIConfig is pretty blurry.
    – sucks with variables’ name. How to handle the common « private Foo foo » use case ? « private FOXMLData FOXMLData » ? Ugly. « private FOXMLData fOXMLData » ? Even worse ! « private FOXMLData foXMLData » ? A tad better, but still no great IMO.
  • keeping only the first letter uppercase:
    + no brainer for variables names. « private FoXmlData foXmlData » just feels right.
    + Can be combined ad nauseum. FoXmlRmiConfig is readable.
    – strange at first look. It’s HTML and PDF, not Html and Pdf damn it !

Over all, it looks like keeping only the first letter uppercase is the best way to go.

As I didn’t want to ignore « previous art », I tried to find out the « official » recommendation(s). I just found some from Microsoft, on the Capitalization Conventions page, in the paragraph « Capitalization Rules for Acronyms ».

To keep it short, what they say basically is:

  • Abbreviations:
    do not use any apart for ID and OK, which « In Pascal-cased identifiers they should appear as Id, and Ok. If used as the first word in a camel-cased identifier, they should appear as id and ok, respectively. »
  • Acronyms:
    – if 2 char long: keep them upper case, « except the first word of a camel-cased identifier ». Which means go for « private IOFile ioFile ».
    – if more than 2 chars, keep only the first letter upper case, except the first word of a camel-cased identifier. Which means « private XmlFile xmlFile ».

This 2 char rule is quite a surprise IMHO. I feel like it could help satisfy all parties on the topic. Yet I find it a bit awkward and overdone. And if « private DBXml dbXml » is the right way to go, then it feels completely mix up.

I wasn’t able to find Java/Sun/Oracle opinion on the topic. If ever you know it, let me know 🙂

As such, this 2 char only extra rule didn’t convince me. I would stick to the « only first letter uppercase rule » all over the place.

If you have a different opinion, I would gladly read it.

This being said, enough, or even already too much, wrote on the topic. Heading to bed !

++
joseph

EDIT : I just discovered recently the Google Java Style guideline, which says the same on camel case. Sweet 🙂

Étiquettes : , , ,

Livre : The Pragmatic Programmer: From Journeyman to Master

juin 30, 2010 1 commentaire

[This article is also available in English.]

Par le passé, j’ai lu des livres tels que My Job Went to India: 52 Ways to Save Your Job ou Practices of an Agile Developer et, hum, j’ai préféré ne pas en parler…

Avec The Pragmatic Programmer: From Journeyman to Master, c’est différent. L’essentiel est dédié à comment augmenter ses compétences en programmation, au sens large (comment débugger, orthogonalité, utilisation des exceptions). Chemin faisant, il fournit des conseils de bonne qualité. Si vous sentez que vous pourriez faire mieux sans savoir vraiment où demander/chercher des conseils, alors ce livre est susceptible d’aider. Dans l’absolu, de bons livres techniques, tel Effective Java, ont ma préférence, mais de façon plus générale, presque en termes de méthodologie et d’approche, The Pragmatic Programmer: From Journeyman to Master peut aider.

Certes, je ne suis pas 100% d’accord avec ce qui est écrit. Je ne suis toujours pas un expert emacs et je n’envisage pas de l’être. La génération de code n’est pas que du bonheur, surtout si fait de façon statique (c’est à dire à un autre moment qu’à l’exécution). Mais cela n’enlève rien de la facilité et du plaisir de lecture global. Les chapitres vont droit au but sans pontifier. L’aspect pragmatique est, j’ai trouvé, ressenti.

Il est à noter que depuis la parution de ce livre, en 1999, et des suivants (susnommés), le web présente bien des ressources intéressantes sur le sujet. Par exemple le wiki 97 Things Every Programmer Should Know (qu’un google translate devrait pouvoir rendre accessible à des francophones purs, à défaut une traduction doit pouvoir se trouver voir même s’envisager). De telles ressources ont un intérêt similaire.

Au final, je ne pense pas que des livres, à eux seuls, puissent permettre de progresser réellement et efficacement en solitaire. Dieu merci, il existe désormais internet où il possible de trouver de bons programmeurs (cf Igor Vaynberg par exemple), voir même parfois de pousser la chose jusqu’à bosser avec eux… D’ailleurs, ne dit on pas « Qui ose gagne » ? lol

++
joseph

ps : lorsque je cherchais à remettre la main sur cette page avec ces 97 astuces, je suis tombé sur ça en chemin : 97 Things Every Software Architect Should Know. Et j’ai vraiment apprécié celle là : « Simplicité avant généralité, utilisation avant réutilisation ». A méditer !

Étiquettes : , , , ,

Book: The Pragmatic Programmer: From Journeyman to Master

[Cet article est également disponible en Français.]

In the past, I’ve read books like My Job Went to India: 52 Ways to Save Your Job or Practices of an Agile Developer and, well, I prefered not to speak about them.

With The Pragmatic Programmer: From Journeyman to Master, it’s different. It focuses itself on how to improve programming skills and, for that, provides mostly good advices. If you feel you aren’t doing good enough and don’t really know where to go/ask for advices, this book could help. Still, good technical books like Effective Java would have my preference, but on a more general level The Pragmatic Programmer would still help.

Yet, I don’t agree with all which is said in the book. I’m no emacs expert and I don’t intend to be. Code generation has drawbacks as well.

Still, it’s an overall easy to read and interesting book.

However, since, stuff like the « 97 Things Every Programmer Should Know » wiki page have popped up and may provide just as much.

And in the end, the more I think of it the more a proper tutor looks like the way to go. You can’t become a master just by reading books, and most probably neither by trying it all alone. Thanks god we have the web and good programmers around (if one is daring enough to go and work with them!).

++
joseph

side note: on my way to find again this « 97 tips » page, I got into this one as well: 97 Things Every Software Architect Should Know. And I really liked this one: Simplicity before generality, use before reuse. Something to work on I fear !

Étiquettes : , , , ,
%d blogueurs aiment cette page :