You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hey everyone! I just arrived here at this repo and would love to contribute a bit :)
Looking at the code organisation and the test setup, it's rather confusing for newcomers right now. Should we discuss those cross-cutting things a bit and then decide the direction going forward? Here's a few ideas - feedback very much welcome:
Ideas
Code structure: Maybe we could define a "template" for code/algorithm files that new code should follow and/or existing code could be migrated towards. Some things to keep in mind, though:
Implementation files (modules?) should adhere to a common structure (e.g. ESM)
Implementation code should be stateless (i.e. it should be possible to call the implementation multiple times without side effects between test runs)
Algorithm implementation should refrain from outputting to the console
... (ideas welcome)
Chores: Automatically running tests and code style checks in the CI is a bit funky right now ;) Mostly due to the fact that there's both Jest and doctest in the mix, of course. However, there's more to do: npm dependencies are outdated, Node.js will have v16 as LTS version starting this October, etc. etc. etc.
Full switch to ESM: Add "type": "module" to our root package.json.
Test setup: There should be just one solution for testing. Do we want to use doctest going forward? Or do we want to use Jest? But keeping both is a source of confusion and will eventually lead to degrading code quality / clarity. (This is basically the attempt to revive the discussion in #142 even though I'd prefer and strongly recommend Jest)
Maybe cleaning out unused dependencies from package.json ?
As this thing does not have or need a runtime environment, all used dependencies should be in devDependencies ?
Maybe adding husky and a pre-commit hook, running standard --fix . could lower the noise ?
Maybe we could even get rid of the job that auto-updates the directory markdown file on a pre-commit basis? (hint, hint: I just improved that one with 2dc8ead...5283a41 but maybe it's even nicer to have it run as a pre-commit hook)
Test setup: There should be just one solution for testing. Do we want to use doctest going forward? Or do we want to use Jest? But keeping both is a source of confusion and will eventually lead to degrading code quality / clarity. (This is basically the attempt to revive the discussion in #142 even though I'd prefer and strongly recommend Jest)
We do have testing problems because doctest does not provide a mechanism to ignore files. Removing them may be a good idea.
I am not a fan of removing tests unless we are replacing them with something equivalent if not better. Let's make sure that we have more tests, not fewer tests.
Maybe we should also add some guidelines about file naming convention. For example in Project-Euler directory, we got :
Problem013.js
Problem1.js
Problem10.js
Problem2.js
etc.
I suggest the following strict naming convention : ProblemXXX.js where is XXX is the problem number, left-padded with zeros, so that the lexicographic order fits the problem numbering order :
Removing (some of) these logs is not as trivial as it sounds, for example the alogrithm for AllCombinationsOfSizeK.js does not return anything but log combinations as they are found (recursively), so we can't just replace console.log by a return statement but need to revise the implementation somehow.
Also, some logs give useful hints about how to implement the algorithm, and for those not being covered by Jest tests, it might be the only hint a developer/student can find at first glance.
For these reasons, log removal is probaly a more tedious task than it seems, so I suggest creating separated issues for covering :
The conversion of all live code into Jest tests (removing code chunks living outside a module).
Revise all algorithms that log their results instead of returning them (removing logs inherent to a module + fix that module if necessary).
I'm new and would be happy to contrbute, so feel free to assign some tasks to me !
I'd argue that it should be quite easy to remove console logging from most implementations and simply return results.
For the few cases where the intermediate hits are part of the overall result, there are ways, too: Either collect all intermediates in a variable and return that once recursion finishes up or provide some kind of "sink" callback that gets called with each intermediate value. This "sink" can be passed in, too. Which means in a test, we could just pass in a jest mock function and check the values that got thrown into it.
Example:
// algorithm. counts up to (not including) max, calling sink with each valuefunctioncountUpTo(max,sink=value=>console.log(value)){for(leti=0;i<max;++i){sink(i);}}// testdescribe('countUpTo',()=>{it('should call the sink fn with the correct values',()=>{constsink=jest.fn();countUpTo(3,sink);expect(sink.mock.calls.length).toBe(3);expect(sink.mock.calls[0][0]).toBe(0);expect(sink.mock.calls[1][0]).toBe(1);expect(sink.mock.calls[2][0]).toBe(2);});});
If someone imported this function e.g. in a manual test and simply only did countUpTo(3), the default parameter would kick in and the values will get printed to the console.
This issue should be fixed by PR #768 which is ready to merge since 2 days (I can't remove the in progress label). @raklaptudirm is asked for review but there are a lot of (small) changes so do not hesitate to throw an eye @cclauss@defaude.
Thank you by the way @defaude for the recommandations you made on this, it definitely helped.
Activity
trasherdk commentedon Oct 4, 2021
Maybe cleaning out unused dependencies from
package.json?As this thing does not have or need a runtime environment, all used dependencies should be in
devDependencies?Maybe adding
huskyand a pre-commit hook, runningstandard --fix .could lower the noise ?defaude commentedon Oct 4, 2021
That sounds like a nice idea! 👍
Maybe we could even get rid of the job that auto-updates the directory markdown file on a pre-commit basis? (hint, hint: I just improved that one with 2dc8ead...5283a41 but maybe it's even nicer to have it run as a pre-commit hook)
raklaptudirm commentedon Oct 5, 2021
@cclauss
cclauss commentedon Oct 5, 2021
An example of this template would be good to see and would spark deeper conversation. I am not sure that idempotency is required for all algorithms. Some of these ideas could enhance the notions expressed in...
https://github.com/TheAlgorithms/Javascript/blob/master/CONTRIBUTING.md#what-is-an-algorithm
raklaptudirm commentedon Oct 5, 2021
Currently, this repository encourages ESM. If you find files which obey other module systems, please create a list of them to be fixed.
Again, if you find algorithms with state, create a list in this issue.
Same as above.
raklaptudirm commentedon Oct 5, 2021
We do have testing problems because
doctestdoes not provide a mechanism to ignore files. Removing them may be a good idea.raklaptudirm commentedon Oct 5, 2021
We can also add codespell as a github action for checking spellings.
defaude commentedon Oct 5, 2021
So you're saying all tests should be written in Jest? (Which I'd totally vote for)
cclauss commentedon Oct 5, 2021
I am not a fan of removing tests unless we are replacing them with something equivalent if not better. Let's make sure that we have more tests, not fewer tests.
Issues related to jest... https://github.com/TheAlgorithms/Javascript/search?q=jest&type=issues
raklaptudirm commentedon Oct 5, 2021
@cclauss We are removing only the
doctests, and keeping all thejestones. How does that sound?defaude commentedon Oct 5, 2021
Agreed. Removing tests is the wrong thing to do. We should migrate doctests to Jest instead!
raklaptudirm commentedon Oct 5, 2021
So, we should migrate everything to
jest? Any issues with that?2 remaining items
raklaptudirm commentedon Oct 8, 2021
I will try to get some progress on tracking the non ESM files.
raklaptudirm commentedon Oct 8, 2021
requireandmodule.exportsfound in:raklaptudirm commentedon Oct 8, 2021
A List of algorithms that output to the console (the list is too long for me to format sadly):
lvlte commentedon Oct 8, 2021
Maybe we should also add some guidelines about file naming convention. For example in Project-Euler directory, we got :
I suggest the following strict naming convention :
ProblemXXX.jswhere is XXX is the problem number, left-padded with zeros, so that the lexicographic order fits the problem numbering order :lvlte commentedon Oct 8, 2021
Removing (some of) these logs is not as trivial as it sounds, for example the alogrithm for
AllCombinationsOfSizeK.jsdoes not return anything but log combinations as they are found (recursively), so we can't just replace console.log by a return statement but need to revise the implementation somehow.Also, some logs give useful hints about how to implement the algorithm, and for those not being covered by Jest tests, it might be the only hint a developer/student can find at first glance.
For these reasons, log removal is probaly a more tedious task than it seems, so I suggest creating separated issues for covering :
I'm new and would be happy to contrbute, so feel free to assign some tasks to me !
raklaptudirm commentedon Oct 8, 2021
@lvlte You can open a new pr and start implementing the changes now.
lvlte commentedon Oct 8, 2021
Ok, I will start working on this tomorrow. Thanks
defaude commentedon Oct 8, 2021
I'd argue that it should be quite easy to remove console logging from most implementations and simply return results.
For the few cases where the intermediate hits are part of the overall result, there are ways, too: Either collect all intermediates in a variable and return that once recursion finishes up or provide some kind of "sink" callback that gets called with each intermediate value. This "sink" can be passed in, too. Which means in a test, we could just pass in a jest mock function and check the values that got thrown into it.
Example:
If someone imported this function e.g. in a manual test and simply only did
countUpTo(3), the default parameter would kick in and the values will get printed to the console.defaude commentedon Oct 8, 2021
... but of course that's always a bit tricky: find out where / how to pluck stuff like this into an existing algorithm ;)
lvlte commentedon Oct 13, 2021
Hi there,
This issue should be fixed by PR #768 which is ready to merge since 2 days (I can't remove the
in progresslabel).@raklaptudirm is asked for review but there are a lot of (small) changes so do not hesitate to throw an eye @cclauss @defaude.
Thank you by the way @defaude for the recommandations you made on this, it definitely helped.
defaude commentedon Oct 14, 2021
Sorry for being so quite. Life happened... ;) I'll take a look right away.