clocgithub.com

measured at 2.10 · downloaded from github-release-file as AlDanial/cloc

What it fails

defaultdoes not agree on 26 of 84 cases

1120-close_then_code_then_stray_and_reopen ✗the block comment is cut out together with the line break inside it, so the code before the opener and the code after the closer become one line and the line that vanished is charged to comments

1180-cmake_bracket_comment ✗CMake has no bracket comment here, only the hash, which is a comment wherever the line's first mark is one. So the opener's line is a comment and its body and closing bracket count as code

1200-nested_block_comment_that_nests ✗the inner closer ends the comment although Haskell's pair nests, so what follows it on that line is left standing and the line counts as code

1210-close_touching_reopen_nesting ✗an opener that comes after a closer on the same line is not acted on, whether the two symbols touch or a space separates them, so the block it reopens is never a comment

1220-nested_block_comment_in_odin ✗the inner closer ends the comment although Odin's pair nests, so the lines under it up to and including the outer closer are left as code

1230-a_comment_word_at_the_head_of_a_longer_word ✗a line whose first word begins with REM is taken as a comment whatever letters follow, so the command counts as one

1240-a_comment_opener_inside_a_vector_type ✗the <* of the vector type opens a documentation comment that nothing closes, so the four lines of the macro under it are counted as comment. The same file with int[<4>] comes out right

2060-backtick_template_holding_a_comment ✗a // at the head of a line opens a comment inside a backtick template as readily as outside one, so that line of template text counts as a comment

2080-odd_triple_quote_count ✗a triple quoted string is read as documentation wherever it opens, the middle of a line of code included, so the lines holding its text and its closing quotes are added to the comment count

2190-triple_quote_read_as_three_short_ones ✗a // at the head of a line opens a comment inside a triple apostrophe string too, so that line counts as one, while the /* under it opens nothing and takes no line with it

5010-line_splice_inside_a_string ✗a string that opened on an earlier line does not stop a // from being stripped, so the line of string text holding it counts as a comment. Inside a string that opens and closes on one line it is left alone

5020-blank_line_inside_a_spliced_string ✗a blank line under a line ending in the language's continuation symbol is read as continuing it and is never blank, so the blank inside the spliced string comes out code

5030-line_splice_inside_a_comment ✗a line comment stops at the line break whatever the line ends with, so the line spliced onto it counts as code

5040-line_splice_in_a_comment_with_no_words ✗a comment carrying no letter or digit is read like any other and still stops at the line break, so the line spliced onto it counts as code

5050-line_splice_after_a_closed_block_comment ✗a block comment closing earlier on the line does not move where the line comment after it stops, which is still the line break, so the line spliced onto it counts as code

5070-blank_line_inside_a_spliced_comment ✗the blank line under the spliced comment is read as continuing it and is never blank, so it comes out comment where its own blanks-first rule says a line of nothing is blank

6020-comment_opener_inside_an_attribute ✗a comment opener inside a quoted attribute value opens a comment all the same, and nothing below closes it, so both lines under it count as comments

6030-opening_tag_split_over_two_lines ✗the file is counted as one language from beginning to end and no script block is separated out however its tag is written, so the js comment inside it counts as markup

6040-script_tag_in_upper_case ✗no script block is separated out of the page at all, so the case of the tag never comes up: the same file written in lower case is counted exactly the same way

6050-script_closer_written_with_a_space ✗every number comes out as the rules ask while the javascript line is credited to the page and no second language is named, so nothing in the totals shows the block was never found

6080-block_named_by_a_mime_type ✗the file is counted as one language from beginning to end, so a block named by a mime type is read with the page's symbols and the comment inside it lands in code

6090-vue_blocks_count_as_their_own_languages ✗the file is counted as one language from beginning to end, and every number comes out right only because the symbols it applies to a vue file already cover the markup, the js and the css comments, while neither block is named

6100-block_language_named_by_the_tag ✗the file is counted as one language from beginning to end and no lang attribute is read, so every number comes out right only because those symbols already treat // as a comment

6110-php_block_holding_html_around_it ✗the file is read as php from beginning to end and never switches language at the closing tag, so the markup comment between the blocks counts as code

6120-script_inside_html_inside_php ✗the file is read as php from beginning to end, so the js comment two languages deep survives only because php spells its line comment the same way, and neither language inside is named

8030-blank_line_inside_a_multiline_string ✗the empty line is set aside as blank before any comment rule runs, which is what its own rules ask, and the rest of the string around it is read as documentation

default--strip-str-commentsdoes not agree on 25 of 84 cases