Je travaille pour IBM depuis 6 mois et je ne l'ai vu nulle part (Dieu merci parce que je déteste ça.) Je vois camelCase ou c_style.

thisMethodIsPrettyCool()
this_method_is_pretty_cool()

Cela dépend de votre langue et de votre environnement. En règle générale, je ne l'utiliserais pas, à moins que l'environnement de développement dans lequel vous vous trouvez ne rende difficile la recherche du type de la variable.

Il existe également deux types différents de notation hongroise. Voir l'article de Joël. Je ne le trouve pas (ses noms ne les rendent pas exactement faciles à trouver), quelqu'un a-t-il un lien vers celui que je veux dire ?

Modifier : Wedge a l'article que je veux dire dans son message.

C'est inutile (et distrayant) mais il est relativement utilisé dans mon entreprise, du moins pour des types comme les entiers, les chaînes, les booléens et les doubles.

Des choses comme sValue, iCount, dAmount ou fAmount, et bFlag sont partout.

Il était une fois une bonne raison pour cette convention. Maintenant, c'est un cancer.

J'utilise la dénomination hongroise pour les éléments de l'interface utilisateur tels que les boutons, les zones de texte et les étiquettes. Le principal avantage est le regroupement dans la fenêtre contextuelle Visual Studio Intellisense. Si je veux accéder à mes étiquettes, je commence simplement à taper lbl.... et Visual Studio proposera toutes mes étiquettes, joliment regroupées.

Cependant, après avoir fait de plus en plus de choses Silverlight et WPF, tirant parti de la liaison de données, je ne nomme même plus tous mes contrôles, puisque je n'ai pas à les référencer à partir du code-behind (puisqu'il n'y a vraiment pas plus de codebehind ;)

Ce qui ne va pas, c'est de mélanger les normes.

Ce qui est bien, c'est de s'assurer que tout le monde fait la même chose.

int Box = iBottom * nVerticleSide