ਟੀਮ ਨੂੰ ਨਿਰਾਸ਼ ਕੀਤੇ ਬਿਨਾਂ ਇੱਕ ਵਿਰਾਸਤੀ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਇੱਕ ਸਥਿਰ ਕੋਡ ਵਿਸ਼ਲੇਸ਼ਕ ਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕਰਨਾ ਹੈ

ਸਥਿਰ ਕੋਡ ਵਿਸ਼ਲੇਸ਼ਕ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨਾ ਆਸਾਨ ਹੈ। ਪਰ ਇਸਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ, ਖਾਸ ਕਰਕੇ ਇੱਕ ਵੱਡੇ ਪੁਰਾਣੇ ਪ੍ਰੋਜੈਕਟ ਦੇ ਵਿਕਾਸ ਵਿੱਚ, ਹੁਨਰ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ. ਜੇਕਰ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਵਿਸ਼ਲੇਸ਼ਕ ਕੰਮ ਨੂੰ ਜੋੜ ਸਕਦਾ ਹੈ, ਵਿਕਾਸ ਨੂੰ ਹੌਲੀ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਟੀਮ ਨੂੰ ਘਟਾ ਸਕਦਾ ਹੈ। ਆਉ ਇਸ ਬਾਰੇ ਸੰਖੇਪ ਵਿੱਚ ਗੱਲ ਕਰੀਏ ਕਿ ਵਿਕਾਸ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਸਥਿਰ ਵਿਸ਼ਲੇਸ਼ਣ ਦੇ ਏਕੀਕਰਣ ਨੂੰ ਕਿਵੇਂ ਸਹੀ ਢੰਗ ਨਾਲ ਪਹੁੰਚਣਾ ਹੈ ਅਤੇ ਇਸਨੂੰ CI/CD ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਵਰਤਣਾ ਸ਼ੁਰੂ ਕਰਨਾ ਹੈ।

ਜਾਣ ਪਛਾਣ

ਹਾਲ ਹੀ ਵਿੱਚ ਮੇਰਾ ਧਿਆਨ ਪ੍ਰਕਾਸ਼ਨ ਵੱਲ ਖਿੱਚਿਆ ਗਿਆ ਸੀ "ਟੀਮ ਨੂੰ ਹਾਵੀ ਕੀਤੇ ਬਿਨਾਂ ਸਥਿਰ ਵਿਸ਼ਲੇਸ਼ਣ ਨਾਲ ਸ਼ੁਰੂਆਤ ਕਰਨਾ". ਇੱਕ ਪਾਸੇ, ਇਹ ਇੱਕ ਵਧੀਆ ਲੇਖ ਹੈ ਜਿਸ ਨਾਲ ਜਾਣੂ ਹੋਣ ਦੇ ਯੋਗ ਹੈ. ਦੂਜੇ ਪਾਸੇ, ਇਹ ਮੈਨੂੰ ਜਾਪਦਾ ਹੈ ਕਿ ਇਹ ਅਜੇ ਵੀ ਇਸ ਗੱਲ ਦਾ ਪੂਰਾ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦਾ ਹੈ ਕਿ ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਸਥਿਰ ਵਿਸ਼ਲੇਸ਼ਣ ਨੂੰ ਕਿਵੇਂ ਦਰਦਨਾਕ ਢੰਗ ਨਾਲ ਲਾਗੂ ਕਰਨਾ ਹੈ. ਲੇਖ ਕਹਿੰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਤਕਨੀਕੀ ਕਰਜ਼ੇ ਨੂੰ ਸਵੀਕਾਰ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਸਿਰਫ ਨਵੇਂ ਕੋਡ 'ਤੇ ਕੰਮ ਕਰ ਸਕਦੇ ਹੋ, ਪਰ ਇਸ ਤਕਨੀਕੀ ਕਰਜ਼ੇ ਦਾ ਬਾਅਦ ਵਿੱਚ ਕੀ ਕਰਨਾ ਹੈ ਇਸ ਦਾ ਕੋਈ ਜਵਾਬ ਨਹੀਂ ਹੈ।

ਸਾਡੀ PVS-ਸਟੂਡੀਓ ਟੀਮ ਇਸ ਵਿਸ਼ੇ 'ਤੇ ਆਪਣਾ ਵਿਚਾਰ ਪੇਸ਼ ਕਰਦੀ ਹੈ। ਆਓ ਦੇਖੀਏ ਕਿ ਸਟੈਟਿਕ ਕੋਡ ਐਨਾਲਾਈਜ਼ਰ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਸਮੱਸਿਆ ਪਹਿਲੀ ਥਾਂ 'ਤੇ ਕਿਵੇਂ ਪੈਦਾ ਹੁੰਦੀ ਹੈ, ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਕਿਵੇਂ ਦੂਰ ਕਰਨਾ ਹੈ, ਅਤੇ ਤਕਨੀਕੀ ਕਰਜ਼ੇ ਨੂੰ ਕਿਵੇਂ ਦਰਦ ਰਹਿਤ ਹੌਲੀ-ਹੌਲੀ ਖਤਮ ਕਰਨਾ ਹੈ।

ਮੁੱਦੇ

ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਲਾਂਚ ਕਰਨਾ ਅਤੇ ਦੇਖਣਾ ਮੁਸ਼ਕਲ ਨਹੀਂ ਹੁੰਦਾ ਕਿ ਇੱਕ ਸਥਿਰ ਵਿਸ਼ਲੇਸ਼ਕ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ [1]। ਤੁਸੀਂ ਕੋਡ ਵਿੱਚ ਦਿਲਚਸਪ ਗਲਤੀਆਂ ਜਾਂ ਡਰਾਉਣੀਆਂ ਸੰਭਾਵੀ ਕਮਜ਼ੋਰੀਆਂ ਵੀ ਦੇਖ ਸਕਦੇ ਹੋ। ਤੁਸੀਂ ਕੁਝ ਠੀਕ ਵੀ ਕਰ ਸਕਦੇ ਹੋ, ਪਰ ਫਿਰ ਬਹੁਤ ਸਾਰੇ ਪ੍ਰੋਗਰਾਮਰ ਹਾਰ ਦਿੰਦੇ ਹਨ।

