ਸਥਿਰ ਕੋਡ ਸਮੀਖਿਆਵਾਂ ਲਈ Claude Code ਸਟਾਈਲ ਗਾਈਡ ਪ੍ਰੰਪਟ

ਕਿਉਂ ਸਟਾਈਲ ਗਾਈਡ ਉਲੰਘਣ ਤੇਜ਼ੀ ਨਾਲ ਫੈਲਦੇ ਹਨ

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

ਸਟਾਈਲ ਡ੍ਰਿਫਟ ਅਕਸਰ ਇਸ ਤਰ੍ਹਾਂ ਦਿਸਦੀ ਹੈ: ਇੱਕ ਫਾਇਲ userID ਵਰਤਦੀ ਹੈ, ਦੂਜੀ userId, ਤੇ ਤੀਜੀ uid। ਇੱਕ ਹੈਂਡਲਰ { error: "..." } ਵਾਪਸ ਕਰਦਾ ਹੈ, ਦੂਜਾ throws ਕਰਦਾ ਹੈ, ਇਕ ਹੋਰ ਲੌਗ ਕਰਦਾ ਅਤੇ null ਵਾਪਸ ਕਰਦਾ ਹੈ। ਹਰ ਬਦਲਾਅ ਛੋਟਾ ਹੁੰਦਾ ਹੈ, ਪਰ ਮਿਲ ਕੇ ਇਹ ਇਕ ਰਿਪੋ ਬਣਾਉਂਦੇ ਹਨ ਜਿੱਥੇ ਪੈਟਰਨ ਅਣਪੇਸ਼ੀਨੀਆਂ ਬਣ ਜਾਂਦੇ ਹਨ।

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

ਇਸ ਲਈ ਲਕਸ਼ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ ਸਹਿ-ਮਿਆਰੀ ਰਵਾਇਤਾਂ ਤੇ, ਨਾ ਕਿ ਨਿੱਜੀ ਪਸੰਦਾਂ ਤੇ। ਸਵਾਲ ਇਹ ਨਹੀਂ ਹੁੰਦਾ "ਕੀ ਮੈਨੂੰ ਇਹ ਨਾਮ ਪਸੰਦ ਹੈ?" ਸਵਾਲ ਇਹ ਹੈ "ਕੀ ਇਹ ਉਹ ਨਿਯਮ ਮੈਨੂੰ ਮੇਰੇ ਸਹਿਮਤ ਨਿਯਮਾਂ ਨਾਲ ਮਿਲਦਾ ਹੈ ਤਾਂ ਕਿ ਅਗਲਾ ਵਿਅਕਤੀ ਬਿਨਾਂ ਸੋਚੇ ਹੀ ਇਸ ਨੂੰ ਫਾਲੋ ਕਰ ਸਕੇ?"

ਉਲੰਘਣਾਂ ਨੂੰ ਜਲਦੀ ਪਕੜਨਾ ਮਤਲਬ ਹੈ ਮਾੜੇ ਪੈਟਰਨ ਨੂੰ ਕਾਪੀ-ਪੇਸਟ ਈਂਧਨ ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ ਰੋਕਣਾ। ਨਵੇਂ ਅਤੇ ਸੋਧੇ ਹੋਏ ਕੋਡ 'ਤੇ ਧਿਆਨ ਦਿਓ, ਕਿਸੇ ਨਵੀਂ ਅਸਮਰੂਪਤਾ ਦੀ ਪਹਿਲੀ ਵਾਰ ਦੀ ਦੁਰੁਸਤਗੀ ਕਰੋ, ਅਤੇ ਉਹ ਮਰਜਜ ਜੋ ਨਵਾਂ ਡ੍ਰਿਫਟ ਲਿਆਉਂਦੇ ਹਨ, ਉਹ ਬਲੌਕ ਕਰੋ। ਜਦੋਂ ਤੁਸੀਂ ਕੋਈ ਮੁੱਦਾ ਫਲੈਗ ਕਰਦੇ ਹੋ, ਇੱਕ ਛੋਟੀ ਪਸੰਦੀਦਾ ਉਦਾਹਰਣ ਜੋੜੋ ਤਾਂ ਕਿ ਲੋਕ ਅਗਲੀ ਵਾਰ ਉਸਦੀ ਨਕਲ ਕਰ ਸਕਣ।

ਇੱਕ ਹਕੀਕੀ ਉਦਾਹਰਣ: ਇੱਕ ਡਿਵੈਲਪਰ ਨਵਾਂ API endpoint ਜੋੜਦਾ ਹੈ ਅਤੇ ਡੀਬੱਗ ਲਈ raw request bodies ਲੌਗ ਕਰਦਾ ਹੈ। ਜੇ ਇਹ ਲੈਂਡ ਕਰ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਅਗਲਾ endpoint ਇਸਨੂੰ ਕਾਪੀ ਕਰ ਦੇਵੇਗਾ, ਅਤੇ ਜਲਦੀ ਹੀ ਸੈਂਸੇਟਿਵ ਡਾਟਾ ਲੌਗਜ਼ ਵਿੱਚ ਆ ਜਾਣਗਾ। ਪਹਿਲੀ PR ਵਿੱਚ ਇਸਨੂੰ ਫੜਨਾ ਸਸਤਾ ਹੈ; ਫੈਲਣ ਤੋਂ ਬਾਅਦ ਫੜਨਾ ਦਰਦਨਾਕ ਅਤੇ ਖਤਰਨਾਕ ਹੈ।

ਆਪਣੀ ਸਟਾਈਲ ਗਾਈਡ ਨੂੰ ਸਪਸ਼ਟ, ਟੈਸਟ-ਯੋਗ ਨਿਯਮਾਂ ਵਿੱਚ ਬਦਲੋ

ਸਮੀਖਿਆਵਾਂ ਵਿੱਚ ਇੱਕ ਸਟਾਈਲ ਗਾਈਡ ਤਦ ਹੀ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦੋਂ ਉਹ ਚੇਕਲਿਸਟ ਵਾਂਗ ਪੜ੍ਹਾਈ ਜਾਵੇ, ਨਾ ਕਿ ਰੁਝਾਨਾਂ ਦੇ ਸੈੱਟ ਵਾਂਗ। ਹਰ ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼ ਨੂੰ_diff_ 'ਤੇ ਚੈਕ ਕੀਤੇ ਜਾ ਸਕਦੇ ਨਿਯਮ ਵਜੋਂ ਮੁੜ ਲਿਖੋ।

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

ਹਰ ਨਿਯਮ ਦੀ ਮਜ਼ਬੂਤੀ ਪਹਿਲਾਂ ਤੋਂ ਨਿਰਧਾਰਤ ਕਰੋ:

• ਲਾਜ਼ਮੀ (Mandatory): ਫੇਲ ਹੋਵਣ 'ਤੇ ਬਦਲਾਅ ਬਲੌਕ ਹੋਵੇਗਾ।
• ਸੁਝਾਈ ਗਈ (Recommended): ਇਸਨੂੰ ਠੀਕ ਕਰੋ ਜਦ ਤੱਕ ਕੋਈ ਵਾਜਬ ਵਜਹ ਨਾ ਹੋਵੇ।
• ਵਿਕਲਪਿਕ (Optional): ਚੰਗਾ ਹੈ, ਪਰ ਕਦੇ ਵੀ ਬਲੌਕ ਨਹੀਂ ਕਰੇਗਾ।

