ತಂಡವನ್ನು ಹಿಂತೆಗೆದುಕೊಳ್ಳದೆಯೇ ಪರಂಪರೆಯ ಯೋಜನೆಯಲ್ಲಿ ಸ್ಥಿರ ಕೋಡ್ ವಿಶ್ಲೇಷಕವನ್ನು ಹೇಗೆ ಕಾರ್ಯಗತಗೊಳಿಸುವುದು

ಸ್ಥಿರ ಕೋಡ್ ವಿಶ್ಲೇಷಕವನ್ನು ಪ್ರಯತ್ನಿಸುವುದು ಸುಲಭ. ಆದರೆ ಅದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು, ವಿಶೇಷವಾಗಿ ದೊಡ್ಡ ಹಳೆಯ ಯೋಜನೆಯ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ, ಕೌಶಲ್ಯದ ಅಗತ್ಯವಿದೆ. ತಪ್ಪಾಗಿ ಮಾಡಿದರೆ, ವಿಶ್ಲೇಷಕವು ಕೆಲಸವನ್ನು ಸೇರಿಸಬಹುದು, ಅಭಿವೃದ್ಧಿಯನ್ನು ನಿಧಾನಗೊಳಿಸಬಹುದು ಮತ್ತು ತಂಡವನ್ನು ತಗ್ಗಿಸಬಹುದು. ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಸ್ಥಿರ ವಿಶ್ಲೇಷಣೆಯ ಏಕೀಕರಣವನ್ನು ಹೇಗೆ ಸರಿಯಾಗಿ ಸಮೀಪಿಸುವುದು ಮತ್ತು CI/CD ಯ ಭಾಗವಾಗಿ ಅದನ್ನು ಬಳಸಲು ಪ್ರಾರಂಭಿಸುವುದು ಹೇಗೆ ಎಂಬುದರ ಕುರಿತು ಸಂಕ್ಷಿಪ್ತವಾಗಿ ಮಾತನಾಡೋಣ.

ಪರಿಚಯ

ಇತ್ತೀಚೆಗೆ ನನ್ನ ಗಮನವನ್ನು ಪ್ರಕಟಣೆಯತ್ತ ಸೆಳೆಯಲಾಯಿತು "ತಂಡವನ್ನು ಮುಳುಗಿಸದೆ ಸ್ಥಾಯೀ ವಿಶ್ಲೇಷಣೆಯೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸುವುದು". ಒಂದೆಡೆ, ಇದು ಪರಿಚಯವಾಗಲು ಯೋಗ್ಯವಾದ ಉತ್ತಮ ಲೇಖನವಾಗಿದೆ, ಮತ್ತೊಂದೆಡೆ, ಯೋಜನೆಯಲ್ಲಿ ಸ್ಥಿರ ವಿಶ್ಲೇಷಣೆಯನ್ನು ನೋವುರಹಿತವಾಗಿ ಹೇಗೆ ಕಾರ್ಯಗತಗೊಳಿಸುವುದು ಎಂಬುದರ ಕುರಿತು ಇದು ಇನ್ನೂ ಸಂಪೂರ್ಣ ಉತ್ತರವನ್ನು ನೀಡುವುದಿಲ್ಲ ಎಂದು ನನಗೆ ತೋರುತ್ತದೆ. ನೀವು ತಾಂತ್ರಿಕ ಸಾಲವನ್ನು ಸ್ವೀಕರಿಸಬಹುದು ಮತ್ತು ಹೊಸ ಕೋಡ್‌ನಲ್ಲಿ ಮಾತ್ರ ಕೆಲಸ ಮಾಡಬಹುದು ಎಂದು ಲೇಖನವು ಹೇಳುತ್ತದೆ, ಆದರೆ ಈ ತಾಂತ್ರಿಕ ಸಾಲವನ್ನು ನಂತರ ಏನು ಮಾಡಬೇಕು ಎಂಬುದಕ್ಕೆ ಉತ್ತರವಿಲ್ಲ.

ನಮ್ಮ PVS-ಸ್ಟುಡಿಯೋ ತಂಡವು ಈ ವಿಷಯದ ಕುರಿತು ತನ್ನ ದೃಷ್ಟಿಕೋನವನ್ನು ನೀಡುತ್ತದೆ. ಸ್ಥಾಯೀ ಕೋಡ್ ವಿಶ್ಲೇಷಕವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಸಮಸ್ಯೆಯು ಮೊದಲ ಸ್ಥಾನದಲ್ಲಿ ಹೇಗೆ ಉದ್ಭವಿಸುತ್ತದೆ, ಈ ಸಮಸ್ಯೆಯನ್ನು ಹೇಗೆ ನಿವಾರಿಸುವುದು ಮತ್ತು ತಾಂತ್ರಿಕ ಸಾಲವನ್ನು ನೋವುರಹಿತವಾಗಿ ಕ್ರಮೇಣ ತೆಗೆದುಹಾಕುವುದು ಹೇಗೆ ಎಂದು ನೋಡೋಣ.

ಸಮಸ್ಯೆಗಳು

ಸ್ಥಾಯೀ ವಿಶ್ಲೇಷಕವು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಪ್ರಾರಂಭಿಸಲು ಮತ್ತು ನೋಡಲು ಸಾಮಾನ್ಯವಾಗಿ ಕಷ್ಟವಾಗುವುದಿಲ್ಲ.1]. ನೀವು ಕೋಡ್‌ನಲ್ಲಿ ಆಸಕ್ತಿದಾಯಕ ದೋಷಗಳನ್ನು ಅಥವಾ ಭಯಾನಕ ಸಂಭಾವ್ಯ ದೋಷಗಳನ್ನು ಸಹ ನೋಡಬಹುದು. ನೀವು ಏನನ್ನಾದರೂ ಸರಿಪಡಿಸಬಹುದು, ಆದರೆ ನಂತರ ಅನೇಕ ಪ್ರೋಗ್ರಾಮರ್ಗಳು ಬಿಟ್ಟುಕೊಡುತ್ತಾರೆ.

ಎಲ್ಲಾ ಸ್ಥಿರ ವಿಶ್ಲೇಷಕಗಳು ತಪ್ಪು ಧನಾತ್ಮಕತೆಯನ್ನು ಉಂಟುಮಾಡುತ್ತವೆ. ಇದು ಸ್ಥಿರ ಕೋಡ್ ವಿಶ್ಲೇಷಣೆ ವಿಧಾನದ ವೈಶಿಷ್ಟ್ಯವಾಗಿದೆ ಮತ್ತು ಅದರ ಬಗ್ಗೆ ಏನನ್ನೂ ಮಾಡಲಾಗುವುದಿಲ್ಲ. ಸಾಮಾನ್ಯ ಸಂದರ್ಭದಲ್ಲಿ, ರೈಸ್ ಪ್ರಮೇಯದಿಂದ ದೃಢೀಕರಿಸಿದಂತೆ ಇದು ಪರಿಹರಿಸಲಾಗದ ಸಮಸ್ಯೆಯಾಗಿದೆ.2]. ಯಂತ್ರ ಕಲಿಕೆ ಅಲ್ಗಾರಿದಮ್‌ಗಳು ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ [3]. ಈ ಅಥವಾ ಆ ಕೋಡ್ ತಪ್ಪಾಗಿದೆಯೇ ಎಂದು ವ್ಯಕ್ತಿಯು ಯಾವಾಗಲೂ ಹೇಳಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೂ ಸಹ, ನೀವು ಇದನ್ನು ಪ್ರೋಗ್ರಾಂನಿಂದ ನಿರೀಕ್ಷಿಸಬಾರದು :).

ಸ್ಥಿರ ವಿಶ್ಲೇಷಕವನ್ನು ಈಗಾಗಲೇ ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ್ದರೆ ತಪ್ಪು ಧನಾತ್ಮಕ ಸಮಸ್ಯೆಗಳಿಲ್ಲ:

• ಅಪ್ರಸ್ತುತ ನಿಯಮ ಸೆಟ್‌ಗಳನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆ;
• ಕೆಲವು ಅಪ್ರಸ್ತುತ ರೋಗನಿರ್ಣಯಗಳನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆ;
• ನಾವು C ಅಥವಾ C++ ಕುರಿತು ಮಾತನಾಡುತ್ತಿದ್ದರೆ, ಅಂತಹ ಮ್ಯಾಕ್ರೋಗಳನ್ನು ಬಳಸುವ ಪ್ರತಿಯೊಂದು ಸ್ಥಳದಲ್ಲಿ ಅನುಪಯುಕ್ತ ಎಚ್ಚರಿಕೆಗಳು ಕಾಣಿಸಿಕೊಳ್ಳಲು ಕಾರಣವಾಗುವ ನಿರ್ದಿಷ್ಟ ರಚನೆಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ಮ್ಯಾಕ್ರೋಗಳನ್ನು ಗುರುತಿಸಲಾಗುತ್ತದೆ;
• ಸಿಸ್ಟಮ್ ಕಾರ್ಯಗಳಂತೆಯೇ ಕ್ರಿಯೆಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಸ್ವಂತ ಕಾರ್ಯಗಳನ್ನು ಗುರುತಿಸಲಾಗಿದೆ (ಅದರ ಸ್ವಂತ ಅನಲಾಗ್ ಮೆಮೊಪಿ ಅಥವಾ printf) [4];
• ಕಾಮೆಂಟ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ತಪ್ಪು ಧನಾತ್ಮಕತೆಯನ್ನು ನಿರ್ದಿಷ್ಟವಾಗಿ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆ;
• ಮತ್ತು ಹೀಗೆ.

ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನಾವು ಸುಮಾರು 10-15% ರಷ್ಟು ಕಡಿಮೆ ತಪ್ಪು ಧನಾತ್ಮಕ ದರವನ್ನು ನಿರೀಕ್ಷಿಸಬಹುದು.5]. ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, 9 ರಲ್ಲಿ 10 ವಿಶ್ಲೇಷಕ ಎಚ್ಚರಿಕೆಗಳು ಕೋಡ್‌ನಲ್ಲಿ ನಿಜವಾದ ಸಮಸ್ಯೆಯನ್ನು ಸೂಚಿಸುತ್ತವೆ, ಅಥವಾ ಕನಿಷ್ಠ "ಬಲವಾದ ವಾಸನೆಯ ಕೋಡ್" ಅನ್ನು ಸೂಚಿಸುತ್ತವೆ. ಒಪ್ಪುತ್ತೇನೆ, ಈ ಸನ್ನಿವೇಶವು ಅತ್ಯಂತ ಆಹ್ಲಾದಕರವಾಗಿರುತ್ತದೆ, ಮತ್ತು ವಿಶ್ಲೇಷಕವು ಪ್ರೋಗ್ರಾಮರ್ನ ನಿಜವಾದ ಸ್ನೇಹಿತ.

ವಾಸ್ತವದಲ್ಲಿ, ದೊಡ್ಡ ಯೋಜನೆಯಲ್ಲಿ, ಆರಂಭಿಕ ಚಿತ್ರವು ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನವಾಗಿರುತ್ತದೆ. ವಿಶ್ಲೇಷಕವು ಪರಂಪರೆ ಕೋಡ್‌ಗಾಗಿ ನೂರಾರು ಅಥವಾ ಸಾವಿರಾರು ಎಚ್ಚರಿಕೆಗಳನ್ನು ನೀಡುತ್ತದೆ. ಈ ಎಚ್ಚರಿಕೆಗಳಲ್ಲಿ ಯಾವುದು ಪ್ರಸ್ತುತವಾಗಿದೆ ಮತ್ತು ಯಾವುದು ಅಲ್ಲ ಎಂಬುದನ್ನು ತ್ವರಿತವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಅಸಾಧ್ಯ. ಈ ಎಲ್ಲಾ ಎಚ್ಚರಿಕೆಗಳೊಂದಿಗೆ ಕುಳಿತುಕೊಳ್ಳುವುದು ಮತ್ತು ವ್ಯವಹರಿಸುವುದನ್ನು ಪ್ರಾರಂಭಿಸುವುದು ಅಭಾಗಲಬ್ಧವಾಗಿದೆ, ಏಕೆಂದರೆ ಈ ಸಂದರ್ಭದಲ್ಲಿ ಮುಖ್ಯ ಕೆಲಸವು ದಿನಗಳು ಅಥವಾ ವಾರಗಳವರೆಗೆ ನಿಲ್ಲುತ್ತದೆ. ವಿಶಿಷ್ಟವಾಗಿ, ಒಂದು ತಂಡವು ಅಂತಹ ಸನ್ನಿವೇಶವನ್ನು ಪಡೆಯಲು ಸಾಧ್ಯವಿಲ್ಲ. ಬದಲಾವಣೆಯ ಇತಿಹಾಸವನ್ನು ಹಾಳುಮಾಡುವ ದೊಡ್ಡ ಸಂಖ್ಯೆಯ ವ್ಯತ್ಯಾಸಗಳು ಸಹ ಇರುತ್ತದೆ. ಮತ್ತು ಕೋಡ್‌ನಲ್ಲಿನ ಹಲವು ತುಣುಕುಗಳ ತ್ವರಿತ ಸಾಮೂಹಿಕ ಸಂಪಾದನೆಯು ಅನಿವಾರ್ಯವಾಗಿ ಹೊಸ ಮುದ್ರಣದೋಷಗಳು ಮತ್ತು ದೋಷಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ.

