Affichage des résultats du sondage: Qu’est-ce que vous préférez utiliser pour indenter vos programmes ? Pourquoi ?

Votants
93. Vous ne pouvez pas participer à ce sondage.
  • Espaces

    31 33,33%
  • Tabulations

    53 56,99%
  • Cela dépend du cas (plus de détails dans les commentaires)

    7 7,53%
  • Aucune préférence particulière

    2 2,15%
+ Répondre à la discussion Actualité déjà publiée
Page 2 sur 4 PremièrePremière 1234 DernièreDernière
  1. #21
    Rédacteur/Modérateur

    Avatar de yahiko
    Homme Profil pro
    Ninja
    Inscrit en
    juillet 2013
    Messages
    1 144
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ninja

    Informations forums :
    Inscription : juillet 2013
    Messages : 1 144
    Points : 6 534
    Points
    6 534
    Billets dans le blog
    43

    Par défaut

    Des options similaires existent dans Eclipse, dans Visual Studio (via un plugin) et autres. L'alignement à la main, c'est juste pas possible...
    Tutoriels et FAQ TypeScript

  2. #22
    Membre régulier
    Inscrit en
    novembre 2009
    Messages
    48
    Détails du profil
    Informations forums :
    Inscription : novembre 2009
    Messages : 48
    Points : 119
    Points
    119

    Par défaut

    Citation Envoyé par yahiko Voir le message
    Avec les IDE "modernes" qui formatent le code automatiquement, c'est un peu un débat dépassé je trouve. On peut passer d'une convention à une autre en une fraction de seconde et ça n'impacte pas le versioning, donc bon...
    Quand on travaille sur des vieilles technos, si ça arrive . Même en 2016 !

    CVS par exemple considère le même fichier sur 2 branches différentes comme différent si un contient des espaces et un autre des tabulations. Ça arrive souvent vu que certains développeurs activent l'option "remplacer les tabulations par des espaces" (et commitent tout sans vérifier ce qui a été modifié !).

    Ca pose de gros problème d'intégration...
    On va me dire qu'il existe une option sur CVS de type "ignore white spaces"... Alors oui, on ne verra plus les différences, mais ces fichiers sont quand même considérés comme différent, et il faut les comparer un par un afin de vérifier s'il faut les livrer ou pas... Alors quand on a 130 classes impactées dont 70 uniquement pour des histoires de tabulation, ça énerve !

    C'est souvent compliqué lorsque le même projet CVS contient des sources JAVA (avec plein de tabulations) et des sources COBOL (uniquement des espaces) par exemple.

    Edit : Dans le monde des Bisounours, on ne devrait pas avoir ce problème :
    • le code sera bien formatté/indenté dès le départ
    • les développeurs n'oublieraient pas de formatter leur modif
    • On met en place un système de norme sur la façon de coder (espace vs tab par ex)
    • Tous les IDE du même projet seraient configurés de façon identique
    • Les développeurs ne commiteraient pas des fichiers non modifiés
    • On ne travaillerait plus avec des vieux trucs style CVS

  3. #23
    Membre du Club
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    décembre 2005
    Messages
    24
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Enseignement

    Informations forums :
    Inscription : décembre 2005
    Messages : 24
    Points : 59
    Points
    59

    Par défaut

    De notre coté, on code beaucoup en PHP et on utilise les espaces, vu que ce sont les recommandations pour PHP.
    Au moins, comme ça, tout le monde voit le même code (puisqu'en plus on utilise le même IDE).

  4. #24
    Membre confirmé

    Inscrit en
    août 2007
    Messages
    299
    Détails du profil
    Informations forums :
    Inscription : août 2007
    Messages : 299
    Points : 508
    Points
    508

    Par défaut

    Pour un hobbyiste ou des professionnels intervenant seuls sur leur code, il n'y a aucun problème avec les tabs, il y a même des avantages (soulignés ici par plusieurs).

    En revanche, en environnement professionnel, il est pénalisant d'utiliser autre chose qu'uniquement des espaces (pas de tabs du tout, pas de mix).
    En effet, sur un programme d'envergure on n'est jamais seul, ou dans un seul langage, ou dans un seul IDE (ou la même version, cf. les nombreuses différences introduites dans VS2013 puis gardées dans 2015 sur la gestion des tabs par rapport à VS2012 qui avait besoin des Powertools). On est aussi toujours dans un environnement SCM. Cette combinaison fait que de nombreux faux positifs interviennent dans les suivis de gestion. Pour une simple modification locale de 50 lignes on a des nouveaux embauchés qui reformattent le fichier à leur gout (parfois sans le savoir, en utilisant l'IDE), et on se prend à rechercher les 50 parmi les 2000. Au delà des étapes de merge proprement dites, il est courant qu'une historique de fichier dépasse les 1000 états. Si quand on l'examine on est parsemé de faux positifs concernant la tabulation, c'est bien plus difficile à gérer.

    Nous le voyons régulièrement à chaque nouvelle embauche, malgré la formation sur nos conventions de codage. Il faut quelques semaines voire mois pour arrêter les faux positifs sur les tabs/espaces. Nous exportons par exemple des paramètres de formattage globaux à la société (fonction bien pratique de VS, qu'on n'a pas dans d'autres IDEs plus frustes).

    Ceci est général et concerne aussi les conventions de commentaires. Si quelqu'un s'amuse à reformater ce que quelqu'un d'autre a écrit, on a aussi de faux positifs. Les outils SCM ne sont pas tous cohérents sur le filtrage, et de nombreux cas passent nos filtres (nous utilisons Perforce/Helix).

    Un cas récent concerne les lambdas en C++: le formattage par défaut de VS ne gère bien sûr pas tous les cas correctement, avec des indentations aberrantes. Nous ne savons pas encore comment gérer ceci correctement, mais au moins n'avoir que des espaces limite la casse.
    "Maybe C++0x will inspire people to write tutorials emphasizing simple use, rather than just papers showing off cleverness." - Bjarne Stroustrup
    "Modern C++11 is not your daddy’s C++" - Herb Sutter

  5. #25
    Rédacteur/Modérateur

    Avatar de SylvainPV
    Profil pro
    Inscrit en
    novembre 2012
    Messages
    3 154
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2012
    Messages : 3 154
    Points : 9 224
    Points
    9 224

    Par défaut

    @ac_wingless: Il suffit de s'accorder sur une convention de style en début de projet et d'intégrer un style checker dans la phase de build. J'ai toujours utilisé les tabulations en environnement professionnel et ça se passe très bien D'autant que ce problème de faux positifs se pose aussi bien pour les tabulations que pour les espaces d'après tes dires. Bien sûr, si quelqu'un dans l'équipe configure n'importe comment son IDE et désactive le style checker, là on aura toujours un problème mais il sera davantage de nature humaine que technique.
    One Web to rule them all

  6. #26
    Expert confirmé
    Avatar de TiranusKBX
    Homme Profil pro
    Développeur C, C++, C#, Python, PHP, HTML, JS
    Inscrit en
    avril 2013
    Messages
    1 473
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur C, C++, C#, Python, PHP, HTML, JS
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : avril 2013
    Messages : 1 473
    Points : 4 930
    Points
    4 930
    Billets dans le blog
    6

    Par défaut

    Perso j'utilise les tabulation puis les espaces pour faire des jolis alignement d'assignation de variable
    merci de me mettre des quand mes messages sont pertinent, et pour les pas contents voici mon service client pour eux

    [Projet en cours] Strategy(nom provisoire) - Advance wars like
    cordova-plugin-file-hash Plugin cordova servant à obtenir le hash d'un fichier

  7. #27
    Membre confirmé

    Inscrit en
    août 2007
    Messages
    299
    Détails du profil
    Informations forums :
    Inscription : août 2007
    Messages : 299
    Points : 508
    Points
    508

    Par défaut

    @SylvainPV: c'est bien évidemment du problème humain que je parle.
    "Il suffit de s'accorder sur une convention de style en début de projet". C'est un peu ce que dit jmi57 dans sa liste. Ta phrase n'existe tout simplement pas dans les programmes un peu gros.
    "Maybe C++0x will inspire people to write tutorials emphasizing simple use, rather than just papers showing off cleverness." - Bjarne Stroustrup
    "Modern C++11 is not your daddy’s C++" - Herb Sutter

  8. #28
    Futur Membre du Club
    Homme Profil pro
    Développeur Java
    Inscrit en
    septembre 2016
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2016
    Messages : 1
    Points : 5
    Points
    5

    Par défaut

    Dans un monde parfait, le SCM stockerait le code en brut ou dans un format pré-défini et la conversion se ferait à la volée côté client selon le paramétrage du format défini dans les préférences de l'IDE. Fini les débats sur le formatage, les conventions de style, les comparaisons de code foireuses suite à un reformatage en masse, etc. A chacun ses préférences sans que ça crée d'impact en équipe. On vit encore à l'âge de pierre sur ce sujet-là, les outils doivent évoluer.

  9. #29
    Rédacteur/Modérateur

    Avatar de SylvainPV
    Profil pro
    Inscrit en
    novembre 2012
    Messages
    3 154
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2012
    Messages : 3 154
    Points : 9 224
    Points
    9 224

    Par défaut

    Citation Envoyé par ac_wingless Voir le message
    "Il suffit de s'accorder sur une convention de style en début de projet". C'est un peu ce que dit jmi57 dans sa liste. Ta phrase n'existe tout simplement pas dans les programmes un peu gros.
    En fait c'est précisément sur les gros projets qu'on s'accorde sur une convention de style, puisque c'est eux qui occasionnent le plus de maintenance et le plus grand nombre de développeurs différents. Pour les petits projets, on est moins regardants et la chaîne d'intégration est plus "légère".

    Il y a parfois des débats internes sur telle ou telle règle de style, mais généralement on clôt le débat assez vite sur l'argument que peu importe la convention choisie, le plus important est que tout le monde suive la même.
    One Web to rule them all

  10. #30
    Membre régulier
    Inscrit en
    novembre 2009
    Messages
    48
    Détails du profil
    Informations forums :
    Inscription : novembre 2009
    Messages : 48
    Points : 119
    Points
    119

    Par défaut

    Citation Envoyé par SylvainPV Voir le message
    En fait c'est précisément sur les gros projets qu'on s'accorde sur une convention de style, puisque c'est eux qui occasionnent le plus de maintenance et le plus grand nombre de développeurs différents. Pour les petits projets, on est moins regardants et la chaîne d'intégration est plus "légère".

    Il y a parfois des débats internes sur telle ou telle règle de style, mais généralement on clôt le débat assez vite sur l'argument que peu importe la convention choisie, le plus important est que tout le monde suive la même.
    Je suis d'accord avec toi sur les nouveaux projets en effet.
    Si on met en place des processus très stricts dès les premières lignes de code, on ne rencontre pas trop ce genre de problèmes.

    Par contre, quand on récupère la maintenance d'un projet, et que le "style checker" n'a a jamais été mis en place, c'est chaud à rattraper...

  11. #31
    Membre confirmé

    Inscrit en
    août 2007
    Messages
    299
    Détails du profil
    Informations forums :
    Inscription : août 2007
    Messages : 299
    Points : 508
    Points
    508

    Par défaut

    Citation Envoyé par SylvainPV Voir le message
    En fait c'est précisément sur les gros projets qu'on s'accorde sur une convention de style, puisque c'est eux qui occasionnent le plus de maintenance et le plus grand nombre de développeurs différents. Pour les petits projets, on est moins regardants et la chaîne d'intégration est plus "légère".

    Il y a parfois des débats internes sur telle ou telle règle de style, mais généralement on clôt le débat assez vite sur l'argument que peu importe la convention choisie, le plus important est que tout le monde suive la même.

    Je parle de choses très concrètes: un stagiaire/sous traitant/consultant/nouvel embauché installe VS2015, check-out un fichier, fait sa modif, fait son Ctrl-K+D Ctrl-S et submit vers une branche de dev. Son collègue fait une autre modif, et submit en respectant la fameuse "convention de style". Ou bien l'un travaille sur C++ Builder et l'autre sur VS. Ou bien l'un est indiscipliné et n'en a rien à foutre de ce boulot de merde alors que l'autre est tout juste promu et fayote. Dire que ces cas n'arrivent pas est assez utopique (jmi57 parle même de "bisounours"), d'autant plus que le nombre de programmeurs est grand, la durée longue (décennies), les langages et outils différents, et le déploiement complexe. Or les conséquences sont définitives (c'est comme la compta: on ne peut plus enlever!) et peuvent "percoler" jusqu'à rendre l'historique des versions inutilisable.

    En effet, les lignes communes sont détectées différentes. Les dégâts ne se limitent pas à un resolve fastidieux, car l'historique de modification est polluée définitivement, et se propage de branche à branche. Pire, son inverse se propage aussi si quelqu'un se met en tête de "corriger" l'erreur, surtout plus tard quand 50 autres commits sont intervenus entre temps. Deux ans après, quand on regarde l'historique sur une release pour un bug client, on voit une contribution d'une AUTRE personne que le coupable ou son collègue innocent, celui qui a fait l'intégration 3 semaines plus tard. Au lieu de voir cette intégration et sa documentation, on voit des modifications qui n'ont aucun rapport.

    A l'usage (désolé d'être un peu vieux, mais avec 31 ans de carrière j'en ai vu des exemples de gros programmes qui merdent), les outils SCM ont réussi à faire abstraction de problèmes simples (CR/LF vs CR, trailing white space), mais sont toujours pourris au niveau tab/espace, malheureusement pour une raison assez fondamentale tant qu'il n'auront pas une connaissance sous-jacente leur permettant d'analyser le texte (peut-être un jour avec LLVM?). Même Helix, qui est quand même assez moderne, n'est pas cohérent sur ses filtres: les outils de resolve font bien abstraction de ce qui est attendu en matière de mix tabs/space, je dirais même avec finesse, mais le mécanisme de détection de conflit est beaucoup plus strict au niveau du serveur, sans doute parce qu'il doit être général et par exemple détecter les évolutions de fichiers binaires ou mixant binaire et texte. Résultat: même si le merge se fait bien ou facilement, l'historique est polluée irrémédiablement. Si on a 200 ou 300 branches, avec même juste 3 gugusses qui s'amusent à ça de temps en temps, au bout de 5 ans c'est une galère.

    Dans la réalité de la gestion de projet, ignorer les techniques défensives simples en faisant confiance aux vœux pieux est risqué. C'est pourquoi je me permets d'être en désaccord avec ta recommandation. Pour moi, c'est un peu comme si tu répondais à quelqu'un qui conseille la programmation défensive "en fait, plus le programme est complexe, plus les enjeux en termes de qualité sont gros, et plus les gens font attention, donc pas la peine".
    "Maybe C++0x will inspire people to write tutorials emphasizing simple use, rather than just papers showing off cleverness." - Bjarne Stroustrup
    "Modern C++11 is not your daddy’s C++" - Herb Sutter

  12. #32
    Rédacteur/Modérateur

    Avatar de SylvainPV
    Profil pro
    Inscrit en
    novembre 2012
    Messages
    3 154
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2012
    Messages : 3 154
    Points : 9 224
    Points
    9 224

    Par défaut

    Je ne connais pas bien le monde C++ mais ça doit bien exister un style checker pour ce langage non ? Tiens je viens d'en tomber sur un : https://kitware.github.io/KWStyle/

    Il ne s'agit pas de vœux pieux, quand je dis qu'on s'accorde sur une convention de style, je veux dire par là qu'on s'accorde sur une configuration du style checker qui tournera systématiquement à chaque modification des sources et s'exécute avant chaque commit. Le seul moyen d'outrepasser cette règle est de désactiver manuellement le style checker en modifiant la config de build. Personne ne l'a fait jusqu'ici, et je pense que celui qui ose aura vite droit à un recadrage.
    One Web to rule them all

  13. #33
    Membre régulier
    Inscrit en
    novembre 2009
    Messages
    48
    Détails du profil
    Informations forums :
    Inscription : novembre 2009
    Messages : 48
    Points : 119
    Points
    119

    Par défaut

    Citation Envoyé par ac_wingless Voir le message
    Je parle de choses très concrètes: un stagiaire/sous traitant/consultant/nouvel embauché installe VS2015, check-out un fichier, fait sa modif, fait son Ctrl-K+D Ctrl-S et submit vers une branche de dev. Son collègue fait une autre modif, et submit en respectant la fameuse "convention de style". Ou bien l'un travaille sur C++ Builder et l'autre sur VS. Ou bien l'un est indiscipliné et n'en a rien à foutre de ce boulot de merde alors que l'autre est tout juste promu et fayote. Dire que ces cas n'arrivent pas est assez utopique (jmi57 parle même de "bisounours"), d'autant plus que le nombre de programmeurs est grand, la durée longue (décennies), les langages et outils différents, et le déploiement complexe. Or les conséquences sont définitives (c'est comme la compta: on ne peut plus enlever!) et peuvent "percoler" jusqu'à rendre l'historique des versions inutilisable.
    Oui j'aime bien le terme "monde des bisounours". Dans la théorie la MOA fait des docs fonctionnelles toutes propres, les développeurs font du code tout beau et bien commenté, les tests sont réalisés correctement et les chefs de projets encadrent très bien leur équipe et tous les plannings sont respectés... ALors on peut mettre en place tout plein de conventions et documentation en place. Dont les fameuses "convention de styles".

    En vrai, la MOA ne sait pas ce qu'elle veut et se contredit, les chefs de projets sont débordés, les développeurs font tout dans l'urgence et ne sont pas toujours très rigoureux, et il y a un réel turn-over au sein de l'équipe (en tout cas sur des projets gérés par des prestataires...) Aors respecter une "convention de style" est loin d'être une priorité sur un projet.
    Ca a comme effet de rendre du code illisible et non documenté. Et comme dit ac_wingless l'historique des versions devient inutilisable.
    Alors au bout de quelques années, un développement sera beaucoup plus long à faire, et on prendra encore plus de retard...

    Bien enendu, il y a les adeptes des outils homogènes.
    Je suis tout à fait pour d'ailleurs mettre en place (dans le monde Java) une plate-forme d'intégration continue, et des IDE identiques et configurés de manière identique pour tous les développeurs.
    Mais il y a aura toujours un développeur qui aura une config différente soit par choix, soit par mégarde.
    Et même au bout de 2 ou 3 ans , il faudra bien mettre à jour les outils. Et là paf, on oublie une config sur la nouvelle version de l'IDE et hop le code change de format...

    Ou alors on travaille en mode ultra-sécurisé. Avec des verrous de partout, des relectures de codes ultra-poussés entre collègues, des outils ultraprefectionnés qui ne laissent rien passer... Mais dans ce cas le projet n'avance plus... On commence tellement à réfléchir sur la forme du code qu'on ne réfléchit plus vraiment sur l'algorithme lui-même...

  14. #34
    Rédacteur/Modérateur
    Avatar de Logan Mauzaize
    Homme Profil pro
    Architecte technique
    Inscrit en
    août 2005
    Messages
    2 861
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Transports

    Informations forums :
    Inscription : août 2005
    Messages : 2 861
    Points : 6 902
    Points
    6 902

    Par défaut

    Citation Envoyé par jmi57 Voir le message
    Edit : Dans le monde des Bisounours, on ne devrait pas avoir ce problème :
    • le code sera bien formatté/indenté dès le départ
    • les développeurs n'oublieraient pas de formatter leur modif
    • On met en place un système de norme sur la façon de coder (espace vs tab par ex)
    • Tous les IDE du même projet seraient configurés de façon identique
    • Les développeurs ne commiteraient pas des fichiers non modifiés
    • On ne travaillerait plus avec des vieux trucs style CVS
    Je pense que tu as également oublié :
    • la convention ne change pas en cours de route
    • le formatteur et le checker ont été bien configurés pour être cohérent


    Pour le problème humain, à mon avis, c'est surtout lié au manque de "dev leader" / "responsable technique" attitré dans les projets. On pense souvent à placer un "chef de projet" pour fliquer le planning et les dépenses mais moins souvent à la personne qui va fliquer le code et le travail réalisé. Ce n'est pas un rôle très sympas (je sais ce que c'est, je l'ai fait) mais je pense nécessaire pour un projet sur le long terme et si on a une conscience professionnelle.

    J'ai toujours travaillé dans un environnement avec des personnes volontaires, et les personnes ayant fait des erreurs ont toujours acceptés de se corriger. Si ce n'est pas le cas, je ne suis pas sûr que ce(s) personne(s) soi(en)t adapté(s) au projet et pour le travail en équipe de manière générale.
    Java : Cours et tutoriels - FAQ - Java SE 8 API - Programmation concurrente
    Ceylon : Installation - Concepts de base - Typage - Appels et arguments

    ECM = Exemple(reproduit le problème) Complet (code compilable) Minimal (ne postez pas votre application !)
    Une solution vous convient ? N'oubliez pas le tag
    Signature par pitipoisson

  15. #35
    Membre averti Avatar de Madmac
    Homme Profil pro
    Responsable de projet fonctionnel
    Inscrit en
    juin 2004
    Messages
    354
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Responsable de projet fonctionnel
    Secteur : Alimentation

    Informations forums :
    Inscription : juin 2004
    Messages : 354
    Points : 338
    Points
    338

    Par défaut

    La tabulation devrait-être la norme. Tout simplement parce que cela permet de personnaliser l'indentation du code selon les préférences personnelles des individus sans que cela affecte le code.
    Permettre ce genre de flexibilité est une délicatesse que me semble normal entre collaborateurs

    De plus, avec des langages comme python, oublie un espace d'un caractère est difficile à repérer.
    intel i7
    OpenSuse Leap 42.2
    Plasma et Cinnamon

  16. #36
    Membre régulier
    Inscrit en
    novembre 2009
    Messages
    48
    Détails du profil
    Informations forums :
    Inscription : novembre 2009
    Messages : 48
    Points : 119
    Points
    119

    Par défaut

    Citation Envoyé par Madmac Voir le message
    La tabulation devrait-être la norme. Tout simplement parce que cela permet de personnaliser l'indentation du code selon les préférences personnelles des individus sans que cela affecte le code.
    Permettre ce genre de flexibilité est une délicatesse que me semble normal entre collaborateurs

    De plus, avec des langages comme python, oublie un espace d'un caractère est difficile à repérer.
    Pour Python ou Java d'accord.

    Mais d'autres langages comme COBOL fonctionnent en "position".
    Or 1 espace = 1 position.
    Le code commence réellement à la position 8.
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
          * voici une ligne de commentaire COBOL
    Comment gérer les tabulations alors ?
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    tab tab * voici une ligne de commentaire COBOL
    Alors le Coboliste qui travaille sous Eclipse va configurer son IDE pour remplacer une tabulation par 4 espaces par exemple.

  17. #37
    Membre régulier
    Inscrit en
    novembre 2009
    Messages
    48
    Détails du profil
    Informations forums :
    Inscription : novembre 2009
    Messages : 48
    Points : 119
    Points
    119

    Par défaut

    Citation Envoyé par Madmac Voir le message
    cela permet de personnaliser l'indentation du code selon les préférences personnelles des individus sans que cela affecte le code.
    Tout-à-fait d'accord.

    En fait, souvent on considère la tabulation comme un ensemble d'espaces. Mais non. La tabulation ne sert pas à éviter d'appuyer 4 fois sur la touche espace.

    La tabulation est en effet un "curseur" configurable (que ce soit au niveau du code ou d'un traitement de texte) qui définit le passage d'une zone à une autre.
    Donc dans la théorie, on ne peut pas remplacer une tabulation par n espaces, ça n'a pas de logique.

    En réalité, c'est courant de faire ça. Même les IDE ont des options pour cela...

  18. #38
    Membre éclairé

    Homme Profil pro
    Développeur informatique
    Inscrit en
    octobre 2013
    Messages
    293
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Conseil

    Informations forums :
    Inscription : octobre 2013
    Messages : 293
    Points : 771
    Points
    771

    Par défaut

    Citation Envoyé par Madmac Voir le message
    La tabulation devrait-être la norme. Tout simplement parce que cela permet de personnaliser l'indentation du code selon les préférences
    De plus, avec des langages comme python, oublie un espace d'un caractère est difficile à repérer.
    Je commence python et c'est ma hantise de faire une erreur de bloque.
    J'aimerai bien avoir du Python avec accolades

    Alors je pense mettre des commentaires pour pas me perdre
    #End if #End for ....
    Un peu comme en Pascal car je trouve ça dangereux
    Une collègue faisait ça sur notre code javas.
    Je trouvait ça un peu exagéré, mais quand on code sans les yeux ça aide.

    En ce moment ça va car je fais que des petits Script Python pour découvrir
    Mais sur un gros script ça doit être facil de se perdre
    Consultez mes articles sur l'accessibilité numérique :

    Comment rendre son application SWING accessible aux non voyants
    Créer des applications web accessibles à tous

    YES WE CAN BLANCHE !!!

    Rappelez-vous que Google est le plus grand aveugle d'Internet...
    Plus c'est accessible pour nous, plus c'est accessible pour lui,
    et meilleur sera votre score de référencement !

  19. #39
    Rédacteur/Modérateur
    Avatar de Logan Mauzaize
    Homme Profil pro
    Architecte technique
    Inscrit en
    août 2005
    Messages
    2 861
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Transports

    Informations forums :
    Inscription : août 2005
    Messages : 2 861
    Points : 6 902
    Points
    6 902

    Par défaut

    Citation Envoyé par CoderInTheDark Voir le message
    Je commence python et c'est ma hantise de faire une erreur de bloque.
    J'aimerai bien avoir du Python avec accolades
    Regardes du côté de Ruby ou Crystal
    Java : Cours et tutoriels - FAQ - Java SE 8 API - Programmation concurrente
    Ceylon : Installation - Concepts de base - Typage - Appels et arguments

    ECM = Exemple(reproduit le problème) Complet (code compilable) Minimal (ne postez pas votre application !)
    Une solution vous convient ? N'oubliez pas le tag
    Signature par pitipoisson

  20. #40
    Rédacteur/Modérateur

    Avatar de yahiko
    Homme Profil pro
    Ninja
    Inscrit en
    juillet 2013
    Messages
    1 144
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ninja

    Informations forums :
    Inscription : juillet 2013
    Messages : 1 144
    Points : 6 534
    Points
    6 534
    Billets dans le blog
    43

    Par défaut

    Je trouve tout de même "surprenant" que les résultats du sondage sur ce topic soit diamétralement opposé aux statistiques sur Github.
    J'aurais tendance à penser que la population des développeurs qui ont répondu ici n'est pas vraiment représentative. J'aurais été curieux de savoir quel était le langage de prédilection de chaque votant.
    Tutoriels et FAQ TypeScript

Discussions similaires

  1. Est ce que on peut utiliser mysql5 en production
    Par amika dans le forum Installation
    Réponses: 7
    Dernier message: 12/09/2005, 16h21
  2. qu'est-ce que les design pattern ?
    Par airseb dans le forum Design Patterns
    Réponses: 1
    Dernier message: 23/11/2004, 09h02
  3. Est-ce que les fichiers .obj sont tous les mêmes?
    Par Bubonik software dans le forum Langages de programmation
    Réponses: 2
    Dernier message: 30/12/2003, 22h04
  4. Réponses: 3
    Dernier message: 19/07/2002, 16h01

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo