Source code documentation template Erica Snider Fermilab June 27, - - PowerPoint PPT Presentation

▶
source code documentation template
SMART_READER_LITE
LIVE PREVIEW

Source code documentation template Erica Snider Fermilab June 27, - - PowerPoint PPT Presentation

Source code documentation template Erica Snider Fermilab June 27, 2017 The objective To the extent reasonably possible Make the code self describing for people interested in Using it Maintaining it Understanding a result


slide-1
SLIDE 1

Source code documentation template

Erica Snider Fermilab June 27, 2017

slide-2
SLIDE 2

May 23, 2017 LArSoft Coordination Meeting 2

The objective

 To the extent reasonably possible

–

Make the code self describing for people interested in

  • Using it
  • Maintaining it
  • Understanding a result

 Requires that

–

It is easy to fnd

–

Contains the key points for those audiences

–

The burden on the developer is low

slide-3
SLIDE 3

May 23, 2017 LArSoft Coordination Meeting 3

The strategy

 Choose the following guidelines

–

Target all levels of the code

–

Have brief comments at the top of header fles, module / service cc fles

–

Adopt more-or-less standard format for

–

Provide only the most important, high-level information required

–

Construct such that they are associated correctly in Doxygen

slide-4
SLIDE 4

May 23, 2017 LArSoft Coordination Meeting 4

The proposal

 In every header fle, module, and service fle, include:

–

File

–

Class

–

Description

–

Inputs

–

Outputs

–

Confguration options

–

Assumptions / pre-requisites

–

Original author / date

–

Revision history

Most important for modules, since these are fixed, but not

  • bvious without looking deep into the implementation

Use @file and @class Doxygen markup for these These are rarely obvious without reading code, but are critical for users to know. Could be in the “description” section, but best to make them easy to see Purpose of the class, what it does, instructions for using it. If appropriate, general description of algorithm. Point is to make it concise. Date + who + one/two line summary of significant changes (can't get this with git)

slide-5
SLIDE 5

May 23, 2017 LArSoft Coordination Meeting 5

The proposal

 In every header fle, module, and service fle, include:

–

File

–

Class

–

Description

–

Inputs

–

Outputs

–

Confguration options

–

Assumptions / pre-requisites

–

Original author / date

–

Revision history

The goal is to allow someone to use the code, so

  • nly need to write as much as needed for that

Detailed description of methods should be included with the method prototype in the class definition Detailed comments on the implementation should be embedded in the code

slide-6
SLIDE 6

May 23, 2017 LArSoft Coordination Meeting 6

The end