ಮತ್ತು ಮುಖ್ಯವಾಗಿ, ಎಚ್ಚರಿಕೆಗಳ ವಿರುದ್ಧದ ಹೋರಾಟದಲ್ಲಿ ಅಂತಹ ಸಾಧನೆಯು ಸ್ವಲ್ಪ ಅರ್ಥವಿಲ್ಲ. ಯೋಜನೆಯು ಹಲವು ವರ್ಷಗಳಿಂದ ಯಶಸ್ವಿಯಾಗಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಕಾರಣ, ಅದರಲ್ಲಿನ ಹೆಚ್ಚಿನ ನಿರ್ಣಾಯಕ ದೋಷಗಳನ್ನು ಈಗಾಗಲೇ ಸರಿಪಡಿಸಲಾಗಿದೆ ಎಂದು ಒಪ್ಪಿಕೊಳ್ಳಿ. ಹೌದು, ಈ ಪರಿಹಾರಗಳು ತುಂಬಾ ದುಬಾರಿಯಾಗಿದ್ದವು, ಡೀಬಗ್ ಮಾಡಬೇಕಾಗಿತ್ತು, ದೋಷಗಳ ಬಗ್ಗೆ ಋಣಾತ್ಮಕ ಬಳಕೆದಾರರ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಪಡೆಯಿತು, ಇತ್ಯಾದಿ. ಸ್ಥಿರ ವಿಶ್ಲೇಷಕವು ಕೋಡಿಂಗ್ ಹಂತದಲ್ಲಿ ಈ ಅನೇಕ ದೋಷಗಳನ್ನು ತ್ವರಿತವಾಗಿ ಮತ್ತು ಅಗ್ಗವಾಗಿ ಸರಿಪಡಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಆದರೆ ಈ ಸಮಯದಲ್ಲಿ, ಒಂದು ರೀತಿಯಲ್ಲಿ ಅಥವಾ ಇನ್ನೊಂದು ರೀತಿಯಲ್ಲಿ, ಈ ದೋಷಗಳನ್ನು ಸರಿಪಡಿಸಲಾಗಿದೆ, ಮತ್ತು ವಿಶ್ಲೇಷಕವು ಮುಖ್ಯವಾಗಿ ಹಳೆಯ ಕೋಡ್‌ನಲ್ಲಿ ನಿರ್ಣಾಯಕವಲ್ಲದ ದೋಷಗಳನ್ನು ಪತ್ತೆ ಮಾಡುತ್ತದೆ. ಈ ಕೋಡ್ ಅನ್ನು ಬಳಸಲಾಗುವುದಿಲ್ಲ, ಇದನ್ನು ಬಹಳ ವಿರಳವಾಗಿ ಬಳಸಬಹುದು ಮತ್ತು ಅದರಲ್ಲಿ ದೋಷವು ಗಮನಾರ್ಹ ಪರಿಣಾಮಗಳಿಗೆ ಕಾರಣವಾಗುವುದಿಲ್ಲ. ಬಹುಶಃ ಎಲ್ಲೋ ಗುಂಡಿಯಿಂದ ನೆರಳು ತಪ್ಪಾದ ಬಣ್ಣವಾಗಿದೆ, ಆದರೆ ಇದು ಉತ್ಪನ್ನದ ಯಾರ ಬಳಕೆಯನ್ನು ಅಡ್ಡಿಪಡಿಸುವುದಿಲ್ಲ.

ಸಹಜವಾಗಿ, ಸಣ್ಣ ತಪ್ಪುಗಳು ಸಹ ಇನ್ನೂ ತಪ್ಪುಗಳಾಗಿವೆ. ಮತ್ತು ಕೆಲವೊಮ್ಮೆ ಒಂದು ತಪ್ಪು ನಿಜವಾದ ದುರ್ಬಲತೆಯನ್ನು ಮರೆಮಾಡಬಹುದು. ಆದಾಗ್ಯೂ, ಎಲ್ಲವನ್ನೂ ತ್ಯಜಿಸುವುದು ಮತ್ತು ಕೇವಲ ತಮ್ಮನ್ನು ತಾವು ಪ್ರಕಟಪಡಿಸುವ ದೋಷಗಳನ್ನು ಎದುರಿಸಲು ದಿನಗಳು/ವಾರಗಳನ್ನು ಕಳೆಯುವುದು ಸಂಶಯಾಸ್ಪದ ಕಲ್ಪನೆಯಂತೆ ಕಾಣುತ್ತದೆ.

ಪ್ರೋಗ್ರಾಮರ್ಗಳು ಹಳೆಯ ಕೆಲಸದ ಕೋಡ್ ಬಗ್ಗೆ ಈ ಎಲ್ಲಾ ಎಚ್ಚರಿಕೆಗಳನ್ನು ನೋಡಿ, ನೋಡಿ, ನೋಡಿ ... ಮತ್ತು ಅವರು ಯೋಚಿಸುತ್ತಾರೆ: ನಾವು ಸ್ಥಿರ ವಿಶ್ಲೇಷಣೆ ಇಲ್ಲದೆ ಮಾಡಬಹುದು. ಕೆಲವು ಹೊಸ ಉಪಯುಕ್ತ ಕಾರ್ಯಗಳನ್ನು ಬರೆಯಲು ಹೋಗೋಣ.

ತಮ್ಮದೇ ಆದ ರೀತಿಯಲ್ಲಿ, ಅವರು ಸರಿ. ಮೊದಲು ಅವರು ಹೇಗಾದರೂ ಈ ಎಲ್ಲಾ ಎಚ್ಚರಿಕೆಗಳನ್ನು ತೊಡೆದುಹಾಕಬೇಕು ಎಂದು ಅವರು ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತಾರೆ. ಆಗ ಮಾತ್ರ ಅವರು ಕೋಡ್ ವಿಶ್ಲೇಷಕದ ನಿಯಮಿತ ಬಳಕೆಯಿಂದ ಪ್ರಯೋಜನವನ್ನು ಪಡೆಯಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಇಲ್ಲದಿದ್ದರೆ, ಹೊಸ ಎಚ್ಚರಿಕೆಗಳು ಹಳೆಯದರಲ್ಲಿ ಮುಳುಗುತ್ತವೆ ಮತ್ತು ಯಾರೂ ಅವರಿಗೆ ಗಮನ ಕೊಡುವುದಿಲ್ಲ.

ಕಂಪೈಲರ್ ಎಚ್ಚರಿಕೆಗಳಂತೆಯೇ ಇದು ಒಂದೇ ಸಾದೃಶ್ಯವಾಗಿದೆ. ಕಂಪೈಲರ್ ಎಚ್ಚರಿಕೆಗಳ ಸಂಖ್ಯೆಯನ್ನು 0 ನಲ್ಲಿ ಇರಿಸಲು ಅವರು ಶಿಫಾರಸು ಮಾಡುತ್ತಾರೆ ಎಂಬ ಕಾರಣವಿಲ್ಲದೆ ಅಲ್ಲ. 1000 ಎಚ್ಚರಿಕೆಗಳು ಇದ್ದಲ್ಲಿ, ನಂತರ 1001 ಇದ್ದಾಗ, ಯಾರೂ ಅದರ ಬಗ್ಗೆ ಗಮನ ಹರಿಸುವುದಿಲ್ಲ ಮತ್ತು ಈ ಹೊಸ ಎಚ್ಚರಿಕೆಯನ್ನು ಎಲ್ಲಿ ನೋಡಬೇಕು ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ.

ಈ ಕ್ಷಣದಲ್ಲಿ ಮೇಲಿನಿಂದ ಯಾರಾದರೂ ನಿಮ್ಮನ್ನು ಸ್ಥಿರ ಕೋಡ್ ವಿಶ್ಲೇಷಣೆಯನ್ನು ಬಳಸಲು ಒತ್ತಾಯಿಸಿದರೆ ಈ ಕಥೆಯಲ್ಲಿ ಕೆಟ್ಟ ವಿಷಯ. ಇದು ತಂಡವನ್ನು ದುರ್ಬಲಗೊಳಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಅವರ ದೃಷ್ಟಿಕೋನದಿಂದ ಹೆಚ್ಚುವರಿ ಅಧಿಕಾರಶಾಹಿ ಸಂಕೀರ್ಣತೆ ಇರುತ್ತದೆ, ಅದು ದಾರಿಯಲ್ಲಿ ಮಾತ್ರ ಸಿಗುತ್ತದೆ. ವಿಶ್ಲೇಷಕರ ವರದಿಗಳನ್ನು ಯಾರೂ ನೋಡುವುದಿಲ್ಲ, ಮತ್ತು ಎಲ್ಲಾ ಬಳಕೆಯು "ಕಾಗದದಲ್ಲಿ" ಮಾತ್ರ ಇರುತ್ತದೆ. ಆ. ಔಪಚಾರಿಕವಾಗಿ, ವಿಶ್ಲೇಷಣೆಯನ್ನು DevOps ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ನಿರ್ಮಿಸಲಾಗಿದೆ, ಆದರೆ ಪ್ರಾಯೋಗಿಕವಾಗಿ ಇದು ಯಾರಿಗೂ ಪ್ರಯೋಜನವಾಗುವುದಿಲ್ಲ. ಕಾನ್ಫರೆನ್ಸ್ ಭಾಗವಹಿಸುವವರಿಂದ ನಾವು ಬೂತ್‌ಗಳಲ್ಲಿ ವಿವರವಾದ ಕಥೆಗಳನ್ನು ಕೇಳಿದ್ದೇವೆ. ಅಂತಹ ಅನುಭವವು ಪ್ರೋಗ್ರಾಮರ್‌ಗಳನ್ನು ದೀರ್ಘಕಾಲದವರೆಗೆ ಸ್ಥಿರ ವಿಶ್ಲೇಷಣಾ ಸಾಧನಗಳನ್ನು ಬಳಸದಂತೆ ನಿರುತ್ಸಾಹಗೊಳಿಸಬಹುದು.

