Yth a écrit 2615 commentaires

Tu veux dire, par exemple en HTML, utiliser STRONG à la place de B, et EM à la place de I ?

Yth.

On est d'accord sur l'ordre de grandeur, je n'ai pas de valeur précise, ma règle c'est juste : si j'ai du mal à « voir » la fonction d'un seul coup d'oeil, c'est qu'elle est trop longue et qu'il faudrait que je cherche à la découper, ou à la réécrire mieux.
« Gagner » une ligne pour chaque accolade ouvrante rend la fonction plus compacte tout en étant à mon sens plus lisible : je vois mieux les blocs logique comme ça, une ligne vide ça a plein de sens, l'indentation en a aussi.
On est vraiment dans le visuel là, ce que mon oeil perçoit rapidement, d'un seul coup, avec le minimum d'analyse de la part du cerveau.
Et j'ai horreur de l'accolade à la ligne parce qu'elle me gène, et je sépare mes fonctions d'au minimum deux lignes sauf si elles sont très étroitement liées.

Donc ces lignes ce n'est pas du grattage pour faire tomber la taille sous une limite dure, c'est vraiment parce que je trouve ça illisible avec l'accolade à la ligne. Ca casse la logique de l'indentation, c'est laid, et j'aime pas ça :)

Yth.

Tu pourrais expliquer rapidement avec genre un exemple marquant ?

Yth.

Oh, c'est vendredi, juste un lâché de troll supplémentaire.
J'ai personnellement horreur de cette façon d'écrire, je trouve que c'est nettement moins lisible que de laisser l'accolade à sa place à la fin de la ligne à laquelle elle appartient.

De plus, j'ai comme philosophie qu'une fonction bien écrite est courte, et se « voit » d'un seul regard. Une fonction ne devrait jamais faire plus d'un écran de long en nombre de lignes, et la moitié c'est déjà pas mal. Sachant que j'utilise en gros un terminal allongé à la hauteur de l'écran, un peu moins de 70 lignes, donc 35 lignes pour une fonction ressemble à une bonne limite floue.
Une fonction trop longue devient illisible, s'il faut faire défiler en haut ou en bas pur la lire en entier c'est insupportable, et plus elle est courte, moins les yeux doivent faire d'aller-retours, plus elle est lisible.
Tout en gardant une opération par ligne bien sûr.

Donc la ligne bêtement perdue par cette accolade qui en prend une pour elle toute seule, gène en soi la lisibilité en accroissant le nombre de ligne.
De plus, l'oeil voit bien les blocs de texte, pour repérer une fonction dans son code, on fait défiler et on regarde la forme du texte, aidé par la coloration syntaxique. Si la fonction est entrecoupée de sauts de ligne incongrus, et de lignes perdues de partout, la fonction semble découpée en tronçons et on a du mal à savoir où elle commence et où elle arrête.
Attention, je ne dis pas qu'il ne faut pas sauter de lignes parfois dans du code, à certains endroits ça sépare des blocs logique et aide à la lisibilité du code, mais il ne faut pas le faire n'importe où.
C'est comme écrire un texte, un livre, tu utilises des paragraphes pour aérer, mais pas des tas de paragraphes d'une seule phrase non plus, le texte est regroupé en groupes de phrases logiques.

Bref, l'accolade à la ligne c'est, à mon sens, une perte de lisibilité.
Après c'est ma vie, mes couleurs, mon appréciation de la chose, mes gouts, mais c'est au moins un peu réfléchi comme avis, donc pas juste un lâché de troll dans le vent du matin :)

Yth.

J'approuve le commentaire de msieur_happy, la coloration syntaxique est encore ce qu'il y a de mieux, de plus simple et répandu, pour ce différencier variables, valeurs, fonctions, mots-clefs, erreurs de syntaxe, etc.

Franchement, pour coder en PHP tout les jours pas vraiment par choix, ces $ devant chaque nom de variable me fatiguent. C'est exactement comme le ; en fin de ligne : totalement inutile, ça plante directement dès qu'ils n'y sont pas, la correction de l'erreur est toujours syntaxiquement évidente.
Le seul et unique intérêt du $ devant les noms de variable est en bash comme en PHP de les glisser directement dans les chaînes de caractères : echo "Bonjour $nom !" , ça c'est pratique.
Ben... C'est tout ce que j'ai trouvé...

