ankushbhardwxj / codemon Goto Github PK

We need to add some tests for each command in codemon. This is just to make sure each command is doing the work it is supposed to. Test for each command should be written in a separate file, eg, for codemon init , create a file codemonInitDirTest.py , and so on. Also, create a single master script build.py or runTests.py which would run all the tests.

These scripts would also be useful in #44
Check example test available in the test directory

The project is currently missing the Code of Conduct file which is important for open source project
So can I go for it @ankingcodes

installation is quite buggy. Test if it works and improve if possible.

Hello maintainer, I just came across this CP template and it's really awesome!

CP Template Gist

What's your opinion??? And don't tag me this time for comment!!! Just say your review bro, and don't tag me!

Hi! This is Chilliagon. I really like this tool . I just came to know about it today
I tried to try it in today's contest , the parsing is perfect but even though i am saving it and running the command listen . It doesn't compile my program . I am working on mac. Can you please help

Contents :

• Arrays
• Vector

Arrays STL container

Arrays are fixed-size sequence containers: they hold a specific number of elements ordered in a strict linear sequence.
Arrays offer contiguous storage, allowing constant time random access to elements. Pointers to an element can be offset to access other elements. They have fixed-size aggregate, i.e., uses implicit constructors and destructors to allocate required space statically. Its size is compile time constant. No memory or time overhead.

Member functions

Iterators

• begin: return iterator to beginning
• end : return iterator to end

main()
  ll n; cin>>n;
  array<int, n> a;
  // or 
  array<int> a(n);
  for(auto &i : a) cin>>i;
  
  for( auto i=a.begin(); i!=a.end(); i++)
    cout<<*i<<endl;

  for( auto x:a ) cout<<x<<endl;

• rbegin : return reverse iterator to reverse begin (~ end)
• rend : return reverse iterator to reverse end (~ begin )

Capacity

• size : return number of elements in container
• max_size : return max number of elements that array can hold
• empty : returns a bool indicating whether container is empty

main()
  array<int,10> a = {1,2,3,4};
  cout<<a.size()<<endl; // 4
  cout<<a.max_size()<<endl; // 10
  cout<<(a.empty() ? "is empty" : "is not empty")<<endl;

Modifiers

• fill : sets val as the value for all elements in array
• swap : swaps/exchanges the content of 2 arrays or values within array

main()
  array<int> a = {1,2,3};
  array<int> b = {4,5,6};
  a.swap(b);
  cout << a; // 4,5,6
  cout << b; // 1,2,3
  a.fill(0);
  cout << a; // 0,0,0

Element access

• [] : used as a[i] or b[0]
• at : returns a reference to element at position n in the array

vector<int> a = {1,2,3};
cout << a.at(2); // 3

• front : returns reference to first element
• back : returns reference to last element

cout << a.front() << '\t' << a.back(); // 1 3

Vector STL container

These are arrays that can change in size. They are contiguous storage locations for their elements, which means that their elements can be accessed using offsets on regular pointers to its elements, and just as efficiently as in arrays. However, size can change dynamically, with their storage being handled automatically by the container.
Vectors use array that may need to be dynamically reallocated to grow in size when new elements are inserted, which implies allocating a new array and moving all elements to it.
Compared to arrays, vectors consume more memory to manage storage dynamically. The properties of this container are - Sequence, Dynamic arrays and allocator aware.

Member functions

Iterators:

• begin: return iterator to beginning
• end : return iterator to end
• rbegin : return reverse iterator to reverse beginning
• rend : return reverse iterator to reverse end

Capacity:

• size : return number of elements in the vector
• max_size : return max number of elements that vector can hold
• resize : resizes the container so that it contains n elements only.(saves space) resize reduces the size of a vector. It has an argument n, which is the number of elements the vector should contain. We can either expand or reduce the container to n elements, by filling or removing elements respectively.
• capacity : returns size of storage space currently allocated
• empty : returns a boolean whether the vector is empty
• shrink_to_fit: similar to resize but applies on capacity or allocated storage

main()
  vector<int> v(100);
  for(int i=1;i<10;i++) v.push_back(i);
  cout << v.size() << endl; // 110
  cout << v.max_size() << endl; // 1073741823
  cout << v.capacity() << endl; // 200
  cout << v.empty() ? "Empty" : "not empty" << endl;
  v.resize(10);
  cout << v.size() << endl; // 10
  v.shrink_to_fit(); 
  cout << v.capacity() << endl; // 10

