Changes between Version 2 and Version 3 of org/meetings/2017Amsterdam/Notes/FindingTechnicalDebtsinTor


Ignore:
Timestamp:
Mar 29, 2017, 8:26:22 PM (2 years ago)
Author:
alison
Comment:

formatting changes

Legend:

Unmodified
Added
Removed
Modified
  • org/meetings/2017Amsterdam/Notes/FindingTechnicalDebtsinTor

    v2 v3  
    1313* We also focused more on coding standards to reduce tech debt in the future. Some things we discussed are:
    1414     
    15 0. Limiting function size to what can fit within a screen (50-60 lines)             
     151. Limiting function size to what can fit within a screen (50-60 lines)             
    1616                                                                                   
    17 1. Limiting test function size similarly, and using contexting to group similar tests
     172. Limiting test function size similarly, and using contexting to group similar tests
    1818                                                                                   
    19 2. Limiting module size, focusing on single responsibility   
     193. Limiting module size, focusing on single responsibility   
    2020                                                                                   
    21 3. Reducing what is available publicly. or.h is a good candidate for refactoring, a lot of its structures can be made private within modules         
     214. Reducing what is available publicly. or.h is a good candidate for refactoring, a lot of its structures can be made private within modules         
    2222                                                                                   
    23 4. Tests should be added for new functionality, and when changing legacy functionality
     235. Tests should be added for new functionality, and when changing legacy functionality
    2424
    25 5. We should be more strict when accepting new code and changing legacy code in general, balancing of course the when there is a need to merge something quickly.                                                                   
     256. We should be more strict when accepting new code and changing legacy code in general, balancing of course the when there is a need to merge something quickly.                                                                   
    2626                                                                                   
    27 6. Reducing size of commits, which should help when reviewing code
     277. Reducing size of commits, which should help when reviewing code
    2828
    29 7. Limit block nesting depth (opinions vary but we discussed 3 as a max depth)
     298. Limit block nesting depth (opinions vary but we discussed 3 as a max depth)
    3030
    3131* We also discussed the stability of the Tor API, as currently, we don't advertise having a stable API. However, doxygen output might lead people to think otherwise. We should add a warning about this.