-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Code Review #1 #13
Comments
I second everything @Danc2050 said! Since there is not a lot for me to test yet, I am going to focus on some higher-level issues: README
Testing
General
Please let me know if you have any questions. |
All looks good in @tdulcet 's comments as well. The only thing I would reemphasize is that during our voice talks (which Teal could not make) I did not require a testing framework to be chosen. That being said, it could potentially help, so that one is definitely up to you. |
Summary
Overall, it looks like a decent start. Some pieces are starting to form as it looks like you all have divided up some of the features to work on. Connecting them and organizing your code structure so you can properly test them will be helpful steps. I apologize in advance that this is so long, but I also apologize if I missed anything (I moved from my local machine editing files, to using GitHub issues).
Specific File Code Reviews:
README
README
with every single detail, since a lot of things can change and you are wasting time + work, but I think you guys know enough at the present moment to add how to run the basic program (e.g.,python3 __main__.py -S [script_name]
) and also to talk about what the project is about. You may also decide to include the help menu for your__main__.py
as well. If one person updates the README, all 6 other people on the team (plus us sponsors) will know how to run the program.debugLogFile
config_files/
andcloud/config_file
?) by default. In other words, there shouldn't be a function that writes the config file each time, as it should exist in perpetuity. I don't know how well your current config library works, but you may check out configparser to update.ini
files if it is easier for you. I will try and verify all the config files that need to exist when you guys develop your requirements doc further.UserScript
main.py
or__main__.py
..format()
(see this f-string article for a discussion on performance). I think this should work as a substitute:print(f'{self.scriptName} did not exit gracefully, Submit a Bug!"')
.executeUserScriptTests
Tests/
folder. Please also note that you should have some sort of CI (e.g., Travis CI) to run these tests on each push to make sure the output is correct.text
in Python 3.6+. See, and reference in the future, the updated documentation. The same is true for this function https://github.com/ismustachio/TheBugTracker/blob/b97d43fe15460ec1de2c1037d0d43b228f969c33/executeUserScriptTests.py#L15-L21.filterLists
autobug
software. Or potentially you could file a bug in theIssues
of their repo.print
statement if it is aWARNING
. Otherwise, sayERROR
and halt the program like you do.self.bugs += [item for item in self.white_data if item not in self.bugs]
. However, I am confused. Is the blacklist bugs you don't want to capture and the white list bugs you do want to capture? 1) You already added in any bugs that were not in the blacklist... I think this is enough and you don't need a white list? Anything else, by default, should be sent as a bug, since the repo owners don't know about it to put it on the Black List. I am sorry if I misled you when I was suggested white lists or black lists. Even if this wasn't an issue, you are adding in all bugs in thewhite list
if they aren't in theself.bugs
array (i.e., when they aren't in the bug output, you are adding them)? I think you wantin self.bugs
notnot in
.in
keyword may get you in some trouble when there is similar output that is not a bug. If anyone is good at regex, they should maybe brainstorm how to use that to find bugs in code, but at the moment its an okay start.file
notarray
here https://github.com/ismustachio/TheBugTracker/blob/b97d43fe15460ec1de2c1037d0d43b228f969c33/filterLists.py#L43."".join(line) + "\n"
?.read_config
__init__
.https://github.com/ismustachio/TheBugTracker/blob/b97d43fe15460ec1de2c1037d0d43b228f969c33/read_config.py#L18 to an f-string for performance.
read_config_test
tests
directory.test = os.path.join(Path.home(), BUGTRACKER)
. The RHS of the equal sign is repeated multiple times in the code. Make it a global or put it in thetestInit
class and reference it from this line on when needed.os.remove
, which can just be called at the end, outside bothif
andelse
functions.os.remove
here https://github.com/ismustachio/TheBugTracker/blob/b97d43fe15460ec1de2c1037d0d43b228f969c33/read_config_test.py#L53-L58. Also present on line 85,88.test
to be. Please also make line 53 less confusing and just sayif test
. Also you can say on line 62,if not test
.General Issues/Comments/Suggestions
Feel free to take the feedback with a grain of salt and ask questions.
Cloud
).init
functions. You should also have a doc string at the top of every file to indicate its main purpose.check_output
is a fine function, but you may actually find thatPopen
will be more useful for your cases. You can get stderr, a return code, etc. more easily this way. See a good intro to this function here. You can actually check theSTDERR
specifically for potential bugs and avoid (or use less) the checking of standard output.Let me know if I can be of any help in clarifying any of the above or answering any more questions.
The text was updated successfully, but these errors were encountered: