docs: keep inline comments brief, trim the Logger ones

Adds a `.claude/CLAUDE.md` section: default to no inline comment, and keep
the ones that survive to a line or two. Rationale, rejected alternatives and
change narration go in the PR description, which is where a `git blame` leads
anyway and which does not go stale as the surrounding code moves.

Applies it to the log_debug/NDEBUG comments this PR added.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NmbKZsRagnasxGVXtnCLoF

Author: claude

.claude/CLAUDE.md

@@ -4,6 +4,33 @@ Guidance specific to Claude Code sessions that open pull requests against this
 repository (including automated/scheduled sessions). See the root `CLAUDE.md`
 and `AGENTS.md` for everything else.
 
+## Keep inline comments very brief — put the color in the PR description
+
+Default to **no comment at all**. Write one only when it carries knowledge a
+reader cannot get from the code itself plus a `git blame` pointing at the PR
+that introduced it. When you do write one, keep it to a line or two.
+
+Rationale, rejected alternatives, benchmark numbers, "we tried X and it
+didn't work", links to upstream issues, and anything that reads as a history
+lesson belong in the **PR description** (and, where user-facing, the
+changeset) — not in the source. Those places are where a reader who has
+already found the line via `git blame` will end up anyway, and they don't
+have to be maintained as the code around them changes.
+
+Concretely, do not write comments that:
+
+- restate what the next line already says;
+- explain why an alternative implementation was _not_ chosen;
+- narrate the change (`// now compiled out in release builds`) — that is a
+  commit message, and it goes stale the moment the code moves;
+- document a well-known toolchain fact (e.g. what `NDEBUG` means) that a
+  reader can look up.
+
+Comments that _do_ earn their place: a non-obvious constraint the compiler or
+platform imposes, a workaround with the exact condition that makes it
+removable (see the upstream-fix guidance in `AGENTS.md`), or a subtle
+invariant a future edit could silently break.
+
 ## Attach CI labels when you open a PR
 
 `.github/workflows/check.yml`'s `pull_request` trigger only fires on

packages/host/cpp/Logger.cpp

@@ -63,9 +63,6 @@ void log_message_internal(LogLevel level, const char *format, va_list args) {
 
 namespace callstack::react_native_node_api {
 
-// See the comment on the declaration in Logger.hpp: in release (NDEBUG)
-// builds log_debug is an inline no-op defined in the header, so this
-// definition only exists (and only needs to exist) outside of NDEBUG.
 #ifndef NDEBUG
 void log_debug(const char *format, ...) {
   va_list args;

packages/host/cpp/Logger.hpp

@@ -4,31 +4,14 @@
 
 namespace callstack::react_native_node_api {
 
-// log_debug is verbose, per-addon diagnostic chatter (library found/loaded,
-// symbol resolution, ...) emitted on every addon load. It is compiled out
-// entirely in release builds: NDEBUG is what CMake's Release/MinSizeRel/
-// RelWithDebInfo configurations define (and what Xcode's Release
-// configuration defines by default), mirroring the dev/release split React
-// Native itself draws with `__DEV__`. Making the release build's log_debug an
-// inline no-op - rather than compiling Logger.cpp's definition and letting it
-// run - drops both the log line and its argument-formatting cost from the
-// startup path, and lets the optimizer elide side-effect-free call sites
-// entirely.
-//
-// This is compile-time only: there is currently no runtime override to
-// re-enable it in a shipped release build to chase a release-only bug (there
-// is no existing mechanism in this codebase - env var, JS-settable flag, etc.
-// - to hook one into without adding new plumbing of its own). Build a
-// Debug or RelWithDebInfo artifact to get this output back; revisit with a
-// runtime toggle if that turns out to be too painful in practice.
+// Inline (rather than a no-op in Logger.cpp) to let the optimizer drop the
+// argument evaluation at every call site.
 #ifdef NDEBUG
 inline void log_debug(const char *, ...) {}
 #else
 void log_debug(const char *format, ...);
 #endif
 
-// log_warning/log_error keep firing unconditionally in every build type,
-// including release (NDEBUG) ones.
 void log_warning(const char *format, ...);
 void log_error(const char *format, ...);