-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cleanup #5
cleanup #5
Conversation
@nVitius i don't know why are we doing options or arguments with upper cases, i know it will probably make you change code but if we can do this in a way that you can do it then let's switch, if not then no worries. |
@cordoval In AWS' API documentation they are written in uppercase like that, so I did the same for mine. If other people think they should be lowercase too though, I can look into changing it. |
no need to spend time on that, let's just leave them at that. Just thought to mention that arguments and options are preferrably lower cases. |
Typically, they should be lowercase, but that is a good question |
@shideon The @abstract tag is only valid in PHP 4, PHP 5 has a keyword abstract. I thought so too, but, apparently not |
I tend not to be repetitive unnecessarily and often prefer to sacrify standards for clean code. I often get a @fabpot like summon when i add things that don't bring value: "does not add value." That is the main reason. It duplicates information or does not keep it DRY. |
and now Aaron just gave me another reason to back it up 👶 |
This does add value. There's code and there are API docs which the docblocks are for. We also have access on class members and methods but we still document them for the API docs.
|
oh no please |
@shideon i'm not really sure that would add value either @shideon. When api docs are generated, they are generated with their access regardless of specifying |
Does PHP Doc generate based on code or docblocks? I'm pretty sure it doesn't read your code (if it did, why have docblocks to begin with?) |
Could totally be wrong. |
Not to mention, I would argue that Private and Protected functions don't really need to be documented in API, as they can't be called outside of the class they reside in. I believe it does read some things from the code, like access. |
er, at least private. Protected could be |
That doesn't matter. The api docs aren't just for clients who have only public access. It's also for others that do have that access. |
If you can't call a private method, or override it, why does it matter? |
Because perhaps I'm a developer working on an extensive library and I do have that access but I want to view docs at a high level to understand things. |
If we're talking about docblocks on protected functions, I think it makes sense to have them. Sure, it doesn't matter when you're talking about API documentation, but it gives an insight into what the function does to whoever is working on the code. |
I would agree to that. But i will still say that having |
For the sake of consistency, if anything, I would probably leave them in there. |
What consistency? |
http://manual.phpdoc.org/HTMLSmartyConverter/HandS/phpDocumentor/tutorial_tags.access.pkg.html
|
Hmm, on the new docs page here: http://phpdoc.org/docs/latest/index.html The @access tag is not there. So perhaps phpdoc does do a little reflection (or some equivalent form of reading) to read the access. Let's hope. That's an important feature from an API doc perspective (even if it's private and I'm editing or working with code that can call it). |
That's v2 of phpdoc. |
@shideon if the code is documented properly, you shouldn't even need to know that its calling a private method |
I suppose it's API docs, so for that argument, you guy's are right. But if I'm editing the classes, it's different. |
And again, i'm not saying there shouldnt be documentation for methods inside the classes. There definitely should be. even if @cordoval disagrees lol |
So about those lower case args and options... I agree. =P |
Quite the discussion. |
Sent with Gush