On se fait un 10 questions / 10 réponses sur le code ?
15 points par curioe 2024-09-10 | 46 commentaires | Partager sur WhatsApp
  1. Vous utilisez des tabulations pour l'indentation ou des espaces ? Combien d'espaces mettez-vous ?
  2. Vous commencez les accolades sur une nouvelle ligne, ou vous les mettez à la suite sur la même ligne ?
  3. Combien de caractères autorisez-vous par ligne ?
  4. Quel style préférez-vous pour nommer les variables ou les fonctions ? (ex. : camelCase, snake_case)
  5. Quel est votre éditeur préféré ?
  6. Quelle police utilisez-vous pour coder ? Et quelle taille ?
  7. Quand vous créez quelque chose, quel est le premier langage de programmation vers lequel vous vous tournez ?
  8. Avez-vous des règles ou un ordre particulier pour importer les modules ou les bibliothèques ?
  9. Faites-vous des tests unitaires ? De quelle manière ?
  10. Un mot à ajouter / un avis / une fierté / une promo / n'importe quoi, écrivez ce que vous voulez.

À lire aussi

46 commentaires

 
aer0700 2024-11-17
  1. 4 espaces
  2. style K&R sur la même ligne
  3. Plutôt que de fixer un nombre de caractères, ça varie selon le contexte.
    Pour la gestion des erreurs, j’essaie de finir en une seule ligne si possible,
    mais pour le reste de la logique, je découpe.
  4. Personnellement, je préfère le Snake, mais je suis ce que fait l’équipe.
  5. VS Code
  6. La police par défaut de VS Code
  7. C
  8. J’include d’abord la bibliothèque standard. Ensuite les bibliothèques externes, puis les bibliothèques internes à l’entreprise.
  9. Au moment du build, j’exécute les tests unitaires. Si un test unitaire échoue, je corrige puis je rebuild... jusqu’à ce que tout passe.
  10. Faites attention au rhume. Faites attention à vos poignets. Buvez avec modération. Mettons-nous au régime.
 
bobcat 2024-10-14
  1. 2 ou 4 espaces
  2. Newline
  3. 79-80 / 119-120
  4. S'il existe une convention comme PEP8, la respecter ; sinon, CC.
  5. VSCode
  6. Consolas, 9 pt
  7. C
  8. Stdlibs (stdlib) > bibliothèques de plateforme (Windows, unistd...) > bibliothèque essentielle (à l'échelle du projet) > bibliothèque auxiliaire (axée module)
  9. Test unitaire
  10. Il fait froid
 
jwh926 2024-10-04
  1. Projet perso : tabulation sur 4 colonnes, au travail : 4 espaces
  2. En ce moment, je l’écris sur la ligne suivante
  3. 100
  4. snake_case
  5. VSCode
  6. Iosevka 22px
  7. Python
  8. Le mot-clé from en priorité, puis la bibliothèque built-in
  9. Je ne le fais pas
  10. Je veux rentrer chez moi
 
tobesimple7 2024-09-20
  1. 4 espaces
  2. Sur la même ligne
  3. 100 caractères, espaces compris
  4. J’utilise à la fois camel et snake_case
  5. JetBrain
  6. d2code, dracula 12 ~ 13
  7. Sql
  8. Rien de particulier
  9. Ordre, par fonctionnalité
  10. C’est sympa
 
nutella 2024-09-19
  1. Tabulation
  2. Sur la même ligne
  3. 100
  4. À utiliser selon le langage
  5. vscode !
  6. Droid Sans Mono, 14pt
  7. Python !
  8. lint
  9. Je teste par fonctionnalité
  10. Je découvre plein de bonnes polices :)
 
erickim27 2024-09-18
  1. J’utilise uniquement des tabulations dans tous les langages.
  2. Pour les déclarations de fonction, je passe à la ligne ; pour les if ou les for, je mets un espace.
  3. Environ 50 caractères.
  4. En minuscules, en remplaçant les espaces par des _.
  5. Principalement VS Code, et vim quand c’est urgent.
  6. mesloLGS NF, 16 pt
  7. Si c’est simple, je pense d’abord à Python.
  8. Pas vraiment. En C, j’ai tendance à utiliser d’abord la bibliothèque standard.
  9. Je ne le fais pas.
  10. Étudier le noyau Linux / le low level est amusant, alors tout le monde devrait essayer au moins une fois.
 
overthinker 2024-09-17
  1. en C++, 4 espaces ; en JS, 2 espaces ; en Go, des tabulations
  2. en C++, à la ligne ; pour le reste, sur la même ligne, mais je préfère le lint propre à chaque langage.
  3. 80 caractères
  4. cela dépend du langage, mais en JS : camel_case ; en C++ : snake_case
  5. vscode
  6. Hack Nerd Font / taille 12 / graisse 450
  7. JS
  8. selon le lint ou par ordre alphabétique
  9. les tests unitaires, je les fais sur des unités fonctionnelles courtes.
  10. bon courage à tous.
 
siscof 2024-09-17
  1. 2 espaces
  2. Sur la même ligne
  3. 80 caractères (pour pouvoir mettre deux éditeurs côte à côte)
  4. Ça dépend du langage, mais je préfère le CamelCase
  5. neovim (AstroNVim) + tmux / IDEA Ultimate
  6. D2Coding / Hack Fira Code Nerd Font
  7. shell bash > js > kotlin
  8. Règles par défaut d'Intellij (je les utilise en les mettant dans editorconfig)
  9. J’écris des tests basés sur la logique métier, et pour l’UI je teste à la main...
  10. Avant, c’était pénible d’ajouter des plugins en vimscript et de tout modifier à mon goût, mais ces jours-ci il y a des choses comme AstroNVim avec une config de base déjà prête, et chaque IDE prend aussi bien en charge les simulateurs vim, donc essayez tous sans pression hehe
 
jjpark78 2024-09-16
  1. Deux espaces.
  2. Même ligne
  3. 100 caractères
  4. camelCase
  5. neovim, et doom emacs pour magit
  6. FiraCode
  7. nodejs
  8. À part la fonction de tri fournie par le LSP, je n’ai pas vraiment de règle particulière.
  9. J’utilise vitest, mais plutôt que l’approche idéale qui consiste à écrire les tests à l’avance avant de coder, je code d’abord puis je crée des tests unitaires ensuite pour éviter les effets de bord. Je m’en sers ensuite pour avoir l’esprit tranquille en sachant qu’une fonctionnalité déjà créée ne sera pas affectée par de nouvelles fonctionnalités ou des modifications ultérieures.
  10. Longue vie à GeekNews.
 
goinwater 2024-09-12
  1. Indentation à 2 espaces (j’écris avec des tabulations puis je les convertis automatiquement en espaces)
  2. Comme je suis développeur TS, j’ouvre l’accolade sur la même ligne (pour la famille C, c’est sur la ligne suivante)
  3. 100 caractères
  4. camelCase
  5. Cursor IDE
  6. Fira Code Nerd Font
  7. TypeScript
  8. Les bibliothèques tout en haut, puis les modules internes
  9. Surtout des modules communs
  10. J’aimerais bien maîtriser vim, mais je n’arrive pas à m’y habituer
 
regentag 2024-09-12
  1. 3 espaces (Ada), 4 espaces (les autres langages)
  2. Il n’y a pas d’accolades en Ada, mais begin s’écrit sur la ligne suivante. En PowerShell, on l’écrit sur la même ligne.
  3. 130 caractères
  4. SNAKE_CASE en majuscules
  5. Understand, Notepad++
  6. D2Coding
  7. PowerShell
  8. Sauf problème particulier, par ordre alphabétique.
  9. Je ne le fais pas.
  10. Bon courage !
 
roxie 2024-09-22

Vous utilisez encore Ada ? Waouh..
 
mhcoma 2024-09-12
  1. Caractères de tabulation sur 4 espaces
  2. Style K&R
  3. 120
  4. snake_case
  5. VS Code
  6. D2Coding 12pt
  7. Python, C
  8. Bibliothèque standard -> bibliothèque externe -> interne, tri par ordre alphabétique
  9. Non...
  10. Les caractères de tabulation sont divins.
 
