स्लोक क्लॉक और कोड (एससीसी) कमांड लाइन टूल जो मैंने लिखा था , जिसे अब अंतिम रूप दिया गया है और कई महान लोगों द्वारा समर्थित किया गया है, कोड की लाइनों, टिप्पणियों को गिनता है, और एक निर्देशिका के अंदर फाइलों की जटिलता का मूल्यांकन करता है। यहां एक अच्छे चयन की जरूरत है। उपकरण कोड में शाखाओं वाले ऑपरेटरों को गिनता है। लेकिन जटिलता क्या है? उदाहरण के लिए, "इस फ़ाइल में कठिनाई 10 है" कथन संदर्भ के बिना बहुत उपयोगी नहीं है। इस समस्या को हल करने के लिए, मैं इंटरनेट पर सभी स्रोतों से भाग गया। यह आपको कुछ चरम मामलों को खोजने की भी अनुमति देगा, जिन्हें मैंने उपकरण में ही नहीं माना था। शक्तिशाली जानवर बल परीक्षण।

लेकिन अगर मैं दुनिया के सभी स्रोतों पर परीक्षण चलाने जा रहा हूं, तो इसके लिए बहुत सारे कंप्यूटिंग संसाधनों की आवश्यकता होगी, जो एक दिलचस्प अनुभव भी है। इसलिए, मैंने सब कुछ नीचे लिखने का फैसला किया - और यह लेख दिखाई दिया।

संक्षेप में, मैंने बहुत सारे स्रोतों को डाउनलोड और संसाधित किया।

नग्न आंकड़े:

• 9,985,051 कुल रिपोजिटरी
  
• कम से कम एक फ़ाइल के साथ 9,100,083 रिपॉजिटरी
  
• 884 968 खाली भंडार (बिना फाइलों के)
  
• सभी रिपॉजिटरी में अधिक से अधिक फ़ाइलें
  
• संसाधित 40 736 530 379 778 बाइट्स (40 टीबी)
  
• 1,086,723,618,560 पंक्तियों की पहचान की गई
  
• कोड मान्यता के साथ 816,822,273,469 लाइनें
  
• 124 382 152 510 खाली लाइनें
  
• १४५ ५१ ९ १ ९ २ ५ lines१ टिप्पणियाँ
  
• एससीसी नियमों के अनुसार कुल जटिलता: 71 884 867 919
  
• Scc में 2 नए कीड़े मिले

आइए सिर्फ एक विस्तार का उल्लेख करें। 10 मिलियन परियोजनाएं नहीं हैं, जैसा कि हाई-प्रोफाइल शीर्षक में संकेत दिया गया है। मैं 15,000 से चूक गया, इसलिए मैंने इसे राउंड किया। मैं इसके लिए माफी मांगता हूं।

सब कुछ डाउनलोड करने, एससीसी के माध्यम से जाने और सभी डेटा को बचाने में लगभग पांच सप्ताह लग गए। फिर 1 टीबी JSON को संसाधित करने और नीचे परिणाम प्राप्त करने के लिए 49 घंटे से थोड़ा अधिक।

यह भी ध्यान दें कि मुझे कुछ गणनाओं में गलत किया जा सकता है। यदि कोई त्रुटि पाई जाती है, तो मैं आपको तुरंत सूचित करूंगा और डेटासेट प्रदान करूंगा।

सामग्री की तालिका

• कार्यप्रणाली
  
• परिणामों की प्रस्तुति और गणना
  
• की लागत
  
• डेटा स्रोत
  
• रिपॉजिटरी में कितनी फाइलें हैं?
  
• भाषा का टूटना क्या है?
  
• भाषा द्वारा रिपॉजिटरी में कितनी फाइलें हैं?
  
• एक ठेठ भाषा फ़ाइल में कोड की कितनी लाइनें हैं?
  
• प्रत्येक भाषा में औसत फ़ाइल जटिलता?
  
• प्रत्येक भाषा में फ़ाइलों के लिए टिप्पणियों की औसत संख्या?
  
• सबसे आम फ़ाइल नाम क्या हैं?
  
• कितने रिपॉजिटरी एक लाइसेंस गुम कर रहे हैं?
  
• किन भाषाओं में सबसे अधिक टिप्पणियां हैं?
  
• कितनी परियोजनाएँ एकाधिक .gitignore फ़ाइलों का उपयोग करती हैं?
  
• कौन सी भाषा अधिक अश्लील भाषा है?
  
• प्रत्येक भाषा में लाइनों की संख्या से सबसे बड़ी फाइलें
  
• हर भाषा में सबसे जटिल फाइल कौन सी है?
  
• लाइनों की संख्या के बारे में सबसे जटिल फ़ाइल?
  
• प्रत्येक भाषा में सबसे अधिक टिप्पणी की जाने वाली फ़ाइल क्या है?
  
• कितने "स्वच्छ" प्रोजेक्ट हैं
  
• टाइपस्क्रिप्ट के साथ प्रोजेक्ट्स लेकिन जावास्क्रिप्ट नहीं
  
• क्या कोई कॉफ़ीस्क्रिप्ट और टाइपस्क्रिप्ट का उपयोग करता है?
  
• प्रत्येक भाषा में विशिष्ट पथ की लंबाई क्या है
  
• YAML या YML?
  
• ऊपरी, निचला, या मिश्रित मामला?
  
• जावा में कारखानों
  
• .Ignore फ़ाइलें
  
• भविष्य के लिए विचार
  
• यह सब क्यों है?
  
• असंसाधित / संसाधित फ़ाइलें

कार्यप्रणाली

Searchcode.com शुरू करने के बाद से , मैंने पहले ही git, mercurial, तोड़फोड़ और इतने पर 7,000,000 से अधिक परियोजनाओं का संग्रह जमा कर लिया है। तो क्यों नहीं उन्हें संसाधित करें? गिट के साथ काम करना आमतौर पर सबसे आसान उपाय है, इसलिए इस बार मैंने मर्क्यूरियल और तोड़फोड़ को नजरअंदाज किया और गिट परियोजनाओं की पूरी सूची तैयार की। यह पता चलता है कि मैंने वास्तव में 12 मिलियन गिट रिपॉजिटरी को ट्रैक किया था, और मुझे यह प्रतिबिंबित करने के लिए मुख्य पृष्ठ को ताज़ा करने की आवश्यकता है।

इसलिए अब मेरे पास डाउनलोड करने और प्रोसेस करने के लिए 12 मिलियन git रिपॉजिटरी हैं।

