JavaScript function names - Developers

Michal Čihař

11 Aug 11 Aug

4:43 p.m.

Hi Isaac Bennetch píše v Pá 11. 08. 2017 v 09:28 -0400:

I was looking at some of the JavaScript function names, in particular in js/pma/move.js and the names are a mess;

Well actually whole designer code is a bit messy - it's only piece of our code which doesn't use jQuery and other modern features (except some new pieces which have been added later). Most of this file is actually 10 years old :-).

...

we have many different variations of naming technique. That led me to look for any coding style guides; I know we have one for PHP files[1] but it's not clear if we use the same standards for JavaScript files. We can improve our documentation about this (unless I just missed some documentation that already exists). Any input about what we should use here? Most of the rest of the JS files seem to use PEAR-standard function names, at least based on a quick look I just did. If we all agree on that, we can just add a bit to the wiki telling people to use those same standards for JS files.

I'm not really sure what are best practices in the JS world, but we should rather try to hold to that instead of using PHP style things in JS. We can then configure Codacy (or other tool) to do such checks. -- Michal Čihař | https://cihar.com/ | https://weblate.org/

Reply

Himanshu Agrawal

5:29 p.m.

The comments are also not formatted in a similar way throughout. We can also set some guidelines to use /*...*/ or // and whether to give spacing after //. The /* should be followed by line break, etc. Is it required or comments would work fine? On Fri, Aug 11, 2017 at 7:27 PM, Manish Bisht <manish.bisht490(a)gmail.com> wrote:

...

I just checked the file "js/pmd/move.js" We can use the following coding standards. 1. Function Names in Camel Case (https://google.github.io/styleguide/jsguide.html# naming-camel-case-defined) 2. Function braces should start after the function name instead of after line break (https://google.github.io/styleguide/jsguide.html#formatting-braces) Thanks, Manish Bisht Email : hi(a)manishbisht.me Website : https://manishbisht.me On Fri, Aug 11, 2017 at 7:13 PM, Michal Čihař <michal(a)cihar.com> wrote:

Hi Isaac Bennetch píše v Pá 11. 08. 2017 v 09:28 -0400:

I was looking at some of the JavaScript function names, in particular in js/pma/move.js and the names are a mess;

Well actually whole designer code is a bit messy - it's only piece of our code which doesn't use jQuery and other modern features (except some new pieces which have been added later). Most of this file is actually 10 years old :-).

we have many different variations of naming technique. That led me to look for any coding style guides; I know we have one for PHP files[1] but it's not clear if we use the same standards for JavaScript files. We can improve our documentation about this (unless I just missed some documentation that already exists). Any input about what we should use here? Most of the rest of the JS files seem to use PEAR-standard function names, at least based on a quick look I just did. If we all agree on that, we can just add a bit to the wiki telling people to use those same standards for JS files.

I'm not really sure what are best practices in the JS world, but we should rather try to hold to that instead of using PHP style things in JS. We can then configure Codacy (or other tool) to do such checks. -- Michal Čihař | https://cihar.com/ | https://weblate.org/ _______________________________________________ Developers mailing list Developers(a)phpmyadmin.net https://lists.phpmyadmin.net/mailman/listinfo/developers

_______________________________________________ Developers mailing list Developers(a)phpmyadmin.net https://lists.phpmyadmin.net/mailman/listinfo/developers

-- Thanks & Regards Himanshu Agrawal himanshuagrawal1998(a)gmail.com Student Developer

Reply

Maurício Meneghini Fauth

11:30 p.m.

Hello Already in my plans to review the JavaScript files, especially in the coding style part. I already had a good idea of the code when I was preparing the webpack pull request, it just didn't work because I bit off more than I could chew. My intention is to work on JavaScript as well, however this time in baby steps and setting a style guide is one of those steps. I recommend using the javascript style guide from Airbnb. https://github.com/airbnb/javascript This guide is very popular and very well done. We can use it as a base in ESlint and go overwriting the rules as needed. And since it is very popular, it would help new contributors who already develop in JavaScript. What do you think about using this style guide? Maurício Meneghini Fauth On Sat, Aug 12, 2017 at 12:03 PM, Isaac Bennetch <bennetch(a)gmail.com> wrote:

...

On Fri, Aug 11, 2017 at 9:43 AM, Michal Čihař <michal(a)cihar.com> wrote:

I'm not really sure what are best practices in the JS world, but we should rather try to hold to that instead of using PHP style things in JS. We can then configure Codacy (or other tool) to do such checks.