codufdl 2024-09-11
  1. J’utilise space 2.
  2. Je commence à la suite sur la même ligne, et je mets la fermeture séparément. Ce qui suit après la fermeture reste sur la même ligne...
  3. J’utilise la taille adaptée à l’écran de la personne de l’équipe qui a la plus grande police. En ce moment, c’est 200.
  4. Je préfère le camelCase.
  5. En ce moment, VS Code est ce qui me convient le mieux.
  6. J’utilise D2Coding / 12.
  7. L’ordre est ecmascript > java > python.
  8. L’ordre est standard > third-party > internal.
  9. Sauf quand je modularise, j’utilise printf haha.
  10. Bon courage à tous !
 
hwhang0917 2024-09-11
  1. space4
  2. même ligne
  3. 80
  4. camelCase
  5. neovim
  6. FiraCode Nerd Font 18
  7. Go, TypeScript
  8. standard, third-party, internal
  9. À propos des utilitaires ou des modules communs
  10. Je vous souhaite de traverser cette année en toute sérénité.
 
iyeti 2024-09-11
  1. space4
  2. même ligne
  3. 120c
  4. camel
  5. VSCode
  6. Consolas 10
  7. Java, C++, Python
  8. tri automatique par ordre alphabétique
  9. en faisant attention à la gestion des exceptions et en restant au minimum
  10. Faites attention au COVID et à la grippe... Après l’avoir attrapé une fois, si votre endurance baisse, la récupération est vraiment lente...
 
semjei 2024-09-11
  1. 4 espaces
  2. Les classes et les interfaces à la ligne suivante, le reste sur la même ligne
  3. Aucune limite, actuellement 220
  4. Les noms de classes et les fonctions globales en camelCase, les fonctions internes et les variables en snake_case
  5. VS Code
  6. D2Coding
  7. C++, PHP
  8. Si possible, par fonctionnalité et par ordre alphabétique
  9. Uniquement les modules communs, pour le reste faites comme vous voulez
  10. Que tout se passe bien cette année aussi
 
nabitang 2024-09-11
  1. 4 espaces
  2. Sur la même ligne
  3. 120 caractères
  4. camelCase
  5. vscode
  6. Fira code
  7. javascript (typescript)
  8. third party, packages -> domain, entity -> use case -> services, adapters -> composants UI
  9. Jest, tester uniquement les use cases si nécessaire, le moins possible si possible
  10. Prenez bien soin de votre santé, vous tous :)
 
crazeidea 2024-09-11
  1. Tab / 4 espaces
  2. Sur la même ligne
  3. 140
  4. camelCase
  5. VSCode
  6. Ubuntu
  7. Typescript
  8. Rien de particulier, mais parfois je trie par ordre alphabétique
  9. Les modules très complexes sont testés
  10. Bon courage à tous
 
n1ghtc4t 2024-09-11
  1. J’étais partisan des tabulations, mais selon les cas je privilégie 4 espaces, et pour le HTML plutôt 2 ; ces derniers temps, avec tous ces mélanges, après tout peu importe.
  2. Je mets les accolades sur la même ligne, mais j’essaie autant que possible de respecter la convention de code existante.
  3. Quand j’étais plus jeune c’était 120, mais avec la presbytie qui arrive, je suis descendu jusqu’à 80.
  4. Je préfère le camelCase pour les noms de classes ou de modules, et le snake_case pour les variables.
  5. J’utilisais VSCode, mais récemment j’essaie de passer à Zed.
  6. Ces derniers temps, c’est CaskaydiaCove Nerd Font Mono.
  7. Au travail, Python ; pour les projets perso, Elixir ; et ce que j’aimerais essayer, c’est Rust.
  8. Je n’y fais pas particulièrement attention.
  9. En phase initiale ou en développement solo, j’écarte autant que possible les tests unitaires ; quand le nombre de collaborateurs augmente dans le projet et que des développeurs juniors arrivent, j’en écris sur le code critique... puis ils finissent laissés à l’abandon.
  10. J’aimerais gagner vite de l’argent, naviguer sur un voilier et faire un peu de code en loisir.
 
