Machen wir 10 Fragen und 10 Antworten zum Coden?

1. Verwendet ihr für die Einrückung Tabs oder Spaces? Mit wie vielen Leerzeichen rückt ihr ein?
2. Beginnen geschweifte Klammern bei euch in einer neuen Zeile oder schreibt ihr sie in derselben Zeile weiter?
3. Wie viele Zeichen pro Zeile erlaubt ihr?
4. Welchen Stil bevorzugt ihr bei Variablen- oder Funktionsnamen? (z. B. camelCase, snake_case)
5. Welchen Editor bevorzugt ihr?
6. Welche Schriftart nutzt ihr zum Coden? Und in welcher Größe?
7. Zu welcher Programmiersprache greift ihr als Erstes, wenn ihr etwas baut?
8. Habt ihr Regeln oder eine feste Reihenfolge für das Importieren von Modulen oder Bibliotheken?
9. Macht ihr Unit-Tests? Wie geht ihr dabei vor?
10. Schreibt gern alles, was ihr sagen möchtet – Meinung, Eigenlob, Werbung oder einfach irgendetwas.

[aer0700]

1. 4 Leerzeichen
2. K&R-Stil in derselben Zeile
3. Statt eine feste Zeichenanzahl vorzugeben, variiere ich je nach Kontext.
   Dinge wie Fehlerbehandlung versuche ich möglichst in einer Zeile zu beenden,
   andere Logik teile ich dagegen auf.
4. Persönlich bevorzuge ich snake_case, aber im Team halte ich mich an die dortige Vorgehensweise.
5. VS Code
6. Standardschriftart von VS Code
7. C
8. Zuerst include ich die Standardbibliothek. Danach externe Bibliotheken, dann interne Bibliotheken des Unternehmens.
9. Beim Build lasse ich Unit-Tests laufen. Wenn ein Unit-Test fehlschlägt, behebe ich das Problem und baue erneut ... bis alles durchläuft.
10. Passt auf, dass ihr euch nicht erkältet. Achtet auf eure Handgelenke. Trinkt Alkohol in Maßen. Lasst uns abnehmen.

[bobcat]

1. 2 oder 4 Leerzeichen
2. Newline
3. 79–80 / 119–120
4. Wenn es Konventionen wie PEP8 gibt, diese einhalten, ansonsten CC.
5. VSCode
6. Consolas, 9pt
7. C
8. Stdlibs (stdlib) > Platform libs (Windows, unistd...) > essenzielle Bibliothek (projektweit) > Hilfsbibliothek (modulbezogen)
9. Unit-Test
10. Mir ist kalt

[jwh926]

1. Persönliches Projekt: 4 Tabs, im Unternehmen: 4 Leerzeichen
2. In letzter Zeit schreibe ich es in die nächste Zeile
3. 100
4. snake_case
5. VSCode
6. Iosevka 22px
7. Python
8. Oberste Priorität hat das Schlüsselwort from, danach die Standardbibliothek
9. Mache ich nicht
10. Ich will nach Hause

[tobesimple7]

1. Vier Leerzeichen
2. In derselben Zeile
3. 100 Zeichen einschließlich Leerzeichen
4. camel und snake_case werden beide verwendet
5. JetBrain
6. d2code, dracula 12 ~ 13
7. SQL
8. Nichts Besonderes
9. Reihenfolge, nach Funktionen
10. Macht Spaß

[nutella]

1. Tab
2. dieselbe Zeile
3. 100
4. je nach Sprache verwenden
5. vscode!
6. Droid Sans Mono, 14pt
7. Python!
8. lint
9. Ich teste nach Funktionen getrennt
10. Ich lerne viele gute Schriftarten kennen :)

[erickim27]

1. Ich verwende in allen Sprachen nur Tabs.
2. Bei Funktionsdeklarationen kommt sie in eine neue Zeile, bei if- oder for-Anweisungen setze ich ein Leerzeichen.
3. Ungefähr 50 Zeichen.
4. Kleinbuchstaben, Leerzeichen ersetze ich durch _.
5. Meistens VS Code, wenn es eilig ist, nutze ich Vim.
6. mesloLGS NF, 16pt
7. Wenn es einfach ist, denke ich zuerst an Python.
8. Nicht wirklich. Wenn es um C geht, nutze ich eher zuerst die Standardbibliothek.
9. Mache ich nicht.
10. Das Studium des Linux-Kernels und von Low-Level-Themen macht Spaß, also probiert es alle mal aus.

