JSON is just one tiny part of most programs, sitting on the edge where the program interacts with other programs; it doesn’t permeate the entire codebase.
Structure privacy, OTOH, does. Count me in as someone who really enjoys the case-based approach. It’s not the only one which could work, but it does work.
The single most productive habit I picked up int the last few years is to always use exactly the same name for the same entity across source files, configs files, database entries, protocol fields, etc.
That’s funny, I did it your way for years and ended up considering it a big mistake.
Today I use idiomatic names - MyName in Go, myName in JS/JSON, my_name in SQL. There are many reasons but generally speaking, for me, it’s less effort and code is more readable.
I just ran into this earlier today - it makes navigating code with grep more difficult.
I had a YAML file using `some_property_name`, which was turned into `SomePropertyName`, and it's a small annoyance. It's not a huge deal, but it adds friction where some languages have none. (Or alternately, getting reordered in a separate system like `property_name_some`.)
The issue that I ran into is dealing with lot of code across different languages, like plpgsql, go and JavaScript.
Especially with database code, something that's fine in Go, like EmployeeID, ends up being employeeid in SQL. You can use underscores in Go but that can trigger other behaviours. If you mix your own JSON with JSON from other sources, you get inconsistent capitalisation. And so on.
And when you have hundreds or thousands of identifiers like this, it gets really hard to read.
You can of course capitalise in SQL - even though it's not semantic - but that becomes inconsistent, too. And then of course the lifecycles of each of these things can be different, which adds another layer of complexity - maybe you refactor your Go code before you upgrade the database, so you end up with two identifiers anyway.
Ultimately I switched to using idiomatic names everywhere, and I really haven't looked back. The boundaries between these systems tend to be pretty clear, as mentioned by someone else, so finding things shouldn't be hard regardless of what they're named.
It's certainly takes slightly longer to deal with idiomatic names - but you read code way more than you write it, and it's easier to read idiomatic code.
I do the same way like you. My logic was that I can tell where the value is coming from. I would use the same type but different name.
Is it coming from a client via http? Then it needs to be checked and saved
The database? then it has an id field which could be null in other cases.
Or I just create a new instance?
Naming things is hard tho, sometimes I do think I should just name them the same and stop caring. I'm not sure if I gain productivity but it gives me some comfort that I can instantly tell the source of the data.
I have the benefit of writing mostly C++ where there is really no globally agreed idiomatic naming. At $JOB we use snake_case naming for C++ functions and objects (as opposed to types), which also matches the python naming convention we use.
Snake case is not idiomatic for xml, but we still happen to use it for leaf config options.
The main benefit is reducing ambiguity to what maps to what across files. Ease of grepability is also an advantage.
The moment you integrate with a third party your US centre zip_code field is suddenly coming over the wire as postCode. The conversions are going to go on, at least in go I can define all of that conversion with ease in one place.
