/* Topic des codeurs [8] */

grim7reaper · Le 03/07/2013, à 02:36

Shanx a écrit :

j’ai placé tout ce qui concernait le curseur de la base de donnée en dehors du main, en tant que variable globale. Il me semble qu’en faire une classe serait un peu mieux, mais j’avoue ne pas du tout savoir comment faire

Bah je verrai un truc simple du genre une classe qui a le curseur en tant qu’attribut.

Shanx a écrit :

la connexion à la bdd pourrait se faire avec un with ou pas ? Est-ce que j’y gagnerai quelque chose ?

Je n’ai pas trop regardé le code (vu qu’apparement tu y as apporté des changements depuis hier), mais en général le with ça permet d’être sûr que tu va libérer la ressources correctement. Même en cas d’exception.
Après faut voir si la connexion supporte le with, ça dépend comment ça a été codé…

Shanx a écrit :

d’une manière plus générale, avez-vous des remarques pour le code (robustesse, conventions, erreurs, etc.) ?

Oui, ça manque de commentaire.
Par exemple, quand on bosse avec des grandeurs physiques c’est sympa de connaître les unités.
Là, vu les bornes min/max je devine que c’est du °C mais ça devrait être explicitement indiqué.
Une valeur physique sans unité n’a aucun sens…
Au passage, ta borne min est fausse : on a déjà eu du -89,2°C sur Terre (base antarctique Vostok).

Shanx a écrit :

J’utilise des tabulations pour indenter, et pas des espaces. À titre personnel, je trouve les tabulations vraiment plus pratiques. Quels sont les arguments expliquant que PEP8 conseille les espaces ?

Bon Rolinh a déjà tout dit, mais je vais le répéter :
- En quoi c’est plus pratique (un éditeur bien configuré va t’ajouter N espaces avec la touche tab, et la touche effacer aura le même comportement si ton éditeur est intelligent) ?
- Le rendu du code va être différent selon la conf’ de l’éditeur du gus
- pire, et si tu mélange tab et espace ça risque de carrément casser du code, voire (vu que Python est sensible à l’indentation) induire des bugs super casse couille à trouver…

Shanx a écrit :

À partir des données stockées dans la bdd, je vais devoir faire des graphiques et des courbes. Que conseillez-vous pour le faire ? J’ai rapidement jeté un œil à GChartWrapper, mais je n’ai pas réussi à l’installer (je suis passé rapidement sur la question, si vous me dites que ça convient je verrais ça plus en profondeur demain)

matplotlib, tu as des exemples de ce que tu peux faire ici et là.
Je pense que ça va largement répondre à ton besoin

Elzen · Le 03/07/2013, à 11:08

Shanx a écrit :

J’utilise des tabulations pour indenter, et pas des espaces. À titre personnel, je trouve les tabulations vraiment plus pratiques. Quels sont les arguments expliquant que PEP8 conseille les espaces ?

On peut recommencer à troller sur des pages et des pages, mais je crois que c'est essentiellement une question de ressenti personnel. En l'occurrence, chacun des arguments avancés par grim et Rolinh en faveurs des espaces aurait tendance à me convaincre d'utiliser plutôt des tabulations.
J'me permet de développer un poil, mais ça n'a pour but de convaincre personne, et ça n'attend pas de réponse, c'est juste pour exprimer un peu plus spécifiquement cette dichotomie.

grim7reaper a écrit :

Le rendu du code va être différent selon la conf’ de l’éditeur du gus

…ce qui est justement un avantage. Si tu n'apprécies pas, visuellement parlant, l'indentation de quatre colonnes, par exemple (genre, deux ou huit te semblent beaucoup plus lisibles… c'est un ressenti visuel sur lequel on ne peut pas tous être d'accord), et que le gus dont tu lis le code a indenté avec quatres espaces, bah tu n'as pas d'autre choix que de lire quatre espaces. S'il a indenté avec des tabulations, tu règles la taille de ces tabulations comme ça t'arrange, et le code s'adapte.

Après, ça dépend du code, bien sûr. Quand on veut aligner les colonnes entre elles (genre, faire démarrer le « then » juste en dessous du « test » dans un script shell, par exemple), les espaces sont indispensables… mais dans ce cas, on n'utilisera de toute façon pas forcément un nombre d'espaces fixes pour l'indentation, et puis, ce sont des cas assez rare. La majorité du temps (de ma modeste expérience, du moins), du moment que les blocs sont correctement décalés entre eux, que ce soit aligné sur telle ou telle colonne n'apporte pas grand chose, donc les tabs conviennent parfaitement, en permettant à chacun de rendre les choses visuellement agréables.

Rolinh a écrit :

Il suffit qu'un mec édite ton code source, ait un tab réglé sur 2 ou 8 (enfin, pas le même tab que toi quoi), il modifie 2 lignes et il flingue tout.

…en cas d'utilisations d'espaces, et uniquement dans ce cas.
Si vous utilisez tous les deux des tabulations, chacun des deux éditeurs mettra toutes les tabs à sa taille à lui, et ce sera transparent pour vous deux, sans rien flinguer du tout. Par contre, oui, si l'un des deux utilise des espaces, il faudra soit que les deux coordonnent leurs tailles d'indentation, soit que l'un des deux passe son temps à rectifier ce que fait son éditeur pour l'adapter à ce que fait l'autre. Bonjour la souplesse.

