Hacker News Reader

Comment by jroseattle | Hacker News Reader

> Don’t print

> Use an isolated serializer

Some old reference material (XML isn't as common as JSON anymore), but still worthwhile learning: don't output data formats directly. Directly = echo, print, printf,println...whatever your syntax suggests. I see this happen a lot with my junior engineers, and I have this same conversation with them.

Prefer to use data serializers that encapsulate all the syntactical rules that go along with XML, CSV, JSON, YAML, etc. Let the serializers do the grunt work of writing output in correct format.

Some serializers aren't always ideal - correctness and speed can be an issue. Nonetheless, prefer to use those mechanisms over writing your own output.

View on HN

It's a classic trap that appears to get software developers caught (even now in 2016!) at that point where you are still lacking that firm grasp of the standard libraries available to you.

Yep. As I usually say, it is better to be able to say "not my problem" than it is to be able to say "invented here."

The single greatest strength of a skilled software engineer is to know when to make it someone else's problem.

Even if it is not your fault it can still be your problem.

Which is why judgment in that question is so valuable.

i think a major problem is that XML kinda looks and feels like HTML (and there was the whole XHTML thing to further confuse), and outputting HTML programmatically (vs string / print / template based) has most been frowned on as overweight and cumbersome.

you come from web dev doing HTML like that and you see XML and think "hey, that looks the same, i'll do it in the same way".

XML is a programmatic data exchange format like JSON or YAML, which most people would never think of outputting as templates or printed text, but it looks and feels like HTML, which most people deal with first and where that's the standard approach.

>YAML, which most people would never think of outputting as templates

Don't tell the Ansible folks!

Ansible uses Jinja2 to output templates in whatever format is preferred by the thing being configured. I haven't personally seen Ansible used to output YAML... But people will do anything :-P

Ansible does use YAML as a configuration language though—something for which it's perfectly suited.

Well, some frameworks use yaml for config files and you might use ansible to write those.

That said the templating is usually trivial, just maybe write some string values.

I’ve done it. It’s painful enough that it teaches you “don’t do this!”. For example, you need to escape `{{ item }}` as `{{ "{{" }} item {{ "}}" }}`!

Outputting JS as templates or printed text was pretty common before every language added a handy toJson method though.

yeah, I guess I sorta missed that... I mean the 'X' in AJAX was for XML... I've def been guilty of outputting "XML" with php tags. by the time we got to JSON there were libs available, or maybe we just wrote our own.

Surely it depends where your output is going? Print and friends are ideal for producing human-readable output, especially when it is temporary, for monitoring or debugging. And they are awful for producing stable machine-readable output which you might want to store.

If I'm trying to output straight to a user sitting in front of a terminal, they are going to be very unhappy if I output XML at them. And if my program only outputs machine-readable and requires another layer to turn it into something human-readable, that seems overcomplicated for most applications.

Have I missed the point, or is this advice intended for more specific scenarios than I imagined?

I think the point is to use a serialization library when you are trying to output a structured format rather than writing a half-assed use-case-specific implementation of one.

Print and friends are appropriate when not attempting to produce data that conforms to any particular structured format.

I think the benefit of a serialization library is going to depend on how complex and dynamic your actual output is. I've done XML-by-printing, but in that case the XML elements were fixed scaffolding with no relation to our internal object hierarchy (A containing array of B containing array of C containing array of D, always, regardless of how our application changed). It was also on an embedded system for which adding libraries was kind of painful.

If I need to communicate with a couple of external endpoints that need 5-10 lines of mostly static xml amd the templating is simple i often might prefer using a static templated xml file.

It's much easier to understand what's happening later.

Reply on news.ycombinator.com