Show HN: I transformed my library into a Node and 100% coverage and Travis tutorial
1–10 of 19 posts
Re: Show HN: I transformed my library into a Node and 100% coverage and Travis tutorial
#2I like it.
It's pretty well documented. Rare thing today IMHO
Re: Show HN: I transformed my library into a Node and 100% coverage and Travis tutorial
#3Hey I'm actually working on a web app to allow people to keep up with a ton of RSS feeds remotely.
I was thinking since it seems like something you could be interested in it would be great if you check it out and possibly give me some feedback.
# where I found your post http://webarcs.com/?open=27311
Re: Show HN: I transformed my library into a Node and 100% coverage and Travis tutorial
#4I like it. It's pretty well documented. Rare thing today IMHO
Don't want to start an argument but perhaps why it's rare to see is because many people realise commenting on code as a rule leads to: https://twitter.com/nzkoz/status/538892801941848064
Commenting on the purpose of a file is reasonable, as it explaining why a piece of code works the way it does e.g. if an external constraint is in play. But explaining how in code comments is redundant if the code is well written and the functions and variables are well named.
Re: Show HN: I transformed my library into a Node and 100% coverage and Travis tutorial
#5Couldn't you have used the Wiki instead of issues? Great work though!!
Re: Show HN: I transformed my library into a Node and 100% coverage and Travis tutorial
#6It's great -- it's 87 LOC though. And don't forget: coverage is tested in terms of LOC, not in terms of program states.
Re: Show HN: I transformed my library into a Node and 100% coverage and Travis tutorial
#7Couldn't you have used the Wiki instead of issues? Great work though!!
I don't know, I just don't like Github wikis. I find issues to be more "social".
Re: Show HN: I transformed my library into a Node and 100% coverage and Travis tutorial
#8I like it. It's pretty well documented. Rare thing today IMHO
Don't want to start an argument but perhaps why it's rare to see is because many people realise commenting on code as a rule leads to: https://twitter.com/nzkoz/status/538892801941848064 Commenting on the purpose of a file is reasonable, as it explaining why a piece of code works the way it does e.g. if an external constraint is in play. But explaining how in code comments is redundant if the code is well written and…
Totally agree! But basically this is a tutorial.
Re: Show HN: I transformed my library into a Node and 100% coverage and Travis tutorial
#9It's great -- it's 87 LOC though. And don't forget: coverage is tested in terms of LOC, not in terms of program states.
Hmm this seems to be a very nice knowledge. Would you mind explaining it a bit further?
Re: Show HN: I transformed my library into a Node and 100% coverage and Travis tutorial
#10I like it. It's pretty well documented. Rare thing today IMHO
Don't want to start an argument but perhaps why it's rare to see is because many people realise commenting on code as a rule leads to: https://twitter.com/nzkoz/status/538892801941848064 Commenting on the purpose of a file is reasonable, as it explaining why a piece of code works the way it does e.g. if an external constraint is in play. But explaining how in code comments is redundant if the code is well written and…
I'd mention one exception: when you're doing something very complicated in a single function. For instance, I recently had to write an algorithm that involved partitioning integers into intervals, and the solution was a very non-intuitive dynamic programming algorithm. I devoted several paragraphs of documentation to the how's and why's, along with additional comments every couple lines. I found it really useful, especially when I had to go back and fix an odd off-by-one error that only occurred in certain cases. In those situations, variable names can only help so much.