We Keep Coding

Javascript inline if statement

I had a bit of a weird result in the javascript console. I was trying to look for an alternative (more readable) version of the ternary operator, just for fun. Typing:
{ if(3===4) {5} else {6} }
Evaluates in my console to 6, but for some reason, I can not assign it to a variable, so running:
let a = { if(3===4) {5} else {6} }
Does not let me store it to the variable directly. So my main question is, if this block is returning something, why can't I assign it?

The fact that blocks (and other statements) return values isn't accessible to your code. Consoles can see the result, and it exists at a language specification level, but not in your code.
Your options are the conditional operator¹ (which is quite readable when you're used to it, but you've said you're looking for alternatives to it) or the if/else assigning to a in both parts:
let a;
if (3 === 4) {
a = 5;
} else {
a = 6;
}
Or you could use an inline function (IIFE):
let a = (() => { if (3 === 4} return 5 else return 6; })();
There is also a proposal being floated for "do expressions", which would look like this:
// Currently a proposal, not implemented in engines yet
let a = do { if (3 === 4) 5; else 6; };
That proposal is at Stage 1 of the process, so it may or may not progress, and if it progresses it could change markedly before doing so.
¹ Although you see "the ternary operator" a lot, the proper name is the conditional operator. It is a ternary operator (an operator accepting three operands), and currently JavaScript's only ternary operator, but that could change someday. :-)

Use ternary operator, because you can't assign if statement:
let a = 3 === 4 ? 5 : 6;

The reason this doesn't work is because if is, as you pointed out, a statement. An assignment requires an expression holding a value to be assigned. A statement doesn't (per se) have a value--it simply performs some side-effect instead.
What you can use if you want to assign a value conditionally is the ternary conditional operator, which is an expression:
let a = (3 === 4 ? 5 : 6)
At this point you're probably wondering, why does the console print a value if a statement merely performs side-effects? This is because statements have a completion value, which for an if statement is the completion value of the corresponding branch, and for an expression statement (which is what the 5 and 6 inside the blocks are), is whatever the expression evaluates to. This is mainly useful for when you want to evaluate an expression in the console and see what it produces, without having to issue a console.log() each time you do.

It's not returning anything. if is not an expression, it's a statement; it has no value.
The point of the ternary operator was to provide a more readable version of this:
let a;
if (condition) {
a = 1;
}
else {
a = 2;
}

Conditional returns or single variable return

I was wondering what if there's any preferable way of returning values conditionally.
And if not, if it makes any different for minified Javascript.
I was checking Google Javascript Style guide and they don't name anything about the issue. Same with Airbnb guidelines
Using multiple conditional returns:
function demo(x, y) {
if (x < y) {
return getX();
} else if (x === y) {
return 'equal';
}
return getY();
}
Or having a single return with and making use of a variable:
function demo(x, y) {
var position;
if (x < y) {
position = getX();
} else if (x === y) {
position = 'equal';
} else {
position = getY();
}
return position;
}

The following is a definition of the return statement.
The return statement stops the execution of a function and returns a value from that function.
Clearly, a conditional return would have to include a condition before that return.
About preference, as the word implies, it is really is a matter of habits.
If you're used to one syntax from, say, another language, or you just like it better - use it, as it will probably reduce syntax errors.
About minifying the code, I believe the switch/case syntax best works for simple conditions, and the ternary operation fits well for two-side conditions.
(Caution! philosophical paragraph ahead)
But again, in the end, the important thing, I believe, is that you will understand the code you write. And, with experience, you will find what suits you best.

You should concern yourself with readability. Write the code in the way that is most understandable. If you are returning from with a deeply nest condition that is likely to be confusing to future read, but if you have a series of early exits at the start of your function that is likely to make the code more readable (when compared to deep nesting). Break up big functions and leave mangling to the compilers. The Closure Compiler will produce the same results for either of your examples.
Examples:
http://closure-compiler.appspot.com/home#code%3D%252F%252F%2520%253D%253DClosureCompiler%253D%253D%250A%252F%252F%2520%2540compilation_level%2520SIMPLE_OPTIMIZATIONS%250A%252F%252F%2520%2540output_file_name%2520default.js%250A%252F%252F%2520%2540formatting%2520pretty_print%250A%252F%252F%2520%253D%253D%252FClosureCompiler%253D%253D%250A%250Afunction%2520demo1(x%252C%2520y)%2520%257B%250A%2520%2520%2520%2520var%2520position%253B%250A%250A%2520%2520%2520%2520if%2520(x%2520%253C%2520y)%2520%257B%250A%2520%2520%2520%2520%2520%2520%2520%2520position%2520%253D%2520getX()%253B%250A%2520%2520%2520%2520%257D%2520else%2520if%2520(x%2520%253D%253D%253D%2520y)%2520%257B%250A%2520%2520%2520%2520%2520%2520%2520position%2520%253D%2520'equal'%253B%250A%2520%2520%2520%2520%257D%2520else%2520%257B%250A%2520%2520%2520%2520%2520%2520%2520%2520position%2520%253D%2520getY()%253B%250A%2520%2520%2520%2520%257D%250A%2520%2520%2520%2520return%2520position%253B%250A%257D%250A%250Afunction%2520demo2(x%252C%2520y)%2520%257B%250A%2520%2520%2520if%2520(x%2520%253C%2520y)%2520%257B%250A%2520%2520%2520%2520%2520%2520%2520return%2520getX()%253B%250A%2520%2520%2520%257D%2520else%2520if%2520(x%2520%253D%253D%253D%2520y)%2520%257B%250A%2520%2520%2520%2520%2520%2520%2520return%2520'equal'%253B%250A%2520%2520%2520%257D%250A%2520%2520%2520return%2520getY()%253B%250A%257D

Use ternary/conditional operator.
In Javascript conditional operator can evaluate to an expression, not just a statement.
var result = x < y ? getX() : getY();
This starts evaluation from left and if your condition meets criteria then result will be the first portion otherwise result would be second portion.
For more conditions you have to use it like
var result = IsYoungerThan18 ? serveMilk() : IsYoungerThan21 ? serveBear() : serveWine();
So in your case it should be
var result = (x < y) ? getX() : (x == y) ? "equal" : getY();

JSHint -Expected a conditional expression and instead saw an assignment

I am well aware of similar questions, but I still can't solve mine basing on those.
So, my code looks like this:
for (var e, i = 0; e = formErrors[i]; i += 1)
JSHint returns said error in char 39, so with ; after formErrors[i]. What can I do?

JSHint is warning you of a potential bug. It is expected that the 2nd part of a for statement will be a Boolean expression. Normally, you'd use one of the comparison operators for this (==, ===, !=, > etc..). Since the expression is e = formErrors[i] it looks like it might be a mistake, possibly due to a missing equal sign. This is a common typo that causes a lot of bugs.
Apparently, in this case it is not a bug, but rather an intentional usage of the fact that any expression evaluates to something, and an assignment expression evaluates to the assigned value:
var x;
alert(x = 1);
So the for statement actually assigns a new value to e, but also evaluates that value as a condition, casting it to Boolean if required.
You could refactor your code such that it both assigns the value and uses a casting operation that would satisfy JSHint and make the code a bit more obvious to the reader:
for (var e, i = 0; !!(e = formErrors[i]); i += 1)
The 2nd ! (the one directly in front of (e...) causes a casting to Boolean, but also negates it, the 1st ! reverts this negation.

That's just a very weird way of writing a loop. JsHint expects a boolean expression ("conditional") there, and judges that your assignment is a mistake and you actually wanted a comparison (== instead of =).
What you should do is switch to the following common array iteration idiom:
for (var i = 0; i < formErrors.length; i += 1) {
var e = formErrors[i];
…
(Which works the same as your original code for non-sparse formErrors arrays that contain no falsy values.)
Or alternatively, if you want to write non-idiomatic code, dump jshint :-)

e = formErrors[i] is an assignment, don't you want a condition there? use a comma after i=0 in that case, else put a condition after the semicolon.

Typically, the middle element in a for loop is the condition that is used to decide whether to continue the loop or not. You have an assignment there, if you wanted a condition you should use e === formErrors[i] (or with a double =, but that is usually not recommended).
An assignment can technically work, because e can be, for example, some object (true) or null (false). But that is considered bad coding style, usually, and won't make for very readable code.

meaning of the AND operator in this line

What is the meaning of && in this JavaScript code?
function doIt(a) {
var b = a.parents(),
c = 1;
return b.each(function() {
jQuery(this).hasClass("free-content") && (c = 0)
}), c
}
normally I would think this would be a logical operator AND, but I can't figure out what it does in this line.

The logical AND operator in this case is used in place of an IF-statement. It will set c to 0 if jQuery(this).hasClass("free-content") returns a truthy value.
It's equivalent to:
if (jQuery(this).hasClass("free-content")) {
c = 0;
}
You wondering what it means is actually the reason I dislike this type of coding and consider it a bad practice. It's hard to read and can create confusion, which in turn can create bugs.
It's also worth noting what logical AND returns, if you want to use the returned value:
(Logical AND) Returns expr1 if it can be converted to false; otherwise, returns expr2. Thus, when used with Boolean values, && returns true if both operands are true; otherwise, returns false.
Here's an example showing, in my opinion, bad code since it's hard to follow:
var foo = bar && baz || qux;
The above code is equivalent to:
var foo;
if (bar && baz) {
foo = baz;
} else {
foo = qux;
}
Summary: Do not use logical operators as a nifty way to replace IF-statements or to save keystrokes. It will most likely come back and bite you or someone else in the ass.
I know there will be people arguing against me on this (usually the same people who doesn't want to use semicolon because ASI), but it's just a really bad idea to write code that only an expert would understand. There's no argument against it.

return b.each(function () {
jQuery(this).hasClass("free-content") && (c = 0)
}), c
b.each loops over all entries in b, and checks whether the current element has the class free-content set. Only if that yields true, the second part of the expression is evaluated – because they are concatenated via &&, and JavaScript stops evaluating such an expression when the first part is false, because then the whole expression can’t become true any more.
So if there is an element with that class, the second part is evaluated – and thereby c is set to the value 0 (because that’s the assignment operator = there, and not a comparison).
And after that each loop is finished, the value of c is returned to the outside – because each() and c are connected via the comma operator , here, which evaluates its operands from left to right and then “returns” the second one.
JavaScript allows a lot of “fancy” coding like this, but as Marcus already said in his answer, that is hard to read, and there is no actual advantage here over, say
b.each(function() {
if(jQuery(this).hasClass("free-content")) {
c = 0;
return false;
}
});
return c;
I added the return false here inside the each loop, because once we found an element with that class, we don’t need to search the rest of them any more – that’s something that the person who came up with the original code forgot to do in all their “fancy-ness” … their loop will continue to iterate over all of b’s elements, not matter if it finds the element it is looking for in the first round already.

Javascript evaluation order for operators

Which of the following expressions will always precede left to right in all browsers(particularly IE6+, F3+, Opera 9+, Chrome)? For example the window should always alert first function then second function. In C they always suggest not to depend on the order of the evaluation of expressions. Is the same true for JavaScript or is Operator Precedence consistent?
function first(){
alert('first function');
return 0;
}
function second(){
alert('second function');
return 23;
}
first() + second();
first() - second();
first() * second();
first() / second();
first() < second();
first() > second();
Using mozilla it appears function evaluation should be consistent in all browsers, but obviously the standard isn't always followed.
Testing
After some test on browsershots.org it appears all browsers follow the standard.
Generally
The exception is when relying on the the valueOf method in javascript. ValueOf definitely appears to be called backwards in specific cases for google chrome.
// The following alerts second then first in google chrome
first.valueOf = function(){alert('first');};
second.valueOf = function(){alert('second');};
first > second;

ECMAScript 5 specifies the order of evaluation of the operands for all operators. In the case of every operator in your code snip the evaluation order is left-to-right. I'm not sure anyone could answer about the behavior of all browsers though.
Edit: See also ECMAScript 3. Evaluation order is defined the same way.

Evaluating the expression into a value (e.g. involving a function call) is always done left to right.
However, once you are comparing two values, they are not converted into primitives in order to do the actual comparison in a left to right fashion. Try the following in Chrome, for example:
var l = {valueOf: function() { alert("L"); }};
var r = {valueOf: function() { alert("R"); }};
l < r; //alerts "L", then "R"
l > r; //alerts "R", then "L"

Operator precedence and order of evaluation are two entirely different things. In the expression "sqrt(9) + sqrt(16) * sqrt(25)" it is misleading to say that "the multiplication is done first.". It is correct to say "multiplication takes precedence over addition.".
The operations are:
sqrt(9)
sqrt(16)
sqrt(25)
4 * 5
3 + 20
The first three could be done in any order, or -- gasp -- simultaneously if you have a four-core CPU and a browser that can take advantage of it. 1 must be done before 5, 2 and 3 must be done before 4, and 4 must be done before 5. There are no other guarantees.
In the expression "a && (b / a)", JavaScript guarantees that a is evaluated first and b / a is not evaluated if a is zero. Many other languages including Fortran do not guarantee this, and can get a division-by-zero exception.

I'm not sure what your use-case is, but this might be an option:
function add() {
var retval = 0;
for (var i = 0; i < arguments.length; i++) {
retval += arguments[i];
}
return retval;
}
function echoNum(num) {
alert("Num: " + num);
return num;
}
alert("Result: " + add(echoNum(1), echoNum(2)));