Hacker News Reader

> It drives me nuts to deal with the typical Java "Each class has its own file -no matter how small" thing.

Couple this with extensive use of inheritance and design patterns, and you have a recipe for awfulness. One of my previous teams had an implementation where rendering a piece of HTML would involve digging through about twenty different source files, each with maybe 3-4 lines of actual code other than the class definition boilerplate. One top-level line would send you down the inheritance hierarchy of ClassThatGetsData/ClassThatGetsDataPlusThisOneOtherThing/...PlusThisOtherOtherThing/... etc etc, then the same thing for ClassThatProcessesData/... and then ClassThatRendersData/...

Adding a single bit of data to rendered HTML (e.g. a tiny star for 'this product is well-reviewed') would involve altering every single source file in the multiple trees, and maybe adding some new specialisations to make the trees even deeper.

At the time, fresh out of Uni with a head full of design patterns, I thought this was just how enterprise code was meant to be structured!

> At the time, fresh out of Uni with a head full of design patterns, I thought this was just how enterprise code was meant to be structured!

Ugh... and that's the flaw in teaching design patterns.

Don't worry, that happened to me too, though I didn't go to a university.

Design patterns are an advanced tool. If you're learning to code, design patterns are mostly non-applicable to the kinds of problems that newbs are solving. Design patterns are meant for specific problems, but somehow we end up believing they're the end-all-be-all and that we must be using some design pattern in our work. If you have design patterns pounded into your head, and you believe the only design patterns that exist are the one's someone has already named, then not using a particular design pattern can seem like chaos even when it's not.

I wish we'd stop teaching that shit. If you've been coding long enough and faced complex enough problems, you'll either come to embrace some design patterns or you won't. Otherwise they'll likely just be misapplied.

OOP fits this view of mine as well. In general, I don't think most programmers need to be aware off OOP principles because they will almost certainly misuse them. And to what end? Several single purpose classes and "tiny functions" scattered across multiple files that others are now forced to jump between.

Most “design patterns” are actually just workarounds for lack of expressiveness in old Java versions.

In other languages or modern Java you can replace half of them with simple constructs. Factory pattern for example can be replaced with simple inline callbacks to anonymous functions. Same with many others.

It takes a long time for some people to understand that complexity is the enemy; and for patterns in particular it takes some people a long time to learn when to apply them.

Same thing for algorithms: BloomFilters are the classic example. You can tell when it has hit the font page of HackerNews recently because suddenly everyone starts looking for problems that it can solve (poorly).

Just don't get me started on blockchain... :-)

It feels like half the usage of inheritance is also just workarounds for mocking things in unit tests or being able to access things that are private/protected. Everything ends up with an interface and an impl just because of silly language decisions.

> Another thing that I do, is have fairly large source files, that aggregate multiple classes/structs/enums/protocols that relate to each other. It drives me nuts to deal with the typical Java "Each class has its own file -no matter how small" thing.

This can go both ways - I've seen plenty of projects where you have to dig through 3k lines of unrelated spaghetti code just to find the bit you need. That turns into a special piece of hell when you have multiple team members working on it.

The original motivation for having more small files was driven by these "god objects" and the limitations of version control. CVS, Visual Source Safe and to a lesser extent Subversion were much easier to use together with smaller files.

If you're using modern version control (git) then that reason has gone.

My personal preference is to split horizontal concerns into their own modules and depend on them; they become the core / support libraries for my team/organisation. For services I try to keep the domain-specific parts close. Tests go in a different module which mirrors the structure. When units start to get big (or become cross-cutting) they get factored into smaller units or other modules.

In the end it's all a balance and unless you're under outside constraints (cough SonarCube box-ticking busywork idiocy cough) then you can generally keep it sane.

> It drives me nuts to deal with the typical Java "Each class has its own file -no matter how small" thing.

There is value in keeping some source together, but I think it's more judgment based than you imply, it can also drive me nuts when I have to dig through a dozen 2k+ line files to find the thing I need to change, and it also reduces my confidence that I can change that thing without introducing unwanted side effects (unit tests help increase that confidence regardless of code structure).

My tolerance for multiple classes in a file or larger classes is heavily driven by what tooling I have available.

If I've got a structural outline panel, like in IntelliJ-based editors, or the SuperCharger plugin in Visual Studio, then whatever, it's easy, because I have that table-of-contents to easily navigate with.

With less powerful tools, the "every type in its own named file" pattern is much more useful.

That makes a lot of sense.

