Unicode defines more line terminators than what is tested; besides the usual LF, CR and CRLF there are also VT, FF, NEL, LS and PS, but the kata only tests for NEL and LS besides the first three.
Are you sure that the test 3 and 4 are ok?
Just looks like there are symbols that not equals "\n" like " " and " ".
And in some parts try to get symbol out of rage like in "AB가
말
語 C"
the length is 10 but try to get the 17th
The test assertions should use XCTAssertEqual(actual, expected) instead of XCTAssertTrue(bool) as the latter does not give any meaningful information why tests failed.
Dem, smart
Unicode defines more line terminators than what is tested; besides the usual
LF
,CR
andCRLF
there are alsoVT
,FF
,NEL
,LS
andPS
, but the kata only tests forNEL
andLS
besides the first three.There are no random tests.
It's called information :D
You can always on the same level of the solution interchange memory and runtime
IMO, production coding is not hack-competition like CodeWars.
Therefore such signature refactoring is actually welcome and recommended if appropriate.
This comment is hidden because it contains spoiler information about the solution
you are right
Please note that all character offsets are in UTF-8 Code Units, not Grapheme Cluster offset as specified in code comment.
Are you sure that the test 3 and 4 are ok?
Just looks like there are symbols that not equals "\n" like " " and " ".
And in some parts try to get symbol out of rage like in "AB가
말
語 C"
the length is 10 but try to get the 17th
Fixed!
The test assertions should use
XCTAssertEqual(actual, expected)
instead ofXCTAssertTrue(bool)
as the latter does not give any meaningful information why tests failed.linechar
orchar
Fixed!
I'm working on it. Thanks.
Issues:
char
instead oflinechar
,{}
)Btw. This is not the way how Python code should be documented (look at PEP 257)
Loading more items...