[overthinker]

1. In C++ vier Leerzeichen, in JS zwei Leerzeichen, in Golang ein Tab
2. In C++ in einer neuen Zeile, der Rest in derselben Zeile, aber ich bevorzuge sprachspezifisches Linting.
3. 80 Zeichen
4. Je nach Sprache unterschiedlich, aber JS: camel_case, C++: snake_case
5. vscode
6. Hack Nerd Font / Schriftgröße 12 / Gewichtung 450
7. JS
8. Nach Linting oder alphabetischer Reihenfolge
9. Unit-Tests mache ich in kurzen funktionalen Einheiten.
10. Viel Erfolg euch allen.

[siscof]

1. 2 Leerzeichen
2. In derselben Zeile
3. 80 Zeichen (damit man zwei Editorfenster nebeneinander platzieren kann)
4. Hängt von der Sprache ab, aber ich bevorzuge CamelCase
5. neovim (AstroNVim) + tmux / IDEA Ultimate
6. D2Coding / Hack Fira Code Nerd Font
7. bash shell > js > kotlin
8. Die Standardregeln von IntelliJ (ich erstelle sie als editorconfig und nutze sie dann)
9. Ich schreibe Testcode auf Basis der Business-Logik, und die UI teste ich von Hand ...
10. Früher war es mühsam, Plugins mit vimscript hinzuzufügen und alles nach meinem Geschmack anzupassen, aber heutzutage gibt es Dinge wie AstroNVim, bei denen die Grundeinstellungen schon fertig sind, und viele IDEs unterstützen auch Vim-Simulatoren, also probiert es alle ruhig mal ganz entspannt aus hehe

[jjpark78]

1. 2 Leerzeichen.
2. gleiche Zeile
3. 100 Zeichen
4. camelCase
5. für neovim und magit Doom Emacs
6. FiraCode
7. nodejs
8. Außer der Sortierfunktion, die das LSP unterstützt, gibt es keine festen Regeln.
9. Ich nutze vitest, aber statt es idealerweise schon vor dem Coden anzulegen, schreibe ich erst den Code und erstelle die Unit-Tests später, um Side Effects zu verhindern. Danach nutze ich sie vor allem für die innere Ruhe, dass einmal erstellte Funktionen nicht durch neue Features oder weitere Änderungen beeinflusst werden.
10. Viel Erfolg für GeekNews.

[goinwater]

1. 2 Leerzeichen (mit Tab schreiben und automatisch in Leerzeichen umwandeln)
2. Als TS-Entwickler in derselben Zeile (bei C-artigen Sprachen in der nächsten Zeile)
3. 100 Zeichen
4. CamelCase
5. Cursor IDE
6. Fira Code Nerd Font
7. TypeScript
8. Bibliotheken ganz oben, interne Module danach
9. Vor allem gemeinsame Module
10. Ich würde gern gut mit vim umgehen können, aber ich gewöhne mich einfach nicht daran

[regentag]

1. 3 Leerzeichen (Ada), 4 Leerzeichen (alle anderen Sprachen)
2. Ada hat keine geschweiften Klammern, aber begin wird in die nächste Zeile geschrieben. In PowerShell steht es in derselben Zeile.
3. 130 Zeichen
4. Großgeschriebenes SNAKE_CASE
5. Understand, Notepad++
6. D2Coding
7. PowerShell
8. Wenn es keinen besonderen Grund gibt, dann alphabetisch.
9. Mache ich nicht.
10. Viel Erfolg!

[roxie]

Benutzen Sie immer noch Ada? Wow..

[mhcoma]

1. Tabulatorzeichen, 4 Leerzeichen
2. K&R-Stil
3. 120
4. snake_case
5. VS Code
6. D2Coding 12pt
7. Python, C
8. Standardbibliothek -> externe Bibliothek -> intern, alphabetisch sortiert
9. Nein...
10. Tabulatorzeichen sind göttlich.

[codufdl]

