I've always written my code by myself or with a group. I've never read someone else's code to find bugs and formatting issues. That's why when we are told that we'll be reviewing other people's code, I wasn't too keen on doing it.
I first looked for a group chat on Slack and found someone who's writing in JavaScript and decided to be partners for this project
Testing and reviewing someone's code is not that different from reviewing your own. I'll say the hardest part was understanding how his code works, and looking for any errors no matter how miniscule they might be. Reading my partner's code surprised me for how elegant his style was compared to mine.
I'm only a beginner in terms of coding. I know the ins and outs of JavaScript, but seeing as how my partner tackled his code, I can only say that I still have much to learn.
Seeing his code I didn't think I would find much of a problem with it so I was a little bit scared. However, realizing that regardless of how good someone is at coding, making some silly mistakes are still a common occurrence. There were a few issues that I noticed with his code.
Partner Issues
Issue #1
I noticed that the code that he had doesn't prevent the user from reading through non text files. This causes the program to throw an error, which can lead to a problem for larger folders. What if the user wants to convert a bunch of .txt files? The process of doing so will be halted, and the user has to go and find the non-txt file which can be an issue if they have a huge amount files to convert.
Issue #2
He doesn't have any prompts to indicate to the user on whether they had failed a specific task. I noticed that when the user misspelled a name for a directory for the "input" flag, that the program just restarts and doesn't do anything. This is a problem, because there are no difference between failing and succeeding on using the flag. It's all blank.
Issue #3
This problem is more of an issue that the project doesn't address. The user is told to overwrite the folder to prevent previous files from showing in the current instance of output. The problem with this however, is that it doesn't prevent the user from overwriting already existing folders i.e., "src".
Issue #4
He doesn't have any condition to prevent the user from overwriting already existing files. I was messing around with his "output" flag, and noticed that when he type the name of a file or a folder that exists within his directory tree, the program overwrites the entire file turning it into a directory. This can be a problem, because I can override his main js file.
Issue #5
This is another issue with the structure of the project description. The author didn't consider the amount of folders the user can create with the output flag. What if the user create a hundred folders, this is a problem for it can make the directory tree cluttered.
My Issues
Issue #1
I was told that having your code written containing a folder that has to be changed every time I pushed my repository was inefficient.
Issue #2
I never considered the importance of having a lock-file for when other people try out my code. What if one of my module were outdated, the program doesn't know that so they install the latest module causing problems with the way my program runs.
Issue #3
It's a silly mistake that I made, because I was just starting to get back on coding after a few months of not doing anything. I was planning on creating a server, but realized it's a static program so there's really no need for that. I forgot to uninstalled it after not using it.
Issue #4
I had forgotten that using a var can lead to a problems down the line with my program. When writing a variable for a function. 90% of the time I only use them for a particular scope i.e., inside a loop, if etc. The problem with using a var is that it makes it so that it can be accessible within the scope of a function regardless on whether I want it to be just within the scope of the condition that I want. On the other hand, let is only accessible within the scope of where it is declared. If I declared it on a for loop, it's only accessible within that block of scope.
Issue #5
I never considered the difference between each Operating System. The use of \n might work on Windows, but it might not work on other OS.
Issue #6
Another silly mistake that I made. I forgot to refer to the actually LICENSE that I was using on my package.json. Would've cause me problem down the line.
Issue #7
Having a great format like .prettier should help my code look more organized instead of clutter
By the end of the day, I managed to solve all the issues I had with my code. The best part of reading through each issue and fixing them, allowed me to find other problems with my code. I learned that by reading other people's code can help you see new ways to right your own. Whilst listening to any glaring issues you might have with your own, can help you find more problems that you might not have seen.
Top comments (0)