[wp-trac] [WordPress Trac] #26429: Introduce .editorconfig to WordPress

WordPress Trac noreply at wordpress.org
Mon Feb 3 22:22:25 UTC 2014


#26429: Introduce .editorconfig to WordPress
------------------------------+------------------------------
 Reporter:  netweb            |       Owner:
     Type:  enhancement       |      Status:  new
 Priority:  normal            |   Milestone:  Awaiting Review
Component:  Build/Test Tools  |     Version:  3.8
 Severity:  normal            |  Resolution:
 Keywords:                    |     Focuses:
------------------------------+------------------------------

Comment (by netweb):

 Replying to [comment:7 jorbin]:
 > I like this idea.  Anything that helps ensure we only add new code that
 is in our guidelines is a good thing.
 >
 > My question is if any editors will interpret this file and attempt to
 make changes to our areas of our code base for the lines not directly
 edited?
 Yes they would, but see next paragraph.

 > We generally avoid whitespace only changes as they make it harder to
 find meaningful change sets.  To quote Nacin
 [http://make.wordpress.org/core/2011/03/23/code-refactoring/ “Code
 refactoring should not be done just because we can.”]
 A 'one time' patch of 'all the whitespace' could be done but I don't think
 it is needed.

 The whitespace in the codebase is pretty good as it is. eg. The 79 .php
 files in the root of `src\wp-admin` I just tested with Sublime Text 3 with
 the .editorconfig patch and not a single erroneous bit of whitespace was
 detected. Many/most 'core devs' would most likely already have these
 WordPress code styling standards already manually configured in their IDE
 of choice.

 > I do wonder if we can perhaps combine all of the various file types into
 the top [*]. We use tabs everywhere.

 As the repo contains .xml, .xap, .txt, .swf, .crt, .pot, .md, .po, .mo,
 .nodelete and .py (could be more I missed)  filetypes and as far as I know
 we can't add an exclusion rule for filetypes thus the explicit grouping of
 the rules for only the filetypes we DO wan't to include code styling for.

 I kept away from the JavaScript in the original patch as the JS guidelines
 were still being proposed at the time, if these are now formalized this
 could also be included.

 The patch also needs a refresh to include SCSS, i.e. From `[*.css]` to
 `[*.css,*.scss]`

 Rule/s for `.travis.yml`, `package.json`, `phpunit.xml.dist`,
 `.gitignore`, `.jshint` could be added or left alone 'for now' and added
 later 'ron.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/26429#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list