اهو هڪ مستحڪم ڪوڊ تجزيي جي ڪوشش ڪرڻ آسان آهي. پر ان کي لاڳو ڪرڻ لاء، خاص طور تي وڏي پراڻي منصوبي جي ترقي ۾، مهارت جي ضرورت آهي. جيڪڏهن غلط طريقي سان ڪيو ويو آهي، تجزيه ڪندڙ ڪم شامل ڪري سگهي ٿو، ترقي کي سست ڪري، ۽ ٽيم کي ختم ڪري سگهي ٿو. اچو ته مختصر طور تي ڳالهايون ته ڪيئن صحيح طريقي سان مستحڪم تجزيو جي انضمام کي ترقي جي عمل ۾ داخل ڪيو وڃي ۽ ان کي CI/CD جي حصي طور استعمال ڪرڻ شروع ڪيو وڃي.
تعارف
تازو منهنجو ڌيان اشاعت ڏانهن ويو "". هڪ طرف، هي هڪ سٺو مضمون آهي جنهن سان واقفيت حاصل ڪرڻ جي قابل آهي. ٻئي طرف، اهو مون کي لڳي ٿو ته اهو اڃا تائين مڪمل جواب نه ڏئي سگهيو آهي ته ڪيئن بغير ڪنهن منصوبي ۾ جامد تجزيي کي لاڳو ڪرڻ لاء تمام گهڻي تڪليف سان. آرٽيڪل چوي ٿو ته توهان ٽيڪنيڪل قرض قبول ڪري سگهو ٿا ۽ صرف نئين ڪوڊ تي ڪم ڪري سگهو ٿا، پر هن ٽيڪنيڪل قرض کي بعد ۾ ڇا ڪرڻو آهي ان جو ڪو جواب ناهي.
اسان جي PVS-اسٽوڊيو ٽيم هن موضوع تي پنهنجو نظريو پيش ڪري ٿي. اچو ته ڏسو ته ڪيئن هڪ جامد ڪوڊ تجزيي کي لاڳو ڪرڻ جو مسئلو پهرين جاء تي پيدا ٿئي ٿو، ڪيئن هن مسئلي تي قابو پائڻ، ۽ ڪيئن تڪليف سان تدريجي طور تي ٽيڪنيڪل قرض کي ختم ڪرڻ.
مسئلا
اهو عام طور تي شروع ڪرڻ ڏکيو ناهي ۽ ڏسڻ ۾ اچي ٿو ته هڪ جامد تجزيه ڪيئن ڪم ڪري ٿو []. توهان ڏسي سگهو ٿا دلچسپ غلطيون يا اڃا به خوفناڪ امڪاني نقصان ڪوڊ ۾. توھان ڪجھھ ٺيڪ ڪري سگھوٿا، پر پوءِ گھڻا پروگرامر ڇڏي ڏين ٿا.
سڀئي جامد تجزيي وارا غلط مثبت پيدا ڪن ٿا. هي جامد ڪوڊ تجزيي جي طريقيڪار جي هڪ خاصيت آهي، ۽ ان بابت ڪجھ به نه ٿو ڪري سگهجي. عام صورت ۾، هي هڪ ناقابل حل مسئلو آهي، جيئن ته رائس جي نظريي جي تصديق ڪئي وئي آهي.]. مشين لرننگ الگورتھم به مدد نه ڪندا]. جيتوڻيڪ ڪو ماڻهو هميشه اهو نه ٿو ٻڌائي سگهي ته اهو يا اهو ڪوڊ غلط آهي، پوء توهان کي هن پروگرام مان اميد نه رکڻ گهرجي :).
غلط مثبت ڪو مسئلو ناهي جيڪڏهن جامد تجزيه ڪندڙ اڳ ۾ ئي ترتيب ڏنل آهي:
- غير لاڳاپيل قاعدن جي سيٽ کي بند ڪيو ويو؛
- ڪجهه غير لاڳاپيل تشخيص کي بند ڪيو ويو آهي؛
- جيڪڏهن اسان C يا C++ بابت ڳالهائي رهيا آهيون، ته پوءِ ميڪرو نشان لڳل هوندا آهن جن ۾ مخصوص ٺاهن تي مشتمل هوندو آهي، جيڪي هر جڳهه تي بيڪار ڊيڄاريندڙن کي ظاهر ڪندا آهن جتي اهڙا ميڪرو استعمال ڪيا ويندا آهن؛
- پنھنجا افعال نشان لڳل آھن جيڪي ڪارناما انجام ڏين ٿا ساڳي طرح سسٽم جي افعال (ان جو پنھنجو اينالاگ مامي يا printf) [];
- غلط مثبت تبصرا استعمال ڪندي خاص طور تي معذور آهن؛
- ۽ پوء تي.
انهي صورت ۾، اسان اميد ڪري سگهون ٿا ته گهٽ غلط مثبت شرح بابت 10-15٪ []. ٻين لفظن ۾، 9 مان 10 تجزياتي ڊيڄاريندڙ ڪوڊ ۾ حقيقي مسئلو ظاهر ڪندا، يا گهٽ ۾ گهٽ "مضبوط بوء وارو ڪوڊ." اتفاق ڪيو، هي منظر انتهائي خوشگوار آهي، ۽ تجزيه ڪندڙ پروگرامر جو حقيقي دوست آهي.
حقيقت ۾، هڪ وڏي منصوبي ۾، ابتدائي تصوير مڪمل طور تي مختلف ٿي ويندي. تجزيه ڪندڙ ورثي ڪوڊ لاءِ سوين يا هزارين ڊيڄاريندڙ مسئلا. اهو جلدي سمجهڻ ناممڪن آهي ته انهن ڊيڄاريندڙن مان ڪهڙيون لاڳاپيل آهن ۽ ڪهڙيون نه آهن. بيهڻ ۽ انهن سڀني ڊيڄاريندڙن سان معاملو ڪرڻ شروع ڪرڻ غير منطقي آهي، ڇاڪاڻ ته هن معاملي ۾ مکيه ڪم ڏينهن يا هفتن لاء بند ٿي ويندو. عام طور تي، هڪ ٽيم اهڙي صورتحال کي برداشت نه ڪري سگهي. اتي به اختلافن جو هڪ وڏو تعداد آهي جيڪو تبديلي جي تاريخ کي خراب ڪري ٿو. ۽ ڪوڊ ۾ ڪيترن ئي ٽڪرن جي تيزيءَ سان ايڊيٽنگ ناگزير طور تي نئين ٽائپس ۽ غلطين جي نتيجي ۾ ٿيندي.
۽ سڀ کان وڌيڪ اهم، ڊيڄاريندڙن جي خلاف جنگ ۾ اهڙي ڪارڪردگي ٿورو احساس آهي. اتفاق ڪيو ته اهو منصوبو ڪيترن ئي سالن کان ڪاميابيءَ سان هلي رهيو آهي، ان ۾ گهڻيون نازڪ غلطيون اڳ ۾ ئي درست ڪيون ويون آهن. ها، اهي سڌارا ڏاڍا قيمتي هئا، ڊيبگ ٿيڻ گهرجن، ڪيڙن بابت منفي صارف راءِ مليا، وغيره. هڪ مستحڪم تجزيه ڪندڙ انهن غلطين مان ڪيترن ئي کي درست ڪرڻ ۾ مدد ڪندو ڪوڊنگ اسٽيج تي، تڪڙو ۽ سستو. پر هن وقت، هڪ طريقو يا ٻيو، اهي غلطيون مقرر ڪيون ويون آهن، ۽ تجزيه ڪندڙ بنيادي طور تي پراڻي ڪوڊ ۾ غير نازڪ غلطيون ڳولي ٿو. هي ڪوڊ استعمال نه ٿي سگھي ٿو، اهو تمام گهٽ استعمال ٿي سگهي ٿو، ۽ ان ۾ هڪ غلطي شايد قابل ذڪر نتيجن جي اڳواڻي نه ڪري سگھي. ٿي سگهي ٿو ته بٽڻ مان پاڇو غلط رنگ آهي، پر اهو ڪنهن جي پيداوار جي استعمال سان مداخلت نٿو ڪري.
يقينن، ننڍيون غلطيون اڃا به غلطيون آهن. ۽ ڪڏهن ڪڏهن هڪ غلطي هڪ حقيقي نقصان لڪائي سگهي ٿو. بهرحال، هر شيءِ کي ڇڏي ڏيڻ ۽ خرچ ڪرڻ وارا ڏينهن/هفتو عيب سان معاملو ڪرڻ جيڪي مشڪل سان پاڻ کي ظاهر ڪن ٿا هڪ مشڪوڪ خيال وانگر.
پروگرامر ڏسندا، ڏسندا، پراڻا ڪم ڪندڙ ڪوڊ بابت انهن سڀني ڊيڄاريندڙن کي ڏسندا... ۽ اھي سوچيندا آھن: اسان جامد تجزيو کانسواءِ ڪري سگھون ٿا. اچو ته ڪجهه نئين مفيد فنڪشنلٽي لکون.
پنهنجي طريقي سان، اهي صحيح آهن. اهي سمجهن ٿا ته پهريان انهن کي ڪنهن نه ڪنهن طرح انهن سڀني ڊيڄاريندڙن کان نجات حاصل ڪرڻي آهي. صرف ان کان پوء اهي ڪوڊ اينالائيزر جي باقاعده استعمال مان فائدو حاصل ڪري سگهندا. ٻي صورت ۾، نوان ڊيڄاريندڙ رڳو پراڻين ۾ ٻڏي ويندا، ۽ ڪو به انهن تي ڌيان نه ڏيندو.
هي ساڳيو قياس آهي جيئن گڏ ڪرڻ وارن وارننگن سان. اهو بغير ڪنهن سبب جي ناهي ته اهي مرتب ڪندڙ ڊيڄاريندڙن جو تعداد 0 تي رکڻ جي صلاح ڏين ٿا. جيڪڏهن 1000 ڊيڄاريندڙ آهن، پوء جڏهن 1001 آهن، ڪو به ان تي ڌيان نه ڏيندو، ۽ اهو واضح ناهي ته هن نئين ڊيڄاريندڙ کي ڪٿي ڳولڻ گهرجي.
هن ڪهاڻي ۾ بدترين شيء اها آهي ته جيڪڏهن مٿي کان ڪو ماڻهو هن وقت توهان کي جامد ڪوڊ تجزيو استعمال ڪرڻ تي مجبور ڪري ٿو. اهو صرف ٽيم کي تباهه ڪندو، ڇاڪاڻ ته انهن جي نقطي نظر کان اتي اضافي بيوروڪريسي پيچيدگي هوندي جيڪا صرف رستي ۾ اچي ٿي. ڪو به تجزيو ڪندڙ جي رپورٽن تي نظر نه ڪندو، ۽ سڀ استعمال صرف "ڪاغذ تي" ٿيندو. اهي. رسمي طور تي، تجزيو DevOps پروسيس ۾ ٺهيل آهي، پر عملي طور تي اهو ڪنهن کي فائدو نٿو ڏئي. اسان ڪانفرنس ۾ شرڪت ڪندڙن کان بوٿن تي تفصيلي ڳالهيون ٻڌيون. اهڙو تجربو پروگرامرن کي حوصلا افزائي ڪري سگهي ٿو جامد تجزياتي اوزار استعمال ڪرڻ کان ڊگھي وقت تائين، جيڪڏهن نه هميشه لاءِ.
ٽيڪنيڪل قرض کي لاڳو ڪرڻ ۽ ختم ڪرڻ
حقيقت ۾، هڪ وڏي پراڻي منصوبي ۾ جامد تجزيو متعارف ڪرائڻ بابت ڪجھ به ڏکيو يا خوفناڪ نه آهي.
CI/CD
ان کان سواء، تجزيي کي فوري طور تي مسلسل ترقي جي عمل جو حصو بڻائي سگهجي ٿو. مثال طور، PVS-اسٽوڊيو ورهائڻ ۾ توهان کي گهربل فارميٽ ۾ رپورٽ کي آسانيءَ سان ڏسڻ لاءِ يوٽيلٽيون شامل آهن، ۽ ڊولپرز لاءِ اطلاع جيڪي ڪوڊ جا مشڪلاتي حصا لکيا آهن. انهن لاءِ جيڪي CI/CD سسٽم مان PVS-اسٽوڊيو شروع ڪرڻ ۾ وڌيڪ دلچسپي رکن ٿا، آئون سفارش ڪريان ٿو ته توهان پاڻ کي ان سان واقف ڪريو دستاويز ۽ مضمونن جو هڪ سلسلو:
پر اچو ته واپس وڃون وڏي تعداد ۾ غلط مثبتن جي مسئلي کي لاڳو ڪرڻ جي پهرين مرحلن تي ڪوڊ تجزيو اوزار.
موجوده ٽيڪنيڪل قرض کي درست ڪرڻ ۽ نئين ڊيڄاريندڙن سان معاملو ڪرڻ
جديد تجارتي جامد تجزيه ڪندڙ توهان کي صرف نئين ڊيڄاريندڙن جو مطالعو ڪرڻ جي اجازت ڏين ٿا جيڪي نئين يا تبديل ٿيل ڪوڊ ۾ ظاهر ٿيندا آهن. هن ميکانيزم تي عملدرآمد مختلف آهي، پر جوهر ساڳيو آهي. PVS-اسٽوڊيو جامد تجزيي ۾، هي ڪارڪردگي هيٺين طور تي لاڳو ڪيو ويو آهي.
تيزيءَ سان جامد تجزيي کي استعمال ڪرڻ شروع ڪرڻ لاءِ، اسان مشورو ڏيون ٿا ته PVS-اسٽوڊيو استعمال ڪندڙن کي ڊيڄاريندڙن جي ماس دٻائڻ لاءِ ميکانيزم استعمال ڪريو []. عام خيال هيٺ ڏنل آهي. صارف تجزيي کي شروع ڪيو ۽ ڪيترائي ڊيڄاريندڙ مليا. جيئن ته هڪ پروجيڪٽ جيڪو ڪيترن ئي سالن کان ترقي ۾ آهي زنده آهي، ترقي ڪري رهيو آهي ۽ پئسا ڪمائي رهيو آهي، پوء گهڻو ڪري رپورٽ ۾ ڪيتريون ئي ڊيڄاريندڙ نه هونديون جيڪي نازڪ خرابين جي نشاندهي ڪن ٿيون. ٻين لفظن ۾، نازڪ ڪيڙا اڳ ۾ ئي مقرر ڪيا ويا آهن هڪ طريقو يا ٻيو وڌيڪ قيمتي طريقا استعمال ڪندي يا گراهڪن جي موٽ جي مهرباني. ان جي مطابق، هر شيء جيڪا تجزيه ڪندڙ هن وقت ڳولي ٿي، اهو سمجهي سگهجي ٿو ٽيڪنيڪل قرض، جيڪو فوري طور تي ختم ڪرڻ جي ڪوشش ڪرڻ ناممڪن آهي.
توھان PVS-Studio کي چئي سگھو ٿا انھن ڊيڄاريندڙن کي ھاڻي لاءِ غير لاڳاپيل سمجھو (بعد ۾ ٽيڪنيڪل قرض بچايو)، ۽ اھو انھن کي وڌيڪ نه ڏيکاريندو. تجزيه ڪندڙ هڪ خاص فائل ٺاهي ٿو جتي اهو غلطين بابت معلومات محفوظ ڪري ٿو جيڪي اڃا تائين دلچسپ نه آهن. ۽ ھاڻي PVS-Studio صرف نئين يا تبديل ٿيل ڪوڊ لاءِ ڊيڄاريندڙ جاري ڪندو. ان کان علاوه، اهو سڀ ڪجهه هوشياري سان لاڳو ڪيو ويو آهي. جيڪڏهن، مثال طور، ماخذ ڪوڊ فائل جي شروعات ۾ هڪ خالي لڪير شامل ڪئي وئي آهي، پوء تجزيه ڪندڙ سمجهي ٿو ته، حقيقت ۾، ڪجھ به تبديل نه ڪيو ويو آهي، ۽ خاموش ٿيڻ جاري رهندو. هي مارڪ اپ فائل ورجن ڪنٽرول سسٽم ۾ رکي سگھجي ٿو. فائل وڏي آهي، پر اهو ڪو مسئلو ناهي، ڇاڪاڻ ته ان کي اڪثر ذخيرو ڪرڻ جو ڪو به مقصد ناهي.
ھاڻي سڀ پروگرامر رڳو نئين يا تبديل ٿيل ڪوڊ سان لاڳاپيل ڊيڄاريندڙ ڏسندا. اهڙيء طرح، توهان تجزيه استعمال ڪرڻ شروع ڪري سگهو ٿا، جيئن اهي چون ٿا، ايندڙ ڏينهن کان. ۽ توهان بعد ۾ ٽيڪنيڪل قرض ڏانهن واپس ڪري سگهو ٿا، ۽ تدريجي طور تي غلطي کي درست ڪريو ۽ تجزيي کي ترتيب ڏيو.
تنهن ڪري، هڪ وڏي پراڻي منصوبي ۾ تجزيي جي عمل سان پهريون مسئلو حل ڪيو ويو آهي. هاڻي اچو ته سمجهون ته ٽيڪنيڪل قرض سان ڇا ڪجي.
بگ فيڪس ۽ ريفيڪٽرنگ
سڀ کان سادو ۽ سڀ کان وڌيڪ قدرتي شيء اهو آهي ته ڪجهه وقت مقرر ڪرڻ لاء وڏي پيماني تي تجزيه ڪندڙ ڊيڄاريندڙن جو تجزيو ڪرڻ ۽ تدريجي طور تي انهن سان معاملو ڪيو وڃي. ڪٿي توهان کي ڪوڊ جي غلطين کي درست ڪرڻ گهرجي، ته ڪٿي توهان تجزيه نگار کي ٻڌائڻ لاءِ ريفيڪٽر ڪرڻ گهرجي ته ڪوڊ مسئلو ناهي. سادو مثال:
if (a = b)اڪثر سي ++ مرتب ڪندڙ ۽ تجزيه ڪندڙ اهڙي ڪوڊ بابت شڪايت ڪن ٿا، ڇاڪاڻ ته اتي هڪ وڏو امڪان آهي ته اهي اصل ۾ لکڻ چاهيندا هئا. (a == ب). پر اتي هڪ اڻ ڄاتل معاهدو آهي، ۽ اهو عام طور تي دستاويز ۾ نوٽ ڪيو ويو آهي، ته جيڪڏهن اضافي قوسون آهن، پوء اهو سمجهيو ويندو آهي ته پروگرامر ڄاڻي واڻي اهڙي ڪوڊ لکيو، ۽ قسم کڻڻ جي ڪا ضرورت ناهي. مثال طور، تشخيص لاء PVS-اسٽوڊيو دستاويزن ۾ اهو واضح طور تي لکيو ويو آهي ته هيٺ ڏنل لائن صحيح ۽ محفوظ سمجهي ويندي:
if ((a = b))ٻيو مثال. ڇا اهو هن C++ ڪوڊ ۾ وساريو ويو آهي؟ ٽوڙڻ يا نه؟
case A:
foo();
case B:
bar();
break;PVS-اسٽوڊيو تجزيه ڪندڙ هتي هڪ ڊيڄاريندڙ جاري ڪندو . ٿي سگهي ٿو اها ڪا غلطي نه هجي، ان صورت ۾ توهان کي پارسر کي وصف شامل ڪندي اشارو ڏيڻ گهرجي يا مثال طور __خاصيت__((زوال جي ذريعي)):
case A:
foo();
[[fallthrough]];
case B:
bar();
break;اهو چئي سگهجي ٿو ته اهڙيون ڪوڊ تبديليون بگ کي درست نه ڪندا آهن. ها، اهو سچ آهي، پر اهو ٻه مفيد شيون ڪري ٿو. پهرين، تجزيي جي رپورٽ غلط مثبت کان نجات حاصل ڪري ٿي. ٻيو، ڪوڊ ان جي سار سنڀال ۾ ملوث ماڻهن لاء وڌيڪ سمجهي سگهجي ٿو. ۽ هي تمام ضروري آهي! هن اڪيلو لاء، اهو ضروري آهي ته معمولي ريفڪٽرنگ کڻڻ لاء ڪوڊ صاف ۽ برقرار رکڻ آسان بڻائي. جيئن ته تجزيه نگار اهو نه ٿو سمجهي ته ”بريڪ“ جي ضرورت آهي يا نه، اهو به ساٿي پروگرامرز لاءِ واضح نه هوندو.
بگ فيڪس ۽ ريفيڪٽرنگ جي اضافي ۾، توهان خاص طور تي واضح طور تي غلط تجزيي وارن وارننگن کي دٻائي سگهو ٿا. ڪجھ غير لاڳاپيل تشخيص کي بند ڪري سگھجي ٿو. مثال طور، ڪو سوچي ٿو ڊيڄاريندڙ بي معني آهن فلوٽ / ٻٽي قدرن جي مقابلي بابت. ۽ ڪجهه انهن کي اهم ۽ مطالعي جي لائق قرار ڏين ٿا.]. ڪهڙا ڊيڄاريندڙ سمجهيا وڃن ٿا لاڳاپيل ۽ ڪهڙا نه آهن فيصلو ڪرڻ لاءِ ترقياتي ٽيم تي آهي.
اتي ٻيا طريقا آھن غلط انتباہ کي دٻائڻ لاء. مثال طور، ميڪرو مارڪ اپ اڳ ذڪر ڪيو ويو آهي. هي سڀ دستاويز ۾ وڌيڪ تفصيل سان بيان ڪيو ويو آهي. سڀ کان اهم شيء اهو سمجهڻ آهي ته جيڪڏهن توهان تدريجي ۽ منظم طريقي سان غلط مثبت سان ڪم ڪرڻ سان رابطو ڪيو، انهن سان گڏ ڪجهه به غلط ناهي. غير دلچسپ ڊيڄاريندڙن جي وڏي اڪثريت ترتيب ڏيڻ کان پوءِ غائب ٿي ويندي آهي، ۽ صرف اهي جڳهيون جن کي واقعي محتاط مطالعي جي ضرورت هوندي آهي ۽ ڪوڊ ۾ ڪجهه تبديليون رهنديون آهن.
انهي سان گڏ، اسان هميشه پنهنجي گراهڪن کي PVS-Studio سيٽ ڪرڻ ۾ مدد ڪندا آهيون جيڪڏهن ڪا مشڪلات پيدا ٿئي. ان کان علاوه، اهڙا ڪيس هئا جڏهن اسان پاڻ کي غلط ڊيڄاريندڙن کي ختم ڪيو ۽ غلطي کي درست ڪيو []. بس صورت ۾، مون اهو ذڪر ڪرڻ جو فيصلو ڪيو ته وڌايل تعاون لاء هي اختيار پڻ ممڪن آهي :).
ڇنڊڇاڻ جو طريقو
هڪ ٻيو دلچسپ طريقو آهي تدريجي طور تي ڪوڊ جي معيار کي بهتر ڪرڻ لاءِ جامد تجزيي وارننگ کي ختم ڪندي. هيٺئين لائن اها آهي ته ڊيڄاريندڙن جو تعداد صرف گهٽجي سگهي ٿو.
جامد تجزيه ڪندڙ طرفان جاري ڪيل ڊيڄاريندڙن جو تعداد رڪارڊ ڪيو ويو آهي. معيار جو دروازو اهڙي طرح ترتيب ڏنو ويو آهي ته هاڻي توهان صرف هڪ ڪوڊ داخل ڪري سگهو ٿا جيڪو عملن جو تعداد وڌائي نٿو سگهي. نتيجي طور، تجزيي کي ترتيب ڏيڻ ۽ غلطين کي درست ڪرڻ سان الارم جي تعداد کي سست رفتاري سان گھٽائڻ جو عمل شروع ٿئي ٿو.
جيتوڻيڪ ڪو ماڻهو ٿورڙو ٺڳي ڪرڻ چاهي ٿو ۽ معيار جي دروازي کي پاس ڪرڻ جو فيصلو ڪري ٿو نه ته پنهنجي نئين ڪوڊ ۾ ڊيڄاريندڙن کي ختم ڪندي، پر پراڻي ٽئين پارٽي جي ڪوڊ کي بهتر ڪندي، اهو خوفناڪ ناهي. ساڳيء طرح، ريچٽ ھڪڙي طرف گھمندو آھي، ۽ تدريجي طور تي خرابين جو تعداد گھٽجي ويندو. جيتوڻيڪ ڪو ماڻهو پنهنجي نئين عيب کي درست ڪرڻ نه چاهيندو آهي، تڏهن به هن کي پاڙيسري ڪوڊ ۾ ڪجهه بهتر ڪرڻو پوندو. ڪجهه نقطي تي، ڊيڄاريندڙن جي تعداد کي گهٽائڻ جا آسان طريقا ختم ٿي ويندا آهن، ۽ اتي هڪ نقطو اچي ٿو جڏهن حقيقي ڪيگ مقرر ڪيا ويندا.
اهو طريقو وڌيڪ تفصيل سان بيان ڪيو ويو آهي Ivan Ponomarev جي هڪ تمام دلچسپ مضمون ۾ ""، جنهن کي مان سفارش ڪريان ٿو پڙهڻ جي هر ڪنهن کي جيڪو ڪوڊ جي معيار کي بهتر ڪرڻ ۾ دلچسپي رکي ٿو.
مضمون جو مصنف پڻ هن موضوع تي هڪ رپورٽ آهي: "".
ٿڪل
مون کي اميد آهي ته هن مضمون کان پوء، پڙهندڙن کي وڌيڪ قبول ڪيو ويندو جامد تجزياتي اوزار ۽ انهن کي ترقي جي عمل ۾ لاڳو ڪرڻ چاهيندا. جيڪڏهن توهان وٽ ڪو سوال آهي، اسان هميشه لاء تيار آهيون اسان جي جامد تجزيو ڪندڙ PVS-Studio جا استعمال ڪندڙ ۽ ان جي عمل درآمد ۾ مدد ڪن ٿا.
اتي ٻيا عام شڪ آھن ته ڇا جامد تجزيو واقعي آسان ۽ ڪارائتو ٿي سگھي ٿو. مون اشاعت ۾ انهن مان اڪثر شڪ کي ختم ڪرڻ جي ڪوشش ڪئي ”پي وي ايس اسٽوڊيو جامد ڪوڊ اينالائيزر کي ترقي جي عمل ۾ متعارف ڪرائڻ جا سبب“ [].
توهان جي توجه جي مهرباني ۽ اچو ۽ ڪوشش ڪريو PVS-Studio analyzer.
اضافي لنڪس
- آندري ڪارپوف.
- وڪيپيڊيا. .
- اندري ڪارپوف، وڪٽوريا خانيوا. .
- PVS-اسٽوڊيو. دستاويزي. .
- آندري ڪارپوف. .
- PVS-اسٽوڊيو. دستاويزي. .
- ايوان اندريشين. .
- Pavel Eremeev، Svyatoslav Razmyslov. .
- آندري ڪارپوف. .
جيڪڏهن توهان هن مضمون کي انگريزي ڳالهائيندڙ سامعين سان حصيداري ڪرڻ چاهيو ٿا، مهرباني ڪري ترجمو لنڪ استعمال ڪريو: Andrey Karpov. .
جو ذريعو: www.habr.com