Javascript "do-while" type loop

Javascript "do-while" type loop - javascript

I'm working with some JS code that I inherited on a project, and in several instances it has loops set up like this one:
while(text = someBufferObject.read()) {
//do stuff with text
}
I'm assuming this is to achieve some sort of do-while type functionality. However, when I run this through JSLINT it complains that it "Expected a conditional expression and instead saw an assignment."
Is there a more accepted approach that I should use for these loops? I'm not sure if something like below is the best way or not:
text = someBufferObject.read()
while(text) {
//do stuff with text
text = someBufferObject.read()
}

Is there a more accepted approach
Don't take JSLint's advice as gospel. It is dogmatic opinion from a cranky old man; some of it entirely sensible, some of it rather questionable.
while (variable= assignment), though it might sometimes be a mistaken comparator, is also a widely-understood idiom of C-like languages. Whether you use that approach or another is a matter of taste, something you should weigh up personally rather than blindly accept Crockford's edict.
JavaScript does have a do-while loop, so if your test is consistently at the end that would be a more appropriate construct:
do {
text= someBufferObject.read();
// do something
} while (text);
More commonly though what you're looking at is a mid-test loop. You may or may not prefer the break idiom as used by Python:
while (true) {
text= someBufferObject.read();
if (!text)
break;
// do something
}

You only need to wrap it in another set of parentheses to make JSLint happy.
while((text = someBufferObject.read())) {
//do stuff with text
}

I can only imagine that's a problem with JSLINT, that's completely valid javascript, it's a lot better than the second solution anyway.

See if JSLINT complains about this:
while (NULL != (text = someBufferObject.read())) {
//do stuff with text
}

Neither example is a "do-while", they're just different code styles that essentially do the same thing. JSLint is simply informing you that the first style goes against best practices.

JSLint is complaining because it's a JavaScript code-smell -- using a single-equals (assignment operator) instead of double- or tripe-equals (equality/identity operator) is a common mistake.
If your code works, don't sweat the warning. It's an automated tool, not an omniscient tool.

while((text = someBufferObject.read()) !== undefined) {
//do stuff with text
}
is also accepted by jsLint and a style less cryptical than the paranthese workaround:
while((a = b)) { ... }

Related

How to execute two jquery events at once [duplicate]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Why does everyone tell me writing code like this is a bad practice?
if (foo)
Bar();
//or
for(int i = 0 i < count; i++)
Bar(i);
My biggest argument for omitting the curly braces is that it can sometimes be twice as many lines with them. For example, here is some code to paint a glow effect for a label in C#.
using (Brush br = new SolidBrush(Color.FromArgb(15, GlowColor)))
{
for (int x = 0; x <= GlowAmount; x++)
{
for (int y = 0; y <= GlowAmount; y++)
{
g.DrawString(Text, this.Font, br, new Point(IconOffset + x, y));
}
}
}
//versus
using (Brush br = new SolidBrush(Color.FromArgb(15, GlowColor)))
for (int x = 0; x <= GlowAmount; x++)
for (int y = 0; y <= GlowAmount; y++)
g.DrawString(Text, this.Font, br, new Point(IconOffset + x, y));
You can also get the added benefit of chaining usings together without having to indent a million times.
using (Graphics g = Graphics.FromImage(bmp))
{
using (Brush brush = new SolidBrush(backgroundColor))
{
using (Pen pen = new Pen(Color.FromArgb(penColor)))
{
//do lots of work
}
}
}
//versus
using (Graphics g = Graphics.FromImage(bmp))
using (Brush brush = new SolidBrush(backgroundColor))
using (Pen pen = new Pen(Color.FromArgb(penColor)))
{
//do lots of work
}
The most common argument for curly braces revolves around maintance programming, and the problems that would ensue by inserting code between the original if statement and its intended result:
if (foo)
Bar();
Biz();
Questions:
Is it wrong to want to use the more compact syntax which the language offers? The people that design these languages are smart, I can't imagine they would put a feature which is always bad to use.
Should we or Shouldn't we write code so the lowest common denominator can understand and have no problems working with it?
Is there another argument that I'm missing?

