03 ਦਸੰ 2025·8 ਮਿੰਟ
Kernighan ਤੇ ਕੋਡ ਦੀ ਸਪਸ਼ਟਤਾ: ਚਤੁਰ ਕੋਡ ਤੋਂ ਰੁਚੀ ਨੂੰ ਤਰਜੀਹ
Brian Kernighan ਦੀ “ਚੰਗੀ ਰੁਚੀ” ਸਲਾਹ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਪੜ੍ਹਨਯੋਗ ਕੋਡ ਸਮਾਂ ਬਚਾਉਂਦਾ ਹੈ, ਬੱਗ ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਚਤੁਰ ਤਰਕਾਂ ਨਾਲੋਂ ਅਸਲੀ ਟੀਮਾਂ ਨੂੰ ਤੇਜ਼ ਚਲਾਉਂਦਾ ਹੈ।
Brian Kernighan ਦੀ “ਚੰਗੀ ਰੁਚੀ” ਸਲਾਹ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਪੜ੍ਹਨਯੋਗ ਕੋਡ ਸਮਾਂ ਬਚਾਉਂਦਾ ਹੈ, ਬੱਗ ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਚਤੁਰ ਤਰਕਾਂ ਨਾਲੋਂ ਅਸਲੀ ਟੀਮਾਂ ਨੂੰ ਤੇਜ਼ ਚਲਾਉਂਦਾ ਹੈ।
Brian Kernighan ਦਾ ਨਾਮ ਉਹਨਾਂ ਥਾਵਾਂ ਤੇ ਮਿਲਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਕਈ ਡਿਵੈਲਪਰ ਬਿਨਾਂ ਸੋਚੇ ਵਰਤਦੇ ਹਨ: ਪੁਰਾਣੇ Unix ਟੂਲ, C ਪਰਿਵਾਰ ਅਤੇ ਉਹ ਲੇਖ ਅਤੇ ਲੈਕਚਰਾਂ ਜੋ ਲੋਕਾਂ ਨੂੰ ਪ੍ਰੋਗਰਾਮ ਸਪਸ਼ਟ ਤਰੀਕੇ ਨਾਲ ਸਮਝਾਉਣਾ ਸਿਖਾਉਂਦੇ ਹਨ। ਚਾਹੇ ਤੁਸੀਂ The C Programming Language (Dennis Ritchie ਨਾਲ), The Unix Programming Environment ਜਾਂ ਉਸਦੇ ਲੇਖ-ਭਾਸ਼ਣ ਯਾਦ ਰੱਖੋ, ਇੱਕ ਸਾਂਝਾ ਧਾਗਾ ਸਾਫ਼ ਤਰੀਕੇ ਨਾਲ ਸਧਾਰਨ ਵਿਚਾਰ ਪ੍ਰਗਟ ਕਰਨ ਦੀ ਜ਼ੋਰਦਾਰ ਮੰਗ ਹੈ।
Kernighan ਦੀ ਸਭ ਤੋਂ ਵਧੀਆ ਸਲਾਹ C ਸਿੰਟੈਕਸ ਜਾਂ Unix ਰਿਵਾਜਾਂ ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਹੈ। ਇਹ ਇਨਸਾਨਾਂ ਦੇ ਪੜ੍ਹਨ ਦੇ ਤਰੀਕੇ ਬਾਰੇ ਹੈ: ਅਸੀਂ ਰਚਨਾ ਲਈ ਸਕੈਨ ਕਰਦੇ ਹਾਂ, ਨਾਮਾਂ ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਾਂ, ਮਨੋਰਥ ਅਨੁਮਾਨ ਲਾਂਦੇ ਹਾਂ ਅਤੇ ਜਦ ਕੋਡ ਤਰਿਕਿਆਂ ਦੇ ਪਿੱਛੇ ਮਤਲਬ ਛੁਪਾ ਲੈਂਦਾ ਹੈ ਤਾਂ ਅਸੀਂ ਉਲਝ ਜਾਂਦੇ ਹਾਂ। ਇਨ੍ਹਾਂ ਕਾਰਨਾਂ ਕਰਕੇ ਪੜ੍ਹਨਯੋਗਤਾ ਵਿੱਚ “ਰੁਚੀ” ਅਜੇ ਵੀ ਮਾਇਨੇ ਰਖਦੀ ਹੈ ਜਦ ਤੁਸੀਂ TypeScript, Python, Go, Java ਜਾਂ Rust ਵਿੱਚ ਲਿਖ ਰਹੇ ਹੋ।
ਭਾਸ਼ਾਵਾਂ ਬਦਲਦੀਆਂ ਹਨ। ਟੂਲਿੰਗ ਸੁਧਰਦੀ ਹੈ। ਟੀਮਾਂ ਅਜੇ ਵੀ ਸਮੇਂ ਦੀ ਦਬਾਵ ਹੇਠ ਫੀਚਰ ਰਿਲੀਜ਼ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਜ਼ਿਆਦਾਤਰ ਕੋਡ ਉਸ ਮੂਲ ਲੇਖਕ ਤੋਂ ਵੱਖਰੇ ਕਿਸੇ ਹੋਰ ਦੁਆਰਾ ਸੰਭਾਲਿਆ ਜਾਂਦਾ ਹੈ (ਅਕਸਰ ਭਵਿੱਖ-ਤੁਸੀਂ)। ਸਪਸ਼ਟਤਾ ਉਹ ਗੁਣਾ ਹੈ ਜੋ ਇਨ੍ਹਾਂ ਸਾਰਿਆਂ ਨੂੰ ਟਿਕਾਊ ਬਣਾਉਂਦੀ ਹੈ।
ਇਹ “ਹੀਰੋ ਕੋਡਿੰਗ” ਦੀ ਸਿਰੰਦਾਜ਼ੀ ਨਹੀਂ ਹੈ ਅਤੇ ਨਾ ਹੀ ਪੁਰਾਣੇ ਨਿਯਮ ਯਾਦ ਕਰਨ ਦੀ ਅਪੀਲ ਹੈ। ਇਹ ਰੋਜ਼ਾਨਾ ਕੋਡ ਨੂੰ ਆਸਾਨ ਬਣਾਉਣ ਵਾਲੀਆਂ ਆਦਤਾਂ ਲਈ ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਗਾਈਡ ਹੈ:
Kernighan ਦੀ ਪ੍ਰਭਾਵਸ਼ੀਲਤਾ ਇਸ ਲਈ ਮਾਇਨੇ ਰੱਖਦੀ ਹੈ ਕਿਉਂਕਿ ਇਹ ਇੱਕ ਸਧਾਰਨ, ਟੀਮ-ਭਲਾਈ ਉਦਦੇਸ਼ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀ ਹੈ: ਐਸਾ ਕੋਡ ਲਿਖੋ ਜੋ ਸੰਚਾਰ ਕਰੇ। ਜਦ ਕੋਡ ਇੱਕ ਸਪਸ਼ਟ ਵਿਆਖਿਆ ਵਾਂਗ ਪੜ੍ਹਿਆ ਜਾ ਸਕੇ, ਤੁਸੀਂ ਇਸਨੂੰ ਡੀਕੋਡ ਕਰਨ ਵਿੱਚ ਘੱਟ ਸਮਾਂ ਵਿਤਾਉਂਦੇ ਹੋ ਤੇ ਇਸਨੂੰ ਸੁਧਾਰਨ ਵਿੱਚ ਵਧੇਰੇ ਸਮਾਂ ਲਾਉਂਦੇ ਹੋ।
ਪੜ੍ਹਨਯੋਗ ਕੋਡ ਵਿੱਚ “ਚੰਗੀ ਰੁਚੀ” ਵਿਅਕਤੀਗਤ ਸ਼ੈਲੀ, ਸ਼ਾਨਦਾਰ ਪੈਟਰਨ ਜਾਂ ਹੱਲ ਨੂੰ ਸਭ ਤੋਂ ਘੱਟ ਲਾਈਨਾਂ ਵਿੱਚ ਨਿਪੇੜਨ ਵਾਲੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਹੈ। ਇਹ ਉਹ ਆਦਤ ਹੈ ਜੋ ਹਮੇਸ਼ਾ ਸਭ ਤੋਂ ਸਪਸ਼ਟ, ਸਧਾਰਨ ਵਿਕਲਪ ਚੁਣਦੀ ਹੈ ਜੋ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਮਨੋਰਥ ਸੰਚਾਰ ਕਰੇ।
ਇੱਕ ਚੰਗੀ-ਰੁਚੀ ਹੱਲ ਅਗਲੇ ਪਾਠਕ ਲਈ ਇੱਕ ਮੂਲ ਪ੍ਰਸ਼ਨ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ: ਇਹ ਕੋਡ ਕੀ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਹੈ, ਅਤੇ ਇਹ ਇਹ ਤਰ੍ਹਾਂ ਕਿਉਂ ਕਰ ਰਿਹਾ ਹੈ? ਜੇ ਇਹ ਜਵਾਬ ਮਾਨਸਿਕ ਵਿਆਮ, ਛੁਪੀਆਂ ਧਾਰਣਾਂ ਜਾਂ ਚਤੁਰ ਤਰਕਾਂ ਨਾਲ ਲਭਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਕੋਡ ਟੀਮ ਦਾ ਸਮਾਂ ਖਰਚ ਕਰ ਰਿਹਾ ਹੈ।
ਬਹੁਤ ਸਾਰਾ ਕੋਡ ਲਿਖਣ ਨਾਲੋਂ ਕਈ ਵਾਰੀ ਪੜ੍ਹਿਆ ਜਾਂਦਾ ਹੈ। “ਚੰਗੀ ਰੁਚੀ” ਪੜ੍ਹਨ ਨੂੰ ਮੁੱਖ ਗਤੀਵਿਧੀ ਮੰਨਦੀ ਹੈ:
ਇਸ ਲਈ ਪੜ੍ਹਨਯੋਗਤਾ ਸਿਰਫ਼ ਸੁੰਦਰਤਾ (ਇੰਡੈਂਟੇਸ਼ਨ, ਲਾਈਨ ਚੌੜਾਈ ਜਾਂ snake_case ਦੀ ਪਸੰਦ) ਨਹੀਂ ਹੈ। ਇਹ ਮੁੱਖ ਤੌਰ 'ਤੇ ਸੋਚ ਵਾਸਤੇ ਆਸਾਨ ਬਣਾਉਣ ਬਾਰੇ ਹੈ: ਸਪਸ਼ਟ ਨਾਮ, ਓਬਵਿਅਸ ਕੰਟਰੋਲ ਫਲੋ ਅਤੇ ਪੈਟਰਨ ਜੋ ਅਨੁਮਾਨਯੋਗ ਹੋਵਣ।
ਇੱਕ ਆਮ ਗਲਤੀ brevity ਲਈ ਓਪਟੀਮਾਈਜ਼ ਕਰਣਾ ਹੈ ਬਜਾਏ ਕਿ clarity ਲਈ। ਕਈ ਵਾਰ ਸਭ ਤੋਂ ਸਪਸ਼ਟ ਕੋਡ ਥੋੜ੍ਹਾ ਲੰਮਾ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਕਦਮਾਂ ਨੂੰ ਖੁੱਲ੍ਹੇ ਤੌਰ 'ਤੇ ਦਿਖਾਉਂਦਾ ਹੈ।
ਉਦਾਹਰਨ ਲਈ, ਦੋ ਤਰੀਕਿਆਂ ਨੂੰ ਤੁਲਨਾ ਕਰੋ:
ਦੂਜਾ ਸੰਸਕਰਣ ਕੁਝ ਲਾਈਨਾਂ ਵਧਾ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਸਹੀਤਾ ਜਾਂਚਣ ਲਈ ਮਾਨਸਿਕ ਭਾਰ ਘਟਾ ਦਿੰਦਾ ਹੈ। ਇਹ ਬੱਗ ਸਨੋਧਣ ਅਤੇ ਬਦਲਾਵ ਲੱਗੂ ਕਰਨ ਨੂੰ ਸੁਰੱਖਿਅਤ ਬਣਾਉਂਦਾ ਹੈ।
ਚੰਗੀ ਰੁਚੀ ਇਹ ਜਾਣਣ ਵਿੱਚ ਹੈ ਕਿ ਕਦੋਂ “ਇੰਟੇਲੀਜੈਂਟ” ਸੁਧਾਰ ਬੰਦ ਕਰਨਾ ਹੈ ਅਤੇ ਮਨੋਰਥ ਨੂੰ ਸਪਸ਼ਟ ਬਣਾਉਣਾ ਹੈ। ਜੇ ਇੱਕ ਟੀਮੀ ਮੈਂਬਰ ਤੁਹਾਡੇ ਨੂੰ ਪੁੱਛਣ ਦੇ ਬਗੈਰ ਸਮਝ ਸਕਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਠੀਕ ਚੁਣਿਆ।
ਚਤੁਰ ਕੋਡ ਅਕਸਰ ਪਲਕਾਂ ਵਿੱਚ ਜਿੱਤ ਵਾਂਗ ਲੱਗਦਾ ਹੈ: ਘੱਟ ਲਾਈਨਾਂ, ਇੱਕ ਚਾਲਾਕ ਹਤਰਿੱਕਾ, diff 'ਤੇ “ਵਾਹ” ਦਾ ਪ੍ਰਭਾਵ। ਅਸਲ ਟੀਮ ਵਿੱਚ, ਇਹ ਚਤੁਰਾਈ ਇੱਕ ਲਗਾਤਾਰ ਬਿੱਲ ਬਣ ਜਾਂਦੀ ਹੈ—ਜੋ ਓਨਬੋਰਡਿੰਗ ਸਮੇਂ, ਰਿਵਿਊ ਸਮੇਂ ਅਤੇ ਹਰ ਵਾਰੀ ਕਦੇ ਕਿਸੇ ਨੂੰ ਕੋਡ ਨੂੰ ਹੱਥ ਲਾਉਣਾ ਪੈਂਦਾ ਹੈ ਤਾਂ ਡਰ ਵਿੱਚ ਭੁਗਤਾਈ ਜਾਂਦੀ ਹੈ।
ਓਨਬੋਰਡਿੰਗ ਸਲੋ ਹੋ ਜਾਂਦੀ ਹੈ। ਨਵੇਂ ਟੀਮੀ ਮੈਂਬਰ ਸਿਰਫ਼ ਪ੍ਰੋਡਕਟ ਨਹੀਂ ਸਿੱਖਦੇ; ਉਹਨਾਂ ਨੂੰ ਤੁਹਾਡੀ ਨਿੱਜੀ ਡਾਇਲੈਕਟ ਵੀ ਸਿੱਖਣੀ ਪੈਂਦੀ ਹੈ। ਜੇ ਕਿਸੇ ਫੰਕਸ਼ਨ ਨੂੰ ਸਮਝਣ ਲਈ ਚਤੁਰ ਓਪਰੇਟਰ ਜਾਂ ਅਸਮਿਕ ਰਿਵਾਜਾਂ ਨੂੰ ਡੀਕੋਡ ਕਰਨਾ ਪੈਂਦਾ ਹੈ, ਲੋਕ ਉਸਨੂੰ ਬਦਲਣ ਤੋਂ ਬਚਣਗੇ—ਜਾਂ ਡਰ ਕੇ ਬਦਲਣਗੇ।
ਰਿਵਿਊਜ਼ ਲੰਬੇ ਅਤੇ ਘੱਟ ਭਰੋਸੇਯੋਗ ਹੋ ਜਾਂਦੇ ਹਨ। ਰਿਵਿਊਅਰ ਤਕਨੀਕ ਦੀ ਸਹੀਤਾ ਸਾਬਤ ਕਰਨ ਵਿੱਚ ਤਾਕਤ ਖਰਚ ਕਰਦੇ ਹਨ ਨਾ ਕਿ ਇਹ ਅੰਕੜਾ ਕੀ ਮਨੋਰਥ ਨਾਲ ਮਿਲਦਾ ਹੈ। ਵੱਧ ਖਰਾਬ ਗੱਲ ਇਹ ਹੈ ਕਿ ਚਤੁਰ ਕੋਡ ਮਨ ਵਿੱਚ ਅਸਰ ਰੂਪ ਵਿੱਚ ਸਿਮੁਲੇਸ਼ਨ ਕਰਨਾ ਮੁਸ਼ਕਿਲ ਹੈ, ਇਸ ਲਈ ਰਿਵਿਊਅਰ ਉਹ ਏਜ ਕੇਸ ਨਹੀਂ ਵੇਖਦੇ ਜੋ ਸਧਾਰਨ ਸੰਸਕਰਣ ਵਿੱਚ ਫੜੇ ਜਾ ਸਕਦੇ ਸਨ।
ਚਤੁਰਾਈ ਇਹਨਾਂ ਹਾਲਾਤਾਂ 'ਚ ਘੱਟੇਗੀ:
ਕੁਝ ਮੁੜ-ਮੁੜ ਦਿੱਸਣ ਵਾਲੇ ਦੋਸ਼:
17, 0.618, -1) ਜੋ ਨਿਯਮਾਂ ਨੂੰ ਕੋਡ ਕਰਦੇ ਹਨ ਜੋ ਕੋਈ ਯਾਦ ਨਹੀਂ ਰੱਖ ਪਾਵੇਗਾ।&& / || ਟਰਿਕ) ਜੋ ਪੜ੍ਹਨ ਵਾਲੇ ਤੋਂ ਨਿਯਮਾਂ ਦੀ ਗਹਿਰਾਈ ਜਾਣਨ ਦੀ ਉਮੀਦ ਰੱਖਦੇ ਹਨ।Kernighan ਦੀ “ਰੁਚੀ” ਬਾਰੇ ਗੱਲ ਇਥੇ ਆਉਂਦੀ ਹੈ: ਸਪਸ਼ਟਤਾ ਵੱਧ ਲਿਖਣ ਬਾਰੇ ਨਹੀਂ; ਇਹ ਮਨੋਰਥ ਨੂੰ ਸਪਸ਼ਟ ਬਣਾਉਣ ਬਾਰੇ ਹੈ। ਜੇ ਕੋਈ “ਸਮਾਰਟ” ਸੰਸਕਰਣ ਅੱਜ 20 ਸਕਿੰਟ ਬਚਾਉਂਦੀ ਹੈ ਪਰ ਭਵਿੱਖ ਦੇ ਹਰ ਪਾਠਕ ਲਈ 20 ਮਿੰਟ ਲਾ ਦੇਂਦੀ ਹੈ, ਤਾਂ ਇਹ ਸਮਾਰਟ ਨਹੀਂ—ਇਹ ਮਹਿੰਗਾ ਹੈ।
Kernighan ਦੀ “ਰੁਚੀ” ਅਕਸਰ ਛੋਟੇ, ਦੁਹਰਾਓਯੋਗ ਫੈਸਲਿਆਂ ਵਿੱਚ ਦਿਸਦੀ ਹੈ। ਤੁਹਾਨੂੰ ਕੋਡ ਨੂੰ ਆਸਾਨ ਬਣਾਉਣ ਲਈ ਕੋਈ ਵੱਡਾ ਰਿਫੈਕਟਰ ਨਹੀਂ ਚਾਹੀਦਾ—ਛੋਟੀਆਂ ਸਪਸ਼ਟਤਾ ਜਿੱਤ ਹਰ ਵਾਰੀ ਗੁਣਾ ਕਰਦੀਆਂ ਹਨ ਜਦ ਕੋਈ ਫਾਈਲ ਸਕੈਨ ਕਰਦਾ, ਰਹਿਤ ਬਿਹਿਉਰ ਲਈ ਖੋਜ ਕਰਦਾ ਜਾਂ ਸਮੇਂ-ਦਬਾਅ 'ਚ ਬੱਗ ਠੀਕ ਕਰਦਾ ਹੈ।
ਇੱਕ ਚੰਗਾ ਨਾਮ ਟਿੱਪਣੀਆਂ ਦੀ ਲੋੜ ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਗਲਤੀਆਂ ਨੂੰ ਛੁਪਾਉਣਾ ਮੁਸ਼ਕਿਲ ਕਰ ਦਿੰਦਾ ਹੈ।
ਮਨੋਰਥ-ਪੱਰਕ ਨਾਮਾਂ ਲਈ ਕੋਸ਼ਿਸ਼ ਕਰੋ ਜੋ ਤੁਹਾਡੀ ਟੀਮ ਵੱਲੋਂ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਸ਼ਬਦਾਂ ਨਾਲ ਮਿਲਦੇ ਹੋਣ:
invoiceTotalCents ਨੂੰ sum ਉੱਪਰ ਤਰਜੀਹ ਦਿਓ।ਜੇ ਇੱਕ ਨਾਮ ਤੁਹਾਨੂੰ ਡੀਕੋਡ ਕਰਨ ਲਈ ਮਜ਼ਬੂਰ ਕਰਦਾ ਹੈ, ਤਾਂ ਉਹ ਆਪਣਾ ਕੰਮ ਨਹੀਂ ਕਰ ਰਿਹਾ।
ਜ਼ਿਆਦਾਤਰ ਪੜ੍ਹਾਈ ਸਕੈਨ ਕਰਨ ਦੀ ਹੁੰਦੀ ਹੈ। ਲਗਾਤਾਰ ਵ੍ਹਾਈਟਸਪੇਸ ਅਤੇ ਢਾਂਚਾ ਨਜ਼ਰ ਨੂੰ ਉਨ੍ਹਾਂ ਚੀਜ਼ਾਂ ਨੂੰ ਲੱਭਣ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ: ਫੰਕਸ਼ਨ ਸੀਮਾਵਾਂ, ਕੰਡੀਸ਼ਨਲ ਅਤੇ “ਹੈਪੀ ਪਾਥ”।
ਕੁਝ ਪ੍ਰਯੋਗਿਕ ਆਦਤਾਂ:
ਜਦ ਤਰਕ ਮੁਸ਼ਕਿਲ ਹੋ ਜਾਂਦੀ ਹੈ, ਪੜ੍ਹਨਯੋਗਤਾ ਅਕਸਰ ਫੈਸਲਿਆਂ ਨੂੰ ਸਪਸ਼ਟ ਕਰਨ ਨਾਲ ਸੁਧਰਦੀ ਹੈ।
ਕੁਝ ਸ਼ੈਲੀਆਂ ਦੀ ਤੁਲਨਾ:
// Harder to scan
if (user \u0026\u0026 user.active \u0026\u0026 !user.isBanned \u0026\u0026 (role === 'admin' || role === 'owner')) {
allow();
}
// Clearer
if (!user) return deny('missing user');
if (!user.active) return deny('inactive');
if (user.isBanned) return deny('banned');
if (role !== 'admin' \u0026\u0026 role !== 'owner') return deny('insufficient role');
allow();
ਦੂਜਾ ਸੰਸਕਰਣ ਲੰਬਾ ਹੈ, ਪਰ ਇਹ ਇੱਕ ਚੈੱਕਲਿਸਟ ਵਾਂਗ ਪੜ੍ਹਦਾ ਹੈ—ਅਤੇ ਇਸ ਨੂੰ ਤਬਦੀਲ ਕਰਨ ਜਾਂ ਵਧਾਉਣ ਵਿਚ ਆਸਾਨੀ ਹੁੰਦੀ ਹੈ ਬਿਨਾਂ ਤੋੜ-ਮਰੋੜ ਦੇ।
ਇਹ ‘ਛੋਟੇ’ ਚੋਣਾਂ ਦਿਨ-ਪ੍ਰਤੀਦਿਨ ਰਖ-ਰਖਾਅ ਯੋਗ ਕੋਡ ਦਾ ਕਾਰੀਗਰੀ ਹਨ: ਨਾਮ ਜੋ ਸੱਚ ਰਹਿੰਦੇ ਹਨ, ਫਾਰਮੈਟਿੰਗ ਜੋ ਪਾਠਕ ਦੀ ਰਹਿਨੁਮਾਈ ਕਰਦੀ ਹੈ, ਅਤੇ ਕੰਟਰੋਲ ਫਲੋ ਜੋ ਕਦੇ ਵੀ ਤੁਹਾਨੂੰ ਮਾਨਸਿਕ ਗਿਨਤੀ 'ਤੇ ਨਹੀਂ ਲੈ ਜਾਂਦਾ।
Kernighan ਦੀ ਸਪਸ਼ਟਤਾ ਦਾ ਅਸਰ ਸਭ ਤੋਂ ਵੱਧ ਇਸ ਗੱਲ ਵਿੱਚ ਨਜ਼ਰ ਆਉਂਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕੰਮ ਨੂੰ ਕਿਵੇਂ ਫੰਕਸ਼ਨਾਂ ਤੇ ਮਾਡਿਊਲਾਂ ਵਿੱਚ ਵੰਡਦੇ ਹੋ। ਇੱਕ ਪਾਠਕ ਨੂੰ ਢਾਂਚਾ ਸਕੀਮ ਸਕੈਨ ਕਰਕੇ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਹਰ ਹਿੱਸਾ ਕੀ ਕਰਦਾ ਹੈ ਅਤੇ ਜਿਸ ਵਿੱਚ ਉਹ ਠੀਕ ਹੋਣ ਦੀ ਉਮੀਦ ਰੱਖ ਸਕੇ।
ਕੋਸ਼ਿਸ਼ ਕਰੋ ਕਿ ਫੰਕਸ਼ਨ ਇੱਕ ਸਮੇਂ ਵਿੱਚ ਸਿਰਫ਼ ਇੱਕ ਕੰਮ ਕਰੇ ਅਤੇ ਇੱਕ ਹੀ “ਜ਼ੂਮ ਲੈਵਲ” ਤੇ ਹੋਵੇ। ਜਦ ਇੱਕ ਫੰਕਸ਼ਨ ਵੈਰੀਫਿਕੇਸ਼ਨ, ਬਿਜ਼ਨਸ ਨਿਯਮ, ਫਾਰਮੈਟਿੰਗ ਅਤੇ I/O ਮਿਲਾ ਦੇਂਦਾ ਹੈ, ਤਾਂ ਪਾਠਕ ਨੂੰ ਕਈ ਥੀਂਗਾਂ ਇੱਕਠੇ ਰੱਖਣੀਆਂ ਪੈਂਦੀਆਂ ਹਨ।
ਇੱਕ ਤੇਜ਼ ਟੈਸਟ: ਜੇ ਤੁਸੀਂ ਕਈ ਵਾਰ ਫੰਕਸ਼ਨ ਦੇ ਅੰਦਰ “// ਹੁਣ X ਕਰੋ” ਵਰਗੀ ਟਿੱਪਣੀ ਲਿਖ ਰਹੇ ਹੋ, ਤਾਂ ਅਕਸਰ X ਲਈ ਇੱਕ ਵੱਖਰਾ, ਸਪਸ਼ਟ ਨਾਮ ਵਾਲਾ ਫੰਕਸ਼ਨ ਚੰਗਾ ਉਮੀਦ(#)ਕੈਂਡੇਟ ਹੋ ਸਕਦਾ ਹੈ।
ਲੰਬੀਆਂ ਪੈਰਾਮੀਟਰ ਲਿਸਟਾਂ ਇੱਕ ਲੁਕਿਆ ਹੋਇਆ ਜਟਿਲਤਾ ਟੈਕਸ ਹੁੰਦੀਆਂ ਹਨ: ਹਰ ਕਾਲ ਸਾਈਟ ਇੱਕ ਛੋਟੀ-ਮੋਟੀ ਕਨਫਿਗਰੇਸ਼ਨ ਫ਼ਾਈਲ ਬਣ ਜਾਂਦੀ ਹੈ।
ਜੇਕਰ ਕਈ ਪੈਰਾਮੀਟਰ ਸਦਾ ਇਕੱਠੇ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਸੋਚ-ਸਮਝ ਕੇ ਸਮੂਹਿਤ ਕਰੋ। ਓਪਸ਼ਨ ਓਬਜੈਕਟ (ਜਾਂ ਛੋਟੇ ਡੇਟਾ ਸਟ੍ਰੱਕਚਰ) ਕਾਲ-ਸਾਈਟਾਂ ਨੂੰ ਖੁਦ-ਵਿਆਖਿਆਤਮਕ ਬਣਾ ਸਕਦੇ ਹਨ—ਜੇ ਤੁਸੀਂ ਸਮੂਹ ਨੂੰ ਠੀਕ ਰੱਖੋ ਅਤੇ ਸਭ ਕੁਝ ਇੱਕ “misc” ਬੈਗ ਵਿੱਚ ਨਾ ਭਰੋ।
ਇਸ ਦੇ ਨਾਲ, ਪ੍ਰਿਮਿਟਿਵਾਂ ਦੀ ਥਾਂ ਡੋਮੇਨ ਸੰਕਲਪ ਪਾਸ ਕਰੋ। UserId ਇੱਕ string ਤੋਂ ਬਿਹਤਰ ਹੈ, ਅਤੇ DateRange (start, end) ਤੋਂ ਜ਼ਿਆਦਾ ਵਧੀਆ ਹੁੰਦਾ ਹੈ ਜਦ ਇਹ ਮੁੱਲ ਨਿਯਮ ਰੱਖਦੇ ਹਨ।
ਮਾਡਿਊਲ ਇੱਕ ਵਾਅਦਾ ਹਨ: “ਇਸ ਸੰਕਲਪ ਲਈ ਜੇ ਕੁਛ ਵੀ ਚਾਹੀਦਾ ਹੈ, ਇਹ ਥਾਂ ਹੈ, ਬਾਕੀ ਹੋਰ ਜਗ੍ਹਾ ਹੈ।” ਮਾਡਿਊਲਾਂ ਨੂੰ ਇੰਨਾ ਛੋਟਾ ਰੱਖੋ ਕਿ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਦਾ ਮਕਸਦ ਆਪਣੇ ਦਿਮਾਗ ਵਿੱਚ ਰੱਖ ਸਕੋ, ਅਤੇ ਬਾਊਂਡਰੀਆਂ ਇਸਤੇ ਤਰ੍ਹਾਂ ਬਣਾਓ ਕਿ ਸਾਈਡ-ਇਫੈਕਟ ਘੱਟ ਹੋਣ।
ਕੁਝ ਪ੍ਰਯੋਗਿਕ ਆਦਤਾਂ ਜੋ ਮਦਦ ਕਰਦੀਆਂ ਹਨ:
ਜਦ ਤੁਸੀਂ ਸਾਂਝਾ ਸਟੇਟ ਦੀ ਲੋੜ ਮਹਿਸੂਸ ਕਰੋ, ਉਸਨੂੰ ਈਮਾਨਦਾਰੀ ਨਾਲ ਨਾਮ ਦਿਓ ਅਤੇ invariants ਦਾ ਵਿਰਣਨ ਰੱਖੋ। ਸਪਸ਼ਟਤਾ ਜਟਿਲਤਾ ਤੋਂ ਬਚਾਉਣ ਬਾਰੇ ਨਹੀਂ ਹੈ—ਇਹ ਉਸਨੂੰ ਉਨ੍ਹਾਂ ਥਾਵਾਂ 'ਤੇ ਰੱਖਣ ਬਾਰੇ ਹੈ ਜਿੱਥੇ ਪਾਠਕ ਦੀ ਉਮੀਦ ਹੁੰਦੀ ਹੈ। ਵਧੇਰੇ boundary-maintenance ਲਈ, ਵੇਖੋ blog/refactoring-as-a-habit.
Kernighan ਦੀ “ਰੁਚੀ” ਟਿੱਪਣੀ ਲਿਖਣ ਦੇ ਤਰੀਕੇ ਵਿੱਚ ਵੀ ਦਿਸਦੀ ਹੈ: ਉਦੇਸ਼ ਹਰ ਲਾਈਨ ਨੂੰ ਐਨੋਟੇਟ ਕਰਨਾ ਨਹੀਂ, ਬਲਕਿ ਭਵਿੱਖ ਦੀ ਗਲਤ ਫੈਰ-ਅਟਵਾਰ ਨੂੰ ਰੋਕਣਾ ਹੈ। ਸਭ ਤੋਂ ਵਧੀਆ ਟਿੱਪਣੀ ਉਹ ਹੁੰਦੀ ਹੈ ਜੋ ਗਲਤ ਧਾਰਣਾ ਨੂੰ ਰੋਕਦੀ ਹੈ—ਖਾਸ ਕਰਕੇ ਜਦ ਕੋਡ ਸਹੀ ਹੈ ਪਰ ਹੈਰਾਨ ਕਰਨ ਵਾਲਾ ਹੈ।
ਜੋ ਟਿੱਪਣੀ ਕੋਡ ਨੂੰ ਦੁਹਰਾਉਂਦੀ ਹੈ (“i ਨੂੰ ਇੰਕ੍ਰੀਮੈਂਟ ਕਰੋ”) ਬੇਕਾਰ ਹੁੰਦੀ ਹੈ ਅਤੇ ਪਾਠਕਾਂ ਨੂੰ ਟਿੱਪਣੀਆਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨ ਦੀ ਆਦਤ ਦਿੰਦੀ ਹੈ। ਲਾਭਦਾਇਕ ਟਿੱਪਣੀਆਂ ਮਨੋਰਥ, ਤਰੱਕੀ-ਵਿਕਲਪ ਜਾਂ ਅਜਿਹੇ ਸੀਮਤਾਂ ਨੂੰ ਸਮਝਾਉਂਦੀਆਂ ਹਨ ਜੋ ਸਿੰਟੈਕਸ ਤੋਂ ਸਪਸ਼ਟ ਨਹੀਂ ਹੁੰਦੀਆਂ।
# Bad: says what the code already says
retry_count += 1
# Good: explains why the retry is bounded
retry_count += 1 # Avoids throttling bans on repeated failures
ਜੇ ਤੁਸੀਂ “ਕੀ” ਟਿੱਪਣੀਆਂ ਲਿਖਣ ਦੀ ਲਾਲਚ ਮਹਿਸੂਸ ਕਰਦੇ ਹੋ, ਤਾਂ ਇਹ ਅਕਸਰ ਇਸ ਗੱਲ ਦੀ ਨਿਸ਼ਾਨੀ ਹੁੰਦੀ ਹੈ ਕਿ ਕੋਡ ਖੁਦ ਹੋਰ ਸਪਸ਼ਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ (ਵਧੀਆ ਨਾਮ, ਛੋਟੀ ਫੰਕਸ਼ਨ, ਸਧਾਰਨ ਕੰਟਰੋਲ ਫਲੋ)। ਕੋਡ ਤੱਥ ਵਹਿੰਦਾ ਹੈ; ਟਿੱਪਣੀਆਂ ਤਰਕ ਵਹਾਉਂਦੀਆਂ ਹਨ।
ਕੋਈ ਵੀ ਚੀਜ਼ ਟਿੱਪਣੀ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਭਰੋਸਾ ਖੋ ਸਕਦੀ ਹੈ ਜਦ ਟਿੱਪਣੀ ਬੇਕਾਰ ਹੋ ਜਾਂਦੀ ਹੈ। ਜੇ ਟਿੱਪਣੀ ਵਿਕਲਪਿਕ ਹੈ, ਇਹ ਸਮੇਂ ਦੇ ਨਾਲ ਡ੍ਰਿਫਟ ਕਰੇਗੀ; ਜੇ ਇਹ ਗਲਤ ਹੋ ਜਾਵੇ, ਤਾਂ ਇਹ ਸਕ੍ਰੂ-ਅਪ ਦਾ ਸਰੋਤ ਬਣ ਜਾਂਦਾ ਹੈ।
ਪ੍ਰਯੋਗਿਕ ਆਦਤ: ਟਿੱਪਣੀ ਅਪਡੇਟਾਂ ਨੂੰ ਬਦਲਾਵ ਦੇ ਹਿਸੇ ਵਜੋਂ ਸਮਝੋ, ਨਾ ਕਿ “ਅਚ੍ਛਾ ਹੋਵੇ ਤਾਂ” ਵਾਲੀ ਚੀਜ਼। ਰਿਵਿਊز ਦੌਰਾਨ ਇਹ ਪੁੱਛਣਾ ਵਾਜਬ ਹੈ: ਕੀ ਇਹ ਟਿੱਪਣੀ ਅਜੇ ਵੀ ਵਿਹਾਰ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੈ? ਜੇ ਨਹੀਂ, ਤਾਂ ਅਪਡੇਟ ਕਰੋ ਜਾਂ ਹਟਾ ਦਿਓ। “ਕੋਈ ਟਿੱਪਣੀ ਨਹੀਂ” ਗਲਤ ਟਿੱਪਣੀ ਤੋਂ ਵਧੀਆ ਹੈ।
ਇਨਲਾਈਨ ਟਿੱਪਣੀਆਂ ਸਥਾਨਕ ਹੈਰਾਨੀ ਲਈ ਹਨ। ਵੱਡੇ ਗਾਈਡਾਂਸ ਨੂੰ docstrings, READMEs, ਜਾਂ ਡਿਵੈਲਪਰ ਨੋਟਸ ਵਿੱਚ ਰੱਖੋ—ਖਾਸ ਕਰਕੇ:
ਵਧੀਆ docstring ਕਿਸੇ ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਫੰਕਸ਼ਨ ਨੂੰ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਕਿਵੇਂ ਵਰਤਣਾ ਹੈ ਅਤੇ ਕਿਹੜੀਆਂ ਗਲਤੀਆਂ ਦੀ ਉਮੀਦ ਰੱਖਣੀ ਚਾਹੀਦੀ ਹੈ—ਬਿਨਾਂ ਇੰਪਲੀਮੇਨਟੇਸ਼ਨ ਨੂੰ ਕਥਾ ਕਰਨ ਦੇ। ਇੱਕ ਛੋਟਾ /docs ਜਾਂ /README ਨੋਟ “ਅਸੀਂ ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਕਿਉਂ ਕੀਤਾ” ਦੀ ਕਹਾਣੀ ਰੱਖ ਸਕਦਾ ਹੈ ਤਾਂ ਜੋ ਰੀਫੈਕਟਰ ਦੇ ਸਮੇਂ ਇਹ ਟਿਕੀ ਰਹੇ।
ਚੁਪ-ਚਪ ਜਿੱਤ: ਘੱਟ ਟਿੱਪਣੀਆਂ, ਪਰ ਹਰ ਇੱਕ ਆਪਣੀ ਜਗ੍ਹਾ 'ਤੇ ਲਾਜ਼ਮੀ ਹੋਵੇ।
ਜ਼ਿਆਦਾਤਰ ਕੋਡ “ਹੈਪੀ ਪਾਥ” 'ਤੇ ਠੀਕ ਦਿਸਦਾ ਹੈ। ਸਵਾਦ ਦੀ ਅਸਲੀ ਜਾਂਚ ਉਹ ਹੈ ਜੋ ਹੁੰਦਾ ਹੈ ਜਦ ਇਨਪੁਟ ਗੁੰਮ ਹੋਏ ਹੋਣ, ਸੇਵਾ ਟਾਈਮਆਊਟ ਹੋਏ ਹੋਣ ਜਾਂ ਯੂਜ਼ਰ ਕੁਝ ਅਨਪੇक्षित ਕਰੇ। ਦਬਾਅ ਹੇਠ, ਚਤੁਰ ਕੋਡ ਸਚ ਨੂੰ ਲੁਕਾਉਂਦਾ ਹੈ। ਸਪਸ਼ਟ ਕੋਡ ਅਸਫਲਤਾ ਨੂੰ ਸਪਸ਼ਟ ਅਤੇ ਠੀਕ ਕਰਨਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।
ਏਰਰ ਸੁਨੇਹੇ ਤੁਹਾਡੇ ਉਤਪਾਦ ਅਤੇ ਡੀਬੱਗਿੰਗ ਵਰਕਫਲੋ ਦਾ ਹਿੱਸਾ ਹਨ। ਉਹਨਾਂ ਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਲਿਖੋ ਜਿਵੇਂ ਅਗਲਾ ਪੜ੍ਹਨ ਵਾਲਾ ਥੱਕਿਆ ਹੋਇਆ ਅਤੇ ਆਨ-ਕੋਲ ਹੋਵੇ।
ਸ਼ਾਮਲ ਕਰੋ:
ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਲੌਗਿੰਗ ਹੈ, ਤਾਂ ਸਮਰਚਿਤ ਸੰਦਰਭ (ਜਿਵੇਂ requestId, userId, ਜਾਂ invoiceId) ਸ਼ਾਮਲ ਕਰੋ ਤਾਂ ਜੋ ਸੁਨੇਹਾ ਕਾਰਵਾਈਯੋਗ ਹੋਵੇ ਬਿਨਾਂ ਅਣਲਾਗਤ ਡੇਟਾ ਖੰਗਾਲਣ ਦੇ।
“ਸਭ ਕੁਝ ਸੰਭਾਲ ਲਵੋ” ਵਾਲੀ ਇੱਕ-ਲਾਈਨਰ ਜਾਂ ਆਮ catch-all ਕਰਕੇ ਸੰਭਵ ਹੈ ਕਿ ਚਤੁਰਾਈ ਛੁਪਾਓ। ਚੰਗੀ ਰੁਚੀ ਉਹ ਕੁਝ ਅਹਮ ਏਜ ਕੇਸ ਚੁਣਦੀ ਹੈ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਦਿਖਾਉਂਦੀ ਹੈ।
ਉਦਾਹਰਨ ਵਜੋਂ, “ਖਾਲੀ ਇਨਪੁਟ” ਜਾਂ “ਨਾਭਿ ਮਿਲਿਆ” ਲਈ ਇੱਕ ਸਪਸ਼ਟ ਸ਼ਾਖਾ ਅਕਸਰ ਇੱਕ ਲੜੀਕਾਰ ਰੂਪਾਨਤਰ ਦੇ ਮੁਕਾਬਲੇ ਵਧੀਆ ਪੜ੍ਹਦੀ ਹੈ। ਜਦ ਇੱਕ ਖਾਸ ਮਾਮਲਾ ਜ਼ਰੂਰੀ ਹੋਵੇ, ਉਸਨੂੰ ਨਾਮ ਦੇ ਕੇ ਆੜੇ ਰੱਖੋ।
ਵੱਖ-ਵੱਖ ਰਿਟਰਨ ਆਕਾਰਾਂ (ਕਦੇ ਆਬਜੈਕਟ, ਕਦੇ ਸਤਰ, ਕਦੇ false) ਪਾਠਕਾਂ ਨੂੰ ਮਾਨਸਿਕ ਫੈਸਲਾ ਵਾਲਾ ਦਰੱਖਤ ਰੱਖਣ ਲਈ ਮਜ਼ਬੂਰ ਕਰਦੀਆਂ ਹਨ। ਉਹਨਾਂ ਪੈਟਰਨਾਂ ਨੂੰ ਤਰਜੀਹ ਦਿਓ ਜੋ ਲਗਾਤਾਰ ਰਹਿੰਦੀਆਂ ਹਨ:
ਸਪਸ਼ਟ ਫੇਲ ਹੈਂਡਲਿੰਗ ਹੈਰਾਨੀ ਘਟਾਉਂਦੀ ਹੈ—ਅਤੇ ਹੈਰਾਨੀ ਉਹੀ ਥਾਂ ਹੈ ਜਿੱਥੇ ਬੱਗ ਅਤੇ ਮਿਡਨਾਈਟ ਪੇਜਜ਼ ਜ਼ਿਆਦਾ ਹੁੰਦੇ ਹਨ।
ਸਪਸ਼ਟਤਾ ਸਿਰਫ਼ ਇਸ ਬਾਰੇ ਨਹੀਂ ਹੈ ਕਿ ਤੁਸੀਂ ਕੋਡ ਲਿਖਦੇ ਸਮੇਂ ਕੀ ਸੋਚਦੇ ਸੀ। ਇਹ ਇਸ ਬਾਰੇ ਹੈ ਕਿ ਅਗਲੇ ਵਿਅਕਤੀ ਨੂੰ 4:55pm 'ਤੇ ਫਾਈਲ ਖੋਲ੍ਹਣ 'ਤੇ ਕੀ ਉਮੀਦ ਹੈ। ਲਗਾਤਾਰਤਾ “ਕੋਡ ਪੜ੍ਹਨਾ” ਨੂੰ ਪੈਟਰਨ ਪਛਾਣ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀ ਹੈ—ਘੱਟ ਚੰਗੇ-ਭੁੱਲ, ਘੱਟ ਗਲਤਫਹਮੀਆਂ, ਘੱਟ ਪਰਚਾਰ ਜੋ ਹਰ ਸਪ੍ਰਿੰਟ ਹੋਰ ਵਾਰ ਚਲਦੇ ਰਹਿੰਦੇ ਹਨ।
ਅੱਛੀ ਟੀਮ ਸਟਾਈਲ ਗਾਈਡ ਛੋਟੀ, ਵਿਸ਼ੇਸ਼ ਅਤੇ ਅਮਲੀ ਹੁੰਦੀ ਹੈ। ਇਹ ਹਰ ਪਸੰਦ ਨੂੰ ਕੋਡ ਨਹੀਂ ਕਰਦੀ; ਇਹ ਮੁੜ ਮੁੜ ਉਠਦੇ ਪ੍ਰਸ਼ਨਾਂ ਨੂੰ ਸੁਲਝਾਉਂਦੀ ਹੈ: ਨਾਮਕਰਨ ਕਨਵੈਨਸ਼ਨ, ਫਾਈਲ ਬਣਤਰ, ਏਰਰ-ਹੈਂਡਲਿੰਗ ਪੈਟਰਨ ਅਤੇ ਟੇਸਟ ਲਈ “ਡਨ” ਦਾ ਮਾਇਨਾ।
ਅਸਲੀ ਮੂੱਲ ਸਮਾਜਿਕ ਹੈ: ਇਹ ਉਹੀ ਗੱਲ ਹਰ ਨਵੇਂ ਪੀਆਰ ਨਾਲ ਮੁੜ ਆਉਣ ਦੀ ਬਹਸ ਰੋਕਦੀ ਹੈ। ਜਦ ਕੁਝ ਲਿਖਿਆ ਹੋਵੇ, ਰਿਵਿਊਜ਼ “ਮੈਂ X ਪਸੰਦ ਕਰਦਾ ਹਾਂ” ਤੋਂ ਬਦਲ ਕੇ “ਅਸੀਂ X 'ਤੇ ਸਹਿਮਤ ਹਾਂ (ਅਤੇ ਏਹੀ ਕਾਰਨ)” ਬਣ ਜਾਂਦੇ ਹਨ। ਇਸਨੂੰ ਜੀਵੰਤ ਅਤੇ ਆਸਾਨੀ ਨਾਲ ਮਿਲਣਯੋਗ ਰੱਖੋ—ਕਈ ਟੀਮਾਂ ਇਸਨੂੰ ਰਿਪੋ ਵਿੱਚ ਲਗਾ ਦਿੰਦੀਆਂ ਹਨ (ਉਦਾਹਰਨ: /docs/style-guide.md) ਤਾਂ ਜੋ ਇਹ ਕੋਡ ਦੇ ਨੇੜੇ ਰਹੇ।
ਕਿਸੇ ਵੀ ਮਾਪੇ ਜਾਣ ਵਾਲੇ ਅਤੇ ਬੋਰਿੰਗ ਨਿਯਮ ਲਈ ਫਾਰਮੇਟਰ ਅਤੇ ਲਿੰਟਰ ਵਰਤੋ:
ਇਸ ਨਾਲ ਮਨੁੱਖਾਂ ਨੂੰ ਮਤਲਬ 'ਤੇ ਧਿਆਨ ਕਰਨ ਲਈ ਖਾਲੀ ਮਿਲਦਾ ਹੈ: ਨਾਮਕਰਨ, API ਆਕਾਰ, ਏਜ ਕੇਸ ਅਤੇ ਇਹ ਕਿ ਕੋਡ ਮਨੋਰਥ ਨਾਲ ਮਿਲਦਾ ਹੈ।
ਹੱਥ-ਨਿਯਮ ਅਜੇ ਵੀ ਜ਼ਰੂਰੀ ਹਨ ਜਦੋਂ ਉਹ ਡਿਜ਼ਾਈਨ ਫੈਸਲਿਆਂ ਦੀ ਵਿਆਖਿਆ ਕਰਦੇ ਹਨ—ਉਦਾਹਰਨ ਲਈ, “ਨੈਸਟਿੰਗ ਘਟਾਉਣ ਲਈ ਪਹਿਲਾਂ ਰਿਟਰਨ ਤਰਜੀਹ ਦਿਓ” ਜਾਂ “ਹਰ ਮਾਡਿਊਲ ਲਈ ਇੱਕ ਪਬਲਿਕ ਐਂਟਰੀ ਪੋਇੰਟ”। ਟੂਲ ਇਹਨਾਂ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਿਆਇਕ ਨਹੀਂ ਕਰ ਸਕਦੇ।
ਕਈ ਵਾਰੀ ਜਟਿਲਤਾ ਜਾਇਜ਼ ਹੁੰਦੀ ਹੈ: ਕਠੋਰ ਪਰਫਾਰਮੈਂਸ ਬਜਟ, ਐਂਬੈਡਡ ਸੀਮਾਵਾਂ, ਮੁਸ਼ਕਿਲ concurrency, ਜਾਂ ਪਲੇਟਫਾਰਮ-ਖ਼ਾਸ ਵਿਵਹਾਰ। ਸਮਝੌਤਾ ਇਹ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ: ਛੋਟੀਆਂ ਛੁਟੀਆਂ ਮਨਜ਼ੂਰ ਹਨ, ਪਰ ਉਹ ਸਪਸ਼ਟ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ।
ਸਧਾਰਨ ਮਿਆਰ ਮਦਦਗਾਰ ਹੈ: ਛੋਟੇ ਟਿੱਪਣੀ ਵਿੱਚ ਟਰੇਡ-ਆਫ ਦਾ ਦਸਤਾਵੇਜ਼ ਕਰੋ, ਜਦ ਪਰਫਾਰਮੈਂਸ ਨੂੰ ਦਲੀਲ ਵਜੋਂ ਲਿਆਉਣਾ ਹੋਵੇ ਤਾਂ ਮਾਇਕ੍ਰੋ-ਬੈਂਚਮਾਰਕ ਜਾਂ ਮਾਪ ਦਿਖਾਓ, ਅਤੇ ਜਟਿਲ ਕੋਡ ਨੂੰ ਇਕ ਸਾਫ ਇੰਟਰਫੇਸ ਦੇ ਪਿੱਛੇ ਅਲੱਗ ਕਰੋ ਤਾਂ ਕਿ ਬਾਕੀ ਕੋਡਬੇਸ ਪੜ੍ਹਨਯੋਗ ਰਹੇ।
ਚੰਗੀ ਕੋਡ ਰਿਵਿਊ ਨੂੰ ਨਿਰੀਖਣ ਵਾਂਗ ਨਹੀਂ ਮਹਿਸੂਸ ਹੋਣਾ ਚਾਹੀਦਾ—ਇਹ ਇਕ ਛੋਟੀ, ਕੇਂਦ੍ਰਿਤ ਪਾਠ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ “ਚੰਗੀ ਰੁਚੀ” ਵਿੱਚ। Kernighan ਦਾ ਨكية ਨਹੀਂ ਕਿ ਚਤੁਰ ਕੋਡ ਬੁਰਾ ਹੈ—ਪ੍ਰਸੰਗ ਇਹ ਹੈ ਕਿ ਚਤੁਰਾਈ ਮਹਿੰਗੀ ਪੈਂਦੀ ਹੈ ਜਦ ਹੋਰ ਲੋਕ ਉਸਦੇ ਨਾਲ ਜੀਉਂਦੇ ਹਨ। ਰਿਵਿਊਜ਼ ਉਹ ਥਾਂ ਹਨ ਜਿੱਥੇ ਟੀਮ ਇਹ ਟਰੇਡ-ਆਫ ਨੂੰ ਵਿਖਾ ਸਕਦੀ ਹੈ ਅਤੇ ਸਪਸ਼ਟਤਾ ਨੂੰ ਮਨਜ਼ੂਰ ਕਰ ਸਕਦੀ ਹੈ।
ਪਹਿਲਾਂ ਪੁੱਛੋ: “ਕੀ ਇੱਕ ਟੀਮੀ ਮੈਂਬਰ ਇੱਕ ਪਾਸ ਵਿੱਚ ਇਹ ਸਮਝ ਸਕਦਾ ਹੈ?” ਇਹ ਅਕਸਰ ਨਾਮ, ਢਾਂਚਾ, ਟੇਸਟ ਅਤੇ ਵਿਹਾਰ ਦੇਖਣ ਦਾ ਮਤਲਬ ਹੁੰਦਾ ਹੈ, ਮਾਈਕ੍ਰੋ-ਉਪਯੋਗਤਾ ਦੀ ਜਾਂਚ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ।
ਜੇ ਕੋਡ ਸਹੀ ਹੈ ਪਰ ਪੜ੍ਹਨ ਵਿੱਚ ਮੁਸ਼ਕਿਲ ਹੈ, ਤਾਂ ਪੜ੍ਹਨਯੋਗਤਾ ਨੂੰ ਇੱਕ ਅਸਲ ਖ਼ਾਮੀ ਵਜੋਂ ਤਬਦੀਲ ਕਰੋ। ਨਾਂ-ਬਦਲਣ, ਲੰਮੇ ਫੰਕਸ਼ਨ ਨੂੰ ਵੰਡਣ, ਕੰਟਰੋਲ ਫਲੋ ਨੂੰ ਸੋਧਣ ਜਾਂ ਇੱਕ ਛੋਟਾ ਟੈਸਟ ਜੋ ਉਮੀਦਸ਼ੁਦਾ ਵਿਹਾਰ ਦਰਸਾਉਂਦਾ ਹੈ—ਇਹ ਸਾਰੀਆਂ ਸੁਝਾਵਾਂ ਹਨ। ਇੱਕ ਰਿਵਿਊ ਜੋ “ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ, ਪਰ ਮੈਨੂੰ ਇਹ ਸਮਝ ਨਹੀਂ ਆ ਰਿਹਾ” ਫੜ ਲੈਂਦਾ ਹੈ ਉਹ ਭਵਿੱਖ ਵਿੱਚ ਕੋਡ ਬਾਰੇ ਚਿੰਤਾ ਨੂੰ ਰੋਕਦਾ ਹੈ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਕ੍ਰਮ ਜੋ ਅਚ্ছে ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ:
ਜਦ ਫੀਡਬੈਕ ਅੰਕ-ਸੰਘਰਸ਼ ਵਾਂਗੋਂ ਆਉਂਦਾ ਹੈ ਤਾਂ ਰਿਵਿਊ ਗਲਤ ਪਾਸੇ ਚੱਲਦੇ ਹਨ। “ਤੁਸੀਂ ਇਹ ਕਿਉਂ ਕੀਤਾ?” ਦੀ ਥਾਂ ਕੋਸ਼ਿਸ਼ ਕਰੋ:
ਸਵਾਲ ਸਹਿਯੋਗ ਨੂੰ ਬੁਲਾਉਂਦੇ ਹਨ ਅਤੇ ਅਕਸਰ ਉਹ ਪਾਬੰਦੀਆਂ ਸਾਹਮਣੇ ਲਿਆਂਦੇ ਹਨ ਜਿਹਨਾਂ ਬਾਰੇ ਤੁਸੀਂ ਜਾਣਦੇ ਨਹੀਂ ਸੀ। ਸੁਝਾਵ ਦਿਓ ਤਰਸਾਊਂਦੇ ਹੋਏ ਦਿਸ਼ਾ ਦਿਖਾਉਂਦੇ ਹਨ ਬਿਨਾਂ ਕਸੂਰ ਠਹਿਰਾਏ। ਇਹ ਟੋਨ ਹੀ ਰੁਚੀ ਟੀਮ ਵਿੱਚ ਵੰਡਦੀ ਹੈ।
ਜੇ ਤੁਸੀਂ ਲਗਾਤਾਰ ਪੜ੍ਹਨਯੋਗਤਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਰਿਵਿਊਅਰ ਦੇ ਮੂਡ 'ਤੇ ਨਿਰਭਰ ਨਾ ਰਹੋ। ਆਪਣੇ ਰਿਵਿਊ ਟੈਮਪਲੇਟ ਅਤੇ definition of done ਵਿੱਚ ਕੁਝ “ਸਪਸ਼ਟਤਾ ਚੈੱਕ” ਸ਼ਾਮਲ ਕਰੋ। ਉਨ੍ਹਾਂ ਨੂੰ ਛੋਟਾ ਅਤੇ ਵਿਸ਼ੇਸ਼ ਰੱਖੋ:
ਸਮੇਂ ਦੇ ਨਾਲ, ਇਹ ਰਿਵਿਊਜ਼ ਨੂੰ ਪਾਲਿਸਿੰਗ ਤੋਂ ਸੁਧਾਰ ਸਿਖਾਉਂਦੇ ਪ੍ਰਕਿਰਿਆ ਬਣਾਉਂਦੇ ਹਨ—ਇਹੀ ਦਿਨ-ਪ੍ਰਤੀਦਿਨ ਅਨੁਸ਼ਾਸਨ Kernighan ਨੇ ਪ੍ਰਚਾਰ ਕੀਤਾ।
LLM ਟੂਲ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਕਰਨ ਵਾਲਾ ਕੋਡ ਪੈਦਾ ਕਰ ਸਕਦੇ ਹਨ, ਪਰ “ਕੰਮ ਕਰਦਾ ਹੈ” Kernighan ਦਾ ਮਾਪਦੰਡ ਨਹੀਂ ਸੀ—ਉਸਦਾ ਮਕਸਦ ਸੀ “ਸੰਚਾਰ ਕਰਨਾ”। ਜੇ ਤੁਹਾਡੀ ਟੀਮ ਚੈਟ-ਅਧਾਰਤ ਵਰਕਫਲੋ ਵਰਤੀਦੀ ਹੈ (ਉਦਾਹਰਨ ਲਈ, chat ਤੋਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਬਣਾਉਣਾ ਅਤੇ ਜਨਰੇਟ ਕੀਤੇ ਕੋਡ 'ਤੇ итਰੇਟ਼ ਕਰਣਾ), ਤਾਂ ਪੜ੍ਹਨਯੋਗਤਾ ਨੂੰ ਪਹਿਲੀ-ਕ੍ਰੈਂਡ ਮੰਨੋ।
ਪਲੇਟਫਾਰਮਾਂ ਤੇ ਜਿਵੇਂ Koder.ai, ਜਿੱਥੇ ਤੁਸੀਂ ਚੈਟ ਪ੍ਰਾਂਪਟ ਤੋਂ React frontends, Go backends ਅਤੇ Flutter mobile apps ਜਨਰੇਟ ਕਰ ਸਕਦੇ ਹੋ (ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਸਰੋਤ ਕੋਡ ਨਿਰਯਾਤ ਕਰ ਸਕਦੇ ਹੋ), ਉਹੀ ਰੁਚੀ-ਚਲਿਤ ਆਦਤਾਂ ਲਾਗੂ ਹੁੰਦੀਆਂ ਹਨ:
ਤੇਜ਼ੀ ਸਭ ਤੋਂ ਵਧੀਆ ਹੈ ਜਦ ਆਉਟਪੁੱਟ ਮਨੁੱਖਾਂ ਲਈ ਸਮੀਖਿਆਯੋਗ, ਰੱਖ-ਰਖਾਅ ਯੋਗ ਅਤੇ ਵਧਾਉਣਯੋਗ ਹੋਵੇ।
Kernighan ਦੀ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਸੋਚ C ਬਾਰੇ ਘੱਟ ਅਤੇ ਇੱਕ ਡਿਰੈਕਸ਼ਨ ਬਾਰੇ ਜ਼ਿਆਦਾ ਹੈ: ਕੋਡ ਇੱਕ ਸੰਚਾਰ ਮਾਧਿਅਮ ਹੈ।
ਭਾਸ਼ਾਵਾਂ ਅਤੇ ਫਰੇਮਵਰਕ ਬਦਲਦੇ ਹਨ, ਪਰ ਟੀਮਾਂ ਨੂੰ ਅਜੇ ਵੀ ਐਸਾ ਕੋਡ ਚਾਹੀਦਾ ਹੈ ਜੋ ਅਸਾਨੀ ਨਾਲ ਸਕੈਨ, ਤਰੱਕੀ, ਰਿਵਿਊ ਅਤੇ ਡੀਬੱਗ ਕੀਤਾ ਜਾ ਸਕੇ—ਖਾਸ ਕਰਕੇ ਮਹੀਨਿਆਂ ਬਾਅਦ ਜਾਂ ਸਮਾਂ-ਦਬਾਅ ਹੇਠਾਂ।
“ਉੱਚੀ ਰੁਚੀ” ਦਾ ਅਰਥ ਹੈ ਲਗਾਤਾਰ ਉਹ ਸਭ ਤੋਂ ਸਧਾਰਨ ਪਰ ਸਪਸ਼ਟ ਵਿਕਲਪ ਚੁਣਨਾ ਜੋ ਮਨੋਰਥ ਨੂੰ ਸੁਚਿੱਤ ਕਰੇ।
ਇੱਕ ਵਰਤੋਂਯੋਗ ਟੈਸਟ: ਕੀ ਕੋਈ ਟੀਮੀ ਮੈਂਬਰ ਪੁੱਛ ਸਕਦਾ ਹੈ “ਇਹ ਕੀ ਕਰ ਰਿਹਾ ਹੈ, ਅਤੇ ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਕਿਉਂ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ?” ਬਿਨਾਂ ਕਿਸੇ ਚਤੁਰ ਤਰਕ ਜਾਂ ਛੁਪੇ ਧਾਰਣਾਂ ਦੇ।
ਕਾਰਨ ਜ਼ਿਆਦਾਤਰ ਕੋਡ ਲਿਖਣ ਨਾਲੋਂ ਕਈ ਵਾਰ ਪੜ੍ਹਿਆ ਜਾਂਦਾ ਹੈ।
ਪੜ੍ਹਨ ਵਾਲਿਆਂ ਲਈ ਅਪਟੀਮੇਾਈਜ਼ ਕਰਨਾ ਓਨਬੋਰਡਿੰਗ ਸਮਾਂ ਘਟਾਉਂਦਾ ਹੈ, ਰਿਵਿਊ ਘਰਤਾਂ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਗਲਤ ਬਦਲਾਵਾਂ ਦੇ ਖ਼ਤਰੇ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ—ਖਾਸ ਕਰਕੇ ਜਦ ਮੁਰੰਮਤ ਕਰਨ ਵਾਲਾ “ਭਵਿੱਖ ਦਾ ਤੁਸੀਂ” ਹੋਵੇ ਜਿਸਦੇ ਕੋਲ ਘੱਟ ਸੰਦਰਭ ਹੁੰਦਾ ਹੈ।
“ਚਤੁਰਾਈ ਟੈਕਸ” ਇਹ ਦਿੱਸਦਾ ਹੈ:
ਜੇ ਚਤੁਰ ਸੰਸਕਰਣ ਅੱਜ ਸੈਕਿੰਡਾਂ ਬਚਾਉਂਦੀ ਹੈ ਪਰ ਹਰ ਵਾਰ ਛੇਤੀ ਛੇਤੀ ਮਿੰਟਾਂ ਖਰਚ ਕਰਵਾਉਂਦੀ ਹੈ, ਤਾਂ ਇਹ ਨੈੱਟ ਨੁਕਸਾਨ ਹੈ।
ਅਕਸਰ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਣ ਵਾਲੇ ਆਮ ਪੈਟਰਨ:
17, 0.618, -1) ਜੋ ਨਿਯਮ ਨੂੰ ਕੋਡ ਕਰਦੇ ਹਨ ਜਿਹੜੇ ਯਾਦ ਨਹੀਂ ਰਹਿੰਦੇਇਹ ਪੈਟਰਨ ਇਹਸਾਰ ਕਰਦੇ ਹਨ ਕਿ ਅੰਦਰੂਨੀ ਹਾਲਤ ਲੁਕਾਈ ਜਾਂਦੀ ਹੈ ਅਤੇ ਰਿਵਿਊ ਵਿੱਚ ਏਜ ਕੇਸ ਛੱਡੇ ਜਾ ਸਕਦੇ ਹਨ।
ਜਦ ਇਹ ਮਾਨਸਿਕ ਭਾਰ ਘਟਾਉਂਦਾ ਹੈ ਤਾਂ ਥੋੜ੍ਹਾ ਲੰਮਾ ਕੋਡ ਵਧੀਆ ਹੁੰਦਾ ਹੈ।
ਕਦਮਾਂ ਨੂੰ ਨਾਮਾਂ ਨਾਲ ਸਪਸ਼ਟ ਕਰਨਾ (ਉਦਾਹਰਨ: validate → normalize → compute) ਸਹੀਤਾ ਜਾਂਚਣਾ, ਡੀਬੱਗ ਆਸਾਨ ਕਰਨਾ ਅਤੇ ਭਵਿੱਖੀ ਬਦਲਾ ਬੇਖੌਫ ਬਣਾਉਂਦਾ ਹੈ—ਭਾਵੇਂ ਇਹ ਕੁਝ ਲਾਈਨਾਂ ਵਧਾ ਦੇਵੇ।
ਇਹ ਅਦਾਇਗੀ ਲਈ ਉੱਤਮ ਆਦਤਾਂ:
invoiceTotalCents ਬਿਹਤਰ ਹੈ sum ਦੇ)ਜੇ ਤੁਹਾਨੂੰ ਕਿਸੇ ਨਾਮ ਨੂੰ ਡੀਕੋਡ ਕਰਨਾ ਪੈਂਦਾ ਹੈ, ਤਾਂ ਉਹ ਆਪਣਾ ਕੰਮ ਨਹੀਂ ਕਰ ਰਿਹਾ; ਨਾਮ ਨੂੰ ਵਾਧੂ ਟਿੱਪਣੀਆਂ ਦੀ ਲੋੜ ਘਟਾਉਣੀ ਚਾਹੀਦੀ ਹੈ।
ਅਸਾਨੀ ਨਾਲ ਸਕੈਨ ਕਰਨ ਲਈ ਸਧਾਰਨ, ਸਪਸ਼ਟ ਬ੍ਰਾਂਚਿੰਗ ਪਸੰਦ ਕਰੋ ਅਤੇ “ਹੈਪੀ ਪाथ” ਨੂੰ ਦਰਸਾਓ।
ਆਮ ਤਰੀਕੇ ਜੋ ਮਦਦ ਕਰਦੇ ਹਨ:
ਕੰਮੈਂਟ ‘ਕਿਉਂ’ ਨੂੰ ਸਮਝਾਉਣੇ ਚਾਹੀਦੇ ਹਨ, ‘ਕਿਆ’ ਨੂੰ ਨਹੀਂ।
ਵਧੀਆ ਟਿੱਪਣੀਆਂ ਮਨੋਰਥ, ਤਰੱਕੀ-ਵਿਕਲਪ ਜਾਂ ਅਤਿ-ਸਪਸ਼ਟ ਧਾਰਣਾਵਾਂ ਨੂੰ ਵਿਆਖਿਆ ਕਰਦੀਆਂ ਹਨ। ਸਪਸ਼ਟ ਕੋਡ ਨੂੰ ਦੱਸਣ ਵਾਲੀਆਂ ਟਿੱਪਣੀਆਂ ਲਿਖਣ ਦੀ ਲੋੜ ਘੱਟ ਹੁੰਦੀ ਹੈ; ਟਿੱਪਣੀਆਂ ਨੂੰ ਅਪਡੇਟ ਕਰਨਾ ਵੀ ਵਿਅਕਤੀਗਤ ਬਦਲਾਵ ਦਾ ਹਿੱਸਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ—ਗਲਤ ਟਿੱਪਣੀ ਨਾ ਹੋਣੀ ਚਾਹੀਦੀ।
ਮਕੈਨਿਕਲ ਨਿਯਮਾਂ ਲਈ ਟੂਲ ਵਰਤੋ (ਫਾਰਮੇਟਰ, ਲਿੰਟਰ) ਅਤੇ ਅਨੁਰਾਗ ਲਈ ਮਨੁੱਖੀ ਰਿਵਿਊ ਛੱਡੋ।
ਲਘੂ-ਫੁਟਕਾਰ ਸਟਾਈਲ ਗਾਈਡ ਆਮ ਰੁਝਾਨਾਂ ਲਈ ਫੈਸਲੇ ਫਿਕਸ ਕਰਦੀ ਹੈ ਤਾਂ ਕਿ ਰਿਵਿਊਜ਼ ਵਿਅਕਤਿਗਤ ਪਸੰਦ ਤੋਂ ਵੱਧ ਸਪਸ਼ਟਤਾ ਅਤੇ ਵਿਵਹਾਰ ਬਾਰੇ ਹੋਣ।
ਜੇ ਤੁਸੀਂ ਪਰਫਾਰਮੈਂਸ ਜਾਂ ਸੀਮਾਵਾਂ ਲਈ ਖਾਸ ਛੋਟ ਦੀ ਆਗਿਆ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਉਸਨੂੰ ਦਸਤਾਵੇਜ਼ ਕਰੋ ਅਤੇ ਜਟਿਲਤਾ ਨੂੰ ਸਾਫ ਇੰਟਰਫੇਸ ਦੇ ਪਿੱਛੇ ਥਾਂ ਦਿਓ।