Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>In reading:</p> <ul> <li><p>You might not be used to that coding style, and might think that this executes the two functions:</p> <pre><code>if(foo) bar(); baz(); </code></pre></li> <li><p>Since JS has automatic semicolon insertion, there are even murkier circumstances. I, for instance, am not comfortable with what ASI would do to this code, even if I can reason it out:</p> <pre><code>if(foo) bar() baz() </code></pre> <p>It is not impossible to figure out or even hard if you know what ASI does, but ASI is a nontrivial algorithm. Having to run it in your head is expensive in terms of time, so it's better if you simply avoid ambiguous (in this sense, not ambiguous as per the ECMA-262 spec) situations.</p></li> <li><p>It makes your lines longer than they need to be. This may be considered a non-issue depending on your coding conventions, if your condition is long, and your statement is as well, the resulting single-line statement will be more taxing on the eyes to read (it is well known that your eyes have difficulty reading very lone lines, hence paragraphing).</p> <p>You can, if you for some reason despite braces, still use something of the form:</p> <pre><code>if(foo) bar(); </code></pre> <p>And that is virtually identical to the code you had, but I see no reason, at that point, not to just put the braces there.</p></li> </ul> <p>In writing:</p> <ul> <li><p>When you need to add another statement, it is not the case that you'll simply write it. You will have to refactor the surrounding area in order to do this. Again, this is not hard at all, but it is something extra to think about, which is not related to neither your problem nor your solution of the problem, it is merely a syntactical quirk.</p> <p>I think you already get the point, but it would be this scenario.</p> <p>Initial code:</p> <pre><code>if(foo) bar(); </code></pre> <p>Changed code:</p> <pre><code>if(foo) bar(); baz(); </code></pre> <p>You can see the problem clearly, but it might not necessarily pop up in a routine code review. If your testcases don't cover this specific codepath, this might get pushed to production because of repeated coder oversights, which are made easier by not requiring blocks be delimited explicitly. The solution you'd could adopt, as you have, is to say something like <code>if(foo) bar() &amp;&amp; baz()</code>, but that would fail if <code>bar()</code> is falsy, so you end up with ugly stuff like <code>if(foo) (bar(), baz());</code> which works, but is decidedly very ugly.</p></li> </ul> <hr> <p>Personally, I use single-line <code>if</code> statements solely when the line is very short, and the algorithm itself is short as well. Something like <code>if(extra_loop) --i;</code> or <code>if(!valid) break;</code> When you start adding <code>else</code>s to these single-line ifs, the structure becomes more and more dangerous to manipulate. </p> <p>In short, you can use it, but use it knowing the pros and cons, just like any other tool.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload