Android Studio generate JavaDoc for AIDL - java

Given that AIDL contain interface definitions, it is important to incorporate them into our javadoc.
However, Android Studio completely refuses to see Javadoc comments added either to aidl files or those to be found in the java files generated from them.
This is what I have in my .aidl test file:
/**
* Displays a Toast Message containing the specified String.
* To be used for testing purpose only.
*
* #param message the Message to be displayed
* #return whether or not the Message could be shown
*/
boolean testMessage(String message);
and this is in the generated .java file:
/**
* Displays a Toast Message containing the specified String.
* To be used for testing purpose only.
*
* #param message the Message to be displayed
* #return whether or not the Message could be shown
*/
#Override public boolean testMessage(java.lang.String message) throws android.os.RemoteException
{
return false;
}
I can generate JavaDoc for the implementation file (e.g. AidlImpl.java in case of IAidl.aidl), but that would yield wrong references in the JavaDoc as the end user would have to use IAidl and not AidlImpl.
How's that supposed to work?
#edit: I ended up writing a wrapper class for the library which can contain javadoc comments the usual way.
Not exactly the most elegant solution, but reasonably straightforward.
Thanks for your attention!

Related

How to resolve At-clause should have a non-empty description? - Checkstyle - Java

I am using the google java style in the checkstyle plugin for eclipse luna. Seeing this error all over my java doc but cannot seem to find how to resolve it. It's minor but its bugging me.
my javadoc:
/**
* This is a description of something
*
* #throws Exception
*/
Error is on the #throws line, Error:
At-clause should have a non-empty description
Typically, you should write
* #throws Exception when this exceptional condition happens
e.g.
* #throws IllegalArgumentException when num is negative
...and generally explaining why that exception would occur.
This is the generic message shown for every parameters in doc starting with '#'.
So for every param you need to add some description.
For example:
/**
* Searches for top cars
* #param carSearchRequest represents CarSearchRequest body
* #param userId represents userid
* #return CarsResponse
* #throws Exception when userid is null
*/
To deal with this fast so my build doesn't fail from checkstyle, I made an Eclipse code template to use in the context "Javadoc":
${word_selection}
* When ${word_selection} occurs.
Select the name of the exception, hit Ctrl+Space, choose "throws" (the name I gave the template), and you have a Checkstyle-legal comment:
* #throws IOException
* When IOException occurs.
It's a dumb comment, but it's a dumb requirement too.

Eclipse Java Doc

I want to automatically generate a template in front of a method like this:
/**
*
* #param tabName
* #return
*/
Web searches have suggested SHIFT+ALT+J or /**. Indeed that has been working for many months. Suddenly today when I do a /** it generates only
/**
*
oddly enough, more towards the top of the class it works correctly. Or at least before most classes.
Here is my method def:
public String clickIt(Object search, Boolean exact, Object link)
but it does not work on other methods either. Any tips on figuring out the problem?
You can check the template used by Eclipse in the following menu item :
Window > Preferences then Java > Code Style > Code Templates
You can edit the Comments > Methods
The default value is :
/**
* ${tags}
*/

What protocols are allowed in hrefs in Swing's HTMLEditorKit class?