I use Xcode’s editor. It makes zipping around big text files, quite easy, and going through multiple text files, a pain.

Fair point.

As someone that regularly digs through 200-1.5K files (2K is a bit much, for me), I can report that good documentation makes a huge difference.

Good documentation is definitely helpful, but expensive and challenging to maintain (and keep correct). In my personal experience, documentation is out of date or invalid nearly the minute the ink dries... much better (again, in my experience) to have good, descriptive unit tests that fail when the code changes.

Unit tests are not always a good match with the application: https://littlegreenviper.com/miscellany/testing-harness-vs-u...

I tend to use a lot of test harnesses (which, IMNSHO, are much better application exemplars than most unit tests).

I also use a lot of headerdoc stuff. In Xcode, it allows your own code to show up in the QuickHelp navigator tab, and you can generate really good SDK docs.

It also stays fresh. Easy to maintain. Using "breakers" is a huge aspect of my code. Makes it much easier to scan, and liberal use of // MARK: is good.

Agreed, higher-order integration tests tend to offer many more serendipitous fault discoveries than unit tests. Still, unit tests add value, acting as the living "comment" on a method or module, while the higher-order integration tests act as the living "how-to-use instructions" for the application.

Yeah. Unit tests aren’t especially applicable to the type of software I tend to write (UI mobile apps), though. I use them a lot for the backend code, and a number of the packages that my apps include, but I don’t like to rely on automated UI testing, as these tests are invariably scripted “record/playback/pattern-match” tests. Only useful for testing a minuscule number of “low-hanging fruit” issues. Not at all useful for a “user goes where they want,” unbounded GUI. Maybe an AI-driven testing system might work.

In my experience, there’s no substitute for good, old-fashioned, disciplined “monkey-tests,” when it comes to UI software. Even test harnesses aren’t always relevant, and I end up running most of my tests on the production code, as the project matures.

Requires discipline. And, in my experience, a well-documented codebase (“Why,” as opposed to “what,” when documenting internals), pays off in spades. Headerdoc markup works wonders. It, quite literally, makes self-documenting code, and documenting the interfaces (as opposed to the internals) has a great shelf life.

Since I use Xcode, it "live-parses" my interface docs, and shows them in the QuickHelp panel, on the right side of the screen, so, when I select a function that I wrote, it displays the interface, just like it does for the Apple-authored stuff. Very cool. Since all my included packages (the ones I wrote, anyway -which is 99% of them), use it, I have great "live" documentation.

I used to argue with my Japanese peers about this stuff. They were not fans of automated testing. I was able to get them on board with unit-testing engine code, but they were absolutely correct about testing GUI code, and I had to cede the point to them.

They were very disciplined, when it came to “monkey testing,” code structure, and documentation. One reason, was because they tended to rotate engineers through projects all the time, and leaving a legacy was important. I write about what I have learned, here: https://littlegreenviper.com/miscellany/leaving-a-legacy/

I followed the same pattern when I had the time to. Instead of building the thing, build it as a separate package and include it as a dep. Packaging code up for open source consumption leads to better docs, tests, and tighter abstractions that are generalized.

I think that's the opposite of what the parent says: first build the thing and only then factor it out and reinclude it.

Not completely. The way that it works for me, is that I start work on a project, and, while building, I notice that some code that I'm working on is:

1) Pretty complex, and fairly insular; and/or

2) Possibly useful, elsewhere.

If that's the case, I will then stop work on the main project, and take some time to extract and "genericize" the subproject. I'll usually set it up as a standalone open-source project; complete with tests and documentation. As the commenter stated, I think that this results in some excellent code. I always clean the house before the guests arrive.

This may happen before I have completed the coding in the main project, or may happen as the result of a review, after the fact.

In some cases, I very clearly need to develop a subproject before starting on the main project, or before certain milestones within that project (for example, SDKs or drivers). In that case, the timelines are completely separate.

If you look at my GH repos, you'll see a whole bunch of these projects, including some rather strange ones, like an XML duration parser[0]. These are the types of projects that I extract.

In some cases, I end up not using the extracted project in my main project (happens to some of my UI widgets). In that case, even though I am not using it, I still have an excellent project for the future. Here's an example[1]. I have ended up not using the spinner in my own work, as it was too obtrusive a widget, but it's nice to have it available for future projects.

[0] https://github.com/RiftValleySoftware/RVS_ParseXMLDuration

[1] https://github.com/RiftValleySoftware/RVS_Spinner

This sounds a lot better than the Single Responsibility Principle that is often quoted and IMHO often misunderstood.