ਸਕੋਪ ਸੈੱਟ ਕਰੋ ਤਾਂ ਕਿ ਸਮੀਖਿਆ ਬੇਅੰਤ ਰੀਫੈਕਟਰਾਂ ਵਿੱਚ ਨਾ ਬਦਲੇ। ਇੱਕ ਸਰਲ ਨਿਯਮ ਚੰਗਾ ਹੈ: "ਨਵਾਂ ਅਤੇ ਸੋਧਿਆ ਕੋਡ ਮੈਲ ਖਾਣਾ ਚਾਹੀਦਾ ਹੈ; ਮੌਜੂਦਾ ਬਿਨਾਂ ਛੁਏ ਕੋਡ ਨੂੰ ਮੁੜ ਲਿਖਿਆ ਨਹੀਂ ਜਾਵੇਗਾ ਜਦ ਤੱਕ ਉਹ ਫਿਕਸ ਨੂੰ ਰੋਕਦਾ ਨਹੀਂ।" ਜੇ ਤੁਸੀਂ ਕਲੀਨਅਪ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਇਹਨੂੰ ਇੱਕ ਵੱਖਰੀ ਟਾਸਕ ਵਜੋਂ ਟਾਇਮਬਾਕਸ ਕਰੋ।

ਇਕ ਸਮੀਖਿਆ ਤੋਂ ਤੁਸੀਂ ਜੋ output ਚਾਹੁੰਦੇ ਹੋ, ਉਸਨੂੰ ਵੀ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਤਾਂ ਕਿ ਕਾਰਵਾਈ ਆਸਾਨ ਹੋ: ਇੱਕ pass/fail ਫੈਸਲਾ, ਫਾਇਲ ਅਤੇ ਲਾਈਨ ਰਿਫਰੰਸਾਂ ਨਾਲ ਉਲੰਘਣਾਂ ਦੀ ਸੂਚੀ, ਸੁਝਾਏ ਗਏ ਠੀਕ-ਕਰੇ ਜਾਣ ਵਾਲੇ ਕਟੋਰੇਆਂ ਦੇ ਰੂਪ ਵਿੱਚ ਸੁਝਾਅ, ਅਤੇ ਸੰਖੇਪ ਰਿਸਕ ਨੋਟ ਜਦੋਂ ਕੋਈ ਚੀਜ਼ ਬੱਗ ਜਾਂ ਲੀਕ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦੀ ਹੋਵੇ।

ਉਦਾਹਰਣ: ਜੇ ਇੱਕ PR raw user tokens ਲੌਗ ਕਰਦਾ ਹੈ, ਸਮੀਖਿਆ "ਲੌਗਿੰਗ: ਕਦੇ ਵੀ ਸੀਕ੍ਰੇਟਸ ਨਾ ਲੌਗ ਕਰੋ" ਹੇਠਾਂ ਅਸਫਲ ਹੋਵੇਗੀ ਅਤੇ ਬਦਲੇ ਵਿੱਚ request ID ਲੌਗ ਕਰਨ ਦੀ ਸਿਫਾਰਸ਼ ਕਰੇਗੀ।

ਪ੍ਰੰਪਟ ਸਟ੍ਰਕਚਰ ਜੋ ਰੁਝਾਨਾਂ ਦੀ ਬਜਾਏ ਨਿਯਮ ਲਾਗੂ ਕਰੇ

ਸਟਾਈਲ ਪ੍ਰੰਪਟ ਅਸਫਲ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਉਹ ਪਸੰਦਾਂ ਵਾਲੇ ਲਹਜੇ ਵਿੱਚ ਲਿਖੇ ਜਾਂਦੇ ਹਨ। ਇੱਕ ਚੰਗੀ ਸਮੀਖਿਆ ਪ੍ਰੰਪਟ ਇੱਕ ਸਹਿਮਾ-ਨਾਮੇ ਵਾਂਗ ਪੜ੍ਹਦੀ ਹੈ: ਸਪਸ਼ਟ ਗੈਰ-ਚੋਣਯੋਗ ਨਿਯਮ, ਸਪਸ਼ਟ ਨਾਮ ਵਾਲੀਆਂ ਛੁਟਾਂ, ਅਤੇ ਪੇਸ਼ਾਨਗੀਆਂ ਵਾਲਾ ਆਉਟਪੁਟ।

ਦੋ ਛੋਟੇ ਬਲਾਕਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: ਕੀ ਲਾਜ਼ਮੀ ਹੈ ਅਤੇ ਕੀ ਝੁਕਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਫਿਰ ਇੱਕ ਫੈਸਲਾ ਨਿਯਮ ਜੋੜੋ: "ਜੇ ਅਸਪਸ਼ਟ ਹੈ, Needs Clarification ਦਰਜ ਕਰੋ। ਅਨੁਮਾਨ ਨਾ ਲਗਾਓ।"

ਸਬੂਤ ਲਾਜ਼ਮੀ ਬਣਾਓ। ਜਦੋਂ ਸਹਾਇਕ ਕੋਈ ਉਲੰਘਣ ਫਲੈਗ ਕਰੇ, ਉਸਨੂੰ ਅੰਦਰੂਨੀ ਤੌਰ ਤੇ ਸਟ੍ਰਿੰਗ, ਫਾਇਲ ਪਾਥ ਅਤੇ ਸੰਕੁਚਿਤ ਕੋਟ ਦਿਓ—ਮੁੱਢੇ ਤੌਰ 'ਤੇ ਸਹੀ ਉਲੰਘਣ ਨੂੰ ਦਰਸਾਉਣ ਲਈ ਇਹ ਇਕ ਜ਼ਰੂਰੀ ਸ਼ਰਤ ਹੈ।

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

ਇੱਥੇ ਇਕ ਢਾਂਚਾ ਹੈ ਜੋ ਤੁਸੀਂ ਮੁੜ ਵਰਤ ਸਕਦੇ ਹੋ:

Role: strict style guide reviewer.
Input: diff (or files changed) + style guide rules.
Non-negotiables: [list].
Allowed exceptions: [list].
Scope: ONLY comment on changed lines and directly impacted code paths. No unrelated refactors.
Evidence: Every finding MUST include (a) file path, (b) exact identifier(s), (c) short quote.
Output: structured compliance report with pass/fail per category + minimal fixes.

ਰਿਪੋਰਟ ਨੂੰ ਹਰ ਵਾਰੀ ਉਨ੍ਹਾਂ ਹੀ ਸੈਕਸ਼ਨਾਂ ਨੂੰ ਰੱਖਣ ਦੀ ਮੰਗ ਕਰੋ, ਭਾਵੇਂ ਕੁਝ ਵਿੱਚ "No issues found" ਹੀ ਕਿਉਂ ਨਾ ਹੋਵੇ: Naming, Layering, Error handling, Logging।

