Talk:Documentation Team: Difference between revisions
New page: One programmer's opinion: I believe it is a mistake to rely on "read the code" as a solution to sugar documentation. There needs to be a document for each class this organization invents... |
No edit summary |
||
| Line 4: | Line 4: | ||
1. What the class is for and when it's appropriate for the developer to use it. | 1. What the class is for and when it's appropriate for the developer to use it. | ||
2. What the class is derived from (if anything), what base-class methods/attributes it overrides/extends/hides and what new methods/attributes are provided. * | 2. What the class is derived from (if anything), what base-class methods/attributes it overrides/extends/hides and what new methods/attributes are provided. * | ||
3. Methods and attributes reference (it could be appropriate for this part to be generated from the code). | 3. Methods and attributes reference (it could be appropriate for this part to be generated from the code). | ||
* Pardon me if that's not Python-speak: I'm new to the Python language. Methods are the things in a class that start with "def"; attributes are the class's data. | (*) Pardon me if that's not Python-speak: I'm new to the Python language. Methods are the things in a class that start with "def"; attributes are the class's data. | ||
| Line 16: | Line 18: | ||
A nice-to-have in all of this would be the ability to call up the relevent documentation while coding, as can be done in Visual Studio. | A nice-to-have in all of this would be the ability to call up the relevent documentation while coding, as can be done in Visual Studio. | ||
[[User:Davewa|dave]] 20:03, 19 May 2008 (UTC) | |||