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;
}
Related
I would really hear some opinions on which of the following solutions is more efficient in JavaScript/TypeScript:
function whatever(param) {
if (param === x) {
doStuff();
}
}
or
function whatever(param) {
if (param !== x) { return false; }
doStuff();
}
Obviously the second one reduces the number of blocks and improves code readability, but does it offer any benefits or drawbacks compared to the first one?
In assembly you'd write both as:
// first
whatever:
CP x, param
JP nz, whatever2
CALL doStuff
whatever2:
RET
// second:
whatever:
CP x, param
JP z, whatever2
RET
whatever2:
CALL doStuff
RET
So while the first one uses 4 instructions, the second uses 5. So in case the JS engine is able to optimize it down to this optimal bytecode (very unlikely, but it makes estimations easier), the second one will be 1 tick slower, which is less than a nanosecond.
Here is a test where I run the comparison 10000 times.
The difference is pretty much non-existant.
There is no significant difference in efficiency, even if you have more than one of these preconditions in your function. No matter what language you use. Some compilers will probably even generate the same machine instructions from both versions.
Stop thinking about efficiency too much. Think about readability and maintainability!
It depends on the use case here, I don't think there is much difference in the context of performance or code readability.
I would personally go with the second approach as it also reduces indentations. Indentation gives me a clear indication of initialization of newer block. If I notice a new indent, I would assume there should be a for loop here or an if statement.
If the code is part of the main flow or the most common flow, I wouldn't want that to be further indented.
Again, All this is my personal style guide rules which have helped me to be able to deduce the code logic faster.
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.
Is there any benefit of doing so and can it lead to readability concerns?
Labels are generally used in JavaScript to break from an outer loop. For example:
while (true) {
while (true) {
if (someCondition) break;
}
}
In this program you'll only break from the inner loop. The outer loop will loop infinitely. Sometimes however you may wish to break from the outer loop instead of the inner loop. You use labels for this purpose:
loop: while (true) {
while (true) {
if (someCondition) break loop;
}
}
That being said if you have lots of nested loops or switch cases then using labels does in fact help with code readability even though it may not actually affect the program itself.
Take the code in this question for example: https://codereview.stackexchange.com/q/14532/15640
Here we have a switch case in a for loop and although it using we never need to break out of the for loop labelling the loop and the switch case might help some people. For others it's just a distraction.
In the end it boils down to your style of programming. Beginners usually like to label everything. More experience programmers find too many comments and labels annoying.
Steve Yegge actually wrote an entire blog post on this. You may find it very interesting: http://steve-yegge.blogspot.in/2008/02/portrait-of-n00b.html
Try coding without comments: http://www.codinghorror.com/blog/2008/07/coding-without-comments.html
While I don't believe in too many absolutes in coding, I will say that it is rare that I'd use a label in Javascript.
In fact, I don't believe I've ever used them at all the language.
Thanks to the powerful structures given, for ... for ... in while do ... while if ... else and the ability to do an early return almost anything that you'd need a label for can be written in a cleaner structure.
I'm hard-pressed to consider a time where requiring nested loops, and breaking the outer by name from within the inner is necessary, versus, perhaps a simple check of a value at the bottom of the outer loop, to decide whether to continue or not...
Typically, that structure is going to be easier to follow than break third_from_outer_loop; or continue loop_that_is_two_loops_higher.
If you're at a point where you're ready to break the outermost loop from the innermost, then why not just return early?
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 10 years ago.
So I have been writing in JavaScript for the last 5 years and am all self taught. The one problem I have come across as I meet more and more programmers. I find that I am not always coding things the best way possible.
I have been trying to figure out what is the best way to program a single line if statement in JS. I do not care about readability and the project is not open source, so I am not worried about others adding to it.
How I usually write my statements
condition = true;
if (condition)
runFunction();
else
runSecondFunction();
But I have found that everyone keeps telling me to use the brackets. I have been writing this off because they always throw in the following line as well "It makes it easier to read"
condition = true;
if (condition) {
runFunction();
}else{
runSecondFunction();
}
And lastly someone finally said to me that I should write the if statements to more closely match how they I written in C# which looks like the following
condition = true;
if (condition)
{
runFunction();
}
else
{
runSecondFunction();
}
And of course there is the shorthand, but I usually only use it for toggling variables like this
condition = true;
(condition) ? condition = false : condition = true;
but would it be better to use the shorthand for regular if statements as well. For example:
condition = true;
(condition) ? runFunction() : runSecondFunction();
So the question is
Out of all of the many ways to write a single line of JavaScript which is the best way to program it to run the fastest. I do not care about readability, so please don't say it is recommend to write it this way or that way because it is easier to read. Please also cite examples of why one way is faster or slower than another.
TO BE CLEAR
It is not that I don't care about readability is that none of those if statements are hard for me to read, they do make sense to me in all versions. So what some of you may consider hard to read I may not. This is what brings me to my next point, since none of those are hard for me to read, maybe I should write it the best way for JS to handle it.
For example I found that JS takes longer to run
counter++;
then it does
counter = counter + 1;
So finally to be clear I don't have a problem to reading any of these and I would just like to know which is best for JS to handle.
Take look at some jsperf tests:
braces vs no braces
ternary vs if
if vs boolean
They all seem to be relatively equal (aside from the boolean version being slower in the test I just ran), so I would go with whatever you like the look of best.
Your shorthand can be shortened:
Instead of:
(condition) ? condition = false : condition = true;
Try:
condition = condition ? false : true;
var a = condition ? 'conditionTrueValue' : 'conditionFalseValue';
// Or in this case, since you're just toggling the boolean:
condition = !condition;
Instead of:
(condition) ? runFunction() : runSecondFunction();
You can save a few characters like this:
(condition ? runFunction : runSecondFunction)();
Now, the performance difference on this, if any, is going to be insignificant.
Make your code readable. You'll be glad you did if you have to get back to your code in a year.
I usually get annoyed by convetion to put every curly bracket in seperate line, and I dont like that closing curly bracked has something afterwards. In addition, I dont like when they are not used at all.
This would me by way.
condition = true;
if (condition) {
runFunction();
}
else {
runSecondFunction();
}
When question is about terniary, then I have to say, that I use it only when there are no functions involved in conditions or results.
result = (number == 521 : "equal to 521" : "some other number");
I care about readability of my code, it matters, when you have file with many thousand lines of code, that looks quite similar - it is hard to debug or upgrade code, if it is unreadable.
If you 'truely' don't care about readability/maintainability then just write it the way that feel the most comfortable.
From my experience programming, the reason why people recommend using the the braces is really for maintainability, when someone has to add a block of code for the if statement, one argument was that if you type it once, you won't have to remember to insert it when you need a block of code rather than a single statement.
I recommend using the form below because Javascript has some quirks with braces (from memory), I believe it was to do with the concept of closure/functions) certain codes won't run. It caught me by surprised when I was debugging my broken code and then I read up on it but that was a long time ago.
if (expression) {
}
As for the performance factor, I believe that is more to do with the logic and code that is being executed and not the way you write the if statement.
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)) { ... }