+1 for adding semicolons, makes the code more readable.
@prabhjyot we may need to review the whole eslintrc and improve the style
guidelines.
Thanks & Regards,
RK
On Sat, Feb 17, 2018 at 12:00 PM, Jongyoul Lee <jongy...@gmail.com> wrote:
> Hi,
>
> I like to this kind of discussion. Currently, we don't have strict rules
> for developing frontend and it might cause a problem. I hope you could
> summarize and fix all of these issues.
>
> Thanks,
> JL
>
> On Fri, Feb 16, 2018 at 10:02 PM, Prabhjyot Singh <
> prabhjyotsi...@gmail.com>
> wrote:
>
> > Dear Zeppelin devs,
> >
> > In our current implementation of "eslintrc" semicolons disallow, and
> > generally, there are two schools of thought. The first is that we should
> > treat ASI as if it didn’t exist and always include semicolons manually.
> The
> > rationale is that it’s easier to always include semicolons than to try to
> > remember when they are or are not required, and thus decreases the
> > possibility of introducing an error.
> >
> > However, the ASI mechanism can sometimes be tricky to people who are
> using
> > semicolons. For example, consider this code:
> >
> > *return*
> > *{*
> > * name: "ESLint"*
> > *};*
> > This may look like a return statement that returns an object literal,
> > however, the JavaScript engine will interpret this code as:
> >
> > *return;*
> > *{*
> > * name: "ESLint";*
> > *}*
> > Effectively, a semicolon is inserted after the return statement, causing
> > the code below it (a labeled literal inside a block) to be unreachable.
> > This rule and the no-unreachable rule will protect your code from such
> > cases.
> >
> >
> > Want to know your opinion on should we change this (eslintrc) to always
> > allow semicolons, which will make JS less error/accident prone and more
> > readable.
> >
> >
> > --
> > Thankx and Regards,
> >
> > Prabhjyot Singh
> >
>
>
>
> --
> 이종열, Jongyoul Lee, 李宗烈
> http://madeng.net
>
