Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Part of meta-issue #1310084: [meta] API documentation cleanup sprint
This is for the system module, subdirectory tests, files and sub-directories starting with E through I.
Comment | File | Size | Author |
---|---|---|---|
#4 | drupal-api_docs_cleanup-1431670-3.patch | 8.53 KB | CB |
Comments
Comment #1
xjmUpdating scope for #1299424: Allow one module per directory and move system tests to core/modules/system.
Comment #2
CBAssigning to myself.
Comment #3
CBUploading a small patch merely for feedback to ensure I am going about it all the right way. I keep referring to the notes here as well as the Doxygen formatting.
I just didnt want to continue working through this if I was doing something fundamentally incorrect. :)
Thanks!
Comment #4
CBWoops, and heres my patch.
Comment #5
aspilicious CreditAttribution: aspilicious commentedtrailing whitespace
trailing whitespace
There are a TON of extra files that need to be checked in "lib/Drupal/System/Tests" they used to be part of the test folder. Maybe you can look at the E-I directories...
-16 days to next Drupal core point release.
Comment #6
Alan D. CreditAttribution: Alan D. commentedThis stuff shouldn't be in the code afaik :)
Also, many editors have options to trim trailing white space on save, it is worth looking into rather than trying to manually parse the file for these.
Comment #7
jhodgdonThanks for making a start on this! In addition to the comments by others above, I found a few things to take note of before you start on the full patch:
a)
Drupals -> Drupal's.
b)
Probably the "Menu callback" should not have been removed here (just reformatted slightly). See
http://drupal.org/node/1354#menu-callback
c)
See http://drupal.org/node/1354#forms -- and also the form submission function that comes after this does not have the right documentation header.
d)
This is a two-line description of a function. It needs to be shortened to one 80-character line:
http://drupal.org/node/1354#functions
e)
- First @param needs a description.
- Second @param and @return - descriptions need to end in ".". See
http://drupal.org/node/1354#functions
And this needs to be done elsewhere in the patch too.
f)
Override -> Overrides
Comment #8
CBThanks for the feedback guys, much appreciated.
I'm curious though, especially regarding jhodgdon's comment about @param $file needing a description, a lot of these test functions and methods have dummy parameters, and this is one. Its not used for anything at all - is it ok to just leave it, or should I write something like 'dummy parameter' etc? Or do I need to trail back through, find all instances of that function call and work out what $file can be (even though it is unused?)
Whitespace was to do after with the perl command posted in the parent issue, but I have since enabled auto trim of whitespace in my editor, so that wont be an issue again.
Jeez, its hard sometimes to reduce function descriptions to a single line! :) But, I'll go through and update them more thoroughly.
Thanks again.
Comment #9
jhodgdonRegarding dummy parameters -- I'm assuming this would be because this function is implementing some interface or overriding some base class function? In which case you can entirely omit the method documentation by using the syntax shown here in the DatabaseStatementBase::execute() or fetchAssoc() method:
http://drupal.org/node/1354#classes
Otherwise, yes, the parameter needs a description, which could say something like "Not used in this function."
Comment #10
CBThis hasn't been forgotten guys, just been insanely busy. Will get some more done this week.
Comment #11
CBI wont be able to continue on this, I've been busy with the accessibility issues for D8. I'll remove myself from the list.
Comment #12
jhodgdonComment #12.0
jhodgdonUpdated issue summary.
Comment #13
jhodgdonThese issues are a lot of work with very little tangible payoff, so I'm closing the rest of them as "won't fix". Your efforts on working on this issue were appreciated... it was just my fault for starting a task that was very difficult to get right.
Let's instead put our effort into fixing and reviewing documentation that is really unclear and/or wrong, and I hope that the people who worked on these issues are not afraid to jump into a more reasonable issue!