3 ms·
Nah, short and single-line functions can be good. Something I'm happy about is if I can create an object to implement some isolated part of the domain in a way
by tetha 2y ago
Nah, short and single-line functions can be good.
Something I'm happy about is if I can create an object to implement some isolated part of the domain in a way that's obviously correct and consistent within itself. For example, currently I'm working on a bit of a backup analyzer to identify different problems, estimate sizes and such. One object in there is the PGBackrestState and it has a whole bunch of one-line methods like total_size_on_disk, full_backup_count, average_incemental_size. Most of these are just one list comprehension. That's nice, readable, correct and stable code - and it makes other code more readable.
But some functions in that code base are an implementation of pretty much a flow chart of grabbing information, figuring out the state of the system and eventually dropping into more specific analyzers. This can be a whole bunch of imperative code in a function. And I've tried, but chopping this into smaller functions makes the overall idea and control flow much harder to understand. Sometimes a rough screen length of logic can be easier to understand as well.
- pbw 2y agoI mentioned in another comment pylint’s 50 line limit for methods. So I agree - a well written 50 line method is sometimes better than the same code chopped up. Although a significant factor is if you chopped it up, would there be multiple callers for the new smaller methods? Because that’s probably better than adding flags to your large method to make it behave differently for different callers, increasing its cyclomatic complexity.