ತಾಂತ್ರಿಕ ಸಾಲವನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸುವುದು ಮತ್ತು ತೆಗೆದುಹಾಕುವುದು

ವಾಸ್ತವವಾಗಿ, ಒಂದು ದೊಡ್ಡ ಹಳೆಯ ಯೋಜನೆಗೆ ಸಹ ಸ್ಥಿರ ವಿಶ್ಲೇಷಣೆಯನ್ನು ಪರಿಚಯಿಸುವಲ್ಲಿ ಕಷ್ಟ ಅಥವಾ ಭಯಾನಕ ಏನೂ ಇಲ್ಲ.

ಸಿಐ / ಸಿಡಿ

ಇದಲ್ಲದೆ, ವಿಶ್ಲೇಷಕವನ್ನು ತಕ್ಷಣವೇ ನಿರಂತರ ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಯ ಭಾಗವಾಗಿ ಮಾಡಬಹುದು. ಉದಾಹರಣೆಗೆ, PVS-ಸ್ಟುಡಿಯೋ ವಿತರಣೆಯು ನಿಮಗೆ ಅಗತ್ಯವಿರುವ ಸ್ವರೂಪದಲ್ಲಿ ವರದಿಯನ್ನು ಅನುಕೂಲಕರವಾಗಿ ವೀಕ್ಷಿಸಲು ಉಪಯುಕ್ತತೆಗಳನ್ನು ಹೊಂದಿದೆ ಮತ್ತು ಕೋಡ್‌ನ ಸಮಸ್ಯಾತ್ಮಕ ವಿಭಾಗಗಳನ್ನು ಬರೆದ ಡೆವಲಪರ್‌ಗಳಿಗೆ ಅಧಿಸೂಚನೆಗಳನ್ನು ಒಳಗೊಂಡಿದೆ. CI/CD ಸಿಸ್ಟಂಗಳಿಂದ PVS-ಸ್ಟುಡಿಯೋವನ್ನು ಪ್ರಾರಂಭಿಸಲು ಹೆಚ್ಚು ಆಸಕ್ತಿ ಹೊಂದಿರುವವರಿಗೆ, ಅನುಗುಣವಾದವುಗಳೊಂದಿಗೆ ನೀವೇ ಪರಿಚಿತರಾಗಿರುವಂತೆ ನಾನು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ ವಿಭಾಗ ದಸ್ತಾವೇಜನ್ನು ಮತ್ತು ಲೇಖನಗಳ ಸರಣಿ:

• PVS-ಸ್ಟುಡಿಯೋ ಮೋಡಗಳಿಗೆ ಹೋಗುತ್ತದೆ: ಅಜುರೆ ಡೆವೊಪ್ಸ್
• PVS-ಸ್ಟುಡಿಯೋ ಮೋಡಗಳಿಗೆ ಹೋಗುತ್ತದೆ: ಟ್ರಾವಿಸ್ CI
• PVS-ಸ್ಟುಡಿಯೋ ಮೋಡಗಳಿಗೆ ಹೋಗುತ್ತದೆ: GitLab CI/CD
• PVS-ಸ್ಟುಡಿಯೋ ಮೋಡಗಳಿಗೆ ಹೋಗುತ್ತದೆ: CircleCI

ಆದರೆ ಕೋಡ್ ವಿಶ್ಲೇಷಣಾ ಸಾಧನಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಮೊದಲ ಹಂತಗಳಲ್ಲಿ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ತಪ್ಪು ಧನಾತ್ಮಕ ವಿಷಯಗಳಿಗೆ ಹಿಂತಿರುಗಿ ನೋಡೋಣ.

ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ತಾಂತ್ರಿಕ ಸಾಲವನ್ನು ಸರಿಪಡಿಸುವುದು ಮತ್ತು ಹೊಸ ಎಚ್ಚರಿಕೆಗಳೊಂದಿಗೆ ವ್ಯವಹರಿಸುವುದು

ಆಧುನಿಕ ವಾಣಿಜ್ಯ ಸ್ಥಿರ ವಿಶ್ಲೇಷಕಗಳು ಹೊಸ ಅಥವಾ ಬದಲಾದ ಕೋಡ್‌ನಲ್ಲಿ ಕಂಡುಬರುವ ಹೊಸ ಎಚ್ಚರಿಕೆಗಳನ್ನು ಮಾತ್ರ ಅಧ್ಯಯನ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಈ ಕಾರ್ಯವಿಧಾನದ ಅನುಷ್ಠಾನವು ಬದಲಾಗುತ್ತದೆ, ಆದರೆ ಸಾರವು ಒಂದೇ ಆಗಿರುತ್ತದೆ. PVS-ಸ್ಟುಡಿಯೋ ಸ್ಟ್ಯಾಟಿಕ್ ವಿಶ್ಲೇಷಕದಲ್ಲಿ, ಈ ಕಾರ್ಯವನ್ನು ಈ ಕೆಳಗಿನಂತೆ ಅಳವಡಿಸಲಾಗಿದೆ.

ಸ್ಥಿರ ವಿಶ್ಲೇಷಣೆಯನ್ನು ತ್ವರಿತವಾಗಿ ಬಳಸಲು ಪ್ರಾರಂಭಿಸಲು, PVS-ಸ್ಟುಡಿಯೋ ಬಳಕೆದಾರರು ಎಚ್ಚರಿಕೆಗಳ ಸಾಮೂಹಿಕ ನಿಗ್ರಹಕ್ಕಾಗಿ ಕಾರ್ಯವಿಧಾನವನ್ನು ಬಳಸಲು ನಾವು ಸೂಚಿಸುತ್ತೇವೆ [6]. ಸಾಮಾನ್ಯ ಕಲ್ಪನೆಯು ಈ ಕೆಳಗಿನಂತಿರುತ್ತದೆ. ಬಳಕೆದಾರರು ವಿಶ್ಲೇಷಕವನ್ನು ಪ್ರಾರಂಭಿಸಿದರು ಮತ್ತು ಅನೇಕ ಎಚ್ಚರಿಕೆಗಳನ್ನು ಸ್ವೀಕರಿಸಿದರು. ಅನೇಕ ವರ್ಷಗಳಿಂದ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿರುವ ಯೋಜನೆಯು ಜೀವಂತವಾಗಿರುವುದರಿಂದ, ಅಭಿವೃದ್ಧಿ ಹೊಂದುತ್ತಿದೆ ಮತ್ತು ಹಣ ಸಂಪಾದಿಸುತ್ತಿದೆ, ನಂತರ ವರದಿಯಲ್ಲಿ ನಿರ್ಣಾಯಕ ದೋಷಗಳನ್ನು ಸೂಚಿಸುವ ಹೆಚ್ಚಿನ ಎಚ್ಚರಿಕೆಗಳು ಇರುವುದಿಲ್ಲ. ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ಕ್ಲಿಷ್ಟಕರವಾದ ದೋಷಗಳನ್ನು ಈಗಾಗಲೇ ಒಂದು ರೀತಿಯಲ್ಲಿ ಅಥವಾ ಇನ್ನೊಂದು ರೀತಿಯಲ್ಲಿ ಹೆಚ್ಚು ದುಬಾರಿ ವಿಧಾನಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಸರಿಪಡಿಸಲಾಗಿದೆ ಅಥವಾ ಗ್ರಾಹಕರ ಪ್ರತಿಕ್ರಿಯೆಗೆ ಧನ್ಯವಾದಗಳು. ಅಂತೆಯೇ, ವಿಶ್ಲೇಷಕವು ಪ್ರಸ್ತುತ ಕಂಡುಕೊಳ್ಳುವ ಎಲ್ಲವನ್ನೂ ತಾಂತ್ರಿಕ ಸಾಲವೆಂದು ಪರಿಗಣಿಸಬಹುದು, ಇದು ತಕ್ಷಣವೇ ತೊಡೆದುಹಾಕಲು ಪ್ರಯತ್ನಿಸಲು ಅಪ್ರಾಯೋಗಿಕವಾಗಿದೆ.