जब आप scc चलाते हैं, तो आप JSON में आउटपुट को फाइल को डिस्क में सेव करने के साथ चुन सकते हैं: scc --format json --output myfile.json main.go परिणाम इस प्रकार हैं (एक फ़ाइल के लिए):

 [ { "Blank": 115, "Bytes": 0, "Code": 423, "Comment": 30, "Complexity": 40, "Count": 1, "Files": [ { "Binary": false, "Blank": 115, "Bytes": 20396, "Callback": null, "Code": 423, "Comment": 30, "Complexity": 40, "Content": null, "Extension": "go", "Filename": "main.go", "Hash": null, "Language": "Go", "Lines": 568, "Location": "main.go", "PossibleLanguages": [ "Go" ], "WeightedComplexity": 0 } ], "Lines": 568, "Name": "Go", "WeightedComplexity": 0 } ] 

एक बड़े उदाहरण के लिए, रेडिस प्रोजेक्ट के लिए परिणाम देखें: redis.json । नीचे दिए गए सभी परिणाम बिना किसी अतिरिक्त डेटा के ऐसे परिणाम से प्राप्त होते हैं।

यह ध्यान में रखा जाना चाहिए कि scc आमतौर पर एक्सटेंशन के आधार पर भाषाओं को वर्गीकृत करता है (जब तक कि एक्सटेंशन आम नहीं है, जैसे कि Verilog और Coq)। इस प्रकार, यदि आप जावा एक्सटेंशन के साथ एक HTML फ़ाइल सहेजते हैं, तो इसे एक जावा फ़ाइल माना जाएगा। यह आमतौर पर एक समस्या नहीं है, क्योंकि ऐसा क्यों करते हैं? लेकिन, ज़ाहिर है, बड़े पैमाने पर, समस्या ध्यान देने योग्य हो जाती है। मुझे यह बाद में पता चला जब कुछ फ़ाइलों को एक अलग विस्तार के रूप में प्रच्छन्न किया गया था।

कुछ समय पहले मैंने scc-based github टैग बनाने के लिए कोड लिखा था। चूंकि परिणाम को कैश करने के लिए आवश्यक प्रक्रिया है, इसलिए मैंने उन्हें एडब्ल्यूएस एस 3 पर जेएसएन प्रारूप में कैश करने के लिए इसे थोड़ा बदल दिया।

लंबोदर पर एडब्ल्यूएस में लेबल के लिए कोड के साथ, मैंने परियोजनाओं की एक निर्यात सूची ली, मेरे लैंबडा से मिलान करने के लिए प्रारूप को साफ करने के लिए अजगर की लगभग 15 पंक्तियां लिखीं, और इसके लिए एक अनुरोध किया। अजगर मल्टीप्रोसेसिंग का उपयोग करते हुए, मैंने 32 प्रक्रियाओं के लिए अनुरोधों को समानांतर किया ताकि समापन बिंदु जल्दी से पर्याप्त रूप से जवाब दे सके।

सब कुछ शानदार ढंग से काम किया। हालाँकि, समस्या, सबसे पहले, लागत में, और दूसरी बात, लैम्ब्डा के पास एपीआई गेटवे / एएलबी के लिए 30 सेकंड का समय है, इसलिए यह बड़ी रिपोजिटरी को तेजी से संसाधित नहीं कर सकता है। मुझे पता था कि यह सबसे किफायती समाधान नहीं था, लेकिन मैंने सोचा था कि कीमत लगभग $ 100 होगी, जिसे मैं लगाऊंगा। एक मिलियन रिपोजिटरी प्रसंस्करण के बाद, मैंने जाँच की - और लागत लगभग $ 60 थी। चूंकि मैं $ 700 के अंतिम AWS खाते की संभावना से खुश नहीं था, इसलिए मैंने अपने फैसले पर पुनर्विचार करने का फैसला किया। ध्यान रखें कि यह मूल रूप से भंडारण और सीपीयू था जो इस सभी जानकारी को इकट्ठा करने के लिए उपयोग किया गया था। डेटा के किसी भी प्रसंस्करण और निर्यात ने कीमत में काफी वृद्धि की।

चूँकि मैं पहले से ही AWS पर था, एक त्वरित समाधान SQS में संदेशों के रूप में URL को छोड़ने और प्रसंस्करण के लिए EC2 या Fargate उदाहरणों का उपयोग करके उन्हें बाहर निकालना होगा। फिर पागलों की तरह पैमाने। लेकिन एडब्ल्यूएस के साथ रोजमर्रा के अनुभव के बावजूद, मैंने हमेशा टैको बेल प्रोग्रामिंग के सिद्धांतों में विश्वास किया है। इसके अलावा, केवल 12 मिलियन रिपॉजिटरी थे, इसलिए मैंने एक सरल (सस्ता) समाधान लागू करने का फैसला किया।

ऑस्ट्रेलिया में भयानक इंटरनेट के कारण स्थानीय रूप से गणना शुरू करना संभव नहीं था। हालाँकि, मेरा searchcode.com ध्यान से Hetzner के समर्पित सर्वरों का उपयोग करके काम करता है। ये काफी शक्तिशाली i7 क्वाड कोर 32 जीबी रैम मशीनें हैं, जिनमें अक्सर 2 टीबी स्टोरेज स्पेस (आमतौर पर इस्तेमाल नहीं किया जाता) होता है। उनके पास आमतौर पर कंप्यूटिंग शक्ति की अच्छी आपूर्ति होती है। उदाहरण के लिए, फ्रंट-एंड सर्वर ज्यादातर समय शून्य के वर्गमूल की गणना करता है। तो वहाँ प्रसंस्करण शुरू क्यों नहीं?

यह वास्तव में टैको बेल प्रोग्रामिंग नहीं है क्योंकि मैंने बैश और ग्नू उपकरण का उपयोग किया था। मैंने 32 पर गो -राईन चलाने के लिए गो पर एक सरल प्रोग्राम लिखा था जो S3 में JSON को आउटपुट लिखने से पहले एक चैनल से डेटा पढ़ता है, git और scc उपप्रोसेस उत्पन्न करता है। मैंने वास्तव में पहले पायथन में समाधान लिखा था, लेकिन मेरे स्वच्छ सर्वर पर पाइप निर्भरता स्थापित करने की आवश्यकता एक बुरे विचार की तरह लग रही थी, और सिस्टम अजीब तरीके से दुर्घटनाग्रस्त हो गया जिसे मैं डिबग नहीं करना चाहता था।

सर्वर पर यह सब चलाने से htop में निम्नलिखित मेट्रिक्स का उत्पादन होता है, और कई रनिंग git / scc प्रोसेस (scc इस स्क्रीनशॉट में दिखाई नहीं देता है) ने मान लिया कि सब कुछ उम्मीद के मुताबिक काम कर रहा था, जिसकी पुष्टि S3 के परिणामों से हुई।

परिणामों की प्रस्तुति और गणना

मैंने हाल ही में इन लेखों को पढ़ा है, इसलिए मुझे जानकारी के प्रस्तुतीकरण के संबंध में इन पदों के प्रारूप को उधार लेने का विचार था। हालाँकि, मैं परिणामों को क्रमबद्ध करने और खोजने / फ़िल्टर करने के लिए बड़ी तालिका में jQuery DataTables जोड़ना चाहता था। इस प्रकार, मूल लेख में, आप फ़िल्टर करने के लिए खोज फ़ील्ड को सॉर्ट करने और उपयोग करने के लिए शीर्षकों पर क्लिक कर सकते हैं।

संसाधित किए जाने वाले डेटा के आकार ने एक और प्रश्न उठाया है। 10 मिलियन JSON फ़ाइलों को कैसे संसाधित करें, S3 बाल्टी में डिस्क स्थान के 1 से अधिक टीबी पर कब्जा कर रहे हैं?

पहला विचार AWS एथेना था। लेकिन जब से इस तरह के डेटासेट के लिए यह $ 2.50 प्रति प्रश्न की लागत होगी, मैंने जल्दी से एक विकल्प की तलाश शुरू कर दी। हालांकि, यदि आप वहां डेटा सहेजते हैं और शायद ही कभी इसे संसाधित करते हैं, तो यह सबसे सस्ता समाधान हो सकता है।

मैंने कॉर्पोरेट चैट में एक प्रश्न पोस्ट किया (अकेले समस्याओं का समाधान क्यों)।

एक विचार डेटा को एक बड़े SQL डेटाबेस में डंप करने का था। हालाँकि, इसका अर्थ है डेटाबेस में डेटा को संसाधित करना, और फिर उस पर कई बार प्रश्नों का निष्पादन करना। साथ ही, डेटा संरचना का मतलब कई तालिकाओं से है, जिसका मतलब है कि प्रदर्शन की एक निश्चित स्तर प्रदान करने के लिए विदेशी कुंजी और अनुक्रमित। यह बेकार लगता है, क्योंकि हम डेटा को प्रोसेस कर सकते हैं क्योंकि हम इसे डिस्क से पढ़ते हैं - एक पास में। मैं इतने बड़े डेटाबेस को बनाने के लिए भी चिंतित था। केवल डेटा के साथ, यह इंडेक्स जोड़ने से पहले आकार में 1 टीबी से अधिक होगा।

यह देखते हुए कि मैंने JSON को एक सरल तरीके से कैसे बनाया, मैंने सोचा, क्यों न उसी तरह से परिणामों को संसाधित किया जाए? बेशक, एक समस्या है। S3 से 1 टीबी डेटा खींचने पर बहुत खर्च होगा। यदि प्रोग्राम क्रैश हो जाता है, तो यह कष्टप्रद होगा। लागत कम करने के लिए, मैं सभी फाइलों को स्थानीय रूप से निकालना चाहता था और उन्हें आगे की प्रक्रिया के लिए सहेजना चाहता था। अच्छी सलाह: एक निर्देशिका में कई छोटी फ़ाइलों को संग्रहीत न करना बेहतर है। यह रनटाइम प्रदर्शन के लिए बेकार है, और फ़ाइल सिस्टम को यह पसंद नहीं है।

इस पर मेरा उत्तर S3 से फ़ाइलों को खींचने के लिए एक और सरल गो कार्यक्रम था और फिर उन्हें टार फ़ाइल में सहेजना था। तब मैं इस फाइल को बार-बार प्रोसेस कर सकता था। टार फ़ाइल को संसाधित करने के लिए प्रक्रिया स्वयं एक बहुत ही बदसूरत गो कार्यक्रम चलाती है ताकि मैं S3 से बार-बार डेटा खींचने के बिना प्रश्नों को फिर से चला सकूं। मैंने दो कारणों से यहां गो-रूटीन से परेशान नहीं किया। सबसे पहले, मैं सर्वर को अधिक से अधिक लोड नहीं करना चाहता था, इसलिए मैंने सीपीयू को कड़ी मेहनत करने के लिए खुद को एक कोर तक सीमित कर दिया (दूसरे को ज्यादातर टार फाइल पढ़ने के लिए प्रोसेसर पर बंद कर दिया गया था)। दूसरे, मैं धागा सुरक्षा की गारंटी देना चाहता था।

जब यह किया गया था, तो उत्तर देने के लिए प्रश्नों का एक सेट आवश्यक था। मैंने फिर से सामूहिक दिमाग का इस्तेमाल किया और अपने सहयोगियों से जुड़ा, जबकि मैं अपने विचारों के साथ आया था। मन के इस विलय का परिणाम नीचे प्रस्तुत किया गया है।

आप JSON को संसाधित करने के लिए उपयोग किए जाने वाले सभी कोड पा सकते हैं, जिसमें स्थानीय प्रसंस्करण के लिए कोड भी शामिल है, और बदसूरत पायथन स्क्रिप्ट जो मैं इस लेख के लिए कुछ उपयोगी तैयार करता था: कृपया इस पर टिप्पणी न करें, मुझे पता है कि कोड बदसूरत है , और यह एक बार के कार्य के लिए लिखा गया है, क्योंकि मैं इसे फिर से देखने की संभावना नहीं है।

यदि आप उस कोड को देखना चाहते हैं जो मैंने सामान्य उपयोग के लिए लिखा था, तो scc स्रोतों को देखें ।

की लागत

मैंने लैम्बडा के साथ काम करने की कोशिश करते हुए कंप्यूटिंग पर लगभग $ 60 खर्च किए। मैंने अभी तक S3 को संग्रहीत करने की लागत को नहीं देखा है, लेकिन यह डेटा के आकार के आधार पर $ 25 के करीब होना चाहिए। हालांकि, इसमें ट्रांसमिशन लागत शामिल नहीं है, जिसे मैंने भी नहीं देखा था। कृपया ध्यान दें कि जब मैंने इसके साथ समाप्त किया तो मैंने बाल्टी को साफ किया, इसलिए यह एक निश्चित लागत नहीं है।

लेकिन थोड़ी देर बाद मैंने अभी भी AWS को छोड़ दिया। तो अगर मैं इसे फिर से करना चाहता हूं तो वास्तविक लागत क्या है?

हमारे पास जितने भी सॉफ्टवेयर हैं वो सब फ्री और फ्री हैं। इसलिए चिंता की कोई बात नहीं है।

मेरे मामले में, लागत शून्य होगी, क्योंकि मैंने searchcode.com से छोड़ी गई "मुक्त" कंप्यूटिंग शक्ति का उपयोग किया था। हालांकि, सभी के पास ऐसे नि: शुल्क संसाधन नहीं हैं। इसलिए, मान लें कि दूसरा व्यक्ति इसे दोहराना चाहता है और सर्वर को ऊपर उठाना होगा।

यह Hetzner के सबसे सस्ते नए समर्पित सर्वर का उपयोग करके € 73 के लिए किया जा सकता है, जिसमें एक नया सर्वर स्थापित करने की लागत भी शामिल है। यदि आप प्रतीक्षा करते हैं और नीलामी के साथ अनुभाग में तल्लीन हैं, तो आप अधिष्ठापन शुल्क के बिना बहुत सस्ता सर्वर पा सकते हैं। लेखन के समय, मुझे एक कार मिली, जो इस परियोजना के लिए एकदम सही है, स्थापना शुल्क के बिना € 25.21 प्रति माह।



क्या बेहतर है, यूरोपीय संघ के बाहर, वैट को इस मूल्य से हटा दिया जाएगा, इसलिए बेझिझक एक और 10% लें।

इसलिए, यदि आप मेरे सॉफ़्टवेयर पर खरोंच से ऐसी सेवा को उठाते हैं, तो अंततः $ 100 तक का खर्च आएगा, लेकिन यदि आप थोड़ा रोगी हैं या सफल हैं, तो $ 50 तक। यह मानता है कि आप सर्वर का उपयोग दो महीने से कम समय से कर रहे हैं, जो डाउनलोड करने और प्रसंस्करण के लिए पर्याप्त है। 10 मिलियन रिपॉजिटरी की सूची प्राप्त करने के लिए पर्याप्त समय भी है।

अगर मैंने ज़िप्ड टार (जो वास्तव में उतना मुश्किल नहीं है) का उपयोग किया है, तो मैं एक ही मशीन पर 10 गुना अधिक रिपोजिटरी की प्रक्रिया कर सकता हूं, और परिणामी फाइल अभी भी उसी एचडीडी पर फिट होने के लिए काफी छोटी रहेगी। हालांकि इस प्रक्रिया में कई महीने लग सकते हैं, क्योंकि डाउनलोड में अधिक समय लगेगा।

100 मिलियन रिपॉजिटरी से बहुत आगे जाने के लिए, हालांकि, किसी प्रकार की शार्डिंग की आवश्यकता होती है। फिर भी, यह कहना सुरक्षित है कि आप बिना किसी प्रयास या कोड परिवर्तन के समान उपकरण पर, मेरे पैमाने पर या बहुत बड़ी प्रक्रिया को दोहराएंगे।

डेटा स्रोत

यहाँ बताया गया है कि तीन स्रोतों में से कितने प्रोजेक्ट आए: जीथब, बिटबकेट और गिटलैब। ध्यान दें कि यह खाली रिपॉजिटरी को बाहर करने से पहले है, इसलिए, राशि उन रिपॉजिटरी की संख्या से अधिक है जो वास्तव में संसाधित होती हैं और निम्नलिखित तालिकाओं में ध्यान में रखी जाती हैं।


यदि आप इसे पढ़ते हैं तो मैं GitHub / Bitbucket / GitLab कर्मचारियों से माफी माँगता हूँ। यदि मेरी स्क्रिप्ट में कोई समस्या हुई (हालांकि मुझे संदेह है), तो मुझसे मिलते समय आपके पास आपकी पसंद का पेय है।

रिपॉजिटरी में कितनी फाइलें हैं?

चलिए असली मुद्दों पर चलते हैं। चलो एक साधारण से शुरू करते हैं। औसत रिपॉजिटरी में कितनी फाइलें हैं? ज्यादातर प्रोजेक्ट्स में केवल एक या दो से अधिक फाइलें होती हैं? रिपॉजिटरी के माध्यम से लूपिंग के बाद, हम निम्नलिखित अनुसूची प्राप्त करते हैं:



यहां, एक्स-एक्सिस फाइलों की संख्या के साथ बाल्टी दिखाता है, और वाई-एक्सिस कई फाइलों के साथ प्रोजेक्ट की संख्या को दर्शाता है। क्षैतिज अक्ष को एक हजार फाइलों तक सीमित करें, क्योंकि तब ग्राफ अक्ष के करीब है।

ऐसा लगता है कि अधिकांश रिपॉजिटरी में 200 से कम फाइलें हैं।

लेकिन 95 वें प्रतिशत तक दृश्य के बारे में क्या, जो वास्तविक तस्वीर दिखाएगा? यह पता चला है कि परियोजनाओं के विशाल बहुमत (95%) में - 1000 से कम फाइलें। जबकि 90% परियोजनाओं में 300 से कम फाइलें और 85% में 200 से कम हैं।



यदि आप स्वयं चार्ट बनाना चाहते हैं और मुझसे बेहतर करना चाहते हैं, तो यहां JSON में कच्चे डेटा का लिंक दिया गया है ।

भाषा का टूटना क्या है?

उदाहरण के लिए, यदि एक जावा फ़ाइल की पहचान की जाती है, तो हम एक-एक करके परियोजनाओं में जावा की संख्या बढ़ाते हैं, और हम दूसरी फ़ाइल के लिए कुछ भी नहीं करते हैं। यह एक त्वरित विचार देता है कि कौन सी भाषाएं सबसे अधिक उपयोग की जाती हैं। अप्रत्याशित रूप से, सबसे आम भाषाओं में मार्कडाउन, .ignignore और प्लेनटेक्स्ट शामिल हैं।

मार्कडाउन सबसे अधिक इस्तेमाल की जाने वाली भाषा है, इसे 6 मिलियन से अधिक परियोजनाओं में देखा जाता है, जो कुल का लगभग 2⁄3 है। यह समझ में आता है, क्योंकि लगभग सभी परियोजनाओं में README.md शामिल है जो HTML में रिपॉजिटरी पृष्ठों के लिए प्रदर्शित होता है।

भाषा द्वारा रिपॉजिटरी में कितनी फाइलें हैं?

पिछली तालिका में जोड़, लेकिन रिपॉजिटरी में प्रत्येक भाषा के लिए फ़ाइलों की संख्या से औसत। यही है, जहां जावा है, उन सभी परियोजनाओं के लिए औसतन कितनी जावा फाइलें मौजूद हैं?

एक ठेठ भाषा फ़ाइल में कोड की कितनी लाइनें हैं?

मुझे लगता है कि यह देखना अभी भी दिलचस्प है कि किन भाषाओं में औसतन सबसे बड़ी फाइलें हैं? अंकगणितीय माध्य का उपयोग करना sqlite.c जैसी परियोजनाओं के कारण असामान्य रूप से उच्च संख्या उत्पन्न करता है, जो कई रिपॉजिटरी में शामिल है, कई फ़ाइलों को एक में शामिल करता है, लेकिन कोई भी कभी भी इस एक बड़ी फ़ाइल पर काम नहीं करता है (मुझे उम्मीद है!)

इसलिए, मैंने औसत के औसत की गणना की। हालाँकि, बेबाक उच्च मूल्यों वाली भाषाएँ, जैसे बॉस्क और जावास्क्रिप्ट, अभी भी बनी हुई हैं।