ਸਾਰੇ ਸਥਿਰ ਵਿਸ਼ਲੇਸ਼ਕ ਝੂਠੇ ਸਕਾਰਾਤਮਕ ਪੈਦਾ ਕਰਦੇ ਹਨ। ਇਹ ਸਥਿਰ ਕੋਡ ਵਿਸ਼ਲੇਸ਼ਣ ਵਿਧੀ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ, ਅਤੇ ਇਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਆਮ ਸਥਿਤੀ ਵਿੱਚ, ਇਹ ਇੱਕ ਅਣਸੁਲਝੀ ਸਮੱਸਿਆ ਹੈ, ਜਿਵੇਂ ਕਿ ਰਾਈਸ ਦੇ ਪ੍ਰਮੇਏ ਦੁਆਰਾ ਪੁਸ਼ਟੀ ਕੀਤੀ ਗਈ ਹੈ [2]। ਮਸ਼ੀਨ ਲਰਨਿੰਗ ਐਲਗੋਰਿਦਮ ਵੀ ਮਦਦ ਨਹੀਂ ਕਰਨਗੇ।3]। ਭਾਵੇਂ ਕੋਈ ਵਿਅਕਤੀ ਹਮੇਸ਼ਾ ਇਹ ਨਹੀਂ ਦੱਸ ਸਕਦਾ ਕਿ ਇਹ ਜਾਂ ਉਹ ਕੋਡ ਗਲਤ ਹੈ, ਫਿਰ ਤੁਹਾਨੂੰ ਪ੍ਰੋਗਰਾਮ ਤੋਂ ਇਸਦੀ ਉਮੀਦ ਨਹੀਂ ਕਰਨੀ ਚਾਹੀਦੀ :).

ਜੇ ਸਟੈਟਿਕ ਐਨਾਲਾਈਜ਼ਰ ਪਹਿਲਾਂ ਤੋਂ ਹੀ ਕੌਂਫਿਗਰ ਕੀਤਾ ਗਿਆ ਹੈ ਤਾਂ ਗਲਤ ਸਕਾਰਾਤਮਕ ਕੋਈ ਸਮੱਸਿਆ ਨਹੀਂ ਹਨ:

• ਅਸਮਰੱਥ ਅਪ੍ਰਸੰਗਿਕ ਨਿਯਮ ਸੈੱਟ;
• ਕੁਝ ਅਪ੍ਰਸੰਗਿਕ ਡਾਇਗਨੌਸਟਿਕਸ ਨੂੰ ਅਸਮਰੱਥ ਕਰ ਦਿੱਤਾ ਗਿਆ ਹੈ;
• ਜੇਕਰ ਅਸੀਂ C ਜਾਂ C++ ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ, ਤਾਂ ਮੈਕਰੋਜ਼ ਨੂੰ ਮਾਰਕਅੱਪ ਕੀਤਾ ਗਿਆ ਹੈ ਜਿਸ ਵਿੱਚ ਖਾਸ ਕੰਸਟਰੱਕਟਸ ਹੁੰਦੇ ਹਨ ਜੋ ਹਰ ਜਗ੍ਹਾ ਜਿੱਥੇ ਅਜਿਹੇ ਮੈਕਰੋ ਵਰਤੇ ਜਾਂਦੇ ਹਨ, ਉੱਥੇ ਬੇਕਾਰ ਚੇਤਾਵਨੀਆਂ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ;
• ਆਪਣੇ ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਚਿੰਨ੍ਹਿਤ ਕੀਤਾ ਗਿਆ ਹੈ ਜੋ ਸਿਸਟਮ ਫੰਕਸ਼ਨਾਂ (ਇਸਦਾ ਆਪਣਾ ਐਨਾਲਾਗ) ਦੇ ਸਮਾਨ ਕਿਰਿਆਵਾਂ ਕਰਦੇ ਹਨ ਮੈਮਪੀਪੀ ਜ printf) [4];
• ਗਲਤ ਸਕਾਰਾਤਮਕ ਟਿੱਪਣੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਅਸਮਰੱਥ ਹਨ;
• ਅਤੇ ਇਸ ਤਰਾਂ.

ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਅਸੀਂ ਲਗਭਗ 10-15% ਦੀ ਘੱਟ ਗਲਤ ਸਕਾਰਾਤਮਕ ਦਰ ਦੀ ਉਮੀਦ ਕਰ ਸਕਦੇ ਹਾਂ [5]। ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, 9 ਵਿੱਚੋਂ 10 ਵਿਸ਼ਲੇਸ਼ਕ ਚੇਤਾਵਨੀਆਂ ਕੋਡ ਵਿੱਚ ਇੱਕ ਅਸਲ ਸਮੱਸਿਆ ਨੂੰ ਦਰਸਾਉਣਗੀਆਂ, ਜਾਂ ਘੱਟੋ-ਘੱਟ "ਮਜ਼ਬੂਤ-ਗੰਧ ਵਾਲਾ ਕੋਡ"। ਸਹਿਮਤ ਹੋਵੋ, ਇਹ ਦ੍ਰਿਸ਼ ਬਹੁਤ ਹੀ ਸੁਹਾਵਣਾ ਹੈ, ਅਤੇ ਵਿਸ਼ਲੇਸ਼ਕ ਪ੍ਰੋਗਰਾਮਰ ਦਾ ਅਸਲ ਦੋਸਤ ਹੈ.