Actually, the only time that's ever really bit me was when I was debugging, and commented out bar():
if(foo)
// bar();
doSomethingElse();
Other than that, I tend to use:
if(foo) bar();
Which takes care of the above case.
EDIT Thanks for clarifying the question, I agree, we should not write code to the lowest common denominator.

Speed of reading...
Aside from what has already been mentioned. At this point, I've already been conditioned to parse if statements with braces and white space. So I read:
if (condition)
{
DoSomething();
}
DoSomethingElse();
Slightly faster than I read:
if (condition) DoSomething();
DoSomethingElse();
I read it a little slower if it looks like this:
if (condition) DoSomething();
DoSomethingElse();
I read this significantly slower than the prior:
if (condition)
DoSomething();
DoSomethingElse();
beause I can't help but read it again just in-case and wonder if the author intended:
if (condition)
{
DoSomething();
DoSomethingElse();
}
Already covered in general, but when it comes to reading the below, I'll be looking into this for quite a while to make sure what the author intended. I may even hunt down the original author to confirm.
if (condition)
DoSomething();
DoSomethingElse();

If it's something small, write it like this:
if(foo()) bar();
If it's long enough to break into two lines, use braces.

I also used to think it's better to only use braces when really needed. But not anymore, the main reason, when you have a lot of code, it does make it more readable and you can parse over the code quicker when you have a consistent bracing style.
Another good reason for always using braces, besides someone adding a second statement to the if, is something like this could happen:
if(a)
if(b)
c();
else
d();
Did you notice that the else clause is actually that of the "if(b)"? You probably did, but would you trust anyone to be familiar with this gotcha?
So, if just for consistency and because you never know what unexpected things might happen when someone else (it's always the others that are stupid) changes the code, I always put braces, because it makes the source code more readable, quicker to parse by your brain. Only for the most simple if statements, like an if where a delegation is made or is switch-like, where you know the clause will never be extended, I would leave out the braces.

Lines are cheap. Processor power is cheap. Developer time is very expensive.
As a general rule, unless I am developing some absolutely resource / speed critical application, I would always err on the side of writing code that is
(a) Easy for any other developer to follow what I am doing
(b) Comment specific parts of the code that may need it
(c) Easy to debug if something goes wrong
(d) Easy to modify if it needs to be in future (i.e. adding / removing code)
The speed or academic elegance of the code is secondary to these factors from a Business perspective. This is not to say I set out to write clunky or ugly code, but this is MY order of priority.
By omitting curly braces in most instances, it for me makes (b), (c) and (d) more difficult (note not impossible however). I would say that using curly braces or not has not effect on (a).

This is not always considered a bad practice. The Mono Project Coding Guidelines suggests not to use curly braces if it's not necessary. The same for the GNU Coding Standards. I think it's a matter of personal taste as always with coding standards.

I prefer the clarity that the curly brace offers. You know exactly what is meant and don't have to guess if someone just goofed and left them off (and introduced a bug). The only time I omit them is when I put the if and action on the same line. I don't do that very often either. I actually prefer the whitespace introduced by putting the curly brace on its own line, though from years of K&R C-like programming, ending the line with a brace is a practice I have to work to overcome if the IDE doesn't enforce it for me.
if (condition) action(); // ok by me
if (condition) // normal/standard for me
{
action();
}

I think it's a matter of guidelines for the project you are working on and personal taste.
I usually omit them when they are not needed, except some cases like the following:
if (something)
just one statement; // i find this ugly
else
{
// many
// lines
// of code
}
i prefer
if (something)
{
just one statement; // looks better:)
}
else
{
// many
// lines
// of code
}

One of the instances where this can bite you is back in the old days of C/C++ macros. I know this is a C# question, but often coding standards carry over without the reasons why the standard was created in the first place.
If you aren't very careful when you create your macros, you can end up causing problems with if statements that don't use the {}.
#define BADLY_MADE_MACRO(x) function1(x); function2(x);
if (myCondition) BADLY_MADE_MACRO(myValue)
Now, don't get me wrong, I'm not saying that you should always do {} just to avoid this problem in C/C++, but I have had to deal with some very strange bugs because of this.

To be blunt I see it as:
Good programmers program defensively, Bad programmers don't.
Since there are several examples above and my own similar experiences with bugs related to forgetting braces then I learned the hard way to ALWAYS PUT BRACES.
Anything else is choosing personal style over safety and that's clearly bad programming.
Joel even mentions this in Making Wrong Code Look Wrong
Once you get bit by a bug because of missing braces you learn that missing braces look wrong because you know it's a potential place for another bug to occur.

I use to think the same way.
Until one day ( why is there always that "one day" that changes your life forever? ) we spend from 24 - 36 hours straight without sleep debugging production code only to find out someone didn't put braces combined with a search/replace change.
It was something like this.
if( debugEnabled )
println( "About to save 1 day of work to some very important place.");
saveDayData();
What came after was
if( debugEnabled )
// println( "About to save 1 day of work to some very important place.");
saveDayData();
It turns out that the system was generating 500 mb of logs daily and we were asked to stop it. The debug flag was not enough so a search and replace println was in order.
Still when the app went to production the debug flag was off and the important "saveDayData" was never called.
EDIT
Now the only place where I don't use the braces is in if/try construct.
if( object != null ) try {
object.close();
} catch( .....
After watching a superstar developer doing that.

I'm quite happy to:
foreach (Foo f in foos)
foreach (Bar b in bars)
if (f.Equals(b))
return true;
return false;
Personally, I don't see why
foreach (Foo f in foos)
{
foreach (Bar b in bars)
{
if (f.Equals(b))
{
return true;
}
}
}
return false;
is any more readable.
Yes, lines are free, but why should I have to scroll through pages and pages of code when it could be half the size?
If there is a difference in readability or maintainability then, sure, put braces in... but in this case I don't see any reason to.
Also, I will always put braces for nested if's where I have nested else's
if (condition1)
if (condition2)
doSomething();
else (condition2)
doSomethingElse();
vs
if (condition1)
if (condition2)
doSomething();
else (condition2)
doSomethingElse();
is terribly confusing, so I always write it as:
if (condition1)
{
if (condition2)
doSomething();
else (condition2)
doSomethingElse();
}
Whenever possible, I use ternary operators, but I never nest them.

I agree that "if you are smart enough to get someone to pay you to write code, you should be smart enough to not rely solely on indentation to see the flow of the code."
However... mistakes can be made, and this one is a pain to debug... especially if you're coming in looking at someone else's code.

I am impressed and humbled that my peers in this field of computer programming (you lot) are not daunted by the prospect of potential bugs when you skip the braces on single line blocks.
I suppose it means I'm not smart. I have made mistakes around this multiple times. I have debugged others' mistakes around this. I have watched software ship with bugs because of this (RDP to a machine running VS2002 and your watch window font will go wonky).
If I look at all the mistakes I've made that could have been avoided with a change in coding style, the list is very long. If I hadn't changed my approach in each of these cases, I probably would never have made it as a programmer. Again, I guess I'm not smart. To compensate, I have been a staunch user of braces on single-line blocks for a long time.
That said, some things have changed in the world that make the "thou shalt use braces on single-line blocks" rule less relevant today than when Moses brought it down to us:
Some popular languages make the issue go away by making the computer read the indentation, just like the programmer does (e.g. Python).
My editor automatically formats for me, so the chances of me getting mislead by indentation is much reduced.
TDD means that if I introduce a bug because I get confused by a single-line block, I'm much more likely to discover the bug quickly.
Refactoring and language expressiveness mean that my blocks are much shorter, and single-line blocks happen much more often than the used to. Hypothetically, with a ruthless application of ExtractMethod, I could possibly have only single-line blocks in my whole program. (I wonder what that would look like?)
In fact, there's a distinct benefit can come of refactoring ruthlessly & omitting braces on single-line blocks: when you see braces, a little alarm can go off in your head that says "complexity here! beware!". Imagine if this was the norm:
if (condition) Foo(); // normal, everyday code
if (condition)
{
// something non-trivial hapening; pay attention!
Foo();
Bar();
}
I'm opening myself to the idea of changing my coding convention to something like "single-line blocks may never have braces" or "if you can put the block on the same line as the condition, and it all fits within 80 characters, omit the braces". We'll see.

My philosophy is if it makes the code more readable, why not do it?
Obviously you have to draw the line somewhere, like finding that happy medium between concise and overly descriptive variable names. But brackets really do avoid errors and improve the readability of the code.
You can argue that people smart enough to be coders are going to be smart enough to avoid bugs that stem bracketless statements. But can you honestly say you've never been tripped up by something as simple as a spelling error? Minutia like this can be overwhelming when looking at large projects.

There are always exceptions, but I would argue against omitting braces only when it's in one of the forms:
if(x == y)
for(/* loop */)
{
//200 lines
}
//rampion's example:
for(/* loop */)
{
for(/* loop */)
for(/* loop */)
{
//several lines
}
}
Otherwise, I have no problem with it.

I occasionally use the very bottom code (multiple using statements), but other than that I always put the braces in. I just find it makes the code clearer. It's blatantly obvious from more than just indentation that a statement is part of a block (and thus probably part of an if etc).
I have seen the
if (...)
foo();
bar();
bug bite me (or rather "me and colleagues" - I didn't actually introduce the bug) once. This was despite the fact that our coding standards at the time recommended using braces everywhere. It took me a surprisingly long time to spot - because you see what you want to see. (This was about 10 years ago. Maybe I'd find it faster now.)
Of course if you use "brace at the end of the line" it reduces the extra lines incurred, but I personally dislike that style anyway. (I use it at work, and have found it less unpleasant than I expected, but it's still a bit unpleasant.)

Out of the three conventions:
if(addCurleyBraces()) bugFreeSofware.hooray();
and:
if(addCurleyBraces())
bugFreeSofware.hooray();
and (which represent any indentation style using an opening and a closing brace):
if(addCurleyBraces()) {
bugFreeSofware.hooray();
}
I prefer the last one as:
I find it easier to read if all the if-statements are written in a uniform way.
It may make the software a tiny bit more robust and bug free. However all modern IDE's and advanced text editors have nice auto-indenting features which I think everyone should use as long as it doesn't mess up comment formatting or go against team standards (in a lot of cases it's possible to create a custom formatting scheme and share it with the team). My point here is that if indentation is done correctly risk of bug introduction is reduced a bit.
I prefer the boolean expression and statement(s) to execute to be on different lines. I like to be able to mark a row for debugging purposes. Even if I'm using an IDE where I may mark a statement and step to it, it's an interactive operation and I might forget where I started to debug or at least it will take me a little bit more time to step through the code several times (as I have to mark the position manually each time during debugging).

Your main arguments against using braces are that they use additional lines and that they require additional indenting.
Lines are (almost) free, minimizing the number of lines in your code shouldn't be an objective.
And indentation is independent of brace usage. In your cascading 'using' example I still think you should be indenting them even when you omit the braces.

I'm a strong believer in writing tidy and concise code, but I would always use curly braces. I find that they are a convenient way of quickly seeing the scope in which a particular line of code exists. There is no ambiguity, it's just explicitly set out in front of you.
Some may say it is a case of preference, but I find the logical flow of a program much easier to follow if it is internally consistent, and I don't believe that it is consistent to write one IF statement like this;
if(x < y)
x = y;
else
y = x;
And another like this;
if(x < y)
{
x = y;
x++;
}
else
{
y = x;
y++;
}
I prefer to just pick one general style and stick with it :)

One of the main issues is when you have regions of one-liners and non-one liners,
along with separation from the control statment (for, if, what have you) and the end of the statment.
For example:
for (...)
{
for (...)
for (...)
{
// a couple pages of code
}
// which for block is ending here? A good text editor will tell you,
// but it's not obvious when you're reading the code
}

I used to be a huge supporter of "curly braces are a MUST!", but since adopting unit testing, I find that my unit tests protect braceless statements from the scenarios like:
if (foo)
snafu();
bar();
With good unit tests, I can confidently omit curly braces for simple statements to improve readability (yes, that can be subjective).
Alternatively, for something like the above, I would likely inline that to look like:
if (foo) snafu();
That way, the developer who needs to add bar() to the condition, would be more apt to recognize the lack of curly braces, and add them.

Okay, this is an old question that has been answered to death. I have something to add.
First I just have to say USE THE BRACES. They can only help readability, and readability (for yourself and others!) should be very high on your priority list unless you're writing assembly. Unreadable code always, always leads to bugs. If you find that braces make your code take up too much space, your methods are probably too long. Most or all of any method should fit within one screen height if you're doing it right, and Find (F3) is your friend.
Now for my addition: There is a problem with this:
if (foo) bar();
Try setting a breakpoint that will only be hit if bar() is going to run. You can do this in C# by putting the cursor on the second half of the code, but that is not obvious and is a bit of a pain. In C++ you couldn't do it at all. One of our most senior developers working on C++ code insists on breaking 'if' statements into two lines for this reason. And I agree with him.
So do this:
if (foo)
{
bar(); //It is easy to put a breakpoint here, and that is useful.
}

Let's say you have some code:
if (foo)
bar();
and then someone else comes along and adds:
if (foo)
snafu();
bar();
According to the way it's written, bar(); is now executed unconditionally. By including the curly braces, you prevent this kind of accidental error. Code should be written in such a way as to make such mistakes difficult or impossible to make. If I was doing a code review and saw the missing braces, especially spread across multiple lines, I would create a defect. In cases where it is justified, keep it on one line so that the chance of making such an error is again kept to a minimum.

I always omit them when appropriate, such as in your first example. Clean, concise code I can see and understand by glancing at is easier to maintain, debug and understand than code I have to scroll through and read line by line. I think most programmers will agree with this.
It is easy for it to get out of hand if you start doing multiple nesting, if/else clauses and so on, but I think most programmers should be able to tell where to draw the line.
I see it kind of like the argument for if ( foo == 0 ) vs if ( 0 == foo ). The latter may prevent bugs for new programmers (and maybe even occasionally for veterans), while the former is easier to quickly read and understand when you're maintaining code.

Reducing lines is not really a good argument for dropping braces. If your method is too big, it should probably be refactored into smaller pieces or restructured. Doing that will no doubt increase readability more than simply taking out braces.

Use some personal judgement.
if (foo)
bar();
is fine by itself. Unless you're really worried about morons putting in something like this later:
if (foo)
bar();
baz();
If you're not worried about morons, you're fine (I'm not -- if they can't get basic code syntax right, this is the least of their problems)>
In exchange, it's a lot more readable.
The rest of the time:
if (foo) {
bar();
baz();
}
Which has been my favorite as long as I can remember. Additionally:
if (foo) {
bar();
baz();
} else {
qux();
}
Works for me.
Vertical space by itself isn't terribly relevant, readability is. The opening brace on a line by itself just stops the conversation for a syntactic element, until your eye moves down to the next line. Not what I like.

in order to keep the code with braces from taking up lots of space, I use the technique recommended in the book Code Complete:
if (...) {
foo();
bar();
}
else {
...
}

Most times it is ingrained as a coding standard, whether for a company or an FOSS project.
Ultimately someone else will need to grok your code and it is a major time drain for each developer to have to figure out the specific style of the section of code they are working on.
Also, imagine that someone is going between Python and a Cish language more than once a day... In Python indenting is part of the block symantics of the language and it would be quite easy to make a mistake like the one you quote.

Err on the side of more secure - just one more bug you potentially won't have to fix.
I personally feel more secure if all of my blocks are wrapped in curlys. Even for one-liners, these are simple notations that easily prevent mistakes. It makes the code more readable in the sense that you clearly see what is in the block as not to confuse the body of the block with the following statements outside of the block.
If I have a one-liner, I typically format it as follows:
if( some_condition ) { do_some_operation; }
If the line is just too cumbersome then use the following:
if( some_condition )
{
do_some_operation;
}

Javascript - generating expressions without operator overloading

I'm using three.js in a js project and I'm trying to calculate if a vector is still in an area like this
var THRESHOLD = 10;
if(!is_in_rect(camera.position - forward * THRESHOLD)))
// do something
where camera.position and foward are THREE.Vector3 objects.
The problem with the approach above, although very readable, is that it's not working since js doesn't support operator overloading. I have to write something like
if(!in_rect(camera.position.clone().add(forward.clone().multiplyScalar(THRESHOLD)))
which looks kinda ugly to me.
Is there any other idiomatic way of doing this in js that I'm missing?

From the page you linked to:
.addScaledVector ( v, s )
Adds the multiple of v and s to this vector
so a bit better is:
camera.position.clone().addScaledVector(forward,THRESHOLD)
Also, there's no real reason to clone forward, as that won't be changed.
If I'm following what #T.J. is saying, and you want something more general, than my answer would be no, if idomatic means using + and -, if we're strictly sticking to JS. You could build your own framework to make things idomatic, such as a general addition operator:
var add = function(x,y):
try {
var sum = x + y;
if ( s != undefined ) { return sum; }
#otherwise
sum = x.clone().add(y);
} catch {
#Otherwise threw something
sum = x.add(y) #maybe another exception? nest try/catch.
}
}
But this is a lot of work, as you would have to type check a lot since JS can add up stuff with impunity. Just trying to return x+y will often be undefined. In my example perhaps testing for add functions before simple additions may be better.
This way you can create the idiom you like, if you think it's worth it, and use your add for everything (instead of + in my example). Probably grow it as you code.

Is there any other idiomatic way of doing this in js that I'm missing?
Not really, no; you'd basically have to write yourself an expression parser, or use one that's already been written.
A couple of notes on that:
Doing that might be a bit easier with ES2015+'s template literals and tagged template functions, since it would do some of the parsing for you. For instance, you might be able to give yourself tag function that would let you write:
if(!is_in_rect(threval`${camera.position} - ${forward} * ${THRESHOLD}`)))
threval would receive an array of the raw strings in that template, followed by the values of camera.position, forward, and THRESHOLD. So you could use that information to build up the sequence. But it would be non-trivial.
You could write yourself a Babel plugin to make your expressions first-class productions, and transpile. The advantage to that is that Babel provides a robust parsing infrastructure and tooling support.

Why test char equals the same char?

Reading through some JavaScript from an ecommerce hosting company and came across this:
function add_wishlist()
{
if ('1' == '1') // <-- What is this?
{
window.open('addtowishlist.asp?itemid=137','popup','height=300,width=550,location=no,scrollbars=no,menubars=no,toolbars=no,resizable=yes');
}
else
{
document.add.action = "add_cart.asp?action=addWishList";
document.add.submit();
}
}
From my basic understanding of JavaScript, the == equality operator will attempt type conversion if required then compare the values. In this case, the character 1 compared to the character 1, which seems like it will always be true.
I feel I might be missing something because why have an else clause if the code is always unreachable? This appears to have been purposeful code as I can't imagine it's easy to accidentally write this comparison. However, there does appear to be some inherent sloppiness to this code since JavaScript programmers should be in the habit of writing curly braces on the same line to avoid any possible semicolon insertion quirks...
Am I missing something here? Or is it just sloppy code?

Sometimes always true statements are used by developers to temporarily disable a branch of code. IMO, comments are a better way to do this.
Another possibility is that this is code generated by a tool, and this is the emitted code they got when disabling a feature.

Should a variable commonly evaluated as true in the "if" or the "else"?

If I have a variable from a dataset that evaluates as true most of the time should I put it in the "if" clause or the "else" clause. Is one faster that the other? I am sure it depends on things like the JavaScript engine and/or the operating system as it is coverted to Machine language.
Like this:
var usualyTrue;
// some more code here...
if(usualTrue)
//do something
else
//do something else
or like this:
var usualyTrue;
// some more code here...
if(!usualTrue)
//do something
else
//do something else

It generally doesn't matter, so you should do whatever makes it the most readable.
Three reasons.
The compiler is smart enough that it won't care much which of these conditions is the case, in most cases (unless you're doing millions/billions of comparisons, booleans are the cheapest evaluations there are)
Branching (at the ISA level) really does mean this doesn't matter. Simple comparisons like this are essentially evaluated simultaneously through pipelining.
The amount of time you would spend optimizing something like this would be far better spent thinking "how can I reduce the number of AJAX calls I make?" or "am I looping through the DOM unnecessarily at some point?"
If you're just curious about what is produced, you could compile the JS yourself using something like Rhino.

