<div dir="ltr">You lost me... Why do you need to do that? JavaScript is not my daily driver, so excuse my ignorance!</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 8, 2014 at 1:56 PM,  <span dir="ltr"><<a href="mailto:ryanstortz@electrifiedpulse.com" target="_blank">ryanstortz@electrifiedpulse.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><a href="http://vertx.io" target="_blank">vertx.io</a> sounds great! I haven't used it before, would love to get started!<br>

<br>
Here's how I get around javascript's return blunder:<br>
<br>
this will fail:<br>
<br>
return<br>
{<br>
  allofmyimportantinformation: false<br>
}<br>
<br>
OR/AND operator(s) save the day! :<br>
<br>
return true &&<br>
{<br>
  allofmyimportantinformation: true<br>
}<br>
<br>
OR<br>
<br>
return {} &&<br>
{<br>
  allofmyimportantinformation: true<br>
}<br>
<br>
MORE..<br>
<br>
return 0||<br>
return 1&&<br>
return void 'blunder!!!' ||<br>
<br>
<br>
Ryan<div><div class="h5"><br>
<br>
On 2014-07-08 11:29, Deven Phillips wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
FYI, I like the idea of using Vert.x for this project because it<br>
supports writing the code in many of the languages that this group has<br>
an interest in:<br>
<br>
Java<br>
Ruby<br>
Python<br>
Groovy<br>
PHP<br>
JavaScript<br>
Scala<br>
Clojure<br>
<br>
That means that almost everyone can be productive and helpful in<br>
contributing to the project...<br>
<br>
Anyone else have opinions?<br>
<br>
Deven<br>
<br>
On Tue, Jul 8, 2014 at 1:23 PM, Deven Phillips<br>
<<a href="mailto:deven.phillips@gmail.com" target="_blank">deven.phillips@gmail.com</a>> wrote:<br>
<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
I like Douglas Crockford’s JS style guidelines (from JavaScript:<br>
The Good Parts, 94)...<br>
<br>
Excerpt:<br>
<br>
I indented the contents of blocks and object literals four spaces.<br>
I placed a space between if and ( so that the if didn't look<br>
like a function invocation. Only in invocations do I<br>
make ( adjacent with the preceding symbol. I put spaces around all<br>
infix operators except for . and [, which do not get spaces<br>
because they have higher precedence. I use a space after every comma<br>
and colon.<br>
<br>
I put at most one statement on a line. Multiple statements on a line<br>
can be misread. If a statement doesn't fit on a line, I will break<br>
it after a comma or a binary operator. That gives more protection<br>
against copy/paste errors that are masked by semicolon insertion.<br>
(The tragedy of semicolon insertion will be revealed in Appendix A<br></div></div>
[1].) I indent the remainder of the statement an extra four spaces,<div><div class="h5"><br>
or eight spaces if four would be ambiguous (such as a line break in<br>
the condition part of an if statement).<br>
<br>
I always use blocks with structured statements such<br>
as if and while because it is less error prone. I have seen:<br>
<br>
if (a)<br>
b( );<br>
<br>
become:<br>
<br>
if (a)<br>
b( );<br>
c( );<br>
<br>
which is an error that is very difficult to spot. It looks like:<br>
<br>
if (a) {<br>
b( );<br>
c( );<br>
}<br>
<br>
but it means:<br>
<br>
if (a) {<br>
b( );<br>
}<br>
c( );<br>
<br>
Code that appears to mean one thing but actually means another is<br>
likely to cause bugs. A pair of braces is really cheap protection<br>
against bugs that can be expensive to find.<br>
<br>
I always use the K&R style, putting the { at the end of a line<br>
instead of the front, because it avoids a horrible design blunder in<br>
JavaScript's return statement.<br>
<br>
I included some comments. I like to put comments in my programs to<br>
leave information that will be read at a later time by people<br>
(possibly myself) who will need to understand what I was thinking.<br>
Sometimes I think about comments as a time machine that I use to<br>
send important messages to future me.<br>
<br>
I struggle to keep comments up-to-date. Erroneous comments can make<br>
programs even harder to read and understand. I can't afford that.<br>
<br>
I tried to not waste your time with useless comments like this:<br>
<br>
i = 0; // Set i to zero.<br>
<br>
In JavaScript, I prefer to use line comments. I reserve block<br>
comments for formal documentation and for commenting out.<br>
<br>
I prefer to make the structure of my programs self-illuminating,<br>
eliminating the need for comments. I am not always successful, so<br>
while my programs are awaiting perfection, I am writing comments.<br>
<br>
JavaScript has C syntax, but its blocks don't have scope. So, the<br>
convention that variables should be declared at their first use is<br>
really bad advice in JavaScript. JavaScript has function scope, but<br>
not block scope, so I declare all of my variables at the beginning<br>
of each function. JavaScript allows variables to be declared after<br>
they are used. That feels like a mistake to me, and I don't want to<br>
write programs that look like mistakes. I want my mistakes to stand<br>
out. Similarly, I never use an assignment expression in the<br>
condition part of an if because:<br>
<br>
if (a = b) { ... }<br>
<br>
is probably intended to be:<br>
<br>
if (a === b) { ... }<br>
<br>
I want to avoid idioms that look like mistakes.<br>
<br>
I never allow switch cases to fall through to the next case. I once<br>
found a bug in my code caused by an unintended fall through<br>
immediately after having made a vigorous speech about why fall<br>
through was sometimes useful. I was fortunate in that I was able to<br>
learn from the experience. When reviewing the features of a<br>
language, I now pay special attention to features that are sometimes<br>
useful but occasionally dangerous. Those are the worst<br>
parts because it is difficult to tell whether they are being used<br>
correctly. That is a place where bugs hide.<br>
</div></div></blockquote>
<br>
<br>
<br>
Links:<br>
------<br>
[1] <a href="http://my.safaribooksonline.com/9780596517748/awful_parts#awful_parts" target="_blank">http://my.safaribooksonline.<u></u>com/9780596517748/awful_parts#<u></u>awful_parts</a><div class=""><br>
<br>
______________________________<u></u>_________________<br>
KyOSS-Discuss mailing list<br>
<a href="mailto:KyOSS-Discuss@kyoss.org" target="_blank">KyOSS-Discuss@kyoss.org</a><br>
Subscribe by sending email to <a href="mailto:kyoss-discuss-subscribe@kyoss.org" target="_blank">kyoss-discuss-subscribe@kyoss.<u></u>org</a><br>
Unsubscribe by sending email (from the address you wish to<br>
unsubscribe) to <a href="mailto:kyoss-discuss-unsubscribe@kyoss.org" target="_blank">kyoss-discuss-unsubscribe@<u></u>kyoss.org</a><br>
Difficulty unsubscribing? Check your email headers for originally-to<br>
address in case you are forwarding your mail.<br>
More options at <a href="http://kyoss.org/cgi-bin/mailman/listinfo/kyoss-discuss" target="_blank">http://kyoss.org/cgi-bin/<u></u>mailman/listinfo/kyoss-discuss</a><br>
</div></blockquote><div class="HOEnZb"><div class="h5">
______________________________<u></u>_________________<br>
KyOSS-Discuss mailing list<br>
<a href="mailto:KyOSS-Discuss@kyoss.org" target="_blank">KyOSS-Discuss@kyoss.org</a><br>
Subscribe by sending email to <a href="mailto:kyoss-discuss-subscribe@kyoss.org" target="_blank">kyoss-discuss-subscribe@kyoss.<u></u>org</a><br>
Unsubscribe by sending email (from the address you wish to unsubscribe) to <a href="mailto:kyoss-discuss-unsubscribe@kyoss.org" target="_blank">kyoss-discuss-unsubscribe@<u></u>kyoss.org</a><br>
Difficulty unsubscribing? Check your email headers for originally-to address in case you are forwarding your mail.<br>
More options at <a href="http://kyoss.org/cgi-bin/mailman/listinfo/kyoss-discuss" target="_blank">http://kyoss.org/cgi-bin/<u></u>mailman/listinfo/kyoss-discuss</a></div></div></blockquote></div><br></div>