Element access:

• [] : used as v[i]
• at : gets element at an index.
• front : returns first element of vector
• back : returns last element of vector

Modifiers:

• assign: useful in copying from one vector to another.

vector<int> a = {1,2,3};
vector<int> b; 
b.assign(a.begin(), a.end());

• push_back: adds a new element to the end of vector, after its current last element.
• pop_back: removes last element from the vector

vector<int> a(n); 
for(auto &i : a) cin>>i;
while(!a.empty()){
  cout<<a.back()<<endl;
  a.pop_back();
}

• insert: inserting elements at a specified position. That position is denoted by iterators.

vector<int> a = {2,10};
a.insert(a.begin()+2, 8); // 2,10,8
vector<int> b = {1,2,3};
b.insert(b.begin()+3, a.begin(), a.end()); // 1,2,3,2,10,8

• erase : removes either a single element at a position or a range of elements.

b.erase(b.begin()); // 2,3,2,10,8
b.erase(b.begin(), b.begin()+2); // 2,10,8

• swap : exchanges content of the container
• clear : removes all elements from the vector

Note: We can also assign a vector to another vector as follows:

vector<int> a = {1,2,3};
vector<int> b;
b = a;

Deque STL container

Deque (double-ended queue) are sequence containers with dynamic sizes that can be expanded or contracted on both ends. They provide functionality similar to vectors but with efficient insertion and deletion of elements also at beginning , and not only to end.
Both vectors and deques provide similar functionality, but they work in different ways: vectors use a single array that is reallocated for growth, the elements of a deque can be scattered in different chunks of storage, with the container keeping the necessary information internally to provide direct access to any of its elements in constant time and with uniform sequential interface.
Note :- For operations that involve frequent insertion or removals of elements at positions other than the beginning or end, deques perform worse and have less consistent iterators than lists and forward lists

Member Functions :

Iterators :

begin, end, rbegin, rend

Capacity :

size, max_size, resize, empty, shrink_to_fit

Element access :

[], at, front, back

Modifiers :

assign, push_back, push_front, pop_back, pop_front, insert, erase, swap, clear.

deque<int> a(n) = {1,2,3,4};
a.push_front(0); // 0,1,2,3,4
a.push_back(5); // 0,1,2,3,4,5
while(!a.empty()){
  a.pop_front();
  a.pop_back();
}
/*
Popping occured as follows : 
0 1 2 3 4 5 
1 2 3 4
2 3
NULL
*/

List STL container

Lists are sequence containers that allow constant time insert and erase operations anywhere within the sequence, and iteration in both directions. Lists are basically doubly-linked lists. The difference between list and forward_list is that forward_list objects are single linked lists and can only be iterated forwards.
Compared to other sequence containers, lists perform better in inserting, extracting and moving elements in any position within the container.
The major drawback of list and forward_lists is that they lack direct access to the elements by their position. They also consume some extra memory to keep the linking information associated to each element.

Member Functions

Iterators:

begin, end, rbegin, rend

Capacity:

empty, size, max_size

Element access:

• first : returns first element of the list
• back : returns last element of the list

Modifiers:

• assign : assign new content to container, replacing its current contents and modifying its size.

list<int> a;
a.assign(InputIterator first, InputIterator second);
a.assign(size_type n, const value_type& val);

• push_front: inserts an element at beginning
• pop_front: delete first element
• push_back: inserts an element at the end
• pop_back: delete last element
• emplace_front: construct and insert element at the end
• insert: container is extended by inserting new elements at the specified position
• erase: removes from the list container either a single element (position) or a range of elements([first,last])

list<int> a;
for(int i=0;i<=5;i++) a.push_back(i);
a.insert(a.begin()+3, 2, 20); // insert two 20 at position 3
list<int> b(19,29); 
a.insert(a.begin(), b.begin(), b.end()); // insert b in a
a.erase(a.begin()+2); // erase element at 2
a.erase(a.begin()+2, a.end()); // erase elements from 2nd position to end

• swap: exchanges contents of the container
• resize: resizes container so that it contains n elements only
• clear: removes all elements from list container

Operations:

• splice: transfers elements from x into the container, inserting them at position
  The first version(1) transfers all elements into the container
  The second version(2) transfers only element pointed from x into container
  The third version(3) transfers the range [first, last) from x into container

list<int> a; 
for(int i=1;i<=4;i++) a.push_back(i); 
list<int> b; 
for(int i=1;i<=3;i++) b.push_back(i*10);
a.splice(a.begin(), b); // (1) 
b.splice(b.begin(), a, a.end()-2); // (2)
b.splice(b.begin(), a, a.begin()+3, a.end()); // (3)

• remove: remove from container all elements that match to val. Unlike erase which removes elements by position, this function removes elements by their value.

a.remove(3); 

• remove_if: removes element from container for which predicate pred returns true.

bool is_odd(int x){
  if(x&1) return true;
  else return false;
}

a.remove_if(is_odd());

• unique: this function without parameters removes all but the fitst element from every consecutive group of equals in the container. Notice that an element is only removed from the list container if it compares equal to the element immediately preceding it. Thus, this function is especially useful for sorted lists.
  The function accepts a single argument which is a predicate or condition on which uniqueness is judged.

a.unique();

• merge : merge sorted lists. Merges x into the list by transferring all of its elements at their respective ordered positions into the container. This effectively removes all the elements in x and inserts them into their ordered position within the container. The operation is performed without constructing nor destroying any element.
• sort : sorts the elements in the list

a.sort(); b.sort();
a.merge(b);

• reverse : reverses the order of the elements in the list container.

a.reverse();

Set STL container

Sets are containers that store unique elements in a specific order. Each value in the set should be unique. They can be inserted and removed but cannot be modified. Sets are typically implemented as binary search trees.

Member functions :

Iterators:

begin, end, rbegin, rend

Capacity:

empty, size, max_size

Modifiers :

insert: extends the container by inserting new elements, returns a pair where pair::first points to either the newly inserted element is already in set. The pair::second element in the pair is set to true if a new element was inserted or false if equivalent element already exists.

set<int> a; 
a.insert(x);

• erase: removes from the set container a single element or a range of elements
• swap : exchanges the contents of set containers
• clear : removes all elements from the set container

Operations :

• find : searches the container for an element equivalent to val
• count : returns the number of occurences of val in container
• lower_bound : returns an iterator pointing to the first element in the container which is not considered to go before val(either equivalent or goes after)
• upper_bound : returns an iterator pointing to the first element in the container which is considered to go after val
• equal_range : returns the bounds of a range that includes all the elements in the container that are equivalent to val

set<int> a;
for(int i=0;i<10;i++) a.insert(i);
auto it = a.find(3);
cout << a.count(3);
auto it_low = a.lower_bound(1);
auto it_up = a.upper_bound(2);
set<int> b; 
for(int i=1;i<=5;i++) b.insert(i*10);
pair<set<int>, set<int>> ret; 
ret = b.equal_range(30);
cout << *ret.first << endl; // 30 - lower
cout << *ret.second << endl; // 40 - upper

Multi-Set STL container

Multisets are containers that store elements following a specific order and where multiple elements can have equivalent values. In multiset, elements can be added or removed but cannot be modified. They are similar to javascript objects, and exist as key value pairs.

multiset<int> a;

Member function

Iterators:

begin, end, rbegin, rend

Capacity:

empty, size, max_size

Modifiers:

insert, erase, swap, clear

Observers:

key_comp, value_comp

Operations:

find, count, lower_bound, upper_bound, equal_range
Note : All functions are similar to that of set

Map STL container

Maps are associative containers that store elements formed by a combination of a key value and a mapped value, following a specific order. Maps are implemented as binary search trees. In a map, the key values are generally used to sort and uniquely identify the elements, while the mapped values store the content associated with the key. The types of key and mapped value may differ.
The mapped values in a map can be accessed directly by their corresponding key using the bracket operator.

Member functions:

Iterators :

begin, end, rbegin, rend

Capacity :

empty, size, max_size

Element access :

• []: map[k], if k matches the key of an element in the container, the function returns a reference to its mapped value. If k does not match the key of any element in the container, the function inserts a new element with that key and returns a reference to its mapped value.

map<int, string> a;
a[0] = "ankush";
a[1] = "bhardwaj";
cout << a[0] << ' ' << a[1] << endl;

• at: returns a reference to the mapped value of the element identified with key k. If k does not match the key of any element in the container, the function throws an out_of_range exception.

map<string, int> movie_ticket = {
  { "3Idiots",0 },
  { "Baby", 0 },
  { "JollyLLB", 0 }
};
movie_ticket.at("3Idiots") = 350;
movie_ticket.at("Baby") = 400;
movie_ticket.at("JollyLLB") = 250;
for( auto x : movie_ticket) 
  cout << x.first << ' ' << x.second << endl;

