Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Simple?
Oui c'est vrai aussiEnvoyé par Dave Hiock
Et donc c'est quoi ta recommendation "simple"?
Du temps de la carte perforée on programmait principalement en Cobol, Basic ou assembleur. Donc des langages à programmation "spaghetti" où il y a rarement des structures à plus de deux niveaux d'imbrication.
Pour les langages à structure de bloc, c'est une autre histoire.
Il ne faut pas confondre l'usage de la touche TAB avec ce qui est inséré dans le fichier.
Tout les éditeurs de texte sérieux permettent d'insérer des espaces à la place d'une tabulation (et ce depuis plus de 35 ans).
Les bons éditeurs permettent aussi de régler la largeur d'une tabulation (ou le nombre d'espaces insérés par la touche TAB) suivant le langage du fichier édité.
Pour ma part, je préfère n'utiliser que des espaces parce que, par expérience, les fichiers avec tabulations finissent inéluctablement par comporter un mélange de caractères espaces et de tabulation, réduisant à néant l'intérêt du caractère de tabulation pour s'adapter aux préférences de chaque personne. Du coup, avec des espaces, l'indentation initiales résistent mieux au temps.
Pour info Stackoverflow avait fait une étude amusante qui démontre que les fans des espaces gagnent plus que ceux des tabs
https://stackoverflow.blog/2017/06/1...oney-use-tabs/
Les deux solutions ont chacunes leurs inconvénients, et puisqu'il s'agit donc de choisir quels aspects comptent le plus sur un projet, il y en a un qu'on oublie souvent : l'accessibilité. Au delà de simples préférences personnelles, les tabulations permettent aux personnes malvoyantes d'adapter plus facilement l'affichage à leurs besoins (qui ne sont pas toujours les mêmes) pour travailler dans des conditions correctes.
Un post intéressant sur le sujet : https://www.reddit.com/r/javascript/...n_to_use_tabs/
Bonjour luciole75w,
Je suis 100% d'accord et c'est bien ce que j'essaie de faire comprendre. A quoi servent les tabulations et espaces multiples en début de ligne? Les IDE correctes permettent de paramétrer la taille et la fonte des caractères ainsi que la taille de chaque indentation que cette IDE automatise, même pour certaines, en fonction du degré d'imbrication. Donc chacun est libre d'afficher le code dans la charte graphique qu'il souhaite, sans dépendance avec un nombre de blancs (espaces ou tabs) que le développeur aurait pu ajouter égoïstement pour son propre confort visuel.
C'est juste une question d'outil de visualisation, pas de code. C'est aussi une erreur que 99% des utilisateurs de traitements de texte font. Ces logiciels permettent une mise en page automatique paramétrable qui rend les documents cohérents et utilisent une charte graphique comprenant les indentations, qui permet même de reconnaître l'entreprise éditrice sans lire le texte, rien qu'au rendu. Cela autorise des mise à jour du document en assurant que la mise en page est conservée et facilite la tâche et du rédacteur, et du correcteur et du lecteur. Peu de monde s'attache pourtant à cette fonctionnalité mais utilise à la place pléthore d'espaces, tabulations et passages à la ligne pour mettre en page. Au final, l'ajout d'un caractère, même un espace sur la première page, peut rendre le reste du document caduque voire illisible. Pourquoi ne pas profiter de bons outils?
Pour une bête histoire d'alignement tu peux avoir un maximum d'emmerdements.Certes aujourd'hui les éditeurs ont tendance à reformater à la première sauvegarde. Donc chacun voit ce qui lui plaît au final.
Hélas au moment d'envoyer dans Git, ça génère plein de lignes "modifiées" uniquement à cause de l'indentation.
Il y a bien une option --ignore-space-change quand on applique un patch, mais pas quand on fait un commit. Peut-être un point à améliorer.
Idéalement ça devrait pouvoir devenir totalement transparent pour l'utilisateur.
Y'a rien de plus chiant pour la lecture du code sur des projets conséquents que de devoir reprendre des mises en pages parce que personne n'a la même configuration d'un éditeur, plateforme à l'autre.
La simplicité a du bon : KISS.
Suis peut être trop vieux...
Lorsque jeune je codais sur cartes perforées et utilisais une machine à écrire mécanique, la tabulation était variable au gré de l'utilisateur qui lui-même réglait ses taquets.
Dans la bataille en cours je me rends compte que les protagonistes utilisent tous les deux, espaces et tabulations, à mauvais escient.
La touche de tabulation sur la machine à écrire permettait d´atteindre une position sur une ligne sans taper de multiples fois sur une touche. Mettre deux tabulations successives est donc une ineptie au même titre que mettre plus de deux espaces consécutifs.
Le but recherché est une indentation de texte pour un visuel confortable.
Dans le cadre de la majorité des codes, nul besoin de mettre d´espace ou de tabulation en début de ligne: chaque caractère comptait et se payait sur une carte perforée!
Une simple analyse du code par un outil convenable, même sans IA, permet d'afficher ce code avec l'indentation souhaitée. C'est ce que font beaucoup d'IDE. Gain d'espace, gain de temps, et tous les parsers peuvent extraire les données.
Utilisons des outils modernes et adaptés au lieu de disserter sur des blancs inutiles du point de vue de la majorité des langages informatiques!
Avec l’expérience on s’en fout
Honnêtement l’un ou l’autre je m’en cogne royalement je veux juste de la cohérence dans le code.
Mais par s’il vous plaît ne mixez pas ces caractères tout comme les fins de lignes Linux ou Windows.
Prenez l’un ou l’autre mais pas les deux en même temps dans une même famille de repo de code.
Dégonflez vos chevilles et pensez collectif.
OK...qui est volontaire pour poser son pantalon sur ces belles chevilles ?!
à propos du sujet :
lisbilité (les tabulations ne me conviennent pas) vs économie (de nos jours, les téléchargements "primaires" sont lourds, les disques sont "larges", et les mises à jours...)
est-ce le signe que Linus commence à vivre dans le passé* ?
--
* malgré ses compétences que personne ne peut nier !
la solution
Stoppez les rotatives !
On a trouvé le génie qui va permettre au monde sortir de windaube !
Vieux débat mais je préfère les tabulations
L'intérêt de la tabulation, et c'est la raison qui a poussé les créateurs de Go d'utiliser cette règle dans les formateurs de code, c'est que ça ne vaut qu'un octet, et que les éditeurs peuvent définir comment l'afficher. Par exemple sur NeoVim, je préfère afficher les tabulations avec 4 espaces en Go, 2 pour typescript et Python, 4 pour le C... Alors que mes collègues vont préférer utiliser 4 partout, ou 8, ou 2... On a tous le même fichier, aucun conflit, c'est l'affichage qui change.
Franchement, j'étais pro espace plus jeune, mais je me suis rendu compte de mon erreur.
Voilà...
Et voilà exactement pourquoi j'ai quitté le codage quasiment des le début en 91! Écoeuré par le C versus les élégants Lisp Pascal et consorts , et ces bidouillages débiles comme Unix (cf le livre The Unix Haters Book).
On a donc un outil extraordinaire, l'ordinateur, capable de traiter des fichiers XML CSS et j'en passe mais on est encore à se battre sur des indentations versus des espaces blancs? N'est-ce pas totalement débile ? Au lieu d'avoir des fichiers de code en texte ne pourrait-on pas inventer du code intelligent type base de données et lisible comme chacun veut (humain ou dorénavant par des IA), et même en anglais ou Français ou chinois? Du code est du code : en C et assembleur et binaire in fine ça doit correspondre donc allez jusqu'au bout, en français ou IA ou bytecode tout doit correspondre. Et en indentations ou espace, c'est bien un combat débile.
Arrêtons de réinventer les tabulations.
Historiquement (sur les machines à écrire), la touche tabulation servait à propulser la tête d'écriture jusqu'au prochain taquet. Les taquets doivent donc être préalablement positionnés.
Rien de tel avec les éditeurs de texte ni avec les commandes comme less ou diff.
Donc il semble logique de ne pas utiliser de caractères de tabulation. Je ne mets que des espaces (avec expandtab sous Vim).
Néanmoins je peux comprendre la réaction de Linux Torvald : si un outil est perturbé par un simple caractère de tabulation alors il faut corriger l'outil au lieu de corriger tous les sources. Le caractère de tabulation doit donc être accepté et traité, si nécessaire, avec un espacement de 8 car c'est l'espacement par défaut de très nombreux terminaux (lire la commande "tabs" par exemple).
Tout cela est bien futile . On dirait une polémique de bureaucrates .
Cela porte un nom : https://fr.wikipedia.org/wiki/Loi_de...9_de_Parkinson
T'indentes comme les guidelines de disent de le faire. Linux impose les tabulations ? T'indentes avec des tabulations, point barre ! Un projet Python choisit de respecter le standard Python alias PEP 8 ? T'utilises des espaces. Idem avec un projet PHP décidant de respecter la PSR-12. Le plus important est de respecter l'équipe et les décisions quant au guide de style prises pour le projet.
Personnellement j'ai toujours été pro-tabulations. L'indentation avec les espaces c'est comme les bises quand on se dit bonjour : personne n'a le même nombre. Alors qu'une tabulation sera toujours une unité d'indentation partout. La simplicité à l'état brut. Mais est-ce pour autant que je force sur les tabulations s'il a été décidé de mettre des espaces ? Non.
Il faut alors faire appel à un bisotologue :
Juste histoire de me la péter un peu. On est dans le domaine de la typographie. Espace est donc féminin, pas masculin. Sur ce, bonne journée
Sortie officielle du noyau Linux 6.9 avec la prise en charge de Rust pour ARM64
Sortie officielle du noyau Linux 6.9, introduisant la prise en charge de Rust sur les architectures AArch64 (ARM64) et la prise en charge du mécanisme Intel FRED.
Le noyau Linux 6.9 est officiellement disponible. Cette version introduit plusieurs nouvelles fonctionnalités et une meilleure prise en charge du matériel, dont la prise en charge de Rust sur les architectures AArch64 (ARM64) et la prise en charge du mécanisme Intel FRED (Flexible Return and Event Delivery).
Le noyau Linux est un noyau de système d'exploitation open-source et gratuit : 4 monolithique, modulaire, multitâche, de type Unix. Il a été écrit à l'origine en 1991 par Linus Torvalds pour son PC i386, et a été rapidement adopté comme noyau du système d'exploitation GNU, qui a été écrit pour être un remplacement libre d'Unix. Linux est déployé sur une grande variété de systèmes informatiques, tels que les appareils embarqués, les appareils mobiles (y compris son utilisation dans le système d'exploitation Android), les ordinateurs personnels, les serveurs, les ordinateurs centraux et les superordinateurs.
Linus Torvalds a annoncé la publication et la disponibilité générale du noyau Linux 6.9, la dernière version stable du noyau Linux. Les points forts du noyau Linux 6.9 comprennent la prise en charge de Rust sur les architectures AArch64 (ARM64), la prise en charge du mécanisme Intel FRED (Flexible Return and Event Delivery) pour l'amélioration de la fourniture d'événements de bas niveau, la prise en charge des invités AMD SNP (Secure Nested Paging) et une nouvelle cible dm-vdo (virtual data optimizer) dans le device mapper pour la déduplication en ligne, la compression, l'élimination du zéro-bloc et le thin provisioning (provisionnement fin).
Le noyau Linux 6.9 prend également en charge la fonction Named Address Spaces dans GCC (GNU Compiler Collection) qui permet au compilateur de mieux optimiser l'accès aux données par CPU, ajoute une prise en charge initiale de FUSE passthrough pour permettre au noyau de servir directement des fichiers à partir d'un serveur FUSE en espace utilisateur, ajoute la prise en charge de la mise à jour dynamique du modèle énergétique au moment de l'exécution, et introduit un nouveau mode LPA2 pour les processeurs ARM 64 bits.
Le langage Rust a été mis à jour à la version 1.76.0 dans Linux 6.9, qui retravaille également le mécanisme de verrouillage dans le sous-système GPIO, ajoute la prise en charge du dérouleur de pile ORC et du correctif en direct du noyau pour l'architecture LoongArch, atténue la vulnérabilité RFDS (Register File Data Sampling) affectant les processeurs Intel Atom, et ajoute la prise en charge de l'appel système membarrier() pour l'architecture RISC-V.
Parmi les autres modifications notables du noyau Linux 6.9 figurent la prise en charge de la compression LZ4 pour le code de création et de chargement de l'image d'hibernation, la prise en charge par les administrateurs NFSD de la révocation de l'état ouvert et verrouillé de NFSv4, la prise en charge de l'arborescence des enfants de sous-volume, l'amélioration du pipelining des journaux, l'amélioration du chemin de rejet, l'amélioration de la vérification de la structure des répertoires et la nouvelle aide mm dans le système de fichiers bcachefs introduite dans le noyau Linux 6.8.
Le système de fichiers F2FS (Flash-Friendly File System) a bénéficié d'une prise en charge des périphériques à blocs zonés, d'une compression par fichier et d'une meilleure récupération des données après une coupure de courant soudaine sur un périphérique à blocs zonés, le système de fichiers exFAT a bénéficié d'améliorations des performances de synchronisation des répertoires, le système de fichiers EXT4 a reçu un indicateur d'inode pour les écritures atomiques et des améliorations de redimensionnement en ligne, et le système de fichiers Btrfs a reçu davantage de correctifs pour le mode zoné et des optimisations mineures des performances.
En outre, les performances de gestion de la mémoire ont été améliorées, l'outil perf a reçu plusieurs nouvelles fonctionnalités, la prise en charge des jetons BPF a été ajoutée pour déléguer un sous-ensemble de fonctionnalités du sous-système BPF à partir de daemons privilégiés à l'échelle du système comme systemd, et les processeurs ARM 64 bits ont reçu une prise en charge initiale du bit PTE contigu pour permettre aux TLB de mapper une plage plus grande qu'une seule PTE si la plage est physiquement contiguë.
Les améliorations apportées au réseau dans Linux 6.9 comprennent la prise en charge de TCP_NOTSENT_LOWAT dans MPTCP, la prise en charge du transfert des messages d'erreur ICMP dans IPSec, la prise en charge de la machine d'état de contrôle indépendante pour le bonding selon IEEE 802.1AX-2008 5.4.15, la prise en charge des hôtes avec plusieurs réseaux MCTP disjoints, la prise en charge des nouveaux modes de liaison 2.5GE et 5GE Energy Efficient Ethernet (EEE), la prise en charge des AMSDU SPP (signalisation et protection de la charge utile) et la prise en charge de l'OFDMA à bande passante élargie.
De nouveaux pilotes sont inclus dans Linux 6.9 pour le contrôleur embarqué de ChromeOS, le VF Octeon PCI Endpoint NIC de Marvell, le générateur d'horloge sans fil FemtoClock3 de RENESAS, le processeur Snapdragon X Elite (X1E80100) de Qualcomm, les périphériques Bluetooth Wireless Action Mouse, Keyboard, GamePad, Book Cover, Universal Keyboard et HOGP Keyboard de Samsung, les manettes de jeu de Snakebyte, ainsi que les contrôleurs tactiles I2C et SPI de Goodix Berlin.
Il ajoute également plus de blocs IP AMD pour prendre en charge le futur matériel AMD, met à jour le pilote graphique Intel Xe, ajoute la prise en charge du tunnel Displayport pour le pilote graphique Intel i915, ajoute la prise en charge HDMI pour le processeur Rockchip RK3128, ajoute la prise en charge SoundWire pour les systèmes AMD ACP 6.3 et la prise en charge du mode DSPless pour les systèmes Intel Soundwire, la prise en charge du contrôle de la charge de la batterie pour les ordinateurs portables Fujitsu, et la prise en charge de la clé de fréquence de rafraîchissement pour les ordinateurs portables Lenovo IdeaPad.
Enfin, le noyau Linux 6.9 indique que le système de fichiers EXT2 est déprécié car il n'est pas (et ne sera pas) protégé contre le problème de l'an 2038. Bien que vous puissiez encore utiliser EXT2 dans le noyau Linux 6.9, les développeurs du noyau Linux recommandent de l'éviter. Dans le même ordre d'idées, Linux 6.9 supprime enfin l'ancienne implémentation du système de fichiers NTFS, en adoptant par défaut NTFS3 pour la prise en charge des systèmes de fichiers NTFS.
Le noyau Linux 6.9 sera une branche éphémère qui ne sera prise en charge que pendant quelques mois. Elle sera remplacée par le noyau Linux 6.10, dont la fenêtre de fusion a été officiellement ouverte par Linus Torvalds. La sortie du noyau Linux 6.10 est prévue pour le milieu ou la fin du mois de septembre 2024.
Voici l'annonce de Linus Torvalds :
Source : Linus TorvaldsLinux 6.9
Thorsten signale encore quelques corrections de régression qui ne me sont pas encore parvenues, mais aucune d'entre elles ne semble suffisamment importante ou inquiétante pour retarder la publication d'une semaine supplémentaire. Nous devrons faire un backport lorsqu'ils seront résolus et qu'ils arriveront en amont.
La 6.9 est donc sortie, et la semaine dernière a semblé assez stable (et l'ensemble de la version a semblé assez normal). Voici le shortlog de la semaine dernière, les changements étant principalement dominés par des mises à jour de pilotes (gpu et réseau étant les plus importants, mais "important" est encore assez petit, et il y a aussi d'autres bruits de pilotes).
En dehors des pilotes, il y a quelques corrections de systèmes de fichiers (bcachefs se distingue toujours, mais ksmbd apparaît aussi), quelques corrections de selftest tardives, et quelques corrections de réseau de base.
Et j'ai maintenant une machine arm64 plus puissante (grâce à Ampere), donc la semaine dernière j'ai fait presque autant de builds arm64 que x86-64, et cela devrait évidemment continuer pendant la fenêtre de fusion à venir. L'ordinateur portable M2 que j'ai est plus du type "test builds weekly" que "continuously".
Non pas que je m'attende à ce que cela révèle des problèmes - les builds de l'ordinateur portable n'en ont jamais révélé - mais je me sens plus heureux d'avoir un peu plus de couverture.
Quoi qu'il en soit, continuez à tester, et cela signifie évidemment que la fenêtre de fusion pour la 6.10 s'ouvre demain. J'ai déjà quelques douzaines de pull requests en attente, j'apprécie les lève-tôt.
Linus
Et vous ?
Quel est votre avis sur le sujet ?
Voir aussi :
Publication de communiqués de presse en informatique. Contribuez au club : corrections, suggestions, critiques, ... Contactez le service news et Rédigez des actualités
Répondre avec citation
Partager