1. Ich nutze space 2.
2. Ich beginne in derselben Zeile weiter, und das Schließen schreibe ich separat. Was nach dem Schließen folgt, kommt in dieselbe Zeile ...
3. Im Team richten wir uns nach der Bildschirmgröße der Person mit der größten Schrift. Aktuell ist es 200.
4. Ich bevorzuge CamelCase.
5. Im Moment ist VS Code für mich am bequemsten.
6. Ich nutze D2Coding / 12.
7. Die Reihenfolge ist ecmascript > java > python.
8. Die Reihenfolge ist standard > third-party > internal.
9. Außer beim Modularisieren nutze ich printf, haha.
10. Viel Erfolg euch allen!

[hwhang0917]

1. space4
2. gleiche Zeile
3. 80
4. camelCase
5. neovim
6. FiraCode Nerd Font 18
7. Go, TypeScript
8. Standard, Third-Party, intern
9. Über Utilities oder gemeinsame Module
10. Ich wünsche Ihnen, dass Sie auch dieses Jahr gut und sicher überstehen.

[iyeti]

1. space4
2. gleiche Zeile
3. 120c
4. Camel Case
5. VSCode
6. Consolas 10
7. Java, C++, Python
8. automatische Sortierung in abc-Reihenfolge
9. mit Blick auf die Ausnahmebehandlung so minimal wie möglich
10. Passen Sie auf Corona und Influenza auf ... Wenn man sich einmal ansteckt und die Kondition nachlässt, dauert die Erholung wirklich lange ...

[semjei]

1. 4 Leerzeichen
2. Klassen und Interfaces in die nächste Zeile, alles andere in dieselbe Zeile
3. Unbegrenzt, derzeit 220
4. Klassennamen und globale Funktionen in CamelCase, interne Funktionen und Variablen in snake_case
5. VS Code
6. D2Coding
7. C++, PHP
8. Wenn möglich alphabetisch nach Funktion
9. Nur gemeinsame Module, den Rest nach Bedarf
10. Auch dieses Jahr gut überstanden

[nabitang]

1. 4 Leerzeichen
2. In derselben Zeile
3. 120 Zeichen
4. camelCase
5. vscode
6. Fira Code
7. JavaScript (TypeScript)
8. Third-Party, Packages -> Domain, Entity -> Use Case -> Services, Adapters -> UI-Komponenten
9. Jest, bei Bedarf nur Use Cases testen, wenn möglich so wenig wie nötig
10. Passt alle gut auf eure Gesundheit auf :)

[crazeidea]

1. Tab / 4 Leerzeichen
2. In derselben Zeile
3. 140
4. camelCase
5. VSCode
6. Ubuntu
7. Typescript
8. Nicht wirklich, aber manchmal Sortierung in alphabetischer Reihenfolge
9. Module mit hoher Komplexität werden getestet
10. Viel Erfolg an alle

[n1ghtc4t]

1. Früher war ich ein Tab-Verfechter, aber je nach Fall haben 4 Leerzeichen Vorrang, bei HTML eher 2, und in letzter Zeit denke ich mir: Wie auch immer, was soll's.
2. Ich setze sie in dieselbe Zeile, passe mich aber so weit wie möglich an die bestehende Code-Convention an.
3. Früher waren es 120, aber mit zunehmender Alterssichtigkeit bin ich mittlerweile bei 80 angekommen.
4. Für Klassen- oder Modulnamen bevorzuge ich Camel Case, für Variablen Snake Case.
5. Ich habe VSCode genutzt, versuche aber in letzter Zeit auf Zed umzusteigen.
6. In letzter Zeit: CaskaydiaCove Nerd Font Mono
7. Beruflich Python, für private Projekte Elixir, und ausprobieren möchte ich Rust.
8. Darauf achte ich nicht besonders.
9. In der Anfangsphase oder bei Solo-Entwicklung lasse ich Unit-Tests möglichst weg; wenn im Projekt mehr Leute zusammenarbeiten und Junior-Entwickler dazukommen, schreibe ich für wesentliche Teile Unit-Tests ... und lasse sie dann doch liegen.
10. Ich möchte schnell Geld verdienen, mit einer Segelyacht fahren und nur noch hobbymäßig coden.

[toaonly]

