I have JSLint and Atom-beautify (which I believe is a front-end for jsbeautify) installed in Atom. Generally that's pretty dandy, except that they bicker about ternary operators (I think that's the right term). So if I do
var theWindow = (thisObj instanceof Panel)? thisObj: new Window("palette", thisObj.scriptTitle, undefined, {resizeable: true});
JSBeautify will make it look like:
var theWindow = (thisObj instanceof Panel)
? thisObj
: new Window("palette", thisObj.scriptTitle, undefined, {resizeable: true});
And then JSLint will complain about bad line breaking.
I had a look at the JSBeautify documentation and the JSLint documentation, but I can't find any option for changing either's behaviour regarding ternary syntax. Can anyone tell me how I can change it so I don't have to manually reformat all my ternary functions every time I beautify my code? I don't mind which one prevails as long as they agree.
Simply add option "preserve_ternary_lines":true in .jsbeautifyrc
The ternary line expression will no more be broken.
Related change from atom-beautify: atom-beautify/pull/726
You're asking about jslint (“lint”), but the linter in use is actually jshint (“hint”.)
jshint
Create a .jshintrc file and add the following rule to tolerate multi-line strings
{
"multistr": true
}
You also might have to set "laxbreak" to true, this tolerates possibly unsafe line breakings. See the example for all available options
jslint
Again, you can create a .jslintrc file to override the default options of JSLint. Use the example as reference.
Related
I saw this syntax I'm not familiar with in the Kotlin compiler test suite.
// !DIAGNOSTICS: +UNUSED_LAMBDA_EXPRESSION, +UNUSED_VARIABLE
fun unusedLiteral(){
<!UNUSED_LAMBDA_EXPRESSION!>{ ->
val <!UNUSED_VARIABLE!>i<!> = 1
}<!>
}
What does <!UNUSED_LAMBDA_EXPRESSION!>...<!> mean?
Found in unusedLiteral.kt
The term UNUSED_LAMBDA_EXPRESSION is declared in Errors.kt to be:
DiagnosticFactory0<KtLambdaExpression> UNUSED_LAMBDA_EXPRESSION = DiagnosticFactory0.create(WARNING);
This syntax is not valid Kotlin. It is only used in the test data files of Kotlin's test pipeline. That is, only the test runners recognises this syntax, not the Kotlin compiler. Specifically, the <!DIAGNOSTIC_NAME!>foo<!> syntax denotes a handler. Handlers do checks on things, or output information to a file. In this case, this syntax checks that there is indeed the specified diagnostic being emitted at that point in the file.
Also note that the // !DIAGNOSTICS comment at the top is not just a comment. It denotes a directive. Directives are like the options for running the test.
I highly recommend you read compiler/testData/diagnostics/ReadMe.md, which explains how diagnostic tests work specifically, and if you're really interested in this stuff, check out compiler/test-infrastructure/ReadMe.md too, which tells you all about how the whole test pipeline works in general.
I apologize as I can't think of the word I'm looking for, but I have a default vue 2.0 project through the vue cli. I allowed ESLint, in order to help with typing. I'm not entirely sure what it is used for, other than pissing someone off at this point.
For example,
functionName() {} <-- no space after functionName is causing a runtime error
AnotherFunc () {
var thisthing = '' <-- You suck for not using another 4 spaces
///Comment <--- expected a space to begin comment after ///
I mean, this is kind of ridiculous. What do I gain from this? How do I get the es6 intellisense without these ludicrous formatting requirements?
Edit .eslintrc.js and
replace:
extends: 'standard'
with:
extends: 'eslint:recommended'
then your linter should be more relaxed.
In order to disable specific rules, check this list and edit rules property in .eslintrc.js.
I'm using this with BundleTransformer from nuget and System.Web.Optimisation in an ASP.Net app. According to various docs this minifier is supposed to "remove unreachable code". I know it's not as aggressive as google closure (which I can't use presently) but I can't get even the simplest cases to work, eg;
function foo() {
}
where foo isn't called from anywhere. I can appreciate the argument that says this might be an exported function but I can't see a way to differentiate that. All my JS code is concatenated so it would be able to say for sure whether that function was needed or not if I can find the right switches.
The only way I've found to omit unnecessary code is to use the debugLookupList property in the web.config for BundleTransformer but that seems like a sledgehammer to crack a nut. It's not very granular.
Does anyone have an example of how to write so-called 'unreachable code' that this minifier will recognise?
Here's a place to test online
I doubt the minifier has any way of knowing if a globally defined function can be removed safely (as it doesn't know the full scope). On the other hand it might not remove any unused functions and might only be interested in unreachable code (i.e. code after a return).
Using the JavaScript Module Pattern, your unused private functions would most likely get hoovered up correctly (although I've not tested this). In the example below, the minifier should only be confident about removing the function called privateFunction. Whether it considers unused functions as unreachable code is another matter.
var AmazingModule = (function() {
var module = {};
function privateFunction() {
// ..
}
module.otherFunction = function() {
// ..
};
return module;
}());
function anotherFunction() {
// ..
}
Encountered a strange error when I tried to compile following code:
package main
import fmt "fmt"
func main()
{
var arr [3]int
for i:=0; i<3; i++
{
fmt.Printf("%d",arr[i])
}
}
Error is as follows:
unexpected semicolon or newline before {
After correction following code worked:
package main
import fmt "fmt"
func main(){
var arr [3]int
for i:=0; i<3; i++{
fmt.Printf("%d",arr[i])
}
}
Is GO language this much strictly Typed? And this doesn't have warnings also. Should this not be a programmers choice how he wants to format his code?
Go language warnings and errors
The Go language does automatic semicolon insertion, and thus the only allowed place for { is at the end of the preceding line. Always write Go code using the same style as gofmt produces and you will have no problems.
See Go's FAQ: Why are there braces but no semicolons? And why can't I put the opening brace on the next line?
go language includes semicolons with a specific rule, in your case, the newline after the i++ introduces a semicolon before the '{'. see http://golang.org/doc/go_spec.html.
formatting is somewhat part of the language, use gofmt to make code look similar, however, you can format your code many different ways.
Should this not be a programmers choice how he wants to format his
code?
Maybe. I think it is nice that Go steps forward to avoid some bike-shedding, like never ending style discussions. There is even a tool, gofmt, that formats code in a standard style, ensuring that most Go code follows the same guidelines. It is like they were saying: "Consistency everywhere > personal preferences. Get used to it, This Is Good(tm)."
Go code has a required bracing style.
In the same way that a programmer can't choose to use braces in python and is required to use indentation.
The required bracing style allows the semicolon insertion to work without requiring the parser to look ahead to the next line(which is useful if you want to implement a REPL for GO code)
package main
func main();
is valid Go code and without looking at the next line the parser assumes this is what you meant and is then confused by the block that isn't connected to anything that you've put after it.
Having the same bracing style through all Go code makes it a lot easier to read and also avoids discussion about bracing style.
Go lang fallows strict rules to maintain the unique visibility for the reader like Python, use visual code IDE, it will do automatic formatting and error detection.
How to setup IntelliJ IDEA to prevent the splitting of an anonymous class, declared on one line, into several lines during auto-reformating (CTRL+ALT+L)?
For example, to prevent the splitting of
x = foo(new Boo() {});
into two lines:
x = foo(new Boo() {
});
"File" [menu]/"Settings"/"Code Style"/"Alignment and Braces":
==> "Keep when Reformatting" Field Set:
Check: "Simple methods in one line"
Check: "Simple blocks in one line"
Stumbled on this old question when searching for the same. The option Simple classes in one line has since been added to IntelliJ.
It can be found in the settings under Editor > Code Style > Java > Wrapping and Braces, in the Keep when reformatting field set.