I use an application (AppWorx! Someone please create this tag!) that allows documentation to be entered about scheduled jobs as html.
I've been trying to create on-call documentation that would have a link something like this:
1 (806) xxx - xxxx
The page is displayed inside the Java app itself, and any link to http:// is opened in the user's browser window. But a tel link like above causes a big error window to pop up that shows the following error:
java.net.MalformedURLException: For input string: "+1806xxxxxxx"
at java.net.URL.<init>(Unknown Source)
at java.net.URL.<init>(Unknown Source)
at java.net.URL.<init>(Unknown Source)
at com.appworx.client.screen.modmgr.M$2.hyperlinkUpdate(NotesPanel.java:191)
at javax.swing.JEditorPane.fireHyperlinkUpdate(Unknown Source)
at javax.swing.text.html.HTMLEditorKit$LinkController.activateLink(Unknown Source)
at javax.swing.text.html.HTMLEditorKit$LinkController.mouseClicked(Unknown Source)
at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source)
Other protocols fail as well (except http). If I have a mailto: link, instead of getting the error as above, it takes me to the domain portion of the email address.
I believe that whatever version of this class that the app was compiled with is several (and maybe many) years old.
Can anyone tell me what the limitations of this class are, or if workarounds exist?
The documentation for Appworx suggests that even http links will not work unless the app is invoked from the jnlp (is this a sandbox thing somehow?). Though on that note, no one here starts the application any other way.
Can anyone tell me what the limitations of this class are?
To give you an idea of how outdated the EditorKit classes are, as of Java 7 HTMLEditorKit "supports HTML version 3.2 (with some extensions), and is migrating toward version 4.0". No surprise then that the URL class (responsible for the MalformedURLException in the trace you posted) supports just the basic protocols, some of which you mentioned above:
Http
Https
Ftp
File
Jar
Can anyone tell me if workarounds exist?
Well, you can get your hands dirty with the code (if you have access to it), use a custom protocol handler and register it. Luckily for you there is one already for the tel protocol courtesy of the J2ME Polish project:
package de.enough.polish.browser.protocols;
import java.io.IOException;
import javax.microedition.io.StreamConnection;
import javax.microedition.midlet.MIDlet;
import de.enough.polish.browser.ProtocolHandler;
/**
* Protocol handler to handle the <code>tel:</code> protocol. This class calls the given phonenumber on MIDP 2.0 phones.
* Example: <a href="tel:+441231234567#22">Call Me</a>
* Note that this handler requires MIDP 2.0 or higher.
* The tel protocol handler allows you to separate the phone number and the dialtone (dtmf) that should be send after
* establishing the phone call using the '#' sign.
*
* This protocol could actually be realized using the ExternalProtocolHandler as well, however in this
* way we can deal post dial tones (DTMF) in a better way - in the HTML code they just need to be
* separated from the phonenumber using a '#'.
*/
public class TelProtocolHandler
extends ProtocolHandler
{
private MIDlet midlet;
/**
* Creates an TellProtocolHandler object using the default "tel" protocol name.
*
* #param midlet the midlet object of the application
*/
public TelProtocolHandler(MIDlet midlet)
{
this( "tel", midlet );
}
/**
* Creates an TelProtocolHandler object using the specified protocol name.
*
* #param protocolName the name of the protocol to handle
* #param midlet the midlet object of the application
*/
public TelProtocolHandler(String protocolName, MIDlet midlet)
{
super( protocolName );
this.midlet = midlet;
}
/* (non-Javadoc)
* #see de.enough.polish.browser.ProtocolHandler#getConnection(java.lang.String)
*/
public StreamConnection getConnection(String url) throws IOException
{
this.midlet.platformRequest( "tel:" + extractMsisdn(url));
return null;
}
/**
* Strips the MSISDN part off an url.
* In contrast to other protocol handlers, the external protocol handler only uses a single colon to
* separate the external protocol from the folllowing protocol, e.g. external:http://www.j2mepolish.org
*
* #param url the url to remove the protocol from
*
* #return the host and part part of the given url
*/
protected String extractMsisdn(String url)
{
String msisdn = url.substring(this.protocolName.length() + 1);
String separator = null;
//#if polish.dtmf.separator:defined
//#= separator = "${polish.dtmf.separator}";
//# if (!separator.equals("#")) {
//# int pos = msisdn.indexOf('#');
//# if (pos != -1) {
//# msisdn = msisdn.substring(0, pos) + separator + msisdn.substring(pos + 1);
//# }
//# }
//#endif
return msisdn;
}
}
Hope that helps!

