> But these traits are in some ways at odds with each other. The most simple code is probably not the most testable. All those interfaces and injected dependencies make for convenient testing, but have a cost in terms of simplicity. Exactly The same code snippet might be good in one context and an annoyance in another context Here's where "generic rules" fail. Like python's avoidance of lambdas and favouring just hav…
20 short functions definitely sound as though they should be explicit. Named, documented, testable. 1 or 2 you could get away with being implicit. 20 requires a lot of understanding as to what's going on!
So here's some TypeScript code I just made up, with a lot of lambdas. It's somewhat typical of code I write all the time.
books
.join(authors, book => book.author, author => author.id)
.filter(([book, author]) => author.lastName === searchText)
.map((book, author) => `The Book ${book.title}, by ${author.fullName()}, has ${book.chapters.count()} chapters, totaling ${book.chapters.sum(chapter => chapter.pages.count())} pages.`);
It sounds like you're suggesting this code should be more like:
///
/// Gets the author of a book
/// The author of the given book
///
/// The book to get the author of
///
///
function getAuthorOfBook(book: Book) {
return book.author;
}
@testMethod()
function canGetAuthorOfBook() {
const mockBook: Book = {
author: 'Test Author',
title: 'Verbosity',
...
};
Assert.areEqual('Test Author', getAuthorOfBook(mockBook);
}
///
/// Takes a last name and returns a function that returns true if the given (Book, Author) tuple contains an author whose last name matches the given string of the outer function.
/// ...
function getBookAuthorPairPredicateFromAuthorLastName(lastName: string) {
return function(pair: [Book, Author])
return pair[1].lastName === lastName;
}
}
books
.join(authors, getAuthorOfBook, author => getIdOfAuthor)
.filter(getBookAuthorPairPredicateFromAuthorLastName (searchText))
.map(describeBookAuthorPair)
What circle of hell are we in!?