Reprise du message précédent :
Excel...
Des millions de boite ne pourraient pas fonctionner sans ce logiciel merdi à tout faire.
 
Un fournisseur américain me fait utiliser un excel bourré de macros de mayrde en VBA (pléonasme), pour générer des binaires à faire bouffer à un système tournant sous windows CE    
 
J'avais un bug dans une macro et ils ne comprenaient pas pourquoi ça marchait chez eux et pas chez moi.
 
Explication:
Pour vérifier qu'un nombre avait des décimales, ils faisaient la conversion de ce nombre en string, et vérifiaient la présence du caractère "."   .
Bien sûr les préférences régionales étant euh... gérées je dirais, sous excel, chez nous le séparateur décimal est ",".
Du coup leur macro ne passait jamais dans leur condition...
 
Ils m'ont quand même dit que nous les français on ne faisait jamais rien comme tout le monde
Je leur ai bien sûr rappelé les unités impériales...

Ca je me fait souvent niquer sur ces questions de ","/".". A coup sur le pc du boulot est en séparateur US pour pas être emmerdé    
Et si un csv ou autre fichier brut passe pas, je fait une conversion des "," en "." ou inversement et hop
 
Mais le plus croustillant que j'ai eu c'était un script linux qui faisait des regex sur les sorties en anglais des utilitaires du système. Manque de pot j'avais des sorties en français donc il se vaudrait en beauté  

Au boulot j'ai entendu "ça ne peut pas marcher à cause d'un problème d'adhérence de code."    
 
Très efficace en réunion car personne n'ose demander ce que ça veut dire ...  
 

 
C'est pas le pire par rapport à la m**** à gérer qu'est le MM/JJ/AAAA

 
Ca me rappelle un discussion avec un collègue  
- Ouais euuhhh ta date, là c'est jj/MM/aaaa ou MM/jj/aaaa ? Parce que bon hein ?
- Bein je sais pas quand tu vois 13/12/2013, tu ne devine pas un peu ?
 
Mon problème est réglé, je n'utilise plus que aaaa/MM/jj

 
Mais c'est pas toujours non-ambiguë, c'est justement le problème

Militons : http://fr.wikipedia.org/wiki/ISO_8601

Sous Excel on peut utiliser jj-xxx-aa
C'est ce que je fais pour mes fichiers de stocks lus par je ne sais combien de péquins dans de lointaines et variées contrées (parce que bien sur l'erp ne sait pas extraire ce type d'info de la base ).
 
Ce qui est grave c'est qu'en tant qu'utilisateur, j'en viens à espérer qu'aucune amélioration ne soit apportée au logiciel, vu qu'à chaque mise en prod d'un patch c'est la merde à certains niveaux.
Et quand la merde en question est juste un popup qui ploppe à chaque action ou une info qui disparait mais qu'il est facile de retrouver "l'erreur n'est pas bloquante, c'est pas prioritaire"

Ouais j'utilise ça depuis quelques années, c'est tellement plus pratique
en plus avec les "-" tu tapes ça dans les noms de fichiers sans soucis.
Il me semble que c'est au Japon qu'ils utilisent aaaa-mm-jj comme format de date standard

Et ça classe par date lorsqu'on trie les fichier par nom.

 
Excel et les . et les ,
 
Je me souviens qu'on m'avais forcé à développer un truc en VBA, les fichiers d'entrée avait des .
La fonction Excel n'utilisait que les ","
 
Résultat, fallait convertir les , en . pour les reconvertir ensuite en , et re-reconvertir en . parce que la deuxième fonction était "bien" programmée  
 
Les anglos saxons  

 
Sans oublier les différentes manières (im)possibles et (in)imaginables que l'on trouve pour effectuer cette "conversion"...  

Tu as échappé à  

 
mes préférés
 

C'est vrai que c'est beau quand tu tombes sur du "if (val == true) return true else return false"
Mais c'est gentillet, et je pense que le compilo sait optimiser ça.

 
Le compilo peut être, mais en attendant ce sont mes yeux qui saignent  
 
Voilà le genre de tromblons que je me coltine à longueur de journée :
 

flute je comprends pas, j'aimerais savoir coder pour ce genre de blagues privées

if true then true else false.

 
Ce ne sont malheureusement pas des blagues
 
Pire encore ! ça marche très bien !
 
Et comme tu le dis, tu ne comprends pas car tu ne sais pas coder... normal, ça s'apprend... Et c'est bien tout le problème de cette "blague", c'est que ceux qui "commettent" ça ne savent pas coder non plus.. ET ON LES LAISSE FAIRE  

Blinkage:
En gros pour savoir si un nombre est négatif, plutôt que de savoir si il est < à 0, là on le convertit en texte et on regarde si il commence par un moins    
 
Apprendre à coder c'est pas compliqué

 
ça se trouve parfois oui

#define TRUE FALSE
 

