Le topic de la programmation: Et envoyez des sioux!

**William Vaurien** · 06/09/2018, 21h03

J'avais trouvé un truc marrant et sympa qui générait un graph à partir de javascript:
http://gitgraphjs.com/

Mais ça à l'air de ressembler pas mal au truc de ton lien...

**vectra** · 06/09/2018, 21h44

C'est bien mieux et bien plus lisible question rendu, mais c'est peut-être un poil trop pénible de devoir écrire une page pour ensuite récupérer une image.
J'avoue que Graphviz me plait bien question facilité et simplicité, j'aurais espéré quelque chose d'avoisinant.

Ou alors un style LaTex

**ducon** · 06/09/2018, 21h46

Tu crées une extension pour LaTeX ?

**vectra** · 06/09/2018, 22h03

Déjà fait!
https://tex.stackexchange.com/questi...itory-in-latex

C'est pas mal en plus.

**rOut** · 08/09/2018, 01h12

- git log --graph --oneline --decorate --all
- tig log --graph --oneline --decorate --all
- gitg

En fait je vois pas bien ce que tu veux faire ?

**Nilsou** · 08/09/2018, 01h26

Sinon gitlab l'a en natif, et se mettre en place un gitlab c'est pas si long.
C'est un plus sexy que le --decorate

**vectra** · 10/09/2018, 10h10

Oh, c'est bieng gitg

je connaissais le 'decorate all', mais je trouvais ça un peu trop too much.

Sinon, en temps normal, je me débrouille avec Bitbucket et plugins, mais pour ça faut pusher.

A l'origine, je voulais un truc qui permette de faire des slides de présentation de Git, mais à usage pour moi tout seul.
Et un truc 'à la graphviz' est parfait pour moi car ça s'intègrerait à la perfection dans emacs.

**yuushiro** · 13/09/2018, 11h29

Envoyé par vectra

C'est bien mieux et bien plus lisible question rendu, mais c'est peut-être un poil trop pénible de devoir écrire une page pour ensuite récupérer une image.
J'avoue que Graphviz me plait bien question facilité et simplicité, j'aurais espéré quelque chose d'avoisinant.

Ou alors un style LaTex

Merci pour Graphviz; je cherchais en effet quelque chose depuis un petit bout de temps pour dessiner une matrice de responsabilité applicative avec un placement un peu ordonné des éléments en fonction de leurs ancêtres et fils.
Il faut maintenant que j'essaye de faire fonctionner ça.

**Frypolar** · 13/09/2018, 19h00

Envoyé par William Vaurien

J'avais trouvé un truc marrant et sympa qui générait un graph à partir de javascript:
http://gitgraphjs.com/

Mais ça à l'air de ressembler pas mal au truc de ton lien...

Merci ça m’a servi il y a peu et ça va encore me servir

Au boulot on parle intégration continue et compagnie, beaucoup ne veulent pas entendre qu’il ne suffit pas de cocher la case « CI » dans un outil de build pour y arriver

**William Vaurien** · 14/09/2018, 09h15

Aller, ce matin je suis motivé, il y a un Jira qui traine depuis longtemps sur un truc de maintenance dans le vieux code C.
En fait c'est une migration technique qui peut se faire de temps en temps et les fichiers impactés sont retrouvés grâce à une grosse regexp des familles en changeant à chaque fois le nom d'une table de base de données.

C'est un peu la loterie à chaque fois.

Ce matin j'ai tiré le gros lot:

Avec dans la plus pur tradition du C 89: toutes les variables déclarées en haut et une dizaine d'imbrications.
Le code n'est pas compliqué à lire, mais un effet secondaire est vite arrivé sur toute modification car c'est dur de comprendre l'impact du moindre changement et d'avoir une vision d'ensemble...

bref

**Nattefrost** · 14/09/2018, 09h19

Je vous souhaite bien du plaisir monsieur Vaurien

**Tramb** · 14/09/2018, 09h31

Je ne crois pas que le C soit en cause, là