You shouldn't worry about which is faster, since it will be marginally faster if there is any difference at all, you're just falling into the trap of premature optimization.
Current browsers (and compilers/interpreters for other languages besides JavaScript) have all sorts of optimizations for boolean logic so you don't have to worry about that.

There's really no serious performance difference, but checking if(usualTrue) seems to make more sense. If you know what is usually true, you can avoid unnecessarily evaluating the frequently false expression.

Write for readability
There is no performance difference either way, what should matter to you is writing for readability i.e. using meaningful variable names and appropriate logic.
e.g.
var errorFound;
// some more code here...
if(errorFound) {
//do something
} else {
//do something else
}
Avoid double-negatives though:
var noErrorFound;
// some more code here...
if(!noErrorFound) {
//do something
} else {
//do something else
}
As that makes it hard to read - to enter the else you're looking for !!noErrorFound - that just makes debugging harder :).

Conditional Operators in Javascript

Is it ok to use conditional operators like a statement like so?
(x == y) ? alert("yo!") : alert("meh!");
Or is it more correct to use it to assign a value like so?
z = (x == y) ? "yo!" : "meh!";
If it's not incorrect to use it like a statement, then is it possible to add more than one line of code for execution like so? Is it more correct to use ifthen and switch statements for multiple lines of code?
(x == y) ? (alert("yo!"), document.write("woot!")) : (alert("meh!"), document.write("blah!"));

