Peer Partnership

This week, as part of my open-source development course (DPS 909 at Seneca College), I had the opportunity to both review a peer’s code and have my own code reviewed. My partner for this exercise was my good friend Fahad Ali Khan. Fahad’s CLI app processes text files to summarize, format, or paraphrase documents, while my project, Tailor4Job, customizes resumes for specific job postings. We decided to conduct our code reviews asynchronously. Here’s what I found during this process.

Reviewing Fahad's CLI App

1. API Key Security Issue
   One major issue with Fahad’s code was the inclusion of an API key as a class member without any security handling. This is a serious security concern. Exposing sensitive information in code can lead to vulnerabilities and potential misuse. Fahad acknowledged this mistake and recognized the importance of securing sensitive data in open-source projects.

2. Use of conio.h
   Fahad used conio.h to design his CLI app. While conio.h allowed him to create the CLI as he intended, it’s not part of the standard C++ library and is platform-specific. I suggested replacing it with modern, portable alternatives to ensure cross-platform compatibility. Fahad was open to this suggestion but questioned whether providing platform-specific instructions would suffice.

3. File Input Limitations
   Another significant issue was the app’s inability to handle multiple file inputs. This limitation affects the functionality and usability of the application. Fahad appreciated this feedback, as it was crucial for the development of his app.

Reviewing My Repo

1. No Validation for Input Files
   In reviewing my code, Fahad pointed out the lack of validation for input files. This is a crucial issue, as inadequate validation can lead to crashes or unexpected behavior. Ensuring robust input validation is essential for reliable application performance.

2. Hardcoding File Format Constraints
   Fahad also noted that I hardcoded file format constraints (restricting inputs to docx and pdf). He suggested that this approach limits the flexibility and maintainability of the app. I agree that making these constraints configurable would enhance the app’s adaptability.

3. Error Handling in File Reading
   Another flaw identified was the lack of proper error handling in file reading operations. The app should be able to manage scenarios where files are missing, locked, or unreadable. Addressing this issue is vital to ensure the app remains functional under various conditions.

Links to Issues Filed:

No validation for input files
Hardcoding File Format Constraints
Error Handling in File Reading
Links to Issues on Fahad’s Repo:

API key as a class member without security handling
Use of conio.h
Cannot input multiple files
Addressing the Issues

I managed to address some of the issues in my repo, though some remain unresolved. The asynchronous review process was a new experience for me, but it was insightful to see Fahad’s approach to coding and provide feedback. Similarly, receiving feedback on my code highlighted areas for improvement and reinforced the importance of thorough validation and error handling.

What I Learned

This code review process was a valuable learning experience. It emphasized the importance of rigorous testing, flexible coding practices, and effective collaboration. Reviewing Fahad’s code and receiving feedback on my own projects showcased the benefits of constructive criticism and the need for continuous improvement in software development.