UVicDSA18
  • Introduction
  • Keras
    • 1. Introduction
    • 2. Documentation Overview
    • 3. Stakeholders
    • 4. Business Goals
    • 5. Architecturally Significant Requirements
    • 6. Module View
      • Main Diagram
      • Element Catalogue
      • Context Diagram
      • Behaviour Diagrams
      • Module Organization Rationale
    • 7.Component and Connector View
      • Main Presentation
      • Element Catalog
        • Elements
        • Relations
        • Interfaces
      • Context Diagram
      • Behavior Diagrams
        • Building a Sequential Model
        • Training a Model
      • Variability Guide
      • Rationale
    • 8. Code Quality and Technical Debt
      • Code Quality Report
        • Introduction
        • Code Quality Issues
      • Potential Technical Debt
        • Introduction
        • Length and Complexity Issues
        • Backend Conditional Code Paths
      • Conclusion
    • 9. Conclusion
    • 10. References
  • Tensorboard
    • List of Figures
    • 1.0 Introduction
    • 2.0 Identifying Stakeholders and Business Goals
      • 2.1 Stakeholders
      • 2.2 Business Goals
    • 3.0 Architecturally Significant Requirements and Utility Tree
      • 3.1 List of Architecturally Significant Requirements
      • 3.2 Prioritized List of Scenarios
      • 3.3 Quality Attribute Scenario Templates
      • 3.4 Utility Tree
    • 4.0 Module View
      • 4.1 Primary Presentation
      • 4.2 Element Catalog
      • 4.3 Context Diagram
      • 4.4 Sequence Diagram
      • 4.5 Rationale
    • 5.0 Component and Connector View
      • 5.1 Primary Presentation
      • 5.2 Element Catalog
        • 5.2.1 Elements and Properties
        • 5.2.2 Relations and Properties
        • 5.2.3 Elements Interfaces
          • Loading Events from a Directory File
          • Processing and Prepare to Load Events into Plugins
        • 5.2.4 Element Behaviour
      • 5.3 Context Diagram
      • 5.4 Variability Guide
      • 5.5 Rationale
    • 6.0 Technical Debt
      • 6.1 SonarQube Analysis
        • 6.1.1 Function Names
        • 6.1.2 Methods and Field Name Capitalization
        • 6.1.3 Cognitive Complexity of the Code
        • 6.1.4 Merging Collapsible “if” Statements
        • 6.1.5 Reducing Code Duplications
      • 6.2 CodeScene Analysis
        • 6.2.1 Hotspots
        • 6.2.2 Refactoring Targets
        • 6.2.3 Code Age
        • 6.2.4 Internal Temporal Coupling
      • 6.3 Technical Debt Recommendations
        • 6.3.1 Duplications and Refactoring
        • 6.3.2 Function Recommendation
        • 6.3.3 Stability
        • 6.3.4 Absence of a Dataset Module
        • 6.3.5 Compatibility of Multiple Browsers
        • 6.3.6 “TODO” Search and Analysis
        • 6.3.7 Other Recommendations
      • 6.4 Technical Debt Summary and Conclusions
    • 7.0 Pull Request
      • 7.1 Problem Description
      • 7.2 Solution
    • 8.0 Conclusions
    • 9.0 References
  • Toyplot
  • Strapi
    • Purpose
    • About Strapi System
    • Stakeholders
    • Business Goals
    • Architecturally Significant Requirements (ASR)
    • Utility Tree
    • Quality Attribute Scenarios (QAS)
    • Module View
      • Primary Presentation
      • Element Catalog
        • Elements and Properties
        • Relations and Properties
        • Element Behaviour
      • Context Diagram
      • Rationale
    • Component and Connector View
      • Primary Presentation
      • Element Catalog
        • Elements and Properties
        • Relations and Properties
        • Element Behaviour
      • Context Diagram
      • Variability Guide
      • Rationale
    • Code Quality and Technical Debt
    • Conclusion
  • Cartographer
    • 1.0 Introduction
    • 2.0 Stakeholder Analysis
    • 3.0 Architecturally Significant Requirements
    • 4.0 Module View
    • 5.0 Component and Connector View
    • 6.0 Code Quality Review
    • 7.0 Conclusion
    • 8.0 References
  • RocketChat
    • Abstract
    • 1. Introduction
      • 1.1 Project overview
      • 1.2 About RocketChat
      • 1.3 Our Project Team
    • 2. Stakeholders and Business Goals
      • 2.1 Stakeholders
      • 2.2 Business Goals
    • 3. Architecturally Significant Requirements
      • 3.1 ASR
      • 3.2 Utility Tree
      • 3.3 Quality Attribute Scenario
    • 4. Module View
      • 4.1 Primary Presentation
      • 4.2 Element Catalog
      • 4.3 Context Diagram
      • 4.4 Behaviour Diagram
      • 4.5 Rationale
    • 5. Component and Connector View
      • 5.1 Primary Presentation
      • 5.2 Element Catalog
      • 5.3 Behaviour Diagram
      • 5.4 Interface Documentation
      • 5.5 Rationale
    • 6. Code Quality and Technical Debt
      • 6.1 Code Quality Analysis Tools
        • 6.1.1 SonarQube
        • 6.1.2 CodeScene
    • 7. Conclusion
    • References
  • SwaggerUI
  • Homebrew
    • 1. Introduction
      • 1.1 Project Overview
      • 1.2 Our Project Team
      • 1.3 Our Supervisors
    • 2. Identifying Project Stakeholders and Business Goals
      • 2.1 Stakeholders
      • 2.2 Business Goals
    • 3. Architecturally Significant Requirements and Utility Tree
      • 3.1 Architecturally Significant Requirements
      • 3.2 Utility Tree
      • 3.3 Quality Attribute Scenarios
    • 4. Module View
      • 4.1 Primary Presentation
      • 4.2 Element Catalog
      • 4.3 Context Diagram
      • 4.4 Behaviour Diagram
      • 4.5 Rationale
    • 5. Component and Connector View
      • 5.1 Primary Presentation
      • 5.2 Element Catalog
      • 5.3 Interface Documentation
        • 5.3.1 Interface
        • 5.3.2 Interface
      • 5.4 Context Diagram
      • 5.5 Variability Guide
        • 5.5.1 Adding/Removing Formulae in homebrew-core
        • 5.5.2 Managing Custom Formulae in homebrew-core
      • 5.6 Behaviour Diagram
      • 5.7 Rationale
    • 6. Code Quality and Technical Debt
      • 6.1 Code Quality Analysis Tools
        • 6.1.1 SonarQube
        • 6.1.2 CodeClimate
        • 6.1.3 CodeScene
      • 6.2 Analysis of Issues
        • 6.2.1 Primary Refactoring Targets
        • 6.2.2 Change Management
    • 7. Conclusion
    • 8. References
  • Open source contributions
Powered by GitBook
On this page
  1. Keras
  2. 8. Code Quality and Technical Debt
  3. Potential Technical Debt

Length and Complexity Issues

PreviousIntroductionNextBackend Conditional Code Paths

Last updated 6 years ago