**William Vaurien** · 14/09/2018, 10h22

J'ai quand même l'impression que chez les 'grands anciens', on retrouve ce pattern: variables toutes déclarées en début de fonction (nécessaire dans les vieux compilo) et grosses méthodes peu modulaires, ce qui était peut être plus simple à gérer du temps des écrans 80 lignes 40 colonnes sans IDE ni coloration syntaxique...

Pas vraiment la faute du C, mais un peu quand même.

**Tramb** · 14/09/2018, 10h24

Lis le code de FreeBSD ou de Linux par exemple, tu trouveras ça modulaire et bien mieux foutu que 98% des projets en C++ que je vois passer.

**William Vaurien** · 14/09/2018, 10h46

Là ça revient à comparer des Bentley et des Fiat...

**vectra** · 14/09/2018, 11h55

Envoyé par William Vaurien

J'ai quand même l'impression que chez les 'grands anciens', on retrouve ce pattern: variables toutes déclarées en début de fonction (nécessaire dans les vieux compilo) et grosses méthodes peu modulaires, ce qui était peut être plus simple à gérer du temps des écrans 80 lignes 40 colonnes sans IDE ni coloration syntaxique...

Pas vraiment la faute du C, mais un peu quand même.

Euh, même dans l'embarqué, j'ai des exemples où on bosse en C++14.
Et s'il n'y a pas de guidelines de code dans ta boîte, c'est pas forcément le cas partout. Je sais pas, vous faites jamais de revues de code pour les pull-requests?
Si les reviewers n'approuvent pas la requête, y'a pas de merge de branche possible...

**TiNitro** · 14/09/2018, 13h13

Envoyé par William Vaurien

J'ai quand même l'impression que chez les 'grands anciens', on retrouve ce pattern: variables toutes déclarées en début de fonction (nécessaire dans les vieux compilo) et grosses méthodes peu modulaires, ce qui était peut être plus simple à gérer du temps des écrans 80 lignes 40 colonnes sans IDE ni coloration syntaxique...

Pas vraiment la faute du C, mais un peu quand même.

oui on retrouve souvent ce pattern chez les anciens, non ce n'était pas plus simple à gérer. C'est vraiment que le découpage n'est pas naturel quand tu découvres la programmation en autodidacte, et que les bonnes pratiques ont mis longtemps à se répandre.
Disons aussi qu'en Fortran 4 il y avait moins de bénéfices à découper, mais bon...

**Møgluglu** · 14/09/2018, 14h13

Ouais, l'écran 80 colonnes 24 lignes encourage plutôt à écrire des petites fonctions avec des variables locales (cf conventions de codage Linux de nazi où une fonction doit tenir sur 1 ou max 2 "écrans"). C est un langage moderne structuré orienté fonction.

Les mauvaises habitudes c'est effectivement plutôt les premières versions de Fortran et autres langages où GOTO est l'instruction de base et où le paquet de cartes perforées numérotées est la structure de code de base, et si tu déclares tes variables globales tu préfères avoir toutes les déclarations ensemble dans un paquet à part pour les retrouver facilement.

Et puis quand la bonne pratique était commencer par prendre son papier quadrillé, son Pentel 0,5 et son gabarit pour dessiner un organigramme :

**TiNitro** · 14/09/2018, 14h59

oui, les vieux assembleurs et la 1èere version de Fortran n'avaient pas de fonctions / subroutines.
Ca a été ajouté par la suite, mais sans grande puissance pour passer des arguments / retourner des résultats complexes, moralité ils mettaient tout dans des zones COMMON déclarées en début de routine.

Ca a créé des très mauvaises habitudes.

J'ignore à quoi ressemblaient Cobol (je n'en ai jamais fait) mais ça du suivre le même genre de chemin.

**yuushiro** · 14/09/2018, 15h15

