कोडिंग पर 10 सवाल, 10 जवाब करें?

1. Indent (दाएँ खिसकाव) के लिए tab इस्तेमाल करते हैं या space? कितने space रखते हैं?
2. Curly braces को नई line से शुरू करते हैं, या उसी line में आगे लिखते हैं?
3. एक line में कितने characters तक की अनुमति देते हैं?
4. Variable या function का नाम रखते समय आपकी पसंदीदा style क्या है? (उदाहरण: camelCase, snake_case)
5. आपका पसंदीदा editor कौन-सा है?
6. Coding font के लिए क्या इस्तेमाल करते हैं? Size क्या रखते हैं?
7. कुछ बनाते समय सबसे पहले किस programming language की ओर हाथ जाता है?
8. Module या library import करने के लिए कोई नियम या क्रम है क्या?
9. क्या आप unit test करते हैं? किस तरीके से करते हैं?
10. कुछ कहना हो / राय / शेखी / प्रचार / कुछ भी, लिखिए।

[aer0700]

1. 4 spaces
2. उसी लाइन में K&R style
3. अक्षरों की संख्या तय करने के बजाय context के हिसाब से आगे-पीछे करता हूँ।
   error handling जैसी चीज़ें जहाँ तक संभव हो एक ही लाइन में खत्म करता हूँ,
   बाकी logic को अलग-अलग बाँटकर लिखता हूँ।
4. निजी तौर पर मैं Snake को पसंद करता हूँ, लेकिन टीम में जैसा होता है वैसा ही फॉलो करता हूँ।
5. VS Code
6. VS Code का default font
7. C
8. सबसे पहले standard library को include करता हूँ। उसके बाद external library, फिर in-house library।
9. build करते समय unit test चलाता हूँ। अगर unit test में fail आता है, तो उसे ठीक करके फिर build... पास होने तक।
10. सर्दी-जुकाम से बचिए। कलाई का ध्यान रखिए। शराब सीमित मात्रा में पिएँ। डाइट करते हैं।

[bobcat]

1. space 2 या 4 spaces
2. Newline
3. 79-80 / 119-120
4. अगर PEP8 जैसी कोई convention है तो उसका पालन, नहीं तो CC.
5. VSCode
6. Consolas, 9pt
7. C
8. Stdlibs (stdlib) > Platform libs (Windows, unistd...) > essential library (project wide) > auxiliary library (module focused)
9. Unit test
10. ठंड है

[jwh926]

1. पर्सनल प्रोजेक्ट: टैब 4 कॉलम, कंपनी में: स्पेस 4 कॉलम
2. आजकल अगली लाइन में लिखता हूँ
3. 100
4. snake_case
5. VSCode
6. Iosevka 22px
7. Python
8. from keyword पहली प्राथमिकता, उसके बाद built-in library
9. नहीं करता
10. घर जाना चाहता हूँ

[tobesimple7]

1. 4 spaces
2. एक ही लाइन
3. स्पेस सहित 100 अक्षर
4. camel और snake_case दोनों इस्तेमाल करता हूँ
5. JetBrain
6. d2code, dracula 12 ~ 13
7. Sql
8. अलग से कुछ नहीं
9. क्रम, फ़ीचर के हिसाब से
10. मज़ेदार है

[nutella]

1. Tab
2. एक ही लाइन
3. 100
4. भाषा के अनुसार उपयोग
5. vscode!
6. Droid Sans Mono, 14pt
7. Python!
8. lint
9. फ़ीचर के हिसाब से टेस्ट करते हैं
10. बहुत से अच्छे फ़ॉन्ट्स के बारे में जानने को मिलता है :)

[erickim27]

