Automatically Generate a GatorGrader Configuration File

[gkapfham]

Right now, the GatorGrader tool can check, for instance, if a file in a directory exhibits certain properties like a Java program containing a specific number of single-line comments.

While this feature is useful, it makes it difficult for people to learn how to create a new gatorgrader.yml file and thus it is hard for people to start using GatorGrader.

I'll add more details about this idea soon. But, for now, my suggestion is that we add a feature to GatorGrader that allows it to detect the number of entities/etc. that exist in specified files in a repository. This would allow a course instructor to run GatorGrader in "detection mode" in a solution repository and then automatically generate a starter for the gatorgrader.yml file.

Do you see what I mean, @Michionlion? Do you think that this would be a useful feature to add to GatorGrader? Do you have any feedback on the challenges associated with implementing this idea?

[Michionlion]

This is certainly an interesting idea -- I think that it would be quite useful, but it doesn't fit well into our current encapsulated functionality. Normally this kind of this would go into GatorGradle, because that's where the gatorgrader.yml file lives, but the functionality needed to generate the data to put in it would definitely fall into GatorGrader territory. I think this needs more thought, but I have a feeling that an entirely different tool would probably be a better path, rather than integrating this into either of the existing tools. The main problem to solve is kind of unrelated to either (determining what elements of a solution are important enough to warrant checks, and what level of checks), and the output is related to both.

[gkapfham]

Hi @Michionlion, yes, I see what you mean.

One quick point: the functionality to perform the detection does currently live in GatorGrader now, although it exists for a different purpose.

So, the current tool can detect how many comments exist in a Java program or how many headers exist in a Markdown file.

If we built this as another tool, would we then "call" GatorGrader somehow? Or, re-implement the functionality?

One feature connected to this idea that is definitely out-of-scope for GatorGrader is the recursive traversal of the file system, detection of file types, and the generation of a config/gatorgrader.yml file.

With that said, in conclusion, I definitely think that this type of tool/feature/plugin would really help to encourage adoption of GatorGrader.

For instance, you could imagine a Docker container that contains a program that you run in a solution repository. This would then analyze all of the code and technical writing in that repository and automatically generate a config/gatorgrader.yml of the all/many possible checks. A professor could tweak this file to produce the complete listing of checks which would go into the starter repository. Especially given the fact that we now use Docker, I am predicting that a tool like this would go a long way towards encouraging people to adopt GatorGrader?

@Michionlion, if you would like, I am open to scheduling a videochat to discuss this or other ideas further. Please let me know what might fit best for your schedule!