This repository contains:
- Source code: original_code/inventory_system_original.py
- Fixed code: fixed_code/inventory_system.py
- Reports: Pylint, Bandit, Flake8 (see
reports/folder) -- Obtained Before and After debug/ fixes (Found in the reports folder for reference--its results were summarised and enlisted below)
| No. | Issue Description | Tool | Line(s) | Severity | Planned Fix |
|---|---|---|---|---|---|
| 1 | Dangerous default mutable argument — The function addItem() uses a default list logs=[]. This can cause shared state across calls. |
Pylint (W0102) | 8 | High | Change to logs=None and initialize inside the function using if logs is None: logs = []. |
| 2 | Bare except / no specific exception type — The except: block in removeItem() hides real errors and causes debugging issues. |
Pylint (W0702), Bandit (B110) | 19 | Medium | Replace except: with except KeyError: or except Exception as e: and log or print the error safely. |
| 3 | Use of eval() — Dangerous use of eval("print('eval used')"), which allows arbitrary code execution. |
Bandit (B307) | 59 | High | Remove eval() entirely and replace it with a direct print statement or a safe function call. |
| 4 | Open file without context manager and encoding — File operations in loadData() and saveData() use open() without with or explicit encoding. |
Pylint (W1514, R1732) | 26, 32 | Medium | Use with open(filename, 'r', encoding='utf-8') as f: and similar for write operations to ensure safe file handling. |
- High priority fixes: #1, #3
- Medium priority fixes: #2, #4
- Total issues detected by tools: 7
- High/Medium issues chosen for fixing: 4
- These fixes aim to improve code safety, maintainability, and compliance with Python best practices.
- After implementation, static-analysis tools will be re-run to confirm improvement in the Pylint score and security checks.
Q1. Which issues were the easiest to fix, and which were the hardest? Why?
Easy: adding docstrings and removing unused import.
Hard: fixing eval() and the bare except because they needed logic changes.
Q2. Did the static analysis tools report any false positives? If so, describe one example.
Yes, a small one — it flagged spacing and naming even though the code worked fine.
Q3. How would you integrate static analysis tools into your actual software development workflow?
I would run them often and add them to GitHub Actions to check code automatically.
Bandit flagged this incorrectly
Q4. What tangible improvements did you observe in the code quality, readability, or potential robustness after applying the fixes?
The code looks cleaner, safer, and easier to read now.