1. मैं सभी भाषाओं में सिर्फ tabs इस्तेमाल करता हूँ.
2. function declaration के समय नई लाइन लेता हूँ, और if या for statement में spacing रखता हूँ.
3. लगभग 50 characters.
4. lowercase में लिखता हूँ, और spaces की जगह _ इस्तेमाल करता हूँ.
5. ज़्यादातर vscode, और जल्दी में हो तो vim इस्तेमाल करता हूँ.
6. mesloLGS NF, 16pt
7. अगर सरल हो तो पहले Python के बारे में सोचता हूँ.
8. ज़्यादा नहीं हैं. C language में हो तो standard library पहले इस्तेमाल करने की कोशिश करता हूँ.
9. नहीं करता.
10. Linux kernel / low level की पढ़ाई मज़ेदार है, आप सब भी एक बार ज़रूर आज़माइए.

[overthinker]

1. c++ में 4 spaces, js में 2 spaces, golang में tab
2. c++ में नई लाइन, बाकी same line पर, लेकिन मैं language-specific lint को prefer करता हूँ।
3. 80 अक्षर
4. हर language में अलग होता है, लेकिन js: camel_case c++: snake_case
5. vscode
6. Hack Nerd Font / 12 font size / weight 450
7. js
8. lint के हिसाब से या alphabet क्रम में
9. unit test छोटे functional units के लिए करता हूँ।
10. आप सबको शुभकामनाएँ।

[siscof]

1. 2 space
2. उसी लाइन में
3. 80 अक्षर (ताकि editor को आड़ा रखकर दो हिस्सों में रखा जा सके)
4. भाषा के अनुसार अलग होता है, लेकिन मैं CamelCase पसंद करता हूँ
5. neovim (AstroNVim) + tmux / IDEA Ultimate
6. D2Coding / hack fira code nerd font
7. bash shell > js > kotlin
8. Intellij के बेसिक नियम (उन्हें editorconfig बनाकर इस्तेमाल करता हूँ)
9. business logic आधारित test code लिखता हूँ और UI हाथ से...
10. पहले vimscript से plugin जोड़ना और उन्हें अपनी पसंद के मुताबिक बदलना काफ़ी मुश्किल था, लेकिन आजकल AstroNVim जैसे विकल्प भी हैं जिनमें basic settings पहले से होती हैं, और हर IDE में vim simulator का भी अच्छा support है, तो सब लोग हल्के-फुल्के तौर पर try करके देखें haha

[jjpark78]

1. 2 spaces.
2. वही लाइन
3. 100 अक्षर
4. camelCase
5. neovim, magit के लिए doom emacs
6. FiraCode
7. nodejs
8. LSP में सपोर्ट होने वाले sort फीचर के अलावा कोई खास नियम नहीं है।
9. मैं vitest इस्तेमाल करता हूँ, लेकिन coding से पहले पहले से test बना लेने वाले आदर्श usage की बजाय पहले code लिखता हूँ और बाद में side effects को रोकने के लिए unit test बना देता हूँ। उसके बाद, एक बार बनाया गया feature नए additions या नए बदलावों से प्रभावित नहीं होगा, इस मानसिक सुकून के लिए इसका इस्तेमाल करता हूँ।
10. GeekNews खूब फले-फूले.

[goinwater]

1. 2 स्पेस ( टैब में लिखता हूँ और उसे अपने-आप स्पेस में बदल देता हूँ )
2. मैं TS डेवलपर हूँ, इसलिए उसी लाइन में ( C-सीरीज़ के मामले में अगली लाइन )
3. 100 अक्षर
4. camelCase
5. Cursor IDE
6. Fira Code nerd font
7. Typescript
8. लाइब्रेरी सबसे ऊपर, उसके बाद internal module
9. मुख्य रूप से common module
10. vim अच्छी तरह इस्तेमाल करना चाहता हूँ, लेकिन इसकी आदत नहीं पड़ रही

[regentag]

1. 3 स्पेस (Ada), 4 स्पेस (बाकी भाषाएँ)
2. Ada में कर्ली ब्रेसेज़ नहीं होते, लेकिन begin अगली पंक्ति में लिखता हूँ। PowerShell में उसी पंक्ति में लिखता हूँ।
3. 130 अक्षर
4. बड़े अक्षरों में SNAKE_CASE
5. Understand, Notepad++
6. D2Coding
7. PowerShell
8. अगर कोई खास समस्या न हो, तो alphabet क्रम में।
9. नहीं करता।
10. शुभकामनाएँ!