ਜੇ ਇਹ ਕਹਿੰਦੀ ਹੈ "service layer leaking DB details," ਤਾਂ ਇਹ ਕੁਝ ਅਜਿਹਾ ਕੋਟ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ: internal/orders/service/order_service.go ਅਤੇ ਉਸ ਸਟੀਕ ਕਾਲ (ਉਦਾਹਰਣ ਵਜੋਂ db.QueryContext) ਤਾਂ ਜੋ ਤੁਸੀਂ ਬਿਨਾਂ ਚਰਚਾ ਕੀਤੇ ਲੀਕ ਨੂੰ ਠੀਕ ਕਰ ਸਕੋ।

ਕਦਮ-ਦਰ-ਕਦਮ: ਇੱਕ ਸਟਾਈਲ-ਚੈਕ ਪ੍ਰੰਪਟ ਵਰਕਫਲੋ ਬਣਾਉ

ਇੱਕ ਸਟਾਈਲ ਗਾਈਡ ਉਸ ਵੇਲੇ ਟਿਕਦੀ ਹੈ ਜਦੋਂ ਪ੍ਰਕਿਰਿਆ ਦੁਹਰਾਏ ਜਾਣਯੋਗ ਹੋਵੇ। ਲਕਸ਼ ਹੈ ਕਿ ਮਾਡਲ ਨਿਯਮਾਂ ਦੀ ਜਾਂਚ ਕਰੇ, ਸੁਆਦ ਦੀ ਨੱਗਲ ਨਾ ਕਰੇ, ਅਤੇ ਹਰ ਵਾਰੀ ਇਕੋ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰੇ।

ਇੱਕ ਸਧਾਰਨ ਦੋ-ਪਾਸ ਵਰਕਫਲੋ ਵਰਤੋ:

1. ਆਪਣੇ ਮਿਆਰਾਂ ਨੂੰ ਇੱਕ ਸੰਕੁਚਿਤ, ਨੰਬਰਵਾਰ ਨਿਯਮ ਸੂਚੀ ਵਜੋਂ ਪੇਸਟ ਕਰੋ (10-25 ਲਾਈਨਾਂ)। ਹਰ ਨਿਯਮ ਟੈਸਟ-ਯੋਗ ਰੱਖੋ।
2. ਬਦਲਾਅ ਲਈ ਸੰਦਰਭ ਜੋੜੋ: diff, ਛੂਹੇ ਗਏ ਫਾਇਲ, ਅਤੇ ਉਦੇਸ਼ ਬਾਰੇ ਇੱਕ ਵਾਕ।
3. ਪਹਿਲਾਂ ਇੱਕ ਉਲੰਘਣ ਰਿਪੋਰਟ ਮੰਗੋ। ਫਾਇਲ ਅਤੇ ਲਾਈਨ ਰਿਫਰੰਸ, ਇੱਕ ਛੋਟੀ ਵਜੇਹ, ਅਤੇ ਸਟਾਈਲ ਨਿਯਮ ਨੰਬਰ ਲੋੜੀਂਦੇ ਹਨ।
4. ਸਿਰਫ ਰਿਪੋਰਟ ਤੋਂ ਬਾਅਦ, ਸੰਭਵਤਮ ਛੋਟੀ ਪੈਚ ਮੰਗੋ ਜੋ ਅਨੁਕੂਲਤਾ ਲਿਆ ਸਕੇ।
5. ਅੱਪਡੇਟ ਕੀਤੇ ਕੋਡ 'ਤੇ ਬਾਕੀ ਰਹਿਣ ਦੀ ਪੁਸ਼ਟੀ ਲਈ ਠੀਕ ਓਹੀ ਪ੍ਰੰਪਟ ਦੁਬਾਰਾ ਚਲਾਓ।

ਉਦਾਹਰਣ: ਇੱਕ PR ਨਵਾਂ endpoint ਜੋੜਦਾ ਹੈ। ਪਹਿਲਾ ਪਾਸ ਇਹ ਦਰਸਾਉੰਦਾ ਹੈ ਕਿ ਹੈਂਡਲਰ PostgreSQL ਨੂੰ ਸਿੱਧਾ ਕਾਲ ਕਰ ਰਿਹਾ ਹੈ (layering), ਰਿਕਵੇਸਟ structs ਲਈ ਮਿਲੀ-ਜੁਲੀ ਨਾਮਕਰਨ (naming), ਅਤੇ ਪੂਰੇ emails ਲੌਗ ਹੋ ਰਹੇ ਹਨ (logging)। ਦੂਜੇ ਪਾਸ 'ਤੇ ਘੱਟੋ-ਘੱਟ ਠੀਕ-ਕਰੇ ਗਏ ਬਦਲਾਅ: DB ਕਾਲ ਨੂੰ ਇੱਕ service ਜਾਂ repository ਵਿੱਚ ਮੂਵ ਕਰੋ, struct ਨੂੰ rename ਕਰੋ, ਅਤੇ ਲੌਗ ਵਿੱਚ email ਨੂੰ(mask) ਕਰੋ। ਹੋਰ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ।

ਨਾਮਕਰਨ ਨਿਯਮ: ਛੋਟੀ ਗੱਲਾਂ ਫੜਨ ਵਾਲੇ ਪ੍ਰੰਪਟ

ਨਾਮਕਰਨ ਦੇ ਮੁੱਦੇ ਨਾਬਜੀਂ ਹੁੰਦੇ ਹਨ, ਪਰ ਇਹ ਅਸਲ ਲਾਗਤ ਪੈਦਾ ਕਰਦੇ ਹਨ: ਲੋਕ ਭੁਲ-ਸਮਝਦੇ ਹਨ, ਖੋਜ ਮੁਸ਼ਕਲ ਹੁੰਦੀ ਹੈ, ਅਤੇ "ਲੱਗਭੱਗ ਉਹੀ" ਨਾਮ ਵਧ ਜਾਂਦੇ ਹਨ।

ਉਸ ਨਾਂ-ਨਿਯਮਾਂ ਨੂੰ ਰੱਖੋ ਜੋ ਸਮੀਖਿਆਕਾਰ ਨੂੰ ਪੂਰੇ ਬਦਲਾਅ ਵਿੱਚ ਲਾਗੂ ਕਰਨ ਦੀ ਲੋੜ ਹੈ: ਫਾਇਲ ਨਾਮ, ਐਕਸਪੋਰਟ ਕੀਤੀਆਂ ਕਿਸਮਾਂ, ਫੰਕਸ਼ਨ, ਵੇਰੀਏਬਲ, ਕਾਂਸਟੈਂਟ ਅਤੇ ਟੈਸਟ। ਕੇਸਿੰਗ ਦੀ ਵਿਆਖਿਆ ਸਪਸ਼ਟ ਕਰੋ (camelCase, PascalCase, snake_case) ਅਤੇ ਇੱਕ ਐਕ੍ਰੋਨਿਮ ਨਿਯਮ ਚੁਣੋ (ਉਦਾਹਰਣ ਲਈ APIClient ਵਿ. ApiClient) ਅਤੇ ਹਮੇਸ਼ਾ ਇਸਦੀ ਪਾਲਣਾ ਕਰੋ।

ਸ਼ੇਅਰ ਕੀਤੇ ਸ਼ਬਦ-ਭੰਡਾਰ ਨੂੰ ਵੀ ਸਟੈਂਡਰਡ ਕਰੋ: error types, log fields, ਅਤੇ config keys। ਜੇ ਲੌਗਜ਼ request_id ਵਰਤਦੇ ਹਨ, ਤਾਂ reqId ਜਾਂ requestId ਨੂੰ ਇੱਕ ਫਾਇਲ ਵਿੱਚ ਮਨਜ਼ੂਰ ਨਾ ਕਰੋ।