1. Leerzeichen, 2 Spaces verwenden
2. In derselben Zeile
3. 80
4. camelCase
5. VSCode
6. Consolas
7. JavaScript, Rust
8. Alphabetische Reihenfolge, danach lokaler Pfad
9. Bei Modulen mit util-Charakter decke ich fast 100 % ab, und bei Business-Logik nur die Fälle nach dem Motto „Wenn das nicht funktioniert, gibt es wirklich ein großes Problem“ (aus Zeitgründen kann man schließlich nicht alles testen...)
10. Viel Erfolg an alle Entwickler und Engineers, die GeekNews lesen!

[hhan8]

1. Leerzeichen, entsprechend der Konvention. Bei privaten Projekten bevorzuge ich 2.
2. Ich schreibe es in dieselbe Zeile.
3. Ich denke, es sind ungefähr 100.
4. camelCase
5. VSCode > Neovim > IntelliJ (bei der Arbeit in JVM-bezogenen Unternehmen notgedrungen nur dafür)
6. Standardschriftart in den Grundeinstellungen, 13–16 pt
7. JavaScript
8. Darauf achte ich nicht besonders.
9. Ich implementiere es meist im BDD-Stil, teste dabei vor allem die Fälle, die ich umsetzen möchte, und fülle zum Schluss die Testabdeckung auf.
10. Ich würde Neovim gerne richtig gut nutzen, aber ich greife ständig wieder zur Maus. Ich habe großen Respekt vor den Leuten, die es gut beherrschen.

[iolothebard]

1. Space 4
2. Gleiche Zeile
3. 120
4. camelCase
5. vim
6. monoplex
7. nodejs
8. built-in, 3rd-party, meins in alphabetischer Reihenfolge
9. Absolut. Mach es einfach!
10. Ho eyo he hum!

[wedding]

1. Hängt vom Formatter ab. 4/2 Leerzeichen
2. Hängt vom Formatter ab. Inline wird bevorzugt
3. Halb-halb. 80
4. Halb-halb. Folgt der Konvention
5. vs pro
6. d2+nerd
7. html
8. Hängt vom Formatter ab
9. Schöne Unit-Tests kann ich nicht schreiben, eher Verifizierung mit Dummy-Daten..

[dbs0829]

1. Vier Leerzeichen
2. In derselben Zeile
3. 79
4. Nach Konvention
5. neovim
6. nerd hack font, Größe ist der Standard des Editors
7. Python oder C#
8. Nach Konvention
9. Nur wenn es eine exakt definierte Spezifikation gibt, erstelle ich separat Testcode. Ansonsten entwickle ich, während ich selbst teste.

[a12341234]

1. 2 Leerzeichen
2. In derselben Zeile
3. 1000+
4. camelCase
5. VSCode
6. Standardschriftart oder D2 Coding
7. Dart
8. Ich folge dem Standard-Formatter
9. Ich verwende nach Möglichkeit kein Mocking, sondern teste angebunden an Entwicklungsserver und Datenbank. Es scheint mehr serverbezogene Probleme zu geben...

[iknowca]

1. 4 Leerzeichen für Tabs
2. In derselben Zeile
3. Ist mir egal.
4. CamelCase
5. VS Code
6. 14pt, D2Coding
7. Python
8. Nichts Besonderes.
9. Kann ich fast gar nicht ...
10. Solche mitmachorientierten Inhalte sind toll

[savvykang]

1. Bei TSX 2 Leerzeichen, sonst 4 Leerzeichen
2. In derselben Zeile
3. 80/120
4. Der vom Sprachstandard empfohlene Stil
5. VSCode, für Java ausschließlich STS
6. Monaco, Menlo, Consolas
7. Python
8. Standardbibliothek, Drittanbieterbibliothek, gleiches Projekt
9. Unit-Tests führe ich nur für Dinge durch, die sich ohne externe Systeme ausschließlich mit dem Dateisystem sowie Ein-/Ausgabeobjekten ausführen lassen
10. Hat Frage 4 nicht eher eine geringe Notwendigkeit?

[xguru]