[roxie]

क्या आप अभी भी Ada का इस्तेमाल करते हैं? वाह..

[mhcoma]

1. टैब कैरेक्टर 4 स्पेस
2. K&R Style
3. 120
4. snake_case
5. VS Code
6. D2Coding 12pt
7. Python, C
8. standard library -> external library -> internal, वर्णक्रमानुसार क्रमबद्ध
9. नहीं...
10. टैब कैरेक्टर भगवान है।

[codufdl]

1. मैं space 2 इस्तेमाल कर रहा/रही हूँ.
2. मैं उसी लाइन में आगे शुरू करता/करती हूँ, और closing अलग से अलग लिखता/लिखती हूँ. Closing के बाद जो आता है, वह उसी लाइन में...
3. टीम में जो सबसे बड़ा font size इस्तेमाल करते हैं, उनके screen size के हिसाब से लिखते हैं. अभी 200 है.
4. मैं camelCase पसंद करता/करती हूँ.
5. अभी के लिए vscode सुविधाजनक लगता है.
6. D2Coding / 12 इस्तेमाल कर रहा/रही हूँ.
7. ecmascript > java > python क्रम है.
8. standard > third-party > internal क्रम है.
9. मॉड्यूलराइज़ेशन करते समय छोड़कर, बाकी में printf इस्तेमाल करता/करती हूँ haha
10. आप सब हिम्मत बनाए रखें!

[hwhang0917]

1. space4
2. एक ही लाइन
3. 80
4. camelCase
5. neovim
6. FiraCode Nerd Font 18
7. Go, TypeScript
8. standard, third-party, internal
9. utility या common modules के बारे में
10. इस पूरे साल भी आप सुरक्षित और कुशल-मंगल रहें।

[iyeti]

1. space4
2. एक ही लाइन
3. 120c
4. camel
5. VSCode
6. Consolas 10
7. Java, C++, Python
8. ऑटो-सॉर्ट abc क्रम में
9. exception handling का ध्यान रखते हुए जितना हो सके न्यूनतम
10. कोरोना, इन्फ्लुएंजा से सावधान रहें... एक बार हो जाए और स्टैमिना गिर जाए तो सच में रिकवरी बहुत धीमी होती है...

[semjei]

1. स्पेस 4 कॉलम
2. क्लास और इंटरफेस अगली लाइन में, बाकी उसी लाइन में
3. कोई सीमा नहीं, अभी 220
4. क्लास नाम और global function camel, internal function और variable snake
5. VS Code
6. D2Coding
7. C++, PHP
8. संभव हो तो फीचर के हिसाब से alphabetically
9. सिर्फ common module, बाकी अपनी समझ से
10. यह साल भी सुरक्षित बीते

[nabitang]

1. 4 spaces
2. उसी लाइन में
3. 120 अक्षर
4. camelCase
5. vscode
6. Fira code
7. javascript (typescript)
8. third party, packages -> domain, entity -> use case -> services, adapters -> UI components
9. Jest, ज़रूरत हो तो सिर्फ use case टेस्ट करें, हो सके तो कम-से-कम
10. आप सभी अपना स्वास्थ्य अच्छे से संभालकर रखें :)

[crazeidea]

1. Tab / 4 स्पेस
2. उसी लाइन में
3. 140
4. camelCase
5. VSCode
6. Ubuntu
7. Typescript
8. खास कुछ नहीं, लेकिन कभी-कभी alphabet क्रम में sort करता हूँ
9. जिन modules की complexity ज़्यादा होती है, उनका test करता हूँ
10. आप सबको शुभकामनाएँ

[n1ghtc4t]

1. मैं tab का समर्थक रहा हूँ, लेकिन स्थिति के हिसाब से पहले 4 spaces, HTML में पहले 2 spaces, और हाल में तो सब कुछ उलझा हुआ है, तो ऐसा हो या वैसा क्या फ़र्क पड़ता है
2. उसी लाइन में जोड़ता हूँ, लेकिन जितना हो सके मौजूदा code convention के हिसाब से
3. बचपन में 120 था, लेकिन उम्र का असर आँखों पर आते-आते अब 80 तक नीचे आ गया है.
4. class या module नामों के लिए camel, variables के लिए snake पसंद है
5. VSCode इस्तेमाल करता था, हाल में Zed पर switch करने की कोशिश कर रहा हूँ
6. हाल में CaskaydiaCove Nerd Font Mono
7. काम में Python, personal project में Elixir, और जो करना चाहता हूँ वह Rust
8. इस पर खास ध्यान नहीं देता
9. शुरुआती चरण या solo development में unit test को जितना हो सके टालता हूँ, लेकिन project में collaboration करने वाले लोग बढ़ जाएँ और junior developers जुड़ें तो ज़रूरी code में unit test लिखता हूँ... फिर बाद में उन्हें छोड़ भी देता हूँ
10. जल्दी पैसे कमाकर sailing yacht पर घूमते हुए शौकिया coding करना चाहता हूँ.

[toaonly]

1. Space, 2 स्पेस इस्तेमाल
2. उसी लाइन में
3. 80
4. camelCase
5. VSCode
6. Consolas
7. JavaScript, Rust
8. पहले alphabet क्रम, उसके बाद local path
9. util जैसे मॉड्यूल्स के लिए लगभग 100% टेस्ट करता हूँ, और business logic में सिर्फ वही चीज़ें करता हूँ जिनके लिए लगता है "अगर यह फेल हुआ तो सच में बड़ी समस्या हो जाएगी" (समय की वजह से सब कुछ टेस्ट नहीं कर सकता...)
10. GeekNews पढ़ने वाले सभी डेवलपर्स और इंजीनियर्स को शुभकामनाएँ!

[hhan8]

1. Space, convention के अनुसार। व्यक्तिगत काम में मैं 2 को पसंद करता हूँ
2. उसी लाइन में लिखता हूँ
3. लगता है लगभग 100 के आसपास है
4. camelCase
5. VSCode > Neovim > IntelliJ (JVM-आधारित कंपनी के काम में ही मजबूरी में इस्तेमाल करता हूँ)
6. डिफ़ॉल्ट सेटिंग फ़ॉन्ट, 13~16pt
7. Javascript
8. मैं इस पर खास ध्यान नहीं देता।
9. मैं BDD स्टाइल में implement करना चाहने वाले cases पर केंद्रित होकर test करता हूँ, और आखिर में test coverage भरने की प्रवृत्ति रखता हूँ।
10. मैं NEOVIM को अच्छी तरह इस्तेमाल करना चाहता हूँ, लेकिन बार-बार cursor का ही इस्तेमाल करने लगता हूँ। जो लोग इसे अच्छी तरह इस्तेमाल करते हैं, उनका सम्मान करता हूँ।

[iolothebard]

1. space 4
2. एक ही पंक्ति
3. 120
4. camelCase
5. vim
6. monoplex
7. nodejs
8. built-in, 3rd-party, mine को alphabet order में
9. बिल्कुल। बस कर डालो!
10. Ho eyo he hum!

[wedding]

1. formatter पर निर्भर। स्पेस 4/2
2. formatter पर निर्भर। inline पसंद
3. कोई बंधन नहीं। 80
4. कोई बंधन नहीं। convention का पालन
5. vs pro
6. d2+nerd
7. html
8. formatter पर निर्भर
9. unit test को सुंदर बनाना नहीं आता, बस dummy data से verify करने जितना..

[dbs0829]

1. स्पेस 4
2. उसी लाइन में
3. 79
4. convention के अनुसार
5. neovim
6. nerd hack font, साइज़ editor डिफ़ॉल्ट
7. python or c#
8. convention के अनुसार
9. सिर्फ़ तब अलग से test code बनाता हूँ जब spec बिल्कुल स्पष्ट हो। बाकी मामलों में खुद test करते हुए develop करता हूँ.

[a12341234]

1. 2 spaces
2. एक ही लाइन
3. 1000+
4. camelCase
5. VSCode
6. डिफ़ॉल्ट फ़ॉन्ट या D2 Coding
7. Dart
8. डिफ़ॉल्ट Formatter का पालन करता हूँ
9. मॉकिंग नहीं करता, और जहाँ तक संभव हो dev server, DB से कनेक्ट करके टेस्ट करता हूँ। लगता है कि server से जुड़े issues ज़्यादा होते हैं, इसलिए...

[iknowca]

1. Tab 4 स्पेस
2. उसी लाइन में
3. परवाह नहीं करता।
4. camelCase
5. vscode
6. 14p, d2 coding
7. python
8. अलग से कुछ नहीं।
9. लगभग नहीं कर पाता...
10. इस तरह का participatory content अच्छा लगता है

[savvykang]

1. TSX में 2 spaces, बाकी में 4 spaces
2. उसी line में
3. 80/120
4. language में recommended style
5. VSCode, Java के लिए केवल STS
6. Monaco, Menlo, Consolas
7. Python
8. standard library, third-party library, same project
9. unit test सिर्फ उन्हीं चीज़ों के लिए करता/करती हूँ जिन्हें बिना external system की ज़रूरत के केवल file system और input/output objects से चलाया जा सके
10. क्या 4वें सवाल की ज़रूरत थोड़ी कम नहीं लगती?

[xguru]

1. 2 स्पेस
2. उसी लाइन में
3. ज़्यादा चौड़ाई में नहीं लिखता, इसलिए लगता है कि अधिकतम लगभग 80 characters पर लाइन तोड़ता हूँ।
4. camelCase
5. VS Code : सिर्फ development ही नहीं, GeekNews पर डालने वाली news को व्यवस्थित करने के लिए भी मैं यही इस्तेमाल करता हूँ। बस आरामदायक है।
6. मॉनिटर घर और ऑफिस में एक ही हैं, लेकिन fonts अलग-अलग इस्तेमाल करता हूँ।

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

7. पहले मैं desktop app को पसंद करता था, इसलिए Delphi (उफ़, ये कब की बात है) इस्तेमाल करता था, और छोटे web pages PHP में थोड़ा-बहुत लिख लेता था।
   लेकिन अब सोचता हूँ तो, आजकल क्या बनाना है उस पर निर्भर करके पहले थोड़ा framework देख लेता हूँ, और अगर कुछ उपयुक्त मिल जाए तो उसी language में development कर लेता हूँ।
   कभी Google Docs में script से development करता हूँ, कभी WordPress में plugin से काम संभालता हूँ, और Node/Python में कोई उपयुक्त module मिल जाए तो उसे भी ले आता हूँ, इसलिए काफ़ी विविधता है।
8. बहुत ज़्यादा हो जाए तो थोड़ा ठीक से व्यवस्थित कर लेता हूँ, बाकी में ज़्यादा ध्यान नहीं देता। (formatter संभाल लेगा)
9. ज़्यादा नहीं करता। हाय
10. Ask में अच्छे सवाल बहुत डालिए! चलिए Ask को सक्रिय बनाते हैं haha

[jic5760]

1. space. 4।
2. उसी लाइन में
3. इतना कि horizontal scroll न बने
4. हर भाषा में अलग (kotlin/go/java/typescript में camelCase, c/c++ में snake_case)
5. Jetbrains
6. Jetbrains का डिफ़ॉल्ट फ़ॉन्ट
7. go या kotlin
8. go में external/internal import को अलग किया जाता है। अलग किए गए हिस्सों के अंदर automatic sorting हो जाती है।
9. ज़्यादातर unit test + जब कई routines साथ चलती हैं, तो अलग से test
10. अच्छे सवाल के लिए धन्यवाद :)

[autumnal]

1. टैब इस्तेमाल, 4 स्पेस
2. प्रोजेक्ट के हिसाब से coding style का पालन।
3. एक नज़र में समझ आ जाए इतना (150 अक्षरों के भीतर)
4. प्रोजेक्ट के हिसाब से coding style का पालन।
5. vscode सबसे बढ़िया
6. Consolas
7. C++
8. अगर कोई ऐसी लाइब्रेरी नहीं है जिसे खास तौर पर तय करना ज़रूरी हो, तो import का क्रम standard - framework dependent - custom
9. फीचर के हिसाब से unit test चलाना
10. मैं और ज़्यादा, और बेहतर coding करना चाहता हूँ। काश समय और ज़्यादा होता!

[cjinzy]

1. 4 स्पेस
2. छोटा हो तो उसी लाइन में, और लंबा होने लगे तो नई लाइन में करता हूँ.
3. आमतौर पर 150 अक्षरों तक रखता हूँ. इसे और कम करने की कोशिश कर रहा हूँ...
4. पहले camelCase इस्तेमाल करता था, हाल में snake_case पर शिफ्ट कर रहा हूँ
5. VS Code और Vim अक्सर इस्तेमाल करता हूँ.
6. Hack, Nerd Font; फ़ॉन्ट साइज़... आँखों की थकान के हिसाब से बदलता रहता है
7. आखिरकार python ही सबसे ज़्यादा हाथ में आ जाता है
8. built-in module, package से install किए जा सकने वाले module, और फिर खुद बनाए module — इसी क्रम में करता हूँ.
9. सिर्फ़ ज़रूरी चीज़ों पर ही ध्यान देता हूँ....धम्म...
10. आपका दिन शुभ हो :)

[alstjr7375]

1. space, 2 स्पेस
2. नई लाइन को पसंद करता हूँ, लेकिन formatter की वजह से अक्सर उसी लाइन में लिखना पड़ता है
3. जितना हो सके 80, लंबा हो तो 120 कॉलम
4. पसंद तो kebab-case है, लेकिन parsing की सीमाओं या तरह-तरह के convention की वजह से camelCase इस्तेमाल करना पड़ता है T_T
5. Emacs, और हाल में plugins की वजह से Visual Studio Code ज़्यादा इस्तेमाल करता हूँ। सरल कामों के लिए Kate इस्तेमाल करता हूँ।
6. Hack + D2Coding(Hangul fallback)
7. Typescript
8. std, लाइब्रेरी, आंतरिक मॉड्यूल, वर्तमान डायरेक्टरी
9. In-Source Test यानी implementation वाली उसी फ़ाइल में किया जाने वाला Test पसंद है।
10. कुछ समय बाद परिचय पोस्ट जारी करूँगाhaha
    Semantic CSS और Atomic CSS को मिलाने के लिए CSS in JS बना रहा हूँ।
    https://github.com/mincho-js/mincho

"Minchodan" वाले लोग अगर स्टार दबा दें तो आभारी रहूँगा...?

[goinwater]

यह Vanilla Extract आधारित है।

[qyurila]

1. टैब कैरेक्टर 3 स्पेस (असल में यह लगभग सिर्फ़ पर्सनल प्रोजेक्ट में ही संभव है..)
2. अगर JS के करीब हो तो उसी लाइन में, अगर Java के करीब हो तो नई लाइन में
3. अगर JS के करीब हो तो 90, अगर Java के करीब हो तो 120
4. convention के मुताबिक इस्तेमाल
5. VSCode (+ स्थिति के हिसाब से Zed और micro भी)
6. JetBrains Mono + Gooroom Sans Code, 14
7. ज़्यादातर मैं उसी भाषा में बनाता हूँ जिसे उस समय सीखने का इरादा बना रखा होता है। नहीं तो TS
8. आम तौर पर built-in के जितना करीब हो, उतना पहले import
9. अगले प्रोजेक्ट से ज़रूर..
10. सभी working professionals का सम्मान करता हूँ

[alstjr7375]

लगता है कि 3 spaces वाकई काफ़ी niche पसंद है, है ना?
क्या इसकी कोई वजह है कि आप इसे पसंद करते हैं?

[qyurila]

मुझे लगता है कि कुछ भाषाओं में, खासकर HTML और JSX में, 4-space टैब मुख्यधारा में इसलिए नहीं है क्योंकि indentation गहरा होने पर वह बेवजह बहुत ज्यादा horizontal space घेर लेता है, और मुझे भी ऐसा ही महसूस होता है।
व्यक्तिगत रूप से, लेकिन 2-space टैब इस्तेमाल करूँ तो levels के बीच फर्क कम महसूस होता है, इसलिए hierarchy समझना मेरे लिए बहुत मुश्किल हो जाता है। शुरुआती दौर से ही मुझे ऐसा लगता था, और आज भी वैसा ही है।

3-space टैब से मेरा पहला परिचय तब हुआ था जब मुझे पहले Lua के साथ काम करना पड़ा था, और उस समय इस्तेमाल किए गए code convention में यह था।
थोड़ा अभ्यस्त होने के बाद लगा... क्या यह 2-space और 4-space टैब के बीच का sweet spot नहीं है? यही सोचकर मैंने इसे दूसरी भाषाओं में भी लागू करना शुरू किया, और मुझे लगा कि जिन भाषाओं में आमतौर पर 2-space या 4-space टैब चलते हैं, उनमें से ज़्यादातर 3-space टैब पर ज्यादा readable लगती हैं, इसलिए जहाँ भी संभव होता है, मैं आज तक इसे अपनाता हूँ haha

Google पर खोजने पर 3-space टैब का समर्थन करने वाले बहुत कम (!) लेख मिलते हैं, लेकिन मज़े के लिए क्या आप यह एक पढ़ना चाहेंगे? 😄

[alstjr7375]

देखते-देखते लगता है जैसे दिमाग इसकी आदत में ढल रहा है, हाहाहा

[curioe]

ओह, दिलचस्प है। अगली बार जब कुछ हल्का-फुल्का बनाऊँगा, तो शायद 3 स्पेस इस्तेमाल करके देखूँ। धन्यवाद।

[neodasida]

1. टैब, 2 स्पेस
2. उसी लाइन में
3. 320
4. camel
5. IntelliJ / vim
6. powerline के लिए Source Code Pro 14pt
7. java / kotlin > javascript
8. Intellij Auto Import ^^; स्क्रिप्ट भाषा के मामले में मैं इसे internal module और external module में अलग करता हूँ.
9. पूरे सिस्टम का E2E टेस्ट कर पाना अच्छा होगा, लेकिन मैं आमतौर पर scope को उस स्तर तक रखता हूँ जहाँ महत्वपूर्ण business logic verify हो सके.

[jaehong21]

1. Tab
2. उसी लाइन में ~
3. ज़्यादातर linter, formatter की default settings फ़ॉलो करता हूँ (या फिर, जितना एक स्क्रीन में दिखे)
4. भाषा के default convention फ़ॉलो करता हूँ, आमतौर पर camelCase पसंद है
5. Neovim
6. NerdFont
7. Golang
8. import को std, external library, internal module के क्रम में रखता हूँ, और उनके अंदर alphabet क्रम में sort करता हूँ
9. सिर्फ़ तब, जब logic complex हो, पहले आंशिक रूप से.... (सब पर लगाना चाहता हूँ, लेकिन...)

[bemong1]

1. 4 स्पेस, टैब
2. नई लाइन
3. स्थिति पर निर्भर
4. c++ में camelCase, बाकी में snake_case
5. vim, vs, vscode
6. Naver d2
7. जल्दी-जल्दी प्रोटोटाइप के लिए python, बाकी प्रोजेक्ट की प्रकृति पर निर्भर
8. पहले system, os लेवल की लाइब्रेरी, और जितना लोअर लेवल की ओर जाएँ उतना नीचे
9. gtest, pytest का उपयोग। समय-समय पर टेस्ट करते रहना
10. मैं यह भी जानना चाहता/चाहती हूँ कि दूसरे लोग डेवलपमेंट डॉक्यूमेंटेशन लिखने के तरीके या स्टाइल कैसे रखते हैं....