Modifiers

insert, erase, swap, clear

Observers

key_comp, value_comp

Operations

find, count, lower_bound, upper_bound, equal_range

Multimap STL container

These are associative containers that store elements formed by a combination of a key value and a mapped value, following a specific order, and where multiple elements can have equivalent keys.
In a multimap, the key values are generally used to sort and uniquely identify the elements, while the mapped values store the content associated to this key. The types of key and mapped value may differ. They are generally implemented as binary search trees.

multimap<char, int> a;

Member function

Iterators

begin, end, rbegin, rend

Capacity

empty, size, max_size

Modifiers

insert, erase, swap, clear

Observers

key_comp, value_comp

Operations

find, count, lower_bound, upper_bound, equal_range

Currently we don't have a proper default template for java. This is the template that gets added to source files during init if the user does not have a custom template in ~/.codemon/ folder.

The goal is to have a sensible default template that is capable of taking care of the basic needs of the user during a competitive programming contest without having too much boilerplate.

The template can be added in the template string under default_java method of the Templates class in the CodemonMeta module.

Add a flag -java to codemon init <contestName> which would do initialisation described in #12 for java coders.

Add a flag -py to codemon init <contestName> which would do initialisation described in #12 for python coders.

"." is not a recognized command.
It gives this error on windows platform after compilation when we run the executable of cpp file.

• Add flags -py, -cpp, -java which would create a file with the extension matching to the flag and use the associate template template_<type> stored at ~/.codemon (at root).
• Add flag -t <template_name> which would create file with specified template name. If template doesnt exist, show error.
• Add functionality to fetch testcases from codeforces for a single file by intelligently parsing its contest number and problem name from the file name .

As we know not everytime questions in Codeforces rounds are A,B,C,D,E,F sometimes they are A, B, C1,C2,D, E , A,B,C,D,E,F,G , A, B,C,D, E1, E2, F etc. So initializing a generic A,B,C,D,E,F for all contests might create some inconsistencies. We need to get the correct filenames according to the contest.

Locally I have solved this by using web scraping to extract the correct names of the questions for each contest by using the contest name provided as argument to the init command.

EDIT: I would like to make a PR for this once this is reviewed by the Mentor and other conflicting PRs are merged.

I think it is important to have contributing guidelines so that an open-source contributor know how to contribute properly.
Can I work on this?

Currently only contest mode is available. Give user ability to create singular files for practice.
codemon init --practice

Can I add pull request template to this project to enhance the workflow of the repository?

When using codemon reg, empty username and password are also stored to the meta.json file.
We should use a validation here.
Also, If there is already a meta.json file, then, it overwrites the meta.json file.
We also need a validation here.

After having saved the A.cpp and adding inputs to the input.txt file, the A.cpp needs to be saved again for codemon listen to work.

we can add "codemon help" command for helping users with some simple queries regarding the use of codemon on different operating systems.
I would also like to work on it once its approved.

This would be an alternative to the webscraping problem.
There's a video on YouTube where Errichto generates test cases and inputs for his coding problems. This would be a great addition in a place where the webscraper fails.

More functionalities and macro definitions could be included so as make the coding part even easier

Codemon listen has issues in fetching correct testcases in contest folder scenario. Works fine for individual contest files.
Doesn't take input from A.in and not matching to A.op !

After merge of #55 , codemon now creates a directory for each problem, containing A.cpp, A.in, A.op and inputs,outputs are fetched from codeforces website. Therefore, we need codemon listen to fetch inputs from A.in compile A.cpp and then display the output.
As a last step, it should compare it with the sample outputs in A.op and then show if they match or not.

The codemon command works only in current repository. Make it global so that it can be used anywhere.

get a flag to create a cpp file with name given in arguments and initialise with default template.

Required to rewrite the parser to parse command arguments properly.

Currently, when compilation fails, the program proceeds to the next step by displaying the output by running the prog file which is unnecessary. Therefore if program compilation fails simply display the errors and dont proceed to display program output.

codemon init <contestName> should create directories named A, B, C, D, E, F, where each directory should contain a .cpp file for writing code, .in file for inputs for the particular problem, .out for the outputs of that problem. The directory structure is as follows:
For a contest, for example codeforces round 1353,

