Voilà pourquoi c'est super important de:

• faire des commits atomiques (un seul sujet par commit et toutes les modifications liées à ce sujet dans le même commit)
• bien remplir ses messages de commit.

Un super article présentant les bonnes pratiques de l'écriture de libairies en Rust. Je me demande jusqu'à quel point ce genre de recommandation peut être vérifiée statiquement avec Clippy.

Excellent !

Il y avait un site appelé motherfuckingwebsite.com, qui expliquait pourquoi le JavaScript et le CSS pour les sites web étaient des nuisances, et pourquoi il valait mieux faire du HTML simple et laisser le navigateur afficher la page comme il veut. Même si le postulat de départ n'est pas complètement faux, les styles par défaut sont vraiment horribles, et vraiment pas faciles à lire.

bettermotherfuckingwebsite.com pour sa part, explique comment faire un site minimaliste (seulement 7 règles CSS) tout en étant bien plus agréable et lisible. Et il y arrive vraiment bien !

Le CSS en question :

body{
margin:40px auto;
max-width:650px;
line-height:1.6;
font-size:18px;
color:#444;
padding:0 10px;
}

h1,h2,h3{
line-height:1.2;
}

Le seul truc un peu foireux la dedans, c'est line-height:1.6 en em (implicite, ce qui n'est pas top non plus) alors que la font-size est en pixel …

Les mecs font une version mineure (1.5.0) qui casse la rétro-compatibilité avec les version d'avant ! C'est débile, c'est pas comme ça qu'on fait du semver !

«Quand tu fais du TDD, tu es le premier à consommer les API que tu mets en œuvre, du coup généralement tu fais des efforts niveau design»

Je suis surpris de n'avoir jamais bookmarké ça. C’est maintenant chose faite.

Un changelog est INDISPENSABLE dans n'importe quel projet logiciel à partir du moment où vous sortez la 1ère release !

Le fait d'utiliser un changelog, tout comme le versionnement sémantique (SemVer dont j'avais déjà parlé ici http://stymaar.fr/links/?xUMHSQ), fait partie de ces pratiques indispensables pour maintenir un projet.

rq : si vous utilisez un workflow genre git-flow, avec une branche master correspondant à la version actuelle et une branche dev pour la prochaine version, je vous conseil fortement d'ajouter une section ##[Dev] au dessus de ## [Unreleased], pour ne pas vous emmêler les pinceaux entre vos hotfix et vos feature et vous faire avoir par les merges automatiques de git.

C'est long, et le milieu n'est pas forcément très intéressant. Par contre les 15 premières minutes valent vraiment le coup.

Particulièrement cette phrase : «TDD is not about testing, it's about design»

«4 God Class
5 Fear of Adding Classes
[…]
9 Useless (Poltergeist) Classes»

Oh comme je les connais bien ces 3 là !

Une liste de bonnes pratiques, adaptée à ES6.

Je ne suis juste pas d'accord avec ça :

• Strings longer than 80 characters should be written across multiple lines using string concatenation. Les template String ça permet de faire des strings multi-lignes ! Allô !

• Always use parentheses around the arguments. Omitting the parentheses makes the functions less readable and only works for single arguments. ça me laisse perplexe, Ok c'est bien d'être cohérent entre aucun/un/plusieurs arguments, mais [1, 2, 3].map((x) => x * x); c'est quand même plus moche que [1, 2, 3].map(x => x * x);

• Don't use iterators ça c'est quand même un peu extrême.

• Use soft tabs set to 2 spaces. Je m'en fou je le ferait pas ! Déjà les espaces c'est idiot, alors en plus 2 espaces merci quoi ! J'ai envie d'indenter mon code lisiblement ! (d'où l’intérêt des tabs d'ailleurs, chacun configure son éditeur comme il veut pour avoir le rendu qui lui va). Rq : J'ai bien dit d'utiliser des tabs pour indenter, pas pour aligner des trucs ! Là il faut des espaces (pour la même raison que précédemment, les tabs sont de largeur variable donc pour aligner c’est pas ouf ^^)

• Additional trailing comma: Nope. Si ! Ça clarifie les diff git ! Et puis franchement IE7 en quirksmode en 2015 on s'en BRANLE !

• Don't save references to this. Use arrow functions or Function#bind. quand on peut utiliser des arrow fonction oui, mais sinon bind est bien pire qu'un petit var self = this !

Par contre j'aime bien ça :

• Methods can return this to help with method chaining : pour toutes les méthodes qui pourraient (ou devraient) retourner undefined

• Use array spreads ... to copy arrays. : const itemsCopy = [...items]; malin !