Thoughts on Manager Code Style (Includes Polls)

Development
1

There are a few areas I wanted to share my opinion on but, more importantly, get the community opinion on:

Use of Semicolon
There was a question in a recent PR on github (#15823) regarding the use of semicolons in Javascript. The author pointed out that they are generally not required when terminating statements. While true, the bottom line is that they are needed but are injected by the compiler automatically when not present. The vast majority of the time the automatic placement will be correct, but it’s not 100% guaranteed. I believe—especially when code is being created and maintained by several authors—that if ever a particular element is needed for code to execute properly (in this case the semicolon, but another example would be curly braces) it should always be used.

The other argument I’d put forth is that the other scripting languages used in a project might inform the overall code style as well. For instance, here we have PHP and Javascript. PHP absolutely requires semicolons to terminate statements. So from a continuity standpoint, it’s less error prone to simply use them across the entire codebase. No need to switch gears everytime you’re coding in one language or the other.

Always Use Semicolon?
  • Yes, always use
  • No, only when required

0 voters

Curly Braces
Again, as with the semicolon, these can be optional in certain circumstances (in both languages). I’d make the same argument here as above: Always use them to minimize mistakes. (Also IMO code just reads more nicely when the style is 100% consistent.)

Always Use Curly Braces?
  • Yes, always use
  • No, only when required

0 voters

Commas in Ext JS Config Objects
One thing that really drives me crazy is the placement of commas at the beginning of object properties, instead of at the end. I understand that this was somehow easier for the original author(s) when developing the Ext end of things, but it’s completely non-standard and doubtful to pass a linter. I want to strongly suggest that style is backed out of the entire codebase and standardized moving forward. I’ve continued writing this way for the core files so as to not introduce inconsistency, but please, let’s normalize the style here.

Ext JS: Comma Placement
  • Yes, always place commas at end of properties and method definitions
  • No, keep commas at beginning

0 voters

That’s it. Thanks for reading and participating! :wink:

2

Most modern tools (such as webpack, eslint, babel etc) know better than developers how to handle source code, and in particular semicolons.
Eslint does an excellent job of identifying ambiguous statements when behavior changes from the presence or absence of a semicolon.

No need to switch gears everytime you’re coding in one language or the other.

Implementing automatic code validation using a linter (eg eslint) eliminates such subjective questions.
Also the application of the same rules is a half-measure in the modern world, where the frontend is separated from the backend.

3

Note that what I’m getting at is that one who works on both the front and back end (separated of course) does not have to change their mindset when moving between those development contexts within the same project.

To all: When thinking about these questions, think about them specifically within the context of developing for MODX (or other open source projects of the like), where contributors are scattered across the globe and, although there are code owners, there aren’t people managing and directing this team of contributors. The best style and process may well be different for a one-person operation vs. a small development studio vs. […].

4

I do not have a strong opinion on this. I’d prefer looking at what’s standard these days for JS code styles, and see about adopting that if we can. I’ve seen Prettier come up on my twitter feed a lot, perhaps worth a closer look? ExtJS may give us some trouble, but hopefully not too much.

It think it may be important to note the PR in question where I asked about the semicolons revolved around inline javascript in the setup - that does not first get compiled which like @yasya_popkin mentions takes care off the details, but is run directly by the browser.