ਵਾਸਤਵ ਵਿੱਚ, ਇੱਕ ਵੱਡੇ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ, ਸ਼ੁਰੂਆਤੀ ਤਸਵੀਰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੱਖਰੀ ਹੋਵੇਗੀ. ਵਿਸ਼ਲੇਸ਼ਕ ਵਿਰਾਸਤੀ ਕੋਡ ਲਈ ਸੈਂਕੜੇ ਜਾਂ ਹਜ਼ਾਰਾਂ ਚੇਤਾਵਨੀਆਂ ਜਾਰੀ ਕਰਦਾ ਹੈ। ਇਹ ਜਲਦੀ ਸਮਝਣਾ ਅਸੰਭਵ ਹੈ ਕਿ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕਿਹੜੀਆਂ ਚੇਤਾਵਨੀਆਂ ਢੁਕਵੇਂ ਹਨ ਅਤੇ ਕਿਹੜੀਆਂ ਨਹੀਂ। ਬੈਠ ਕੇ ਇਨ੍ਹਾਂ ਸਾਰੀਆਂ ਚੇਤਾਵਨੀਆਂ ਨਾਲ ਨਜਿੱਠਣਾ ਸ਼ੁਰੂ ਕਰਨਾ ਤਰਕਹੀਣ ਹੈ, ਕਿਉਂਕਿ ਇਸ ਕੇਸ ਵਿੱਚ ਮੁੱਖ ਕੰਮ ਦਿਨਾਂ ਜਾਂ ਹਫ਼ਤਿਆਂ ਲਈ ਰੁਕ ਜਾਵੇਗਾ। ਆਮ ਤੌਰ 'ਤੇ, ਇੱਕ ਟੀਮ ਅਜਿਹੇ ਦ੍ਰਿਸ਼ ਨੂੰ ਬਰਦਾਸ਼ਤ ਨਹੀਂ ਕਰ ਸਕਦੀ. ਤਬਦੀਲੀਆਂ ਦੇ ਇਤਿਹਾਸ ਨੂੰ ਵਿਗਾੜਨ ਵਾਲੇ ਬਹੁਤ ਸਾਰੇ ਅੰਤਰ ਵੀ ਹੋਣਗੇ। ਅਤੇ ਕੋਡ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਟੁਕੜਿਆਂ ਦਾ ਤੇਜ਼ੀ ਨਾਲ ਪੁੰਜ ਸੰਪਾਦਨ ਕਰਨ ਨਾਲ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਨਵੀਂ ਟਾਈਪੋਜ਼ ਅਤੇ ਗਲਤੀਆਂ ਪੈਦਾ ਹੋਣਗੀਆਂ।

ਅਤੇ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ, ਚੇਤਾਵਨੀਆਂ ਦੇ ਵਿਰੁੱਧ ਲੜਾਈ ਵਿੱਚ ਅਜਿਹਾ ਕਾਰਨਾਮਾ ਬਹੁਤ ਘੱਟ ਅਰਥ ਰੱਖਦਾ ਹੈ. ਸਹਿਮਤ ਹੋਵੋ ਕਿ ਕਿਉਂਕਿ ਇਹ ਪ੍ਰੋਜੈਕਟ ਕਈ ਸਾਲਾਂ ਤੋਂ ਸਫਲਤਾਪੂਰਵਕ ਚੱਲ ਰਿਹਾ ਹੈ, ਇਸ ਵਿੱਚ ਜ਼ਿਆਦਾਤਰ ਗੰਭੀਰ ਤਰੁੱਟੀਆਂ ਪਹਿਲਾਂ ਹੀ ਠੀਕ ਕੀਤੀਆਂ ਜਾ ਚੁੱਕੀਆਂ ਹਨ। ਹਾਂ, ਇਹ ਫਿਕਸ ਬਹੁਤ ਮਹਿੰਗੇ ਸਨ, ਡੀਬੱਗ ਕੀਤੇ ਜਾਣੇ ਸਨ, ਬੱਗ ਬਾਰੇ ਨਕਾਰਾਤਮਕ ਉਪਭੋਗਤਾ ਫੀਡਬੈਕ ਪ੍ਰਾਪਤ ਕਰਦੇ ਸਨ, ਅਤੇ ਹੋਰ ਵੀ ਬਹੁਤ ਕੁਝ। ਇੱਕ ਸਥਿਰ ਵਿਸ਼ਲੇਸ਼ਕ ਇਹਨਾਂ ਵਿੱਚੋਂ ਬਹੁਤ ਸਾਰੀਆਂ ਗਲਤੀਆਂ ਨੂੰ ਕੋਡਿੰਗ ਪੜਾਅ 'ਤੇ ਜਲਦੀ ਅਤੇ ਸਸਤੇ ਢੰਗ ਨਾਲ ਠੀਕ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰੇਗਾ। ਪਰ ਇਸ ਸਮੇਂ, ਇੱਕ ਜਾਂ ਦੂਜੇ ਤਰੀਕੇ ਨਾਲ, ਇਹ ਗਲਤੀਆਂ ਹੱਲ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ, ਅਤੇ ਵਿਸ਼ਲੇਸ਼ਕ ਮੁੱਖ ਤੌਰ 'ਤੇ ਪੁਰਾਣੇ ਕੋਡ ਵਿੱਚ ਗੈਰ-ਨਾਜ਼ੁਕ ਗਲਤੀਆਂ ਦਾ ਪਤਾ ਲਗਾਉਂਦਾ ਹੈ। ਇਹ ਕੋਡ ਨਹੀਂ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਇਹ ਬਹੁਤ ਘੱਟ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਸ ਵਿੱਚ ਇੱਕ ਗਲਤੀ ਦੇ ਕਾਰਨ ਧਿਆਨ ਦੇਣ ਯੋਗ ਨਤੀਜੇ ਨਹੀਂ ਹੋ ਸਕਦੇ ਹਨ। ਸ਼ਾਇਦ ਕਿਤੇ ਬਟਨ ਤੋਂ ਪਰਛਾਵਾਂ ਗਲਤ ਰੰਗ ਹੈ, ਪਰ ਇਹ ਕਿਸੇ ਦੇ ਉਤਪਾਦ ਦੀ ਵਰਤੋਂ ਵਿੱਚ ਰੁਕਾਵਟ ਨਹੀਂ ਪਾਉਂਦਾ ਹੈ।

