Tchat programmation

Il faut trouver un juste milieu, à mon avis, Mister, généraliser de façon "intelligente", sinon ça peut compliquer le code plus qu'autre chose. Je n'ai pas d'exemple sous la main pour la surfactorisation, mais, à terme, on se retrouve avec des méthodes / classes dont on ne connaît plus l'intention originelle (notamment dû à des développeurs qui veulent "gagner du temps", en réutilisant l'existant à tort et à travers).

Je suis d'accord, la structuration du code doit avoir du sens.
Bannir absolument les usages détournés qui rendent le code incompréhensible, même pour son auteur 6 mois après.

Normalement, il est coutume de dire qu'il faut environ 30% de la taille du code en commentaires. Pour faciliter sa reprise.

Un code simple, avec des identificateurs bien choisis se passe de commentaires.

Les commentaires c'est un vaste débat à mon avis. Perso je suis pro-commentaires, même si 30% (1 commentaire toutes les 3 lignes grosso-modo) perso je trouve que ça fait beaucoup David :p

Le problème des commentaires reste qu'ils tombent rapidement en désynchronisation par rapport au code => quand on fait une évolution / correction à la va vite et qu'on ne prend pas le temps de mettre à jour le commentaire correspondant. Cependant, même avec les identificateurs les mieux appropriés, il me semble que certaines parties de code ne peuvent tout simplement pas se passer de commentaire.

Enfin, une technique que j'aime bien, consiste à écrire d'abord les commentaires, et compléter ensuite chaque ligne par le code correspondant. Après il faut potentiellement nettoyer en supprimant les commentaires qui portent sur des sections qui parlent d'elles-mêmes.

Les commentaires qui paraphrasent le code.

c'est vrai qu'il a parfois (souvent ?) des commentaires inutiles. Je pense que ça s'apprend, c'est un art de bien commenter (je ne prétends pas le maîtriser du reste...)

Swing je la ressortirais si j'ai l'occaze (et si j'ai envie de me faire lourder )

Excellent l'anecdote Swing

Souvent dans les commentaires, les développeurs oublient les points importants à préciser. ex: unité de la valeur, chemin de fichier absolu ou relatif, terminé ou non avec '/', encodage des chaines de caractères, etc.

Salut Mister Hyde.

Ok pour l'unité de valeur par contre

chemin de fichier absolu ou relatif, terminé ou non avec '/', encodage des chaines de caractères, etc.

Pas sûr d'avoir bien interprété => ces 2 exemples figurent dans les paramètres de configuration plutôt que les commentaires
(H.S. : les problèmes d'encodage sont importants à prendre en compte dés le début, sinon ça peut devenir une vraie galère )

A mon avis, les commentaires sont nécessaires et ne doivent pas paraphraser le code mais expliciter l'intention du développeur. Par la force des choses, quand le code correspond à ce qui est voulu, on aura l'impression d'une paraphrase.
Mais en cas de problème, si la maintenance est effectuée par un autre développeur (ou par le même six mois après), la description de ce qui était censé être codé sera bien utile.
Des identificateurs parlants permettent de lire facilement le code mais ne renseignent pas vraiment sur ce qu'il était censé faire.

Salut Taka. Je suis d'accord avec toi concernant l'intention. Expliquer "pourquoi" le code fait quelque chose, plutôt que d'expliquer "comment" il le fait (ce dernier point étant normalement directement compréhensible en lisant le code).

2 postes ouverts chez notre ami prt:
1
Developer - C/C++ Linux

Lille area, CDI Learn more

1
Developer - WEB Full Stack PHP

Lille area, CDI Learn more
https://trading.prorealtime.com/en/careers/index.phtml

Initiation (vulgarisation ? Pas encore tout lu) au machine learning:

https://medium.com/@alexis.anzieu/samuser-avec-le-machine-learning-a40159bb0546

Comme dit le monsieur
"Il est très probable que vous n’ayez aucune idée de pourquoi cette combinaison particulière fonctionne.Donc vous avez écrit une fonction que vous ne comprenez pas vraiment mais dont vous pouvez prouver son efficacité"

https://www.quora.com/My-boss-gave-me-30-days-not-working-days-to-learn-Python-to-transfer-to-the-Data-Science-team-What-is-the-best-approach-to-learn-as-much-as-possible

My boss gave me 30 days (not working days) to learn Python to transfer to the Data Science team. What is the best approach to learn as much as possible?


Meilleure réponse pour moi:
"Show him this - after 43 years of using and teaching programming, learning it in 30 days will, AT BEST, let you know what basics you need to learn. It takes the average left-brained individual (one most suited to learning programming) at least 6 months to learn programming, and a few years to become somewhat competent at it.

30 days? Does he also want you standing on the tip of your nose the entire month? That’s how silly “learn programming in 30 days” sounds to someone who’s been there. (If you’re already an accomplished programmer, just look at a language manual and start porting a program you’ve written into Python. That’s about an hour of work, plus the time it takes to port it.)"

Marre de voir n'importe quoi dans les codes source.

J'étais passé à côté de ce tchat...Du coup j'ai une question pour vous

Je suis en train de faire un programme en python pour récupérer les cotations des options pour différents indices, différents strike et différentes maturités. Le but est de me constituer une base de données pour ensuite analyser...bâ je sais pas trop...variations du sous-jacents vs options, volatilité vs sous-jacent, bref les possibilités sont nombreuses.
Comme je n'ai pas trouvé d'API fiable (Yahoo a fermé les siennes, google aussi et IG ne proposent pas les options "officielles") je scrape directement le site eurex.
https://tinyurl.com/ycv276jm
et cela me sors un tableau comme celui-ci (y'a un peu de ménage à faire):

Spoiler:

Screenshot_20180510_113741.png (177.47 Kio) Vu 752 fois

Le but est de puller les datas tous les 1/4 heure pour 6-7 maturité et 3-4 indices différents. Donc tous les 1/4 heure je me retrouve avec 28 tableaux comme ci dessus.
Mes question est la suivante: est-ce judicieux de passer par une base de données ? laquelle est la plus light (sachant que je n'y connais rien) ? ou passer par du json (ce que je fais actuellement) est- il suffisant ?

merci

A mon avis :
- Si tu optes pour une base de donnée, je te conseillerais MySql
- Mais, personnellement, je ne ferais pas ce choix.
- Je ne choisirais pas non plus du JSON, car trop verbeux pour cette utilisation.

Je stockerais mes données tout simplement à plat dans des fichiers CSV.
J'y vois les avantages suivants :
- Moins de perte de place que JSON
- Plus simple et plus rapide qu'une BDD (surtout que tu n'as pas besoin de relations complexes)
- Utilisables directement sous Excel pour des vérifications, des calculs ou l'affichage rapide de graphiques
- Faciles à exploiter dans tes programmes

+1 pour .csv (je programme pas, je fais du seo donc j'en ai besoin et c'est léger, efficace et effectivement sous excel c'est parfait). j'ai 100.000 lignes max

Pour une fois je suis d'accord avec tout le monde: dans mon robot je n'utilise que du CSV et si vraiment un jour il me faut une bdd ça sera sqlite (léger , rapide, souple).

ok merci pour vos réponses. va pour le csv donc ! mon problème c'était surtout la rapidité pour parser ces fichiers. si je surveille un indice pendant un an j'ai calculé que le fichier ferai environ 300000 lignes (150000 sur je sépare les puts et les calls).
des retours sur la rapidité dans ce cas là ?