dites, vous avez un moyen de de différencier les "fichiers actifs" dans les IDE jetbrains ?
 
genre j'ai des fichiers que j'édite et une tonne d'autre fichiers où je fais que lire le code. Souvent on retrouve les fichiers édités parce qu'ils sont en vert, mais là j'ai committé pour essayer d'apaiser la foule qui veut des petits commits et la baisse de la TVA sur les tiki torches. Du coups mes fichiers "du moment" sont redevenus blancs.
 
Je sais pas trop si y'a un mécanisme pour retrouver rapidement ses fichiers "en cours".

comment on fait ?

moi je coupe mon IDE en 2 ou 3 groupes de tabs, j'imagine que tu pourrais rtier comme ça, mais ça reste très manuel  

Autant j'ai bénéficié d'une aide financière en béton pour mes études (ils ont payé les deux premières années de mon école, soit environ 12k€ + le loyer et la bouffe quand je logeais là-bas, j'ai plus les chiffres mais c'était conséquent), autant ils n'ont plus la capacité financière pour m'aider niveau logement, il faut qu'ils pensent à eux et à leur retraite maintenant. Bon d'un autre côté c'est pas grave. Je suis arrivé trop tard avec des moyens financiers sur le marché immo pour espérer acheter quoi que ce soit là où je veux vivre, donc j'épargne comme un goret à la place et je verrai plus tard.

mon ide ressemble à ça en général : https://i.imgur.com/VzvK5u2.png
3 colonnes pour le code, 2 terminaux . Quand j'en suis a spliter les colonnes en 2 (verticalement,) c'est qje suis dans un moment de génie ou de galère
 
Je suis a peu prêt sur qu'il y a cette fonctionnalité dans jetbrain

 
Parents interdits bancaire ici, donc pas de prêt ni d'aide, j'ai bossé à 20 piges un dut en poche, je pouvais pas aller en école d'ingé.  
Avec le recul je sais même pas si un prêt étudiant était possible, de toute façon mes parents étaient perturbés, j'étais perturbé, et je n'avais en ligne de mire que de gagner des ronds et vite pour être autonome.
 
Au début y a des fins de mois où j'ai un peu jeûné, parce qu'en plus j'étais un branque pour gérer mes sous et pour demander à être payé décemment.

https://twitter.com/olesovhcom/stat [...] 8108375040 < ovh qui parle de l'appel d'offre pour le cloud données de santé  

et aujourd'hui tu changes de maisons tous les 2 ans

 
Avec teamviewer tu as des options pour ne pas afficher le fond d'écran et pour optimiser la vitesse. Le streaming induit par teamviewer est vraiment faible si tu choisis les bonnes options. C'est étonnant que la connexion ADSL, meme pourrie, de tes parents ne suffise pas.

et aujourd'hui tu changes de maisons tous les 2 ans

J'avais lu un truc qui disait qu'il fallait au moins 5 ans avant de revendre sinon on perdait forcément de l'argent dessus parce qu'on ne paie que l'équivalent des intérêts pendant cette période

Dites y'a un modo dans ce topic ?

Dites y'a un modo dans ce topic ?

Faux, mais le résultat est proche dans la pratique.
 
Tu payes plus d'intérêts au départ...parce-que le capital restant à rembourser est plus important. Plus le temps passe, moins il te reste de capital à rembourser, et plus la part de capital remboursé dans le montant fixe que tu payes est importante.

Les RE devraient être interdites sans commentaire explicitant exactement ce qu'elles signifient, avec des mots.

 
 
 
 
C'est complètement con ces remarques. Un développeur expérimenté vous fait comprendre que c'est imbitable, et vous tout ce que vous trouvez à répondre c'est que vous les trouvez simples. À se demander si on fait le même métier.

Ma politique c'est que toutes les regex (à l'exception des plus triviales) doivent être converties en anglais lisible et avoir des tests unitaires. Je pense que j'accepterais pas le genre de truc que Nicolas a cité dans du code dont je suis responsable.

