6 ms·
I'm pretty sure he's referring to things like unneeded patterns, extra abstraction. I'd add stuff like "one type per file" (totally breaks down if you don't hav
by MichaelGG 11y ago
I'm pretty sure he's referring to things like unneeded patterns, extra abstraction. I'd add stuff like "one type per file" (totally breaks down if you don't have large types). Or pointless use of classes/instances, when you're just providing functions. For example, if you create a "SendEmail" function, then needlessly put it in an object. If the object isn't carrying any state, and if you're just replacing "EmailThing.SendEmail" with "var x = new EmailThing(); x.SendEmail" -- that's pointless extra code and can be removed.
As I've gotten more experienced, I do less "ceremony" and more "write code that does stuff". It hasn't seem to hurt, and I end up with less code to maintain.
Explicit is not always better than implicit. If you're being explicit about obvious facts, that's pointless verbosity. Type inference is a good thing; take advantage of it. Implicit's only an issue when there's complicated or hidden rules at play. For instance with automatic conversion operators that do "magic".
- koevet 11y agoHow do you test the code that needs to send an email, if your "SendEmail" function is not in a separate class that can be mocked? (ok, you can use a fake smtp server, but it makes tests more complex, imo)
- spinningarrow 11y agoWhy can't you mock the function? Mocks aren't specific to classes.
- MichaelGG 11y agoIf you're passing an object in, you can just as easily pass in a function. Though I was explicitly referring to the case where the code is literally rewriting static functions into objects without using any actual OO features - just adding extra noise.