ಸದ್ಯಕ್ಕೆ ಈ ಎಚ್ಚರಿಕೆಗಳನ್ನು ಅಪ್ರಸ್ತುತವೆಂದು ಪರಿಗಣಿಸಲು PVS-ಸ್ಟುಡಿಯೋಗೆ ನೀವು ಹೇಳಬಹುದು (ನಂತರ ತಾಂತ್ರಿಕ ಸಾಲವನ್ನು ಉಳಿಸಿ), ಮತ್ತು ಅದು ಇನ್ನು ಮುಂದೆ ಅವುಗಳನ್ನು ತೋರಿಸುವುದಿಲ್ಲ. ವಿಶ್ಲೇಷಕವು ವಿಶೇಷ ಫೈಲ್ ಅನ್ನು ರಚಿಸುತ್ತದೆ, ಅಲ್ಲಿ ಅದು ಇನ್ನೂ ಆಸಕ್ತಿದಾಯಕವಲ್ಲದ ದೋಷಗಳ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಉಳಿಸುತ್ತದೆ. ಮತ್ತು ಈಗ PVS-ಸ್ಟುಡಿಯೋ ಹೊಸ ಅಥವಾ ಬದಲಾದ ಕೋಡ್‌ಗೆ ಮಾತ್ರ ಎಚ್ಚರಿಕೆಗಳನ್ನು ನೀಡುತ್ತದೆ. ಇದಲ್ಲದೆ, ಇದೆಲ್ಲವನ್ನೂ ಜಾಣತನದಿಂದ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಮೂಲ ಕೋಡ್ ಫೈಲ್‌ನ ಪ್ರಾರಂಭಕ್ಕೆ ಖಾಲಿ ರೇಖೆಯನ್ನು ಸೇರಿಸಿದರೆ, ವಾಸ್ತವವಾಗಿ, ಏನೂ ಬದಲಾಗಿಲ್ಲ ಮತ್ತು ಮೌನವಾಗಿ ಮುಂದುವರಿಯುತ್ತದೆ ಎಂದು ವಿಶ್ಲೇಷಕ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತಾನೆ. ಈ ಮಾರ್ಕ್ಅಪ್ ಫೈಲ್ ಅನ್ನು ಆವೃತ್ತಿ ನಿಯಂತ್ರಣ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಇರಿಸಬಹುದು. ಫೈಲ್ ದೊಡ್ಡದಾಗಿದೆ, ಆದರೆ ಇದು ಸಮಸ್ಯೆ ಅಲ್ಲ, ಏಕೆಂದರೆ ಅದನ್ನು ಆಗಾಗ್ಗೆ ಸಂಗ್ರಹಿಸುವುದರಲ್ಲಿ ಯಾವುದೇ ಅರ್ಥವಿಲ್ಲ.

ಈಗ ಎಲ್ಲಾ ಪ್ರೋಗ್ರಾಮರ್‌ಗಳು ಹೊಸ ಅಥವಾ ಬದಲಾದ ಕೋಡ್‌ಗೆ ಸಂಬಂಧಿಸಿದ ಎಚ್ಚರಿಕೆಗಳನ್ನು ನೋಡುತ್ತಾರೆ. ಹೀಗಾಗಿ, ಮರುದಿನದಿಂದ ಅವರು ಹೇಳಿದಂತೆ ನೀವು ವಿಶ್ಲೇಷಕವನ್ನು ಬಳಸಲು ಪ್ರಾರಂಭಿಸಬಹುದು. ಮತ್ತು ನೀವು ನಂತರ ತಾಂತ್ರಿಕ ಸಾಲಕ್ಕೆ ಹಿಂತಿರುಗಬಹುದು ಮತ್ತು ಕ್ರಮೇಣ ದೋಷಗಳನ್ನು ಸರಿಪಡಿಸಬಹುದು ಮತ್ತು ವಿಶ್ಲೇಷಕವನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು.

ಆದ್ದರಿಂದ, ದೊಡ್ಡ ಹಳೆಯ ಯೋಜನೆಯಲ್ಲಿ ವಿಶ್ಲೇಷಕದ ಅನುಷ್ಠಾನದ ಮೊದಲ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲಾಗಿದೆ. ತಾಂತ್ರಿಕ ಸಾಲದೊಂದಿಗೆ ಏನು ಮಾಡಬೇಕೆಂದು ಈಗ ಲೆಕ್ಕಾಚಾರ ಮಾಡೋಣ.

ದೋಷ ಪರಿಹಾರಗಳು ಮತ್ತು ಮರುಫಲಕಗಳು

ಬೃಹತ್ ಪ್ರಮಾಣದಲ್ಲಿ ನಿಗ್ರಹಿಸಲಾದ ವಿಶ್ಲೇಷಕ ಎಚ್ಚರಿಕೆಗಳನ್ನು ವಿಶ್ಲೇಷಿಸಲು ಮತ್ತು ಕ್ರಮೇಣ ಅವುಗಳನ್ನು ನಿಭಾಯಿಸಲು ಸ್ವಲ್ಪ ಸಮಯವನ್ನು ನಿಗದಿಪಡಿಸುವುದು ಸರಳ ಮತ್ತು ಅತ್ಯಂತ ನೈಸರ್ಗಿಕ ವಿಷಯವಾಗಿದೆ. ಎಲ್ಲೋ ನೀವು ಕೋಡ್‌ನಲ್ಲಿ ದೋಷಗಳನ್ನು ಸರಿಪಡಿಸಬೇಕು, ಎಲ್ಲೋ ನೀವು ಕೋಡ್ ಸಮಸ್ಯಾತ್ಮಕವಾಗಿಲ್ಲ ಎಂದು ವಿಶ್ಲೇಷಕರಿಗೆ ಹೇಳಲು ರಿಫ್ಯಾಕ್ಟರ್ ಮಾಡಬೇಕು. ಸರಳ ಉದಾಹರಣೆ:

if (a = b)