grim7reaper a écrit :

pire, et si tu mélange tab et espace ça risque de carrément casser du code, voire (vu que Python est sensible à l’indentation) induire des bugs super casse couille à trouver…

Le soucis, c'est le mélange mal foutu, oui. Sauf cas exceptionnel, faut éviter de mélanger. Mais ça marche dans les deux sens (ça foirera autant si tu codes avec des espaces et qu'un gus vient fiche des tabulations, que si tu codes avec des tabulations et qu'un gus vient fiche des espaces).

Rolinh a écrit :

Pour le côté pratique, il suffit de bien réglé son éditeur et du coup, l'utilisation d'espaces à la place de tabs devient transparent.

grim7reaper a écrit :

En quoi c’est plus pratique (un éditeur bien configuré va t’ajouter N espaces avec la touche tab, et la touche effacer aura le même comportement si ton éditeur est intelligent) ?

En résumé, les deux sont aussi pratiques… à condition, pour les espaces, de s'être paluché une configuration aux petits oignons d'abord ; alors que pour les tabs, il suffit de prendre l'éditeur dans son état de base, et ça marche bien. En gros, les espaces sont aussi pratiques… quand tu codes dans ton environnement à toi, perso, en espérant que tu n'aies jamais besoin d'éditer un de tes programmes depuis une autre machine (ouais, j'exagère un peu, désolé )

Rolinh a écrit :

Non, plus sérieusement, c'est bien de suivre les recommandations/bonnes pratiques d'un langage. Surtout que pour le coup, en Python l'indentation compte vraiment...

Il y a PEP8, donc oui, en démarrant un nouveau truc de code, qui est destiné à être diffusé, il vaut mieux utiliser des espaces, pour s'y conformer ; mais l'existence de la recommandation ne justifie pas cette recommandation.

En l'occurrence, et précisément parce que l'indentation compte en python, j'aurais d'autant plus tendance à y favoriser les tabulations, pour une raison toute bête : avec des tabs, un niveau d'indentation supplémentaire == un caractère (même si plusieurs colonnes pour le confort visuel). C'est le truc qui me semble plus logique avec les tabs. Mais je conçois tout à fait que ça ne « parle » pas à d'autres.

Encore une fois, ceci n'avait pas pour but de poser que les tabs, c'est mieux ; simplement d'expliciter en quoi il me semble qu'à peu près chaque point de différence entre les deux usages que l'on pourra développer pourra être prit dans les deux sens, selon la personne qui parle. Pour répondre à la question d'origine, je ne pense pas qu'il y ait de raison « objective » de préférer l'un ou l'autre ; si PEP8 recommande les espaces, je dirais que c'est essentiellement parce que ça a été fait par des gens qui avaient l'habitude des espaces, ni plus, ni moins.
Mais vu que c'est dedans, ouais, 'faut essayer d'appliquer ça (grim, quand on attaquera Arpège, on mettra des espaces, pas de soucis )

