21–30 of 44 posts
1. View -> Task List
2. At the top of the task list click the drop-down that is by default set to "User Tasks" and choose "Comments."
You can also customize the trigger words[1]. I very rarely use the feature myself as failing unit tests are far superior when compared to TODOs.
This functionality is already built into every major OS and this new tool isn't any easier to use than the existing ones: Linux / UNIX: grep -n TODO *.js Windows: find /n "TODO" *.js
This library is also doing regex matching, so that you don't have to worry about matches that exist outside of comments... But like you said...you could always use fgrep (and most of us probably don't have "TODO" outside of comments anyways).
This TODO scanner project is completely, utterly, pointless.
I like the idea, but it's a deal-breaker if it can't parse TODOs and FIXMEs at the end of lines—that's where most of mine go.
Also, you run into problems with strings which might be a false positive
Visual Studio does this automatically. 1. View -> Task List 2. At the top of the task list click the drop-down that is by default set to "User Tasks" and choose "Comments." You can also customize the trigger words[1]. I very rarely use the feature myself as failing unit tests are far superior when compared to TODOs. [1]: https://msdn.microsoft.com/en-us/library/zce12xx2.aspx
Now what happens when you want the output in different formats? I had a person contacting me for exporting as xml since he wants to plug it in for a CI (jenkins). What if you want a JSON for your own tool?
Leasot is far from the perfect solution to TODOs, but if your use case requires anything other than simple regex, you will run into the same issues that Leasot tries to solve.
As far as speed, in my work project, parsing 552 javascript files takes around 0.2s on my mac. Some of these files being really big.
the watson[1] gem (for ruby) has a nice feature list you could go off of. leasot + some of those features might be more suitable for people who want to stay in npmland
I always thought TODO and such were a huge anti-pattern. Let's be real, these are never fixed. I always thought that you should be logging this as cards in your backlog rather than littering the codebase.
I use them primarily when developing something large from scratch. All sorts of edge cases / things that can go wrong will pop into my mind when coding a method but I don't want to get out of the flow of whatever I'm doing. In this case a simple "TODO: fix for leap years" or whatever is helpful. When I get closer to completion I will search for these and attend to them. In a production codebase, you are absolutely co…
Then it's a simple matter of grepping through the codebase for "XXX" and "TODO" and implementing the changes.
Even when starting from scratch, my usual flow is to implement the top level logic using stubs (commented with "XXX"), then go back and fill in the logic from there.
Thanks for the comments. Regarding simple `ag` or `grep` usages: Yeah, that will definitely be faster (as with git grep). The problem arises when you have false positives due to either strings, variable names or other things (perhaps template or pattern matches). Then you will need extremely good regex (which leasot implements) or be really good with filtering the results. Now what happens when you want the output in…
In short, a cool tool, which I hope you had fun creating to fill your needs, but it's not something I could personally justify using at the moment. My lint tools (for Python) and `godoc` already alert me to "XXX" and "TODO" comments, letting me see them as part of my normal programming flow.
I wouldn't expend too much effort trying to convince others of it's utility - you'll get frustrated. Instead, let the tool's utility speak for itself (if its useful to you, it will also be useful to someone else), and move on and create more useful tools.
A lot of comments here comparing it with grep or some other native CLI. I think this fares better at least on three metrics: 1. Fun to build. 2. Output looks prettier. 3. Easier to add more syntactic stuff as edge cases for different languages are factored in. Won't be too hard to extend it for github issues, for example. Since there would be very few cases of partial matches of "TODO" I think grep would still be muc…
1. thats a moot point because it doesn't explain why other people might want to use it. 2. $ alias grep="grep --color" 3. it would be even easier to extend grep via pipes. Plus pipes are langauge agnostic where as extending this tool requires knowledge of Python As a personal project, this is fine. But I really don't see the point in anyone else using it when it's slower than existing tools, no more user friendly, re…