ಹೆಚ್ಚಿನ C++ ಕಂಪೈಲರ್‌ಗಳು ಮತ್ತು ವಿಶ್ಲೇಷಕರು ಅಂತಹ ಕೋಡ್ ಬಗ್ಗೆ ದೂರು ನೀಡುತ್ತಾರೆ, ಏಕೆಂದರೆ ಅವರು ನಿಜವಾಗಿಯೂ ಬರೆಯಲು ಬಯಸಿದ ಹೆಚ್ಚಿನ ಸಂಭವನೀಯತೆ ಇದೆ. (ಎ == ಬಿ). ಆದರೆ ಮಾತನಾಡದ ಒಪ್ಪಂದವಿದೆ, ಮತ್ತು ಇದನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ದಸ್ತಾವೇಜನ್ನು ಗಮನಿಸಲಾಗಿದೆ, ಹೆಚ್ಚುವರಿ ಆವರಣಗಳಿದ್ದರೆ, ಪ್ರೋಗ್ರಾಮರ್ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಅಂತಹ ಕೋಡ್ ಅನ್ನು ಬರೆದಿದ್ದಾರೆ ಎಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಪ್ರತಿಜ್ಞೆ ಮಾಡುವ ಅಗತ್ಯವಿಲ್ಲ. ಉದಾಹರಣೆಗೆ, ರೋಗನಿರ್ಣಯಕ್ಕಾಗಿ PVS-ಸ್ಟುಡಿಯೋ ದಾಖಲಾತಿಯಲ್ಲಿ V559 (CWE-481) ಕೆಳಗಿನ ಸಾಲನ್ನು ಸರಿಯಾದ ಮತ್ತು ಸುರಕ್ಷಿತವೆಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ ಎಂದು ಸ್ಪಷ್ಟವಾಗಿ ಬರೆಯಲಾಗಿದೆ:

if ((a = b))

ಇನ್ನೊಂದು ಉದಾಹರಣೆ. ಈ C++ ಕೋಡ್‌ನಲ್ಲಿ ಅದು ಮರೆತುಹೋಗಿದೆಯೇ? ಬ್ರೇಕ್ ಅಥವಾ ಇಲ್ಲವೇ?

case A:
  foo();
case B:
  bar();
  break;

PVS-ಸ್ಟುಡಿಯೋ ವಿಶ್ಲೇಷಕವು ಇಲ್ಲಿ ಎಚ್ಚರಿಕೆಯನ್ನು ನೀಡುತ್ತದೆ V796 (CWE-484). ಇದು ದೋಷವಾಗಿರದೆ ಇರಬಹುದು, ಈ ಸಂದರ್ಭದಲ್ಲಿ ನೀವು ಗುಣಲಕ್ಷಣವನ್ನು ಸೇರಿಸುವ ಮೂಲಕ ಪಾರ್ಸರ್‌ಗೆ ಸುಳಿವು ನೀಡಬೇಕು [[ಪತನದ ಮೂಲಕ]] ಅಥವಾ ಉದಾಹರಣೆಗೆ __ಗುಣಲಕ್ಷಣ__((ಫಾಲ್ಥ್ರೂ)):

case A:
  foo();
  [[fallthrough]];
case B:
  bar();
  break;

ಅಂತಹ ಕೋಡ್ ಬದಲಾವಣೆಗಳು ದೋಷವನ್ನು ಸರಿಪಡಿಸುವುದಿಲ್ಲ ಎಂದು ಹೇಳಬಹುದು. ಹೌದು, ಇದು ನಿಜ, ಆದರೆ ಇದು ಎರಡು ಉಪಯುಕ್ತ ಕೆಲಸಗಳನ್ನು ಮಾಡುತ್ತದೆ. ಮೊದಲನೆಯದಾಗಿ, ವಿಶ್ಲೇಷಕ ವರದಿಯು ತಪ್ಪು ಧನಾತ್ಮಕತೆಯನ್ನು ತೊಡೆದುಹಾಕುತ್ತದೆ. ಎರಡನೆಯದಾಗಿ, ಅದರ ನಿರ್ವಹಣೆಯಲ್ಲಿ ತೊಡಗಿರುವ ಜನರಿಗೆ ಕೋಡ್ ಹೆಚ್ಚು ಅರ್ಥವಾಗುವಂತಹದ್ದಾಗಿದೆ. ಮತ್ತು ಇದು ಬಹಳ ಮುಖ್ಯ! ಇದಕ್ಕಾಗಿ ಮಾತ್ರ, ಕೋಡ್ ಅನ್ನು ಸ್ಪಷ್ಟಪಡಿಸಲು ಮತ್ತು ನಿರ್ವಹಿಸಲು ಸುಲಭವಾಗುವಂತೆ ಸಣ್ಣ ಪುನರಾವರ್ತನೆಗಳನ್ನು ಕೈಗೊಳ್ಳುವುದು ಯೋಗ್ಯವಾಗಿದೆ. ವಿಶ್ಲೇಷಕವು "ಬ್ರೇಕ್" ಅಗತ್ಯವಿದೆಯೇ ಅಥವಾ ಇಲ್ಲವೇ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳದ ಕಾರಣ, ಸಹ ಪ್ರೋಗ್ರಾಮರ್ಗಳಿಗೆ ಇದು ಅಸ್ಪಷ್ಟವಾಗಿರುತ್ತದೆ.

ದೋಷ ಪರಿಹಾರಗಳು ಮತ್ತು ರಿಫ್ಯಾಕ್ಟರಿಂಗ್‌ಗಳ ಜೊತೆಗೆ, ನೀವು ಸ್ಪಷ್ಟವಾಗಿ ತಪ್ಪು ವಿಶ್ಲೇಷಕ ಎಚ್ಚರಿಕೆಗಳನ್ನು ನಿರ್ದಿಷ್ಟವಾಗಿ ನಿಗ್ರಹಿಸಬಹುದು. ಕೆಲವು ಅಪ್ರಸ್ತುತ ರೋಗನಿರ್ಣಯಗಳನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಬಹುದು. ಉದಾಹರಣೆಗೆ, ಎಚ್ಚರಿಕೆಗಳು ಅರ್ಥಹೀನವೆಂದು ಯಾರಾದರೂ ಭಾವಿಸುತ್ತಾರೆ V550 ಫ್ಲೋಟ್/ಡಬಲ್ ಮೌಲ್ಯಗಳನ್ನು ಹೋಲಿಸುವ ಬಗ್ಗೆ. ಮತ್ತು ಕೆಲವರು ಅವುಗಳನ್ನು ಪ್ರಮುಖ ಮತ್ತು ಅಧ್ಯಯನಕ್ಕೆ ಯೋಗ್ಯವೆಂದು ವರ್ಗೀಕರಿಸುತ್ತಾರೆ [7]. ಯಾವ ಎಚ್ಚರಿಕೆಗಳನ್ನು ಪ್ರಸ್ತುತವೆಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಯಾವುದು ಅಲ್ಲ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಲು ಅಭಿವೃದ್ಧಿ ತಂಡಕ್ಕೆ ಬಿಟ್ಟದ್ದು.