1. 2 Leerzeichen
2. Dieselbe Zeile
3. Ich schreibe nicht zu breit und breche meist bei maximal etwa 80 Zeichen um.
4. camelCase
5. VS Code: Ich nutze es nicht nur für die Entwicklung, sondern auch zum Aufbereiten der Nachrichten, die ich auf GeekNews poste. Es ist einfach bequem.
6. Der Monitor ist zu Hause und im Büro derselbe, aber ich verwende unterschiedliche Schriftarten.

• Windows: JetBrains Mono, 14p
• Mac: Menlo, 12p

7. Früher habe ich Desktop-Apps bevorzugt und mit Delphi gearbeitet (wow, wie lange ist das her), kleinere Webseiten kritzele ich mit PHP zusammen.
   Wenn ich aber darüber nachdenke, schaue ich heutzutage je nachdem, was ich baue, erst nach einem passenden Standard-Framework, und wenn es etwas Geeignetes gibt, entwickle ich einfach in dieser Sprache.
   Ich entwickle auch mal per Skript in Google Docs, setze etwas als Plugin in WordPress um oder nutze passende Module für Node/Python, wenn es welche gibt – also ziemlich vielfältig.
8. Wenn es sehr viel wird, ordne ich es etwas übersichtlicher an, ansonsten kümmere ich mich nicht darum. (Der Formatter wird das schon richten.)
9. Mache ich kaum. Schluchz
10. Bitte stellt viele gute Fragen bei Ask! Lasst uns Ask aktiver machen haha

[jic5760]

1. 4 Leerzeichen.
2. In derselben Zeile
3. So weit, dass kein horizontaler Scrollbalken entsteht
4. Je nach Sprache unterschiedlich (kotlin/go/java/typescript verwenden camelCase, c/c++ verwenden snake_case)
5. Jetbrains
6. Die Standard-Schriftart von Jetbrains
7. go oder kotlin
8. In go werden externe und interne Imports getrennt. Innerhalb dieser Gruppen werden sie automatisch sortiert.
9. Meistens Unit-Tests + wenn mehrere Routinen zusammenlaufen, werden sie separat getestet
10. Vielen Dank für die gute Frage :)

[autumnal]

1. Tabs verwenden, 4 Leerzeichen
2. Den projektspezifischen Coding-Style einhalten.
3. So, dass man es auf einen Blick erfassen kann (innerhalb von 150 Zeichen)
4. Den projektspezifischen Coding-Style einhalten.
5. VSCode ist am besten
6. Consolas
7. C++
8. Wenn nicht ausdrücklich eine bestimmte Bibliothek vorgegeben ist, in der Reihenfolge Standard - Framework-abhängig - benutzerdefiniert importieren
9. Unit-Tests nach Funktion durchführen
10. Ich möchte noch mehr und noch besser programmieren. Wenn ich nur mehr Zeit hätte!

[cjinzy]

1. 4 Leerzeichen
2. Wenn es kurz ist, in derselben Zeile; wenn es länger zu werden scheint, in einer neuen Zeile.
3. Ich halte mich meist an bis zu 150 Zeichen. Ich versuche, es noch weiter zu verkürzen...
4. Ich habe camelCase verwendet, stelle aber in letzter Zeit auf snake_case um.
5. Ich benutze häufig VS Code und Vim.
6. Hack, Nerd Font – bei der Schriftgröße wechsle ich je nach Ermüdung der Augen hin und her.
7. Am Ende greife ich wohl am häufigsten zu Python.
8. Ich gehe in der Reihenfolge vor: eingebaute Module, Module, die sich als Paket installieren lassen, und dann selbst erstellte Module.
9. Ich mache nur die wichtigen Dinge zuerst ... plumps ...
10. Ich wünsche euch einen schönen Tag :)

[alstjr7375]

1. Leerzeichen, 2 Leerzeichen
2. Ich bevorzuge neue Zeilen, aber wegen der Formatter schreibe ich oft in dieselbe Zeile
3. Möglichst 80, wenn länger dann 120 Spalten
4. Mein Geschmack ist eigentlich kebab-case, aber wegen Parsing-Grenzen oder verschiedener Konventionen nutze ich dann doch camelCase T_T
5. Emacs, und in letzter Zeit wegen der Plugins oft Visual Studio Code. Für einfache Sachen nutze ich Kate.
6. Hack + D2Coding (koreanischer Fallback)
7. Typescript
8. std, Bibliotheken, interne Module, aktuelles Verzeichnis
9. Ich mag In-Source Tests, also Tests in derselben Datei wie die Implementierung.
10. Den Vorstellungstext werde ich bald veröffentlichen, hehe
    Ich arbeite gerade an einem CSS-in-JS, das Semantic CSS und Atomic CSS miteinander kombinieren soll.
    https://github.com/mincho-js/mincho

