Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Is there any such thing as the "standard" convention for JSON indentation level? Should it be 2 spaces, 3 spaces, 4 spaces, tabs delimited, or something else?
I tried to come across the official JSON site, but it is not stated there.
JSON is a serialization format, not a presentation format.
As such, there is no "standard" indentation - JSON is typically sent as compactly as possible.
(That said, there is an option to JSON.stringify() to request "pretty printed" JSON - look at the space parameter at the MDN documentation)
There is no standard. The JSON specification permits any number of whitespaces.
However, when you are pretty-printing JSON to make it readable (e.g. in config files) it is good practise to be consistent with the coding conventions of your project and use the same indendation level as you would for an JS object literal - which is often 4 (Crockford) or 2 spaces (Node.js).
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
The page proposals:date_literal_syntax at ecmascipt wiki says:
Spec retracted 2006-08-28 following meeting on 2006-08-23; proposals for supporting a sensible date syntax have been folded into proposals:date_and_time.
However, that page does not even mention date literals at all.
As date literals would be very useful for some JSON vNext syntax (e.g. JSON5), I am interested on what's their current state, and why they were retracted.
As far as the proposal, I would say "Date/Time Literals are Dead". The article(s) referenced were last updated in 2008 (6+ years) while neither ES5 nor ES6-draft support such literals per the grammar rules.
Since there is no Date/Time literal in ES5, such cannot be represented in JSON5 as literals because it has a goal of being a "strict subset of JavaScript". JSON5 looks to expand JSON to encompass more JavaScript literal syntax1 constructs, but does not cover non-literal forms like new Date("ISO8601").
1 JSON is not JavaScript, despite sharing a word in the name; just a mostly-compatible serialization format. (Which is why JSON5 makes me go ugh! it complicates the format/processing while the biggest compatiblity target - JavaScript ed.5 - does not sanely rely on "eval" to handle JSON.)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
In Python underscores are used for variables:
some_long_var, my_name, first_name, etc.
In JavaScript camelcase is preferred:
someLongVar, myName, firstName, etc.
All is fine and dandy until the two technologies start interacting:
JS Ajax Call:
$.get('url', {foo_bar: fooBar, bar_baz: barBaz}).done(function (data) {
console.log(data.computed_result);
};
Python view:
def url():
foo_bar = request.GET.get('foo_bar')
bar_baz = request.GET.get('bar_baz')
return jsonify(computed_result=foo_bar + bar_baz)
Do I use the Python or the JS style within the data JSON object sent to the server?
What about the JSON response?
Pick one and be consistent. I write Python a lot, therefore I would choose the Python style, which is concerned with readability for non-native-English speakers. However, reasonable people could disagree. Build concensus on your team, and take what you can best agree to be the best course of action.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Lets say you needed a hardcoded list of strings (the question here is not whether or not you should hard-code things).
Is there a reason to prefer this:
var things = 'a b see'.split(' ');
over this:
var things = ['a', 'b', 'see'];
Pros of first approach:
Easier to refactor data from code. (String is not language specific)
Pros of second approach:
Less prone to error (what if your string has a space in it?)
Easier to format automatically (can and probably should separate each string by newline)
Easier to get data from alternate sources in the future.
Signals intent more clearly
Tiny bit more efficient
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am a Python programmer before learning Javascript, and as lowercase_separated_by_underscores is recommended for Python's variable naming,
I continued using it for programming Javascript since changing habit is painful and unconvenient. But after seeing a lot of
professional Javascript code which use lower camel case to name variables, I begin to think about
what is the most standard and suggested way, this_way or thatWay ?
The universally accepted naming convention for JavaScript is lowerCamelCase, yes.
Well, have you taken a look at the DOM API? Or the built-in objects? Here are some methods names...
getElementById
forEach
addEventListener
toLowerCase
This should answer your concerns.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm trying to model my javascript object using visio, visio doesn't support javascript data types.
Then I start thinking, how do you desing model your javascript code?
Cheers
In the past, I've used Open Source tools like Dia and just fudged the data types where needed...
It's enough to get the idea across, but you're definitely not going to get anything even close to code generation from it.
I prefer Object Oriented design - even for JavaScript - so I suggest Rational Rose. I like some of the features of OO (e.g. encapsulation and abstraction) and like to add some discipline to a potentially undisciplined environment - especially when working with developers new to JavaScript. Rose meets my needs.