तो मैंने सोचा, क्यों न एक नाइट की चाल बनाई जाए? के सुझाव पर डेरेल (डेटा से निवासी Kablamo और बेहतरीन विद्वान) मैं एक छोटा सा परिवर्तन किया और समांतर माध्य बदल गया है, और अधिक से अधिक 5000 लाइनों की फ़ाइलों फेंक, विसंगतियों को दूर करने के।

प्रत्येक भाषा में औसत फ़ाइल जटिलता?

प्रत्येक भाषा के लिए औसत फ़ाइल जटिलता क्या है?

वास्तव में, भाषाओं के बीच जटिलता की रेटिंग को सीधे संबद्ध नहीं किया जा सकता है। रीडमे से ही अंश scc:

जटिलता स्कोर केवल एक संख्या है जिसे केवल उसी भाषा में फ़ाइलों के बीच मिलान किया जा सकता है। इसका उपयोग सीधे भाषाओं की तुलना करने के लिए नहीं किया जाना चाहिए। कारण यह है कि प्रत्येक फ़ाइल के लिए शाखा और लूप ऑपरेटरों की तलाश करके इसकी गणना की जाती है।

इस प्रकार, भाषाओं की यहां एक दूसरे के साथ तुलना नहीं की जा सकती है, हालांकि यह जावा और सी जैसी समान भाषाओं के बीच किया जा सकता है, उदाहरण के लिए।

यह एक ही भाषा में व्यक्तिगत फ़ाइलों के लिए अधिक मूल्यवान मीट्रिक है। इस प्रकार, आप इस सवाल का जवाब दे सकते हैं कि "क्या यह फ़ाइल मैं औसत से आसान या कठिन काम कर रहा हूं?"

मुझे इस बात का उल्लेख करना होगा कि मैं इस मीट्रिक को scc में सुधार के सुझावों से खुश रहूँगा । एक कमिट के लिए, यह आमतौर पर भाषाओं में केवल कुछ कीवर्ड जोड़ने के लिए पर्याप्त होता है। फ़ाइल को किसी भी प्रोग्रामर की मदद कर सकते हैं।

प्रत्येक भाषा में फ़ाइलों के लिए टिप्पणियों की औसत संख्या?

प्रत्येक भाषा में फाइलों में टिप्पणियों की औसत संख्या क्या है?

शायद सवाल को फिर से परिभाषित किया जा सकता है: डेवलपर्स जिसमें भाषा सबसे अधिक टिप्पणियां लिखती है, पाठक की गलतफहमी का सुझाव देती है।

सबसे आम फ़ाइल नाम क्या हैं?

विस्तार और मामले की अनदेखी करते हुए सभी कोडबेस में कौन से फ़ाइल नाम सबसे आम हैं?

यदि आपने मुझसे पहले पूछा था, तो मैं कहूंगा: README, मुख्य, सूचकांक, लाइसेंस। परिणाम बहुत अच्छी तरह से मेरी मान्यताओं को दर्शाते हैं। हालांकि बहुत सी दिलचस्प बातें है। मुझे पता नहीं है कि इतने सारे प्रोजेक्ट में एक फाइल क्यों है 15या कहा जाता है s15।

सबसे आम मेकफाइल ने मुझे थोड़ा आश्चर्यचकित किया, लेकिन फिर मुझे याद आया कि इसका उपयोग कई नई जावास्क्रिप्ट परियोजनाओं में किया गया था। एक और दिलचस्प बात ध्यान दें: ऐसा लगता है कि jQuery अभी भी घोड़े पर है, और उसकी मौत की रिपोर्ट बहुत ही अतिरंजित है, और वह सूची में चौथे स्थान पर है।


कृपया ध्यान दें कि स्मृति सीमाओं के कारण, मैंने इस प्रक्रिया को थोड़ा कम सटीक बनाया। प्रत्येक 100 परियोजनाओं के बाद, मैंने मानचित्र की जाँच की और सूची से 10 गुना कम होने वाली फ़ाइलों के नाम हटा दिए। वे अगले परीक्षण में लौट सकते थे, और यदि वे 10 से अधिक बार मिले, तो वे सूची में बने रहे। शायद कुछ परिणामों में कुछ त्रुटि होती है यदि कुछ सामान्य नाम शायद ही कभी सामान्य होने से पहले रिपॉजिटरी के पहले बैच में दिखाई देते हैं। संक्षेप में, ये पूर्ण संख्या नहीं हैं, लेकिन इनके काफी करीब होना चाहिए।

मैं स्थान को "निचोड़ने" के लिए उपसर्ग वृक्ष का उपयोग कर सकता हूं और पूर्ण संख्या प्राप्त कर सकता हूं, लेकिन मैं इसे लिखना नहीं चाहता था, इसलिए मैंने मानचित्र को पर्याप्त मेमोरी बचाने और परिणाम प्राप्त करने के लिए थोड़ा दुरुपयोग किया। हालांकि, बाद में उपसर्ग पेड़ की कोशिश करना काफी दिलचस्प होगा।

कितने रिपॉजिटरी एक लाइसेंस गुम कर रहे हैं?

यह बहुत दिलचस्प है। कितने रिपॉजिटरी में कम से कम कुछ स्पष्ट लाइसेंस फ़ाइल है? कृपया ध्यान दें कि यहां लाइसेंस फ़ाइल की अनुपस्थिति का मतलब यह नहीं है कि परियोजना में यह नहीं है, क्योंकि यह README फ़ाइल में मौजूद हो सकता है या लाइनों में SPDX टिप्पणी टैग के माध्यम से इंगित किया जा सकता है। इसका सीधा सा मतलब है कि sccयह अपने स्वयं के मानदंड का उपयोग करके स्पष्ट लाइसेंस फ़ाइल नहीं पा सकता है। वर्तमान में, ऐसी फ़ाइलों को "लाइसेंस", "लाइसेंस", "कॉपी करना", "कॉपी करना", "नकल करना", "बिना लाइसेंस", "लाइसेंस-माइट", "लाइसेंस-माइट" या "कॉपीराइट" माना जाता है।

दुर्भाग्य से, विशाल भंडार के पास लाइसेंस नहीं है। मैं कहूंगा कि कई कारणों से किसी भी सॉफ़्टवेयर को लाइसेंस की आवश्यकता होती है, लेकिन किसी और ने मेरे लिए कहा ।

कितनी परियोजनाएँ एकाधिक .gitignore फ़ाइलों का उपयोग करती हैं?

कुछ को यह पता नहीं हो सकता है, लेकिन एक git प्रोजेक्ट में कई .gitignore फाइलें हो सकती हैं। इस बात को ध्यान में रखते हुए, कितनी परियोजनाएँ एकाधिक .gitignore फ़ाइलों का उपयोग करती हैं? और एक ही समय में, कितने में एक भी नहीं है?

मुझे 25,794 के साथ एक दिलचस्प परियोजना मिली। रिपोजिटरी में .ignignore फाइलें। अगला परिणाम 2547 था। मुझे नहीं पता कि वहां क्या चल रहा है। मैंने संक्षेप में देखा: ऐसा लगता है कि वे निर्देशिकाओं की जांच करने के लिए उपयोग किए जाते हैं, लेकिन मैं इसकी पुष्टि नहीं कर सकता।

डेटा पर लौटते हुए, यहां 20 .gitignore फ़ाइलों के साथ रिपॉजिटरी का एक ग्राफ है, जिसमें सभी परियोजनाओं का 99% शामिल है।



जैसा कि अपेक्षित था, अधिकांश परियोजनाओं में 0 या 1 .gitignore फाइलें होती हैं। 2 फाइलों वाली परियोजनाओं की संख्या में दस गुना की भारी गिरावट से इसकी पुष्टि होती है। मुझे आश्चर्य हुआ कि कितनी परियोजनाओं में एक से अधिक .gitignore फ़ाइल हैं। इस मामले में लंबी पूंछ विशेष रूप से लंबी है।

मैं उत्सुक था कि कुछ परियोजनाओं में ऐसी हजारों फाइलें क्यों हैं। मुख्य संकटमोचनों में से एक कांटा https://github.com/PhantomX/slackbuilds है : उनमें से प्रत्येक में लगभग 2547 .gitignore फाइलें हैं। हजार से अधिक .गितिग्नोर फाइलों के साथ अन्य रिपॉजिटरी नीचे सूचीबद्ध हैं।

• 25,794 फाइलें: https://github.com/knot-git/rrs_publication_ocr
  
• 1523 फाइलें: https://github.com/brunosimon/hetic
  
• 1267 फाइलें: https://github.com/par4all/par4all
  
• 1186 : https://github.com/ramonluis1987/code_school
  
• 1133 : https://github.com/signed/license-maven-plugin

?

यह खंड एक सटीक विज्ञान नहीं है, लेकिन प्राकृतिक भाषा प्रसंस्करण की समस्याओं के वर्ग के अंतर्गत आता है। फाइलों की एक विशिष्ट सूची में अपमानजनक या अपमानजनक शब्दों के लिए खोज करना कभी भी प्रभावी नहीं होगा। यदि आप एक सरल खोज के साथ खोज करते हैं, तो आपको कई सामान्य फाइलें मिलेंगी जैसे कि assemble.shऔर भी। इसलिए मैंने शापों की एक सूची ली और फिर जाँच की कि क्या प्रत्येक परियोजना की कोई भी फाइल इन में से किसी एक मान के बाद शुरू होती है। इसका मतलब है कि नाम वाली फ़ाइल gangbang.javaको ध्यान में रखा जाएगा, लेकिन assemble.shनहीं। हालांकि, वह कई अलग-अलग विकल्पों को याद करेंगे, जैसे कि pu55syg4rgle.javaअन्य समान रूप से असभ्य नाम।

मेरी सूची में कुछ दिलचस्प मामलों को पकड़ने के लिए लेट्सपेक पर कुछ शब्द हैं, जैसे कि b00bsऔर b1tch। पूरी सूची यहाँ।

हालांकि यह पूरी तरह से सही नहीं है, जैसा कि पहले ही उल्लेख किया गया है, यह परिणाम को देखने के लिए अविश्वसनीय रूप से दिलचस्प है। आइए उन भाषाओं की सूची से शुरू करें जिनमें सबसे अधिक शाप हैं। संभवतः, आपको प्रत्येक भाषा में कोड की कुल राशि के साथ परिणाम को सहसंबंधित करना चाहिए। तो यहां के नेता हैं।



दिलचस्प! मेरा पहला विचार था: "ओह, ये शरारती सी डेवलपर्स!" लेकिन बड़ी संख्या में ऐसी फ़ाइलों के बावजूद, वे इतना कोड लिखते हैं कि शाप का प्रतिशत कुल राशि में खो जाता है। हालाँकि, यह बहुत स्पष्ट है कि डार्ट डेवलपर्स के शस्त्रागार में कुछ शब्द हैं! यदि आप डार्ट प्रोग्रामर में से एक को जानते हैं, तो आप उसका हाथ हिला सकते हैं।

मैं यह भी जानना चाहता हूं कि सबसे ज्यादा इस्तेमाल होने वाले श्राप क्या हैं। आइए एक सामान्य गंदे सामूहिक दिमाग को देखें। कुछ सबसे अच्छे जो मुझे मिले वे सामान्य नाम थे (यदि आप स्क्विंट करते हैं), लेकिन अधिकांश अन्य निश्चित रूप से सहकर्मियों और पूल अनुरोधों में कुछ टिप्पणियों को आश्चर्यचकित करेंगे।



कृपया ध्यान दें कि सूची में कुछ अधिक आपत्तिजनक शब्दों में मिलान नाम थे, जो मुझे बहुत चौंकाने वाले लगे। सौभाग्य से, वे बहुत आम नहीं हैं और ऊपर की सूची में शामिल नहीं हैं, जो कि 100 से अधिक की संख्या के साथ फाइलों तक सीमित है। मुझे आशा है कि ये फाइलें केवल परीक्षण अनुमति / इनकार सूची और पसंद के लिए मौजूद हैं।

प्रत्येक भाषा में लाइनों की संख्या से सबसे बड़ी फाइलें

जैसा कि अपेक्षित था, प्लेनटेक्स्ट, SQL, XML, JSON, और CSV शीर्ष पदों पर काबिज हैं: वे आमतौर पर मेटाडेटा, डेटाबेस डंप और इसी तरह होते हैं।

नोट। फ़ाइलें बनाते समय कुछ अतिरिक्त जानकारी के कारण नीचे दिए गए कुछ लिंक काम नहीं कर सकते हैं। अधिकांश को काम करना चाहिए, लेकिन कुछ के लिए, आपको URL को थोड़ा संशोधित करने की आवश्यकता हो सकती है।

हर भाषा में सबसे जटिल फाइल कौन सी है?

एक बार फिर, ये मूल्य सीधे एक दूसरे के साथ तुलना करने योग्य नहीं हैं, लेकिन यह देखना दिलचस्प है कि हर भाषा में सबसे कठिन क्या माना जाता है।

इन फ़ाइलों में से कुछ पूर्ण राक्षस हैं। उदाहरण के लिए, मुझे मिली सबसे जटिल C ++ फ़ाइल पर विचार करें: COLLADASaxFWLColladaParserAutoGen15PStreetValidation.cpp : यह कंपाइलर नरक की 28.3 मेगाबाइट है (और, सौभाग्य से, यह स्वचालित रूप से उत्पन्न होता है)।

