Feature/417 leftout comments

[baristaGeek]

Description

Adds detecting multi-line leftover comments as a code smell

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Chore: cleanup/renaming, etc
• RFC
• Test

Notes

I tested with the commit that this file has that has a leftover comment itself (already removed) and it successfully dects the leftover comment.

However, there is an error in the logic. The code gets the correct position of the occurrence of the leftover comment (number of lines below the @@ header hunk, not the actual line number in the file). However it comments the lineNumber under the wrong header hunk (the first one). Thsi needs to be fixed for this to be upgraded from draft PR.

Acceptance

• I have read the Contributing guidelines
• I have read the Code of Conduct

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
watermelon	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 24, 2024 11:07pm

[watermelon-copilot-for-code-review]

Watermelon AI Summary

This PR introduces a new feature that enhances the code quality by adding the ability to detect multi-line leftover comments, which are considered a code smell. The series of updates in the PR progressively develop, refine, and streamline this feature, while also addressing an identified error in the logic that incorrectly matches the position of comments within the code.

GitHub PRs

• #424 - Feature/417 leftout comments - By baristaGeek 1 weeks ago

• #429 - Add new user page - By EstebanDalelR 5 days ago

• #430 - Fix marketplace link - By gvijay4321 2 days ago

watermelon is an open repo and Watermelon will serve it for free.
🍉🫶
Why not invite more people to your team?

[EstebanDalelR]

What can we extract? This is a 600 LOC file!
Code seems ok, but I think we do not want blocking commenting of files but rather choosing one?

[baristaGeek]

What can we extract? This is a 600 LOC file! Code seems ok, but I think we do not want blocking commenting of files but rather choosing one?

I totally agree there's a bunch of things to abstract. I'm worrying about making it work first, then I'll worry about abstracting the code.

[baristaGeek]

I upgraded the PR to "ready for review". Changes include:

• We now handle the multi-line comments created with "//" on each line case. In addition to the actual multi-line syntax (/* */) case. Image below.
• We need to index lineNumbers at 4 instead of 0 because the GitHub UI always adds 3 lines below the @@ header (plus they are indexed at 1 instead of 0, plus the octokit comments.position parameter is the number of lines below the @@ heaer instead of the actual line number in the file).
• I changed the name of the file and the function to detectCodeSmells since we're generalizing the capabilities of this feature.

Considerations

• Might be missing syntax from some major languages
• I agree that the file can be abstracted. I propose we agree on whether this works or not, and then the abstraction step could happen in a separate PR.

CC: @EstebanDalelR

[EstebanDalelR]

This seems very independent, can we split it as to call it in this function?
Other than that LGTM!