Optimize Telegram command registration to avoid redundant calls

[chinkan]

Summary

Refactored the Telegram command registration logic to eliminate redundant function calls and improve efficiency.

Key Changes

• Extracted supported_commands() call to a variable to avoid calling it multiple times
• Stored the command count in a separate variable for use in the log message
• Simplified the success log statement by using the pre-computed count value

Implementation Details

The original code called supported_commands() twice in the same match expression—once to pass to set_my_commands() and again to get the length for logging. This change computes both values once upfront, reducing unnecessary function calls and improving code clarity. The behavior remains identical, but the implementation is now more efficient.

https://claude.ai/code/session_01A3PgAuXiQFNJBZ4ZJyMbme

[github-actions]

Claude finished @chinkan's task in 47s —— View job

---

Code Review: PR #38

Tasks:

• Gather context and understand the PR
• Read changed files
• Analyze the diff
• Post review feedback

---

Review Summary

This is a clean, correct micro-optimization. The change is well-scoped and accurately described in the PR body.

What Changed

-    match bot.set_my_commands(supported_commands()).await {
-        Ok(_) => info!(
-            "Registered {} Telegram commands",
-            supported_commands().len()
-        ),
+    let commands = supported_commands();
+    let count = commands.len();
+    match bot.set_my_commands(commands).await {
+        Ok(_) => info!("Registered {} Telegram commands", count),

Analysis

Correctness: ✅ The refactoring is semantically equivalent. supported_commands() is a pure, deterministic function (returns a static Vec<BotCommand>), so calling it once vs. twice produces identical results. The count is computed from commands.len() before commands is moved into set_my_commands(), which is exactly right.

Efficiency: The improvement is real but modest — supported_commands() simply constructs a static vec. Still, avoiding duplicate allocation is good practice, and this follows the Rust idiom of binding values before consuming them.

Clarity: The extracted variables make the intent explicit — commands is what gets registered, count is what gets logged. This is easier to read than the original double-call.

Style: Consistent with the project's conventions (snake_case, no unnecessary comments, concise logging with tracing).

Minor Nit (Non-blocking)

The variable name count is generic. command_count would be marginally more descriptive in isolation, but given it's only used one line below its declaration, count is perfectly readable here. This is strictly a style preference and not worth blocking on.

Verdict

Approve. This is a correct, simple cleanup with no behavioral changes. CI should pass cleanly. No action required.