Awesome Reviewers

When adding warnings/logs, treat them as part of the user experience: only emit warnings when they are actionable, accurate, and non-noisy—especially when runtime feature detection changes behavior.

Guidelines:

• Scope warnings to the exact scenario that needs it (don’t warn unconditionally). If a warning only applies under specific preconditions, move it closer to the triggering branch.
• If you use capability/shape guards (e.g., hasattr on an SDK operation group) that can silently change behavior, log a warning when the guarded path is unavailable so users can understand why an expected lookup/action didn’t happen.
• Avoid misleading guidance when settings override each other or when the message may not apply; consider existing configuration before warning.
• Ensure warning content is correct and specific (e.g., OS/plan type labels must match Hyper-V vs Windows).
• Prefer emitting large/raw content through the intended CLI rendering path; avoid logging raw payloads redundantly if it will also be displayed.
• For CLI commands, keep informational output off stdout when it could interfere with scripting—write it to stderr.

Example pattern (behavior-guard warning):

if not hasattr(cert_orders_client, 'app_service_certificate_orders'):
    logger.warning(
        "Certificate orders operation group is unavailable in the current SDK. "
        "Falling back to treating certificate name as a raw Key Vault secret name."
    )
    # fallback behavior...
else:
    # normal behavior...

Example pattern (emit accurate stderr for informational text):

import sys
print("Starting interactive shell session...", file=sys.stderr)

This site is open source. Improve this page.