The Pretty JSON Revolution

> Maybe jq will get a pretty output option after reading the article. :-)

In my experience jq already does pretty the output. Maybe I'm missing something in your comment.

I keep the `-p` (pretty) option as a single option. Not a convention at all. I toyed with 80x3 and 80:3 but ended up with 80.3. You are right though, it probably make sense to support two options as well to avoid the unusual convention. Maybe a `-edge` and `-max-depth` options in addition. Issue created: https://github.com/ohler55/ojg/issues/36

Just because the data is structured this way in the example, doesn't mean it's not possible. What's hindering you from defining a class property for each color?

"colors": { "red":{"rgb":"fff"}", ... }

That's the point GP is making. Use JSON objects for dictionary-like structures instead of directly translating XML to JSON.

I maintained a code beautification tool for about a decade. Here is what I learned from code beautification.

1. First notice that there is a world of difference between what users want and what they are willing to achieve. Know this more than anything else. People will ask for all kinds of shit, and.... A wish list is not a fully explored business requirement with known sub-tasks and test cases. A simple ask can become something worthy of a different independent project.

2. Too subjective. Everybody has subtle different personal preferences. In some cases the inability to support some edge case of some language will cause certain users to have an emotional episode. WTF. This is free software providing a convenience that you can easily live without.

3. A lot of work. You have to be very clear about what language, grammar, class of languages, or other various of characters you are willing to support. For example there is HTML then there are about billion trillion different HTML template schemes each with their own syntax and inside that syntax is a wildly different language than the surrounding HTML.

4. Carve out a measurable portion of your life. This is an investment of time you will never get back. Writing a code beautifier is far more work than it sounds. First, you need a parser. If one does not exist for the language you wish to support in the language or format of your tool you will need to write one. Be careful though, because that parser will have to support conventions that are unique to beautification and not necessarily useful elsewhere. In the case of the HTML example above you will need multiple different parsers that can achieve a nesting of parse trees or achieve harmony of a uniform parse tree beloved by all languages. This is achievable, as I have done it, but good luck.

5. Maintenance. There are always new edge cases, new languages, new grammars, new features and your users will want them all. Set hard boundaries.

------

With the amount of work required you will begin to ask yourself some basic life questions:

Does this tool bring me more money or a better job? Does it bring me prestige AND satisfy a craving for attention? Does it improve my work, as in other real work outside your beautification tool?

In my case, for a while, the tool did allow me access to better jobs with increased pay. It demonstrated I could do things many other developers could not and that I was willing to dedicate some absurd about of effort into something people actually used. But, that will only take your career so far after which you are just spinning your wheels and burning time.

When I got further in my career I realized I wasn't beautifying my code ever. I had no need for the tool I was maintaining and despite continuous maintenance by me the tool started to decay, because the requirements had grown out of control and I was no longer an end user.