I like to comment my code as little as possible. Here's why. Even without the comment, the version that calls a named function is easier to read.

Taking pieces and naming them is usually more effective than commenting. Obviously there's lots of times this isn't enough and you need a comment, but people often double take when I say I try to avoid commenting code. #Swift

@tewha The difference between those two isn't really about comments. Or at least there are significant non-comment differences.

@atomicbird I totally agree. But each time I find myself wanting to write a comment, I think about restructuring instead. It’s an excuse. 😀

edit: or maybe a better way to think about it is that simple comments are a sign of code stink.

@tewha @atomicbird I don’t necessarily consider it a code smell. Many methods are better kept “quasi-atomic”; adding methods just to organize should be weighed against the increased API surface (and dev tendencies to use/reuse/*repurpose* methods inappropriately), as well as whether it improves or reduces testability.

With this, I’d consider adding it to Array<Expense> with a default parameter of `.now` to improve its reusability and testability, but many might feel it reduces discoverability.

@pgor @atomicbird Yeah, these are all factors but not necessarily outright signs. There's few absolutes.

In this case, I ended up renaming the function markReported(selectedExpenses). (I also changed how that actually works.)

@tewha @atomicbird Even more strongly, I feel that creating methods like this that don’t use an implicit `self` are a smell. You’re creating a free function that has no reason to be bound to that object.

@pgor @atomicbird I agree, though it *does* use self thanks to how model contexts work. But it's the same kind of smell, which will eventually be MVVM'd out.

I just hate how MVVM works with SwiftUI right now. I feel like trying to implement it doubles or more the size of my code, and introduces way too many opportunities for bugs.

@tewha @atomicbird This aligns with the sentiment of Kernighan and Plauger: “Don’t comment bad code - rewrite it” as related in the 1993 “Tutorial on Good Lisp Programming style” by Peter Norvig (yes, that Peter Norvig) and Kent Pitman.

https://courses.cs.northwestern.edu/325/readings/luv-slides.pdf