[Development] [closed] Using semicolons in JS (QML)

[André Somers]

So, now we need one of these QUIPs to document the descision if I 
understand it correctly ?

André


Op 06/10/2016 om 10:58 schreef Mitch Curtis:
> 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 at qt-
>> project.org] On Behalf Of Kai Koehne
>> Sent: Wednesday, 5 October 2016 3:23 PM
>> To: Viktor Engelmann <viktor.engelmann at qt.io>; development at 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 at qt-
>>> project.org] On Behalf Of Viktor Engelmann
>>> Sent: Tuesday, October 04, 2016 3:51 PM
>>> To: development at 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.Engelmann at qt.io <mailto:Viktor.Engelmann at 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 at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development