Conditional operators are intentionally succinct and especially useful for assignments:
var a = x ? 1 : 2;
Using them to conditionally run functions, while possible, should, for the sake of readability be done using IF/ELSE statements:
// This is possible but IMO not best practice:
X ? doSomething() : doSomethingElse();
While long-winded, most of the time, this is the better solution:
if (X) {
doSomething();
} else {
doSomethingElse();
}
One notable benefit to the IF/ELSE structure is that you can add additional tasks under each condition with minimal hassle.
Your last snippet is also possible but it looks somewhat long-winded and, again, might be better suited to a more conventional logical structure; like an IF/ELSE block.
That said, a conditional operator can still be readable, e.g.
(something && somethingElse > 2) ?
doSomeLongFunctionName()
: doSomeOtherLongFunctionName();
In the end, like many things, it's down to personal preference. Always remember that the code you're writing is not just for you; other developers might have to wade through it in the future; try and make it as readable as possible.

JavaScript won't prevent you from doing it, but it's very a unusual practice that will confuse anyone reading your code.
The conditional operator is almost always used for selecting two alternative values, not statements. An if statement is preferred for conditional branching of statements.
As to your last question, yes, if you really must, you can abuse the [] construct:
(x == y) ? [alert("yo!"), document.write("woot!")] : otherstuff();
But please don't. 8-)

