objectionary / objectionary/lints
`DefectMissing.apply` checks for a null map after dereferencing it
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 14
- Forks
- 39
- Avg merge
- 22h 54m
- Merged PRs (30d)
- 90
Description
DefectMissing.apply in src/main/java/org/eolang/lints/DefectMissing.java:56 checks this.defects != null and falls back to an empty SetOf at line 59. But line 47 of the same method already calls this.defects.get(name), so a null map would throw there first and the else branch can never run.
The map never is null anyway: its only production source is LtUnlintNonExistingDefect.existing() at LtUnlintNonExistingDefect.java:117, which returns the result of Collectors.groupingBy, and every case in DefectMissingTest passes a MapOf.
Replacing the conditional with this.defects.keySet() removes the unreachable branch without changing behavior.
@yegor256
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Open src/main/java/org/eolang/lints/DefectMissing.java and inspect apply around lines 47-59, then review DefectMissingTest and LtUnlintNonExistingDefect.existing() around line 117. Confirm the map is always produced by groupingBy and test coverage uses MapOf. Done means the unreachable null fallback is removed without changing behavior and DefectMissingTest passes.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- tooling
- Issue type
- Refactor
- Difficulty
- 1/5
- Estimated time
- Under an hour
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 92/100