si vous voulez du code dedeulasse ... je vais vous sortir des progammes indus pour des automates c''est souvent immonde

 
A mon "époque", le code dans l'industrie se voulait "astucieux" pour pouvoir être "optimisé" selon les contraintes physique et technique du matos... pas toujours très propre, certes, mais toujours justifié !
 
ça a changé depuis ?

merci
ils devraient faire comment pour faire du "propre" ? et ca changerait quoi à part l'amour du code, ce serait davantage rapide à exécuter pour le processeur ?

Programmation par petits bouts de codes clairs (programmation orientée composant), le tout bien indenté, noms de variables explicites avec une portée intelligente. Si des passages sont complexes niveau algo, commenter ce qui est nécessaire. Rester générique au possible. Ne pas mettre des débug de partout une fois en prod. Avoir un bon outil de suivi de version (Git) et un workflow sûr (qui intègre, qui code, bref qui fait quoi). Enfin, l'idéal c'est d'avoir un code testable, comme ça avec des outils d'intégration continue, tu sais de suite si tu fais des régressions quand tu changes des choses (« casser le build »).

Ça change : qualité, évolutivité, maintenabilité, facilité d'intégrer des nouveaux sur le projet, sécurité et donc au final grosse réduction des coûts et des délais.

Je vois pas bien où c'est le cas ici ?

Tu parles de trouver si  un entier est négatif ? : (value < 0) tout simplement.
Sans même parler de perfs, c'est se compliquer la vie pour rien, c'est sous-optimal et moins robuste si dans une langue inconnue par exemple on met pas un '-' mais un quelconque autre caractère ou si on le met à la fin, etc... des conneries comme ça auxquelles personne ne pense mais des bugs potentiels.
Ça montre une façon de penser tortueuse et une méconnaissance de la programmation.
 
En simplifiant à l'extrême, en termes de perf, les cpu sont câblés pour faire des comparaisons arithmétiques de ce genre en un cycle d'horloge, passer par une représentation textuelle te prendra genre 20 fois plus de cycles, des écritures en RAM inutiles, etc...
Si ce bout de code est dans un calcul intensif, tu pourris tes perfs bêtement.
 

Ce message venu d'un autre monde

Si ta condition est vrai alors il retourne vrai, si elle est fausse il retourne faux.  
 
Qu'il retourne la condition cela sera plus rapide (et même mieux il la teste directement plutôt que de faire une fonction séparée).

En pratique le code industriel c'est souvent un seul type qui a tout géré du cahier des charges aux essais finaux en passant par le codage du merdier avec toutes ses suxxeries, les schémas de câblage et la documentation...  
 
 

Sur la grande majorité des systèmes informatiques, le système utilisé pour la représentation des nombres permet de savoir si un nombre est négatif juste en regardant un bit, donc grosso modo un test supérieur / inférieur à 0 c'est quasiment une instruction de base du processeur.
La méthode qu'il décrit consiste à faire traduire en texte le nombre, pour voir si le premier caractère est un "-". Bref tu brasse toute une usine à gaz qui doit prendre au moins 100x plus de temps de calcul... pour réinventer l'eau chaude...

Je me demande souvent combien de programmeurs savent encore un petit peu comment ca marche vraiment dans les processeurs ( piles de code ,pile de donnees , registres ,...)  histoire de ne pas faire de conneries stupides comme celle-la

C'est enseigné mais les devs oublient vite a force de faire du java.

C'est pour ça que je suis content d'avoir appris le fonctionnement du CPU, fait de l'assembleur, du C, puis du C sous Windows (l'API Win32 de base et tout), puis seulement des langages plus évolués qui encapsulent tout (C++, Delphi, C#)
Pour ça Delphi était pas mal : dans tous les objets évolués fournis, on pouvait aller voir le code de base caché derrière, voir quels appels à l'API ça faisait. Et on pouvait aussi voir le code assembleur généré correspondant, quand on était motivé

ou pire... du c#
et quand ils codent du C, je te raconte pas le bordel....

En effet de temps en temps un malloc() mal foutu et hop des failles béantes comme heartbleed  

 
Pour faire claire tout ça se résume à

 
1) lâche mon cahier d'exercice Isométriques s'il te plaît.
2) je parlais évidement à l'échelle globale, pas pour ce petit bout de code
 

 
Je ne sais que trop bien, pour écrire mon post j'ai justement pensé à l'inverse de tous les projets que j'ai pu voir dans des SSII ou des grosses boîtes (industrie ou service)

Ah oui je vois. Mais c'est bien plus lisible/compréhensible d'écrire ça comme il l'a fait, plutôt que de retourner directement l'expression booléenne. Les optimisations du compilateur sont là pour *normalement* donner le même résultat au niveau assembleur
 
Bref, c'est pas l'humain qui doit s'adapter à la machine, mais la machine qui doit s'adapter à l'humain.