ਬੇਸ਼ੱਕ, ਛੋਟੀਆਂ-ਮੋਟੀਆਂ ਗ਼ਲਤੀਆਂ ਵੀ ਗ਼ਲਤੀਆਂ ਹੀ ਹੁੰਦੀਆਂ ਹਨ। ਅਤੇ ਕਈ ਵਾਰ ਇੱਕ ਗਲਤੀ ਇੱਕ ਅਸਲੀ ਕਮਜ਼ੋਰੀ ਨੂੰ ਛੁਪਾ ਸਕਦੀ ਹੈ. ਹਾਲਾਂਕਿ, ਸਭ ਕੁਝ ਛੱਡ ਦੇਣਾ ਅਤੇ ਨੁਕਸਾਂ ਨਾਲ ਨਜਿੱਠਣ ਲਈ ਦਿਨ/ਹਫ਼ਤੇ ਬਿਤਾਉਣਾ ਜੋ ਮੁਸ਼ਕਿਲ ਨਾਲ ਆਪਣੇ ਆਪ ਨੂੰ ਪ੍ਰਗਟ ਕਰਦੇ ਹਨ ਇੱਕ ਸ਼ੱਕੀ ਵਿਚਾਰ ਵਾਂਗ ਜਾਪਦਾ ਹੈ।

ਪ੍ਰੋਗਰਾਮਰ ਪੁਰਾਣੇ ਕਾਰਜਸ਼ੀਲ ਕੋਡ ਬਾਰੇ ਇਹਨਾਂ ਸਾਰੀਆਂ ਚੇਤਾਵਨੀਆਂ ਨੂੰ ਦੇਖਦੇ ਹਨ, ਦੇਖਦੇ ਹਨ, ਦੇਖਦੇ ਹਨ... ਅਤੇ ਉਹ ਸੋਚਦੇ ਹਨ: ਅਸੀਂ ਸਥਿਰ ਵਿਸ਼ਲੇਸ਼ਣ ਤੋਂ ਬਿਨਾਂ ਕਰ ਸਕਦੇ ਹਾਂ। ਚਲੋ ਕੁਝ ਨਵੀਂ ਉਪਯੋਗੀ ਕਾਰਜਸ਼ੀਲਤਾ ਲਿਖਦੇ ਹਾਂ।

ਆਪਣੇ ਤਰੀਕੇ ਨਾਲ, ਉਹ ਸਹੀ ਹਨ. ਉਹ ਸਮਝਦੇ ਹਨ ਕਿ ਪਹਿਲਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਇਨ੍ਹਾਂ ਸਾਰੀਆਂ ਚੇਤਾਵਨੀਆਂ ਤੋਂ ਛੁਟਕਾਰਾ ਪਾਉਣਾ ਹੋਵੇਗਾ। ਤਦ ਹੀ ਉਹ ਕੋਡ ਐਨਾਲਾਈਜ਼ਰ ਦੀ ਨਿਯਮਤ ਵਰਤੋਂ ਤੋਂ ਲਾਭ ਉਠਾ ਸਕਣਗੇ। ਨਹੀਂ ਤਾਂ, ਨਵੀਆਂ ਚੇਤਾਵਨੀਆਂ ਸਿਰਫ਼ ਪੁਰਾਣੀਆਂ ਵਿੱਚ ਡੁੱਬ ਜਾਣਗੀਆਂ, ਅਤੇ ਕੋਈ ਵੀ ਉਨ੍ਹਾਂ ਵੱਲ ਧਿਆਨ ਨਹੀਂ ਦੇਵੇਗਾ.

ਇਹ ਕੰਪਾਈਲਰ ਚੇਤਾਵਨੀਆਂ ਵਾਂਗ ਸਮਾਨਤਾ ਹੈ। ਇਹ ਬਿਨਾਂ ਕਾਰਨ ਨਹੀਂ ਹੈ ਕਿ ਉਹ ਕੰਪਾਈਲਰ ਚੇਤਾਵਨੀਆਂ ਦੀ ਗਿਣਤੀ 0 'ਤੇ ਰੱਖਣ ਦੀ ਸਿਫ਼ਾਰਸ਼ ਕਰਦੇ ਹਨ। ਜੇਕਰ 1000 ਚੇਤਾਵਨੀਆਂ ਹਨ, ਤਾਂ ਜਦੋਂ 1001 ਹਨ, ਤਾਂ ਕੋਈ ਵੀ ਇਸ ਵੱਲ ਧਿਆਨ ਨਹੀਂ ਦੇਵੇਗਾ, ਅਤੇ ਇਹ ਸਪੱਸ਼ਟ ਨਹੀਂ ਹੈ ਕਿ ਇਸ ਨਵੀਂ ਚੇਤਾਵਨੀ ਨੂੰ ਕਿੱਥੇ ਲੱਭਣਾ ਹੈ।

