Mauvaise programmation

[gege]

Bonjour,
J'écris un article (hum hum) sur les façons parfois horribles que nous programmons nos bébêtes.
Avez-vous des idées ?
Pas votre code bien sûr, qui est parfait, hein, celui des autres ces "noobs" comme disent les djeunz !

Attention on ne parle pas de bugs, mais par exemple d'un même calcul qu'on refait à chaque fois dans une boucle, etc...
Allez racontez !
G.E.

[kenneth]

sur oric a mes debuts j utilisait l instruction "pop" reservee aux programmes mal fagotes. En Basic ca consistait a sortir sauvagement d une sous-routine appelee par un GOSUB ....sans RETURN.

[Hobiecat]

Ayant programmé à une époque où l'octet était rare, il me semble que la programmation était relativement optimisée.

Cependant j'avoue sur de la programmation sur la HP-41CV où la place était un peu plus disponible avoir fait de la programmation à la volée (c'est-à-dire sans support papier ), avec recours à des facilités, comme par exemple se limiter aux tests "x=0?" sans se soucier du nombre d'octets, pour ne pas se compliquer la vie ! Bien sûr, refaire le même calcul plusieurs fois parce qu'on a la flemme de chercher quel registre contient le bon résultat est aussi de la partie !

En même temps, quand je vois le Giga-octets qu'installent les systêmes comme windows, je me dis que le code doit être infesté de ces programmations un peu bâclées...

[pir2]

Dans mon monde de l'EAI, j'ai implémenté un framework qui trappe automatiquement toutes les erreurs, du coup, les codeurs qui l'utilisent ne se posent plus de questions et ne font plus de tests d'exceptions, ce sera capturé en production et géré par les équipes de supports

Idem pour les opérations faites dans les boucles, ce qui marche bien en tests unitaires avec des listes de moins de 10 éléments, sur un seul test, devient catastrophique en production, avec des milliers de messages contenant des listes de centaines d'objets ... (j'ai aussi fait ces choses moi-même, mais vite réagi aux premiers symptômes, çà ne s'est pas vu )

Autre anecdote dans le genre, mais rapporté par un collègue. Dans un programme d'édition en COBOL (donc fin des 80's), juste avant une mise en production, quelqu'un avait remplacé par inadvertance un AFTER LINE par un AFTER PAGE. Le site d'impression étant distant de quelques kilomètres, c'est un camion qui avait ramené les listings ...

J'ai fait ça plus tard moi-même en imprimant avec le mauvais code sur la mauvaise imprimante (postscript), l'imprimante étant à l'époque à côté de mon bureau, je n'avais gâché qu'une rame de papier A4, j'ai eu des brouillons pour plusieurs années

[zpalm]

Une anecdote sur les effets de bord d'un changement mineur effectué au dernier moment sans vérification suffisante :
En 2011 intel a du rappeller des millions de PCs à cause d'un problème sur les ports SATA.

c|net:
How issue was discovered: Last week customers started telling Intel that there was an issue. As Intel stressed the part, Intel's labs started seeing a failure to access ports 2 through 5. The Intel stress test simulated time passing and it showed that over time this issue could come up.
How many Sandy Bridge chipsets shipped to date: 8 million. But Intel claims relatively few are in customers' hands. Most of those are in the sales channel and will be pulled out of the channel. Intel is supporting PC makers in this effort.

La raison ? Un changement effectué juste avant la mise en production sur un seul transistor sur les millions que compte un circuit intégré !!! Petite cause, grands effets.

Anandtech:
I just got off the phone with Intel’s Steve Smith (VP and Director of Intel Client PC Operations and Enabling) and got some more detail on this morning’s 6-series chipset/SATA bug.
[…]
The problem in the chipset was traced back to a transistor in the 3Gbps PLL clocking tree. The aforementioned transistor has a very thin gate oxide, which allows you to turn it on with a very low voltage. Unfortunately in this case Intel biased the transistor with too high of a voltage, resulting in higher than expected leakage current.
[...]
To make matters worse, the problem was inserted at the B-stepping of the 6-series chipsets. Earlier steppings (such as what we previewed last summer) didn’t have the problem. Unfortunately for Intel, only B-stepping chipsets shipped to customers.
[…]
While Steve wouldn’t go into greater detail he kept mentioning that this bug was completely an oversight. It sounds to me like an engineer did something without thinking and this was the result.

[billaj]

Holala...
Sur ma TI-83, dans ma folle jeunesse, je mettais du GOTO dans tous les sens, même pour sortir des boucles. En fait je crois me rappeler que faire ça pourrissait la pile et que donc il fallait malgré tout exécuter un END après être sorti comme un sauvage. Bref mes boucles se terminaient donc par fatras infâme de GOTO, END et LBL.

[gege]

Il y a un article là-dessus dans la Gazette n°7.
G.E.