Detect mobile devices from user agent string [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
I am looking for a way to analyze user agent strings to determine whether they were generated by mobile devices. This needs to be java-based and usable in large batch log file analysis on hadoop for generating statistics (i.e., a web service wouldn't be appropriate).
I have seen WURFL, but given that I just need a binary mobile/not mobile response, the license fee seems prohibitive.
So far I have been using UADetector, which is almost exactly what I need. However, I have encountered some limitations with it. In my testing, I have found many user agent strings that provide enough information to determine that the user agent is from a mobile device, but are reported as UNKNOWN by UADetector.
For example, poorly-standardized Android apps can send the UA string "Android". This is enough to know that it came from a mobile device, but UADetector reports this UserAgentType as UNKNOWN rather than MOBILE_BROWSER.
Apache Mobile Filter's Lite Device Detection does the right thing, but I need something I can use from Java.
Can anyone recommend a better solution?
I'm the founder and maintainer of the MobileESP project, a free open source cross-platform library for detecting mobile devices. It's still very much alive! :-)
www.mobileesp.org
MobileESP only gives binary "is mobile" responses. You can detect by platform like iOS, Android or Windows Phone, or by device category, like "iPhone Tier" smartphones vs. tablet. Be sure to take a quick review of the API page.
As you may know, useragent strings vary widely. If the browser shipped on the device, the manufacturer may customize it. For example, HTC often customizes the native Android browser's useragent string.
Google provides recommendations on how the OEM should customize the useragent. If the device should be considered a phone, then Google recommends including the word "mobile" element in the string. But if the device should be considered a tablet, then the string should not contain "mobile." Adherence to this recommendation varies widely, of course.
Third party browsers like Opera or Maxthon can put whatever they want to in the useragent string -- and do! Certain "new" browsers which shall remain nameless have been doing very poor jobs of putting the correct information in their useragent strings for each platform (e.g., Android vs. iOS versions). There's not much you can do unless you get a lot of traffic from these browsers and wish to invest in tracking their exact useragent values per platform and software rev.
Anyway, MobileESP was created with the vision of doing the detection on a page-by-page basis when the page is served. I purposefully wrote the code to be very easy to read and customize, too.
To do the batch processing, you might do something like this:
1.) In the constructor, comment out the initDeviceScan() method. You won't need this for bulk processing.
2.) Pass the UserAgent and an empty string in to the constructor (UAgentInfo()).
3.) Then run whatever detect methods you're interested in. Be thoughtful about the order in which you do them to save time, based on a scan of your users.
For example, if most of your users are on iPhone and that's one of the detection criteria you're interested in, then run that check first. If this example, you certainly wouldn't run the BlackBerry method first!
My contact info is in the source code and on the web site. Send me a note if you have any questions or run into any bugs. Definitely look around the MobileESP.org web site for some tips.
Best wishes on your project, Aniket!
Anthony
Another thread suggests using the following library:
https://github.com/ahand/mobileesp/blob/master/Java/UAgentInfo.java
which seems OK.
How to read the Apache Mobile Filter value in JSP (for Tomcat)?
Before in the httpd.conf file where you have to configure mod_jk you muse add this:
JkEnvVar AMF_IS_MOBILE undefined
The Java code is:
request.getAttribute("AMF_IS_MOBILE")
from: http://wiki.apachemobilefilter.org
51Degrees has a free open source Java API that allows you to run offline processing. You can access it from the GitHub Repository here. https://github.com/51Degrees/Java-Device-Detection.
As part of the API there is an offline processing example (code also shown below) this takes a CSV file of User-Agents and returns the required properties into an Output file. The following example just uses 3 of the properties within the data set, for a full list you can look at the dictionary here https://51degrees.com/resources/property-dictionary
// output file in current working directory
public String outputFilePath = "batch-processing-example-results.csv";
// pattern detection matching provider
private final Provider provider;
/**
* Initialises the device detection Provider with the included Lite data
* file. For more data see:
* <a href="https://51degrees.com/compare-data-options">compare data options
* </a>
*
* #throws IOException if there was a problem reading from the data file.
*/
public OfflineProcessingExample() throws IOException {
provider = new Provider(StreamFactory.create(
Shared.getLitePatternV32(), false));
}
/**
* Reads a CSV file containing User-Agents and adds the IsMobile,
* PlatformName and PlatformVersion information for the first 20 lines.
* For a full list of properties and the files they are available in please
* see: <a href="https://51degrees.com/resources/property-dictionary">
* Property Dictionary</a>
*
* #param inputFileName the CSV file to read from.
* #param outputFilename where to save the file with extra entries.
* #throws IOException if there was a problem reading from the data file.
*/
public void processCsv(String inputFileName, String outputFilename)
throws IOException {
BufferedReader bufferedReader =
new BufferedReader(new FileReader(inputFileName));
try {
FileWriter fileWriter = new FileWriter(outputFilename);
try {
// it's more efficient over the long haul to create a match
// once and reuse it in multiple matches
Match match = provider.createMatch();
// there are 20k lines in supplied file, we'll just do a couple
// of them!
for (int i = 0; i < 20; i++) {
// read next line
String userAgentString = bufferedReader.readLine();
// ask the provider to match the UA using match we created
provider.match(userAgentString, match);
// get some property values from the match
Values isMobile = match.getValues("IsMobile");
Values platformName = match.getValues("PlatformName");
Values platformVersion = match.getValues("PlatformVersion");
// write result to file
fileWriter.append("\"")
.append(userAgentString)
.append("\", ")
.append(getValueForDisplay(isMobile))
.append(", ")
.append(getValueForDisplay(platformName))
.append(", ")
.append(getValueForDisplay(platformVersion))
.append('\n')
.flush();
}
} finally {
fileWriter.close();
}
} finally {
bufferedReader.close();
}
}
/**
* Match values may be null. A helper method to get something displayable
* #param values a Values to render
* #return a non-null String
*/
protected String getValueForDisplay(Values values) {
return values == null ? "N/A": values.toString();
}
/**
* Closes the {#link fiftyone.mobile.detection.Dataset} by releasing data
* file readers and freeing the data file from locks. This method should
* only be used when the {#code Dataset} is no longer required, i.e. when
* device detection functionality is no longer required, or the data file
* needs to be freed.
*
* #throws IOException if there was a problem accessing the data file.
*/
#Override
public void close() throws IOException {
provider.dataSet.close();
}
/**
* Instantiates this class and starts
* {#link #processCsv(java.lang.String, java.lang.String)} with default
* parameters.
*
* #param args command line arguments.
* #throws IOException if there was a problem accessing the data file.
*/
public static void main(String[] args) throws IOException {
System.out.println("Starting Offline Processing Example");
OfflineProcessingExample offlineProcessingExample =
new OfflineProcessingExample();
try {
offlineProcessingExample.processCsv(Shared.getGoodUserAgentsFile(),
offlineProcessingExample.outputFilePath);
System.out.println("Output written to " +
offlineProcessingExample.outputFilePath);
} finally {
offlineProcessingExample.close();
}
}
Hope this helps.
Disclosure: I work at 51Degrees.
To detect iPhone, Android and other mobile devices in Java user-agent can be used. If you are using Spring you can customize the below code as per your need.
#Override
public ModelAndView redirectToAppstore(HttpServletRequest request) {
String userAgent = request.getHeader("user-agent").toLowerCase();
String iphoneStoreUrl = "IPONE_STORE_URL";
String androidStoreUrl = "ANDROID_STORE_URL";
if (userAgent.contains("iphone"))
return new ModelAndView("redirect:" + iphoneStoreUrl);
else if (userAgent.contains("android"))
return new ModelAndView("redirect:" + androidStoreUrl);
return new ModelAndView("redirect:/");
}