Wer zum "Mint-Choco-Lager" gehört, dem wäre ich dankbar für einen Star...?

[goinwater]

Basiert auf Vanilla Extract.

[qyurila]

1. Tabulatorbreite 3 Zeichen (praktisch nur in privaten Projekten möglich..)
2. Wenn es näher an JS ist, in derselben Zeile; wenn es näher an Java ist, in einer neuen Zeile
3. Wenn es näher an JS ist, 90; wenn es näher an Java ist, 120
4. Entsprechend der Konvention verwenden
5. VSCode (+ je nach Situation auch Zed und micro)
6. JetBrains Mono + Gooroom Sans Code, 14
7. Meistens erstelle ich es in der Sprache, die ich damals unbedingt lernen wollte. Sonst TS
8. In der Regel importiere ich zuerst, je näher etwas an Built-ins ist
9. Ab dem nächsten Projekt ganz bestimmt..
10. Ich habe großen Respekt vor allen, die bereits in dem Beruf arbeiten

[alstjr7375]

Drei Leerzeichen sind definitiv eher eine spezielle(?) Vorliebe.
Gibt es einen Grund, warum Sie das bevorzugen?

[qyurila]

Soweit ich weiß, liegt der Grund, warum bei manchen Sprachen (insbesondere HTML und JSX) eine Einrückung mit 4 Leerzeichen nicht der Mainstream ist, darin, dass bei tiefer Verschachtelung unnötig viel Breite verbraucht wird — und ich empfinde das genauso.
Persönlich finde ich aber, dass bei 2 Leerzeichen die Trennung zu schwach ist und man die Hierarchie viel zu schwer erkennen kann. So habe ich das schon seit meinen Anfängen empfunden, und daran hat sich bis heute nichts geändert.

Mit 3 Leerzeichen Einrückung bin ich zum ersten Mal in einer Code Convention in Berührung gekommen, als ich früher einmal mit Lua arbeiten musste.
Als ich mich etwas daran gewöhnt hatte, dachte ich mir: Ist das nicht der Sweet Spot zwischen 2 und 4 Leerzeichen? Deshalb habe ich angefangen, das auch auf andere Sprachen anzuwenden, und bei den meisten Sprachen, in denen 2 oder 4 Leerzeichen üblich sind, finde ich 3 Leerzeichen bis heute lesbarer — deshalb setze ich es, wenn möglich, immer noch ein.

Wenn man googelt, findet man eine winzige Zahl von Beiträgen (!), die für 3 Leerzeichen werben. Wie wäre es, wenn ihr euch aus Spaß mal diesen hier durchlest? 😄

[alstjr7375]

Wenn man sich das so anschaut, hat man fast das Gefühl, dass das Gehirn sich langsam daran gewöhnt, haha

[curioe]

Oh, interessant. Wenn ich das nächste Mal etwas Leichtes schreibe, probiere ich vielleicht mal 3 Leerzeichen aus. Danke.

[neodasida]

1. Tabs, 2 Leerzeichen
2. gleiche Zeile
3. 320
4. Camel Case
5. IntelliJ / vim
6. Source Code Pro for powerline 14pt
7. Java / Kotlin > JavaScript
8. IntelliJ Auto Import ^^; Bei Skriptsprachen unterscheide ich zwischen internen Modulen und externen Modulen.
9. Es wäre gut, alles E2E testen zu können, aber ich setze den Scope in der Regel so, dass zumindest die wichtigen Business-Logiken verifiziert werden.

[jaehong21]

1. Tabs
2. gleiche Zeile ~
3. Meistens folge ich den Standard-Einstellungen von Linter und Formatter (oder so weit, wie es auf einen Bildschirm passt)
4. Ich folge den Standard-Konventionen der Sprache, meist bevorzuge ich camelCase
5. Neovim
6. NerdFont
7. Golang
8. Imports in der Reihenfolge std, externe Bibliotheken, interne Module; innerhalb davon alphabetisch sortiert
9. Nur wenn die Logik komplex ist, erst einmal teilweise ... (Ich würde gern überall welche setzen, aber ...)

