-
Which issues were the easiest to fix, and which were the hardest? Why? Easiest: The style-related and simple logical issues were easiest to fix — such as changing the mutable default argument (logs=[] → logs=None) and correcting PEP 8 violations like spacing, blank lines, and long lines flagged by Flake8. These fixes required minor syntax adjustments. Hardest: The hardest issues were related to exception handling and security. Replacing the broad except: statements with specific exceptions (KeyError, TypeError) required analyzing how errors could occur. Removing eval() and safely replacing it with ast.literal_eval() also required understanding Bandit’s security recommendations and ensuring equivalent safe functionality.
-
Did the static analysis tools report any false positives? If so, describe one example. Yes. Pylint occasionally flagged some variables as "unused" even though they were used indirectly for logging or formatting purposes. For example, a variable used only inside a logging.info() statement was sometimes marked as unused, even though it contributed to output. Such warnings were reviewed but left unchanged since the code behavior was correct and intentional.
-
How would you integrate static analysis tools into your actual software development workflow? -> Integrate Pylint, Flake8, and Bandit into a Continuous Integration (CI) pipeline using GitHub Actions. -> Configure CI to automatically run these tools on every commit or pull request and fail the build if new issues appear. -> Use pre-commit hooks locally so developers run linting automatically before committing code. -> Maintain a configuration file (.pylintrc, .flake8, .bandit) to ensure consistent rules across the team. -> This ensures early detection of code quality, style, and security issues, improving maintainability and team efficiency.
-
What tangible improvements did you observe in the code quality, readability, or potential robustness after applying the fixes? -> Code Quality: Improved through explicit input validation, safer file handling (with open()), and modular, well-documented functions. -> Readability: Consistent naming conventions and formatted code (PEP 8) made the script easier to understand and maintain. -> Security: Replacing eval() with ast.literal_eval() and adding type checks reduced vulnerabilities. -> Robustness: The use of specific exception handling and proper logging enhanced fault tolerance and traceability. Overall, the final code is cleaner, safer, easier to debug, and production-ready.