A tool to add and complete PHP source code documentation [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I have several finished, older PHP projects with a lot of includes that I would like to document in javadoc/phpDocumentor style.
While working through each file manually and being forced to do a code review alongside the documenting would be the best thing, I am, simply out of time constraints, interested in tools to help me automate the task as much as possible.
The tool I am thinking about would ideally have the following features:
Parse a PHP project tree and tell me where there are undocumented files, classes, and functions/methods (i.e. elements missing the appropriate docblock comment)
Provide a method to half-way easily add the missing docblocks by creating the empty structures and, ideally, opening the file in an editor (internal or external I don't care) so I can put in the description.
Optional:
Automatic recognition of parameter types, return values and such. But that's not really required.
The language in question is PHP, though I could imagine that a C/Java tool might be able to handle PHP files after some tweaking.
Thanks for your great input!
I think PHP_Codesniffer can indicate when there is no docblock -- see the examples of reports on this page (quoting one of those) :
--------------------------------------------------------------------------------
FOUND 5 ERROR(S) AND 1 WARNING(S) AFFECTING 5 LINE(S)
--------------------------------------------------------------------------------
2 | ERROR | Missing file doc comment
20 | ERROR | PHP keywords must be lowercase; expected "false" but found
| | "FALSE"
47 | ERROR | Line not indented correctly; expected 4 spaces but found 1
47 | WARNING | Equals sign not aligned with surrounding assignments
51 | ERROR | Missing function doc comment
88 | ERROR | Line not indented correctly; expected 9 spaces but found 6
--------------------------------------------------------------------------------
I suppose you could use PHP_Codesniffer to at least get a list of all files/classes/methods that don't have a documentation; from what I remember, it can generate XML as output, which would be easier to parse using some automated tool -- that could be the first step of some docblock-generator ;-)
Also, if you are using phpDocumentor to generate the documentation, can this one not report errors for missing blocks ?
After a couple of tests, it can -- for instance, running it on a class-file with not much documentation, with the --undocumentedelements option, such as this :
phpdoc --filename MyClass.php --target doc --undocumentedelements
Gives this in the middle of the output :
Reading file /home/squale/developpement/tests/temp/test-phpdoc/MyClass.php -- Parsing file
WARNING in MyClass.php on line 2: Class "MyClass" has no Class-level DocBlock.
WARNING in MyClass.php on line 2: no #package tag was used in a DocBlock for class MyClass
WARNING in MyClass.php on line 5: Method "__construct" has no method-level DocBlock.
WARNING in MyClass.php on line 16: File "/home/squale/developpement/tests/temp/test-phpdoc/MyClass.php" has no page-level DocBlock, use #package in the first DocBlock to create one
done
But, here, too, even if it's useful as a reporting tool, it's not that helpful when it comes to generating the missing docblocks...
Now, I don't know of any tool that will pre-generate the missing docblocks for you : I generally use PHP_Codesniffer and/or phpDocumentor in my continuous integration mecanism, it reports missing docblocks, and, then, each developper adds what is missing, from his IDE...
... Which works pretty fine : there is generally not more than a couple of missing docblocks every day, so the task can be done by hand (and Eclipse PDT provides a feature to pre-generate the docblock for a method, when you are editing a specific file/method).
Appart from that, I don't really know any fully-automated tool to generate docblocks... But I'm pretty sure we could manage to create an interesting tool, using either :
The Reflection API
token_get_all to parse the source of a PHP file.
After a bit more searching, though, I found this blog-post (it's in french -- maybe some people here will be able to understand) : Ajout automatique de Tags phpDoc à l'aide de PHP_Beautifier.
Possible translation of the title : "Automatically adding phpDoc tags, using PHP_Beautifier"
The idea is actually not bad :
The PHP_Beautifier tool is pretty nice and powerful, when it comes to formating some PHP code that's not well formated
I've used it many times for code that I couldn't even read ^^
And it can be extended, using what it calls "filters".
see PHP_Beautifier_Filter for a list of provided filters
The idea that's used in the blog-post I linked to is to :
create a new PHP_Beautifier filter, that will detect the following tokens :
T_CLASS
T_FUNCTION
T_INTERFACE
And add a "draft" doc-block just before them, if there is not already one
To run the tool on some MyClass.php file, I've had to first install PHP_Beautifier :
pear install --alldeps Php_Beautifier-beta
Then, download the filter to the directory I was working in (could have put it in the default directory, of course) :
wget http://fxnion.free.fr/downloads/phpDoc.filter.phpcs
cp phpDoc.filter.phpcs phpDoc.filter.php
And, after that, I created a new beautifier-1.php script (Based on what's proposed in the blog-post I linked to, once again), which will :
Load the content of my MyClass.php file
Instanciate PHP_Beautifier
Add some filters to beautify the code
Add the phpDoc filter we just downloaded
Beautify the source of our file, and echo it to the standard output.
The code of the beautifier-1.php script will like this :
(Once again, the biggest part is a copy-paste from the blog-post ; I only translated the comments, and changed a couple of small things)
require_once 'PHP/Beautifier.php';
// Load the content of my source-file, with missing docblocks
$sourcecode = file_get_contents('MyClass.php');
$oToken = new PHP_Beautifier();
// The phpDoc.filter.php file is not in the default directory,
// but in the "current" one => we need to add it to the list of
// directories that PHP_Beautifier will search in for filters
$oToken->addFilterDirectory(dirname(__FILE__));
// Adding some nice filters, to format the code
$oToken->addFilter('ArrayNested');
$oToken->addFilter('Lowercase');
$oToken->addFilter('IndentStyles', array('style'=>'k&r'));
// Adding the phpDoc filter, asking it to add a license
// at the beginning of the file
$oToken->addFilter('phpDoc', array('license'=>'php'));
// The code is in $sourceCode
// We could also have used the setInputFile method,
// instead of having the code in a variable
$oToken->setInputString($sourcecode);
$oToken->process();
// And here we get the result, all clean !
echo $oToken->get();
Note that I also had to path two small things in phpDoc.filter.php, to avoid a warning and a notice...
The corresponding patch can be downloaded there : http://extern.pascal-martin.fr/so/phpDoc.filter-pmn.patch
Now, if we run that beautifier-1.php script :
$ php ./beautifier-1.php
With a MyClass.php file that initialy contains this code :
class MyClass {
public function __construct($myString, $myInt) {
//
}
/**
* Method with some comment
* #param array $params blah blah
*/
public function doSomething(array $params = array()) {
// ...
}
protected $_myVar;
}
Here's the kind of result we get -- once our file is Beautified :
<?php
/**
*
* PHP version 5
*
* LICENSE: This source file is subject to version 3.0 of the PHP license
* that is available through the world-wide-web at the following URI:
* http://www.php.net/license/3_0.txt. If you did not receive a copy of
* the PHP License and are unable to obtain it through the web, please
* send a note to license#php.net so we can mail you a copy immediately.
* #category PHP
* #package
* #subpackage Filter
* #author FirstName LastName <mail>
* #copyright 2009 FirstName LastName
* #link
* #license http://www.php.net/license/3_0.txt PHP License 3.0
* #version CVS: $Id:$
*/
/**
* #todo Description of class MyClass
* #author
* #version
* #package
* #subpackage
* #category
* #link
*/
class MyClass {
/**
* #todo Description of function __construct
* #param $myString
* #param $myInt
* #return
*/
public function __construct($myString, $myInt) {
//
}
/**
* Method with some comment
* #param array $params blah blah
*/
public function doSomething(array $params = array()) {
// ...
}
protected $_myVar;
}
We can note :
The license block at the beginning of the file
The docblock that's been added on the MyClass class
The docblock that's been added on the __construct method
The docblock on the doSomething was already present in our code : it's not been removed.
There are some #todo tags ^^
Now, it's not perfect, of course :
It doesn't document all the stuff we could want it too
For instance, here, it didn't document the protected $_myVar
It doesn't enhance existing docblocks
And it doesn't open the file in any graphical editor
But that would be much harder, I guess...
But I'm pretty sure that this idea could be used as a starting point to something a lot more interesting :
About the stuff that doesn't get documented : adding new tags that will be recognized should not be too hard
You just have to add them to a list at the beginning of the filter
Enhancing existing docblocks might be harder, I have to admit
A nice thing is this could be fully-automated
Using Eclipse PDT, maybe this could be set as an External Tool, so we can at least launch it from our IDE ?
Since PHPCS was already mentioned, I throw in the Reflection API to check for missing DocBlocks. The article linked below is a short tutorial on how you could approach your problem:
http://www.phpriot.com/articles/reflection-api
There is also a PEAR Package PHP_DocBlockGenerator that can Create the file Page block and the DocBlocks for includes, global variables, functions, parameters, classes, constants, properties and methods (and other things).
php-tracer-weaver can instrument code and generate docblocks with the parameter types, deducted through runtime analysis.
You can use the Code Sniffer for PHP to test your code against a predefined set of coding guidelines. It will also check for missing docblocks and generate a report you can use to identify the files.
The 1.4.x versions of phpDocumentor have the -ue option (--undocumentedelements) [1], which will cause undocumented elements to be listed as warnings on the errors.html page that it generates during its doc run.
Further, PHP_DocBlockGenerator [2] from PEAR looks like it can generate missing docblocks for you.
[1] -- http://manual.phpdoc.org/HTMLSmartyConverter/HandS/phpDocumentor/tutorial_phpDocumentor.howto.pkg.html#using.command-line.undocumentedelements
[2] -- http://pear.php.net/package/PHP_DocBlockGenerator
We use codesniffer for this functionality at work, using standard PEAR or Zend standards. It will not allow you to edit the files on the fly, but will definitely give you a list, with lines and description of what kind of docblock is missing.
HTH,
Jc
No idea if it's any help, but if Codesniffer can point out the functions/methods, then a decent PHP IDE (I offer PHPEd) can easily inspect and scaffold the PHPDoc comments for each function.
Simply type /** above each function and press ENTER, and PHPEd will auto-complete the code with #param1, #param1, #return, etc. filled out correctly, ready for your extra descriptions. Here's the first one I tried in order to provide an example:
/**
* put your comment here...
*
* #param mixed $url
* #param mixed $method
* #param mixed $timeout
* #param mixed $vars
* #param mixed $allow_redirects
* #return mixed
*/
public static function curl_get_file_contents($url, $method = 'get', $timeout = 30, $vars = array(), $allow_redirects = true)
This is easily tweaked to:
/**
* Retrieves a file using the cURL extension
*
* #param string $url
* #param string $method
* #param int $timeout
* #param array $vars parameters to pass to cURL
* #param int $allow_redirects boolean choice to follow any redirects $url serves up
* #return mixed
*/
public static function curl_get_file_contents($url, $method = 'get', $timeout = 30, $vars = array(), $allow_redirects = true)
Not exactly an automated solution, but quick enough for me as a lazy developer :)
You want to actually automate the problem of filling in the "javadoc" type data?
The DMS Software Reengineering Toolkit could be configured to do this.
It parses source text just like compilers do, builds internal compiler structures, lets you implement arbitrary analyses, make modification to those structures, and then regenerate ("prettyprint") the source text changed according to the structure changes. It even preserves comments and formatting of the original text; you can of course insert additional comments and they will appear and this seems to be your primary goal. DMS does this for many languages, including PHP
What you would want to do is parse each PHP file, locate every class/method, generate the "javadoc" comments that should be that entity (difference for classes and methods, right?) and then check that corresponding comments were actually present in the compiler structures. If not, simply insert them. PrettyPrint the final result.
Because it has access to the compiler structures that represent the code, it shouldn't be difficult to generate parameter and return info, as you suggested. What it can't do, of course, is generate comments about intendend purpose; but it could generate a placeholder for you to fill in later.
I had to do a large batch of automation of docblock fixing recently, mostly based on the correct answer above kwith some context-specific changes. It's a hack, but I'm linking back here in case it's useful to anyone else in the future. Essentially, it does basic parsing on comment block tokens within PHP Beautifier.
https://gist.github.com/israelshirk/408f2656100196e73367

Categories

Resources