ਇੱਕ ਵਰਤੋਂਯੋਗ ਸਮੀਖਿਆਦਾਰ ਹਦਾਇਤ:

Check every new or renamed identifier. Enforce casing + acronym rules.
Flag vague names (data, info, handler), near-duplicates (userId vs userID), and names that contradict behavior.
Prefer domain language: business terms over generic tech words.

ਇਕ ਰਿਪੋਰਟ ਮੰਗੋ: ਸਭ ਤੋਂ ਭਿੰਨਢੇ ਹੋਏ ਤਿੰਨ ਨਾਮ, ਕੋਈ ਵੀ near-duplicates ਅਤੇ ਕਿਸ ਨੂੰ ਰੱਖਣਾ ਹੈ, ਨਾਲ ਹੀ ਕੋਈ ਵੀ log/config/error ਨਾਮ ਜੋ ਮਿਆਰ ਨਾਲ ਨਹੀਂ ਮਿਲਦੇ।

ਲੇਅਰਿੰਗ ਨਿਯਮ: ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਨੂੰ ਮਿਲਾਉਣ ਤੋਂ ਰੋਕੋ

ਲੇਅਰਿੰਗ ਨਿਯਮ ਸਪਸ਼ਟ ਭਾਸ਼ਾ ਵਿੱਚ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦੇ ਹਨ: ਹੈਂਡਲਰ HTTP ਨਾਲ ਗੱਲ ਕਰਦਾ ਹੈ, ਸਰਵਿਸ ਬਿਜ਼ਨੈਸ ਨਿਯਮ ਰੱਖਦੀ ਹੈ, repository ਡੇਟਾਬੇਸ ਨਾਲ ਗੱਲ ਕਰਦੀ ਹੈ।

ਨਿਰਭਰਤਾ ਦਿਸ਼ਾ ਲਾਕ ਕਰੋ। ਹאַנדਲਰ ਸਿਰਫ ਸਰਵਿਸ ਨੂੰ ਕਾਲ ਕਰ ਸਕਦਾ ਹੈ। ਸਰਵਿਸ repository ਨੂੰ ਕਾਲ ਕਰ ਸਕਦੀ ਹੈ। repository ਸਰਵਿਸ ਜਾਂ ਹੈਂਡਲਰ ਨੂੰ ਕਾਲ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ। ਹેન્ડਲਰਾਂ ਨੂੰ ਡੇਟਾਬੇਸ ਕੋਡ, SQL ਹੈਲਪਰਾਂ, ਜਾਂ ORM ਮਾਡਲ ਨਾ ਇੰਪੋਰਟ ਕਰਨ ਦਿਓ। ਜੇ ਤੁਸੀਂ shared ਪੈਕੇਜ (config, time, IDs) ਵਰਤਦੇ ਹੋ, ਉਹਨਾਂ ਨੂੰ ਐਪ ਲੌਜਿਕ ਤੋਂ ਮੁਕਤ ਰੱਖੋ।

ਕਰਾਸ-ਕੱਟਿੰਗ ਕੰਮ ਨੂੰ ਇਕ ਘਰ 'ਤੇ ਪਿਨ ਕਰੋ। Validation ਆਮ ਤੌਰ 'ਤੇ ਬਾਊਂਡਰੀ 'ਤੇ request shape ਲਈ ਅਤੇ ਸਰਵਿਸ ਵਿੱਚ ਬਿਜ਼ਨੈਸ ਨਿਯਮ ਲਈ ਹੁੰਦੀ ਹੈ। Authorization ਅਕਸਰ ਹੈਂਡਲਰ ਵਿੱਚ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ (identity, scopes), ਪਰ ਅੰਤਿਮ ਫੈਸਲਾ ਸਰਵਿਸ ਦੁਆਰਾ ਲਾਗੂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। Mapping ਲੇਅਰ ਦੇ ਕਿਨਾਰਿਆਂ 'ਤੇ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ: ਹੈਂਡਲਰ HTTP ਨੂੰ domain input ਵਿੱਚ ਮੈਪ ਕਰੇ, repository DB rows ਨੂੰ domain types ਵਿੱਚ ਮੈਪ ਕਰੇ।

ਇਸਨੂੰ ਪ੍ਰੰਪਟ ਵਿੱਚ ਰੱਖਣ ਲਈ:

Check layering: handler -> service -> repository only.
Report any leaks:
- DB types/queries in handlers or services
- HTTP request/response types inside services or repositories
- repository returning DB models instead of domain objects
- auth/validation mixed into repository
For each leak, propose the smallest fix: move function, add interface, or rename package.

ਰਿਪੋਰਟ ਸਪਸ਼ਟ ਬਣਾਓ: ਫਾਇਲ ਦਾ ਨਾਮ, ਜਿਸ ਲੇਅਰ ਵਿਚ ਇਹ ਹੋਣਾ ਚਾਹੀਦਾ ਸੀ, ਉਹ ਇੰਪੋਰਟ ਜਾਂ ਕਾਲ ਜੋ ਨਿਯਮ ਤੋੜਦੀ ਹੈ, ਅਤੇ ਉਹ ਘੱਟੋ-ਘੱਟ ਬਦਲਾਅ ਜੋ ਪੈਟਰਨ ਦੇ ਫੈਲਾਅ ਨੂੰ ਰੋਕੇ।

ਤਰੁੱਟੀ ਸੰਭਾਲ ਨਿਯਮ: ਦਬਾਅ ਹੇਠਾਂ ਇਕਸਾਰਤਾ

ਅਧਿਕਤਮ ਸਟਾਈਲ ਵਾਲੀਆਂ ਚਰਚਾਵਾਂ ਉਥੇ ਜ਼ੋਰ ਨਾਲ ਉਦਵਿਗਨ ਹੋਦੀਆਂ ਹਨ ਜਦੋਂ ਕੁਝ production ਵਿੱਚ ਟੁੱਟਦਾ ਹੈ। ਇੱਕ ਸਪਸ਼ਟ error handling ਨੀਤੀ fixes ਨੂੰ ਠੰਡਾ ਰੱਖਦੀ ਹੈ ਕਿਉਂਕਿ ਹਰ ਕੋਈ ਜਾਣਦਾ ਹੈ ਕਿ "ਛੰਗਾ" ਕੀ ਹੈ।

ਫਿਲਾਸਫੀ ਲਿਖੋ ਅਤੇ ਇਸਨੂੰ ਅਜ਼ਮਾਉਣ ਵਿੱਚ ਲਗਾਓ। ਉਦਾਹਰਣ ਲਈ: "ਸੰਦੇਸ਼ ਜੋੜਨ ਲਈ errors ਨੂੰ wrap ਕਰੋ; ਨਵਾਂ error ਸਿਰਫ ਉਹ ਵੇਲੇ ਬਣਾਓ ਜਦੋਂ ਅਰਥ ਬਦਲ ਰਿਹਾ ਹੋਵੇ ਜਾਂ ਯੂਜ਼ਰ-ਮੈਸੇਜ ਲਈ ਮੈਪ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੋਵੇ। ਸਿਸਟਮ ਬਾਉਂਡਰੀ 'ਤੇ ਹੀ خام errors ਵਾਪਸ ਕਰੋ।" ਇਹ ਇਕ ਵਾਕ ਬੇਹਤ ਸਾਰੇ ਬੇਤਰਤੀਬੀ ਪੈਟਰਨ ਨੂੰ ਰੋਕਦਾ ਹੈ।

