Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-20608] Add config files jsbeautify, etc that match Appcelerator's coding style

GitHub Issuen/a
TypeImprovement
PriorityCritical
StatusClosed
ResolutionDone
Resolution Date2018-07-23T15:49:05.000+0000
Affected Version/sn/a
Fix Version/sn/a
ComponentsTooling
Labelsn/a
ReporterBrenton House
AssigneeChristopher Williams
Created2016-03-07T20:43:51.000+0000
Updated2018-08-06T17:34:46.000+0000

Description

As a developer, I want to be able to to format code submissions to Appcelerator's open source projects, So that the added code format matches the coding standards set by Appcelerator. Could you include the .files for jsbeautify and similar libraries to help in contributing?

Comments

  1. Mostafizur Rahman 2016-03-21

    Hello, Thanks for sharing with us. Code formatting option has already present in Appcelerator Studio. To find this option, please go to *Studio* > *Source* > *Format* from the menu bar of the Studio. Please check [screenshot](http://postimg.org/image/z18hgbb0r/). Thanks.
  2. Brenton House 2016-03-21

    Thanks, but I am talking about providing some of the dotfiles for those of us that don't use Studio... :)
  3. Brenton House 2016-03-21

    [~mrahman] also, can you remove the link to screenshot you provided above? It links to inappropriate images... Thanks!
  4. Chris Barber 2016-08-24

    Code processor is dead.
  5. Brenton House 2016-08-24

    [~cbarber] Not sure what part is dead but these would be helpful in matching the Appc style of coding so that contribs don't get rejected b/c of formatting issues.
  6. Chris Barber 2016-08-24

    Whoops. Had the wrong component and wasn't paying attention. :)
  7. Brenton House 2017-04-27

    Reviving this issue as we could really use some definition around what Axway/Appcelerator defines as their JavaScript coding style. I can work on creating the appropriate helper files if there is a style guide that I can use as a reference. cc: [~hansknoechel]
  8. Chris Barber 2017-04-27

    [~brentonhouse] I wrote the original JS style guide (https://wiki.appcelerator.org/display/guides2/JavaScript+Coding+Standards), however it is very out-of-date. There are so many things that even I don't follow anymore. Now, I use ESLint now and here's my config: 
       {
   	"ecmaFeatures": {
   		"modules": true
   	},
   	"env": {
   		"es6": true,
   		"node": true
   	},
   	"extends": "eslint:recommended",
   	"globals": [
   		"appcd"
   	],
   	"parser": "babel-eslint",
   	"plugins": [
   		"security"
   	],
   	"rules": {
   		"indent": [ 2, "tab", { "SwitchCase": 1 } ],
   		"linebreak-style": [ 2, "unix" ],
   		"no-console": 0,
   		"no-cond-assign": 0,
   		"no-mixed-spaces-and-tabs": 0,
   		"no-inner-declarations": 0,
   		"no-case-declarations": 0,
   		"no-unused-vars": 0,
   		"quotes": [ 2, "single" ],
   		"semi": [ 2, "always" ]
   	}
   }
    The dashboard team uses an even stricter version. Since most of the code I write these days is ES6 and beyond, I'm still trying to define best practices and coding style. Promise chains and imports are pretty new and I'm not sure the best way to format them. Most other coding constructs are pretty straightforward. I always use const unless I need let, never var. I favor arrow functions over explicit functions unless I need to access this. The list goes on and on.
  9. Brenton House 2017-04-27

    [~cbarber] After talking with a few different people, I have heard that there are some rules around things like: {noformat} - Add padding spaces within empty paren, "f()" vs "f( )" - Add padding spaces within paren, ie. f( a, b ) - Should the space before conditional statement be added, "if(true)" vs "if (true)" - Should the space before an anonymous function's parens be added, "function()" vs "function ()" {noformat} I am not sure if ESLint gets to this level of detail. I took a look at the link you provided and I am not sure these are addressed in that doc either. I will take another look in case I missed it. Thanks!
  10. Chris Barber 2017-04-27

    f(), never f( ) f(a, b), never f( a, b ). However, for arrays, add the space: f([ a, b ]). if (true) {, never if(true){ } else {, never }\nelse {, though there's a ton of this going on. function (), never function() And most importantly, tabs, not spaces! :)
  11. Brenton House 2017-04-27

    awesome! thank you!! I will put together some config files for these for anyone that is interested. A lot of IDEs/tools look for the dot config files in root of project and will then format code accordingly. https://github.com/prettier/prettier https://github.com/beautify-web/js-beautify If there are other tools used by devs in axway/appc community, let me know and I can research and create those as well. Thanks again!!
  12. Brenton House 2017-05-02

    [~cbarber] -- Based on your feedback I have added the following eslint rules but there are probably more than can be defined based on the axway coding standard: 
        "space-before-function-paren": ["error", {
    	"anonymous": "always",
    	"named": "ignore",
    	"asyncArrow": "always"
    },
    "array-bracket-spacing": ["error", "always", { "objectsInArrays": false, "arraysInArrays": false }],
    "space-in-parens": ["error", "never"],
    "keyword-spacing": ["error"],
  13. Chris Barber 2017-05-02

    [~brentonhouse] This is awesome! I added those rules to my eslint file and it caught about a dozen whitespace issues. I appreciate the help. :)
  14. Christopher Williams 2018-07-23

    We've moved to using eslint rules that apply to our JS code, and clang-format for Java/Obj-C code. We check these rules on CI builds and try to provide feedback about any issues flagged in the PRs (specifically via Danger.JS for the SDK).
  15. Eric Merriman 2018-08-06

    Closed as completed. If this is in error, please reopen.

JSON Source