1353/
   A/
     a.cpp
     a.op
     a.in
  B/
  C/
  ...
  test_case.cpp (program to write testcase) 
  prog 
  test_case (generate testcases in this file)

Make sure .cpp files created uses template from ~/.codemon directory at root.
If template doesn't exist, add default template:

#include<bits/stdc++.h>
using namespace std;

int main() {
  return 0;
}

I think it is a great feature to add contributors image in README file. It really motivate to contributors. It is dynamically order the contributors.

If you want to this feature on README so I want to do this issue @ankingcodes Sir !! 😄

Create a command codemon push ( for batch) and codemon push <target> to push a batch of files or target file with a generic commit message to github

Listen command should do the following:

• It should detect changes in the filename given in argument
• It should continuously recompile and give result every time code is saved,

Follow up to this issue #12

It will be used to delete redundant files left after the contest as discussed in the issue above. We will have a lot of redundant files which will simply eat our storage.
codemon clean will clear up all the mess(prog, input.txt, testcase files) after a contest.

There is a catch to this. We can't randomly delete the mess. We can directly delete prog. But for input.txt, we must check whether it contains something, if its empty delete it else give an error message saying "Input file is not empty, do you want to delete ? (Y/N)` and user can decide what to do with it. For the testcase files, we have to "diff" them before deleting, i.e., if the testcase files had no changes in it then it can be deleted else if any kind of changes was done, they must stay.

• When inputs and outputs are written in the .in and .op files, there's an additional newline at the top of each file, which can cause problems in diffing between outputs during codemon listen, therefore, we need to avoid adding that newline either during write or be remove post write.
• Improve all verbose messages and use consistent coloring, currently, some of them are green and some are yellow, in a very inconsistent way. Maybe stick to white or some other bright colour which will be good for a basic terminal.
• Maybe get rid of codemon fetch <contestName> ? This needs discussion. Currently there are 3 ways to leverage the fetching functionality: codemon fetch inside contest directory, codemon init -f <contestdir>, codemon fetch <contestName>. The last one creates a directory with given contest name and contains only inputs and outputs and no code files. I believe we have already served that purpose with codemon init -f <contestDir>, therefore we can get rid of this command.

make a command such as codemon test <filename> which should generate testcases, run certain test program and show results in terminal.

What is this about?

I've seen some script tools and witnessed that they use some kind of ANSI based lettered logos in it. For example, run neofetch script in Linux, it'll print a vibrant colored logo made of letters. Like that, we can try to implement.

Though, it's a suggestion, it's your call to think on this and review it. So, yep. Awaiting for your reply

Currently we don't have a proper default template for python. This is the template that gets added to source files during init if the user does not have a custom template in ~/.codemon/ folder.

The goal is to have a sensible default template that is capable of taking care of the basic needs of the user during a competitive programming contest without having too much boilerplate.

The template can be added in the template string under default_py method of the Templates class in the CodemonMeta module.

• Check if an user has registered on Codemon, by checking if meta.json file exists in ~/.codemon.
• If user is registered, use the username defined in meta.json in the templates
• If user is not registered, use "@ankingcodes" as default username

The usage of os.system for calling the compilation and execution commands poses several issues we need to address, such as:

• It executes the passed command in a subshell without any control over the process. It would require < input.txt to be suffixed to the command string to send the input data to the compiled executable.
• As previously discussed in #21, it is error-prone in non-GNU systems, and also leads to errors with file/directory names with special characters and whitespace.
• All we have access to is the return value once the process has finished executing. We can't examine or control the flow of data in stdin and stdout. It would also help if we want to automate the verification of right output to the given input.

The compilation command-executing strategy should therefore be migrated to subprocess, which is supported by the following points:

• We control the flow of data into stdin and out of stdout i. e. We read the data from input.txt, pass it into the subprocess call, obtain the data sent to stdout and format and display it as desired. It enables us to choose i. e. Define custom stdin and stdout for the subprocess call.
• Instead of executing the command in a subshell, a child process is created and executed, which is a safer and more efficient choice.
• Unlike os.system, we have access to a lot more than just the return value. We receive an object for the subprocess, whereafter we can choose to wait for it to finish or continue. We can communicate with the subprocess during its lifetime.
• We wouldn't need to worry about issues with quoting parameters that would contain special characters and/or whitespace, because a call made using subprocess would require the parameters to be provided in a list.
• It would be convenient to handle the absence of gcc/g++ in PATH as well as improve the handling of #25.