ਯੂਜ਼ਰ-ਸਾਮ੍ਹਣੇ ਵਾਲੇ ਟੈਕਸਟ ਨੂੰ ਅੰਦਰੂਨੀ ਵੇਰਵੇ ਤੋਂ ਵੱਖ ਕਰੋ। ਯੂਜ਼ਰ ਸੁਨੇਹੇ ਛੋਟੇ ਅਤੇ ਸੁਰੱਖਿਅਤ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਅੰਦਰੂਨੀ errors ਵਿੱਚ ਓਪਰੇਸ਼ਨ ਨਾਮ ਅਤੇ ਕੁੰਜੀ ਪਛਾਣਕਰਤਾ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਸੀਕ੍ਰੇਟ ਨਹੀਂ।

ਸਮੀਖਿਆ ਵਿੱਚ ਕੁਝ ਆਮ ਗਲਤੀਆਂ 'ਤੇ ਨਿਗਰਾਨੀ ਕਰੋ: swallowed errors (ਲੌਗ ਤਾਂ ਕੀਤੇ ਜਾਣ ਪਰ ਵਾਪਸ ਨਾ ਕੀਤੇ ਜਾਣ), ambiguous returns (ਫੇਲ ਹੋਣ ਦੇ ਬਾਵਜੂਦ nil value ਅਤੇ nil error), ਅਤੇ ਯੂਜ਼ਰ-ਸਾਮ੍ਹਣੇ message ਜੋ stack traces, query text, tokens ਜਾਂ PII ਲੀਕ ਕਰਦੇ ਹੋਣ। ਜੇ ਤੁਸੀਂ retries ਜਾਂ timeouts ਸਹਿਯੋਗ ਕਰਦੇ ਹੋ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ explicit ਰੱਖੋ।

ਉਦਾਹਰਣ: checkout ਕਾਲ timeout ਹੁੰਦੀ ਹੈ। ਯੂਜ਼ਰ ਨੂੰ ਦਿਸਦਾ ਹੈ "Payment service is taking too long." ਅੰਦਰੋਂ, timeout ਨੂੰ wrap ਕਰੋ ਅਤੇ op=checkout.charge ਅਤੇ order ID ਸ਼ਾਮਿਲ ਕਰੋ ਤਾਂ ਕਿ ਇਹ searchable ਅਤੇ actionable ਹੋਵੇ।

ਲੌਗਿੰਗ ਨਿਯਮ: ਪੜ੍ਹਨਯੋਗ, ਖੋਜਯੋਗ ਅਤੇ ਸੁਰੱਖਿਅਤ

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

ਲੌਗ ਲੈਵਲ ਗੈਰ-ਚੋਣਯੋਗ ਬਣਾਓ: debug ਵਿਕਾਸੀ ਵੇਰਵਾ ਲਈ, info ਆਮ milestones ਲਈ, warn ਅਣਉਮੀਦਿਤ ਪਰ ਸੰਭਾਲੇ ਗਏ ਹਾਲਾਤ ਲਈ, ਅਤੇ error ਜਦੋਂ ਯੂਜ਼ਰ-ਮੁਖਾਬਲਾ ਕਾਰਵਾਈ ਫੇਲ ਹੁੰਦੀ ਹੈ ਜਾਂ ਧਿਆਨ ਲੋੜੀਂਦਾ ਹੈ। "fatal" ਜਾਂ "panic" ਘੱਟ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ ਅਤੇ ਇੱਕ ਸਪਸ਼ਟ ਕ੍ਰੈਸ਼ ਨੀਤੀ ਨਾਲ ਜੁੜੇ ਹੋਏ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।

ਸੰਰਚਿਤ ਲੌਗ ਜ਼ਿਆਦਾ ਅਹਿਮੀਅਤ ਰੱਖਦੇ ਹਨ। ਡੈਸ਼ਬੋਰਡ ਅਤੇ ਅਲਰਟ ਤੋੜਨ ਤੋਂ ਬਚਾਉਣ ਲਈ ਸਥਿਰ ਕੁੰਜੀਆਂ ਦੀ ਜ਼ਰੂਰਤ ਹੈ। ਛੋਟੀ ਕੋਰ ਸੈੱਟ ਨਿਰਧਾਰਤ ਕਰੋ (ਉਦਾਹਰਣ: event, component, action, status, duration_ms) ਅਤੇ ਇਹਨਾਂ ਦੀ ਲਗਾਤਾਰ ਪਾਲਣਾ ਕਰੋ।

ਸੰਵੇਦਨਸ਼ੀਲ ਡਾਟਾ ਨੂੰ ਕਠੋਰ ਰੋਕੋ। ਇਹ ਸਪਸ਼ਟ ਕਰੋ ਕਿ ਕੀ ਕਦੇ ਵੀ ਲੌਗ ਨਹੀਂ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ: passwords, auth tokens, ਪੂਰੇ credit cards, secrets, ਅਤੇ raw personal data। ਉਹ ਚੀਜ਼ਾਂ ਜੋ ਨਜ਼ਰ ਆਉਂਦੀਆਂ ਭਲੇ ਹੀ ਨਰਮਲ ਲੱਗਦੀਆਂ ਹਨ ਪਰ ਨਹੀਂ ਹਨ, ਉਨ੍ਹਾਂ ਨੂੰ ਵੀ ਉੱਠਾਓ—ਜਿਵੇਂ password reset links, session IDs, ਅਤੇ ਪੂਰੇ request bodies।

Correlation IDs ਡੀਬੱਗਿੰਗ ਨੂੰ ਲੇਅਰਾਂ ਦੇ ਵਿਚਕਾਰ ਸੰਭਵ ਬਣਾਉਂਦੇ ਹਨ। ਹਰ request-bound ਲਾਈਨ ਵਿੱਚ request_id ਦੀ ਲੋੜ ਰੱਖੋ। ਜੇ ਤੁਸੀਂ user_id ਲੌਗ ਕਰਦੇ ਹੋ, ਤਾਂ ਇਹ ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਕਦੋਂ ਇਸ ਦੀ ਆਗਿਆ ਹੈ ਅਤੇ ਗੈਰ-ਮੌਜੂਦ ਜਾਂ ਗੁਪਤਯ ਸਥਿਤੀ ਵਿੱਚ ਕਿਵੇਂ ਦਰਸਾਉਣਾ ਹੈ।

ਇੱਕ ਦੁਹਰਾਏ ਜਾਣਯੋਗ ਪ੍ਰੰਪਟ ਬਲਾਕ:

Review the changes for logging conventions:
- Check level usage (debug/info/warn/error). Flag any level that does not match impact.
- Verify structured fields: require stable keys and avoid free-form context in the message.
- Confirm correlation identifiers: request_id on all request-bound logs; user_id only when allowed.
- Flag any sensitive data risk (tokens, secrets, personal data, request/response bodies).
- Identify noisy logs (in loops, per-item logs, repeated success messages) and missing context.
Return: (1) violations with file/line, (2) suggested rewrite examples, (3) what to add or remove.

