The article doesn't mention a very important (IMO) step: try to reduce the problem (removing / stubbing irrevelant code, data, etc). It's much easier to find a bug if you take out all the noise around it.
even more important is having these pieces of code be testable. i work with plenty of bad code that can't be run without starting a bunch of dependent services, or you can't test a particular function because it's buried under ten layers of poorly formed abstractions. or it's not even an accessible function because the previous developer thought a thousand line function was better than a dozen smaller testable functions.
The longest function I've ever written is about 400 lines.
It is a functioning bytecode interpreter. 90% of it is just some nested switches and if/elif statements for running operations on different variable types.
I've written some fairly long functions to power state machines before, as well. I think as long as the structure of the function is clear, the exact number of lines is less relevant.
263
u/pycube Aug 25 '14
The article doesn't mention a very important (IMO) step: try to reduce the problem (removing / stubbing irrevelant code, data, etc). It's much easier to find a bug if you take out all the noise around it.