नोट। फ़ाइलें बनाते समय कुछ अतिरिक्त जानकारी के कारण नीचे दिए गए कुछ लिंक काम नहीं कर सकते हैं। अधिकांश को काम करना चाहिए, लेकिन कुछ के लिए, आपको URL को थोड़ा संशोधित करने की आवश्यकता हो सकती है।

लाइनों की संख्या के बारे में सबसे जटिल फ़ाइल?

यह सिद्धांत में अच्छा लगता है, लेकिन वास्तव में ... कुछ छोटा या बिना रेखा के टूटने से परिणाम विकृत हो जाते हैं, जिससे वे अर्थहीन हो जाते हैं। इसलिए, मैं गणना के परिणामों को प्रकाशित नहीं करता हूं। हालांकि, मैं बनाया एक टिकट में sccसमर्थन minification का पता लगाने गणना परिणाम से निकालने के लिए थे।

आप संभवतः उपलब्ध आंकड़ों के आधार पर कुछ निष्कर्ष निकाल सकते हैं, लेकिन मैं चाहता हूं कि सभी उपयोगकर्ता इस सुविधा से लाभान्वित हों scc।

प्रत्येक भाषा में सबसे अधिक टिप्पणी की जाने वाली फ़ाइल क्या है?

मुझे नहीं पता कि आप इससे कौन सी बहुमूल्य जानकारी निकाल सकते हैं, लेकिन यह देखना दिलचस्प है।

नोट। फ़ाइलें बनाते समय कुछ अतिरिक्त जानकारी के कारण नीचे दिए गए कुछ लिंक काम नहीं कर सकते हैं। अधिकांश को काम करना चाहिए, लेकिन कुछ के लिए, आपको URL को थोड़ा संशोधित करने की आवश्यकता हो सकती है।

कितने "स्वच्छ" प्रोजेक्ट हैं

परियोजनाओं के प्रकार में "शुद्ध" के तहत विशुद्ध रूप से एक भाषा में हैं। बेशक, यह अपने आप में बहुत दिलचस्प नहीं है, इसलिए आइए उन्हें संदर्भ में देखें। जैसा कि यह निकला, परियोजनाओं के विशाल बहुमत में 25 से कम भाषाएं हैं, और अधिकांश में दस से कम है।

नीचे दिए गए ग्राफ़ में शिखर चार भाषाओं में है।

बेशक, स्वच्छ परियोजनाओं में केवल एक प्रोग्रामिंग भाषा हो सकती है, लेकिन अन्य प्रारूपों के लिए समर्थन है, जैसे कि मार्कडाउन, json, yml, css, .itignore, जिन्हें ध्यान में रखा जाता है scc। संभवतः यह मान लेना उचित है कि पाँच से कम भाषाओं वाली कोई भी परियोजना "स्वच्छ" (स्वच्छता के कुछ स्तर के लिए) है, और यह कुल डेटासेट के आधे से अधिक है। बेशक, आपकी स्वच्छता की परिभाषा खान से भिन्न हो सकती है, इसलिए आप अपनी पसंद के किसी भी नंबर पर ध्यान केंद्रित कर सकते हैं।

मुझे आश्चर्य है कि लगभग 34-35 भाषाओं में एक अजीब उछाल है। मेरे पास इसकी कोई वाजिब व्याख्या नहीं है कि यह कहां से आया है, और यह संभवतः एक अलग जांच के योग्य है।

टाइपस्क्रिप्ट के साथ प्रोजेक्ट्स लेकिन जावास्क्रिप्ट नहीं

आह, टाइपस्क्रिप्ट की आधुनिक दुनिया। लेकिन टाइपस्क्रिप्ट परियोजनाओं के लिए, इस भाषा में कितने शुद्ध हैं?


मुझे स्वीकार करना चाहिए, मैं इस संख्या से थोड़ा हैरान हूं। हालांकि मैं समझता हूं कि जावास्क्रिप्ट को टाइपस्क्रिप्ट के साथ मिलाना काफी आम है, मुझे लगता है कि नई भाषा में अधिक परियोजनाएं होंगी। लेकिन यह संभव है कि रिपॉजिटरी का एक और हालिया सेट नाटकीय रूप से उनकी संख्या में वृद्धि करेगा।

क्या कोई कॉफ़ीस्क्रिप्ट और टाइपस्क्रिप्ट का उपयोग करता है?

मुझे लगता है कि कुछ टाइपस्क्रिप्ट डेवलपर्स इसके बारे में बहुत सोचकर बीमार हो जाते हैं। अगर यह उनकी मदद करता है, तो मैं यह मान सकता हूं कि इनमें से अधिकांश परियोजनाएं ऐसे कार्यक्रम हैं जो sccपरीक्षण उद्देश्यों के लिए सभी भाषाओं के उदाहरणों के साथ हैं।

प्रत्येक भाषा में विशिष्ट पथ की लंबाई क्या है

यह देखते हुए कि आप या तो सभी फाइलों को एक निर्देशिका में अपलोड कर सकते हैं या एक निर्देशिका प्रणाली बना सकते हैं, विशिष्ट पथ की लंबाई और निर्देशिकाओं की संख्या क्या है?

ऐसा करने के लिए, प्रत्येक फ़ाइल और औसत के लिए पथ में स्लैश की संख्या गिनें। मुझे नहीं पता था कि यहां क्या उम्मीद है, सिवाय इसके कि जावा सूची में सबसे ऊपर हो सकता है, क्योंकि आमतौर पर लंबे फ़ाइल पथ होते हैं।

YAML या YML?

स्लैक में एक बार "चर्चा" हुई - .yaml या .yml का उपयोग करना। दोनों ओर से कई मारे गए।

बहस अंततः (?) समाप्त हो सकती है। हालांकि मुझे संदेह है कि कुछ अभी भी विवाद में मरना पसंद करेंगे।

ऊपरी, निचला, या मिश्रित मामला?

फ़ाइल नामों के लिए किस रजिस्टर का उपयोग किया जाता है? चूंकि अभी भी एक विस्तार है, हम उम्मीद कर सकते हैं, मुख्य रूप से, एक मिश्रित मामला।


जो, ज़ाहिर है, बहुत दिलचस्प नहीं है, क्योंकि आमतौर पर फ़ाइल एक्सटेंशन लोअरकेस होते हैं। क्या होगा अगर एक्सटेंशन को अनदेखा करें?


मुझे उम्मीद नहीं थी। फिर से, ज्यादातर मिश्रित, लेकिन मैंने सोचा होगा कि नीचे अधिक लोकप्रिय होगा।

जावा में कारखानों

एक अन्य विचार जो कुछ पुराने जावा कोड को देखते समय सहकर्मियों के साथ आया था। मैंने सोचा, किसी भी जावा कोड के लिए चेक क्यों नहीं जोड़ा जाए जहां फैक्टरी, फैक्टरीफैक्ट्री, या फैक्ट्रीफैक्ट्रीफैक्ट्री शीर्षक में दिखाई देती है। इस तरह के कारखानों की संख्या का अनुमान लगाने का विचार है।


तो, जावा कोड का केवल 2% से अधिक फैक्ट्री या फैक्ट्रीफैक्टिक निकला। सौभाग्य से, कोई factoryfactoryfactory नहीं मिला। शायद यह मजाक अंत में मर जाएगा, हालांकि मुझे यकीन है कि कम से कम एक गंभीर तीसरे स्तर के पुनरावर्ती मल्टीफ़ंक्शन अभी भी कुछ प्रकार के जावा 5 मोनोलिथ में कहीं काम करते हैं, और यह हर दिन अधिक पैसा कमाता है जितना मैंने अपने पूरे करियर में देखा है। ।

.Ignore फ़ाइलें

हैकर न्यूज़ पर एक चर्चा में .tsore फाइलों का विचार burntsushi और ggreer द्वारा विकसित किया गया था । शायद यह "प्रतिस्पर्धी" ओपन सोर्स टूल्स का सबसे अच्छा उदाहरण है जो अच्छे परिणामों के साथ मिलकर काम करते हैं और रिकॉर्ड समय में पूरा होते हैं। यह कोड जोड़ने के लिए वास्तविक मानक बन गया है जो उपकरण की अनदेखी करेगा। sccभी .ign नियम को पूरा करता है, लेकिन यह भी जानता है कि उन्हें कैसे गिनना है। आइए देखें कि यह विचार कितना अच्छा फैला है।

भविष्य के लिए विचार

मैं भविष्य के लिए कुछ विश्लेषण करना पसंद करता हूं। AWS AKIA कुंजी और जैसी चीजों को स्कैन करना अच्छा होगा। मैं प्रत्येक के लिए विश्लेषण के साथ Bitbucket और Gitlab परियोजनाओं के कवरेज का विस्तार करना चाहूंगा, यह देखने के लिए कि क्या वहां अलग-अलग क्षेत्रों के विकास दल हो सकते हैं।

यदि मैं कभी भी इस परियोजना को दोहराता हूं, तो मैं निम्नलिखित कमियों को दूर करना चाहूंगा और निम्नलिखित विचारों को ध्यान में रखूंगा।

• कहीं मेटाडेटा में URL को सही तरीके से संग्रहीत करें। फ़ाइल नाम को संग्रहीत करने के लिए इसका उपयोग करना एक बुरा विचार था, क्योंकि जानकारी खो गई है और फ़ाइल के स्रोत और स्थान को निर्धारित करना मुश्किल हो सकता है।
  
• S3 से परेशान न हों। ट्रैफ़िक के लिए भुगतान करने के लिए यह बहुत कम समझ में आता है अगर मैं इसे केवल भंडारण के लिए उपयोग करता हूं। यह बहुत पहले से एक टार फ़ाइल में सब कुछ हथौड़ा करने के लिए बेहतर था।
  
• , .
  
• -n , , , .
  
• scc, , . , CIDE.C C, , HTML. .
  
• , scc, , , . .
  
• मैं चाहूँगा कि शेक का पता लगाने के लिए एक सीबीसी जोड़ना होगा ।
  
• किसी भी तरह गीथूब पर सितारों की संख्या और कमिट की संख्या पर विचार करना अच्छा होगा।
  
• मैं किसी भी तरह एक स्थिरता सूचकांक गणना जोड़ना चाहता हूं। यह देखना बहुत अच्छा होगा कि किन परियोजनाओं को उनके आकार के आधार पर सबसे अधिक मरम्मत योग्य माना जाता है।

यह सब क्यों है?

खैर, मैं इसमें से कुछ जानकारी ले सकता हूं और अपने सर्चकोड.कॉम ​​सर्च इंजन और प्रोग्राम में इसका इस्तेमाल कर सकता हूं scc। कम से कम कुछ उपयोगी डेटा बिंदु। प्रारंभ में, इस के लिए कई तरीकों से परियोजना की कल्पना की गई थी। इसके अलावा, अपनी परियोजना की दूसरों के साथ तुलना करना बहुत उपयोगी है। यह कुछ दिलचस्प समस्याओं को हल करने के लिए कई दिनों तक खर्च करने का एक दिलचस्प तरीका भी था। और एक अच्छी विश्वसनीयता की जाँच करें scc।

इसके अलावा, मैं वर्तमान में एक ऐसे टूल पर काम कर रहा हूं जो प्रमुख डेवलपर्स या प्रबंधकों को कोड का विश्लेषण करने में मदद करता है, विशिष्ट भाषाओं की खोज, बड़ी फाइलें, खामियां, आदि ... इस धारणा के साथ कि आपको कई रिपॉजिटरी का विश्लेषण करने की आवश्यकता है। आप किसी प्रकार का कोड दर्ज करते हैं, और टूल कहता है कि यह कितना रखरखाव योग्य है और इसे बनाए रखने के लिए किन कौशल की आवश्यकता है। यह तय करने के लिए उपयोगी है कि किसी तरह का कोड आधार खरीदा जाए, उसे सेवा दी जा सके, या अपने स्वयं के उत्पाद के बारे में एक विचार प्राप्त किया जा सके जो विकास टीम देती है। सैद्धांतिक रूप से, यह साझा संसाधनों के माध्यम से टीमों के पैमाने में मदद करनी चाहिए। AWS Macie जैसा कुछ, लेकिन कोड के लिए - कुछ इस तरह से मैं काम कर रहा हूँ। मुझे खुद रोज़मर्रा के काम के लिए इसकी आवश्यकता है, और मुझे संदेह है कि दूसरों को इस तरह के एक उपकरण के लिए आवेदन मिल सकता है, कम से कम यह सिद्धांत है।

शायद यह यहाँ रुचि रखने वालों के लिए पंजीकरण के कुछ फार्म डालने लायक होगा ...

असंसाधित / संसाधित फ़ाइलें

अगर कोई अपना विश्लेषण करना चाहता है और सुधार करना चाहता है, तो यहां संसाधित फ़ाइलों (20 एमबी) की एक कड़ी है। अगर कोई सार्वजनिक डोमेन में कच्ची फाइलें पोस्ट करना चाहता है, तो मुझे बताएं। यह 83 जीबी टारगेट है, और अंदर सिर्फ 1 टीबी से अधिक है। सामग्री में विभिन्न आकारों की सिर्फ 9 मिलियन से अधिक JSON फाइलें हैं।

युपीडी। कई अच्छी आत्माओं ने फ़ाइल रखने का सुझाव दिया, स्थानों को नीचे इंगित किया गया है:

• https://releases.wekan.team/scc/

इस tar.gz फ़ाइल की मेजबानी करके, वीकन प्रोजेक्ट से xet7 के लिए सर्वर के लिए सीएनसीएफ को धन्यवाद ।