Static testing really is an excellent tool!
For this lab, we were tasked to set up a linter and code formatter for our link checkers, making sure they are set up for their respective languages. To get my program tools working, I chose to use Flake8 (which is a linter tool to help determine syntax issues) and Black (a tool that is handy in implementing a standard style to Python source code, making it easier to read).
This was a fairly straight-forward exercise once reading up on the material of each of the tools. Installing the necessary packages was a breeze, and then all that was left was to create the files necessary to run it any way the user saw fit (whether calling the command on the file or running the script files in the repo).
For Flake8, I was required to create a bash script file (which I named lint.sh) that contained a singe line of code to run the command on my main Python file (checkMyURL.py). Another file (.flake8) was needed to lay out the configuration of the project. As of right now, I only found it necessary to set a maximum length for each line (max-line-length) as well as which files to exclude from being "linted".
A similar setup for Black was needed to get the code formatted. The first file that I wrote up was another bash script (saved as format.sh), this time calling the 'black' command against my Python file. Alongside that, I also needed to create a file (pyproject.toml) that specified the files that were not to be formatted, along with the line length I preferred (to match the value set for Flake8).
Once those two functions were settled and working as intended, I proceeded to set up the necessary file to assist users that were utilizing VSCode for contributing to this project. After finding out the proper way to implement the features needed, I created a settings.json file within a new folder named '.vscode'. Within this JSON structure, I laid out the commands that forced the linter and formatter run on the source code at every point they saved their work.
As I was running these commands, the main issues that were discovered consisted of:
1) Lines of code that extended too far, and
2) An improper use of escape characters within regular expressions.
The length of the lines was easy enough to take care of. If the formatter (Black) didn't handle all of the lines, I had to decide the most reasonable (and readable) way to break up these lengthy lines. The second issue took a little bit of time to find the answer, but the fix was relatively simple. With the regex that was within my program, there was not character preceding the quotation marks to specify that this was, indeed, a regular expression. To fix this, I only needed to place the letter 'r' just before the quotes.
While I felt my source code was written to a decent standard in my eyes, it became obvious that the end result was not ideal for all setups. The few line lengths that went beyond the prescribed 88 characters would obviously make it difficult to read if the user happened to be viewing the file in a smaller window. As for the regular expression issue, I became aware that, while it MAY run without the specification attached to it, there was a chance that there would be a problem.
All in all, these tools will make it easier for me to program in the future, now that I can take a little les time having to format as I go!
Comments
Post a Comment