कोड formatting अनावश्यक होना चाहिए

 (maxleiter.com)
1 पॉइंट द्वारा GN⁺ 2025-09-09 | 4 टिप्पणियां | WhatsApp पर शेयर करें
  • अतीत में Ada development environment में code formatting की समस्या पहले ही हल की जा चुकी थी
  • डेवलपर DIANA intermediate representation (IR) के रूप में code के साथ काम करते थे, और हर कोई अपनी पसंद की pretty-printing settings के साथ उसे देखता था
  • आज भी linter या formatting policy जैसी चीज़ों के कारण बार-बार होने वाली अक्षमता और बहस मौजूद है
  • उस समय Rational R1000 workstation ने एक नवोन्मेषी development environment और सुविधाएँ प्रदान कीं
  • code formatting समस्या में एक पीढ़ी पहले के तरीके को देखकर आज की development practices में बदलाव के लिए विचार प्रस्तुत किया गया है

कोड formatting बहस – 1980 के दशक का समाधान

  • लेखक अपने हाई स्कूल के समय Ada compiler पर काम करने वाले computer science शिक्षक Mr. Paige के साथ हुए अनुभव का ज़िक्र करता है
  • 2016 में linter tool setup को लेकर असुविधा जताते हुए जब उसने पूछा, “हमें अब भी ऐसी समस्या क्यों झेलनी पड़ती है?”, तब उसे बताया गया कि यह समस्या 40 से अधिक साल पहले ही हल हो चुकी थी

Ada और DIANA का आगमन

  • Ada डेवलपर्स text source code को store करने के बजाय, DIANA(Descriptive Intermediate Attributed Notation for Ada) नामक intermediate representation का उपयोग करते थे
  • हर डेवलपर अपनी pretty-printing settings के साथ source को अपनी पसंद के तरीके से देख सकता था
  • formatting बहस या linter issues मौजूद नहीं थे, और editor में program tree को सीधे संशोधित किया जा सकता था (यह आधुनिक projectional editing के समान है)

Rational R1000 – अग्रणी development environment

  • Rational R1000 workstation में incremental compilation, static analysis, version control, debugging जैसी कई उन्नत सुविधाएँ अंतर्निहित थीं
  • इसका उपयोग DoD जैसे सरकारी प्रोजेक्ट, International Space Station (ISS), F-22 fighter jet जैसे महत्वपूर्ण software development में हुआ, और इसने UML के जन्म में भी योगदान दिया
  • Grady Booch के अनुसार, R1000 एक DIANA-आधारित machine थी जो source code को store नहीं करती थी, बल्कि केवल DIANA tree की pretty-printing का उपयोग करती थी

DIANA-आधारित development के लाभ

  • formatting बहस, linter setup, या editor environment को एक जैसा रखने की आवश्यकता नहीं थी
  • hardware acceleration के कारण incremental compilation, आसान refactoring, तेज integration जैसी चीज़ों के साथ एक नवोन्मेषी development experience मिलता था
  • इसने development efficiency और बड़े systems पर काम करने की क्षमता पर महत्वपूर्ण प्रभाव डाला

आज के लिए संकेत

  • hardware-accelerated compilation अब कम महत्वपूर्ण है, लेकिन formatting समस्या का समाधान अब भी अपर्याप्त है
  • मुख्यधारा का तरीका projectional editing या live environment नहीं है, लेकिन अतीत के दृष्टिकोण की तरह ज़्यादा दक्ष और कम विवाद वाले development practices को अपनाने पर विचार करने का समय है

संदर्भ सामग्री

  • लेखक ने इस विषय की जाँच करते समय R1000 से जुड़ी विभिन्न documents और technical reports का हवाला दिया है

संबंधित पढ़ाई

4 टिप्पणियां

 
ndrgrd 2025-09-10

मेरी जानकारी में, shared code को एक unified setting के ज़रिए अपने-आप format करने की सुविधा पहले से है, और कंपनियाँ भी इसका काफी इस्तेमाल करती हैं।
 
euphcat 2025-09-10

मुझे लगता है कि मुद्दा auto formatting नहीं है, बल्कि यह धारणा है कि कोई खास formatting श्रेष्ठ है, या फिर अपनी formatting छोड़कर किसी अनजान formatting के अनुरूप ढलने की प्रक्रिया ही अनावश्यक है। तर्क यह है कि formatting से बंधे बिना किसी intermediate representation को सहेज लिया जाए, और फिर user अपनी सुविधा के अनुसार उसे pretty-print कर सके।
 
ndrgrd 2025-09-10

मेरा कहना यह था कि automatic formatting के ज़रिए, बीच की किसी अभिव्यक्ति के बिना भी, मौजूदा भाषाओं में वही काम किया जा सकता है, लेकिन लगता है कि मेरी व्याख्या पर्याप्त नहीं थी।
 
GN⁺ 2025-09-09
Hacker News राय
  • मुझे समझ नहीं आता कि लोग linter settings को लेकर इतना क्यों परेशान होते हैं; यह साफ़ तौर पर बेकार की बहस है। बस किसी एक चीज़ पर फैसला करो, linter अपने-आप चलाओ और बात खत्म। मुझे लगता है कि असली software engineering के लिए समय ज़्यादा महत्वपूर्ण है। टीम कोई भी format तय कर ले, उसे इस्तेमाल करते-करते एक हफ़्ते में आदत पड़ जाती है।
    • यहाँ यह बताया गया है कि source code formatter और lint program अलग चीज़ें हैं। formatter सिर्फ code layout को ठीक करता है, जबकि linter code में संभावित bug या error ढूँढता है। कुछ tools दोनों काम करते हैं, लेकिन वह implementation detail है। lint क्या है, इसके लिए https://en.wikipedia.org/wiki/Lint_(software) देख सकते हैं।
    • मैं अपना ज़्यादातर समय code को "पढ़ने" में बिताता हूँ, और code layout का सीधा संबंध इस बात से है कि मैं code कितनी जल्दी पढ़ पाता हूँ। अलग layouts की आदत डाली जा सकती है, लेकिन हर layout एक जैसा पढ़ने में आसान नहीं होता। मैं code को visual patterns के रूप में याद रखता हूँ और layout के आधार पर उसे हिस्सों में बाँटकर पढ़ता हूँ। विडंबना यह है कि मुझे aphantasia है, यानी मैं मन की आँखों से चीज़ें visualize नहीं कर पाता, फिर भी visual cues से बेहतर याद रखता हूँ।
    • कुछ linter settings के स्पष्ट फायदे होते हैं। उदाहरण के लिए, table में trailing comma लगाने से आख़िरी line में नया item जोड़ते समय सिर्फ एक line edit करनी पड़ती है और diff भी आसान हो जाता है। इसलिए गलत चुनाव मेरी ज़िंदगी मुश्किल बना देता है। यही बात sorted list या include पर भी लागू होती है; अगर sort न करो, तो लोग हमेशा अंत में जोड़ते हैं और merge conflict बहुत होते हैं। जैसे auto formatter समय बचाता है, वैसे sorting से भी समय बचना चाहिए। और मैं inconsistent style को लेकर संवेदनशील हूँ। सबसे ज़रूरी है कि सिर्फ एक style पर एकरूपता रहे।
    • मुझे detailed options की उतनी परवाह नहीं, लेकिन common linter settings के साथ PR देखते समय बेकार का noise कम करना ज़रूरी लगता है। मुझे यह भी लगता है कि git और कई PL का line-based processing पर टिके होना बहुत elegant नहीं है। Ada language जैसी ज्यादा refined approach मैंने अपने 20 साल के करियर में सिर्फ एक बार देखी है। कुछ सचमुच elegant और efficient बनाना मुश्किल है, और जब पहले से काफी अच्छे alternatives मौजूद हों, तो उसका व्यापक रूप से फैलना और भी कठिन होता है।
    • मैं भी कम उम्र में इस बहस में फँसा था। वजह यह थी कि मुझे भ्रम था कि मैं टीम में सबसे स्मार्ट हूँ। मुझे लगता था कि मेरी राय सबसे ज़्यादा अहम है। मैं मानता था कि सबको मेरी बात सुननी चाहिए। लेकिन मैं गलत था।
  • यहाँ विचार करने वाला trade-off यह है कि अगर text के अलावा कोई और format इस्तेमाल करें, तो grep, diff, sed, version control जैसे generic tools की उपयोगिता घट जाती है। अंततः special tools, formats या IDE extensions पर निर्भरता बढ़ती है। Unix philosophy की ताकत plain text की composability में है। इस बहस को जल्दी काटने वाला एक सवाल है: अगर editor में सिर्फ whitespace width ही अपनी पसंद से सेट की जा सके, तो क्या tab पसंद करने वालों के पास और कोई तर्क बचेगा?
    • text-based approach के अपने फायदे हैं, लेकिन मुझे लगता है कि हम थोड़ा नीचे उतरकर एक और ऊँचे पहाड़, यानी projectional editing, तक जा सकते थे और नहीं जा पाए; हम अब भी नीचे ही भटक रहे हैं। दिए गए सारे उदाहरण structural information वाले code पर बेहतर काम करते हैं। उदाहरण के लिए, symbol search, जिसे मैं text grep से कहीं ज़्यादा इस्तेमाल करता हूँ, ast-grep से किया जा सकता है; diff के लिए semanticdiff.com जैसे tools structural moves या meaning-less changes को ignore कर सकते हैं। sed के विकल्प के रूप में @codemod/cli इस्तेमाल किया जा सकता है। version control में भी Unison जैसी languages पर non-semantic changes, जैसे order या whitespace, से होने वाले conflicts को अपने-आप टालने के लिए काफी प्रयोग हुए हैं।
    • यह विचार बार-बार सामने आता है, लेकिन एक साधारण formatter चलाने के बजाय बहुत जटिल tools की ज़रूरत पड़ती है, इसलिए लागत के मुकाबले लाभ खास नहीं है। हर developer का code को अपनी पसंद के अनुसार देख पाना वास्तव में बहुत मायने नहीं रखता। जिन भी teams के साथ मैंने काम किया, सबने मिलकर rules तय किए और formatter से उन्हें enforce किया। शुरुआत में असहमति हो सकती है, लेकिन जल्दी आदत पड़ जाती है। formatting पर बहस समय की बर्बादी का क्लासिक उदाहरण है।
    • grep, diff, sed, line-based merge जैसी चीज़ें वास्तव में code manipulation के लिए खराब tools हैं। इस बहस से बेहतर होगा कि हम बेहतर tools के बारे में सोचें।
    • अगर intermediate representation को text के रूप में रखा जाए, तो grep/diff/sed सभी काम कर सकते हैं। अगर सिर्फ AST-based formatter इस्तेमाल किया जाए, तो code किसी खास AST के अनुरूप normalized form में store होगा, editor AST parse करके उसे user की पसंद के format में दिखाएगा, और save करते समय फिर normalized form में बदल देगा।
    • पूरा operating system ऐसे ही source files पर निर्भर होकर बना है। Unix philosophy भी तभी सचमुच चमकती है जब सारे tools plain text को ध्यान में रखकर उसे parse कर सकें।
  • मुझे लगता है कि source code formatting में typographic तत्व भी स्पष्ट रूप से होते हैं। मैं इस दावे से सहमत नहीं कि यह पूरी तरह व्यक्तिगत पसंद का मामला है। कुछ formatting अर्थ और संरचना को प्रभावी ढंग से पहुँचाने का साधन होती है। अगर automation tools सिर्फ minimum tokens को serialize करके बाद में restore करें, तो यह मूल्य खो जाता है। https://naildrivin5.com/blog/2013/05/17/source-code-typograp...
    • print experts लंबे समय से tables और formulas में spacing और alignment के लिए बहुत मेहनत करते आए हैं। बाहरी लोगों को यह तुरंत महसूस नहीं होता, लेकिन यह बहुत महत्वपूर्ण रहा है। मुझे लगता है कि source code के लिए भी अधिक refined formatting में प्रगति संभव है।
    • उदाहरण के लिए, Python का black formatter SQLAlchemy queries को ज़रूरत से ज़्यादा कई lines में तोड़ देता है, जिससे readability उल्टे घट जाती है—ऐसी शिकायतें हैं।
    • मुझे हमेशा आश्चर्य होता है कि इतने लोग code की typography के महत्व को क्यों महसूस नहीं कर पाते।
    • typography की परवाह करते हुए भी, मुझे लगता है कि programming language conventions का बिना सोचे-समझे पालन करना सबसे गलत दिशा है। उदाहरण के लिए, लोग register जैसे शब्द खुशी से इस्तेमाल करते हैं, लेकिन pointers को asterisk (*) से दिखाने जैसी परंपराएँ भी हैं। notation की हर चीज़ अधिक intuitive और स्पष्ट हो सकती है, फिर भी हम अनावश्यक रूप से जटिल और कम पढ़ने योग्य तरीकों पर अड़े रहते हैं। symbols या reserved words को भी अधिक परिचित और natural terms से बदला जा सकता है, लेकिन हम पारंपरिक conventions से इतने चिपके रहते हैं कि readability की बलि दे देते हैं। उदाहरण के तौर पर, C code के strcpy function को भी अधिक स्पष्ट और पढ़ने योग्य शब्दों और syntax से पूरी तरह फिर से बनाया जा सकता है।
    • C में parameter declaration modifiers, data type और name से मिलकर बनती है—यह समझाने के बाद, char *argv[] जैसे उदाहरण से जटिल declarations की readability समस्या पर तंज कसा गया है। और C++ style formatting, जैसे char* a, b, भी गलतफ़हमी पैदा कर सकती है; इसलिए ऐसी style से बचना चाहिए।
  • मैं इस बहस के मूल premise से सहमत नहीं हूँ। code formatting बहुत महत्वपूर्ण communication tool है। अच्छी formatting इस बात का signal है कि developer (1) formatting के महत्व को समझता है, (2) rules का पालन अच्छी तरह करता है, (3) उसकी अच्छी taste है, और (4) exceptions में भी सही judgment रखता है। ये चारों बातें सिर्फ formatting से आगे जाकर developer की समग्र क्षमता को प्रभावित करने वाली महत्वपूर्ण skills हैं। लेकिन auto formatter या linter rules ऐसे signals को कमजोर कर देते हैं और Goodhart’s law की तरह मूल उद्देश्य को ही धुंधला कर देते हैं।
    • कहा गया है कि blog post छोटी और सरल है, इसलिए उसे सीधे पढ़ना चाहिए। सिर्फ title देखकर तुरंत विरोध न करें; should और unnecessary जैसे शब्दों का संदर्भ समझना बेहतर होगा।
    • जो लोग formatting की परवाह नहीं करते, उनके बारे में यह राय दी गई है कि या तो (1) उन्होंने कभी कई लोगों के साथ एक ही file edit नहीं की, (2) branch merge नहीं किया, (3) बड़े codebase की maintenance नहीं की, (4) बड़े refactoring का अनुभव नहीं लिया, (5) code history खोजने या diff/comparison tools इस्तेमाल करने का अनुभव नहीं है, (6) codebase automation tools बनाए नहीं हैं, या (7) वे collaboration mindset के बिना सिर्फ खुद पर ध्यान देने वाले हैं।
    • अगर उन सब बिंदुओं का जवाब 'नहीं' है, तो बस pass/commit के समय formatting automate कर दो, और अगर automation न गुज़रे तो CI error दे दे—इतना काफी है। बारीकियों पर अटकने से बेहतर है कि default अपनाया जाए और अपनी व्यक्तिगत style छोड़ दी जाए; यह भी एक फायदा है। default जैसा है वैसा रहने देने पर code देखने वाले हर व्यक्ति को वह परिचित लगता है। और formatting और linting अलग चीज़ें होते हुए भी, दोनों को automation tools से एक साथ संभाला जा सकता है।
    • इसी तरह का मूल्यांकन handwriting से भी सीखा जा सकता है—मज़ाक में जोड़ा गया कि अब से PR cursive handwriting में जमा करानी चाहिए।
    • "अच्छे formatting rules चुनने की taste" पर निर्भर रहना उल्टा बहस को जन्म देता है और समय बरबाद करता है। Go और Rust की तरह built-in formatter पर छोड़ देना बेहतर है।
  • code को syntax tree के आधार पर store करने और इंसान के देखने वाले code को उसके rendered रूप में संभालने की कोशिशें 20–25 साल पहले से होती रही हैं। यह 1990s में refactoring के लोकप्रिय होने के शुरुआती दौर से चला आ रहा रुझान है। Visual Age जैसे IDEs ने file system के बजाय database में code store करने का model अपनाया था। intentional programming और model-based development भी इसी cycle का हिस्सा थे। refactoring का सार AST transformation है; symbol name बदलना बहुत आसान हो जाता है और source code में manually ढूँढकर बदलने की ज़रूरत नहीं पड़ती। लेकिन लोग अब भी file editing के अभ्यस्त हैं, और structure को ही store करने वाले approach को mainstream बनाने में resistance और friction है। समय बीतने के बाद भी formatting की बहस का जारी रहना, इस alternative की ज़रूरत का संकेत भी है। language या editor level पर robust symbol rename तक ठीक से न दे पाने के उदाहरण आम हैं।
    • एक राय यह है कि यहाँ abstraction layers मिलाई जा रही हैं। AST को भी आखिर file में store होना पड़ता है, इसलिए human-readable files पर AST-aware tools चलाने से यह बहुत अलग नहीं है। storage format इतना महत्वपूर्ण नहीं; असली मुद्दा अधिक smart tools का है। उदाहरण के रूप में Microsoft का Roslyn और modern compilers का APIs के माध्यम से codebase के साथ interact करने की दिशा का ज़िक्र किया गया है।
  • यह भी सीधे उदाहरण देकर कहा गया है कि कुछ formatting सिर्फ AST से निकाली नहीं जा सकती। उदाहरण के लिए, अगर कई assignment statements हों, तो तीन lines को एक सीध में align करना, = के आधार पर align करना, या indentation बढ़ाकर structure की गहराई को उभारना—ये सब अलग-अलग choices हैं। अगर values पर ज़ोर देना हो तो numbers को right-align किया जा सकता है; अगर structure पर ज़ोर देना हो तो member variables को align करके readability बढ़ाई जा सकती है। लेखक code के किस पहलू पर ज़ोर देना चाहता है, यह अलग हो सकता है। तर्क यह है कि ऐसी जानकारी अतिरिक्त metadata के बिना AST से निकाली नहीं जा सकती।
    • बात समझ में आती है, लेकिन व्यवहार में लोग वास्तव में पहली दो ही विधियाँ इस्तेमाल करते हैं। असली उद्देश्य emphasis से ज़्यादा readability होता है। AST में बदलते समय कुछ चीज़ें खोती ज़रूर हैं, लेकिन इस स्तर पर मिलने वाला लाभ कहीं बड़ा है। और emphasis जैसी variations को AST में बनाए रखने के तरीके भी संभव हैं—उदाहरण के लिए setValue([bar, glob], 1) जैसा रूप, या style override के लिए comment syntax आदि।
    • 'वांछनीय code formatting' आखिरकार subjective ही है; उदाहरण की तरह, कोई 2/4/8 spaces पसंद कर सकता है, कोई column alignment। AST में source code की formatting information नहीं होती, इसलिए उसे अपने-आप derive नहीं किया जा सकता।
    • दूसरा और तीसरा formatting example वास्तव में structural design problems हैं, जैसे Law of Demeter का उल्लंघन, इसलिए वे formatting की श्रेणी में नहीं आते।
  • Projectional Editing को text source पर भी लागू किया जा सकता है। JetBrains MPS में code से table render करने वाला एक example video भी है: https://www.youtube.com/watch?v=XolJx4GfMmg&t=63s। IDE में dictionary को table के रूप में render करने की सुविधा की इच्छा व्यक्त की गई है। अभी भी code folding, inlay hints, HTML-rendered docstring जैसी कुछ मिलती-जुलती सुविधाएँ मौजूद हैं। https://x.com/efortis/status/1922427544470438381
  • यह परिभाषा दी गई है कि plain text से अधिक abstract किसी चीज़ को अभी तुरंत स्वीकार न कर पाना हमारी सीमा है। कोशिश करें तो भी आखिर में plain text projection तक downgrade हो जाता है। Morse Code से Unicode तक जमा हुई "विशाल lookup table (GLUT)" ने आज की symbolic decoding culture बनाई है। abstraction level बढ़ाने पर applications के लिए अधिक उपयुक्त symbol set बन सकता है, लेकिन उसके अनुरूप tools नहीं आते। आखिरकार उसे text transmission में बदलकर parse किया जाता है, जैसे CSV या Markdown। XML के लिए भी dedicated editors आते हैं, लेकिन लोग अंत में plain text में edit करना चाहते हैं। हालाँकि character encoding issues या special characters की वजह से यह पूरी तरह सकारात्मक भी नहीं है।
  • कभी-कभी यह सवाल उठता है कि stored artifact और हम जो code projection वास्तव में देखते हैं, वे एक जैसे क्यों होने चाहिए। अगर git diff भी IR (intermediate representation) projection के रूप में देखा जा सके तो अच्छा होगा। treesitter जैसे AST tools आने से यह कल्पना करना आसान हुआ है कि इंसान AST या IR को अधिक कुशलता से संभालने वाले interfaces इस्तेमाल कर सकते हैं। उदाहरण के तौर पर, f# की ordered compilation structure code review को सरल बनाती है। वहीं, जो languages या structures free ordering की अनुमति देते हैं, उनमें एक छोटा diff जाँचने के लिए भी कई जगह जाना पड़ता है और पूरे परिवर्तन का संदर्भ समझना झंझट भरा हो जाता है।
  • eslint-config-airbnb से जुड़ी असुविधा भी साझा की गई है। प्रतिनिधि issues: #1271, #1122। मौजूदा project पर airbnb config लागू करने की कोशिश में एक घंटे से ज़्यादा समय बर्बाद हुआ, जबकि code पहले से बिल्कुल सही था। अनावश्यक rules की वजह से यह गैर-उत्पादक लगा। अंत में सिर्फ उन rules को local में बंद कर दिया गया, और उसके बाद किसी project में इसे फिर कभी इस्तेमाल नहीं किया। यह उदाहरण दिखाता है कि गलत lint rules उत्पादकता को कितनी बुरी तरह नुकसान पहुँचा सकते हैं।