ತಪ್ಪು ಎಚ್ಚರಿಕೆಗಳನ್ನು ನಿಗ್ರಹಿಸಲು ಇತರ ಮಾರ್ಗಗಳಿವೆ. ಉದಾಹರಣೆಗೆ, ಮ್ಯಾಕ್ರೋ ಮಾರ್ಕ್ಅಪ್ ಅನ್ನು ಮೊದಲೇ ಉಲ್ಲೇಖಿಸಲಾಗಿದೆ. ಇದೆಲ್ಲವನ್ನೂ ದಸ್ತಾವೇಜನ್ನು ಹೆಚ್ಚು ವಿವರವಾಗಿ ವಿವರಿಸಲಾಗಿದೆ. ತಪ್ಪಾದ ಧನಾತ್ಮಕತೆಗಳೊಂದಿಗೆ ನೀವು ಕ್ರಮೇಣವಾಗಿ ಮತ್ತು ವ್ಯವಸ್ಥಿತವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದರೆ, ಅವುಗಳಲ್ಲಿ ಯಾವುದೇ ತಪ್ಪಿಲ್ಲ ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಅತ್ಯಂತ ಮುಖ್ಯವಾದ ವಿಷಯ. ಹೆಚ್ಚಿನ ಆಸಕ್ತಿರಹಿತ ಎಚ್ಚರಿಕೆಗಳು ಕಾನ್ಫಿಗರೇಶನ್ ನಂತರ ಕಣ್ಮರೆಯಾಗುತ್ತವೆ ಮತ್ತು ನಿಜವಾಗಿಯೂ ಎಚ್ಚರಿಕೆಯಿಂದ ಅಧ್ಯಯನ ಮಾಡುವ ಮತ್ತು ಕೋಡ್‌ನಲ್ಲಿ ಕೆಲವು ಬದಲಾವಣೆಗಳ ಅಗತ್ಯವಿರುವ ಸ್ಥಳಗಳು ಮಾತ್ರ ಉಳಿದಿವೆ.

ಅಲ್ಲದೆ, ಯಾವುದೇ ತೊಂದರೆಗಳು ಉಂಟಾದರೆ ನಾವು ಯಾವಾಗಲೂ ನಮ್ಮ ಗ್ರಾಹಕರಿಗೆ PVS-ಸ್ಟುಡಿಯೊವನ್ನು ಹೊಂದಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತೇವೆ. ಇದಲ್ಲದೆ, ನಾವೇ ತಪ್ಪು ಎಚ್ಚರಿಕೆಗಳನ್ನು ತೆಗೆದುಹಾಕಿದಾಗ ಮತ್ತು ದೋಷಗಳನ್ನು ಸರಿಪಡಿಸಿದಾಗ ಪ್ರಕರಣಗಳಿವೆ [8]. ಒಂದು ವೇಳೆ, ವಿಸ್ತೃತ ಸಹಕಾರಕ್ಕಾಗಿ ಈ ಆಯ್ಕೆಯು ಸಹ ಸಾಧ್ಯ ಎಂದು ನಮೂದಿಸಲು ನಾನು ನಿರ್ಧರಿಸಿದೆ :).

ರಾಟ್ಚೆಟ್ ವಿಧಾನ

ಸ್ಥಿರ ವಿಶ್ಲೇಷಕ ಎಚ್ಚರಿಕೆಯನ್ನು ತೆಗೆದುಹಾಕುವ ಮೂಲಕ ಕೋಡ್ ಗುಣಮಟ್ಟವನ್ನು ಕ್ರಮೇಣ ಸುಧಾರಿಸಲು ಮತ್ತೊಂದು ಆಸಕ್ತಿದಾಯಕ ವಿಧಾನವಿದೆ. ಬಾಟಮ್ ಲೈನ್ ಎಂಬುದು ಎಚ್ಚರಿಕೆಗಳ ಸಂಖ್ಯೆಯು ಕಡಿಮೆಯಾಗಬಹುದು.

ಸ್ಥಿರ ವಿಶ್ಲೇಷಕದಿಂದ ನೀಡಲಾದ ಎಚ್ಚರಿಕೆಗಳ ಸಂಖ್ಯೆಯನ್ನು ದಾಖಲಿಸಲಾಗಿದೆ. ಗುಣಮಟ್ಟದ ಗೇಟ್ ಅನ್ನು ಈಗ ನೀವು ಕಾರ್ಯಾಚರಣೆಗಳ ಸಂಖ್ಯೆಯನ್ನು ಹೆಚ್ಚಿಸದ ಕೋಡ್ ಅನ್ನು ಮಾತ್ರ ನಮೂದಿಸಬಹುದಾದ ರೀತಿಯಲ್ಲಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ. ಪರಿಣಾಮವಾಗಿ, ಅಲಾರಂಗಳ ಸಂಖ್ಯೆಯನ್ನು ಕ್ರಮೇಣ ಕಡಿಮೆ ಮಾಡುವ ಪ್ರಕ್ರಿಯೆಯು ವಿಶ್ಲೇಷಕವನ್ನು ಸರಿಹೊಂದಿಸುವ ಮೂಲಕ ಮತ್ತು ದೋಷಗಳನ್ನು ಸರಿಪಡಿಸುವ ಮೂಲಕ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ.

ಒಬ್ಬ ವ್ಯಕ್ತಿಯು ಸ್ವಲ್ಪ ಮೋಸ ಮಾಡಲು ಬಯಸಿದರೂ ಮತ್ತು ಗುಣಮಟ್ಟದ ಗೇಟ್ ಅನ್ನು ತನ್ನ ಹೊಸ ಕೋಡ್‌ನಲ್ಲಿ ಎಚ್ಚರಿಕೆಗಳನ್ನು ತೆಗೆದುಹಾಕುವ ಮೂಲಕ ಹಾದುಹೋಗಲು ನಿರ್ಧರಿಸಿದರೂ, ಆದರೆ ಹಳೆಯ ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಕೋಡ್ ಅನ್ನು ಸುಧಾರಿಸುವ ಮೂಲಕ, ಇದು ಭಯಾನಕವಲ್ಲ. ಎಲ್ಲಾ ಒಂದೇ, ರಾಟ್ಚೆಟ್ ಒಂದು ದಿಕ್ಕಿನಲ್ಲಿ ತಿರುಗುತ್ತದೆ, ಮತ್ತು ಕ್ರಮೇಣ ದೋಷಗಳ ಸಂಖ್ಯೆ ಕಡಿಮೆಯಾಗುತ್ತದೆ. ಒಬ್ಬ ವ್ಯಕ್ತಿಯು ತನ್ನದೇ ಆದ ಹೊಸ ದೋಷಗಳನ್ನು ಸರಿಪಡಿಸಲು ಬಯಸದಿದ್ದರೂ ಸಹ, ಅವನು ಇನ್ನೂ ನೆರೆಯ ಕೋಡ್‌ನಲ್ಲಿ ಏನನ್ನಾದರೂ ಸುಧಾರಿಸಬೇಕಾಗುತ್ತದೆ. ಕೆಲವು ಹಂತದಲ್ಲಿ, ಎಚ್ಚರಿಕೆಗಳ ಸಂಖ್ಯೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಸುಲಭವಾದ ಮಾರ್ಗಗಳು ಕೊನೆಗೊಳ್ಳುತ್ತವೆ ಮತ್ತು ನಿಜವಾದ ದೋಷಗಳನ್ನು ಸರಿಪಡಿಸಿದಾಗ ಒಂದು ಹಂತವು ಬರುತ್ತದೆ.

ಈ ವಿಧಾನವನ್ನು ಇವಾನ್ ಪೊನೊಮರೆವ್ ಅವರ ಕುತೂಹಲಕಾರಿ ಲೇಖನದಲ್ಲಿ ಹೆಚ್ಚು ವಿವರವಾಗಿ ವಿವರಿಸಲಾಗಿದೆ "ದೋಷಗಳನ್ನು ಹುಡುಕಲು ಬಳಸುವ ಬದಲು ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಸ್ಥಿರ ವಿಶ್ಲೇಷಣೆಯನ್ನು ಅಳವಡಿಸಿ", ಕೋಡ್ ಗುಣಮಟ್ಟವನ್ನು ಸುಧಾರಿಸಲು ಆಸಕ್ತಿ ಹೊಂದಿರುವ ಯಾರಿಗಾದರೂ ಓದಲು ನಾನು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ.

