Discussion :

[ManusDei]

Code :

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

Message = Fonction1(Trim(Ucase(Cells(l,c)))) & "-" & Fonction2(Trim(Ucase(Cells(l,c))))

Code :

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

1
2
CelFormatee = Trim(Ucase(Cells(l,c)))
Message = Fonction1(CelFormatee) & "-" & Fonction2(CelFormatee)

Question quasi hors-sujet, c'est pas optimisé automatiquement par gcc ça (à condidiont d'utiliser gcc bien sûr) ?

[el_slapper]

Question quasi hors-sujet, c'est pas optimisé automatiquement par gcc ça (à condidiont d'utiliser gcc bien sûr) ?

Un compilateur C open source pour compiler du VBA pour Excel? Hum, j'ai comme qui dirait un doute... La valeur intermédiaire, sur des algos complexes, a aussi l'avantage de simplifier la lecture(si et seulement si on la nomme correctement, évidemment).

[ManusDei]

Un compilateur C open source pour compiler du VBA pour Excel? Hum, j'ai comme qui dirait un doute... La valeur intermédiaire, sur des algos complexes, a aussi l'avantage de simplifier la lecture(si et seulement si on la nomme correctement, évidemment).

Prout. Ce code compile en C (sauf peut-être le "-"). Et je pensais que c'était du pseudo-code.

[tomlev]

Question quasi hors-sujet, c'est pas optimisé automatiquement par gcc ça (à condidiont d'utiliser gcc bien sûr) ?

