[Documentation] Add code comment conventions to CONTRIBUTING.md#91
Merged
[Documentation] Add code comment conventions to CONTRIBUTING.md#91
Conversation
Closes #86 ### Summary Added comprehensive "Code Comment Conventions" section to CONTRIBUTING.md to prevent future documentation drift and establish clear standards. ### What's Included **Proof Status Conventions**: - Clear rules for when to use `sorry` vs no marker - Prohibition on TODO/STUB in proven theorems - Examples of good vs bad patterns **Module Documentation**: - Standard header format with Status/Dependencies - Clear status definitions (Complete/Partial/Draft) - Example template **Future Work Comments**: - Use `FUTURE:` instead of `TODO:` - Always link to tracking issue - Avoid FIXME/HACK **Implementation Notes**: - Use `NOTE:` for non-obvious design choices - Explain why, not just what - Reference related files **Axiom Documentation**: - Inline comment requirements - Link to AXIOMS.md - Consistent format **Property Test Tags**: - Must match Lean theorem names exactly - Standard tag format **What NOT to Include**: - Stale TODOs in completed code - Difficulty estimates after completion - Verbose explanations of obvious code - Inaccurate status claims ### Context Issue #86 identified stale TODO comments and inconsistent status claims. Recent refactoring commits (see #61, #62, #63) cleaned up the actual issues: - Removed 151 lines of stale planning comments - Deleted dead reentrancy wrappers - Fixed stale YulGeneration README - Removed 162 lines of stale/duplicate content This PR completes #86 by documenting conventions to prevent recurrence. ### Impact **Before**: - ❌ No documented comment conventions - ❌ Inconsistent status markers - ❌ TODOs in completed code - ❌ No guidance for contributors **After**: - ✅ Clear comment conventions documented - ✅ Standard status definitions - ✅ Examples of good/bad patterns - ✅ Prevents future documentation drift **For Contributors**: - Clear guidelines on code comments - Prevents misleading documentation - Consistent style across codebase - Easier code review ### Files Changed - `CONTRIBUTING.md`: Added 130-line "Code Comment Conventions" section ### Related Work Recent cleanup commits that addressed the actual issues: - #61: Delete dead reentrancy wrappers, clean stale proof comments - #62: Remove 151 lines of stale planning comments from proofs - #63: Simplify Compiler/Proofs/README.md from 324 to 109 lines Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Th0rgal
pushed a commit
that referenced
this pull request
Feb 14, 2026
Closes #70 ### Summary Created detailed proof debugging handbook at docs-site/content/guides/debugging-proofs.mdx to help developers overcome common proof failures and errors. ### What's Included **10 major sections** covering practical debugging: 1. **Quick Reference** - Fast lookup table for common issues 2. **Diagnostic Tools** - #check, #print, trace, #eval 3. **Common Tactic Failures** - simp, omega, synthesize instance, motive errors 4. **Type Errors** - Type mismatch debugging and fixes 5. **Arithmetic & Overflow Proofs** - SafeAdd/SafeSub patterns 6. **Storage State Reasoning** - Function extensionality, runState composition 7. **Proof Pattern Library** - Authorization, induction, case analysis, options 8. **Tactic Ordering** - unfold → simp → omega best practices 9. **Common Error Messages** - Table of errors with causes and fixes 10. **Proof Performance** - Caching, splitting, optimization **Plus**: - Debugging workflows for unknown errors, stuck goals, type mismatches - Real examples from DumbContracts codebase - Getting help guidelines with minimal example template - Advanced debugging techniques (tracing, logging) - Quick decision tree for common issues ### Key Features **Practical Focus**: - ✅ Real code examples from DumbContracts - ✅ Before/after comparisons (❌ bad vs ✅ good) - ✅ Copy-paste ready solutions - ✅ Diagnostic commands explained **Comprehensive Coverage**: - ✅ 15+ common error patterns - ✅ 20+ proof patterns - ✅ 30+ code examples - ✅ Import, type, and proof error tables **Developer-Friendly**: - ✅ Quick reference at top for fast lookup - ✅ Decision tree for systematic debugging - ✅ Links to related resources - ✅ Encouraging tone ("You've got this!") ### Structure ``` debugging-proofs.mdx (800+ lines) ├── Quick Reference (lookup table) ├── Diagnostic Tools │ ├── Type inspection (#check, #print) │ ├── Goal inspection (trace) │ └── Evaluation (#eval, #reduce) ├── Common Tactic Failures │ ├── "simp made no progress" │ ├── "omega failed" │ ├── "failed to synthesize instance" │ └── "motive is not type correct" ├── Type Errors │ ├── Type mismatch debugging │ ├── Expected vs actual │ └── Rewriting to match types ├── Arithmetic & Overflow Proofs │ ├── SafeAdd/SafeSub patterns │ ├── Proving no overflow │ └── Bounded arithmetic ├── Storage State Reasoning │ ├── Function extensionality │ ├── Storage unchanged except │ └── runState composition ├── Proof Pattern Library │ ├── Authorization checks │ ├── Nat induction │ ├── List induction │ ├── Case analysis │ └── Option handling ├── Tactic Ordering (unfold → simp → omega) ├── Common Error Messages (3 tables) ├── Proof Performance │ ├── Caching intermediate results │ ├── Splitting into smaller lemmas │ └── Using rfl instead of simp ├── Debugging Workflows (3 workflows) ├── Real Examples (3 from codebase) ├── Getting Help (when and how) ├── Advanced Debugging │ ├── Proof term inspection │ ├── Tactic tracing │ └── Goal state logging └── Summary (quick decision tree) ``` ### Example Content Quality **Common Tactic Failure: "simp made no progress"** ```lean -- ❌ DOESN'T WORK theorem getValue_correct : ... := by simp [getStorage] -- Error: simp made no progress -- ✅ WORKS theorem getValue_correct : ... := by unfold getValue -- First unfold the definition simp [getStorage] -- Now simp can make progress ``` **Real Example: Counter increment** ```lean theorem increment_correct (state : ContractState) : let finalState := increment.runState state finalState.storage countSlot = add (state.storage countSlot) 1 := by unfold increment Contract.runState simp [getStorage, setStorage, countSlot, add] ``` ### Impact **Before this PR**: - ❌ No guide for common proof failures - ❌ Developers get stuck with cryptic errors - ❌ Slows contribution velocity - ❌ Pattern knowledge is tribal (not documented) - ❌ Frustration leads to abandonment **After this PR**: - ✅ Comprehensive debugging guide (800+ lines) - ✅ 15+ common errors with solutions - ✅ Quick lookup table for fast help - ✅ Real examples from codebase - ✅ Reduces abandonment rate - ✅ Enables self-service problem solving **For Developers**: - Fast solutions to common problems - Learn by example with before/after - Systematic debugging workflows - Know when to ask for help **For Project**: - Reduced "help needed" issues - Faster contribution velocity - Lower barrier to entry - Better developer experience ### Success Metrics (from issue #70) - ✅ Covers 15+ common error patterns (20+ included) - ✅ Comprehensive diagnostic tools section - ✅ Real examples from DumbContracts codebase - ✅ Clear workflows and decision trees - ✅ Getting help guidelines ### Files Changed - `docs-site/content/guides/debugging-proofs.mdx`: New 800+ line guide - `docs-site/content/guides/_meta.js`: Added navigation entry ### Related Work Complements recent documentation improvements: - #90: First contract tutorial (onboarding) - #89: Trust assumptions (architecture) - #91: Code comment conventions (style) - #66: First contract tutorial (prerequisite) Together, these provide comprehensive documentation for DumbContracts development. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Th0rgal
added a commit
that referenced
this pull request
Feb 14, 2026
Closes #70 ### Summary Created detailed proof debugging handbook at docs-site/content/guides/debugging-proofs.mdx to help developers overcome common proof failures and errors. ### What's Included **10 major sections** covering practical debugging: 1. **Quick Reference** - Fast lookup table for common issues 2. **Diagnostic Tools** - #check, #print, trace, #eval 3. **Common Tactic Failures** - simp, omega, synthesize instance, motive errors 4. **Type Errors** - Type mismatch debugging and fixes 5. **Arithmetic & Overflow Proofs** - SafeAdd/SafeSub patterns 6. **Storage State Reasoning** - Function extensionality, runState composition 7. **Proof Pattern Library** - Authorization, induction, case analysis, options 8. **Tactic Ordering** - unfold → simp → omega best practices 9. **Common Error Messages** - Table of errors with causes and fixes 10. **Proof Performance** - Caching, splitting, optimization **Plus**: - Debugging workflows for unknown errors, stuck goals, type mismatches - Real examples from DumbContracts codebase - Getting help guidelines with minimal example template - Advanced debugging techniques (tracing, logging) - Quick decision tree for common issues ### Key Features **Practical Focus**: - ✅ Real code examples from DumbContracts - ✅ Before/after comparisons (❌ bad vs ✅ good) - ✅ Copy-paste ready solutions - ✅ Diagnostic commands explained **Comprehensive Coverage**: - ✅ 15+ common error patterns - ✅ 20+ proof patterns - ✅ 30+ code examples - ✅ Import, type, and proof error tables **Developer-Friendly**: - ✅ Quick reference at top for fast lookup - ✅ Decision tree for systematic debugging - ✅ Links to related resources - ✅ Encouraging tone ("You've got this!") ### Structure ``` debugging-proofs.mdx (800+ lines) ├── Quick Reference (lookup table) ├── Diagnostic Tools │ ├── Type inspection (#check, #print) │ ├── Goal inspection (trace) │ └── Evaluation (#eval, #reduce) ├── Common Tactic Failures │ ├── "simp made no progress" │ ├── "omega failed" │ ├── "failed to synthesize instance" │ └── "motive is not type correct" ├── Type Errors │ ├── Type mismatch debugging │ ├── Expected vs actual │ └── Rewriting to match types ├── Arithmetic & Overflow Proofs │ ├── SafeAdd/SafeSub patterns │ ├── Proving no overflow │ └── Bounded arithmetic ├── Storage State Reasoning │ ├── Function extensionality │ ├── Storage unchanged except │ └── runState composition ├── Proof Pattern Library │ ├── Authorization checks │ ├── Nat induction │ ├── List induction │ ├── Case analysis │ └── Option handling ├── Tactic Ordering (unfold → simp → omega) ├── Common Error Messages (3 tables) ├── Proof Performance │ ├── Caching intermediate results │ ├── Splitting into smaller lemmas │ └── Using rfl instead of simp ├── Debugging Workflows (3 workflows) ├── Real Examples (3 from codebase) ├── Getting Help (when and how) ├── Advanced Debugging │ ├── Proof term inspection │ ├── Tactic tracing │ └── Goal state logging └── Summary (quick decision tree) ``` ### Example Content Quality **Common Tactic Failure: "simp made no progress"** ```lean -- ❌ DOESN'T WORK theorem getValue_correct : ... := by simp [getStorage] -- Error: simp made no progress -- ✅ WORKS theorem getValue_correct : ... := by unfold getValue -- First unfold the definition simp [getStorage] -- Now simp can make progress ``` **Real Example: Counter increment** ```lean theorem increment_correct (state : ContractState) : let finalState := increment.runState state finalState.storage countSlot = add (state.storage countSlot) 1 := by unfold increment Contract.runState simp [getStorage, setStorage, countSlot, add] ``` ### Impact **Before this PR**: - ❌ No guide for common proof failures - ❌ Developers get stuck with cryptic errors - ❌ Slows contribution velocity - ❌ Pattern knowledge is tribal (not documented) - ❌ Frustration leads to abandonment **After this PR**: - ✅ Comprehensive debugging guide (800+ lines) - ✅ 15+ common errors with solutions - ✅ Quick lookup table for fast help - ✅ Real examples from codebase - ✅ Reduces abandonment rate - ✅ Enables self-service problem solving **For Developers**: - Fast solutions to common problems - Learn by example with before/after - Systematic debugging workflows - Know when to ask for help **For Project**: - Reduced "help needed" issues - Faster contribution velocity - Lower barrier to entry - Better developer experience ### Success Metrics (from issue #70) - ✅ Covers 15+ common error patterns (20+ included) - ✅ Comprehensive diagnostic tools section - ✅ Real examples from DumbContracts codebase - ✅ Clear workflows and decision trees - ✅ Getting help guidelines ### Files Changed - `docs-site/content/guides/debugging-proofs.mdx`: New 800+ line guide - `docs-site/content/guides/_meta.js`: Added navigation entry ### Related Work Complements recent documentation improvements: - #90: First contract tutorial (onboarding) - #89: Trust assumptions (architecture) - #91: Code comment conventions (style) - #66: First contract tutorial (prerequisite) Together, these provide comprehensive documentation for DumbContracts development. Co-authored-by: Claude Sonnet 4.5 <noreply@anthropic.com>
This was referenced Feb 15, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Completes #86 by documenting code comment conventions to prevent future documentation drift.
Context
Issue #86 identified two problems:
Recent cleanup commits already fixed problem #1:
7fff141: Removed 151 lines of stale planning comments09e574f: Deleted dead reentrancy wrappers, cleaned stale proof comments1cea450: Fixed stale YulGeneration READMECurrent state:
This PR addresses problem #2: Documenting conventions to prevent future issues.
What's New
Added comprehensive "Code Comment Conventions" section (130 lines) to CONTRIBUTING.md covering:
1. Proof Status Markers
2. Module Documentation Standards
3. Future Work Comments
FUTURE:instead ofTODO:4. Implementation Notes
NOTE:for non-obvious design choices5. Axiom Documentation
6. Property Test Tags
/// Property: exact_theorem_name7. What NOT to Include
❌ Stale TODOs in completed code
❌ Difficulty estimates after completion
❌ Verbose explanations of obvious code
❌ Inaccurate status claims
Impact
Before:
After:
Why This Matters
For Maintainers:
For Contributors:
For Auditors:
Related Work
This PR complements recent documentation improvements:
Together, these establish comprehensive documentation standards for DumbContracts.
Test Plan
Manual Verification
Related Issues
🤖 Generated with Claude Code
Note
Low Risk
Documentation-only change with no impact on runtime behavior or proof/CI logic.
Overview
Adds a new "Code Comment Conventions" section to
CONTRIBUTING.mdto standardize how contributors document Lean proofs and related code.The guidelines define acceptable proof status markers (
sorryonly for incomplete proofs), module header status conventions, preferred tags for future work (FUTURE:) and implementation notes (NOTE:), requirements for documenting axioms (inline +AXIOMS.md), and a naming convention for Solidity property-test tags that match Lean theorem names.Written by Cursor Bugbot for commit 3a9bb30. This will update automatically on new commits. Configure here.