ਮਰਜ ਤੋਂ ਪਹਿਲਾਂ, ਇੱਕ ਤੇਜ਼ "ਸੁਰੱਖਿਆ ਪਾਸ": ਕੋਈ ਵੀ ਨਵਾਂ ਲੌਗ ਜੋ request-bound ਕੰਮ ਲਈ request_id ਗੁਆ ਚੁੱਕਾ ਹੈ, ਕੋਈ ਨਵਾਂ ਕੀਂਜ ਜੋ ਮੌਜੂਦਾ ਨਾਮ ਬਦਲਦਾ ਹੈ (userId ਵੈ. user_id), ਕੋਈ error log ਜਿਸ 'ਚ ਕੀ ਫੇਲ ਹੋਇਆ ਇਹ ਨਹੀਂ ਦਿਖ ਰਿਹਾ (operation, resource, status), ਕੋਈ high-volume ਲੌਗ ਜੋ ਹਰ request 'ਤੇ ਚੱਲੇਗਾ, ਅਤੇ ਕੋਈ ਵੀ ਸੀਕ੍ਰੇਟ ਜਾਂ ਨਿਜੀ ਡਾਟਾ ਜੋ ਫੀਲਡ ਜਾਂ ਮੈਸੇਜ ਵਿੱਚ ਆ ਸਕਦੀ ਹੈ—ਇਹਨਾਂ ਚੀਜ਼ਾਂ ਨੂੰ ਫਲੈਗ ਕਰੋ।

ਉਲੰਘਣਾਂ ਨੂੰ ਫੈਲਣ ਤੋਂ ਪਹਿਲਾਂ ਕਿਵੇਂ ਫੜਣਾ

ਸਟਾਈਲ ਡ੍ਰਿਫਟ ਨੂੰ build break ਵਾਂਗ treat ਕਰੋ, ਨਾ ਕਿ ਸਿਫ਼ਾਰਸ਼ ਵਾਂਗ। ਇੱਕ ਸਖ਼ਤ gate ਜੋ ਮਰਜ ਤੋਂ ਪਹਿਲਾਂ ਚਲਦੀ ਹੈ ਅਤੇ ਇੱਕ ਸਪਸ਼ਟ pass ਜਾਂ fail ਵਾਪਸ ਕਰਦੀ ਹੈ, ਸ਼ਾਮਿਲ ਕਰੋ। ਜੇ ਇੱਕ ਲਾਜ਼ਮੀ ਨਿਯਮ ਟੁਟਿਆ (ਨਾਮਕਰਨ, ਲੇਅਰ ਬਾਉਂਡਰੀ, ਲੌਗਿੰਗ ਸੁਰੱਖਿਆ, ਤਰੁੱਟੀ ਸੰਭਾਲ), ਤਾਂ ਉਹ ਫੇਲ ਹੋ ਅਤੇ ਸਹੀ ਫਾਇਲਾਂ ਅਤੇ ਲਾਈਨਾਂ ਦੀ ਨਿਸ਼ਾਨਦੇਹੀ ਕਰੇ।

Gate ਨੂੰ ਛੋਟਾ ਰੱਖੋ। ਇੱਕ ਕਾਰਗਰ ਤਰਕੀਬ ਇਹ ਹੈ ਕਿ ਹਰ ਨਿਯਮ ਲਈ YES/NO ਚੈੱਕਲਿਸਟ ਮੰਗੋ, ਅਤੇ ਜੇ ਕੋਈ ਆਈਟਮ NO ਆਏ ਤਾਂ ਮਨਜ਼ੂਰੀ ਰੱਦ।

ਇੱਕ PR-ਸਾਈਜ਼ ਚੈੱਕਲਿਸਟ ਜੋ ਜ਼ਿਆਦਾਤਰ ਸਮੱਸਿਆਵਾਂ ਫੜ ਲੈਂਦੀ ਹੈ:

• Naming: ਫਾਇਲਾਂ, ਕਿਸਮਾਂ, ਅਤੇ ਫੰਕਸ਼ਨਾਂ ਲਈ ਮਨਜ਼ੂਰ ਕੀਤਾ ਪੈਟਰਨ
• Layering: ਕੋਈ ਸਿੱਧਾ ਕਾਲ ਜੋ ਲੇਅਰਾਂ ਨੂੰ ਸਕਿਪ ਕਰਦਾ ਹੋ (ਉਦਾਹਰਣ: ਹੈਂਡਲਰ ਤੋਂ DB ਕੈੱਲ)
• Errors: context ਨਾਲ ਨਿਯਮਤ ਤਰੀਕੇ ਨਾਲ ਵਾਪਸ ਕੀਤੀਆਂ ਗਈਆਂ, ਕੁਝ ਵੀ ਚੁੱਪ ਨਹੀਂ ਕੀਤਾ ਗਿਆ
• Logging: ਇਕਸਾਰ ਫੀਲਡ, ਕੋਈ ਸੀਕ੍ਰੇਟ ਨਹੀਂ, ਅਤੇ ਲੈਵਲ ਪ੍ਰਭਾਵ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੋਇਆ
• Tests/docs: ਜੇ ਹਵਾਲਾ ਜਾਂ public APIs ਬਦਲੇ ਹਨ ਤਾਂ ਅਪਡੇਟ ਕੀਤੇ ਹੋਏ

ਜਦੋਂ ਟੂਲ ਸੁਝਾਅ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਇਹ ਮੰਗੋ ਕਿ ਹਰ ਟਚ ਕੀਤੇ ਨਿਯਮ ਲਈ ਇੱਕ ਛੋਟਾ ਅਨੁਕੂਲ ਸਨਿੱਪੇਟ ਦਿੱਤਾ ਜਾਵੇ। ਇਹ ਅਜਿਹੀਆਂ vague feedback ਨੂੰ ਰੋਕਦਾ ਹੈ ਜਿਵੇਂ "ਸਪਸ਼ਟਤਾ ਲਈ rename ਕਰੋ"।

ਪ੍ਰੰਪਟ ਨਾਲ ਸਟਾਈਲ ਲਾਗੂ ਕਰਨ ਸਮੇਂ ਆਮ ਫੰਦ

ਸਟਾਈਲ ਗਾਈਡ ਫੇਲ ਹੋਣ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਰੂਮ ਛੱਡਣਾ ਹੈ। ਜੇ ਦੋ ਸਮੀਖਿਆਕਾਰ ਇੱਕੋ ਨਿਯਮ ਨੂੰ ਵੱਖ-ਵੱਖ ਤਰੀਕਿਆਂ ਨਾਲ ਸਮਝ ਸਕਦੇ ਹਨ, ਤਾਂ ਟੂਲ ਸੁਆਦ ਨੂੰ ਲਾਗੂ ਕਰੇਗਾ, ਨਾਂ ਕਿ ਮਿਆਰਾਂ ਨੂੰ।

