Macintosh-SW/ResKnife
1
0
Fork 0
mirror of https://github.com/nickshanks/ResKnife.git synced 2024-09-27 11:59:05 +00:00
Code Issues Projects Releases Wiki Activity

I wish I had a markdown editor that did live previewing

Browse Source 
That way I wouldn't have to commit to Github each time I wanted to see
how my edits looked
This commit is contained in:
Eric Gallager 2012-05-06 12:53:53 -04:00
parent e74056d839
commit bbd36e8d84
1 changed files with 26 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

47
README.md
View File

@ -1,8 +1,14 @@
/*
* * * * * * * * * * * *
RESKNIFE READ-ME
* * * * * * * * * * * *
Last updated: 9 November 2003 (i.e. a really long time ago)
#* * * * * * * * * * * *
#RESKNIFE READ-ME
#* * * * * * * * * * * *
Last updated by someone official: 9 November 2003 (i.e. a really long time ago)
WHAT IS IT?
-----------
@ -65,25 +71,24 @@ Notes on commenting/documenting for the ResKnife project:
ResKnife methods, functions, headers, classes, ivars and practically anything else is commented using the format specified by HeaderDoc (a C-based equivalent to JavaDoc), although with ResKnife-specific modifications (NB: although I've yet to modify HeaderDoc to read these new parameters, they should still be used for the time being). The general format is to use the standard C block-commenting mechanism, with the addition of an exclamation mark immediately after the open comment marker. Following this are one or more lines beginning with an at sign, a keyword, arguments if any, and finally a string value. For source code consistency, I (Nicholas) am suggesting the following when documenting an object.
1) All HeaderDoc comments immediately precede the object to which they pertain.
2) HeaderDoc comments documenting a method or function must follow the following order (for consistency & readability), where an ellipsis indicates the line above can be repeated multiple times:
1) All HeaderDoc comments immediately precede the object to which they pertain.
2) HeaderDoc comments documenting a method or function must follow the following order (for consistency & readability), where an ellipsis indicates the line above can be repeated multiple times:
`@method` or `@function`
`@abstract`
`@author`
`@created`
`@updated` [significant changes that other developers should be aware of; ordered reverse chronological, i.e. most recent at the top]
...
`@pending` [higher priority TODO items should be above lower priority ones]
...
`@description`
`@param` [listed in order taken by method/function]
...
`@method` or `@function`
`@abstract`
`@author`
`@created`
`@updated` [significant changes that other developers should be aware of; ordered reverse chronological, i.e. most recent at the top]
...
`@pending` [higher priority TODO items should be above lower priority ones]
...
`@description`
`@param` [listed in order taken by method/function]
...
3) The pertinent keywords or their equivalents in the above item should retain the specified order wherever reasonably applicable (e.g. for `@class` and `@protocol` comments)
4) The value for the `@created` keyword should take the following form: YYYY-MM-DD
5) The value for the `@updated` keyword should take the following form: YYYY-MM-DD Author: Description
where Author is your initials or sourceforge user name.
3) The pertinent keywords or their equivalents in the above item should retain the specified order wherever reasonably applicable (e.g. for `@class` and `@protocol` comments)
4) The value for the `@created` keyword should take the following form: `YYYY-MM-DD`
5) The value for the `@updated` keyword should take the following form: `YYYY-MM-DD Author: Description` where "Author" is your initials or Sourceforge user name (or Github user name).
Due to really poor maintenance on my part, very few methods have `@updated` comments. Sorry :-(
*/