Après, avoir de bonnes conventions de codage pour voir clairement les variables, leur type prévu ou leur utilisation, ou même leur champs d'action, c'est valable quel que soit le langage.
Mais je n'ai aucune difficulté à lire, même sans coloration syntaxique, un truc du genre :
for x in ma_liste:
print x
Ce n'est pas moins clair, au contraire, que :
foreach($ma_liste as $x) {
echo $x;
}

Yth.

Je vais choisir un langage disons...
- interprété, parce que pour le compilé j'ai le C qui me convient bien ;
- rapide ;
- peu verbeux ;
- a la syntaxe claire (au revoir bash, perl...) ;
- plutôt sans contraintes de typage, parce que si j'ai besoin de faire un truc super précis, ben j'ai encore le C, là ça serait plutôt pour moins me prendre le choux ;
- un bon paquet de bibliothèques variées et aisément disponibles ;
- ah tiens, s'il pouvait y avoir une killer-feature comme un interpréteur en ligne de commande, un shell du langage en somme, ça tuerait tout, pouvoir tester rapidement un fonctionnement, une fonction, sans écrire tout un programme, juste écrire le bout de code qui t'intéresse et voir ce qu'il donne, super pratique ça, ça manque a des langages comme le PHP ou même le javascript (pourtant ça serait faisable en js)... ;
- intéropérable évidemment (au revoir java (on est vendredi !), et visualbasic, la larme à l'oeil (mwarfff...)) ;
- qui permette aisément de faire un programme, un site web, un script, tout ça dans un même langage, histoire de ne pas en apprendre douze différents, je connais déjà le C en plus, deux langages plus le HTML/CSS/JS, ça suffit amplement ;
- qui soit adapté au calcul scientifique (bc c'est sympa mais un peu limité quand même) ;
- et qui fait ce qu'on attend de lui sans même avoir besoin de t'imposer de mettre $ devant tes noms de variables ;
- qui permette d'éviter de voir l'ignoblissime syntaxe venue de certains inutilisateurs du C qui consiste à mettre l'accolade ouvrante à la ligne, pouaaark !

Bref, ça fait pas mal de contraintes, j'en ai heureusement un sous la main.

Python.


Yth.

Oh pardon !
Arf, le coup classique, on fait une remarque et on met une énormité au milieu...
J'ai vraiment besoin de sommeil ^^

Yth...

« Mais le monsieur ne le SAURA jamais. »

Ca faisait longtemps, je m'excuse de le faire encore une fois, mais je le fais sur des fautes grosses et récurrentes, pas sur des fautes de frappe.

Le monsieur là, il ne saura jamais, pas il ne sera jamais s'il a reçu son mail.
Saura : c'est le verbe savoir : il ne va pas *savoir* s'il a reçu son mail.
Sera : ça c'est le verbe être ! : il va être d'avoir reçu son mail ? Mux ?

Je l'ai vu passer un certain nombre de fois ces derniers jours, pas forcément par la même personne, c'est une faute trop courante, alors j'explique :)

Maître Ythello.


PS : Je ne parle plus des participe passé écrit en « -er » et des infinitif écrit en « -é », ça me déprime trop, mais remplacez vos verbes par un verbe du troisième groupe, « finir » par exemple, prononcez, on entend mieux la différence entre fini et finir qu'entre payé et payer...

C'est aussi un des intérêts du C de ne pas mettre ce genre de limites.
Le C a un statut très particulier parmi les langages : tu es seul maitre à bord, tes conneries sont les tiennes, mais tes bidouilles aussi.
Ce n'est pas forcément le pied quand on veut un projet complexe, avec de multiples contributeurs de niveaux inégaux, et qu'on n'a pas le temps ou l'énergie de gérer le projet aussi bien que par exemple un kernel Linux, mais cette liberté est irremplaçable quand on en a besoin.

Personnellement, j'adore cette sensation de liberté quand je code en C :)
Et j'adore cette sensation de simplicité quand je code en Python.
Mais ce n'est pas pour les même choses...

Yth.

Tu peux réussir à le faire à la fois en whitespace ET en Rails ?
Les espaces donnent le sens en whitespace, et le reste en Rails !

Yth.

Je sais qu'on est vendredi, troll tout ça, mais franchement, régulièrement je cherche, mais je reviens *toujours* à xmms pour écouter ma musique.
J'en ai testé plein, de mpd à amarok en passant par audacious ou aqualung.
Je n'aime pas les trucs à la amarok, qui « gère tes musique », c'est chiant de juste écouter le contenu d'un fichier juste là, devant toi, sur ta fenêtre ROX-Filer. Ca c'est une question de goût.
Un truc simple qui te fait juste playlist correctement, ben j'en ai pas trouvé de mieux que XMMS.

Je veux bien qu'on m'en propose, j'essaie de quitter XMMS, c'est juste que je n'y arrive pas... Et ça me déprime un peu :(

Yth.

Il est pas moche l'installateur, il est en mode console, texte.
Mais il y a des couleurs, des choix, des textes explicatifs, il permet de modifier ses choix si on s'est trompé, se charge de toute la configuration de base sans problème, et fait ça bien sans s'emmêler les pinceaux ni faire de conneries.

C'est un choix assez aisé à faire finalement, parce que la seule chose que d'autres installateurs ont et que lui n'a pas, c'est un environnement graphique avec une souris.
Franchement... Ya pas de quoi en faire un plat hein !

Yth.

Tu ne sais pas tout !
Il y a de vieux hiéroglyphes de l'époque de Sékhemkhet dans l'ancien empire d'Egypte, qui relatent l'utilisation du manchot à la pipe. C'est très clair sur les hiéroglyphes, ils ne se sont pas foulés, ils ont directement repris le logo de la Slack, en un peu stylisé, pour la nommer.
Ce qui nous amène à plus de 4500 ans déjà.

Un peu plus tard on le retrouve sur des vases de la dynastie Shang, en Chine, il y a donc entre 3000 et 3500 ans.

Certains historiens en parlent même dans le peu que l'on sait des invasions Kourganes, il y a entre 7000 et 5000 ans, et qui sont à l'origine de la civilisation Hittite. Des traces auraient été trouvées à Çatal Hüyük (ville fondée il y a 9000 ans), en Anatolie (Turquie), et viennent donc étayer cette thèse cependant controversée.

Bref, la Slackware, c'est un peu la mémoire de l'humanité toute entière.


Yth, oh fichtre, on est vendredi, et je suis fatigué !

Mais voyons, la Slackware est tellement importante que le thème Slackware EST le thème par défaut de linuxfr voyons !
Linuxfr est en permanence en thème Slackware, sauf quand on change pour d'autres thèmes de temps en temps.

Slackware est fêtée tout les jours sur Linuxfr, c'est la moindre des choses.

Yth, mais bien sûr...

Oh... Merde !

Yth ^^

Oui, mais c'est une décision quasiment politique de la part du policier. Parce que manifester c'est un droit, ce n'est pas interdit.
Tu as le droit d'être où tu es, d'être sur le chemin d'un flic qui marche dans la rue, d'être devant lui au tourniquet du métro.

S'il te demande de bouger et que tu refuses, sans l'agresser non plus, il n'a pas comme seul recours de te rentrer dedans. C'est un choix de sa part de faire dégénérer la situation. Et ce n'est pas forcément un choix légitime...

C'est aussi un choix de ta part de la faire dégénérer, si tu refuses obstinément, y compris de le suivre au poste quand il te l'a demandé,et que tu te débats pour ne pas te laisser pousser vers la voiture, on est d'accord. Mais d'un côté comme de l'autre, *choisir* de faire dégénérer vers la violence n'est *pas a priori* un choix légitime. Tout dépend bien sûr de la situation. Mais crois-moi, heureusement que tout les flics ne répondent pas à la violence (même verbale), par la violence, ou en « rentrant dedans », parce que sinon, les émeutes grecques, on les aurait aussi en France...

Yth.

Malheureusement, si la connerie tuait, ça se saurait, et la terre serait nettement moins peuplée, ce n'est pas le cas...

Yth.

« Est-ce à dire qu'il faut tout excuser parce que ce sont des adolescents ? »

Non, mais je ne crois pas que les flinguer soit la solution non plus...
Il me semble que des solutions il y en a, aussi imparfaites soient-elles, pour gérer les adolescents qui foutent un peu trop le boxon...

Je crois qu'il est inutile de chercher des excuses : tuer quelqu'un n'est *jamais* la bonne solution. Jamais.


Yth.

Ca dépend ce qu'on appelle « rentrer dedans», mais je doute qu'un quelconque policier ait le droit de porter la main sur toi si tu n'as aucune action agressive, dangereuse ou violente, pas forcément à son encontre d'ailleurs, juste parce que tu es là, et qu'il préférerait que tu sois ailleurs.

Ils peuvent te verbaliser, te coller des amendes, voire t'embarquer au poste et t'y garder la nuit (et là si tu résistes, il peut te forcer), mais te « rentrer dedans », au sens où je peux le comprendre, j'en doute très très fort...

Yth.

« Un flic a le droit d'en avoir marre d'être pris pour cible pour n'importe quel type de jet. »

En service il a surtout le *devoir* de NE PAS en avoir marre et de conserver son calme...
Dès qu'il quitte son uniforme et redevient un simple citoyen il peut gueuler comme tout le monde, manifester, etc. En service, non.

Si c'était un accident, et bien c'était un accident. Si le flic a consciemment, même dicté par un gros ras-le-bol, tiré pour tuer, c'est un meurtrier, et pas le gamin qui a pu essayer de le tuer avant. Le meurtrier est celui qui tue, par définition, ce qui n'enlève rien aux actions effectuées par sa victime...

Yth.

Ben non voyons, en type responsable et conscient de ce qu'il fait, tu attends que les mauvais administrateurs fassent la mise à jour et se plantent, ou pas, avant de la faire toi même. C'est d'ailleurs ce qui fait que toi, contrairement à eux, tu es un bon administrateur.

Yth, groovy...

J'ai une logitech Mx310 (c'est écrit dessus !), optique, et j'ai une précision au pixel sans soucis. Elle n'a probablement pas dû coûter plus de10€, mais pas beaucoup moins non plus.
Et j'utilise une doc avec la couverture un peu cartonnée comme tapis de souris, couleurs assez unies, mais rien de luxueux.
Et pas besoin de la nettoyer, contrairement aux vieilles souris à balle !

Pour le coup je suis entièrement satisfait de la qualité de ma souris, pour pas cher :)

