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.
Related
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.
This is how I wrote it, but I get
Parse Error: Unrecognised Input
How can I circumvent this?
I do not want to declare individual mixin for focus, active and disabled states.
I am using WinLess for compiling on Windows 7.
WinLess version:1.9.1
Less.js version:2.1.2
Here is my code
.state(#state,#property,#colour){
&:#{state}{
#{property}:#colour;
}
}
Any help is appreciated.
The best solution to is to update your Less.js compiler to the latest version (v 2.5.3) because it compiles the code provided in the question as-is without the need for any modifications.
However, if you can't upgrade the compiler for whatever reasons then you would need an intermediate variable to form the pseudo-class selectors and then use them like in the below snippet:
.state(#state,#property,#colour){
#sel: ~":#{state}";
&#{sel}{
#{property}:#colour;
}
}
#demo{
.state(hover,color,red);
}
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() {
// ..
}
I have been using SASS for a while now, and one thing I really like is how I can use it for my FlashBuilder projects also, namely that is supports custom CSS attributes, like 'embedAsCFF' and 'unicodeRange'.
I'm trying out LESS for the first time, and it will not let me compile to CSS while using these two custom attributes:
embedAsCFF: true;
unicodeRange: U+0021, U+0023-U+0026, U+0028-U+002a, U+002c, U+002e-U+0039, U+0040-U+005d, U+0061-U+007d;
I receive a 'Less Compilation Error: Syntax Error...'
Any LESS users know how I need to add in support for these custom attributes? Thanks in advance.
Update: This issue will be resolved in the release of LESS 1.4.2
Not a Custom Name but a Format Issue
It appears on my experimenting that the issue is really the fact that you are using capital letters in the property names (not that they are custom attributes themselves). Capital letters are apparently not supported by LESS. In other words, these work:
embedascff: true;
embed-as-cff: true;
unicoderange: U+0021; //etc.
unicode-range: U+0021; //etc.
But this does not:
Color: red;
I have not for certain isolated where in the actual LESS code itself this might be fixed (if it can be fixed for the way LESS handles the property rules). I suspect the cause is in the parser.js file lines 1578-1584 (as of this writing), which are:
property: function () {
var name;
if (name = $(/^(\*?-?[_a-z0-9-]+)\s*:/)) {
return name[1];
}
}
This seems to be filtering out allowing for capital letters. I don't know what the consequences would be if that regular expression was changed to allow for them.
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.