Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hang your code out to DRY

johan.hal.se

Post reply on HN
Print view View original

71–80 of 82 posts

Re: Hang your code out to DRY

#71

Post by jamil7 »

manmal wrote: post #70
jamil7 wrote: post #66

Earlier quoted context omitted.

> Isn't TCA a dependency framework? It is but it's quite straightforward to build your own simpler version using only Combine - that's what we're doing at the moment and it tends to work very well, interacting with Core Data has been kind of clunky though. > I am looking forward to SwiftUI. I really hope that the documentation improves, though. I've been on a project using it for the last 8 months both for macOS and…

If you are using TCA only for dependency management, I’d suggest to reconsider and put all business logic in it. In my experience, most serious efforts of wrangling SwiftUI into a complex app wind up with a solution that’s similar to TCA.

Ah! We're putting all our business logic in it, I guess I misunderstood what OP was asking and assumed they meant something else, that's why I mentioned we built our own version of it internally.

Re: Hang your code out to DRY

#72

Post by isleyaardvark »

manuel_w wrote: post #46

I once read a comment I wish I'd saved. It goes along the lines of: W beats X, X beats Y, Y beats Z; in terms of what principle you'd like to apply to your code. One of these letters was essentially representing DRY. I summed things up pretty nicely. Does someone happens to remember?

I'm willing to bet it was this, because I was so struck by it I saved it:

>I try to optimize my code around reducing state, coupling, complexity and code, in that order. I'm willing to add increased coupling if it makes my code more stateless. I'm willing to make it more complex if it reduces coupling. And I'm willing to duplicate code if it makes the code less complex. Only if it doesn't increase state, coupling or complexity do I dedup code.

https://news.ycombinator.com/item?id=11042400

edit: and of course it's from a long and worthwhile HN thread on Sandi Metz's original article which was the start of the back-and-forth resulting in the article for this thread

Re: Hang your code out to DRY

#73

Post by ChrisMarshallNY »

jamil7 wrote: post #71
manmal wrote: post #70

Earlier quoted context omitted.

If you are using TCA only for dependency management, I’d suggest to reconsider and put all business logic in it. In my experience, most serious efforts of wrangling SwiftUI into a complex app wind up with a solution that’s similar to TCA.

Ah! We're putting all our business logic in it, I guess I misunderstood what OP was asking and assumed they meant something else, that's why I mentioned we built our own version of it internally.

Nah. I meant that it is a library, that needs to be included as a dependency.

That's a nonstarter, for me. I'm pretty picky about dependencies. If I use external ones, I like them to be something that can be encapsulated/injected, as opposed to being totally interwoven.

But I'm not trying to make money, I just want to write really good apps.

Re: Hang your code out to DRY

#74

Post by contravariant »

ChrisMarshallNY wrote: post #69
contravariant wrote: post #13

Earlier quoted context omitted.

There's something to be said for preferring composition over inheritance, but in that case overly DRY code consists almost entirely of glue. As with almost anything it's a matter of choosing the right tool for the job. The only code style advices that I've found to hold nigh universally are the following: - The best code is no code - Don't end classes in 'er' or 'or' Coding paradigms are good when they let you do tho…

Almost every one of my classes (in my UIKit app) is a ViewController. I don't really need to write anything more. So they pretty much all are "er" classes. ¯\_(ツ)_/¯

So what you're saying is you've got a bunch of views and most of your programming code is spent on classes that ensures they do the right thing?

I'm not ruling out that this is an illustration of the problem with classes ending in -er.

Re: Hang your code out to DRY

#75

Post by ChrisMarshallNY »

contravariant wrote: post #74
ChrisMarshallNY wrote: post #69

Earlier quoted context omitted.

Almost every one of my classes (in my UIKit app) is a ViewController. I don't really need to write anything more. So they pretty much all are "er" classes. ¯\_(ツ)_/¯

So what you're saying is you've got a bunch of views and most of your programming code is spent on classes that ensures they do the right thing? I'm not ruling out that this is an illustration of the problem with classes ending in -er.

Not saying it's great.

It's just the way you write iOS apps (at least, the original design way).

It's classic MVC. Most of the action happens in the controllers.

BTW: I totally agree that the best code I write, is the code I don't write.

Re: Hang your code out to DRY

#78

Post by darkwater »

MauranKilom wrote: post #52
darkwater wrote: post #4

Earlier quoted context omitted.

Why does the "does it actually work" go down over time? I would expect to be the other way round: more experience, more chances your software "actually works", even if it's not following strict rules anymore.

The axis is labelled "relative importance". If you place non-zero value on readability, you must place less than 100% importance on "does it work".

Why? There is absolute no correlation between readability and working status. It might be obfuscated code that works perfectly, or it might be obfuscated code that explodes every 2 days. And it might be perfectly clear code badly implementing a business need or implementing it perfectly.

Re: Hang your code out to DRY

#79

Post by manmal »

ChrisMarshallNY wrote: post #73
jamil7 wrote: post #71

Earlier quoted context omitted.

Ah! We're putting all our business logic in it, I guess I misunderstood what OP was asking and assumed they meant something else, that's why I mentioned we built our own version of it internally.

Nah. I meant that it is a library, that needs to be included as a dependency. That's a nonstarter, for me. I'm pretty picky about dependencies. If I use external ones, I like them to be something that can be encapsulated/injected, as opposed to being totally interwoven. But I'm not trying to make money, I just want to write really good apps.

I share your sentiment, and try to avoid dependencies like the pest. But, I wouldn't write my own crypto library, and TCA falls into a similar category - it's a really good solution for a hard problem. Those guys invest a big part of their time into just those few hundred lines of code. There's word that even Apple uses their stuff internally.

Re: Hang your code out to DRY

#80

Post by dllthomas »

BurningFrog wrote: post #45
ebiester wrote: post #6

My first heuristic is: If I change the code in block A, is it assured that I will need to change the code in block B? My second heuristic is: Can I name the method I wish to de-duplicate in a way that is honest for all cases I wish to cover, yet explains its business purpose? The more it deviates from these heuristics, the more likely I am to duplicate the code in object oriented programming.

My slightly different heuristic: If fact X changes, how many places in the code do we have to change it? If the number is > 1, relying on humans to realize that will, on average, always fail. I know of two ways to fix that. [1]: DRY it up. [2]: Write a test asserting that all the places use the same value. Sadly, most people rely on this: [3]: We "just have to remember" to do these changes in all places, despite the…

[2b] is to use the type system to make sure the places are consistent, the practicality of which depends significantly on both particular task and choice of technology.

[3b] is adding comments, which is better than relying purely on memory but can often be missed. I've locally improved on this a bit by including cross-references on the relevant lines, along with tooling such that the referents are automatically surfaced during code review.

Post reply on HN