To understand the purpose of this project in the context of the exercism submission platform, there are a few documents to review:
- Introduction to Representers
- Creating a Representer
- The Representer Interface
- How to normalize representations for the highest efficiency
- Docker image build and deployment
Code analysis is tough, and the programming required to create them is complex. Initially the goal of the exercism platform was to provide automated analysis on a wide scale. But while this proved to be successful at a small scale (for now), it also served to prove how complex they are.
So rather than attempting to provide automated analysis, we attempt to normalize submissions to distill the solutions to the general approaches taken, provide feedback on the normalized subset, then memoize the feedback so that when a recongnized solution pattern is submitted, feedback can be replayed from the previous submissions.
The role of this service is to take a code submission, and normalize it in the following ways:
- format using
mix format, enforcing do...end blocks - removing comments
- normalizing
@docand@moduledocdocumentation - normalize module, variable, function names and maintain a mapping from the original to the placeholder names
- this is done by analyzing the source using the ast representation to find the names to replace
- then doing a textual find/replace on the source using the mapping
lib/representer/cli.ex
This is the entrypoint for an escript to process the relevant files from the command line.
Some of the tests depend on the /elixir git submodule. Run git submodule update --init --recursive once after cloning this repo to also get the submodule.
To check at which commit the submodule is, run git submodule. To update the submodule to the newest commit, run git submodule update --remote --merge.
The submodule is used only by the tests.