En plus de la réponse d'el_slapper (gcc ne compile pas du VBA), ce ne serait pas une optimisation valable : si l'expression Trim(Ucase(Cells(l,c)) avait des effets de bord (ce que le compilateur ne peut pas savoir), cette "optimisation" modifierait le comportement du code...

[mumen]

Ce conseil me pose toujours un problème mais je pense me souvenir que nous avons évoqué le sujet il y a quelques temps car le "ne pas optimiser" va se traduire trop souvent par "je fais n'importe quoi".

J'ai bien mentionné "lors de la première écriture". On doit considérer que tout code difficile et ambitieux (même petit) est forcément réécrit et adapté plusieurs fois avant d'être opérationnel.

Dans absolument tout conseil on va retrouver un ou plusieurs côtés tendanciels dangereux. Le problème alors, c'est l'interprétation du conseil.

Quand tu spécifies que ce conseil est alors donné a un développeur déjà expérimenté, je suis assez en phase avec ce que tu veux dire, mais je formulerai cela différemment en disant ce conseil est alors donné a un développeur exigeant.

MaJe l'ai mis et je le maintiens dans ma liste parce qu'il est une source de méditation très enrichissante sur le codage, parce qu'il contient et exprime un des mystères de ce métier, l'imprévisibilité.

[mumen]

Ce conseil me pose toujours un problème mais je pense me souvenir que nous avons évoqué le sujet il y a quelques temps car le "ne pas optimiser" va se traduire trop souvent par "je fais n'importe quoi".

J'ai bien mentionné "lors de la première écriture". On doit considérer que tout code difficile et ambitieux (même petit) est forcément réécrit et adapté plusieurs fois avant d'être opérationnel.

Dans absolument tout conseil on va retrouver un ou plusieurs côtés tendanciels dangereux. Le problème alors, c'est l'interprétation du conseil. Pas le conseil.

Quand tu spécifies que ce conseil est alors donné a un développeur déjà expérimenté, je suis assez en phase avec ce que tu veux dire, mais je formulerai cela différemment en disant ce conseil est alors donné a un développeur exigeant.

Quelle est la personne pas exigeante qui suivra un conseil en y réfléchissant vraiment ?

Un bon conseil est avant tout une source de méditation pour qui peut ou veut méditer. C'est une petite goutte de métaphysique, pas de morale. Celui là exprime selon moi un des mystères de ce métier, l'imprévisibilité et, comme je l'ai laissé comprendre, il me touche.

[qadassi]

Un conseil pour bien programmer: "continuer à faire la géométrie d'Euclide", où on rivalise en nouvelles démonstrations d'un même problèmes, où les arguments les plus limpides permettent de progresser le plus rapidement, où l'analyse des données mène à la solution du problème, où l'ajout d'élément supplémentaire dans la construction est toujours repoussé au plus tard, bref: revenir aux maths de collège avant de péter plus haut que son QI au risque de souffler du vent.

[Logan Mauzaize]

péter plus haut que son QI au risque de souffler du vent un nuage toxique.

Au propre comme au figuré.

[mumen]

Tu es obligé de proposer ton conseil de façon à mépriser quelqu'un ? détend toi.

Un conseil pour bien programmer: "continuer à faire la géométrie d'Euclide", où on rivalise en nouvelles démonstrations d'un même problèmes, où les arguments les plus limpides permettent de progresser le plus rapidement, où l'analyse des données mène à la solution du problème, où l'ajout d'élément supplémentaire dans la construction est toujours repoussé au plus tard, bref: revenir aux maths de collège avant de péter plus haut que son QI au risque de souffler du vent.

Ton conseil ne me convainc pas. Oh, il est élégant, même emprunt d'intelligence, puisque tu semble te questionner la dessus, mais on ne dirait pas le conseil de quelqu'un irait souvent sur le terrain.

[mumen]

J'ai écrit une chose erronée concernant le conseil en général. Sur l'histoire de la morale et de la métaphysique. Je ne le crois plus maintenant, je crois que le conseil peut prendre toutes les formes du raisonnement. Il peut aussi être logique, psychologique, etc.

[rimram31]

...Quand tu spécifies que ce conseil est alors donné a un développeur déjà expérimenté, je suis assez en phase avec ce que tu veux dire, mais je formulerai cela différemment en disant ce conseil est alors donné a un développeur exigeant....

Je veux dire que a "donner un conseil", je dirais plutôt fait attention a ce que tu écris, n'hésite pas a perdre 5mn de relecture car ça nous fera gagner des heures précieuses par la suite plutôt que d'annoncer: "te prends pas la tête a optimiser inutilement". Les deux conseils sont intéressants mais de loin, je lui préfère le premier pour avant tout faire prendre conscience a un développeur que de la qualité de son travail va dépendre celle des métiers qui lui succèdent.

Tout est dans le sens que l'on donne a "optimiser", malheureusement mon expérience me fait constater que depuis quelques années, la simple écriture d'un code propre me suffirait amplement.

[mumen]

Je veux dire que a "donner un conseil", je dirais plutôt fait attention a ce que tu écris, n'hésite pas a perdre 5mn de relecture car ça nous fera gagner des heures précieuses par la suite plutôt que d'annoncer: "te prends pas la tête a optimiser inutilement". Les deux conseils sont intéressants mais de loin, je lui préfère le premier pour avant tout faire prendre conscience a un développeur que de la qualité de son travail va dépendre celle des métiers qui lui succèdent.

Tout est dans le sens que l'on donne a "optimiser", malheureusement mon expérience me fait constater que depuis quelques années, la simple écriture d'un code propre me suffirait amplement.

Hum, tu devrais réfléchir avant de poster, à ce que tu veux vraiment faire avec ton message. Ici tu me donne un conseil dédaigneux, et c'est ce dédain qui semble être ta cause. Vérifie s'il te plait... Ce que tu écris sur ce que j'aurais écris n'a pas d'existence dans ce que j'ai réellement écris... ou alors en mode de lecture diagonale / partiale. C'est bien à toi de prendre les cinq minutes...

Désolé, du coup je ne rentre pas dans ton questionnement, aussi intéressant puisse t'il être.

[mumen]

Les trois notes négatives que se récupère mon message précédent semblent me donner tort. J'accepte, mais je voudrais savoir la raison.

Elle ne peut pas venir de ce que j'aurais écrit au début de mon conseil "te prends pas la tête a optimiser inutilement" et que je nierais maintenant, parce que je ne l'ai pas écrit ni même sous entendu, c'est indubitable. Or c'est la dessus que portait ma réponse précédente, ainsi que sur une dérive de ton dont je suis peut être aussi acteur pour n'avoir pas été encore plus clair ou pour toute autre raison comme de n'avoir pas suffisamment pris en compte la sensibilité de mon interlocuteur.

Je voudrais de l'honnêteté la dessus.

Merci

[Logan Mauzaize]

En tant que modérateur, je suis contre la justification des votes. Et tout autant contre l'étalage de propos hors-sujet. C'est déjà un premier point.

Cependant comme on est dans les débats. Et que je pense que chacun a le droit à des explications.
Pour ma part, si parfois je trouve les idées bonnes, souvent la forme laisse vraiment à désirer au point de pas les comprendre, ou pire, de douter de ce qu'on en comprend. Exprimer ces idées clairement ce sont les assumées, autrement ca reste qu'une succession de mots sans sens et qui n'apportent rien au sujet. On en revient au premier point.


Pour ne pas tomber dans les mêmes travers, je complète un peu ma dernière réponse. A force de vouloir faire trop intelligent (péter plus haut que son cul), on finit par diffuser de mauvaises idées (souffler un nuage toxique). Bref, il faut reste simple et humble. KISS.

[AkiroVIII]

Personnellement, le premier conseil que j'ai reçu d'un développeur expérimenté découle du principe KISS.

"Réfléchis toujours au plus simple et ensuite améliore".

J'avais tendance à réfléchir toujours à la solution la plus complexe et du coup je n'aboutissais à rien de concret ou de fonctionnel...

[rimram31]

Hum, tu devrais réfléchir avant de poster...

Désolé de l'incompréhension de mon dernier post, il n'avait absolument rien de personnel, je parlais des conseils que je donnerai, que j'ai donné a des développeurs dans mes équipes. Il ne s'agit pas d'un "questionnement" de ma part mais d'un retour d'expérience, je l'ai peut-être dit plus haut, mon premier conseil sera d'expliquer a un développeur qu'il n'est pas seul, que de son travail dépend celui de nombreuses autres personnes et, a ce titre, je lui demanderai de faire attention a ce qu'il écrit.

[petdelascar]

Même conclusion : "Lis plus, écris moins". Tout est dit.

[Asmanour]

Bonjour,

A mon avis, pour développez positivement il faut suivre une méthodologie :
1- Etude et analyse de l’existant qui pourra nous faire pouvoir cerner nos besoins par la suite.

2- choisir le langage de programmation à utiliser.

[Yalalaaaa]

le meilleur conseil c'est google .

[moldavi]

Bonjour.

Avec qui êtes-vous le plus d'accord ?

Avec tous.

"write less code"

Moins il y a de ligne de code, plus c'est facile à lire/comprendre (logique de base). Il faut toujours se demander, lorsque l'on sent que son code est compliqué : "comment pourrai-je simplifier ce code tout en restant facilement lisible/compréhensible... Et le faire. C'est très bon pour la maintenance, et souvent pour l'optimisation.

toujours prendre le temps de réfléchir quand on a une erreur avant de rajouter du code supplémentaire.

Je l'ai souvent observé. Lorsque j'ai une erreur, je code rapidement dans une direction qui, quand ce n'est pas la bonne, me fait regretter de ne pas avoir sauvegardé une version d'avant les modifications. Cela n'arrive presque plus...

"read much more than you write"

Le fait de beaucoup lire, c'est le fait de savoir ce qui existe, ce qui se fait. Si votre mémoire est bonne, face à un problème, vous pourrez utilisez ce que vous avez déjà lu pour résoudre ce problème efficacement. Souvent.

pour devenir meilleur, participer sur des forums ou des groupes de discussions en aidant ceux qui ont des questions, si vous avez la réponse, dites là, si vous ne l'avez pas, rechercher sa réponse sur Internet.

Cela permet de faire des recherches sur des questions que vous ne vous êtes jamais posées. Mais un jour, peut-être, ces questions se poseront à vous, et vous permettrons de résoudre un problème plus rapidement.

refactoriser son code

Cela rejoint beaucoup "write less code".

écrire des tests unitaires pour son code avant de l'intégrer au projet

Lorsque l'on ne maîtrise pas certaines fonctionnalités, c'est bien de faire des tests à part. Histoire de bien comprendre le comportemment d'une fonctionnalité. C'est plus simple et plus efficace que dans un programme complet.

d'abord rendre son code fonctionnel avant de vouloir l'améliorer !

Celui-là est plus difficile à comprendre sans avoir pratiqué. Mais cela rejoint beaucoup l'adage qui consiste à optimiser en fin de développement, et non au début.
On doit être certain que le programme fonctionne correctement avant de l'optimiser. L'inverse est souvent moins vrai.