Indeed, I agree. I quickly was able to find the jQuery style guide[1] or the Google one[2]. I immediately preferred the Google one because it looks more comprehensive. On closer inspection, jQuery uses tabs for indentation and Google uses spaces. I didn't notice any other differences in the areas that matter to me; they seem pretty similar with style of braces and naming conventions. So I prefer the Google one. That also happens (by coincidence) to be the same guide referenced by Manish in his reply. 1 - https://contribute.jquery.org/style-guide/js/ 2 - https://google.github.io/styleguide/jsguide.html On Fri, Aug 11, 2017 at 10:29 AM, Himanshu Agrawal <himanshuagrawal1998(a)gmail.com> wrote:

The comments are also not formatted in a similar way throughout. We can also set some guidelines to use /*...*/ or // and whether to give

spacing after //. The

/* should be followed by line break, etc. Is it required or comments

would work fine? I think we should pick a style to follow, then fix up the existing files based on the guide presented there, but realistically the code works and any fix ups are going to result in code that still works, so it's not a very glamorous task. Even more so with comments that just aren't in a modern format. The whole section of code may need a refactoring more than it needs to be adjusted to match the style guide. It's an interesting project management puzzle to think about whether it should be refactored outright, made to match the style guide, or just left how it is. _______________________________________________ Developers mailing list Developers(a)phpmyadmin.net https://lists.phpmyadmin.net/mailman/listinfo/developers

Reply

Manish Bisht

5:08 a.m.

Just checked Airbnb style guide also looks good. Manish Bisht Email : hi(a)manishbisht.me Website : https://manishbisht.me On Sun, Aug 13, 2017 at 7:17 AM, Isaac Bennetch <bennetch(a)gmail.com> wrote:

...

On Sat, Aug 12, 2017 at 4:30 PM, Maurício Meneghini Fauth <mauriciofauth(a)gmail.com> wrote:

Hello Already in my plans to review the JavaScript files, especially in the coding style part. I already had a good idea of the code when I was preparing the webpack pull request, it just didn't work because I bit off more than I could chew. My intention is to work on JavaScript as well, however this time in baby steps and setting a style guide is one of those steps.

I thought you might have this in mind :)

I recommend using the javascript style guide from Airbnb. https://github.com/airbnb/javascript This guide is very popular and very well done. We can use it as a base in ESlint and go overwriting the rules as needed. And since it is very popular, it would help new contributors who already develop in JavaScript.

I hadn't seen that one yet. You're right that it's very well done. I have no preference for any particular guide; if you prefer the Airbnb one then I have no objection. That's fine by me.

What do you think about using this style guide? Maurício Meneghini Fauth On Sat, Aug 12, 2017 at 12:03 PM, Isaac Bennetch <bennetch(a)gmail.com> wrote:

On Fri, Aug 11, 2017 at 9:43 AM, Michal Čihař <michal(a)cihar.com> wrote:

I'm not really sure what are best practices in the JS world, but we should rather try to hold to that instead of using PHP style things in JS. We can then configure Codacy (or other tool) to do such checks.

Indeed, I agree. I quickly was able to find the jQuery style guide[1] or the Google one[2]. I immediately preferred the Google one because it looks more comprehensive. On closer inspection, jQuery uses tabs for indentation and Google uses spaces. I didn't notice any other differences in the areas that matter to me; they seem pretty similar with style of braces and naming conventions. So I prefer the Google one. That also happens (by coincidence) to be the same guide referenced by Manish in his reply. 1 - https://contribute.jquery.org/style-guide/js/ 2 - https://google.github.io/styleguide/jsguide.html On Fri, Aug 11, 2017 at 10:29 AM, Himanshu Agrawal <himanshuagrawal1998(a)gmail.com> wrote:

The comments are also not formatted in a similar way throughout. We can also set some guidelines to use /*...*/ or // and whether to give spacing after //. The /* should be followed by line break, etc. Is it required or comments would work fine?

I think we should pick a style to follow, then fix up the existing files based on the guide presented there, but realistically the code works and any fix ups are going to result in code that still works, so it's not a very glamorous task. Even more so with comments that just aren't in a modern format. The whole section of code may need a refactoring more than it needs to be adjusted to match the style guide. It's an interesting project management puzzle to think about whether it should be refactored outright, made to match the style guide, or just left how it is. _______________________________________________ Developers mailing list Developers(a)phpmyadmin.net https://lists.phpmyadmin.net/mailman/listinfo/developers

_______________________________________________ Developers mailing list Developers(a)phpmyadmin.net https://lists.phpmyadmin.net/mailman/listinfo/developers

Reply