I would like to work on the issue, if approved.

Add a command codemon reg which would ask for Name, Codeforces username, password, Github username, Github password, Github competitive programming repository URL etc. which would be saved at a directory named .codemon by the filename meta. Also, add custom templates by the name of template_py, template_cpp, template_java inside the .codemon folder.

Currently, Codemon is only supporting a fixed amount of code files being generated per contest.
As evident for now, codemon just supports 3 practice files (which is okay), and 7 contest problem files (A-G, assuming one file per question in a contest, which does not always needs to be valid).

As per the current numbering and naming conventions for problems, it seems like codemon is well-adapted with the current cases of coding rounds in platforms like CodeForces, AtCoder, etc. While this can work with such contests for now, the problems may arise in cases when there are more than 7 contests in a competition (such as CodeChef Long Challenges, which feature 10 problems per challenge).

It'd be great if these counts of 3 and 7 problems per contest are kept as a default count, and codemon init gets an option to manually enter the problems count we'd like to generate using some flag for count. This would be handy for platforms other than CodeForces, which are not retrieved over web scraping for now.

Of course, to prevent misuse of the count flag (like passing in a very large value that keeps the files generating and filling up a lot of unnecessary memory), upper limit can also be included for the same. Please feel free to comment for any more details needed for the same.

The tool should get the current url in the browser and get the inputs to a question automatically.
We need to support this for codeforces atleast.

Opening this on the request of @ankingcodes . It would be helpful to have an automated CI system that can test all PRs for proper coding style (proper indentation and other python standards) and merge/reject them based on the results.

Can I make issue templates to enhance the workflow of the repository?

It would be great if we could add our custom templates that we generally use, as most of the programmers use their own templates, which vary. So if a template path is specified, then codemon should load that, else the default template is used.

• Add a command codemon test <problem_name> to run diff between output of particular program and testcase generated output.
• Add codemon push to push to git repository using git username and password available at ~/.codemon/meta.

in linux the file save two times thats why we have two output .

A better fix for this would be to fetch template corresponding to file extension (cpp, java, py) from a directory .codemon/templates/ (note the ., since its hidden) from root directory (~/).

Command : codemon fetch inside contest directory.

• Check if the current working directory is a contest directory ? If not, display error message to cd into a contest directory.
• Parse the contest number from the directory name, if contest number is not parsed, display error message to rename directory with the contest number i.e., if contest round is Codeforces Round 1234 then directory should be named 1234 or maybe round1234. Contest number should be present mandatorily.
• Alternately give user option to add contest name as codemon fetch <contestName> .
• After getting the contest number, go to Contest URL (https://codeforces.com/contest/1234/problems), scrape all inputs and outputs and store in respective question folder. For example, inputs and outputs of problem A should be stored in A/a.in and A/a.out respectively.

Currently, the help message is very unstructured and includes long descriptions. This issue involves rewriting the help messages to something short and concise while maintaining a balanced structure.
The help message can be seen on typing codemon or codemon --help.

           ---CODEMON---
A CLI tool to ace competitive programming contests

COMMANDS:

codemon - - - - - - - - - - - - - - -  displays this message
codemon --help - - - - - - - - - - - - shows help
codemon init <contestName> - - - - - - initialises a contest
codemon fetch <contestName> - - - - fetches all the sample test cases for the contest name provided
codemon fetch  - - - - - - - - - - - extracts contest name from contest directory name and fetches all sample test cases
codemon init -n <file> - - - - - - - - creates file with given name
codemon listen - - - - - - - - - - - - compiles and gives output
codemon reg - - - - - - - - - - - - -  Register user details
codemon practice <dirName> - - - - - - Starts a practice session

To streamline the development process and prevent any future conflicts from happening, it might be a good idea to add clear and concise Contribution guidelines and Code of Conduct to the documentation of this repo, specially in light of the recent PR conflicts that happened.

Some example guidelines we can add for contributors:

• Make short and concise PRs that handle one issue at a time as they are considered good practise and are easy for the mentor to test and integrate into the project.
• Specific to this repo and nWoC, no issue opened by the Mentor will be assigned to anyone and that only self opened issues, if approved by the mentor, will be considered assigned since this is a competetive program.

etc etc.

We can also include Coding Style guidelines (indentation rules etc).
All this can prevent future conflicts and might help the project greatly.

@ankingcodes If you're interested in this suggestion I can make PRs to help add the necessary documentation to the project.