Citation:
Envoy� par Babylon
Pas besoin d'un clavier azerty belge pour ca : tous les clavier azerty le font avec altgr 9 et 0. :wink:
Version imprimable
Citation:
Envoy� par Babylon
Pas besoin d'un clavier azerty belge pour ca : tous les clavier azerty le font avec altgr 9 et 0. :wink:
bah je viens de regarder sur un azerty fran�ais et les accolades sont sur altgr 4 et la touche � cot� du backspace
Aucun probl�me de mon c�t�, je tape en qwerty qui est bien plus pratique que l'azerty pour faire du C (ou n'importe quoi d'autre en fait, l'azerty est vraiment minable :). Que ce soit pour les accolades, les ponctuations, les chiffres, etc.Citation:
Envoy� par Keihilin
M�me pas besoin d'autres IDE. Plugin Visual Assist -> intellisense surboost�, beaucoup, beaucoup plus rapide pour r�diger que l'intellisense de base.Citation:
Envoy� par Keihilin
Sinon, la productivit�, je ne crois pas que �a puisse se r�sumer � la vitesse de production de lignes de code. Loin de l� m�me.
Exemple b�te que j'ai eu l'occasion d'exp�rimenter plusieurs fois : une classe en VB.NET qui comporte un vingtaine ou trentaine de propri�t�s, et la m�me en C#. Ok, en VB.NET �a remplit les End Property/End Get/End Set tout seul, on peut gagner un peu de temps de r�daction gr�ce � �a. En revanche, on se retrouve avec des fichiers 2 fois plus longs (� peine exag�r� si la classe en question contient essentiellement ces propri�t�s).
Exemple type, pour des propri�t�s tr�s courantes se contentant de donner acc�s � des membres :�a, plus un saut de ligne entre propri�t�s, pour 20 propri�t�s, �a fait 200 lignes en VB.NET, 60 en C#. 80 si on met get et set sur deux lignes. Tout sur une seule ligne est une option aussi (40 lignes), mais l� c'est un peu excessif quand m�me (enfin �a d�pend des cas, �a peut rester tr�s lisible, surtout si on aligne bien les noms d'une ligne � l'autre, chose qu'on ne peut pas faire en VB.NET, formatteur automatique oblige).Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
C'est l�g�rement plus pratique pour s'y retrouver apr�s coup, non ? :)
Question lisibilit�, c'est toujours subjectif, mais franchement, dans ce cas bien particulier, je vois mal comment on peut consid�rer la version VB.NET plus lisible (pas pour une propri�t� hein, pour 20). En plus de l'�ternelle lourdeur de syntaxe. "Bonjour, je m'appelle Roger, je voudrais faire une propri�t� qui renvoit et modifie une chaine. J'y acc�de sans parenth�ses, mais il faut quand m�me les mettre dans la d�claration. J'ai d�j� dit qu'elle repr�sente une chaine, mais il faut quand m�me le r�p�ter pour le Set. Je ne mets qu'un Get pour qu'elle soit en lecture seule, mais il faut quand m�me ajouter ReadOnly."
Ok, �a se remplit plus vite, super, mais mes principales r�criminations contre le c�t� verbeux du VB ne viennent pas du temps que �a met � taper, mais de l'impression de lire un roman particuli�rement inint�ressant apr�s-coup :)
Les propri�t�s sont mon exemple favori pour �a, tellement l'�cart est �norme. Et qu'on m'explique pourquoi MS emp�che sp�cifiquement la possibilit� d'utiliser ':' pour mettre Get et End Get sur la m�me ligne quand le code tient en 2 mots.
Dans mon cas, le temps �ventuellement gagn� pour pondre le code (minime, qwerty, VAssist et bonne vitesse de frappe aidant) est tr�s, tr�s largement compens� par le temps perdu en relecture. Et l�, c'est � nouveau totalement subjectif :)
J'connais pas ce plugin...C'est vraiment aussi bien que �a ? On le trouve o� ?Citation:
Envoy� par Maniak
Concernant les propri�t�s, j'suis assez d'accord avec toi sur le principe "d'inutilit�" de toutes ces lignes...
Ca ne me g�ne pas pour la lecture, mais c'est fastidieux � taper, m�me avec VS qui m�che le boulot.
Pour gagner du temps, j'utilise une macro pour construire cette partie de mes classes. J'ai juste � d�clarer :
Private _Toto as String
et la propri�t� est cr��e toute seule sur demande (ctrl+P,ctrl+W = Read/write, ctrl+P,ctrl+R= Read only)...C'est peut �tre un des trucs qui me fait gagner le plus de temps...
http://www.wholetomato.com/x/downloads/Citation:
Envoy� par Keihilin
C'est pas exempt de d�fauts, certaines options sont plus ou moins utiles selon les go�ts, mais dans l'ensemble c'est sacr�ment pratique :)
Ouaip, �a doit aider :)Citation:
Envoy� par Keihilin
Cela dit, �a n'emp�che qu'au final, temps de frappe mis � part, on se retrouve avec des tonnes de lignes inutiles qui alourdissent (inutilement donc) la lecture.
Et vu que j'utilise beaucoup les propri�t�s et que je deviens d�j� un peu hyst�rique quand les fichiers d�passent 300 lignes (m�me en utilisant #region pour aider un peu), l'id�e de se retrouver avec 200 lignes juste pour lister quelques propri�t�s, c'est d�j� suffisant pour me faire rejeter l'id�e de faire du VB.NET volontairement :)
Doubl� avec l'emploi de using que je consid�re comme imp�ratif, la question ne se pose vraiment pas :)
8OCitation:
Envoy� par Babylon
Oui, tu as raison : je sais pas alors d'o� vient le clavier que g entre les mains :?
J'avais h�sit� � d�marrer mon projet en VB.Net ou C#. J'ai finalement, bien fiat de choisir C#.
Pourquoi?
Parce que avec c#, on peut sp�cifier qu'un "event" ne doit pas �tre s�rialis� ( Attribut [field : NonSerialize] devant l'�v�nement ), bizarrement en VB.Net, ce n'es pas possible.
Oufff
franchement quand ta l'habitude de programm� (exemple en java) ces touches deviennent instinctives!Citation:
un r��l gain de temps par rapport au {} qui ne sont pas les touches qui tombent le plus naturellement sous les doigts sur un clavier...
quand une utilise c# avec visual studio c'est pareil il reconnait toutes les propri�t�s et toutes les methodes, je gain de temps est je pense identique. en tout cas c'est mieux qu'avec notePad!!Citation:
Sans parler des propri�t�s d'une classe...en VB.net, tu tapes une lignes et VS te compl�te toute la structure...Vu que g�n�ralement y en a beaucoup des propri�t�s...
Allez au boulot tout le monde!!
comme beaucoup d'entre vous le remarquent, malgr� la grande ressemblance entre ces 2 langages, VB.NET est moins strict que C#.
Pour cette raison, et au regard des �volutions futures de ces deux langages (voir http://www.microsoft.com/france/vstu...-devtools.html), apr�s en avoir longuement discut� avec de tr�s nombreux clients, j'aurais tendance � r�pondre � ce vaste d�bat de la fa�on suivante :
- si vous connaissez d�j� VB, allez vers VB.NET
- si vous connaissez d�j� C++ ou Java, allez vers C#.
MAIS je temp�rerais imm�diatement ce conseil du fait qu'� mon avis, de par sa plus grande permissivit�, VB.NET est mieux adapt� � la conception de la couche d'affichage (�crans...) des applications, pour �viter les casts explicites � tout va, alors qu'ils n'apportent rien dans l'affichage, qui ne craint pas trop en terme de perfs et o� les donn�es ne sont pas r�utilis�es. A l'oppos�, pour l'�criture de composants serveurs, de logique m�tier, et autres DLL, je privil�gierais C# pour sa rigueur et une meilleure exploitation des concepts objet.
My 2 cents
Cela peut para�tre un peu surr�aliste, mais on vient d'avoir un petit retour d'exp�rience qui tend � d�montrer que cela peut �tre une erreur, m�me si ce choix est le plus naturel.Citation:
Envoy� par driard
Nous avons eu pas mal de probl�mes avec une �quipe de d�veloppeur VB6 : Passage � .net, VB.net s'impose naturellement vu le background de l'�quipe et...il a �t� tr�s difficile de faire abandonner les "mauvaises habitudes" de VB6 et d'inculquer des notions correctes de POO � ceux qui n'en avait pas. En bref, si c'�tait � refaire, on imposerait C#, du moins au d�but.
Tout � fait. (enfin sauf pour l'histoire des casts implicites...on fait du code propre partout ou on n'en fait pas !!)Citation:
Envoy� par driard
J'ajouterais que VB s'impose pour les couches de pr�sentation gr�ce � sa plus grande productivit�. M�me si certains "pro-C#" ne seront absolument pas d'accord ( hein Maniak ? :wink: ), je suis convaincu que pour le moment, Visual Studio rend VB.net plus productif que C# en "assistant" plus intens�ment le d�veloppeur lorsque en mode VB.
Sinon, je vois que c'est une approche assez souvent adopt�e : C# pour tout ce qui est "r�utilisable" (Composants, etc...), et VB.net pour le reste (Interfaces).
Je ne suis absolument pas d'accord.Citation:
Envoy� par Keihilin
� ton service :)Citation:
Envoy� par Keihilin
Et moi je suis convaincu que l'�ventuel gain (qui peut tr�s bien exister, �a je ne conteste pas) est loin d'�tre suffisant pour se trainer un langage sp�cifiquement pour une partie du d�veloppement, soit-disant non-r�utilisable, avec lequel les habitu�s de VB ont un mal de chien � se mettre � la POO et risquent fortement de produire du code fortement bancal.Citation:
Envoy� par Keihilin
C# est plus strict et rigoureux, �a c'est un fait que m�me les pro-VB ne peuvent pas nier (chacun son tour :), et je ne vois pas en quel honneur les interfaces (ou quoi que ce soit) gagneraient � �tre faites de mani�re moins rigoureuse.
Tu dis "on fait du code propre partout ou on n'en fait pas", je compl�te avec "on est rigoureux partout ou on ne l'est pas" :)
VB.NET pour les interfaces et C# pour le reste, c'est un jonglage entre langages totalement inutile.
Mdr. Je l'aurai pari� ! :DCitation:
Envoy� par Maniak
Je ne suis pas pro-VB, mais je ne le nie pas.Citation:
Envoy� par Maniak
Simple question de productivit�...rien d'autre.Citation:
Envoy� par Maniak
Je ne dis pas que ce choix est la panac�e universelle et que tout le monde devrait faire comme �a, je me borne � constater que c'est une orientation assez souvent prise.
Tu sembles quand m�me oublier une chose : on est d'accord que C# oblige � une certaines rigueur, mais VB.net n'emp�che pas d'�tre aussi strict et rigoureux, m�me s'il est plus permissif � la base.
Je partage cet avis.Citation:
Envoy� par Maniak
Sans rentrer dans l'aspect verbeux ou non du langage, je ne vois pas l'int�r�t de m�langer les deux langages.
Il est tout � fait possible d'�crire un code propre en VB.NET, et moi j'�cris mon code (r�utilisable ou non) en VB.NET, car je suis (par habitude) plus productif en VB.
Au jour d'aujourd'hui, il est clair que C# poss�de une meilleure capacit� � utiliser le Framework. N�anmoins, MS corrige le tir dans la prochaine version (Whidbey) avec par exemple l'arriv�e des Using en VB.
A propos du using. Personnellement je trouve son utilisation plutot "dangereuse". Je suis en effet de ceux qui pr�f�re voir les instructions de nettoyage de ressources �crites explicitement.
Et �a t'emb�te pas plus que �a de ne pas avoir les commentaires XML pour un code r�utilisable ?Citation:
Envoy� par bidou
Les instructions de nettoyage de ressources sont �crites explicitement dans les m�thodes Dispose. using permet juste de s'assurer qu'elles sont appel�es, donc de ne plus avoir � y penser. Ce n'est plus la responsabilit� du d�veloppeur, mais celle des objets. Un pas de plus en direction de la POO en somme :)
Sans parler de l'assurance que ces instructions de nettoyage seront appel�es quoi qu'il arrive, m�me s'il y a des exceptions, des sorties de boucles/fonctions en cours de route etc.
Il y a des outils tierce qui le font plus ou moins bien. Et ce sera inclus pour VB dans WhidbeyCitation:
Envoy� par Keihilin
Plut�t moins que plus.Citation:
Envoy� par abelman
Putain il serait temps que ce soit disponible en VB !!
C'est vraiment LE truc qu'il manque � VB depuis le d�but de .net.
J'ai jamais compris ce choix d'inclure �a dans C# seulement...
Justement dans le code, je trouve qu'il est pr�f�rable de voir l'appel du Dispose (ou du Close). Si tu prends la classe SqlConnection par exemple, faire un using sur une instance de cette classe veut dire que tu n'appelles pas explicitement le Close dessus une fois que tu a finis de l'utiliser.Citation:
Envoy� par Maniak
Je pr�f�re v�rifier la sym�trie des appels Open /Close que de me dire que le "using sous entend que le Close sera appell� automatiquement".
De plus l'utilisation du Using n'entraine t elle pas une identation en plus ? qu'en est il si tu dois utiliser plusieurs using sur des dans la m�me fonction ? tu identes � chaque fois ?
Juste une petite note au passage, vu que les "ce sera inclus dans Whidbey" qui commencent � se multiplier : dans les entreprises qui ont investi dans VS.NET 2003, combien vont se jeter sur Whidbey quand il sortira ?Citation:
Envoy� par abelman
D�j� que le passage de VS.NET 2002 � 2003 n'est m�me pas fait partout, d'ici � ce que tout le monde soit sur Whidbey, faut peut-�tre pas s'empresser de prendre des d�cisions avec VS.NET 2003 qui ne vaudront que pour Whidbey (et pas directement r�utilisables, vu que les projets d�velopp�s sous 2003 resteront probablement sous 2003, pour �viter le red�veloppement qui sera n�cessaire pour la prochaine version du framework).
Donc bon. L� on en est � VS.NET 2003, avec du 2002 qui traine encore un peu, autant s'en tenir � �a pour les discussions. Whidbey sera peut-�tre tout beau tout neuf avec plein de trucs en plus qui changeront la donne, mais il est encore loin, donc en gros : on s'en tape. Les d�cisions � prendre pour les projets de l�, maintenant, sont � prendre par rapport � la situation l�, maintenant.