toaonly 2024-09-11
  1. Espaces, 2 caractères
  2. Sur la même ligne
  3. 80
  4. camelCase
  5. VSCode
  6. Consolas
  7. JavaScript, Rust
  8. Ordre alphabétique, puis chemin local
  9. Pour les modules de type util, j’en fais presque à 100 %, et pour la logique métier, je ne couvre que ce qui relève de « si ça ne marche pas, ça va vraiment très mal tourner » (faute de temps, on ne peut pas tout tester...)
  10. Courage à tous les développeurs et ingénieurs qui lisent GeekNews !
 
hhan8 2024-09-11
  1. Des espaces, en respectant les conventions. Pour mes projets perso, je préfère 2.
  2. Je les mets sur la même ligne.
  3. Environ 100, je pense.
  4. camelCase
  5. VSCode > Neovim > IntelliJ (je l’utilise à contrecœur uniquement pour le boulot en entreprise sur l’écosystème JVM)
  6. Police par défaut des réglages, 13 à 16 pt
  7. Javascript
  8. Je n’y prête pas particulièrement attention.
  9. J’ai tendance à implémenter dans un style BDD, en testant d’abord les cas que je veux couvrir, puis à compléter la couverture de tests à la fin.
  10. J’aimerais vraiment bien maîtriser NEOVIM, mais je finis toujours par utiliser le curseur. J’ai beaucoup de respect pour ceux qui le manient bien.
 
iolothebard 2024-09-11
  1. espace 4
  2. même ligne
  3. 120
  4. camelCase
  5. vim
  6. monoplex
  7. nodejs
  8. built-in, 3rd-party, les miens par ordre alphabétique
  9. absolument. Foncez !
  10. Ho eyo he hum !
 
wedding 2024-09-11
  1. Dépend du formateur. Espaces 4/2
  2. Dépend du formateur. Préférence pour l’inline
  3. Sans limite stricte. 80
  4. Sans limite stricte. Suit la convention
  5. VS Pro
  6. d2+nerd
  7. html
  8. Dépend du formateur
  9. Je ne sais pas vraiment rendre les tests unitaires élégants, je me contente plutôt de valider avec des données factices..
 
dbs0829 2024-09-11
  1. Indentation de 4 espaces
  2. Sur la même ligne
  3. 79
  4. Selon la convention
  5. neovim
  6. nerd hack font, taille par défaut de l’éditeur
  7. python ou c#
  8. Selon la convention
  9. Je ne crée des tests séparés que lorsqu’il existe des spécifications précises. Sinon, je développe en testant au fur et à mesure par moi-même.
 
a12341234 2024-09-11
  1. 2 espaces
  2. Sur la même ligne
  3. 1000+
  4. camelCase
  5. VSCode
  6. Police par défaut ou D2 Coding
  7. Dart
  8. Je suis le formateur par défaut
  9. Je ne fais pas de mocking et, autant que possible, je teste en me connectant au serveur de développement et à la base de données. Il semble y avoir davantage de problèmes liés au serveur...
 
iknowca 2024-09-11
  1. Tabulation de 4 espaces
  2. Sur la même ligne
  3. Je n’y fais pas attention.
  4. CamelCase
  5. vscode
  6. 14p, d2 coding
  7. python
  8. Rien de particulier.
  9. Je n’y arrive presque pas...
  10. J’aime bien ce genre de contenu participatif
 
savvykang 2024-09-10
  1. 2 espaces en TSX, 4 espaces pour le reste
  2. Sur la même ligne
  3. 80/120
  4. Le style recommandé par le langage
  5. VSCode, STS uniquement pour Java
  6. Monaco, Menlo, Consolas
  7. Python
  8. Bibliothèque standard, bibliothèque tierce, même projet
  9. Je ne fais des tests unitaires que pour ce qui peut être exécuté uniquement avec le système de fichiers et des objets d’entrée/sortie, sans nécessiter de système externe
  10. La question n°4 n’est-elle pas moins nécessaire ?
 
