Le topic de la programmation: Et envoyez des sioux!

[Whiskey]

ola j'ai une petite question simple, en ce moment je fait un peu de python, j'ai pas vraiment de soucis avec le langage en lui-même mais plus sur sa manière d'écrire le code. Je m'explique :

Aujourd'hui, dans la plupart des cas on écris les variables avec la norme Camel case (par exemple : int minVoiture = 0 ou int maxVoiture = 10), mais pour le python, la plupart des articles que je vois c'est plutôt à l'ancienne mode avec des _ a la place des espaces (par exemple: min_voiture = 0 ou max_voiture = 10).

La plupart des personnes que j'ai pu demander me disent qu'ils faut abandonner l'ancienne norme (avec le _) pour du Camel case, soit disant plus lisible. Seul quelques personnes (souvent qui ont connu de vieux langages auparavant) me conseille de rester sous les normes du python, peut être par nostalgie

Qu'en pensez vous ? (Je sais c'est pas forcement une question importante, mais quitte a faire un programme, autant le faire proprement).

Merci d'avance.

[ducon]

Tu fais comme tu veux, ça ne change rien.
Tu as des consignes de rédaction de code ou non ?

[Whiskey]

Tu fais comme tu veux, ça ne change rien.
Tu as des consignes de rédaction de code ou non ?

Non c'est du développement personnel, j'ai pas de consigne particulière, mais si un jour je fourni le code pour autrui, j'aimerais qu'il soit propre et au norme

[Tramb]

Qu'en pensez vous ? (Je sais c'est pas forcement une question importante, mais quitte a faire un programme, autant le faire proprement).

https://www.python.org/dev/peps/pep-0008/

Après tu fais comme tu le sens, puisque Python c'est le Bronx de toute façon

[Orhin]

Tout pareil. Et à la base j’ai fait des études de mécanique, c’est pire. 10% ? Même pas en rêve.

Ah ouais ? Pour le coup dans mon école (INSA Rennes) c'était les filières génie mécannique/civil/matériaux où on retrouvait la plus forte mixité.

Par contre des retours récent que j'ai pu avoir le taux de mixité en première année a tendance à augmenter et serait pas loin de 40% maintenant.

[Nilsou]

Idem dans mon école d'électronique, ils sont pas loin des 40% tout pareil alors que quand j'y étais c'était dans les 15% en gros. Il y a eu une grosse évolution dans les écoles d'ingé en quelques années on dirait. Le changement de génération pour une génération qui est né avec les technologies d'entrée de jeu ?

[Cwningen]

ola j'ai une petite question simple, en ce moment je fait un peu de python, j'ai pas vraiment de soucis avec le langage en lui-même mais plus sur sa manière d'écrire le code. Je m'explique :

Aujourd'hui, dans la plupart des cas on écris les variables avec la norme Camel case (par exemple : int minVoiture = 0 ou int maxVoiture = 10), mais pour le python, la plupart des articles que je vois c'est plutôt à l'ancienne mode avec des _ a la place des espaces (par exemple: min_voiture = 0 ou max_voiture = 10).

La plupart des personnes que j'ai pu demander me disent qu'ils faut abandonner l'ancienne norme (avec le _) pour du Camel case, soit disant plus lisible. Seul quelques personnes (souvent qui ont connu de vieux langages auparavant) me conseille de rester sous les normes du python, peut être par nostalgie

Qu'en pensez vous ? (Je sais c'est pas forcement une question importante, mais quitte a faire un programme, autant le faire proprement).

Merci d'avance.