(D'ailleurs, à ce sujet, pour les gens qui s'y connaissent en conf' Vim : par défaut, son auto-indentation est assez foireuse, vu qu'elle transforme X espaces en une tabulation automatiquement à la ligne suivante. La seule solution que j'ai trouvé jusque là pour empêcher ça, c'est de mettre « set expandtab », mais ça fait que, du coup, les tabulations ne sont plus possibles du tout (genre, si je suis en train de faire un script shell et que je veux faire un cut sur un truc en fonction des tabulations, il faut que je sorte de l'éditeur pour pouvoir insérer la tabulation là où il faut). Connaîtriez-vous par hasard le moyen de demander à Vim de faire de la bonne auto-indentation propre, c'est-à-dire de recopier précisément celle qu'il y a à la ligne au dessus, sans la modifier ?)

grim7reaper · Le 03/07/2013, à 12:24

TIens, je me doutais bien que tu allais apparaître toi

Bon je ne répondrai pas à ton argumentation, comme tu l’as dit ça n’attends pas de réponse et ça pourrait durer des pages et des pages (et le sujet déjà été traité sur ce topic 2 ou 3 fois au moins) et je n’ai pas trop le temps pour ça ^^'

Elzen a écrit :

(grim, quand on attaquera Arpège, on mettra des espaces, pas de soucis )

En parlant de ça, tu as des nouvelles de Kamui ?

Elzen a écrit :

(genre, si je suis en train de faire un script shell et que je veux faire un cut sur un truc en fonction des tabulations, il faut que je sorte de l'éditeur pour pouvoir insérer la tabulation là où il faut).

Ça ne répond pas vraiment à ta question, mais cut n’accepte pas \t pour représenter une tabulation ?

Elzen · Le 03/07/2013, à 12:28

grim7reaper a écrit :

TIens, je me doutais bien que tu allais apparaître toi

J'ai failli ne pas (En fait, ça faisait un moment que je ne postais plus, mais bon, j'me suis dit que ça avait assez duré, et que c'était une bonne occasion de recommencer ^^)

grim7reaper a écrit :

Bon je ne répondrai pas à ton argumentation, comme tu l’as dit ça n’attends pas de réponse et ça pourrait durer des pages et des pages (et le sujet déjà été traité sur ce topic 2 ou 3 fois au moins) et je n’ai pas trop le temps pour ça ^^'

Juste une question rapide, quand même : es-tu d'accord sur le fait qu'il ne semble pas exister d'argument « objectif », ou pas ?

grim7reaper a écrit :

En parlant de ça, tu as des nouvelles de Kamui ?

Pas depuis un bail

grim7reaper a écrit :

Ça ne répond pas vraiment à ta question, mais cut n’accepte pas \t pour représenter une tabulation ?

seth@fadreils: ~$ echo "gnap" | cut -d"\t" -f1
cut: le délimiteur doit être un seul caractère
Saisissez « cut --help » pour plus d'informations.
seth@fadreils: ~$ echo 'echo "gnap" | cut -d"\t" -f1' > test.sh
seth@fadreils: ~$ sh test.sh 
cut: le délimiteur doit être un seul caractère
Saisissez « cut --help » pour plus d'informations.
seth@fadreils: ~$

Il y a peut-être un truc pour lui demander d'interprêter ça correctement, mais je n'ai pas encore trouvé.

grim7reaper · Le 03/07/2013, à 13:23

Elzen a écrit :

grim7reaper a écrit :
Bon je ne répondrai pas à ton argumentation, comme tu l’as dit ça n’attends pas de réponse et ça pourrait durer des pages et des pages (et le sujet déjà été traité sur ce topic 2 ou 3 fois au moins) et je n’ai pas trop le temps pour ça ^^'
Juste une question rapide, quand même : es-tu d'accord sur le fait qu'il ne semble pas exister d'argument « objectif », ou pas ?

Bah disons qu’il n’y pas d’argument suffisamment fort pour mettre au fin au débat (qui semble aussi vieux, si ce n’est plus, que la guerre Vim/Emacs).
Le problème que je vois au tabulation c’est que tu ne peux pas faire une indentation fine juste avec elles (tu le dis toi-même, quand on veux aligner ou faire un décalage, parfois faut passer par des espaces). Du coup, ça peut induire des mélanges, ce qui peut induire des problèmes (dans les langages qui y sont sensibles tels qu’Haskell et Python).
Sinon, le pur tabulation n’est pas plus mauvais que le pur espace (juste moins souple).

Après, ce n’est pas un argument bien sûr, mais je connais plus de langages qui recommande l’espace que la tabulation. De mémoire, Python (via la PEP8), Haskell, et Fortran (le compilo’ émet un warning).

Elzen a écrit :

grim7reaper a écrit :
Ça ne répond pas vraiment à ta question, mais cut n’accepte pas \t pour représenter une tabulation ?
seth@fadreils: ~$ echo "gnap" | cut -d"\t" -f1
cut: le délimiteur doit être un seul caractère
Saisissez « cut --help » pour plus d'informations.
seth@fadreils: ~$ echo 'echo "gnap" | cut -d"\t" -f1' > test.sh
seth@fadreils: ~$ sh test.sh 
cut: le délimiteur doit être un seul caractère
Saisissez « cut --help » pour plus d'informations.
seth@fadreils: ~$ 
Il y a peut-être un truc pour lui demander d'interprêter ça correctement, mais je n'ai pas encore trouvé.

Bah en fait non, il ne faut rien faire ^^
Par défaut c’est déjà la tabulation :

man 1 cut a écrit :

-d, --delimiter=DELIM
use DELIM instead of TAB for field delimiter

echo "gnap\tgnop" | cut -f2
gnop

Elzen · Le 03/07/2013, à 13:46

Ah, oui, en effet ^^" Tellement l'habitude de mettre un -d que je n'avais même pas pensé à vérifier ce qu'il prenait par défaut ><
Cependant, ça élimine le cas particulier le plus fréquent (merci ), mais pas le problème reste vrai dans le cas général : j'aimerais pouvoir faire en sorte que Vim reproduise les espaces d'indentation de la ligne du dessus, mais sans m'empêcher de mettre des tabulations là où j'aimerais en mettre.

grim7reaper a écrit :

Le problème que je vois au tabulation c’est que tu ne peux pas faire une indentation fine juste avec elles (tu le dis toi-même, quand on veux aligner ou faire un décalage, parfois faut passer par des espaces). Du coup, ça peut induire des mélanges, ce qui peut induire des problèmes (dans les langages qui y sont sensibles tels qu’Haskell et Python).
Sinon, le pur tabulation n’est pas plus mauvais que le pur espace (juste moins souple).

Pour la souplesse, ça dépend de quoi on parle Et oui, ça dépend des besoins (alignements par colonnes → espaces, par définition).

grim7reaper a écrit :

Après, ce n’est pas un argument bien sûr, mais je connais plus de langages qui recommande l’espace que la tabulation. De mémoire, Python (via la PEP8), Haskell, et Fortran (le compilo’ émet un warning).

En fait, j'aurais tendance à dire que ce sont plus des aspects sociaux que pratiques. De ma modeste expérience, les gens qui utilisent des espaces ont tendance à vouloir davantage imposer leur point de vue que ceux qui utilisent des tabulations. D'ailleurs, à plusieurs reprises, j'ai entendu un discours qui ressemblait à « pour faire du vrai code, tu dois utiliser des espaces, point. », sans plus d'arguments. Je ne dis pas que c'est nécessairement le cas en général ; mais si ça l'était, ça expliquerait la différence de recommandation, quelles que soient les qualités des deux pratiques par ailleurs.

D'ailleurs, ça me fait penser à un truc.
Sur la promo dans laquelle je fais cours, apparemment, l'un des premiers réflexes des enseignants est d'apprendre à leurs élèves à configurer leur éditeur pour utiliser des espaces à la place des tabulations. Le résultat, j'ai pu le constater à chaque rendu de code cette année, est qu'il y a très peu de code correctement indenté : le nombre d'espaces utilisé varie d'un bloc à l'autre (on fait du Java, donc ça passe)
J'ai bien envie de suggérer (et de faire moi-même, vu que j'aurai des premières années l'an prochain) qu'on insiste sur l'indentation, mais en leur disant d'utiliser des tabs, juste pour voir si le résultat sera du même niveau ou pas. Tiens, d'ailleurs, je vais envoyer un mail à mes collègues maintenant. Si ça passe, je vous tiendrai au courant

(En fait, la discussion sur « espaces ou tabulations » peut être beaucoup assez intéressante, si on l'aborde d'un point de vue un peu plus vaste que de juste argumenter sa propre pratique, je trouve)

Didier-T · Le 03/07/2013, à 16:21

Bonjour à vous Elzen et grim7reaper,
je débute actuellement sous python, et personnellement pour écrire mes scripts j'utilise "Geany", que j'ai configuré pour faire des indentations avec des tabulations, mais qui les convertis en espaces lors de l'enregistrement.
je trouve les tabulations plus pratique pour indenter, mais ce sont des espaces qui sont le plus couramment employé donc pour le partage de bout de code c'est plus pratique.
Enfin ce n'est que mon point de vue.

Dernière modification par Didier-T (Le 04/07/2013, à 05:46)

Pylades · Le 03/07/2013, à 23:51

Juste en passant, bash permet d’écrire des tabulations.

cut -d $'\t' -f 1 <<< $'plip\tplop' # useless uses of echo are bad

Mais de toutes façons, oui, le comportement pas défaut de cut est de couper sur la tabulations.

Et la tabulation, c’est un caractère de contrôle obscur, hérité de la machine à écrire, dont le comportement est rarement prévisible et qui finit par créer des problèmes ; il devrait être évité absolument.

grim7reaper · Le 04/07/2013, à 04:05

Elzen a écrit :

Ah, oui, en effet ^^" Tellement l'habitude de mettre un -d que je n'avais même pas pensé à vérifier ce qu'il prenait par défaut ><
Cependant, ça élimine le cas particulier le plus fréquent (merci ), mais pas le problème reste vrai dans le cas général : j'aimerais pouvoir faire en sorte que Vim reproduise les espaces d'indentation de la ligne du dessus, mais sans m'empêcher de mettre des tabulations là où j'aimerais en mettre.

Je ne comprends pas ton problème.
Tu veux dire que si tu as une indentation de avec des tab de 4 espaces, mais que sur une lignes tu à mis 4 espaces pour indenter, Vim va le convertir en caractère Tab ?
Ça me semble logique.
Par contre oui, ça risque de pourrir le rendu si la tabulation change de largeur, encore une preuve qu’il ne faut pas mélanger les deux.

Elzen a écrit :

grim7reaper a écrit :
Après, ce n’est pas un argument bien sûr, mais je connais plus de langages qui recommande l’espace que la tabulation. De mémoire, Python (via la PEP8), Haskell, et Fortran (le compilo’ émet un warning).
En fait, j'aurais tendance à dire que ce sont plus des aspects sociaux que pratiques.

Pour Fortran c’est une raison plus pratique que sociale il me semble :

man 1 gfortran a écrit :

tabs are not members of the Fortran Character Set

Mais bon, le Fortran est un langage merveilleux où tu es obligé d’ajouter IMPLICIT NONE dans tout des modules, sous peine d’avoir à endurer une fabuleuse fonctionnalité du Fortran 77 (qui se justifiait sûrement à l’époque des cartes perforées où l’on pouvait gagner de la place en omettant le type je suppose…)

Une variable dont le nom commence par i,j,k,l,m,n est automatiquement de type integer. Une variable commençant par toute autre lettre (de a à h et de o à z) est automatiquement de type real.

Elzen a écrit :

Sur la promo dans laquelle je fais cours, apparemment, l'un des premiers réflexes des enseignants est d'apprendre à leurs élèves à configurer leur éditeur pour utiliser des espaces à la place des tabulations. Le résultat, j'ai pu le constater à chaque rendu de code cette année, est qu'il y a très peu de code correctement indenté : le nombre d'espaces utilisé varie d'un bloc à l'autre (on fait du Java, donc ça passe)

Bah si l’éditeur est bien configuré, je ne vois pas comment ça peut arriver.
Donc, soit : mauvais éditeur, changer éditeur
Soit : mauvais étudiant, changer étudiant…

Didier-T a écrit :

je trouve les tabulations plus pratique pour indenter.

Mais en quoi ?
L’argument de la configuration supplémentaire est invalide car on le fait une bonne fois pour toute, et quand on a un usage intensif d’un outil on le laisse extrêmement rarement dans sa conf’ par défaut (donc cocher une checkbox de plus ou ajouter une ligne supplémentaire dans le fichier de conf’ c’est négligeable).

Πυλάδης a écrit :

Juste en passant, bash permet d’écrire des tabulations.
cut -d $'\t' -f 1 <<< $'plip\tplop' # useless uses of echo are bad

Use of non POSIX feature is bad

Syntax error: redirection unexpected

Dernière modification par grim7reaper (Le 04/07/2013, à 04:21)

Didier-T · Le 04/07/2013, à 06:11

grim7reaper a écrit :

...
Didier-T a écrit :
je trouve les tabulations plus pratique pour indenter.
Mais en quoi ?
L’argument de la configuration supplémentaire est invalide car on le fait une bonne fois pour toute, et quand on a un usage intensif d’un outil on le laisse extrêmement rarement dans sa conf’ par défaut (donc cocher une checkbox de plus ou ajouter une ligne supplémentaire dans le fichier de conf’ c’est négligeable).
...

Justement, c'est le fait que modifier la configuration par défaut d'un éditeur est un acte négligeable, qui rend la cohabitation possible.
Je suis un grand fainéant, du coup entre presser 4 fois espace, ou presser 1 fois tabulation le choix est vite fait.
De plus le chemin arpenté n'a d’intérêt que pour le voyager, pour les autres seuls la destination compte (à la fin il n'y a que des espaces), et comme je le disais, ce n'est que l'avis d'un débutant.

Elzem a écrit :

...
grim7reaper a écrit :
Le rendu du code va être différent selon la conf’ de l’éditeur du gus
…ce qui est justement un avantage. Si tu n'apprécies pas, visuellement parlant, l'indentation de quatre colonnes, par exemple (genre, deux ou huit te semblent beaucoup plus lisibles… c'est un ressenti visuel sur lequel on ne peut pas tous être d'accord), et que le gus dont tu lis le code a indenté avec quatres espaces, bah tu n'as pas d'autre choix que de lire quatre espaces. S'il a indenté avec des tabulations, tu règles la taille de ces tabulations comme ça t'arrange, et le code s'adapte.
...

dans le pire des cas pour celui qui a besoin d'une indentation différente un coup de sed et c'est fini (il n'aura eu mal aux yeux qu'une fois, pour voir l'indentation d’origine)

nesthib · Le 04/07/2013, à 06:30

Quand je code et que je presse [tab], sous vim, j'obtiens 4 espaces
De manière similaire, [retour] efface ces 4 espaces pour revenir au niveau d'indentation précédent.
oui je sais, grillé par Rolinh et grim7reaper

@Elzen : je pensais comme toi et je préférais les tab aux espaces pour des raisons similaires, mais il faut avouer que la plupart tu temps (surtout en python) les codes existants utilisent des espaces. En pratique et pour des questions d'interopérabilité il est plus simple de suivre les règles de codage de ton projet/langage. Pour python c'est 4 espaces, il n'y a donc pas à revenir dessus je pense.

grim7reaper · Le 04/07/2013, à 06:35

Didier-T a écrit :

Justement, c'est le fait que modifier la configuration par défaut d'un éditeur est un acte négligeable, qui rend la cohabitation possible.

C’est négligeable quand c’est à faire une bonne fois pour toute.
S’il faut que je modifie les réglages à chaque code que j’ouvre selon si c’est des tabulations ou des espaces, ça devient casse couille.

Didier-T a écrit :

Je suis un grand fainéant, du coup entre presser 4 fois espace, ou presser 1 fois tabulation le choix est vite fait.

Justement, presser une fois Tab peut insérer X espaces d’un coup (sauf si tu utilises un vieil éditeur de derrière les fagots). Donc l’argument n’est pas valide.

Didier-T a écrit :

De plus le chemin arpenté n'a d’intérêt que pour le voyager, pour les autres seuls la destination compte (à la fin il n'y a que des espaces), et comme je le disais, ce n'est que l'avis d'un débutant.

Oui, je suis d’accord que ta méthode est OK.
Que le remplacement se fasse au fur et à mesure, ou une fois à la fin (comme toi) le résultat final est le même

Didier-T a écrit :

dans le pire des cas pour celui qui a besoin d'une indentation différente un coup de sed et c'est fini (il n'aura eu mal aux yeux qu'une fois, pour voir l'indentation d’origine)

Oui mais non
sed va aussi traiter les commentaires et les chaînes de caractères, ce qui peut avoir des effets imprévus, voire néfastes.
Je ne m’y risquerai pas en tout cas.
Il vaut mieux utiliser des programmes plus « intelligent », genre GNU indent, ou son éditeur (Vim permet de faire ce genre de chose).

@nesthib : oui, voilà c’est de ça que je parle. Indenter avec des espaces n’est pas moins pratique que d’utiliser les tabulations.

nesthib · Le 04/07/2013, à 06:40

@Elzen : et pour insérer des tabulations sous vim : ctrl+v [tab] (il s'agit en fait d'un mécanisme d'échappement du shell).

Shanx · Le 04/07/2013, à 08:38

Python, sockets et problèmes. Si y’en a un qui est motivé, j’ai un truc à lui proposer. Cette histoire commence à m’embêter.

Elzen · Le 04/07/2013, à 10:43

grim7reaper a écrit :

Je ne comprends pas ton problème.
Tu veux dire que si tu as une indentation de avec des tab de 4 espaces, mais que sur une lignes tu à mis 4 espaces pour indenter, Vim va le convertir en caractère Tab ?
Ça me semble logique.
Par contre oui, ça risque de pourrir le rendu si la tabulation change de largeur, encore une preuve qu’il ne faut pas mélanger les deux.

Ce que tu décris me semblerait logique, en effet ; mais ce n'est pas ce que je voulais dire, désolé si je me suis mal exprimé.

Si j'ouvre un fichier dans lequel les lignes sont indentées par des espaces, mais que je ne lance pas la commande « set expandtab », vim m'insérera des tabulations si j'utilise la touche tab pour sur-indenter une ligne déjà écrite ; ça, normal.
Mais le problème est que, dès que j'insère une nouvelle ligne, son auto-indentation va me placer le curseur à la même colonne que le départ de la ligne précédente, sauf que si le nombre d'espaces utilisé à la ligne précédente pour indenter correspond à la largeur d'une ou de plusieurs tabulations, il va remplacer, sur la nouvelle ligne, les espaces qui étaient sur celle du dessus par le nombre correspondant de tabulations. Je me retrouve donc avec toutes les lignes du fichiers indentées par des espaces, sauf celle que je viens d'ajouter, qui a des tabulations.
La réciproque est vraie aussi, d'ailleurs : si j'ouvre un fichier indenté avec des tabulations, et que la commande « set expandtab » est lancée, chaque fois que j'insère une nouvelle ligne, la nouvelle ligne en question se retrouve indentée avec des espaces, alors que toutes les autres du fichier restent indentées avec des tabulations.

Pour moi, là, il y a clairement un grave soucis quelque part ; surtout que tous les autres éditeurs que je connais sont capable de te reproduire l'indentation de la ligne du dessus à l'identique, sans faire de bêtises à ce niveau.

Edit : le truc fait d'ailleurs que je préfère ne pas mettre « set expandtab » dans mon ~/.vimrc, puisque je ne sais pas comment on annule cette commande, donc si jamais je tombe sur un fichier contenant des espaces, ça cassera tout si j'essaye de le modifier. Du coup, j'ouvre d'abord le fichier, je regarde, puis je tape « set expandtab » à la main, ou pas, en fonction de ce qu'il y a dedans. Super pratique ^^

grim7reaper a écrit :

Bah si l’éditeur est bien configuré, je ne vois pas comment ça peut arriver.
Donc, soit : mauvais éditeur, changer éditeur
Soit : mauvais étudiant, changer étudiant…

Je dirais que la faute est aux étudiants. Mais en même temps, ils n'ont que 2h d'informatique par semaine, les pauvres.

En fait, en y re-réfléchissant, je pense qu'il y a deux façons d'interprêter leurs bizarreries d'indentation : soit certains d'entre eux n'utilisent simplement pas la touche tabulation, mais appuient un nombre variable de fois sur la touche espace, soit (du moins, pour les projets) chacun a configuré son éditeur différemment, et c'est dû au travail en équipe.
Pour expliciter un peu, leur code donne généralement un truc comme ça (bon, avec du code un peu plus constructif quand même) :

public class Machin {
  public static void main(String args[]) {
      int x;
      if (true) {
         x = 0;
         System.out.println(x);
      }
      else {
           x = 1;
           System.out.println(x);
      }
  }
}

(Ceci dit, si on pouvait utiliser autre chose que JDev, ça aiderait aussi, je pense >< Enfin, l'année prochaine, j'aurai des première année, on leur fait utiliser Geany, c'est mieux )

nesthib a écrit :

@Elzen : je pensais comme toi et je préférais les tab aux espaces pour des raisons similaires, mais il faut avouer que la plupart tu temps (surtout en python) les codes existants utilisent des espaces. En pratique et pour des questions d'interopérabilité il est plus simple de suivre les règles de codage de ton projet/langage. Pour python c'est 4 espaces, il n'y a donc pas à revenir dessus je pense.

Ah mais ça, j'suis d'accord ; ce qui prime, ce sont les normes imposées et les usages.
Pour Python, j'utilise encore des tabs pour les trucs que je fais dans mon coin et qui n'ont aucune raison d'être diffusés (et qui sont, de toute façon, assez petits pour que je rectifie ça si jamais je dois le diffuser) ; mais dès que je commence un truc à vocation plus ouverte, je mets des espaces, pour respecter PEP8.

…enfin, Touhy a encore des tabs, alors qu'il est gros et rendu public, mais c'est parce que j'ai commencé à coder ça avant de connaître PEP8, et d'ailleurs, c'est loin d'être le seul aspect du coding style qui n'est pas très « pythonesque » (genre, parenthèses systématiques autour des conditions dans les if… je débutais en Python). Et comme c'est prévu pour être réécrit (sans doute dans un autre langage) à plus ou moins moyen terme (j'ai dit que je m'en occuperai quand l'un des successeurs de X sera vraiment utilisé), j'ai la flemme de proprer ça d'ici-là.

nesthib a écrit :

@Elzen : et pour insérer des tabulations sous vim : ctrl+v [tab] (il s'agit en fait d'un mécanisme d'échappement du shell).

Merci pour l'astuce Ça ne résout pas le problème, mais c'est déjà bon à savoir

Edit :

grim7reaper a écrit :

Oui mais non
sed va aussi traiter les commentaires et les chaînes de caractères, ce qui peut avoir des effets imprévus, voire néfastes.
Je ne m’y risquerai pas en tout cas.
Il vaut mieux utiliser des programmes plus « intelligent », genre GNU indent, ou son éditeur (Vim permet de faire ce genre de chose).

Précisons quand même que sed prend des regexp, donc on peut lui préciser « en début de ligne uniquement », il me semble.

Mais je vais regarder GNU indent, tiens, pour voir.

Dernière modification par Elzen (Le 04/07/2013, à 10:49)

Jules Petibidon · Le 04/07/2013, à 11:37

C'est pour éviter ces problèmes d'indentation qu'on s'impose cette norme des espaces au lieu des tabulations. Et que du coup le set expandtab dans le vimrc est logique et l'on considère que si ça pose un problème, c'est que le fichier est mal formé.

Concernant tes étudiants, je dirais qu'il faut leur prendre le chou avec le réglage de l'indentation, et être justement intransigeant.

Et pour les problèmes d'incohérence des modifications, à priori la commande :retab de vim devrait rendre service.

Elzen · Le 04/07/2013, à 12:45

Jules Petibidon a écrit :

C'est pour éviter ces problèmes d'indentation qu'on s'impose cette norme des espaces au lieu des tabulations.

Je vais éviter de répondre

Jules Petibidon a écrit :

Et que du coup le set expandtab dans le vimrc est logique et l'on considère que si ça pose un problème, c'est que le fichier est mal formé.

Ce n'est pas le set expandtab qui est illogique et qui pose problème, c'est la stupidité profonde qu'il y a à « auto-indenter » une ligne sans reproduire exactement l'indentation présente à la ligne supérieure.

Jules Petibidon a écrit :

Concernant tes étudiants, je dirais qu'il faut leur prendre le chou avec le réglage de l'indentation, et être justement intransigeant.

Sans vouloir te vexer, je crains que tu n'aies pas bien compris ce dont je parlais.

Jules Petibidon a écrit :

Et pour les problèmes d'incohérence des modifications, à priori la commande :retab de vim devrait rendre service.

Merci.

The Uploader · Le 04/07/2013, à 13:23

Sortie de Ruby On Rails 4.0

Elzen · Le 04/07/2013, à 17:09

Allez, histoire de conclure sur l'histoire avec mes étudiants, je vous transmet le mail que je viens d'envoyer à mes collègues :

Ce que j'aimerais, c'est qu'on évalue l'intérêt pédagogique d'utiliser l'un ou l'autre. Or, il me semble qu'on est dans les conditions plus ou moins idéales pour ça : deux filières, plusieurs groupes, plusieurs intervenants, même programme par ailleurs, et mêmes points sur lesquels on décide d'insister, en théorie.
Le protocole expérimental que je suggère donc, assez simple : dans l'une des filières (choisir laquelle selon les préférences personnelles des intervenants), on commence par leur apprendre à configurer leur éditeur de texte pour que la touche tab insère quatre espaces, et on pose que l'indentation, c'est quatre espaces, point barre. Dans l'autre, on commence par leur expliquer ce que c'est que ce bizarre caractère tabulation, et on pose que l'indentation, c'est une tabulation, point barre. Dans les deux promos, on insiste autant sur l'importance de bien indenter. À la fin de l'année, voire des deux ans, on regarde lesquels s'en sortent le mieux, et on conclue

J'vous tiendrai au courant ^^

Dernière modification par Elzen (Le 04/07/2013, à 17:10)

nesthib · Le 04/07/2013, à 17:19

Tu crois que les étudiants ne discutent pas entre promos ?

Elzen · Le 04/07/2013, à 17:21

Si ; mais ce sont deux filières d'étudiants d'origine étrangère, et pas le même étranger, donc pas trop ^^

Shanx · Le 04/07/2013, à 17:22

Ah.

Parce que nous, les étudiants (nous ^^) font plus que discuter. Y’a du code qui circule aussi.

Rolinh · Le 04/07/2013, à 19:03

Shanx a écrit :

j’ai du mal à réfléchir (et à codé) en orienté objet. Et je ne sais pas comment faire pour avoir le déclic (c’est d’ailleurs pour ça que j’ai beaucoup de mal avec le java).

J'avoue que je ne vois pas comment provoquer un déclic parce que je trouve ça plutôt naturel.
Si tu as un objet Maison, alors tes attributs sont par exemple les fenêtres, les portes, les pièces, ... Et tes méthodes sont par exemple ouvrirGarage(), augmenterChauffage(), etc.
Du coup, pour ouvrir ton garage, une fois que ta maison est construite (=instanciée, m = new Maison()), tu fais m.ouvrirGarage().
Sans penser objet, tu aurais des objets fenêtres, portes, etc pas rattaché à une maison, une méthode ouvrirGarage(id_de_la_maison) (et si c'est pas l'id d'une maison qui est passé à la méthode?), etc. Bref, une belle pagaille.
Un objet c'est utile quand tu as des éléments qui devraient former une entité cohérente constituée de ceux-ci.

C'était mon essai de vulgarisation à 2 balles... mais ne sait-on jamais, peut-être que ça peut aider à débloquer un peu...

Shanx a écrit :

Sinon, je ne vois toujours pas les avantages de l’ORM.

Il y en a tout plein et je ne vais pas me risquer à tous les énumérer. Néanmoins, en voici quelques-uns:
- couche d'abstraction: tu ne fais jamais du sql explicitement dans ton code. Si un jour tu veux utiliser une autre base que sqlite pour une raison ou une autre, pas besoin de changer ton code, juste le driver de la db. Ça te prendrait 2 minutes vs... ça dépend de la taille du code mais bieeeeeen plus que 2 minutes.
- tu te concentres sur la logique métier de ton application et pas sur comment tu vas stocker tes données
- moins de code => gain en temps de développement, réduction (probable) du nombre de bugs, etc.
- si tu changes ton modèle, les changements ne sont à apporter qu'à un endroit (pas besoin de corriger toutes tes requêtes SQL...)
- support de la concurrence (plusieurs utilisateurs veulent mettre à jour les données en même temps...)
- gestion d'un cache (bon pour les performances des grosses appli même si dans ton cas c'est peut-être pas un avantage déterminant ^^)
- ...

On peut sûrement trouver encore plein d'autres raisons mais bon, ça en fait déjà quelques unes intéressantes.

Shanx · Le 04/07/2013, à 19:12

Merci bien Rolinh. Ta tentative de vulgarisation n’a pas été bien vaine, et ton exemple avec ouvrirGarage(id_maison) m’a un peu éclairé sur les avantages de l’objet.

Concernant l’ORM, je n’ai pas eu le temps de m’y plonger. Cependant, comme je vais me mettre à Flask pour faire un petit site présentant les données stockés dans la bdd, je risque de m’y mettre sous peu.

The Uploader · Le 04/07/2013, à 21:16

Faut bien se dire, même si on va te bourrer le crâne avec, que la POO y'a pas que ça dans la vie (ça ne résout pas tous les problèmes d'architecture logiciel, encore moins si on n'applique pas les principes SOLID).
Il existe d'autres paradigmes de programmation (aspect, fonctionnel, ...) qui répondent à d'autres problèmes.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1501 Le 03/07/2013, à 02:36

Re : /* Topic des codeurs [8] */

#1502 Le 03/07/2013, à 11:08

Re : /* Topic des codeurs [8] */

#1503 Le 03/07/2013, à 12:24

Re : /* Topic des codeurs [8] */

#1504 Le 03/07/2013, à 12:28

Re : /* Topic des codeurs [8] */

#1505 Le 03/07/2013, à 13:23

Re : /* Topic des codeurs [8] */

#1506 Le 03/07/2013, à 13:46

Re : /* Topic des codeurs [8] */

#1507 Le 03/07/2013, à 16:21

Re : /* Topic des codeurs [8] */

#1508 Le 03/07/2013, à 23:51

Re : /* Topic des codeurs [8] */

#1509 Le 04/07/2013, à 04:05

Re : /* Topic des codeurs [8] */

#1510 Le 04/07/2013, à 06:11

Re : /* Topic des codeurs [8] */

#1511 Le 04/07/2013, à 06:30

Re : /* Topic des codeurs [8] */

#1512 Le 04/07/2013, à 06:35

Re : /* Topic des codeurs [8] */

#1513 Le 04/07/2013, à 06:40

Re : /* Topic des codeurs [8] */

#1514 Le 04/07/2013, à 08:38

Re : /* Topic des codeurs [8] */

#1515 Le 04/07/2013, à 10:43

Re : /* Topic des codeurs [8] */

#1516 Le 04/07/2013, à 11:37

Re : /* Topic des codeurs [8] */

#1517 Le 04/07/2013, à 12:45

Re : /* Topic des codeurs [8] */

#1518 Le 04/07/2013, à 13:23

Re : /* Topic des codeurs [8] */

#1519 Le 04/07/2013, à 17:09

Re : /* Topic des codeurs [8] */

#1520 Le 04/07/2013, à 17:19

Re : /* Topic des codeurs [8] */

#1521 Le 04/07/2013, à 17:21

Re : /* Topic des codeurs [8] */

#1522 Le 04/07/2013, à 17:22

Re : /* Topic des codeurs [8] */

#1523 Le 04/07/2013, à 19:03

Re : /* Topic des codeurs [8] */

#1524 Le 04/07/2013, à 19:12

Re : /* Topic des codeurs [8] */

#1525 Le 04/07/2013, à 21:16

Re : /* Topic des codeurs [8] */

Pied de page des forums