xguru 2024-09-10
  1. 2 espaces
  2. Sur la même ligne
  3. Comme je n’écris pas très large, j’ai l’impression de couper vers 80 caractères maximum.
  4. camelCase
  5. VS Code : je m’en sers non seulement pour le développement, mais aussi pour préparer les actualités que je publie sur GeekNews. C’est juste pratique.
  6. J’ai le même moniteur à la maison et au bureau, mais j’utilise des polices différentes.
  • Windows : JetBrains Mono, 14p
  • Mac : Menlo, 12p
  1. Avant, je préférais les applis desktop, donc Delphi (waouh, ça remonte à quand ça), et je gribouille aussi de petites pages web en PHP.
    En y repensant, de nos jours, selon ce que je veux créer, je cherche d’abord un framework de base, et s’il y en a un qui convient, je développe simplement dans ce langage.
    Il m’arrive aussi de développer avec des scripts dans Google Docs, de traiter ça avec des plugins sur WordPress, ou de récupérer des modules adaptés en Node/Python s’il y en a, donc c’est assez varié.
  2. Si ça devient vraiment nombreux, je les range un peu pour que ce soit plus lisible, sinon je n’y prête pas attention. (Le formateur s’en chargera bien.)
  3. Je ne le fais presque pas. Snif.
  4. Postez plein de bonnes questions sur Ask ! Faisons vivre Ask haha
 
jic5760 2024-09-10
  1. 4 espaces.
  2. Sur la même ligne
  3. Juste assez pour éviter l’apparition d’un défilement horizontal
  4. Cela dépend du langage (kotlin/go/java/typescript utilisent camelCase, c/c++ utilisent snake_case)
  5. Jetbrains
  6. La police par défaut de Jetbrains
  7. go ou kotlin
  8. En go, on distingue les imports externes et internes. À l’intérieur de chaque groupe, le tri se fait automatiquement.
  9. Principalement des unit tests + si plusieurs routines fonctionnent ensemble, je les teste séparément
  10. Merci pour ces bonnes questions :)
 
autumnal 2024-09-10
  1. Utilisation de tabulations, 4 espaces
  2. Respecter le style de code propre à chaque projet.
  3. Suffisamment lisible d’un seul coup d’œil (moins de 150 caractères)
  4. Respecter le style de code propre à chaque projet.
  5. vscode est le meilleur
  6. Consolas
  7. C++
  8. Sauf si une bibliothèque spécifique doit absolument être définie, importer dans l’ordre suivant : standard - dépendant du framework - personnalisé
  9. Effectuer des tests unitaires par fonctionnalité
  10. Je veux coder plus, et mieux. Si seulement j’avais plus de temps !
 
cjinzy 2024-09-10
  1. 4 espaces
  2. Si c’est court, sur la même ligne ; si ça risque de devenir long, sur une nouvelle ligne.
  3. J’essaie généralement de rester jusqu’à 150 caractères. J’essaie encore de réduire...
  4. J’utilisais le camelCase, mais récemment je suis en train de passer au snake_case.
  5. J’utilise souvent VS Code et Vim.
  6. Hack, Nerd Font ; pour la taille de police... j’ai tendance à l’ajuster selon la fatigue des yeux.
  7. Au final, c’est quand même Python que j’utilise le plus souvent.
  8. Je procède dans l’ordre suivant : modules intégrés, modules installables via des packages, puis modules que j’ai créés moi-même.
  9. Je ne fais que les choses importantes surtout... s’effondre...
  10. Passez une excellente journée :)
 
alstjr7375 2024-09-10
  1. espaces, 2 caractères
  2. Je préfère une nouvelle ligne, mais à cause des formatters, je l’écris souvent sur la même ligne
  3. Au maximum 80, 120 colonnes si c’est long
  4. Ma préférence va à kebab-case, mais à cause des limites de parsing ou de diverses conventions, je finis par utiliser camelCase T_T
  5. Emacs, ou récemment beaucoup Visual Studio Code à cause des plugins. Pour les choses simples, j’utilise Kate.
  6. Hack + D2Coding (fallback coréen)
  7. Typescript
  8. std, bibliothèque, module interne, répertoire courant
  9. J’aime les tests de type In-Source Test, faits dans le même fichier que l’implémentation.
  10. Je publierai bientôt un texte de présentation haha
    Je suis en train de créer un CSS in JS pour combiner Semantic CSS et Atomic CSS.
    https://github.com/mincho-js/mincho