ਨਾਮਕਰਨ ਇਸਦਾ ਆਮ ਉਦਾਹਰਣ ਹੈ। "ਸਾਫ਼ ਨਾਮ ਵਰਤੋਂ" ਟੈਸਟਬਲ ਨਹੀਂ ਹੈ। ਇਸਨੂੰ ਤੰਗ ਕਰੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਜਾਂਚ ਸਕੋ: "ਫੰਕਸ਼ਨਾਂ ਦੇ ਨਾਮ ਕਿਰਿਆਵਾਂ ਹੋਣ (ਜਿਵੇਂ createInvoice), ਬੂਲੀਅਨ is/has/can ਨਾਲ ਸ਼ੁਰੂ, exported types PascalCase."

ਹੋਰ ਫੰਦ: ਸਭ ਕੁਝ ਇਕੱਠੇ ਮੰਗਣਾ। ਜਦੋਂ ਇੱਕ ਪ੍ਰੰਪਟ ਨਾਮਕਰਨ, ਲੇਅਰਿੰਗ, errors, logging, tests, ਅਤੇ performance ਸਾਰੇ ਕਵਰ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਤਾਂ ਫੀਡਬੈਕ ਥਲ੍ਹੂ ਹੋ ਜਾਂਦਾ ਹੈ। ਜਦੋਂ ਡਿਪਥ ਚਾਹੀਦੀ ਹੋਵੇ ਤਾਂ ਸਮੀਖਿਆ ਨੂੰ ਧਿਆਨਕੇਂਦਰਿਤ ਪਾਸਾਂ ਵਿੱਚ ਵੰਡੋ, ਜਾਂ gate ਪ੍ਰੰਪਟ ਨੂੰ ਫਕਤ ਲਾਜ਼ਮੀ ਨਿਯਮਾਂ ਤੱਕ ਸੀਮਿਤ ਰੱਖੋ।

ਜੋ ਸਮੱਸਿਆਵਾਂ ਤਰੱਕੀ ਨੂੰ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਡ੍ਰਿਫਟ ਕਰਨ ਦਿੰਦੀਆਂ ਹਨ:

• ਅਸਪਸ਼ਟ ਨਿਯਮ: "ਸਾਫ਼" ਅਤੇ "ਇਕਸਾਰ" ਨੂੰ ਮਾਪਣਯੋਗ ਭਾਸ਼ਾ ਨਾਲ ਬਦਲੋ।
• ਸਟਾਈਲ ਫਿਕਸ ਨਾਲ redesign ਮਿਲਾਉਣਾ: ਪ੍ਰੰਪਟ ਨੂੰ ਨਵੀਂ ਆਰਕੀਟੈਕਚਰ ਸੁਝਾਉਣ ਦੀ ਆਗਿਆ ਨਾ ਦਿਓ।
• ਬਿਨਾਂ ਕੋਟ ਕੀਤੇ ਸਬੂਤ: ਹਰ ਟਿੱਪਣੀ ਨੂੰ ਸਟਿਕ-ਸਟ੍ਰਿੰਗ ਜਾਂ ਸਨਿੱਪੇਟ ਕੋਟ ਕਰਨ ਦੀ ਲੋੜ ਰੱਖੋ।
• ਚੁੱਪ ਛੁਟਾਂ: ਜੇ ਤੁਸੀਂ ਛੁਟ ਦੀ ਆਗਿਆ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਇੱਕ ਸੰਖੇਪ ਨੋਟ ਲਾਜ਼ਮੀ ਕਰੋ ਕਿ ਕਿਉਂ ਅਤੇ ਕਦੋਂ ਇਹ ਹਟਾਈ ਜਾਵੇਗੀ।

ਜੇ ਤੁਸੀਂ ਪ੍ਰੰਪਟ ਨੂੰ ਟੈਸਟਾਂ ਵਾਂਗ ਤੇਬਤ ਕਰੋਗੇ, ਤਾਂ ਤੁਹਾਨੂੰ ਪੇਸ਼ਗੋਹ enforcement ਮਿਲੇਗੀ। ਜੇ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਸਲਾਹ ਵਾਂਗ ਮੰਨਦੇ ਹੋ, ਤਾਂ ਉਲੰਘਣ ਛੁਪ ਕੇ ਆ ਕੇ ਵਧ ਜਾਏਗੀ।

ਹਰ ਬਦਲਾਅ 'ਤੇ ਦੌੜਾਉਣ ਲਈ ਇੱਕ ਛੋਟੀ ਚੈੱਕਲਿਸਟ

diff ਉੱਤੇ ਇੱਕ ਤੇਜ਼ ਪਾਸ ਚਲਾਓ (ਗੌਦੇ ਰਿਪੋ ਨਹੀਂ) ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ:

• Naming: ਨਵੇਂ identifiers ਤੁਹਾਡੇ ਪੈਟਰਨ (ਕੇਸ, prefix, suffix) ਦੇ ਅਨੁਸਾਰ ਹਨ। ਇਕ ਕਾਂਸਪਟ ਲਈ ਇਕੋ ਨਾਂ ਹਰ ਫਾਇਲ ਵਿੱਚ।
• Layering: ਨਿਰਭਰਤਾਵਾਂ ਸਿਮਤ ਦਿਸ਼ਾ ਵਿੱਚ ਹੀ ਹਨ। ਨੀਵੇਂ ਲੇਅਰ ਉੱਚੇ ਲੇਅਰ ਨੂੰ ਇੰਪੋਰਟ ਨਹੀਂ ਕਰਦੇ।
• Errors: ਸਮਰੱਥਾ ਨਾਲ context ਦੇ ਨਾਲ ਵਾਪਸ ਕੀਤੀਆਂ ਗਈਆਂ। ਕੁਝ ਵੀ ਚੁੱਪ ਨਹੀਂ।
• Logging: ਠੀਕ ਲੈਵਲ, ਸਥਿਰ ਫੀਲਡ, ਅਤੇ ਕੋਈ ਸੀਕ੍ਰੇਟ ਜਾਂ ਨਿੱਜੀ ਡਾਟਾ ਨਹੀਂ।
• Final pass: ਸਮੀਖਿਆਕਾਰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਕਹਿੰਦਾ ਹੈ: "no mandatory violations found", ਜਾਂ ਉਹ ਉਲੰਘਣਾਂ ਦੀ ਸੂਚੀ ਦਿੰਦਾ ਹੈ ਜੋ ਮਰਜ ਤੋਂ ਪਹਿਲਾਂ ਠੀਕ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ।

ਹਰ ਬਦਲਾਅ ਨਾਲ ਇੱਕ ਛੋਟਾ ਪ੍ਰੰਪਟ ਟੈਮਪਲੈਟ ਪੇਸਟ ਕਰੋ:

Review ONLY the changed code against our rules for naming, layering, errors, and logging.
List mandatory violations first (with file + line if available). Then list optional suggestions.
End with either: “no mandatory violations found” or “mandatory violations found”.

ਉਦਾਹਰਣ: ਹੈਂਡਲਰ ਵਿੱਚ ਨਵਾਂ ਫੰਕਸ਼ਨ procUsr() ਜੋ PostgreSQL ਨੂੰ ਸਿੱਧਾ ਲਿਖਦਾ ਹੈ, ਨਾਂਮਕਰਨ ਅਤੇ ਲੇਅਰਿੰਗ ਦੋਹਾਂ 'ਤੇ fail ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਭਾਵੇਂ feature ਕੰਮ ਕਰ ਰਿਹਾ ਹੋਵੇ। ਇੱਥੇ ਫੜਨਾ ਕਾਪੀ-ਪੇਸਟ ਰਾਹੀਂ ਗਲਤੀ ਫੈਲਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।

