Code metrics improvements / code optimizations / production (readability/coupling/complexity)

[default-writer]

LinkedList optimizations:
-added counter variable
-added overflow/underflow exceptions
-moved counter to read-only property
-moved code to function nodeAtIndex function
-changed variables to optionals for readability
-removed overcompilcated code blocks
-removed Enumerable constraint for T
-removed print

LLNode optimizations:
-added default init and parametrized init to LLNode

Tests modifications:
-added try! code block to bypass exception handling

[default-writer]

Currently working at
default-writer@50f8ede

My opinion that it is essential to replace spaces with tabs, because different users like different tabs on XCode [Preferences - > Text Editing -> Indentation].

I prefer 2, GitHub prefers 8, so for commits using tabs it will not overcommit the lines and extra spaces

[morganchen12]

My concern with tabs vs spaces is Xcode's default is to use spaces to indent. Either way, the precedent for tabs vs spaces shouldn't be evaluated on a case-by-case basis per PR; someone should add a style guide or contributing guide to this repo. Until then, you may want to stick with spaces since the rest of the project already uses spaces--but, if you don't, it's not such a big deal.

[morganchen12]

There's a few places (1, 2) where force-unwraps aren't necessary.

[morganchen12]

For the map and filter functions, consumers probably shouldn't have to know about the LLNode type, since that would be revealing the implementation details of the linked list in its public interface.

func map<U>(transform: T -> U) -> LinkedList<U>

instead of

func map(formula: LLNode<T> -> T) -> LinkedList<T>

[morganchen12]

There are a few defer closures that are followed immediately by return statements, which seems unnecessary.

[morganchen12]

the addLink() and addNode() methods could maybe be renamed to indicate how the values are added (i.e. append, prepend), but naming is hard and verbosity can feel awkward.

[default-writer]

@morganchen12 Hi! Could you advice easy to read names for the duplicate function naming (if i understood remark correctly) for addNode, addLink functions? (i.e. append<...>, prepend<...>)? I'm not a native speaker and do not understand the mush difference and verbosity then

[morganchen12]

addLinkAtIndex(key: index:) could be renamed to addValue(_: atIndex:), addLink(key:) could be renamed to prepend(key:). Other than that it looks fine. Naming is also partially opinion, so you're free to propose alternatives.

[waynewbishop]

Thanks for submitting this pull request. Since this submission the code has been changed considerably. Feel free to check the latest version on develop if there are additional changes you'd like to see.

Regards;