Adopt pugjs coding style

[TimothyGu]

It might be better to make the coding style consistent with the rest of @pugjs. Specifically, the lack of semicolons and the comma-first style makes the code in this repo looks significantly different from Pug proper.

I don't want to get into bikeshedding on which style is better (in fact, I have experiences with both), but since there has been an established style already for Pug (and all packages under @pugjs other than this one) I'd love to make stuff look the same.

Of course, @benedfit, you are the maintainer of this package, so you have the final say on this matter :)

[TimothyGu]

This problem seems to be more annoying than I thought. So I tried to write a pretty simple rule module, and a part of it is:

      tokens.forEach(function (token, i) {
        var next = tokens[i + 1]

        if (!next || next.type !== 'path') return

        if (token.type === 'include') {
          if (path.basename(next.val).indexOf('.') === -1) {
            errors.add('Included file path must have a file extension', next.line, next.col)
          } else if (path.extname(next.val) === '.jade') {
            errors.add('Included Pug file must end in .pug', next.line, next.col)
          }
        } else if (token.type === 'extends') {
          if (path.extname(next.val) === '.jade') {
            errors.add('Extended Pug file must end in .pug', next.line, next.col)
          }
        }
      })

Of course, this loop doesn't pass the linter, because it has a cyclomatic complexity of 8, 2 more than the accepted 6.

Come on, really?

The code isn't that difficult to read, and making it less "complex" will reduce the accuracy of the message, or the precision of the rule in general.

In addition, I also don't like to see enterprise-specific things creeping into the general code base, especially the bundled preset "clock." True, pug-lint is designed to be pluggable, so people can choose what they want; but then why bundling something very specific for a company?

Sorry if I came off a little rude, and made this issue off-topic. I'm just a bit frustrated with the linter setting, and the inability to get to the real, juicy part of the test, which is my new rule.

[benedfit]

Hi @TimothyGu

Having started out as a solo non-@pugjs project I had anticipated that discussion around coding style and feature development would arise at some point along the line, and I welcome it.

Linting

I'm more than happy to change the coding style to be consistent with Pug proper. I don't have a particular preference for any style, the current style is simply one I've inherited from my day-to-day coding at Clock. Is there a preferred linter and config that I can pull from another project to check against? If not, it's something that I would suggest someone makes a decision on, as while I don't have a style preference, I do feel strongly that we should use tooling to help everyone maintain the style.

Presets

I borrowed heavily from JSCS when building the linter, and presets are one of the things that I simply copied 😄 . However, as of Today, I plan to replace presets with the ability to extend configuration files in the same way as eslint in #79

P.S. Not to give you further annoyance, but you may also find yourself running afoul of jsinspect the more tests you write. So again, this is something the wider @pugjs team might want to look at taking a stand point on

[TimothyGu]

I'm more than happy to change the coding style to be consistent with Pug proper.

Great!

I don't have a particular preference for any style, the current style is simply one I've inherited from my day-to-day coding at Clock.

Okay, I understand.

Is there a preferred linter and config that I can pull from another project to check against? If not, it's something that I would suggest someone makes a decision on, as while I don't have a style preference, I do feel strongly that we should use tooling to help everyone maintain the style.

No there isn't, although my experiences tell me that our style is the most similar to xo with 2 spaces rather than tabs for indentation. Function syntax is pretty varied throughout the code base (probably my fault ;), although I try to use function name() { and function () { these days. Either way xo doesn't care about functions so it's fine.

However, as of Today, I plan to replace presets with the ability to extend configuration files in the same way as eslint in #79

Great! I saw that in #80 there is a confusion because of the existence of Clock's config in the tree. That's exactly the kind of things I want to avoid, but seems like we are on the right track already.

P.S. Not to give you further annoyance, but you may also find yourself running afoul of jsinspect the more tests you write. So again, this is something the wider @pugjs team might want to look at taking a stand point on

Yeah, while I agree that these tools can be helpful they shouldn't be part of the test suite.

Since none of the other projects IIRC use linters or style checkers, I think the best way to move forward with this issue is to just add a style-only linter like xo. @benedfit, what do you say?

[benedfit]

Okey dokey, xo it is. I'll get a new PR going for the change over

[benedfit]

@TimothyGu one decision to make: are we going with tabs or spaces as default? xo uses tabs, but current .editorconfig files, in the few projects they exist in uses spaces?

[TimothyGu]

I'd prefer spaces, and all other Pug projects already use spaces.