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
In the languages like python, ruby, javascript, there is separate syntax for single-line and multi-line comments. I don't see the benefit of this complexity. Why, from a language design perspective, is there a distinction between the two? Using javascript as an example, here's the implementation:
// I'm a single-line comment!
/*
I'm a
multi-line
comment
*/
Why not simply (something like):
/* Just a comment */
/*
Doesn't matter
how many
lines
/*
People need to comment out blocks of code at once
People also need to comment out single lines
Commenting out a single line is faster when there’s only one change to make.
There are languages that only support comments with a starting and ending delimiter — C89 is a notable example (ever think C99 added // for a reason?). However, using the same starting and ending character would make a complete mess if you forgot to take one (or the other) out. Every comment following it would be flipped, and how would the compiler (if it’s a somewhat helpful one) know where the syntax error was?
One possible answer is that single-line comments are faster to add.
For example, in JS you need 2 special characters to add single-line comment and 4 to add multi-line comment.
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 2 years ago.
Improve this question
I was wondering why the following code is problematic to the CRA (and many other) js linter(s) by default. What I see here is a compact readable line of code. My guess is because the one liner below is not very scalable. Sometimes small simple chunks of code won't (shouldn't) need to get any bigger anyway. What other reasons are there to avoid writing simple one liners like this?
doSomething( prev => (prev.searchField = val, { ...prev }) );
Do I really need to do this to make the linter happy or are there other ways to keep the above one-liner?
doSomething(prev => {
prev.searchField = val;
return { ...prev };
});
To keep this succinct Lets not debate what is more readable just please answer why you think the linters warn this type of code with Unexpected use of comma operator no-sequences.
The ESLint rules are very customisable, to allow teams that have specific guidelines to customise the warnings and lintings so that they can begin to use the tool without having to edit all their previous code.
However, CRA and a few others come with recommended linter settings that are generally "best practise" and also prevent beginners making mistakes.
Although you may think that simple one liner is readable, for a lot of people it isn't, and so that no-sequences rule is a part of that pre-selected rule-set that you happen to be using.
If you disagree with the recomendations, then you are able to turn it off easily.
no-sequences rule in EsLint docs
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 2 years ago.
Improve this question
I sometimes run into situations where I would need a best practice to define a long string. I'm talking about something like this:
const text = 'This is indeed a very long string. Some might say that it is really, really long.'
My problem here is that the string is just too wide. If I would prefer a solution where the column width is considered. I would usually use one of two solutions:
a.)
const text = 'This is indeed a very long string. ' +
'Some might say that it is really, really long.'
The problem with this one is that it uses an unnecessary concatenation.
b.)
const text = `This is indeed a very long string.
Some might say that it is really, really long.`
And the problem with this one is that the resulting string will actually contain a new line, which might not be wanted in some situations.
I realize that this might be a question for opinionated answers, but I still feel like that I'm missing something, or that there is a better solution out there. Please show me if you have one!
You can use the string continuation character \ (single backslash) to do that.
const longString = "This is a really really \
long string that should \
not be split in multiple lines."
console.log(longString)
See the documentation in the Long literal strings section for details.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I'm somewhat new to regex. I understand most of the basics but what I'm trying to do is beyond my knowledge, and may not even be possible.
I'm trying to make a regex in JavaScript that can match a series of function calls in the following pattern.
Name.Name(Params).Name(Params)
The names could be any standard java function name. I understand how do to this part. The params though can be different number of parameters (Currently only 0-2)
My biggest issue however is that params could potentially take ANY string with either a single or double quotation mark, or variable names. I have added some examples below as I need all of these to work with my regular expression (if Possible).
Examples:
Func.Foo().Bar()
Foo.Bar('foo', bar).Foobar()
Foo.Bar("foo", "bar").bar(')')
Foo.Bar('/"foo/"').bar("foo(bar/")")
My main concern here is I cant just look for a opening and parentheses or even 2 quotation marks.
Is it possible to use a regex so that I can parse the function call and parameters out?
The short answer to the Question in the title is yes, you can build a regex that matches any substring. But unfortunately that is not what you want. If you allow arbitrary substrings your regex will either match many cases you dont want to match or it will become extremely complex (see the email regex for an example).
What you want is a tokenizer!(https://medium.freecodecamp.org/how-to-build-a-math-expression-tokenizer-using-javascript-3638d4e5fbe9)
Edit: for the solutions in the comments: the ast parser is for java, the author wants to use javascript.
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 6 years ago.
Improve this question
I see most code-bases using bracketed if-statements in all cases including cases in which only one statement needs to be executed after the if.
Are there any clear benefits to always using bracketed if-statements or has it just become a standard over time?
What is the general consensus on this, would it be a big mistake to allow one-line ifs through our linter?
Largely this comes down to developer preference, although many reasons are given for using the curly braces on every control block.
First, it makes the control block more readable. Consider:
if (some_condition)
runSomeFunction();
runSomeOtherFunction();
Since indentation is not respected in most curly brace languages, this will work, but it really reduces the readability (only runSomeFunction() will happen in the control block). Compare to:
if (some_condition) {
runSomeFunction();
}
runSomeOtherFunction();
Second, when you need to add something to the control block (which almost invariably happens more often than not), adding the curly's can be frustrating or easily forgotten leading to issues like the above.
Still, those largely come down to preference and you can always find exceptions (like if (some_condition) runSomeFunction(); which is much more readable than the first example above while still accomplishing the same goal in a much more concise format that retains readability).
If you have to go back to the code to add something, you might forget that you didn't open brackets, and your code wouldn't work if you exceed one line.
Other than that it's a matter of preference and format.
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).