ਇਸ ਕਹਾਣੀ ਵਿੱਚ ਸਭ ਤੋਂ ਭੈੜੀ ਗੱਲ ਇਹ ਹੈ ਕਿ ਜੇਕਰ ਇਸ ਸਮੇਂ ਉੱਪਰੋਂ ਕੋਈ ਤੁਹਾਨੂੰ ਸਥਿਰ ਕੋਡ ਵਿਸ਼ਲੇਸ਼ਣ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ। ਇਹ ਸਿਰਫ ਟੀਮ ਨੂੰ ਨਿਰਾਸ਼ ਕਰੇਗਾ, ਕਿਉਂਕਿ ਉਨ੍ਹਾਂ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ ਇੱਥੇ ਵਾਧੂ ਨੌਕਰਸ਼ਾਹੀ ਜਟਿਲਤਾ ਹੋਵੇਗੀ ਜੋ ਸਿਰਫ ਰਸਤੇ ਵਿੱਚ ਆਉਂਦੀ ਹੈ. ਕੋਈ ਵੀ ਵਿਸ਼ਲੇਸ਼ਕ ਦੀਆਂ ਰਿਪੋਰਟਾਂ ਨੂੰ ਨਹੀਂ ਦੇਖੇਗਾ, ਅਤੇ ਸਾਰੀ ਵਰਤੋਂ ਸਿਰਫ "ਕਾਗਜ਼ 'ਤੇ" ਹੋਵੇਗੀ। ਉਹ. ਰਸਮੀ ਤੌਰ 'ਤੇ, ਵਿਸ਼ਲੇਸ਼ਣ ਨੂੰ DevOps ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਬਣਾਇਆ ਗਿਆ ਹੈ, ਪਰ ਅਭਿਆਸ ਵਿੱਚ ਇਸ ਨਾਲ ਕਿਸੇ ਨੂੰ ਵੀ ਲਾਭ ਨਹੀਂ ਹੁੰਦਾ। ਅਸੀਂ ਕਾਨਫਰੰਸ ਹਾਜ਼ਰੀਨ ਤੋਂ ਬੂਥਾਂ 'ਤੇ ਵਿਸਤ੍ਰਿਤ ਕਹਾਣੀਆਂ ਸੁਣੀਆਂ। ਅਜਿਹਾ ਅਨੁਭਵ ਪ੍ਰੋਗਰਾਮਰਾਂ ਨੂੰ ਲੰਬੇ ਸਮੇਂ ਲਈ ਸਥਿਰ ਵਿਸ਼ਲੇਸ਼ਣ ਸਾਧਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਤੋਂ ਨਿਰਾਸ਼ ਕਰ ਸਕਦਾ ਹੈ, ਜੇਕਰ ਹਮੇਸ਼ਾ ਲਈ ਨਹੀਂ।

ਤਕਨੀਕੀ ਕਰਜ਼ੇ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਅਤੇ ਖ਼ਤਮ ਕਰਨਾ

ਵਾਸਤਵ ਵਿੱਚ, ਇੱਕ ਵੱਡੇ ਪੁਰਾਣੇ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਸਥਿਰ ਵਿਸ਼ਲੇਸ਼ਣ ਨੂੰ ਪੇਸ਼ ਕਰਨ ਬਾਰੇ ਕੁਝ ਵੀ ਮੁਸ਼ਕਲ ਜਾਂ ਡਰਾਉਣਾ ਨਹੀਂ ਹੈ.

ਸੀਆਈ / ਸੀਡੀ

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਵਿਸ਼ਲੇਸ਼ਕ ਨੂੰ ਤੁਰੰਤ ਨਿਰੰਤਰ ਵਿਕਾਸ ਪ੍ਰਕਿਰਿਆ ਦਾ ਹਿੱਸਾ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ. ਉਦਾਹਰਨ ਲਈ, PVS-ਸਟੂਡੀਓ ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਵਿੱਚ ਤੁਹਾਨੂੰ ਲੋੜੀਂਦੇ ਫਾਰਮੈਟ ਵਿੱਚ ਰਿਪੋਰਟ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਦੇਖਣ ਲਈ ਉਪਯੋਗਤਾਵਾਂ ਅਤੇ ਕੋਡ ਦੇ ਸਮੱਸਿਆ ਵਾਲੇ ਭਾਗਾਂ ਨੂੰ ਲਿਖਣ ਵਾਲੇ ਡਿਵੈਲਪਰਾਂ ਲਈ ਸੂਚਨਾਵਾਂ ਸ਼ਾਮਲ ਹਨ। ਉਹਨਾਂ ਲਈ ਜੋ CI/CD ਸਿਸਟਮਾਂ ਤੋਂ PVS-ਸਟੂਡੀਓ ਸ਼ੁਰੂ ਕਰਨ ਵਿੱਚ ਵਧੇਰੇ ਦਿਲਚਸਪੀ ਰੱਖਦੇ ਹਨ, ਮੈਂ ਸਿਫ਼ਾਰਸ਼ ਕਰਦਾ ਹਾਂ ਕਿ ਤੁਸੀਂ ਆਪਣੇ ਆਪ ਨੂੰ ਇਸ ਨਾਲ ਜਾਣੂ ਹੋਵੋ ਅਨੁਭਾਗ ਦਸਤਾਵੇਜ਼ ਅਤੇ ਲੇਖਾਂ ਦੀ ਇੱਕ ਲੜੀ:

• ਪੀਵੀਐਸ-ਸਟੂਡੀਓ ਬੱਦਲਾਂ 'ਤੇ ਜਾਂਦਾ ਹੈ: ਅਜ਼ੂਰ ਡੇਵੋਪਸ
• ਪੀਵੀਐਸ-ਸਟੂਡੀਓ ਬੱਦਲਾਂ 'ਤੇ ਜਾਂਦਾ ਹੈ: ਟ੍ਰੈਵਿਸ ਸੀਆਈ
• PVS-ਸਟੂਡੀਓ ਬੱਦਲਾਂ 'ਤੇ ਜਾਂਦਾ ਹੈ: GitLab CI/CD
• ਪੀਵੀਐਸ-ਸਟੂਡੀਓ ਬੱਦਲਾਂ 'ਤੇ ਜਾਂਦਾ ਹੈ: ਸਰਕਲਸੀਆਈ

ਪਰ ਆਓ ਕੋਡ ਵਿਸ਼ਲੇਸ਼ਣ ਟੂਲਸ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੇ ਪਹਿਲੇ ਪੜਾਵਾਂ 'ਤੇ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਝੂਠੇ ਸਕਾਰਾਤਮਕ ਦੇ ਮੁੱਦੇ 'ਤੇ ਵਾਪਸ ਚਲੀਏ।

ਮੌਜੂਦਾ ਤਕਨੀਕੀ ਕਰਜ਼ੇ ਨੂੰ ਠੀਕ ਕਰਨਾ ਅਤੇ ਨਵੀਆਂ ਚੇਤਾਵਨੀਆਂ ਨਾਲ ਨਜਿੱਠਣਾ

ਆਧੁਨਿਕ ਵਪਾਰਕ ਸਥਿਰ ਵਿਸ਼ਲੇਸ਼ਕ ਤੁਹਾਨੂੰ ਸਿਰਫ਼ ਨਵੀਆਂ ਚੇਤਾਵਨੀਆਂ ਦਾ ਅਧਿਐਨ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ ਜੋ ਨਵੇਂ ਜਾਂ ਬਦਲੇ ਹੋਏ ਕੋਡ ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ। ਇਸ ਵਿਧੀ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਵੱਖੋ-ਵੱਖਰਾ ਹੈ, ਪਰ ਤੱਤ ਇੱਕੋ ਹੈ. ਪੀਵੀਐਸ-ਸਟੂਡੀਓ ਸਟੈਟਿਕ ਐਨਾਲਾਈਜ਼ਰ ਵਿੱਚ, ਇਹ ਕਾਰਜਕੁਸ਼ਲਤਾ ਹੇਠ ਲਿਖੇ ਅਨੁਸਾਰ ਲਾਗੂ ਕੀਤੀ ਗਈ ਹੈ।

ਸਥਿਰ ਵਿਸ਼ਲੇਸ਼ਣ ਦੀ ਵਰਤੋਂ ਜਲਦੀ ਸ਼ੁਰੂ ਕਰਨ ਲਈ, ਅਸੀਂ PVS-ਸਟੂਡੀਓ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਚੇਤਾਵਨੀਆਂ ਦੇ ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਦਮਨ ਲਈ ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਸੁਝਾਅ ਦਿੰਦੇ ਹਾਂ।6]। ਆਮ ਵਿਚਾਰ ਹੇਠ ਲਿਖੇ ਅਨੁਸਾਰ ਹੈ। ਉਪਭੋਗਤਾ ਨੇ ਵਿਸ਼ਲੇਸ਼ਕ ਲਾਂਚ ਕੀਤਾ ਅਤੇ ਬਹੁਤ ਸਾਰੀਆਂ ਚੇਤਾਵਨੀਆਂ ਪ੍ਰਾਪਤ ਕੀਤੀਆਂ। ਕਿਉਂਕਿ ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਜੋ ਕਈ ਸਾਲਾਂ ਤੋਂ ਵਿਕਾਸ ਵਿੱਚ ਹੈ, ਜੀਵਿਤ ਹੈ, ਵਿਕਾਸ ਕਰ ਰਿਹਾ ਹੈ ਅਤੇ ਪੈਸਾ ਕਮਾ ਰਿਹਾ ਹੈ, ਤਾਂ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ ਰਿਪੋਰਟ ਵਿੱਚ ਗੰਭੀਰ ਨੁਕਸ ਦਰਸਾਉਣ ਵਾਲੀਆਂ ਬਹੁਤ ਸਾਰੀਆਂ ਚੇਤਾਵਨੀਆਂ ਨਹੀਂ ਹੋਣਗੀਆਂ। ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿਚ, ਨਾਜ਼ੁਕ ਬੱਗ ਪਹਿਲਾਂ ਹੀ ਵਧੇਰੇ ਮਹਿੰਗੇ ਤਰੀਕਿਆਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਜਾਂ ਗਾਹਕਾਂ ਤੋਂ ਫੀਡਬੈਕ ਲਈ ਧੰਨਵਾਦ ਕਰਕੇ ਇਕ ਜਾਂ ਦੂਜੇ ਤਰੀਕੇ ਨਾਲ ਹੱਲ ਕੀਤੇ ਜਾ ਚੁੱਕੇ ਹਨ। ਇਸ ਅਨੁਸਾਰ, ਜੋ ਵੀ ਵਿਸ਼ਲੇਸ਼ਕ ਵਰਤਮਾਨ ਵਿੱਚ ਲੱਭਦਾ ਹੈ ਉਸਨੂੰ ਤਕਨੀਕੀ ਕਰਜ਼ਾ ਮੰਨਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਜਿਸ ਨੂੰ ਤੁਰੰਤ ਖਤਮ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨਾ ਅਵਿਵਹਾਰਕ ਹੈ.

ਤੁਸੀਂ PVS-Studio ਨੂੰ ਇਹਨਾਂ ਚੇਤਾਵਨੀਆਂ ਨੂੰ ਫਿਲਹਾਲ ਅਪ੍ਰਸੰਗਿਕ ਮੰਨਣ ਲਈ ਕਹਿ ਸਕਦੇ ਹੋ (ਬਾਅਦ ਲਈ ਤਕਨੀਕੀ ਕਰਜ਼ੇ ਨੂੰ ਬਚਾਓ), ਅਤੇ ਇਹ ਉਹਨਾਂ ਨੂੰ ਹੁਣ ਨਹੀਂ ਦਿਖਾਏਗਾ। ਵਿਸ਼ਲੇਸ਼ਕ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਫਾਈਲ ਬਣਾਉਂਦਾ ਹੈ ਜਿੱਥੇ ਇਹ ਉਹਨਾਂ ਗਲਤੀਆਂ ਬਾਰੇ ਜਾਣਕਾਰੀ ਸੁਰੱਖਿਅਤ ਕਰਦਾ ਹੈ ਜੋ ਅਜੇ ਦਿਲਚਸਪ ਨਹੀਂ ਹਨ। ਅਤੇ ਹੁਣ PVS-ਸਟੂਡੀਓ ਸਿਰਫ ਨਵੇਂ ਜਾਂ ਬਦਲੇ ਹੋਏ ਕੋਡ ਲਈ ਚੇਤਾਵਨੀਆਂ ਜਾਰੀ ਕਰੇਗਾ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇਹ ਸਭ ਚਲਾਕੀ ਨਾਲ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ. ਜੇ, ਉਦਾਹਰਨ ਲਈ, ਸਰੋਤ ਕੋਡ ਫਾਈਲ ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਇੱਕ ਖਾਲੀ ਲਾਈਨ ਜੋੜੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਵਿਸ਼ਲੇਸ਼ਕ ਸਮਝਦਾ ਹੈ ਕਿ, ਅਸਲ ਵਿੱਚ, ਕੁਝ ਨਹੀਂ ਬਦਲਿਆ ਹੈ, ਅਤੇ ਚੁੱਪ ਰਹਿਣਾ ਜਾਰੀ ਰਹੇਗਾ. ਇਸ ਮਾਰਕਅੱਪ ਫਾਈਲ ਨੂੰ ਵਰਜਨ ਕੰਟਰੋਲ ਸਿਸਟਮ ਵਿੱਚ ਰੱਖਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਫਾਈਲ ਵੱਡੀ ਹੈ, ਪਰ ਇਹ ਕੋਈ ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ ਇਸਨੂੰ ਅਕਸਰ ਸਟੋਰ ਕਰਨ ਦਾ ਕੋਈ ਮਤਲਬ ਨਹੀਂ ਹੁੰਦਾ.

ਹੁਣ ਸਾਰੇ ਪ੍ਰੋਗਰਾਮਰ ਸਿਰਫ਼ ਨਵੇਂ ਜਾਂ ਬਦਲੇ ਹੋਏ ਕੋਡ ਨਾਲ ਸਬੰਧਤ ਚੇਤਾਵਨੀਆਂ ਦੇਖਣਗੇ। ਇਸ ਤਰ੍ਹਾਂ, ਤੁਸੀਂ ਅਗਲੇ ਦਿਨ ਤੋਂ ਵਿਸ਼ਲੇਸ਼ਕ ਦੀ ਵਰਤੋਂ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹੋ, ਜਿਵੇਂ ਕਿ ਉਹ ਕਹਿੰਦੇ ਹਨ. ਅਤੇ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਤਕਨੀਕੀ ਕਰਜ਼ੇ ਤੇ ਵਾਪਸ ਜਾ ਸਕਦੇ ਹੋ, ਅਤੇ ਹੌਲੀ ਹੌਲੀ ਗਲਤੀਆਂ ਨੂੰ ਠੀਕ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਵਿਸ਼ਲੇਸ਼ਕ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰ ਸਕਦੇ ਹੋ।

ਇਸ ਲਈ, ਇੱਕ ਵੱਡੇ ਪੁਰਾਣੇ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਵਿਸ਼ਲੇਸ਼ਕ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਪਹਿਲੀ ਸਮੱਸਿਆ ਹੱਲ ਹੋ ਗਈ ਹੈ. ਹੁਣ ਆਓ ਇਹ ਸਮਝੀਏ ਕਿ ਤਕਨੀਕੀ ਕਰਜ਼ੇ ਨਾਲ ਕੀ ਕਰਨਾ ਹੈ.

ਬੱਗ ਫਿਕਸ ਅਤੇ ਰੀਫੈਕਟਰਿੰਗ

ਸਭ ਤੋਂ ਸਰਲ ਅਤੇ ਸਭ ਤੋਂ ਕੁਦਰਤੀ ਗੱਲ ਇਹ ਹੈ ਕਿ ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਦਬਾਈਆਂ ਗਈਆਂ ਵਿਸ਼ਲੇਸ਼ਕ ਚੇਤਾਵਨੀਆਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਲਈ ਅਤੇ ਹੌਲੀ ਹੌਲੀ ਉਹਨਾਂ ਨਾਲ ਨਜਿੱਠਣ ਲਈ ਕੁਝ ਸਮਾਂ ਵੱਖਰਾ ਕਰਨਾ ਹੈ। ਕਿਤੇ ਤੁਹਾਨੂੰ ਕੋਡ ਦੀਆਂ ਗਲਤੀਆਂ ਨੂੰ ਠੀਕ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਤੇ ਤੁਹਾਨੂੰ ਵਿਸ਼ਲੇਸ਼ਕ ਨੂੰ ਇਹ ਦੱਸਣ ਲਈ ਰੀਫੈਕਟਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕੋਡ ਸਮੱਸਿਆ ਵਾਲਾ ਨਹੀਂ ਹੈ। ਸਧਾਰਨ ਉਦਾਹਰਨ:

if (a = b)

ਜ਼ਿਆਦਾਤਰ C++ ਕੰਪਾਈਲਰ ਅਤੇ ਵਿਸ਼ਲੇਸ਼ਕ ਅਜਿਹੇ ਕੋਡ ਬਾਰੇ ਸ਼ਿਕਾਇਤ ਕਰਦੇ ਹਨ, ਕਿਉਂਕਿ ਇੱਥੇ ਇੱਕ ਉੱਚ ਸੰਭਾਵਨਾ ਹੈ ਕਿ ਉਹ ਅਸਲ ਵਿੱਚ ਲਿਖਣਾ ਚਾਹੁੰਦੇ ਸਨ (a == b). ਪਰ ਇੱਕ ਅਣ-ਬੋਲਾ ਸਮਝੌਤਾ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਨੋਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਕਿ ਜੇ ਵਾਧੂ ਬਰੈਕਟ ਹਨ, ਤਾਂ ਇਹ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ ਕਿ ਪ੍ਰੋਗਰਾਮਰ ਨੇ ਜਾਣਬੁੱਝ ਕੇ ਅਜਿਹਾ ਕੋਡ ਲਿਖਿਆ ਹੈ, ਅਤੇ ਸਹੁੰ ਖਾਣ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਡਾਇਗਨੌਸਟਿਕਸ ਲਈ 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-ਸਟੂਡੀਓ ਦੇ ਉਪਭੋਗਤਾ ਅਤੇ ਇਸ ਨੂੰ ਲਾਗੂ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ।

