If you're not sure what a script does, you're better off not running it until you are sure what it does. Ways to reduce the damage radius of a bad script include running it using a new user, running it in a container, or running it in a virtual machine. But that first statement still holds: If you're not sure what something does, consider not running it until you do.

As @ctt said, it's probably a good idea to run it in a sandbox of some kind first. Using a VM is probably the easiest solution. Multipass is pretty simple.

Install multipass (assuming you haven't already):

sudo snap install multipass --beta --classic

Spin up a new VM:

multipass launch --name myvm

Login to your new VM:

multipass shell myvm

Then run your script (inside your vm):

multipass@myvm:~$ git clone https://github.com/jgigault/42FileChecker ~/42FileChecker && cd ~/42FileChecker && bash ./42FileChecker.sh

As the school you are attending has published the scripts, the best place to voice your concerns is with your instructors.

That said we can help you decipher the code on a line by line basis. It is probably impractical for anyone here to analyze all the code.

You actually have 40 bash scripts with a total 5,360 lines. I've combined them together and looked for bash/shell commands that could be abused. They all appear to be used normally:

$ cat /tmp/sshellcheck.mrg | grep " rm "

      rm -rf "$RETURNPATH"/tmp/*
      rm -f "$RETURNPATH"/.mynorminette
    rm -f $LOGFILENAME
    rm -f $LOGFILENAME
      rm -f .mymoulitest
        rm -f "${RETURNPATH}/tmp/${FILEN}"

$ cat /tmp/sshellcheck.mrg | grep -i kill

  function check_kill_by_name
          kill $PROCESSID0
  declare -a CHK_MINISHELL_AUTHORIZED_FUNCS='(malloc free access open close read write opendir readdir closedir getcwd chdir stat lstat fstat fork execve wait waitpid wait3 wait4 signal kill exit main)'
        check_kill_by_name "${PROGNAME}"
      kill -0 "${CURRENT_CHILD_PROCESS_PID}" 2>/dev/null && kill "${CURRENT_CHILD_PROCESS_PID}" 2>/dev/null
      display_error "killed pid: ${CURRENT_CHILD_PROCESS_PID}"
    check_kill_by_name "$PROGNAME $PROGARGS"
        check_kill_by_name "$PROGNAME $PROGARGS"
        kill ${PID} 2>/dev/null

$ cat /tmp/sshellcheck.mrg | grep -i root

      "check_configure_select ROOT" "Root folder:          /"\
      'ROOT')
        echo "'${ALLOWED_FILES}' must be placed at root folder but was found here:" >>"${LOGFILENAME}"
        printf "%s" "'${ALLOWED_FILES}' must be placed at root folder"

$ cat /tmp/sshellcheck.mrg | grep -i sudo

$ 

• There is no rm -rf / command to wipe the whole hard disk partition.
• There is no requirement that sudo be used to run the script.
• The script actually makes sure only authorized C functions are used in the files checked.
• A quick browse of the bash/shell code shows it is professionally written and easy to follow.
• Using shellcheck on merged include files reveals only three syntax errors.
• Author names are identified and the main author even has his picture on his github page.
• Although there are no guarantees in life, 42FileChecker appears safe to use.

It's not human-readable bash scripts you need to worry about so much. It is compiled binary objects you cannot read that are cause for concern. For example a program called "shiny-bouncy-sphere" might paint something like that on your screen but in the background it could be erasing all your files.

Original answer

It is best to ask the author of the script what it does. Indeed you can almost post your question verbatim as it appears above.

Also ask the author:

• What files are updated?
• What happens if crash due to power failure or program bug?
• Can a mini-backup be performed first?

And any other good questions you can think of.

Edit 1 - Worries about a malicious author.

You should only use software with lots of good public reviews. Alternately authors you trust here in Ask Ubuntu like Serge, Jacob, Colin King, etc. Other respected sites like Ask Ubuntu and their respected members should also be considered "non-malicious".

The advantage of "respected authors" here in Ask Ubuntu is they stake their self-worth on "reputation points". If they were to intentionally write code that "stole" or "damaged" data they would quickly loose their reputation. Indeed authors could suffer the "wrath of mods" and being suspended and/or having 10,000's of reputation points taken away.

Edit 2 - Don't follow all the instructions

I took a deeper look into your bash script instructions:

git clone https://github.com/jgigault/42FileChecker ~/42FileChecker &&
    cd ~/42FileChecker &&
    bash ./42FileChecker.sh

The "safe" method is to only run the first line:

git clone https://github.com/jgigault/42FileChecker ~/42FileChecker

This downloads the scripts but doesn't run them. Next use nautilus (file manager) to inspect the directories and files installed. Very quickly you discover there are a collection of bash scripts written by a group of students in France.

The purpose of the scripts is to compile and test C programs for improper functions and memory leaks.

You can use Docker. Docker containers are isolated from the host OS, so any malicious activity will stay within a container, as long as you don't specifically let it out by forwarding ports or mounting filesystems.

To install docker:

sudo apt-get install docker.io

To download a new Ubuntu Bionic container:

docker pull ubuntu:bionic

After that, log into the container

docker run -it ubuntu:bionic

and perform the dodgy operation in it:

git clone https://github.com/jgigault/42FileChecker ~/42FileChecker && cd ~/42FileChecker && bash ./42FileChecker.sh

I'm no expert at this, but I would recommend using strace and docker.

So first create a Docker container as by the instructions in this answer. But the addition being that strace will tell you what system calls are made. Or to quote:

strace is a diagnostic, debugging and instructional userspace utility for Linux. It is used to monitor and tamper with interactions between processes and the Linux kernel, which include system calls, signal deliveries, and changes of process state.

You can combine these commands to

docker exec -it ubuntu_container strace bash ./42FileChecker.sh

Consider using the debugging mode by running the script as:

$ bash -x scriptname

Further useful Bash information

The debugging mode will not stop the script from doing something bad, but it will let you go through the script line by line and examine the effects. You might also check the script for some common potential mistakes and/or exploits, e.g. search the scripts for any occurrence of rm and look at those commands very closely. Many of these tools have some help built in for trying them out, e.g. rm will not delete a directory by default, it needs the -r, -R, or --recursive option to do so.

There may even be some antivirus-like tools that would search a bash script for these patterns, but I'm not aware of any by name. Your example scripts are sort of extra iffy, in the sense that they download other tools, so each of those should also be examined. Checking which servers they contact may also be worthwhile.

The relevant information to provide an answer is unluckily only found in a comment of yours:

I'm learning C in the Ecole 42 course. The functions I'm making needs to run through this norme check. I need to install the 42FileChecker in Ubuntu to run this norme check.

So the situation is that in practice you have the option of skipping the course, or you can run the script to perform normative checks on your sources. Talking with your instructor is hardly an option, due to lack of the former (it wouldn't be an option otherwise anyway, no school is going to change their procedure because one student isn't happy with it).
The question what to do to limit possible damage from that script therefore doesn't even arise. It's not a random script that a horny girl with large breasts e-mailed to you, and which you need to run to see her picture.
You're doing a programming class. This is where this script came into play. The question is whether or not you want to comply with the frame conditions for successfully completing the course.

However, if you are truly worried, there's still the possibility of running the script in a container or a virtual machine, and put your sources in a shared folder, or onto a network share exposed by the container/virtual machine. That's pretty much going the full paranoia path, but then again virtualization isn't really all that complicated these days, so it doesn't cost an awful lot.

Barring the unlikely possibility of a really harsh exploit being contained in that script, logging in as any non-root user (which you have hardly a choice of doing otherwise on Ubuntu) and avoiding to type sudo for no obvious reason pretty much prevents 99% of all bad things that could possibly happen anyway. Such as formatting the harddisk, which you are worried about. A normal user just cannot do that. Worst thing to happen is the script erases the user's home directory. So what, no issue, really.