Discussion :

[seb.49]

Une belle fonction contient au plus 7 lignes de code,
Une belle procédure appelle au plus 7 fonctions,
Un beau programme est lisible et compréhensible,
Dans tous les autres cas, une optimisation s'impose.

Et pour vous c'est quoi un "beau programme"

[O-ERON]

mmh... un programme
compréhensible
documenté
facilement modifiable/étendu (ce qui implique une bonne analyse ou tout du mon un découpage en classe bien fait)

et évidemment qui ne plante pas (ou pas beaucoup on va dire )

je concidère aussi de plus en plus qu'un programme facilement utilisable par l'utilisateur est une bonne définition
en effet... au final c'est pour lui que l'on fait le programme
et dérivé de ça, un programme joli à voir: quelques icones 256 couleurs me suffisent (par moment on tombe sur des horreurs dignes de win3.11)

[- Robby -]

je ne suis pas un pro du programme commercialisé,
des notions de clientèles ... etc ...
Mais pour pour moi, il ne faut pas confondre programme et
interface utilisateur.
Une belle interface utilisateur, facile d'utilisation, agréable,
conviviale ... pour moi, c'est du décorum !
Un décorum essentiel, indispensable, d'accord ... mais c'est de l'enballage.
Et dans un bel enballage, on peut mettre ce que l'on veut, meme une m...
Pour moi, un beau programme, c'est avant tout des algorithmes
bien pensés, efficaces, optimisés.
Il n'y a qu'un informaticien qui pourra juger de la beauté d'un programme.
Pas un utilisateur ! ... au sens ou moi je l'entends.

[aaazera]

Je suis d'accord avec Ruby: seul un informaticien peut juger de la beauté d'un programme parceque pour moi une beau programme est avant tout un programme agréable à lire et qui réalise chacune de ses fonctions avec élégance (pas de calculs inutiles, noms de variables bien choisis, etc...)
Un beau programme c'est comme une oeuvre d'art, dans le sens où l'on est admiratif devant l'auteur de l'oeuvre parce qu'il a fait une chose mieux que quiconque.
enfin bon, c'est mon avis...

[Kangourou]

Salut,

tout a fait d'accord avec Robby, il ne faut pas confondre interface utilisateur et algorithmes. Meme si la qualite de l'interface est quand meme necessaire, c'est le premier contact qu'on a avec le prog, en general.

Par contre, un beau programme n'est pas forcement un monstre d'optimisation, mais plutot un programme bien organise, et que l'oin peut etendre facilement (cf O-ERON). C'est quand on rentre facilement dans un code qu'on apprecie le travail du programmeur. Et en general, plus on optimise, moins c'est comprehensible. Le programme optimise a l'extreme s'ecrit d'ailleurs en assembleur ...

pour resumer,
bon programme = comprehensible + extensible

A

[Admin]

je suis à moitié d'accord avec vous, c'est souvent cette erreur que commettent tous les developpeurs, ce n'est pas au developpeur de definir les algorithmes, les implenter oui, mais pas les definir, ça c'est au responsable fonctionnel, celui qui maitrise le domaine de l'outil, trop de logiciel sont "beau" pour le developpeur, et sont des m**** pour l'utilisateur simplement parce que le developpeur ne se soucie pas de l'utilisateur.

Dites vous bien que la chose la plus importante dans un programme c'est le domaine fonctionnel et comment il est implémenté.

Moi je ne me soucis pas de savoir comment fonctionne ma voiture, tout ce que je veux c'est qu'elle demarre quand je tourne la clé, qu'elle aille à droite quand je tourne le volant à droite, peut m'importe de savoir si c'est un moteur à rampe commune ou pas.

L'informatique c'est pareil, ok vous voulez vous faire plaisir et faire un joli programme, tout en fonction, ou tout en objet avec methodes et procedures, pas de soucis, mais n'oubliez jamais que c'est l'utilisateur qui doit etre le premier satisfait pas vous.

C'est à cause de ce genre d'oubli qu'un programme disparait.

donc pour moi un meilleur programme c'est celui qui
satisfait l'utilisateur
me satisfait

[c-top]

L'ihm peut avoir beaucoup d'importance si elle est conçue dans un but pédagogique pour présenter le problème à résoudre par le logiciel.
Un programme est un tout et je suis d'accord avec goshiz

[Erwy]

L'ihm peut avoir beaucoup d'importance si elle est conçue dans un but pédagogique pour présenter le problème à résoudre par le logiciel.
Un programme est un tout et je suis d'accord avec goshiz

Un tout, m'ouais pas tout a fait d'accord en tout cas en client/serveur
Je n'emploierais pas ces termes dans ce cas.personnellement je travaille sur des ihm et j'essais tjrs au maximum de separer l'aspect interface et le code declenche,aussi bien au niveau du code que de la conception.pour moi il doivent etre le + indepenfdant possible pour permettre une meilleur maintenance et evolution,pour le reste je suis d'accord mais a mes yeux c'est pas le meme "programme" plutot le meme "projet" peut etre que certain trouveront que je joue sur les mots,mais comme on doit pouvoir developper les deux presque separement....

[Brogomil]

Perso, je crois que le developpeur juge de la beauté du code (Un "beau" programme est un programme qui se documente de lui même et qui est lisible (très peu de ligne par procédure). j'entends par se documente lui même que les noms de fonctions et procédure indiquent clairement ce qu'elles veulent dire. une fonction sauve un client au format xml, et bien elle s'appelle SaveClientToXml et pas sctxml! de mon point de vue, mes amis et collègues qui utilisent mes objets ne lisent pas mon code, ils s'en foutent de savoir comment ca marche, tant que ca marche et qu'ils trouvent facilement la fonction à utiliser.)

Et l'utilisateur juge la qualité du résultat cad si le programme est bon!

ps:Je vous rassure : mes codes sont plus lisibles que mes mails

[Sékiltoyai]

Perso je suis un novice en la matiere (mais ca m'empeche pas de trouver un programme beau qui pour moi est :
-évidemment un programme agréable à utiliser (interface, saisie des données, prise en main facile)
-Mais aussi au niveau code (organisé et compact, fonctions et variables ingénieuses)
-Qu'on a eu du mal a faire

[Teuchteu]

Tout ici n'est question que de vocabulaire...
La définition d'un beau programme dépend aussi de l'utilisation qu'il en est prévu. Dans le cas d'un soft livré à un client, un programme est "beau" s'il répond à toute les éxigneces clients, et s'il est facile à maintenir.
Si c'est un programme fait pour soi, on le trouvera beau comme dit Sékiltoyai si on a eu du mal à le faire (en fait ça reviens à dire qu'il répond à nos éxigences...).

Je dirai donc que pour moi un beau programme répond aux éxigences, est facile à modifier, ne contient pas de fioritures inutiles et rend utilisateur et créateur heureux (si c'est possible d'avoir les 2 heureux ensemble : )

[Metal Tom]

Un beau programme : voilà ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
qsort []     = [] 
qsort (x:xs) = qsort elts_lt_x ++ [x] ++ qsort elts_greq_x 
                 where 
                   elts_lt_x   = &#91;y | y <- xs, y < x&#93; 
                   elts_greq_x = &#91;y | y <- xs, y >= x&#93;

C'est le quick sort en Haskell. C'est pas joli ? En 5 lignes c'est baclé.
8 lignes pour le CAML :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
let rec tri = function 
[]->[] 
|x::l-> 
   let rec inflist = function 
   &#91;&#93;->&#91;&#93;|y&#58;&#58;m-> let suite = inflist m in if y < x then y&#58;&#58;suite else suite 
   in let rec suplist = function 
   &#91;&#93;->&#91;&#93;|y&#58;&#58;m-> let suite = suplist m in if y >= x then y&#58;&#58;suite else suite 
in &#40;tri&#40;inflist l&#41;&#41; @ &#91;x&#93; @ &#40;tri&#40;suplist l&#41;&#41;;;

Pour moi un beau code c'est un code puissant : c'est à dire qui faitle plus de choses possibles en un minimum de code.

[djibxav]

Pour moi un beau code c'est:

-Bien organisé au niveau des classes et fonctions (mais ça c'est plus de l'analyse que du code)

-Bien rangé (mes fonctions elles sont là, mes classes là, vu trop de progs avec un fonction ecrite en plein milieu parce que tout a coup on en a besoin)

-Bien indenté pour etre lisible
Là je suis meme pour aovir plus de lignes bien rangées, que moins de lignes pas trop lisibles, ça à l'air bête mais personellement je prefere ça:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
function mafonction()
	{
	traitement;
	traitement;
	}//fin mafonction

plutôt que ça:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
function mafonction(){
traitement;
traitement;}

-Un code qui utilise les fonctions de façon intelligente: Exemple une mode en PHP en ce moment consiste à utilise les expressions regulières a tout bout de champ, une expression regulière pour faire un substring de 3 caractères dans une chaînes c'est un bazooka pour ecraser une mouche.

[Cyr1c]

Pour ma part, un bon programme doit savoir allier une facilité d'utilisation avec une conception (et une réalisation) de qualité.
Je pense que c'est indissociable.

J'ai souvent vu des programmes bien conceptualisés, mais avec une interface tellement horrible et mal fichue qu'au final on utilise un logiciel moins performant mais plus simple d'utilisation.

Je pense donc que faut savoir allier les deux.

mais en tant qu'informaticien, j'aime les programmes bien pensé, bien étudiés qui soit facile à lire et à comprendre.
J'aime aussi et surtout qu'il soit évolutif, simple à retravailler.
Il est très agréable (surtout en objet) de pouvoir réutiliser des packages développés pour des programmes spécifique mais avec une approche généraliste afin de permettre la réutilisation !

Je ne supporte pas les programmes peu commentés, ou fait à l'arrache (bon parfois, ya pas tellement le choix). Quand je développe, je me force toujours de faire comme si quelqu'un allait toujours reprendre mon travail derrière, même si je sais que ce n'est pas le cas ...

[Metal Tom]

Bien organisé au niveau des classes et fonctions (mais ça c'est plus de l'analyse que du code)

Ca c'est valable que quand tu codes en langage objet naturellement

Mais je suis d'accord. Pour l'indentation et les commentaires d'ailleurs.
Moi l'indentation en C/C++ je préfère

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
function mafonction() 
{ 
   traitement; 
   traitement; 
}

Ca me permet de localiser plus facilement le début et la fin.