une regexp comme ça me pose problème, en tout cas je ne la lis pas aussi trivialement qu'un opérateur ternaire ou des suite de map/join/reduce

J'ai quand-même l'impression que vous avez un autre soucis s'il faut commenter la moindre regexp non (ou alors faut bien se mettre d'accord sur ce que vous appelez 'triviales').

Ça fait partie des outils de base d'un programmeur ou d'un sysadmin linux je trouve (et ça fait partie d'à peu près tous les cursus en info non ?)... si on commence à commenter des trucs du genre s/\(Use[A-Z][^ (]*[ (]\)/\1(/g' pour moi c'est un peu comme commenter un ternary operator ou une récursion en faisant la supposition que certains ne seront pas à l'aise avec ces concepts, ya plus un gros défaut de formation là

Dans mon équipe un programmeur C ou Java ne sait pas lire un truc du genre functools.reduce(lambda u, wb: np.maximum(0, u.dot(wb[0])+wb[1]), zip(ws, bs), x) à mon avis.

Non, les regexp ne font pas partie des outils de base d'un programmeur. Un mec qui fait 100% d'info de gestion a à peu près jamais touché une regexp de sa vie et celle que tu postes là est un charabia illisible, pour lui.
Je ne me rappelle pas avoir touché à une regexp dans mon cursus.

Ou alors, j'utilise des toutes faites.

Idem, je trouve ça d'un chiant à lire. Je les fuis comme la peste. Et quand j'ai besoin d'une, je suis obligé d'utiliser des sites pour en construire une et bien la tester.
 
Ou alors, j'utilise des toutes faites.

J'ai quand-même l'impression que vous avez un autre soucis s'il faut commenter la moindre regexp non (ou alors faut bien se mettre d'accord sur ce que vous appelez 'triviales').

Ça fait partie des outils de base d'un programmeur ou d'un sysadmin linux je trouve (et ça fait partie d'à peu près tous les cursus en info non ?)... si on commence à commenter des trucs du genre s/\(Use[A-Z][^ (]*[ (]\)/\1(/g' pour moi c'est un peu comme commenter un ternary operator ou une récursion en faisant la supposition que certains ne seront pas à l'aise avec ces concepts, ya plus un gros défaut de formation là

Les cours d'automates et langages avec regexp, théorème de kleene, les grammaires etc c'est dès la license en info  

Les trucs comme ça (les regexp commentées donc) sont littéralement à la fin du premier cours

Un sysadmin si tu veux, un programmeur non. Une regex par design c'est illisible, c'est fait pour être concis et puissant. C'est bien pour faire tourner un script sed à l'arrache. Dans une base de code, non. On a passé 70 ans à améliorer nos langages pour qu'ils soient de plus en plus expressifs, c'est pas pour se retrouver avec ce genre d'horreur dans du code qui est sensé être lu par nos pairs. Et une fois de plus, à mon très humble avis l'argument mais moi je la lis très ben c'est toi qu'est trop con, c'est de la merde, c'est le contraire de ce qu'on cherche à faire quand on écrit du code. Si un collègue pas complétement con te dit qu'il ne comprend pas ton code, tu le réécris de façon plus lisible tu lui demandes pas d'apprendre le langage que tu utilises. Si le code c'est une regex, c'est pas possible.

 
J'ai quand-même l'impression que vous avez un autre soucis s'il faut commenter la moindre regexp non (ou alors faut bien se mettre d'accord sur ce que vous appelez 'triviales').
 
