home / skills / yelmuratoff / agent_sync / comments

comments skill

/.ai/src/skills/comments

This skill helps you write meaningful, concise code comments by emphasizing intent, readability, and correct scope across APIs and internal logic.

npx playbooks add skill yelmuratoff/agent_sync --skill comments

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
2.0 KB
---
name: effective-commenting
description: Best practices for writing meaningful and clean code comments.
---

# Effective Commenting

## When to use

- Explaining complex business logic or algorithms.
- Documenting public APIs (Data layer → Domain layer).
- Clarifying non-obvious workarounds, hacks, or side effects.
- Warning about potential pitfalls or future refactoring needs.

## Steps

1.  **Assess Necessity**: Review if the code can explain itself; if so, proceed without comments. Only comment if the code cannot convey the full context.
2.  **Clarify via Naming**: Rename methods and variables to describe their purpose explicitly.
3.  **Document Intent**: Write comments that explain the "why" (business context, constraints) behind the implementation.
4.  **Finalize Output**: Ensure only the active, necessary code remains, removing any temporary artifacts or disabled blocks.
5.  **Distinguish Scope**: Use `///` for public API documentation and `//` for internal implementation notes.

## Code

### Bad Examples (Avoid)

```dart
// Step 1: Initialize list of users
// This variable stores user data
final users = <User>[];

// Loop through users to save them
for (var u in users) {
  // validation logic
  if (u.isValid) {
    save(u); // AI thought: saving to database here
  }
}

// Code below is deprecated
// void oldFunction() {
//   print('old logic');
// }
```

### Good Examples

```dart
/// Syncs user data with remote backend.
///
/// Throws [SyncException] if network fails or data is invalid.
Future<void> syncUser() async {
  // Use a LinkedHashMap to preserve insertion order for UI rendering,
  // as the backend returns unordered JSON but order matters here.
  final cache = <String, User>{};

  try {
    await _api.fetch();
  } catch (e) {
    // Suppress 404 errors as they indicate "no data yet" for this specific
    // endpoint, which is a valid state for new users.
    if (e is NetworkException && e.statusCode == 404) return;
    rethrow;
  }
}

/// Example of self-explanatory code (No comments needed)
bool get isAdult => age >= 18;

```

Overview

This skill teaches best practices for writing meaningful, minimal, and maintainable code comments. It focuses on when comments add value, how to document intent, and how to choose the right comment style for public APIs versus internal notes. The aim is clearer code, fewer stale comments, and improved team communication.

How this skill works

It inspects code context and guides developers to prefer self-explanatory names and minimal comments that explain the "why" rather than the "what." It recommends assessing necessity, renaming identifiers to clarify intent, and using different comment styles for public documentation versus internal notes. It also includes examples of poor and strong commenting patterns to illustrate recommended practices.

When to use it

  • When complex business logic or algorithms cannot be made self-explanatory
  • When documenting public APIs or library surfaces for consumers
  • To clarify non-obvious workarounds, hacks, or side effects
  • To warn about potential pitfalls or future refactoring needs
  • When behavior depends on external constraints or domain knowledge

Best practices

  • Assess necessity first—prefer code that explains itself through clear names and structure
  • Document intent and business context; explain why a decision was made, not what the code does
  • Use /// (or equivalent doc comments) for public API documentation and // for internal notes
  • Avoid redundant comments that restate obvious code; remove deprecated or temporary blocks
  • Keep comments concise, current, and actionable—update or delete them when code changes

Example use cases

  • Documenting why a specific data structure is chosen for UI ordering
  • Explaining suppression of a particular exception as an accepted state
  • Marking a temporary workaround with a TODO and clear conditions for removal
  • Adding API doc comments that list exceptions, side effects, and expected behavior
  • Replacing verbose inline explanations by improving variable and method names

FAQ

When is a comment justified?

When the code cannot convey the rationale, trade-offs, or external constraints; prefer comments for intent and domain context rather than implementation details.

Should I comment every public method?

Public methods should have concise documentation for consumers (exceptions, side effects, contracts). If behavior is obvious from names and types, keep docs minimal but clear.