ಲೇಖನದ ಲೇಖಕರು ಈ ವಿಷಯದ ಬಗ್ಗೆ ವರದಿಯನ್ನು ಸಹ ಹೊಂದಿದ್ದಾರೆ: "ನಿರಂತರ ಸ್ಥಿರ ವಿಶ್ಲೇಷಣೆ".

ತೀರ್ಮಾನಕ್ಕೆ

ಈ ಲೇಖನದ ನಂತರ, ಓದುಗರು ಸ್ಥಿರ ವಿಶ್ಲೇಷಣಾ ಸಾಧನಗಳನ್ನು ಹೆಚ್ಚು ಸ್ವೀಕರಿಸುತ್ತಾರೆ ಮತ್ತು ಅವುಗಳನ್ನು ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಅಳವಡಿಸಲು ಬಯಸುತ್ತಾರೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ನೀವು ಯಾವುದೇ ಪ್ರಶ್ನೆಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ನಾವು ಯಾವಾಗಲೂ ಸಿದ್ಧರಿದ್ದೇವೆ ಸಲಹೆ ನಮ್ಮ ಸ್ಥಿರ ವಿಶ್ಲೇಷಕ PVS-ಸ್ಟುಡಿಯೊದ ಬಳಕೆದಾರರು ಮತ್ತು ಅದರ ಅನುಷ್ಠಾನಕ್ಕೆ ಸಹಾಯ ಮಾಡುತ್ತಾರೆ.

ಸ್ಥಿರ ವಿಶ್ಲೇಷಣೆಯು ನಿಜವಾಗಿಯೂ ಅನುಕೂಲಕರ ಮತ್ತು ಉಪಯುಕ್ತವಾಗಿದೆಯೇ ಎಂಬುದರ ಕುರಿತು ಇತರ ವಿಶಿಷ್ಟ ಅನುಮಾನಗಳಿವೆ. "PVS-Studio ಸ್ಟ್ಯಾಟಿಕ್ ಕೋಡ್ ವಿಶ್ಲೇಷಕವನ್ನು ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಪರಿಚಯಿಸಲು ಕಾರಣಗಳು" ಎಂಬ ಪ್ರಕಟಣೆಯಲ್ಲಿ ನಾನು ಈ ಹೆಚ್ಚಿನ ಅನುಮಾನಗಳನ್ನು ಹೋಗಲಾಡಿಸಲು ಪ್ರಯತ್ನಿಸಿದೆ.9].

ನಿಮ್ಮ ಗಮನಕ್ಕೆ ಧನ್ಯವಾದಗಳು ಮತ್ತು ಬನ್ನಿ скачать ಮತ್ತು PVS-ಸ್ಟುಡಿಯೋ ವಿಶ್ಲೇಷಕವನ್ನು ಪ್ರಯತ್ನಿಸಿ.

ಹೆಚ್ಚುವರಿ ಲಿಂಕ್‌ಗಳು

1. ಆಂಡ್ರೆ ಕಾರ್ಪೋವ್. C ಮತ್ತು C++ ಕೋಡ್‌ಗಾಗಿ PVS-ಸ್ಟುಡಿಯೋ ವಿಶ್ಲೇಷಕವು ಉತ್ಪಾದಿಸುವ ಆಸಕ್ತಿದಾಯಕ ಎಚ್ಚರಿಕೆಗಳನ್ನು ನಾನು ತ್ವರಿತವಾಗಿ ಹೇಗೆ ನೋಡಬಹುದು?
2. ವಿಕಿಪೀಡಿಯ. ರೈಸ್ ಪ್ರಮೇಯ.
3. ಆಂಡ್ರೆ ಕಾರ್ಪೋವ್, ವಿಕ್ಟೋರಿಯಾ ಖನೀವಾ. ಪ್ರೋಗ್ರಾಂ ಮೂಲ ಕೋಡ್‌ನ ಸ್ಥಿರ ವಿಶ್ಲೇಷಣೆಯಲ್ಲಿ ಯಂತ್ರ ಕಲಿಕೆಯನ್ನು ಬಳಸುವುದು.
4. PVS-ಸ್ಟುಡಿಯೋ. ದಾಖಲೆ. ಹೆಚ್ಚುವರಿ ರೋಗನಿರ್ಣಯ ಸೆಟ್ಟಿಂಗ್‌ಗಳು.
5. ಆಂಡ್ರೆ ಕಾರ್ಪೋವ್. EFL ಕೋರ್ ಲೈಬ್ರರಿಗಳ ಉದಾಹರಣೆಯನ್ನು ಬಳಸಿಕೊಂಡು PVS-ಸ್ಟುಡಿಯೋ ವಿಶ್ಲೇಷಕದ ಗುಣಲಕ್ಷಣಗಳು, 10-15% ತಪ್ಪು ಧನಾತ್ಮಕ.
6. PVS-ಸ್ಟುಡಿಯೋ. ದಾಖಲೆ. ವಿಶ್ಲೇಷಕ ಸಂದೇಶಗಳ ಸಾಮೂಹಿಕ ನಿಗ್ರಹ.
7. ಇವಾನ್ ಆಂಡ್ರಿಯಾಶಿನ್. ಎಕ್ಸ್-ರೇ ಎಂಡೋವಾಸ್ಕುಲರ್ ಸರ್ಜರಿಯ ಶೈಕ್ಷಣಿಕ ಸಿಮ್ಯುಲೇಟರ್‌ನ ನಮ್ಮ ಯೋಜನೆಯಲ್ಲಿ ನಾವು ಸ್ಥಿರ ವಿಶ್ಲೇಷಣೆಯನ್ನು ಹೇಗೆ ಪರೀಕ್ಷಿಸಿದ್ದೇವೆ ಎಂಬುದರ ಕುರಿತು.
8. ಪಾವೆಲ್ ಎರೆಮೀವ್, ಸ್ವ್ಯಾಟೋಸ್ಲಾವ್ ರಾಜ್ಮಿಸ್ಲೋವ್. PVS-ಸ್ಟುಡಿಯೋ ತಂಡವು ಅನ್ರಿಯಲ್ ಎಂಜಿನ್ ಕೋಡ್ ಅನ್ನು ಹೇಗೆ ಸುಧಾರಿಸಿದೆ.
9. ಆಂಡ್ರೆ ಕಾರ್ಪೋವ್. ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಸ್ಥಿರ ಕೋಡ್ ವಿಶ್ಲೇಷಕ PVS-ಸ್ಟುಡಿಯೊವನ್ನು ಪರಿಚಯಿಸಲು ಕಾರಣಗಳು.

ನೀವು ಈ ಲೇಖನವನ್ನು ಇಂಗ್ಲಿಷ್ ಮಾತನಾಡುವ ಪ್ರೇಕ್ಷಕರೊಂದಿಗೆ ಹಂಚಿಕೊಳ್ಳಲು ಬಯಸಿದರೆ, ದಯವಿಟ್ಟು ಅನುವಾದ ಲಿಂಕ್ ಬಳಸಿ: ಆಂಡ್ರೆ ಕಾರ್ಪೋವ್. ಲೆಗಸಿ ಪ್ರಾಜೆಕ್ಟ್‌ನಲ್ಲಿ ಸ್ಟ್ಯಾಟಿಕ್ ಕೋಡ್ ವಿಶ್ಲೇಷಕವನ್ನು ಹೇಗೆ ಪರಿಚಯಿಸುವುದು ಮತ್ತು ತಂಡವನ್ನು ನಿರುತ್ಸಾಹಗೊಳಿಸಬಾರದು.

ಮೂಲ: www.habr.com