"Fossies" - the Fresh Open Source Software Archive

Member "brlcad-7.32.4/doc/checklist.txt" (29 Jul 2021, 3323 Bytes) of package /linux/misc/brlcad-7.32.4.tar.bz2:


As a special service "Fossies" has tried to format the requested text file into HTML format (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file.

    1 BRL-CAD Code Review Checklist
    2 =============================
    3 
    4 Included below is a list of criteria used when reviewing code changes.
    5 While not comprehensive, it's a good checklist for new contributors to
    6 evaluate against their changes prior to submission.  The checklist is
    7 part of common criteria used for core development and peer review.
    8 The answer to all questions should be "yes".
    9 
   10 
   11 Legal
   12 -----
   13 00. Are all changes under legally compatible license?  No GPL, no NC.
   14 01. Are all contributors documented?  AUTHORS if new.
   15 02. Do all new files have correct license header, copyright line, year?
   16 
   17 Organization
   18 ------------
   19 03. Are changes in an appropriate location with similar/related logic?
   20 04. Do all new files have a consistent name?  c/cpp/h extension.
   21 05. Do the changes NOT introduce a cyclic dependency?
   22 
   23 Style
   24 -----
   25 06. Does the file have the right style footer?
   26 07. Is the code indented consistently?  4 char per level, 8 char tabs.
   27 08. Is whitespace correct (no EOL spaces, internal tabs, or space around ops)?
   28 09. Are braces consistent with existing code?  Typically BSD KNF / K&R style.
   29 
   30 Documentation
   31 -------------
   32 10. Publicly visible changes / features are documented?  NEWS entry.
   33 11. Does referencing documentation reflect interface changes?  Check manpages.
   34 12. Are new public symbols documented?  Doxygen comment in include/ dir.
   35 13. Are changed public symbols documented?  CHANGES entry, DEPRECATED comment.
   36 14. Is all dead or conditional debugging code documented?  Comment or remove.
   37 15. Are new numeric constants documented?  Comment or eliminate.
   38 
   39 Declaration
   40 -----------
   41 16. Do changed files include and only include headers in use by that file?
   42 17. Are new public symbols named consistently?  Prefixed according to library.
   43 18. Are new private symbols NOT prefixed like they're public?
   44 19. Are new functions NOT referenced in other files marked static?
   45 20. Are new global variables avoided?  No new ones allowed in libraries.
   46 
   47 Definition
   48 ----------
   49 21. Do changes avoid platform/compiler-specific constructs?  libbu exempt.
   50 22. Do new structures / classes have static size?  No preprocessor toggles.
   51 23. Do changes avoid exact floating point math?  Use NEAR_EQUAL, see vmath.h
   52 24. Do changes use wrapped system functions?  See libbu API and HACKING.
   53 25. Do changes avoid duplication, or refactor accordingly to shared code?
   54 
   55 Compilation
   56 -----------
   57 26. Does the code compile without warnings?  All enabled.
   58 27. Reasonable to think changes will trivially compile on all major platforms?
   59 
   60 Testing
   61 -------
   62 28. Are any new inputs checked, sanitized?
   63 29. For changes fixing a recurrant bug, is there an accompanying test?
   64 30. Does performance testing pass and NOT decrease?  No slow downs.
   65 31. Do all regression tests pass?  No new failures.
   66 
   67 
   68 The following guidelines are also desirable ideals, but not as
   69 strictly measurable:
   70 
   71 ** should minimize new public API, less is more
   72 ** should leverage standard libraries and standards, C++11 in particular
   73 ** should leverage demonstrably robust 3rd-party dependencies
   74 ** should resist new 3rd-party dependencies with duplicate functionality
   75 ** should keep code robust to different configurations and change
   76 ** should resist or eliminate changes not taken to some useful completion
   77 ** should prefer simple over complex or clever, except that which has merit