Code Review#5
Open
Jas-mine0 wants to merge 1 commit into
Open
Conversation
Naming issues:
There are no comments in the code which makes it difficult to know what is going on.
"Console.WriteLine("gimmiefile");" is not a good naming convention as it is not memorable.
"var z", "var q", "var s",
"var t", "var w" "foreach (var e in a)",
"int j", are also bad naming conventions as they do not explain what the varaible is and it will be
confusing when you go back to the code and try to do more programming, as you won't know what the stand for or what they do.
Code Structure issues:
Code has not been put into different classes, which makes the code look clunky and hard to read.
Code has not been split up into different files and the code violates the single responsibility principle, by not
doing so the code is more difficult to understand.
Error Handling issues:
The code does not check if the file exists, which means that the program will crash if the file does not exist.
No exception handling for the I/O operations on the file.
No validation of user input (examples: empty strings, invalid paths)
File Assumption issue:
Assumes file exists and that it can be read.
OOP Principle issues:
No encapsulation is used, all of the logic is exposed in the main method.
No abstraction has been used.
Output issues:
No sorting of results and poor formatting.
Program Logic issue:
No input validation or sanitization.
Naming suggestions:
Add comments to the code so it is more understandable, readable, and maintainable.
The use of comments will help you understand your code when you go back to it later, in addition to helping other people understand what is going on with your code when they look at it.
Change
"Console.WriteLine("gimmiefile");" to be something more memorable. This will help as you will know what the code is meant to do if it is changed to be something more memorable/descriptive.
Change "var z", "var q", "var s",
"var t", "var w" "foreach (var e in a)",
"int j" to something more memorable. This will help you when you go back to your code as you will then know what each thing stands for.
Code Structure suggestions:
Put the code into different classes, this will make the code less clunky and easier to read.
Split the code into different files and ensure the code does not violate the single responsibility principle. Putting the code into different files will make the code more maintainable.
Error Handling suggestions:
Add error handling and check to see if the file exists. If it does not exist then ensure that the program ends gracefully.
Ensure there is exception handling for the I/O operations on the file. This will ensure that there are no errors regarding exceptions.
Validate user input to ensure that the input is what you expect from the user.
This will ensure that whatever is input will not cause the program to crash.
File Assumption suggestion:
Check if the file exists and that it can be read. If it does not exist or cannot be read tell the user that it cannot be found or read.
OOP Principles suggestions:
Make use of encapsulation to avoid code being altered accidentally.
Make use of abstraction.
Output suggestion:
Sort the results. Examples: sort by frequency, alphabetically, or length.
Program Logic suggestion:
Make use of input validation to ensure the user is giving valid inputs.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
1) "Is the code properly documented/commented?".
No, the code is not proprly documented or commented. The code has no comments in it and provides no information about what the program is supposed to do.
a. "Does it need more work?/Is it great?".
Yes, the code needs more work as it is a very basic program with no comments and no documentation. In addition to this, it does not have good naming conventions, does not handle errors, and does not follow the correct code structure. In my opinion, the program is not great and it could be improved upon.
b. "Where should it be better?".
The code should be better regarding comments, documentation, code structure, handling errors, naming conventions, output, readability, OOP Principles, and Program Logic.
2). "Does the code handle the errors properly?".
No, the code does not handle the errors properly as the code does not include any attempt at error handling.
a. "Does it need more work?/Is it great?".
The code needs more work when it comes to error handling as it has not been attempted. No, it is not great as there is no error handling.
b. "Where could it be better?".
The code could be better when it comes to ensuring the file exists, validation of user input, and ensuring that exception handling is used for I/O.
Suggestions for improvements can be found towards the bottom of the code review.
Naming issues:
There are no comments in the code which makes it difficult to know what is going on.
"Console.WriteLine("gimmiefile");" is not a good naming convention as it is not memorable.
"var z", "var q", "var s",
"var t", "var w" "foreach (var e in a)",
"int j", are also bad naming conventions as they do not explain what the varaible is and it will be confusing when you go back to the code and try to do more programming, as you won't know what the stand for or what they do.
Code Structure issues:
Code has not been put into different classes, which makes the code look clunky and hard to read.
Code has not been split up into different files and the code violates the single responsibility principle, by not doing so the code is more difficult to understand.
Error Handling issues:
The code does not check if the file exists, which means that the program will crash if the file does not exist.
No exception handling for the I/O operations on the file.
No validation of user input (examples: empty strings, invalid paths)
File Assumption issue:
Assumes file exists and that it can be read.
OOP Principle issues:
No encapsulation is used, all of the logic is exposed in the main method.
No abstraction has been used.
Output issues:
No sorting of results and poor formatting.
Program Logic issue:
No input validation or sanitisation.
Naming suggestions:
Add comments to the code so it is more understandable, readable, and maintainable. The use of comments will help you understand your code when you go back to it later, in addition to helping other people understand what is going on with your code when they look at it.
Change "Console.WriteLine("gimmiefile");" to be something more memorable. This will help as you will know what the code is meant to do if it is changed to be something more memorable/descriptive.
Change "var z", "var q", "var s",
"var t", "var w" "foreach (var e in a)",
"int j" to something more memorable. This will help you when you go back to your code as you will then know what each thing stands for.
Code Structure suggestions:
Put the code into different classes, this will make the code less clunky and easier to read.
Split the code into different files and ensure the code does not violate the single responsibility principle. Putting the code into different files will make the code more maintainable.
Error Handling suggestions:
Add error handling and check to see if the file exists. If it does not exist then ensure that the program ends gracefully.
Ensure there is exception handling for the I/O operations on the file. This will ensure that there are no errors regarding exceptions.
Validate user input to ensure that the input is what you expect from the user. This will ensure that whatever is input will not cause the program to crash.
File Assumption suggestion:
Check if the file exists and that it can be read. If it does not exist or cannot be read tell the user that it cannot be found or read.
OOP Principles suggestions:
Make use of encapsulation to avoid code being altered accidentally.
Make use of abstraction.
Output suggestion:
Sort the results. Examples: sort by frequency, alphabetically, or length.
Program Logic suggestion:
Make use of input validation to ensure the user is giving valid inputs.