Ça fait partie des outils de base d'un programmeur ou d'un sysadmin linux je trouve (et ça fait partie d'à peu près tous les cursus en info non ?)... si on commence à commenter des trucs du genre s/\(Use[A-Z][^ (]*[ (]\)/\1(/g' pour moi c'est un peu comme commenter un ternary operator ou une récursion en faisant la supposition que certains ne seront pas à l'aise avec ces concepts, ya plus un gros défaut de formation là

Idem, je trouve ça d'un chiant à lire. Je les fuis comme la peste. Et quand j'ai besoin d'une, je suis obligé d'utiliser des sites pour en construire une et bien la tester.

Ou alors, j'utilise des toutes faites.

Un sysadmin si tu veux, un programmeur non. Une regex par design c'est illisible, c'est fait pour être concis et puissant. C'est bien pour faire tourner un script sed à l'arrache. Dans une base de code, non. On a passé 70 ans à améliorer nos langages pour qu'ils soient de plus en plus expressifs, c'est pas pour se retrouver avec ce genre d'horreur dans du code qui est sensé être lu par nos pairs. Et une fois de plus, à mon très humble avis l'argument mais moi je la lis très ben c'est toi qu'est trop con, c'est de la merde, c'est le contraire de ce qu'on cherche à faire quand on écrit du code. Si un collègue pas complétement con te dit qu'il ne comprend pas ton code, tu le réécris de façon plus lisible tu lui demandes pas d'apprendre le langage que tu utilises. Si le code c'est une regex, c'est pas possible.

On a passé 70 ans à améliorer nos langages pour qu'ils soient de plus en plus expressifs

 
Je m'inscris en faux désolé, les regexp ont la qualité de pouvoir être décrites par des patterns souvent bien plus simples que les autres moyens.

nray a mentionné les parser combinators, c'est vraiment mille fois mieux dans pas mal de cas, typiquement vérifier ou déconstruire des URLs.

Je m'inscris en faux désolé, les regexp ont la qualité de pouvoir être décrites par des patterns souvent bien plus simples que les autres moyens.

La regexp ^[ \t]+|[ \t]+$ détecte les espaces ou tab inutiles en début de ligne ou en fin de ligne, pour peu que tu connaisses la base en effet (^ pour début, $ pour fin, | pour OR...), elle est à la fois plus lisible, plus fiable et moins error-prone qu'un bout de code maison qui viserait à détecter la même chose (et qui aurait sans doute besoin d'une batterie de test pour garantir que ça fait bien ce que c'est censé faire, surtout si on rajoute de l'unicode ou autre). La regexp t'évite d'écrire ton parsing à la main en fait.

Outre la lisibilité de la regex, quand tu tombes dessus, il y a la compréhension de l'intention du dev qui l'a écrite qui compte.

Et dès qu'il y a doute possible sur une intention (truc non trivial ou contre intuitif) il faut pallier à ce que ne dit pas le code par des commentaires.
Une regex par essence, c'est pas trivial. Si ça l'est c'est que c'est remplaçable par un if-else et c'est préférable car mieux testable.

Ergo, une regex doit être accompagnée d'un commentaire avec au min. ce qui est attendu en entrée et le résultat escompté.

 
Je m'inscris en faux désolé, les regexp ont la qualité de pouvoir être décrites par des patterns souvent bien plus simples que les autres moyens.  
 
La regexp ^[ \t]+|[ \t]+$ détecte les espaces ou tab inutiles en début de ligne ou en fin de ligne, pour peu que tu connaisses la base en effet (^ pour début, $ pour fin, | pour OR...), elle est à la fois plus lisible, plus fiable et moins error-prone qu'un bout de code maison qui viserait à détecter la même chose (et qui aurait sans doute besoin d'une batterie de test pour garantir que ça fait bien ce que c'est censé faire, surtout si on rajoute de l'unicode ou autre). La regexp t'évite d'écrire ton parsing à la main en fait.

 
Outre la lisibilité de la regex, quand tu tombes dessus, il y a la compréhension de l'intention du dev qui l'a écrite qui compte.
 
Et dès qu'il y a doute possible sur une intention (truc non trivial ou contre intuitif) il faut pallier à ce que ne dit pas le code par des commentaires.
Une regex par essence, c'est pas trivial. Si ça l'est c'est que c'est remplaçable par un if-else et c'est préférable car mieux testable.
 
Ergo, une regex doit être accompagnée d'un commentaire avec au min. ce qui est attendu en entrée et le résultat escompté.

 
tu veux juste vérifier s'il y a un espace inutile au début ou à la fin d'une chaine de caractères et t'as besoin d'écrire un parser? Quel langage moderne ne permet pas de faire un truc du genre