ਉਦਾਹਰਣ: ਹਕੀਕਤੀ ਸਮੀਖਿਆ ਜੋ ਮੁੱਦੇ ਜਲਦੀ ਠੀਕ ਕਰਦੀ ਹੈ

ਇੱਕ ਸਾਥੀ ਨੇ ਨਵਾਂ endpoint ਜੋੜਿਆ: POST /v1/invoices/{id}/send. ਇਹ ਇੱਕ ਹੈਂਡਲਰ, ਇੱਕ ਸਰਵਿਸ, ਅਤੇ storage ਨੂੰ ਛੁਹਦਾ ਹੈ।

ਪਹਿਲੇ ਪਾਸ 'ਤੇ ਤੁਸੀਂ ਰਿਪੋਰਟ ਚਾਹੁੰਦੇ ਹੋ, ਨਾਂ ਕਿ ਰੀਰਾਈਟ:

Pass 1 (report only)
You are a strict style checker. Read the patch.
Rules: naming must match our guide, handlers call services only, services call storage only, no SQL in handlers,
errors must be wrapped with context, logs must be structured and not leak PII.
Output: a numbered list of violations with file:line, rule name, and one-sentence impact. Do not propose fixes.
If a rule might be intentionally broken, ask one clarification question.

ਆਮ ਪਾਇਆ ਜਾਣ ਵਾਲੇ ਮੁੱਦੇ: SendInvoiceNow() ਵਿ. SendInvoice ਨਾਮਕਰਨ ਅਸਮਰੂਪਤਾ, ਹੈਂਡਲਰ db.QueryRow ਨੂੰ ਸਿੱਧਾ ਕਾਲ ਕਰ ਰਿਹਾ, err ਨੂੰ context ਵਿੱਣਾ ਵਾਪਸ ਕੀਤਾ ਜਾ ਰਿਹਾ, ਅਤੇ log.Printf("sending invoice %v", invoice) ਵਰਗੇ noisy ਲੌਗ ਜੋ ਪੂਰੇ objects ਡੰਪ ਕਰ ਦਿੰਦੇ ਹਨ।

ਦੂਜੇ ਪਾਸ 'ਤੇ ਘੱਟੋ-ਘੱਟ ਅਤੇ ਸੁਰੱਖਿਅਤ ਬਦਲਾਅ ਮੰਗੋ:

Pass 2 (minimal fix suggestions)
Using the violations list, propose the smallest code edits to comply.
Constraints: keep behavior the same, no refactors beyond what is needed, show suggested function names and where code should move.
For each fix, include 1-2 lines of example code.

ਜੇ ਨਿਯਮ ਟੋੜਣਾ ਮਨਜ਼ੂਰ ਕੀਤਾ ਗਿਆ ਹੈ, ਤਾਂ ਪਹਿਲਾਂ ਇਹ ਦੱਸੋ: "Exceptions are permitted only if you add a short comment explaining why, and you add a follow-up task to remove the exception."

ਫਿਕਸ ਦੇ ਬਾਅਦ, ਹੈਂਡਲਰ ਇੱਕ ਪਤਲਾ adapter ਬਣ ਜਾਂਦਾ ਹੈ, ਸਰਵਿਸ workflow ਦੀ ਮਾਲਕੀ ਲੈਂਦੀ ਹੈ, storage query ਦੀ ਮਾਲਕੀ ਲੈਂਦਾ ਹੈ, errors ਹੁੰਦੇ ਹਨ fmt.Errorf("send invoice: %w", err), ਅਤੇ ਲੌਗ ਇੱਕ ਸਾਫ਼ ਲਾਈਨ ਬਣ ਜਾਂਦੇ ਹਨ ਜਿਸ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਫੀਲਡ (invoice ID, ਨਾ ਕਿ ਪੂਰਾ invoice) ਹੁੰਦੇ ਹਨ।

ਅਗਲੇ ਕਦਮ: ਰੁਕਾਵਟਾਂ ਬਿਨਾਂ ਰੁਟੀਨ ਬਣਾਉ

ਇੱਕ ਟੀਮ-ਮੰਨਿਆ ਪ੍ਰੰਪਟ ਚੁਣੋ ਅਤੇ ਉਸਨੂੰ ਇੱਕ ਸਾਂਝਾ ਟੂਲ ਵਜੋਂ ਰੱਖੋ। ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਚੀਜ਼ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਤੁਹਾਨੂੰ ਸਮੀਖਿਆਵਾਂ ਵਿੱਚ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਤਕਲਿਫ਼ ਦੇ ਰਹੀ ਹੈ (ਨਾਮਕਰਨ ਡ੍ਰਿਫਟ, ਲੇਅਰ ਲੀਕ, ਅਨੁਸਾਰ ਨਾ ਹੋਣ ਵਾਲੀਆਂ errors, ਅਸੁਰੱਖਿਅਤ ਲੌਗਜ਼)। ਪ੍ਰਤੀਖਿਆ 'ਤੇ ਹੀ ਪ੍ਰੰਪਟ ਨੂੰ ਅਫ਼ਸਰਤਾ ਮਿਲਦੀ ਹੈ; ਉਸਨੂੰ ਸਿਰਫ਼ ਅਸਲੀ ਕੋਡ ਮੁੱਦਿਆਂ ਦੇ ਵੇਲੇ ਅਪਡੇਟ ਕਰੋ।

ਹਰ ਸਮੀਖਿਆ ਵਿੱਚ ਪ੍ਰੰਪਟ ਦੇ ਉੱਪਰ ਇੱਕ ਛੋਟਾ ਨਿਯਮ ਬਲਾਕ ਰੱਖੋ ਅਤੇ ਹਰ ਵਾਰੀ ਉਹੀ ਨਾ ਬਦਲੋ। ਜੇ ਹਰ ਕੋਈ ਹਰ ਵਾਰੀ ਨਿਯਮਾਂ ਨੂੰ ਸੋਧੇਗਾ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਮਾਪਦੰਡ ਨਹੀਂ, ਸਿਰਫ ਇੱਕ बहस ਹੋਏਗੀ।

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

ਜੇ ਤੁਸੀਂ ਚੈਟ-ਚਲਿਤ build ਫਲੋ ਵਰਤਦੇ ਹੋ ਜਿਵੇਂ Koder.ai (koder.ai), ਤਾਂ ਇਹ ਵਧੀਆ ਹੈ ਕਿ ਤੁਹਾਡੇ gate checks ਬਦਲਾਵ ਦੌਰਾਨ ਹੀ ਚਲ ਰਹੇ ਹੋਣ, ਸਿਰਫ਼ ਅਖੀਰ ਤੇ ਨਹੀਂ। Planning, snapshots, ਅਤੇ rollback ਜਿਹੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਤੁਹਾਨੂੰ ਸਟਾਈਲ ਫਿਕਸ ਛੋਟੇ ਅਤੇ ਵਾਪਸੀਯੋਗ ਰੱਖਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦੀਆਂ ਹਨ।