It is entirely up to you, you can do it either way. You just have to ask yourself, though, does this style follow company guidelines, and how readable do you want this code to be?
Using if statements is way more readable.
Personally, I only use the ternary operator for simple and quick true/false conditions--where doing so makes sense--or where I need something "inline".

Either of the two methods are acceptable although you could have also written:
alert((x == y) ? "yo!" : "meh!");
Aside from that I would never recommend using an inline conditional for multiline statements, just use a standard if/else block. Given the syntax you entered isn't valid JS either, you could have placed the multiple statements into anonymous methods and yada yada, then you enter into a tangled mess of nearly unmanageable and unnecessarily difficult code. So again, standard if/else.

I agree with both Chris and J-P that:
Conditional operators are handy for short statements. J-P's variable assignment is a great example: var a = x ? 1 : 2;
Multi-statement clauses should be separated on to separate lines, for readability.
Conditional operators can be made readable as multiline statements with the right indentation, but if/else syntax is much more familiar to most developers. Readability is about matching the expectations of your reader, so familiarity is important.
I will add that multi-line conditional operators leave you open to semicolon insertion errors. Check out the JSLint documentation (see the section on "Line Breaking") for more on this. If you must use a multi-line conditional operator, make sure operators are at the end of each line. I would rework J-P's multi-line example thusly:
(something && somethingElse > 2) ?
doSomeLongFunctionName() :
doSomeOtherLongFunctionName();
As has been mentioned, there are many style guides out there and you can choose whichever you prefer. Some choices are more error-prone than others, however. Definitely take a close look at that JSLint documentation; it is a very well-thought-out style guide, and if you adhere to it, you can even use the JSLint tool to automatically check your code for potential problems.

We Keep Coding

JavaScript is the programming language of the Web.