[bemong1]

1. 4 Leerzeichen, Tab
2. Neue Zeile
3. Kommt auf die Situation an
4. Bei C++ camelCase, sonst snake_case
5. vim, vs, vscode
6. Naver D2
7. Für schnelles Prototyping Python, ansonsten je nach Art des Projekts unterschiedlich
8. Zuerst Bibliotheken auf System- und OS-Ebene, und je tiefer die Ebene, desto weiter unten
9. Verwende gtest und pytest. Es wird laufend getestet
10. Mich würde auch interessieren, wie andere ihre Entwicklungsdokumentation schreiben und welchen Stil sie dabei verwenden....

[ganadist]

1. Shell: 2 Leerzeichen, Makefile: Tab, alles andere: 4 Leerzeichen
2. Hängt von den Sprachkonventionen ab, wenn möglich auf derselben Zeile
3. Bei älteren Sprachen 80 Zeichen, bei neueren(?) Sprachen 100 Zeichen
4. Folgt den Sprachkonventionen
5. neovim, Android Studio, IntelliJ, gelegentlich vscode
6. Wenn möglich die standardmäßige Monospace-Schrift des OS
7. In der Reihenfolge Shell -> Python -> Kotlin neu geschrieben
8. Heutzutage erledigen Formatter und Linter das von selbst... (starrt in die Ferne)
9. Ein bisschen daran geschrieben und dann liegen gelassen.. (sackt in sich zusammen...)
10. Auf der Welt gibt es keine leichten Dinge. schnief..

[baeba]

1. Tabs, 4 Leerzeichen
2. In einer neuen Zeile beginnen
3. Je nach Fall (etwa 100 Zeichen)
4. Ich verwende snake_case und camelCase gemischt
5. Notepad++ > Ultraedit (Version 2001) > VS Code
6. D2 Coding
7. C/C++ > Java > JavaScript/CSS
8. Je nach Fall
9. Ich füge ein Modul ein, das Logs in den Code schreibt, und speichere sie in einer Datei. Ich mache das einfach parallel zur Entwicklung mit.
10. Wann gehe ich in Rente?

[yshrust]

1. 2 Leerzeichen
2. in derselben Zeile
3. so, dass es gut aussieht
4. Ich glaube, meistens folgt man je nach Sprache dem, was viele Leute verwenden.
5. Visual Studio
6. Cascadia Code
7. C#
8. Ich glaube, ich gruppiere sie ungefähr in standardmäßig verwendete / selbst erstellte / so etwas in der Art.
9. Ich denke immer nur, ich sollte es machen, ich sollte es machen, aber irgendwie mache ich es dann doch nicht so richtig..
10. Nur ein einziges Mal im Lotto gewinnen ..

[curioe]

1. Vier Leerzeichen. Meine Augen sind nicht mehr die besten, deshalb mag ich es lieber etwas größer.
2. In derselben Zeile {
   }
3. Ich setze da nicht strikt eine Zeichenbegrenzung, aber wenn es nicht auf einen halben Bildschirm passt, teile ich es eher auf.
4. Das scheint je nach Sprache unterschiedlich zu sein, aber meistens verwende ich camelCase.
5. VS Code
6. Menlo, 16 – allerdings bei einer Auflösung von 1920. haha
7. Im Moment habe ich wohl keine bestimmte. Das ändert sich immer wieder. Vor etwa 10 Jahren war es Java, aber heute schaue ich es mir nicht einmal mehr an. haha
8. Ich importiere in der Reihenfolge, in der ich sie brauche, gruppiere aber Dinge mit derselben Rolle oder aus derselben Schicht.
9. Ich teste nur die wirklich wichtige Business-Logik, einfach um mein ungutes Gefühl etwas zu beruhigen. Muss ich selbstkritisch zugeben ...
10. Ich hätte gern ein Lifestyle-Business (ein Business, das genug Geld einbringt, um den Lebensstil zu finanzieren, den man selbst leben möchte).