feat: update move number handling to use int type and improve parsing… #25
Conversation
WalkthroughThis pull request updates how move numbers are handled within the codebase. The Changes
Sequence Diagram(s)sequenceDiagram
participant Parser as PGN Parser
participant Move as Move Object
Parser ->> Parser: Parse move text to extract moveNumber (uint64)
alt moveNumber > 0
Parser ->> Move: Assign move.number (converted to int)
else
Parser ->> Parser: Skip move number assignment
end
Parser ->> Caller: Return parsed move
Possibly related PRs
Poem
Tip 🌐 Web search-backed reviews and chat
✨ Finishing Touches
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #25 +/- ##
==========================================
+ Coverage 74.43% 74.48% +0.05%
==========================================
Files 27 27
Lines 5241 5245 +4
==========================================
+ Hits 3901 3907 +6
+ Misses 1204 1203 -1
+ Partials 136 135 -1 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Actionable comments posted: 1
🔭 Outside diff range comments (1)
move.go (1)
32-32: Consider keeping uint consistency.The
numberfield is defined asuintbut theNumber()method returnsint. This type inconsistency could lead to potential issues:
- Data loss for large move numbers when converting from uint to int.
- Unnecessary type conversion overhead.
- Semantic confusion as move numbers are always positive.
Consider one of these approaches:
- Keep both as
uint(preferred):-func (m *Move) Number() int { - return int(m.number) +func (m *Move) Number() uint { + return m.number
- Or change both to
int:- number uint + number int -func (m *Move) Number() int { - return int(m.number) +func (m *Move) Number() int { + return m.numberAlso applies to: 116-118
🧹 Nitpick comments (1)
pgn_test.go (1)
206-213: LGTM! Good test coverage for move numbers.The test correctly verifies that move numbers match their position in the sequence.
Consider adding edge cases:
- Test with very large move numbers (e.g., 1000+) to verify no overflow.
- Test with variations to ensure correct numbering in sidelines.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
move.go(1 hunks)pgn.go(2 hunks)pgn_test.go(2 hunks)
🔇 Additional comments (1)
pgn_test.go (1)
259-277: LGTM! Good test coverage in TestBigPgn.The test appropriately:
- Verifies move numbers in a large dataset.
- Skips games with variant "From Position".
- Provides helpful debug output on failure.
| } | ||
|
|
||
| func (p *Parser) parseMoveText() error { | ||
| var moveNumber uint64 |
There was a problem hiding this comment.
Fix potential data loss and redundant check.
- Using
uint64formoveNumberbutuintforMove.numbercould lead to data loss for large numbers. - The
> 0check is redundant for unsigned types.
Apply this diff:
- var moveNumber uint64
+ var moveNumber uint
- if moveNumber > 0 {
- move.number = uint(moveNumber)
- }
+ move.number = moveNumberAlso applies to: 192-194
… logic
Summary by CodeRabbit
Refactor
Tests