2 ms·

So much of this is subjective. For example, I find break/continue to be far clearer than anonymous functions and map/filter (because you can skip/bail early an

So much of this is subjective. For example, I find break/continue to be far clearer than anonymous functions and map/filter (because you can skip/bail early and for single conditions). Generally for code review, I find the best strategy isn't "this could be better", and _definitely_ not "I would have done this differently". Currently, I think it's "this gets the job done (is tested, passes acceptance tests), isn't overly clever, and looks like most of our other code". Anything more than that should either be a larger refactoring/rearchitecting job, or threatens to quagmire you in a tarpit of subjectivity.

joshuamorton 7y ago
> So much of this is subjective. For example, I find break/continue to be far clearer than anonymous functions and map/filter (because you can skip/bail early and for single conditions). To be clear, I am not suggesting anonymous functions, nor am I suggesting using the map/filter constructs. I'm suggesting that def my_process_seq(seq) for obj in seq: if meets(obj, cond): break return process(obj) is better as def get_obj(seq): for obj in seq: if meets(obj, cond): return obj process(get_obj(seq)) This gets even more helpful if you have complex conditions, or nested loops and apply this hoisting operation at each level. I have even stronger opinions about how to do this the "best" way. But break and continue are (at least in my line of work) generally the worst way. > not "I would have done this differently" I agree.