Live data from Hacker News

Show HN: Parse and output TODOs and FIXMEs from comments in your files

github.com

11–20 of 44 posts

Re: Show HN: Parse and output TODOs and FIXMEs from comments in your files

#11
post #9

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, requires more dependancies, and isn't part of the default install like grep and find (Windows CLI) are. Plus this tool doesn't even support all instances where a TODO might appear (https://github.com/pgilad/leasot#comment-format) nor all programming languages (https://github.com/pgilad/leasot#supported-languages) like grep and find do.

Re: Show HN: Parse and output TODOs and FIXMEs from comments in your files

#14
My developer has just shown me this.

My first reaction was saying we already have that in our rails project using `rake notes`. As he mentioned, the rake task is very slow, though. It will also ignore a lot of our code which is not rails specific.

Thinking about it twice, I realized: this should be hooked to git. This allows very fast lookup and will ensure we do not search in not commited and thus irrelevant files, like logs.

I came up with this alias for git:

    todo = grep -E 'FIXME|TODO'
Formatting is nowhere near as pleasant as Leasot or `rake notes`, but it's blazing fast and relevant.

Anyway, thanks for having made us think about that :)

Re: Show HN: Parse and output TODOs and FIXMEs from comments in your files

#15
post #10

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

You probably want fgrep.

fgrep / grep -F only really comes into it's own if you have regular expression patterns that need to be matched as plain strings. "TODO" is purely alpha characters so regular grep is fine.

Re: Show HN: Parse and output TODOs and FIXMEs from comments in your files

#16
post #15

Earlier quoted context omitted.

You probably want fgrep.

fgrep / grep -F only really comes into it's own if you have regular expression patterns that need to be matched as plain strings. "TODO" is purely alpha characters so regular grep is fine.

Did not know that. Thank you.

Re: Show HN: Parse and output TODOs and FIXMEs from comments in your files

#17
post #15

Earlier quoted context omitted.

fgrep / grep -F only really comes into it's own if you have regular expression patterns that need to be matched as plain strings. "TODO" is purely alpha characters so regular grep is fine.

Did not know that. Thank you.

What did you think regular grep did, then?

Re: Show HN: Parse and output TODOs and FIXMEs from comments in your files

#19
post #10

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).

Re: Show HN: Parse and output TODOs and FIXMEs from comments in your files

#20

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 correct, you should standardize these items into a ticket manager.

Post reply on HN