How did you go about doing your code reviews? Do you prefer an async or sync approach? Why?
I prefer the async approach because I like checking my mistakes later and figuring them out by giving myself time, otherwise I forget what kind of problems I faced.
What was it like testing and reviewing someone else's code? Did you run into any problems? Did anything surprise you?
I actually liked it because I realized that the issues I had in my code could be the same problems other people face. Also, that was the first time I worked with the Go language. I liked the simplicity and error handling of this language. Overall, I understood that the logic looks pretty much the same across different languages.
That's pretty cool. Someone who reads my code doesn't see my code as sacred, so when they find issues, it saves me time and I learn a lot.
What was it like having someone test and review your code? Were you surprised by anything?
I actually liked it, because i realised that the issues that i got in my code people could have the same problems. Also that was the first time i checked Go language. I liked the simplicity and error handling of this language. Overall, i got the main idea that in other languages the logic looks pretty the same.
What kind of issues came up in your testing and review? Discuss a few of them in detail.
I faced redundant else clauses and faulty error handling. Even though I didn't know Go, I was able to figure it out based on my experience with other languages.
Provide links to issues you filed, and summarize what you found
1) https://www.reddit.com/r/golang/comments/1dbaxf6/how_can_someone_write_go_code_to_annoy_you_during/
3) https://www.geeksforgeeks.org/system-design/single-responsibility-in-solid-design-principle/
Regarding the first link, I realized how people misuse the language based on their experience with other languages, which breaks Go language principles.
I found the second link really useful for producing reliable and reusable code. The third one explains how we can avoid making one module or struct too heavy and how to make code reusable.
Provide links to issues that were filed on your repo, and what they were about
1) https://stackoverflow.com/questions/13047693/cmake-problems-in-windows
2) https://stackoverflow.com/questions/72756469/can-i-use-vcpkg-without-visual-studio
I will figure this out, i have not fixed yet,but thanks to the collaboration with my groupmate i doubly verified i got problems with CMake and linkage errors.What i have done so far for CMake and vcpkg are static and will not be used in other OS except Windows.
Were you able to fix all your issues? What was that like?
As I mentioned before, I will improve on that and keep working on it. I know that proper project set up and handling dependencies are my weak points.
What did you learn through the process of doing the testing and reviewing?
I learned that it's not necessary to be afraid of other languages; at the end of the day, logic is mostly the same and I can be flexible. Also, I realized again that having someone review your code is really good for improvement and avoiding waste of time.
Note about your links: The links you provided are general resources about Go practices and CMake issues, but they don't appear to be actual GitHub issues you filed. For academic assignments, you typically need to provide links to specific issues you created in repositories, not general educational resources.
Top comments (0)