4 ms·
Show HN: I transformed my library into a Node and 100% coverage and Travis tutorial
- darfs 11y agoI like it. It's pretty well documented. Rare thing today IMHO
- lifebeyondfife 11y agoDon'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 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.
- filipedeschamps 11y agoTotally agree! But basically this is a tutorial.
- openasocket 11y agoI'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.
- darfs 11y agoThing here is, it can replace any Blog/Book/Posts whatever about RSS Parsing with Nodejs And a line-by-line documented Code is in such a case a better solution for those who want learn by reading Code :-) Surely, it's worse in big Projects. But there I miss often a detailed documentation about the implementation. Look for example to the strlen() Std implementation for C/C++(it was the same with Magic Hexcodes and so on, right?)
- FraserGreenlee 11y agoHey 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. http://webarcs.com http://webarcs.com # where I found your post http://webarcs.com/?open=27311 http://webarcs.com/?open=27311
- thebiglebrewski 11y agoCouldn't you have used the Wiki instead of issues? Great work though!!
- filipedeschamps 11y agoI don't know, I just don't like Github wikis. I find issues to be more "social".
- sz4kerto 11y agoIt's great -- it's 87 LOC though. And don't forget: coverage is tested in terms of LOC, not in terms of program states.
- filipedeschamps 11y agoHmm this seems to be a very nice knowledge. Would you mind explaining it a bit further?
- dmoy 11y agoSay you have the following code: if (foo) { setSomeState() } At least with tools I'm familiar with, your coverage will be 100% if you have one test with 'foo = true'. That means that you could have odd untested behavior if not executing 'setSomeState()' leaves something important unset.... but you'd have 100% coverage. Of course in practice, 100% state coverage is really impossible to achieve.
- dsp1234 11y agoImagine a function that is something like: function X(Y, Z){ if(Y){ foo(); } if(Z){ bar(); } } If you have tests like: X(true, false); X(false, true); Then your code coverage from the "line" point of view is 100%. Those two tests execute every line of code. However, the two states: X(true, true); X(false, false); have not been tested, and if foo() and bar() both manipulate some global state, or otherwise have side effects, then the system could still break. This is an issue with many code coverage tools. The lines themselves have been executed, but not necessarily all program states.
- talles 11y ago"a Node"? Anyway, that amount of comment is alright for learning purposes but for an actual lengthy code base it would be a nightmare keeping all that updated. Comments are supposed to be used just for complicated/critical code, otherwise is just noise to be maintained.