[ganadist]

1. shell में 2 spaces, Makefile में tab, बाकी सब में 4 spaces
2. language convention पर निर्भर करता है, हो सके तो उसी line में
3. पुराने language इस्तेमाल करते समय 80 characters, नए(?) language इस्तेमाल करते समय 100 characters
4. language convention का पालन
5. neovim, Android Studio, IntelliJ, कभी-कभी vscode
6. हो सके तो OS का default fixed-width font
7. shell -> Python -> Kotlin के क्रम में फिर से लिखकर देखा
8. आजकल formatter, linter अपने-आप कर देते हैं... (दूर देखते हुए)
9. थोड़ा-सा लिखकर छोड़ देता हूँ.. (धम्म से बैठ गया...)
10. दुनिया में कोई काम आसान नहीं है। सुबक सुबक..

[baeba]

1. Tab, 4 spaces
2. नई लाइन से शुरू
3. case by case (लगभग 100 अक्षर)
4. snake_case, camelCase मिलाकर इस्तेमाल करता/करती हूँ
5. Notepad++ > Ultraedit(2001 version) > VS Code
6. D2 Coding
7. C/C++ > Java > JavaScript/CSS
8. case by case
9. कोड में log डालने वाला मॉड्यूल जोड़कर फ़ाइल में सेव करता/करती हूँ। डेवलपमेंट करते हुए बस साथ में ही कर लेता/लेती हूँ.
10. रिटायर कब होऊँगा/होऊँगी?

[yshrust]

1. space 2 स्पेस
2. वही लाइन
3. बस इतना कि देखने में अच्छा लगे
4. आम तौर पर लगता है कि हर भाषा में लोग वही ज़्यादा इस्तेमाल करते हैं जो ज़्यादातर लोग इस्तेमाल करते हैं।
5. visual studio
6. cascadia-code
7. c#
8. लगता है मैं इसे बुनियादी तौर पर इस्तेमाल होने वाली चीज़ें / मेरी बनाई हुई चीज़ें / ,, इस तरह ग्रुप बनाकर इस्तेमाल करता हूँ।
9. करना तो है, करना तो है.. ऐसा सोचता ही रहता हूँ, लेकिन ठीक से कर नहीं पाता..
10. बस एक बार लॉटरी लग जाए ..

[curioe]

1. चार spaces। मेरी नज़र थोड़ी कमजोर है, इसलिए मुझे थोड़ा बड़ा-बड़ा अच्छा लगता है।
2. उसी line में {
   }
3. मैं इसे खास तौर पर count से सीमित नहीं करता, लेकिन अगर वह स्क्रीन के 1/2 हिस्से में नहीं आता, तो मैं उसे बाँट देता हूँ।
4. लगता है यह language पर निर्भर करता है, लेकिन मैं ज़्यादातर camelCase इस्तेमाल करता हूँ।
5. VS Code
6. Menlo, 16, लेकिन resolution 1920 है। haha
7. आजकल तो खास कोई नहीं लगता। हर बार अलग होता है। करीब 10 साल पहले Java था, लेकिन आजकल तो उसकी तरफ देखता भी नहीं हूँ haha
8. मैं imports ज़रूरत के क्रम में करता हूँ, लेकिन जिनका role या layer एक जैसा हो, उन्हें group कर देता हूँ।
9. सिर्फ़ वही चलाता हूँ जिनमें business logic महत्वपूर्ण हो, ताकि बस अपनी घबराहट थोड़ी शांत कर सकूँ। आत्मचिंतन...
10. मैं एक lifestyle business (ऐसा business जो अपनी मनचाही ज़िंदगी बनाए रखने लायक पैसे कमाकर दे) रखना चाहता हूँ।