- There are unnecessary lines of code.
- They may add uneeded function calls or overhead.
- Removing the unused variables reduces noise in files and makes less code that needs to be maintained.
- These issues are nice ones for people to learn the core process. (After doing a few, and reviewing a few, find other issues in other topics by looking for other novice issues: https://drupal.org/project/issues/search/drupal?status%5B%5D=Open&versio... or other metas. See irc factoid: metas? Which links to the methods meta and properties rename meta Another option is to jump in #drupal-contribute and ask for someone to recommend an issue to work on, or attend core mentoring office hours to find issues matched to your interest and skills.)
Remove the lines of code that declare the unused variables.
Is there a way to automatically detect? No. See #12-#14.
- (done) Identify each file that has an unused variable.
- (done) Make one issue per file.
- Also, write down reproducable steps to identifying per file, each unused variable. Might require IDE.
- (done) Create the issue and list the variables in that issue.
- (done) Add the file to the table.
- (done) Link the issue in the table.
- Do a few that are active or needs work.
- Review a few. See hints for reviewers.
Be careful of an include_once. It might use the variables that an IDE says is unused, but it is actually used. There are very few places in core that do that, but be careful of it.
(Small note be careful of list(). Most people can ignore this.)
Hints for reviewers
- Look at the patch with dreditor (http://dreditor.org).
- Are there unintended changes? Ask about them.
- Was trailing whitespace accidentally included (an example at https://drupal.org/documentation/git/interdiff | Microbranching workflow: http://xjm.drupalgardens.com/blog/interdiffs-how-make-them-and-why-they-... )? If so, instead of just pointing it out in a comment, also go ahead and make a new patch and interdiff that removes the whitespace. For instructions on creating an interdiff, see
- Apply the patch, then
- If it does not apply:
- If you have time, reroll it. (reroll instructions: http://drupal.org/patch/reroll) Interdiffs usually do not make sense with rerolls, but you can add some info like saying if it was an automatic merge, if there were conflicts, and if you found the issue/commit that caused it to not apply, mention that. If you do not have time to reroll it, mark the status needs work, and add the Needs reroll tag.
- If the patch cannot be applied because it was already fixed by other patch (the line/lines to fix dissapeared), find the issue where that patch was posted and reference it. Then, you can mark it as "Closed (won't fix)" . Example:
- If it did apply, recheck (by opening the file in an IDE like phpstorm) if any new unused variables are revealed by the removal of other unused variables.
- If it does not apply:
- Look at the code near the var. If you think the unused var.. actually needed to be used, you may have spotted a flaw that needs to be fixed. (For example: and .)
- Summarize what you checked, how you checked them, and your findings (instead of just saying "looks good"). For example .
- Also see https://drupal.org/contributor-tasks/review for more info.
From #10 When making an issue, put the number of the new issue between the # and @ and it will make a great link. (the @ shows who it is assigned to, if it is assigned). Remove the create link when putting the issue number in.
Anyone can use the create link to make the issue and then edit this issue summary.
User interface changes
No ui changes.
No api changes.