Ça vient d'où d'appeler la snake_case (ou lower_case_with_underscores comme l'appelle la doc Python) "l'ancienne norme" ? Il y a eu une réforme des "normes" ?

[gros_bidule]

Ouaip, ça dépend juste des projets et des personnes.
Je te dirais donc :
- projet perso : fais ce qui te plais plais plais
- projet en équipe ou pro : fais comme l'équipe ou ce que demande le cahier des charges. L'adaptation est une qualité importante

Dans un autre registre, je prônerais aussi la tolérance. Exemple :
en Java tu peux mettre des "_" dans les nombres pour les rendre davantage lisibles. Par exemple au lieu d'écrire 1000000, tu peux écrire 1_000_000.
Hélas, je me suis retrouvé dans une team où le jeune techlead avait décidé que les "_" c'était moche donc interdit. Encore hélas, je lui ai expliqué en vain que faisant sévèrement de la dysphasie, j'ai bcp de mal à distinguer plus de deux chiffres cotes à cotes, et donc 1/ la notation avec les "_" m'aide énormément, 2/ ça n'empêche pas les autres de lire.

[Whiskey]

Ça vient d'où d'appeler la snake_case (ou lower_case_with_underscores comme l'appelle la doc Python) "l'ancienne norme" ? Il y a eu une réforme des "normes" ?

Bah la plupart des langages aujourd'hui utilisent le Camel case, le python comme dit un peu plus haut sur tout ce que j'ai pu lire sur ce sujet il conseille le "snake case", mais quand je vois le nombre de personne qui moufte sur ce "snake case", je me pose la question si justement faut passer au camel ou garder le snake ^^

Peut etre que je m'exprime mal, désolé si c'est le cas.

- - - Mise à jour - - -

https://www.python.org/dev/peps/pep-0008/

Après tu fais comme tu le sens, puisque Python c'est le Bronx de toute façon

Ouaip, ça dépend juste des projets et des personnes.
Je te dirais donc :
- projet perso : fais ce qui te plais plais plais
- projet en équipe ou pro : fais comme l'équipe ou ce que demande le cahier des charges. L'adaptation est une qualité importante

Dans un autre registre, je prônerais aussi la tolérance. Exemple :
en Java tu peux mettre des "_" dans les nombres pour les rendre davantage lisibles. Par exemple au lieu d'écrire 1000000, tu peux écrire 1_000_000.
Hélas, je me suis retrouvé dans une team où le jeune techlead avait décidé que les "_" c'était moche donc interdit. Encore hélas, je lui ai expliqué en vain que faisant sévèrement de la dysphasie, j'ai bcp de mal à distinguer plus de deux chiffres cotes à cotes, et donc 1/ la notation avec les "_" m'aide énormément, 2/ ça n'empêche pas les autres de lire.

Merci pour vos réponses, je prend note

[ducon]

Python aussi sait gérer les nombres écrits avec le tiret du 8.

[gros_bidule]

Comme la plupart des langages , c'est juste que le suis un néophyte en pythonlogie.

[Tramb]

Oui et ce merveilleux langage moderne a à peine attendu 15 ans et sa version 2.5 pour gérer les bigint de base.
HLL.

[ducon]

Et combien pour le C ?

[Tramb]

Le C n'a pas vocation à être haut niveau à sa décharge.
Python est à comparer à des langages de haut niveau garbage collectés.

[Anonyme20240202]

On t'a dit des conneries Whiskey. Tu fais comme tu veux du moment que t'es constant et idéalement a un truc reproductible (via un fichier d'IDE, ou autre outil du genre clang format) ou à défaut une documentation. Si t'as un truc reproductible c'est bien car tu peux facilement inclure d'autres gens dans le projet et automatiser la mise en forme pour avoir un truc cohérent.

Perso je trouve camel case dégueulasse et illisible donc j'utilise toujours des underscores pour les noms de fonction et les variables, pour les classes je reste en camel case mais généralement tu ne vois quasiment plus apparaitre les types dans le code, dans tous les languages à la mode (c++, language sans vraiment de type comme python, etc.) sauf lorsque tu appelles le constructeur directement.

Par exemple cher google z'ont un document qui décrit leurs conventions et point barre, parfois c'est justifié, parfois c'est juste un choix arbitraire par soucis de lisibilité et de cohérence:

https://google.github.io/styleguide/cppguide.html

D'ailleurs la librairie standard en C++ c'est du snake case, pareil pour Boost, donc ça n'a rien de vieux, c'est utilisé tous les jours

Le seul argument à peu près """viable""" c'est que parfois des mecs disent vouloir se distinguer de la librairie sous jacente qu'ils utilisent (qui est souvent snake_case) et donc utilisent camel case partout. Mais c'est bidon c'est juste choix.

L'important c'est la reproductibilité (et un minimum de cohérence interne, accord avec les autres contributeurs du projet, etc.)

- - - Mise à jour - - -

D'ailleurs concernant le 1_000_000

en C++ on a officiellement depuis C++14:

auto le_million = 1'000'000;

Elle est pas belle la vie

[Tramb]

D'ailleurs concernant le 1_000_000

en C++ on a officiellement depuis C++14:

auto le_million = 1'000'000;

Elle est pas belle la vie

Et en Ada depuis... 1983

[Anonyme20240202]

Ah excuse moi je vous avais pas vu

1 JavaScript 22.63%
2 Python 14.75%
3 Java 14.01%
4 C++ 8.45%
5 C 6.03%
6 PHP 5.85%
7 C# 5.03%
8 Shell 4.85%
9 Go 4.10%
10 TypeScript 3.89%
11 Ruby 3.27%
12 Jupyter Notebook 2.74%
13 Objective-C 1.99%
14 Swift 1.89%
15 Kotlin 1.28%
16 R 0.81%
17 Scala 0.78%
18 Rust 0.73%
19 Lua 0.69%
20 Matlab 0.53%
21 PowerShell 0.52%
22 CoffeeScript 0.50%
23 Perl 0.46%
24 Groovy 0.41%
25 Haskell 0.39%

Nan blague à part c'est une honte que le C++ soit resté dans cet état aussi longtemps, mais l'avenir est prometteur les choses avancent enfin

[TwinBis]

Ça pour avancer, ça avance.

https://thenewstack.io/microsoft-rus...s-programming/

(par contre ça s'eloigne du C++)

[Anonyme20240202]

J'espère vraiment que c'était du second degré parce que ces chaussettes incapables de chez Microsoft qui parlent de sécurité c'est la plus belle blague.

Tous leurs software puent la merde et meurrent enfin lentement remplacés par leurs équivalents open source, souvent du C/C++

C'est pas un langage différent qui rendra leurs soft pourraves meilleurs

In particular, Microsoft binaries are now almost completely built on the Microsoft Visual C++ compiler which produces MSVC binaries, whereas Rust relies on LLVM.

Mais quelle chiasse cet article hahaha, GCC, Clang, LLVM (et LLVM c'est du C++, MDR) peu importe, ça n'a aucun rapport.

Enfin bref, je hais Microsoft, avec flegme, mais énormément de mépris tout de même

(Sinon j'ai absolument rien contre Rust, ça a l'air cool)

(Et je défends pas le C++ hein, c'est juste un standard un peu fortuit, le language n'a rien de dingue, mais ça s'améliore)

[Whiskey]

On t'a dit des conneries Whiskey. Tu fais comme tu veux du moment que t'es constant et idéalement a un truc reproductible (via un fichier d'IDE, ou autre outil du genre clang format) ou à défaut une documentation. Si t'as un truc reproductible c'est bien car tu peux facilement inclure d'autres gens dans le projet et automatiser la mise en forme pour avoir un truc cohérent.

Perso je trouve camel case dégueulasse et illisible donc j'utilise toujours des underscores pour les noms de fonction et les variables, pour les classes je reste en camel case mais généralement tu ne vois quasiment plus apparaitre les types dans le code, dans tous les languages à la mode (c++, language sans vraiment de type comme python, etc.) sauf lorsque tu appelles le constructeur directement.

Par exemple cher google z'ont un document qui décrit leurs conventions et point barre, parfois c'est justifié, parfois c'est juste un choix arbitraire par soucis de lisibilité et de cohérence:

https://google.github.io/styleguide/cppguide.html

D'ailleurs la librairie standard en C++ c'est du snake case, pareil pour Boost, donc ça n'a rien de vieux, c'est utilisé tous les jours

Le seul argument à peu près """viable""" c'est que parfois des mecs disent vouloir se distinguer de la librairie sous jacente qu'ils utilisent (qui est souvent snake_case) et donc utilisent camel case partout. Mais c'est bidon c'est juste choix.

L'important c'est la reproductibilité (et un minimum de cohérence interne, accord avec les autres contributeurs du projet, etc.)

- - - Mise à jour - - -

D'ailleurs concernant le 1_000_000

en C++ on a officiellement depuis C++14:

auto le_million = 1'000'000;

Elle est pas belle la vie

Ok merci pour toutes ses précisions !

[Nilsou]

J'espère vraiment que c'était du second degré parce que ces chaussettes incapables de chez Microsoft qui parlent de sécurité c'est la plus belle blague.

Tous leurs software puent la merde et meurrent enfin lentement remplacés par leurs équivalents open source, souvent du C/C++

C'est pas un langage différent qui rendra leurs soft pourraves meilleurs



Mais quelle chiasse cet article hahaha, GCC, Clang, LLVM (et LLVM c'est du C++, MDR) peu importe, ça n'a aucun rapport.

Enfin bref, je hais Microsoft, avec flegme, mais énormément de mépris tout de même

(Sinon j'ai absolument rien contre Rust, ça a l'air cool)

(Et je défends pas le C++ hein, c'est juste un standard un peu fortuit, le language n'a rien de dingue, mais ça s'améliore)

C'est surtout qu'a chaque fois des mecs promettent mont et merveilles avec des langages qui seraient « sécurisés » implicitement question mémoire, et à chaque fois ça s’avère être soit complétement faux (toujours une fuite mémoire qui traine, parfois liée à la logique même de leur garbage collector, et le langage n'est qu'une suite de patch infini sur ceci) soit c'est lourd au possible et donc absolument impossible à employer dans des applications un tant soit peu limitées en puissance de calculs, soit on a doit toujours contourner la sécurité pour l'utiliser pour de véritables applications (via des mots clés du langage), ce qui revient au même finalement.

[ducon]

(c++, language sans vraiment de type comme python, etc.)

Python est typé, toute variable a un type, c’est-à-dire en fait une classe.
Tu peux préciser des types dans tes fonctions en Python mais ça reste indicatif, tu peux toujours contourner mais il faut le faire exprès.

[Tramb]

C'est surtout qu'a chaque fois des mecs promettent mont et merveilles avec des langages qui seraient « sécurisés » implicitement question mémoire, et à chaque fois ça s’avère être soit complétement faux (toujours une fuite mémoire qui traine, parfois liée à la logique même de leur garbage collector, et le langage n'est qu'une suite de patch infini sur ceci) soit c'est lourd au possible et donc absolument impossible à employer dans des applications un tant soit peu limitées en puissance de calculs, soit on a doit toujours contourner la sécurité pour l'utiliser pour de véritables applications (via des mots clés du langage), ce qui revient au même finalement.

Nan, quand même, safe par default c'est mieux.
Le nombre de bugs de sécurité parce que [] est unchecked par défaut en C et en C++ est faramineux.
Le unchecked devrait être opt-in.

[Orhin]

Tous leurs software puent la merde et meurrent enfin lentement remplacés par leurs équivalents open source, souvent du C/C++

lolno.

(ce qui ne change rien à la "qualité" de l'article par contre)
(et Microsoft fait pas mal d'open source depuis quelques années)

Je suis pas fan de crosoft mais à un moment faut essayer d'être un minimum objectif.

[TwinBis]

J'aurais du mettre un trigger warning avant mon lien on dirait.

(Je ne touche ni à C++ ni à Rust, donc le débat me laisse froid)

[ducon]

Oui, enfin c’est open source comme dans un peep show : tu paies pour regarder mais tu ne touches pas.

[Anonyme20240202]

Bah chai pas je suis dans l'industrie depuis un moment maintenant, j'ai programmé sur tout ce qui bouge, serveurs en tout genre, applications mobiles, WEB, clients classiques, GPU, FPGA, servo moteurs, tout ce que tu veux

Et j'ai jamais échoué à trouver une alternative open source, et à chaque fois c'est mieux. A vrai dire y'a la moitié trucs que je saurais même pas faire sous windows et je m'y pencherai jamais.

D'ailleurs je veux bien qu'on me cite un seul truc que Crosoft fait correctement, .Net core peut être, visual studio code.

On le voit avec des trucs comme Blender, désormais utilisé de plus en plus et qui devrait arriver à Hollywood si ça continue. Vulkan qui va on l'espère continuer à botter le cul de DirectX

Fin t'façon je vois même pas comment on pourrait défendre Microsoft très honnêtement, j'ai jamais rien vu de chez eux qui fonctionne bien, c'est même pire que ça: c'est souvent mal intentioné.

Ils ont complètement perdu le marché mobile alors qu'ils avaient un nouveau monopole facile à installer, Android (linux modifié) possède quasiment tout le marché now. Ils n'ont pas du tout le monopole côté serveur (me semble que c'est du 40% pour eux désormais) et j'ai jamais rencontré un seul mec qui apprécie travailler avec des serveurs windows. Niveau développement c'est tout simplement une blague, tout le monde déteste développer sous Windows.

Faut pas oublier qu'un téléphone c'est une machine comme une autre, les téléphones d'aujourd'hui sont plus puissants que les PCs des années 2000. Microsoft qui perd le marché mobile c'est la preuve qu'un rien pourrait leur faire perdre le marché desktop de la même manière.

Dans TOUTES les entreprises ou j'ai bossé, le pool de truc microsoft est issu d'un lobby au niveau des achats en gros, c'est jamais une décision pragmatique/justifié technologiquement, de la même manière que Lotus Note (IBM je crois) ou autres daubes du genre

Donc il leur reste que les desktops, il suffira d'un rien pour que Windows se fasse rayer de la carte comme se fut le cas sur mobile, et on n'en parlera plus.

Lenovo a fait un pas dans cette direction, Unreal Engine de même, enfin bref, c'est un miracle que cette vieille moule de windows s'aggripe encore à son rocher.

Je suis honnêtement ouvert à des exemples de trucs Microsoft cool, mais le simple fait que ce soit pas open-source la majorité du temps est un énorme point noir, je suis incapable de citer un truc Microsoft dont je me servirais. Sans compter le monceau de casseroles qu'ils se trainent

[Tramb]

Sans DirectX y aurait jamais eu Vulkan ni même d'OpenGL moderne.
Même le reste du monde (Linux, FreeBSD) a besoin de la compétition avec MS sinon ça s'enlise, à mon avis.

(Microsoft research fait des trucs bien chouette sinon, mais ça ne devient pas forcément des produits )

[Anonyme20240202]

Ah? En quoi ça a contribué à ces initiatives? Je suis pas hyper versé dans l'histoire de l'émergence de ces projets

Si jamais tu sous entend que c'est du à l'aspect compétitif pour moi ça sonne un peu comme "Top 10 des inventions issue de la WW2" (https://www.thevintagenews.com/2016/...d-live-better/)

Après ouais pourquoi pas, c'est vrai qu'une de mes grandes motivations souvent c'est de proposer une alternative à un truc Windows haha

[Cwningen]

C'est surtout qu'a chaque fois des mecs promettent mont et merveilles avec des langages qui seraient « sécurisés » implicitement question mémoire, et à chaque fois ça s’avère être soit complétement faux (toujours une fuite mémoire qui traine, parfois liée à la logique même de leur garbage collector, et le langage n'est qu'une suite de patch infini sur ceci) soit c'est lourd au possible et donc absolument impossible à employer dans des applications un tant soit peu limitées en puissance de calculs, soit on a doit toujours contourner la sécurité pour l'utiliser pour de véritables applications (via des mots clés du langage), ce qui revient au même finalement.

Rust n'a pas de garbage collector. C'est une gestion mémoire assez proche du C++ mais en plus strict (comme la vérification de la durée de vie lors des emprunts). Le point qui m'avait déçu quand j'en avais fait un peu c'était les flottants, ce sont des IEEE 754 avec leurs valeurs bizarres et ne sont donc pas totalement ordonnés. Au final ils ne sont ni sûrs ni pratiques, mais ça doit pas être possible à résoudre tout en restant performant. Il faudra que je m'y remette quand même, c'est un langage que j'ai envie d'aimer mais je cède trop facilement au confort de mes langages habituels.

Python est typé, toute variable a un type, c’est-à-dire en fait une classe.
Tu peux préciser des types dans tes fonctions en Python mais ça reste indicatif, tu peux toujours contourner mais il faut le faire exprès.

Je pense qu'il voulait parler de typage dynamique, c'est à dire que la variable n'a pas de type fixe et il peut changer au cours de sa vie. Ou vu autrement : le contenu de la variable a un type mais pas la variable elle-même.

Nan, quand même, safe par default c'est mieux.
Le nombre de bugs de sécurité parce que [] est unchecked par défaut en C et en C++ est faramineux.
Le unchecked devrait être opt-in.

Il me semble que l'implémentation de Microsoft vérifie l'index de std::vector::operator[] quand on compile en debug par défaut. Je ne sais pas s'il y a quelque chose pour les tableaux C par contre.