Si vous faites partie du "camp mint choco", je vous serais reconnaissant de laisser une étoile... ?
 
goinwater 2024-09-12

C'est basé sur Vanilla Extract.
 
qyurila 2024-09-10
  1. Tabulations de 3 caractères (en pratique, seulement possible sur des projets persos..)
  2. Si c’est plus proche de JS, sur la même ligne ; si c’est plus proche de Java, sur une nouvelle ligne
  3. Si c’est plus proche de JS, 90 ; si c’est plus proche de Java, 120
  4. Les utiliser en respectant la convention
  5. VSCode (+ selon les cas, Zed et micro)
  6. JetBrains Mono + Gooroom Sans Code, 14
  7. La plupart du temps, je les fais dans le langage que j’avais justement envie d’apprendre à ce moment-là. Sinon, TS
  8. En général, plus c’est proche du built-in, plus j’importe en premier
  9. À partir du prochain projet, c’est sûr..
  10. J’ai du respect pour toutes les personnes qui travaillent déjà dans le métier
 
alstjr7375 2024-09-10

Trois espaces, c’est clairement un goût plutôt de niche, non ?
Il y a une raison pour laquelle vous les préférez ?
 
qyurila 2024-09-11

Je crois comprendre que, dans certaines langues (notamment HTML et JSX), si les tabulations de 4 espaces ne sont pas la norme, c’est parce qu’à mesure que l’imbrication s’approfondit, elles prennent trop de largeur inutilement, et c’est aussi mon ressenti.
Personnellement, cela dit, quand on utilise une indentation de 2 espaces, je trouve que la séparation est trop faible et qu’il devient très difficile de bien percevoir la hiérarchie. Je le ressentais déjà à mes débuts, et c’est toujours le cas aujourd’hui.

J’ai découvert l’indentation de 3 espaces il y a longtemps, dans une convention de code que j’avais dû utiliser en travaillant sur Lua.
Une fois un peu habitué… je me suis dit : et si c’était le sweet spot entre 2 et 4 espaces ? J’ai donc commencé à l’appliquer à d’autres langages, et pour la plupart des langages où 2 ou 4 espaces dominent, j’ai trouvé que la lisibilité était meilleure avec 3 espaces. Du coup, je continue à l’utiliser dès que c’est possible hehe.

En cherchant sur Google, on peut trouver un tout petit nombre d’articles (!) qui font la promo des tabulations de 3 espaces ; pour le fun, pourquoi ne pas en lire un ? 😄
 
alstjr7375 2024-09-11

À force de regarder, j’ai l’impression que mon cerveau finit par s’y habituer aussi hahaha
 
curioe 2024-09-11

Oh, c’est intéressant. La prochaine fois que je coderai un petit truc léger, je vais peut-être essayer d’utiliser 3 espaces. Merci.
 
neodasida 2024-09-10
  1. Tabulation, 2 espaces
  2. Sur la même ligne
  3. 320
  4. Camel case
  5. IntelliJ / vim
  6. Source Code Pro for powerline 14pt
  7. java / kotlin > javascript
  8. IntelliJ Auto Import ^^; dans le cas d’un langage de script, je distingue les modules internes et les modules externes.
  9. Ce serait bien de pouvoir tout tester en E2E, mais j’ai plutôt tendance à définir le périmètre jusqu’au niveau où la logique métier importante est vérifiée.
 
jaehong21 2024-09-10
  1. Tabulation
  2. Sur la même ligne ~
  3. Je suis surtout les réglages par défaut du linter et du formatter (sinon, jusqu’à ce que ça tienne sur un écran)
  4. Je suis la convention par défaut du langage, en général je préfère camelCase
  5. Neovim
  6. NerdFont
  7. Golang
  8. Imports dans l’ordre std, bibliothèques externes, puis modules internes, et à l’intérieur de chaque groupe triés par ordre alphabétique
  9. Seulement quand la logique est complexe, et encore seulement partiellement, dans un premier temps... (j’aimerais bien tout commenter, mais...)
 