Je confirme pour le COBOL, toutes les variables sont déclarées en début de copy, donc ça oblige souvent à remonter en haut de fichier pour savoir ce que l'on a déclaré.
L'avantage, c'est que lorsque tu cherches tes variables tu as pas besoin de fouiller tout le code; ce qui n'est plus vrai avec les IDE d'aujourd'hui où il suffit de mettre en surbrillance la variable pour connaitre son type (adieu les vieille règle de nommage à la VB6 strMaVar, bMavar, etc.... *sig*)

**TiNitro** · 14/09/2018, 15h30

ouais enfin, si tu as une fonction qui fait 3000 lignes (pleurez, on en a) le surlignage ne te sauve pas.

Enfin rien ne te sauve, il te reste que la fonction de recherche.

**vectra** · 14/09/2018, 15h34

BMDJ:

https://plugins.jetbrains.com/plugin/7095-org4idea

Il ne manque plus que Org-mode sur Jira/Bitbucket, et mon bonheur serait parfait.

**Møgluglu** · 14/09/2018, 15h42

Envoyé par yuushiro

Je confirme pour le COBOL, toutes les variables sont déclarées en début de copy, donc ça oblige souvent à remonter en haut de fichier pour savoir ce que l'on a déclaré.
L'avantage, c'est que lorsque tu cherches tes variables tu as pas besoin de fouiller tout le code; ce qui n'est plus vrai avec les IDE d'aujourd'hui où il suffit de mettre en surbrillance la variable pour connaitre son type (adieu les vieille règle de nommage à la VB6 strMaVar, bMavar, etc.... *sig*)

Bah le type c'est facile, si le nom commence par une lettre entre I et N c'est un entier, sinon c'est un flottant.

Sinon un truc qui m'a fait marrer. Déjà de découvrir l'existance d'un concours de programmation APL en 2018. Bon, pourquoi pas.
Puis de lire dans la bio d'un des gagnants :

10 years ago, I abandoned COBOL and started using APL.

Oui, j'ai vérifié plusieurs fois pour être sûr. C'est bien en 2018.

**Logan** · 14/09/2018, 15h49

Du coup il a arrêté le COBOL en 2008, et c'est pas bien c'est ça ?

**TiNitro** · 14/09/2018, 16h00

putain pour se mettre à APL en 2008 ???!!!!
Misère.

APL punaise.... Aux environs de 2008 j'ai mis un dev à la retraite parce qu'il ne savait faire que ça...

**William Vaurien** · 14/09/2018, 16h08

Pour aller avec mes mains pourris de 1000 lignes, j'ai eu le droit au PL/SQL de 2000 lignes aussi \O/

Bon pour le coup c'était plus simple, juste changer des trucs dans des inserts. Mais c'est quand même bien la misère.

**Møgluglu** · 14/09/2018, 16h20

Envoyé par Logan

Du coup il a arrêté le COBOL en 2008, et c'est pas bien c'est ça ?

Jelb : en 2008 il a arrêté COBOL, un langage qui date de 1960, pour se mettre à APL, un langage qui date de 1962. Imagine quand il va découvrir ALGOL 68 et Modula 3.

Et d'après son age il est né en 1981. Je suis jaloux.

**Helix** · 14/09/2018, 17h46

Ceci dit, les anciens langages c'est parfois bien. Je programme principalement en Common Lisp, et je ne suis pas prêt de laisser tomber

Mais je ne programme pas dans une équipe de dev.

**Tramb** · 14/09/2018, 17h51

Envoyé par Helix

Ceci dit, les anciens langages c'est parfois bien. Je programme principalement en Common Lisp, et je ne suis pas prêt de laisser tomber

Mais je ne programme pas dans une équipe de dev.

Oui enfin c'est pas un langage obsolète, ça.

**Helix** · 14/09/2018, 18h02

Envoyé par Tramb

Oui enfin c'est pas un langage obsolète, ça.

Ce n'est pas l'avis de mes collègues, sauf après que je leur montre des bouts de codes.
Mais rien à avoir avec l'APL, c'est vrai.

Discussion: Le topic de la programmation: Et envoyez des sioux!

Outils de la discussion

Règles de messages