ਇਸ ਬਾਰੇ ਹੋਰ ਆਮ ਸ਼ੰਕੇ ਹਨ ਕਿ ਕੀ ਸਥਿਰ ਵਿਸ਼ਲੇਸ਼ਣ ਅਸਲ ਵਿੱਚ ਸੁਵਿਧਾਜਨਕ ਅਤੇ ਉਪਯੋਗੀ ਹੋ ਸਕਦਾ ਹੈ। ਮੈਂ ਪ੍ਰਕਾਸ਼ਨ ਵਿੱਚ ਇਹਨਾਂ ਵਿੱਚੋਂ ਜ਼ਿਆਦਾਤਰ ਸ਼ੰਕਾਵਾਂ ਨੂੰ ਦੂਰ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ "ਪੀਵੀਐਸ-ਸਟੂਡੀਓ ਸਟੈਟਿਕ ਕੋਡ ਐਨਾਲਾਈਜ਼ਰ ਨੂੰ ਵਿਕਾਸ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਪੇਸ਼ ਕਰਨ ਦੇ ਕਾਰਨ" [9].

ਤੁਹਾਡੇ ਧਿਆਨ ਲਈ ਧੰਨਵਾਦ ਅਤੇ ਆਓ скачать ਅਤੇ PVS-ਸਟੂਡੀਓ ਐਨਾਲਾਈਜ਼ਰ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ।

ਵਧੀਕ ਲਿੰਕ

1. ਐਂਡਰੀ ਕਾਰਪੋਵ. ਮੈਂ ਦਿਲਚਸਪ ਚੇਤਾਵਨੀਆਂ ਨੂੰ ਕਿਵੇਂ ਦੇਖ ਸਕਦਾ ਹਾਂ ਜੋ PVS-ਸਟੂਡੀਓ ਵਿਸ਼ਲੇਸ਼ਕ C ਅਤੇ C++ ਕੋਡ ਲਈ ਤਿਆਰ ਕਰਦਾ ਹੈ?
2. ਵਿਕੀਪੀਡੀਆ. ਚਾਵਲ ਦਾ ਪ੍ਰਮੇਯ.
3. ਆਂਦਰੇ ਕਾਰਪੋਵ, ਵਿਕਟੋਰੀਆ ਖਾਨੀਵਾ। ਪ੍ਰੋਗਰਾਮ ਸਰੋਤ ਕੋਡ ਦੇ ਸਥਿਰ ਵਿਸ਼ਲੇਸ਼ਣ ਵਿੱਚ ਮਸ਼ੀਨ ਸਿਖਲਾਈ ਦੀ ਵਰਤੋਂ ਕਰਨਾ.
4. PVS-ਸਟੂਡੀਓ। ਦਸਤਾਵੇਜ਼ੀਕਰਨ। ਵਧੀਕ ਡਾਇਗਨੌਸਟਿਕ ਸੈਟਿੰਗਾਂ.
5. ਐਂਡਰੀ ਕਾਰਪੋਵ. ਈਐਫਐਲ ਕੋਰ ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੀ ਉਦਾਹਰਣ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਪੀਵੀਐਸ-ਸਟੂਡੀਓ ਵਿਸ਼ਲੇਸ਼ਕ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ, 10-15% ਝੂਠੇ ਸਕਾਰਾਤਮਕ.
6. PVS-ਸਟੂਡੀਓ। ਦਸਤਾਵੇਜ਼ੀਕਰਨ। ਵਿਸ਼ਲੇਸ਼ਕ ਸੁਨੇਹਿਆਂ ਦਾ ਸਮੂਹਿਕ ਦਮਨ.
7. ਇਵਾਨ ਐਂਡਰੀਸ਼ਿਨ. ਇਸ ਬਾਰੇ ਕਿ ਅਸੀਂ ਐਕਸ-ਰੇ ਐਂਡੋਵੈਸਕੁਲਰ ਸਰਜਰੀ ਦੇ ਵਿਦਿਅਕ ਸਿਮੂਲੇਟਰ ਦੇ ਸਾਡੇ ਪ੍ਰੋਜੈਕਟ 'ਤੇ ਸਥਿਰ ਵਿਸ਼ਲੇਸ਼ਣ ਦੀ ਜਾਂਚ ਕਿਵੇਂ ਕੀਤੀ।.
8. ਪਾਵੇਲ Eremeev, Svyatoslav Razmyslov. PVS-ਸਟੂਡੀਓ ਟੀਮ ਨੇ ਅਰੀਅਲ ਇੰਜਨ ਕੋਡ ਨੂੰ ਕਿਵੇਂ ਸੁਧਾਰਿਆ.
9. ਐਂਡਰੀ ਕਾਰਪੋਵ. ਵਿਕਾਸ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਸਥਿਰ ਕੋਡ ਵਿਸ਼ਲੇਸ਼ਕ PVS-Studio ਨੂੰ ਪੇਸ਼ ਕਰਨ ਦੇ ਕਾਰਨ.

ਜੇਕਰ ਤੁਸੀਂ ਇਸ ਲੇਖ ਨੂੰ ਅੰਗਰੇਜ਼ੀ ਬੋਲਣ ਵਾਲੇ ਦਰਸ਼ਕਾਂ ਨਾਲ ਸਾਂਝਾ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਕਿਰਪਾ ਕਰਕੇ ਅਨੁਵਾਦ ਲਿੰਕ ਦੀ ਵਰਤੋਂ ਕਰੋ: ਐਂਡਰੀ ਕਾਰਪੋਵ। ਇੱਕ ਵਿਰਾਸਤੀ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਇੱਕ ਸਥਿਰ ਕੋਡ ਵਿਸ਼ਲੇਸ਼ਕ ਨੂੰ ਕਿਵੇਂ ਪੇਸ਼ ਕਰਨਾ ਹੈ ਅਤੇ ਟੀਮ ਨੂੰ ਨਿਰਾਸ਼ ਨਹੀਂ ਕਰਨਾ ਹੈ.

ਸਰੋਤ: www.habr.com