bemong1 2024-09-10
  1. 4 espaces, tabulation
  2. Nouvelle ligne
  3. Ça dépend du contexte
  4. Pour C++, camelCase, pour le reste, snake_case
  5. vim, Visual Studio, VS Code
  6. Naver D2
  7. Pour prototyper rapidement, Python ; pour le reste, ça dépend de la nature du projet
  8. D'abord les bibliothèques au niveau système et OS, puis plus bas à mesure qu'on descend dans les couches
  9. Utilisation de gtest et pytest. Tests effectués régulièrement
  10. Je suis aussi curieux de voir comment les autres rédigent leur documentation de développement et quel style ils adoptent....
 
ganadist 2024-09-10
  1. Pour le shell, 2 espaces ; pour les Makefile, des tabulations ; pour le reste, 4 espaces
  2. Ça dépend de la convention du langage, mais si possible sur la même ligne
  3. 80 caractères pour les langages anciens, 100 pour les langages modernes (?)
  4. Je suis la convention du langage
  5. neovim, Android Studio, IntelliJ, et parfois vscode
  6. Si possible, la police à chasse fixe par défaut de l’OS
  7. Je réécris dans l’ordre shell -> Python -> Kotlin
  8. Ces temps-ci, les formatters et les linters s’en chargent tout seuls... (regard au loin)
  9. J’ai commencé à coder un peu puis j’ai laissé tomber... (s’effondre...)
  10. Rien n’est facile dans ce monde. Bouhou..
 
baeba 2024-09-10
  1. Tabulation, 4 espaces
  2. Commencer sur une nouvelle ligne
  3. Au cas par cas (environ 100 caractères)
  4. J’utilise un mélange de snake_case et de camelCase
  5. Notepad++ > UltraEdit (version 2001) > VS Code
  6. D2 Coding
  7. C/C++ > Java > JavaScript/CSS
  8. Au cas par cas
  9. J’ajoute un module qui écrit des logs dans le code et les enregistre dans un fichier. Je le fais simplement en même temps que le développement.
  10. C’est pour quand, la retraite ?
 
yshrust 2024-09-10
  1. 2 espaces
  2. sur la même ligne
  3. juste ce qu’il faut pour que ce soit agréable à lire
  4. En général, j’ai l’impression que chacun suit ce que beaucoup de gens utilisent dans son langage.
  5. Visual Studio
  6. Cascadia Code
  7. C#
  8. En gros, je les regroupe par ceux que j’utilise par défaut / ceux que j’ai créés / etc.
  9. Je me dis qu’il faudrait que je le fasse, qu’il faudrait que je le fasse..., mais au final je ne m’y mets pas vraiment..
  10. Gagner au loto, juste une fois..
 
curioe 2024-09-10
  1. Quatre espaces. J’ai une mauvaise vue, donc je préfère quand c’est bien grand.
  2. Sur la même ligne {
    }
  3. Je ne me limite pas strictement à un nombre de lignes, mais si ça ne tient pas dans une demi-fenêtre, j’ai tendance à découper.
  4. Ça dépend de chaque langage, mais j’utilise surtout le camelCase.
  5. VS Code
  6. Menlo, 16, mais la résolution est de 1920. Haha.
  7. En ce moment, pas vraiment. Ça change selon les périodes. Il y a une dizaine d’années, c’était Java, mais aujourd’hui je ne le regarde même plus, haha.
  8. J’importe dans l’ordre où j’en ai besoin, mais j’ai tendance à regrouper ce qui a le même rôle ou appartient à la même couche.
  9. Je ne lance que les tests des parties où la logique métier est importante, juste pour calmer mon anxiété. Je devrais me remettre en question...
  10. J’aimerais avoir une lifestyle business (une activité qui rapporte suffisamment pour me permettre de maintenir le mode de vie que je veux).