ignacio-chiazzo / algorithms-leetcode-javascript Goto Github PK

Pick a problem in Leetcode or any other platform.

If you find a solution, follow the next steps:

Open A PR that contains:

1. Solution in a file with a description of the problem at the top.
2. A test file with some test cases. The test file must export a test() function which will run all the tests of the file.
3. An entry of the problem in the list of solutions within the README file.

PR Example: #39

If you don't find a solution but want to discuss a problem, I would be happy to! In that case, please submit an issue.

The current repository uses a Github Action for running linters Github workflows

Add the option to run the linter locally by running commands. Optionally we can combine unit tests and lint and run them all in one command. There are also a few tests failing that should be updated.

It would be nice to add JS linters. Something basic to detect identation, spaces, and a few JS red flags

We often have to request changes to PRs due to tests not being present or an entry to the readme isn't added.

I suggest we create a unit test that:
1- reads all the problem names and asserts there is a file for testing. We can do that by inspecting the problem's name and asserting there is a corresponding ${file_name}_test name with assert_ methods.
1- Reads the README and asserts there is a link to the problem created. This one is less important than the previous one.

Thoughts @hot9cups ?

This is in response to the comment from my last PR.
I've been experimenting ever since, and I think there's a way it could be achieved.

What we want to do:

1. For every problem, if we have multiple solutions, then we would like to have multiple test functions, one for each solution. This should help in debugging as well as is a cleaner and more maintainable way of writing code. We should also be free to name our test functions anything, as opposed to the rigid and undescriptive names(test or in some cases test1, test2, etc) we have right now,
2. We want to modify Tests.js to be able to handle the test imports dynamically. Right now we hardcode it to invoke the test function as can be seen here. We want to get rid of this hardcoding as well as be able to invoke varying number of tests per test file as opposed to being able to invoke just 1 test per test file currently.

After having explored some of the options Javascript offers, I have found a solution to do this.
I'll be happy to work on the PR if you'd like to assign the issue to me.

Create a better pattern for problems:

• Make sure each object implements its main function and export it.
• Don't stop the main if any of the classes didn't implement the function
• Put a warning with red letters whenever a problem wasn't added a main function
• Fail test if a class doesn't implement main function an export it?

Create a structure for every problem like this? :

/* 
@param {string} a
@param {number} b
*/

var problemName = function(a,b...) {...}

var testCases = function() {
    console.log(problemName(...));
}

var main = function() {
   // print  something useful if needed
   testCases();
}

module.exports.main = main;

Doing so will help contributors to find unsolved problems easily

    another solution that doesn't require translating the integer to a String would be to 

get the number, divide it by 10, get the digit and repeat the process.

Originally posted by @ignacio-chiazzo in #57 (comment)