3 ms·
I generally like this style guide a lot. It makes (in my opinion) the more rational choice on some items (like no nested closures), has a lot of good tips (lik
by bps4484 15y ago
I generally like this style guide a lot. It makes (in my opinion) the more rational choice on some items (like no nested closures), has a lot of good tips (like named closures), or makes a definitive decision on stuff that could go either way, but is better to have something chosen over doing both (like tabs versus spaces). But this:
"Keep your functions short. A good function fits on a slide that the people in the last row of a big room can comfortably read. So don't count on them having perfect vision and limit yourself to ~10 lines of code per function."
I can't tell if that is a joke or not. Given the rest of this seems serious, I have to believe it too is serious, and I don't understand how this can lead to good code. Some functions simply have more than 10 lines of logic. In these cases, to follow that rule would either involve A) breaking up the code into other functions because "that's the rule" or B) combining lines of code unnecessarily, making the code less readable. When I write a function, I'm either trying to make logic reusable, or abstract away logic. How much logic is of much less importance.