To make it a bit more formal and hopefully prevent it from being lost in the mail archives, let's update our QML coding conventions:
https://codereview.qt-project.org/#/c/173027/ > -----Original Message----- > From: Development [mailto:development-bounces+mitch.curtis=qt.io@qt- > project.org] On Behalf Of Kai Koehne > Sent: Wednesday, 5 October 2016 3:23 PM > To: Viktor Engelmann <viktor.engelm...@qt.io>; development@qt- > project.org > Subject: [Development] [closed] Using semicolons in JS (QML) > > Hi, > > Alright, to close this thread: It seems the majority agrees that using > semicolons after JS statement inside a Javascript {} block is a good idea. The > suggestion is to follow this in new code. Personally, I will point out > missing ; > as defects in reviews. > > Regards > > Kai > > > -----Original Message----- > > From: Development [mailto:development-bounces+kai.koehne=qt.io@qt- > > project.org] On Behalf Of Viktor Engelmann > > Sent: Tuesday, October 04, 2016 3:51 PM > > To: development@qt-project.org > > Subject: Re: [Development] Using semicolons in JS (QML) > > > > Am 30.09.2016 um 17:43 schrieb Shawn Rutledge: > > > > > > Back in Nokia times it was said that we shouldn't use semicolons, > > because it would speed up the parsing [...] > > > > > > As someone who has written countless parsers, I *highly* doubt that > > this is actually true. Indenting with tabs was also believed to be > > *much* slower than indenting with spaces (which makes absolutely no > > sense), and that measurement result turned out to be caused by a bug > > in firebird. I bet this is also just an urban legend. Someone probably > > thought "hey - one less character to read - must be faster to load", > > but as André pointed out, the error recovery will most likely cost > > more than what you save. Unless if the behavior is baked into the LR(1) > state-graph maybe. > > > > Also I don't think it is good style to write code that doesn't conform > > to the actual language, just because *most* parsers correctly *guess* > > what you meant *most* of the time (except in those pathological > > cases...). I think that you should *always* tell parsers *precisely* > > what you mean and don't rely on it's guessing ability. For reference: > > The Mariner 1 crash (which cost $80 > > million) was supposedly caused by an error that could have been caught > > by static analysis at compile time, but was just "guessed away" wrongly. > > > > > > Anyhow, I believe that we have spent more time on this debate than > > will ever be saved by omitting semicolons. > > > > > > Viktor > > > > > > -- > > > > > > > > Viktor Engelmann > > Software Engineer > > > > The Qt Company GmbH > > Rudower Chaussee 13 > > D-12489 Berlin > > viktor.engelm...@qt.io <mailto:viktor.engelm...@qt.io> > > +49 151 26784521 > > http://qt.io > > > > Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der > > Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB > > 144331 B <http://qt.io> <http://www.facebook.com/Qt> > > <http://www.twitter.com/qtproject> > > <https://www.linkedin.com/company/the-qt-company/> > > <https://plus.google.com/104580575722059274792> > > <https://www.youtube.com/QtStudios> > > <http://qtworldsummit.com/> > > Qt World Summit 2016 | Pier 27, San Francisco, CA Experience > > Exponential Potential on October 18-20 www.qtworldsummit.com > > <http://www.qtworldsummit.com> > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development