Par contre je veux bien croire qu'une souris premier prix soit bien daubée...

Yth.

Sérieux, faut vraiment que tu m'expliques, avec un exemple et tout, parce que je ne vois pas le problème en fait...
Les noms de fichier sont majoritairement ascii, donc quel que soit l'encodage, UTF-8, iso-8859-1, ou que sais-je, ils sont codés de la même manière, et fonctionnent pareil.

Décider que tout sera en UTF-8 ressemble quand même à une bonne idée pour éviter des tas d'emmerdes : les divers encodages de caractères sont depuis toujours une inépuisable source d'emmerdes et de complexités.

Donc quel peut bien être le problème des noms de fichiers UTF-8 utilisés avec Mercurial ?

Yth, vraiment perplexe.

Pourquoi ça ?

Yth...

« de l'information aussi [...] peu visible »
Je ne suis pas d'accord, l'indentation c'est au contraire tout ce qu'on voit, directement et rapidement.

Va trouver l'accolade ouvrante correspondant à l'accolade fermante que tu regardes sans un éditeur qui te la montre quand tu es dessus ?
Si tu n'indentes pas correctement ton code, tu es parfois obligé de recompter tes accolades, et dans le genre chiant, c'est pas mal...

Par contre, si tu n'es pas prévenu à l'avance, et que tu ne fais pas attention, c'est sûr, tu vas te planter avec la mode python. Mais c'est uniquement parce que c'est inhabituel, différent des autres.

Yth, toujours aussi fan de l'indentation python :)