style-guide, code and naming conventions

[tunnckoCore]

@regexps/owners
Starts here https://github.com/regexps/regex-block-comment/issues/1

@jonschlinkert apologize in advance if something, but I think here is the correct place for it. I cant realize and understand, yet, why you keep/started it there. lol
IMO, we should keep these type of discussions here 1) because this is the main repo for this purpose, 2) history/log about what happens. Discussion shouldn't be just in some repo that will not exists in future or will be with some totally different target - e.g. block comment regex talks. Yea maybe closed issue, but there. Or worst - deleted repo - we lost history/votes/thoughts.

Style-guide & Code conventions

imo, we definitely should have separate repo for style-guide

1. Should we have style-guide repo? Or just follow some other guide(s)?
   • felixge/node-style-guide
   • jshttp/style-guide
   • jscs presets
2. Should we have template files for repos as in jshttp? Which to be the files?
3. JSHint or JSLint? imo, JSHint + @jscs-dev looks great.
4. I think we should have this minimum of files
   • package.json
   • index.js
   • readme.md
   • history.md
   • license.md - dot md, prettier look? lol like here
   • .jshintrc
   • .jscsrc
   • .editorconfig

Is this .editorconfig enough for start?

root = true

[*.js]
indent_size = 2
indent_style = space
charset = utf-8
end_of_line = lf
insert_final_newline = true
trim_trailing_whitespace = false

[*.php]
# ...

[*.go]
# ...

Naming conventions

What i think so far

• we should keep current organization name - regexps
  • also suggested regular-expressions and regexes
• we should use prefix regexp-* for future modules, imo; or
  • prefix: regex-foo-bar, regexp-foo-bar
  • suffix: foo-bar-regex, foo-bar-regexp
  • or without worry of what is the name
• publish with prefix in npm
• without prefix in github repo

Vote and discuss

This is my and suggested thoughts.
Not attack me for that I only copy-pasting everything around. I just trying to centralize the things.

Good night from me :)

[jonschlinkert]

I don't have any opinions on any of this. I just want good quality regex projects to use, for users to be able to find them easily, and for them all to be consistent.

[tunnckoCore]

Agreed.

[tomByrer]

I just want good quality regex projects to use

Same here. I'm indifferent... OTOH, boy that is alot of overhead for 1 line of code. I'm assuming you're only targeting Node?

I'm starting to think there should be only 1 repo, with each rule in its own folder.... or some way to sync the support files like .jshintrc, .jscsrc, .editorconfig.

[jonschlinkert]

alot of overhead

What overhead?

[johno]

I think they will be best in their own repos. This will keep things modular and lightweight.

The overhead/boilerplate can be handled with a yeoman generator (or some other alternative). Once we have an established pattern for the regexes, I'd imagine that we will tackle some sort of generator to keep the workflow quick and simple.

Ideally only requiring the following steps:

1. yo regex-package regex-name
2. Add regex to index.js
3. Add regex details to the readme
4. Push to Github

Relevant issue: #5

[tomByrer]

The overhead/boilerplate can be handled with a yeoman generator

Good idea, hopefully the Gulp version.
If it is only a few LOC, maybe an online repo-maker would work?

[tunnckoCore]

alot of overhead

Yea you have the right for 1-line modules. But as @johnotander said it can be handled with generator. My flow is fully through cli - creating gh repo, init repo, populating template files with data, generating tests and etc.

[yoshuawuyts]

There's little overhead for having modules, especially if you specify a files property in package.json (example).

If you're looking for a module generator, both regex-utc-date and regex-email were generated with initialize. Depending on your needs / taste it might be useful.

I'm -1 on a org level style guide. The only thing I think we need to agree on is how we want to expose the regexes, some of the discussion is already taking place here.

[jonschlinkert]

Oh, I see. Sorry my question wasn't meant to be flippant when I asked "what overhead?". @tomByrer you meant all of the junk that comes with a repo for just a small regex. got it. I think we're all on the same page there.

I'm also -1 on an org level style guide. I think we'll have good stewardship here, and everyone in the org is experienced and opinionated about how they like to do things - which is good and expected.

just my 2c, I'm good with how things are progressing

[yocontra]

I don't think we need any of this. Maybe we should focus more on building regular expressions and less on guidelines.

Let best practices emerge naturally.

[tunnckoCore]

So okey, Im agree with you @regexps/owners , guys. Let's finalize the things?

• Organization name remains the same.
• No specific style guide.
  • Only .editorconfig! Indent size 2, indent style spaces, please, lol
• keyword regex as suffix or prefix, no matter, but requirement
  • because search show more results
  • sounds more natural
  • commonly used

Something missing?

[johno]

👍

[jonschlinkert]

👍

[tunnckoCore]

Okey you can transfer your repos/projects :P

What about this badge as requirement? lol

[yoshuawuyts]

I'm going to take the time to add editorconfigs to all projects

Cool, PRs are welcome!

Also we should standardise readme files

@arthurvr -1, consensus was already reached. A better investment of time would probably be to create more modules.

[tunnckoCore]

I'm going to take the time to add editorconfigs to all projects

@arthurvr awesome, cool 👍

[tomByrer]

So use a var or simply return? EG
return /(?:\/|^)(\.[^\/]*)$/;
vs
var regex = /(?:youtube\.com\/\...)/g; return regex;

[tunnckoCore]

@tomByrer no matter. its "so so", lol

[tomByrer]

Cosi Cosi?
Well, I was thinking of an automated scrapper. Better for something standardized, then have to make a complicated RegEx to scrape RegExes.

[tunnckoCore]

@regexps/owners
I think we can close this and summarize it when generators #5 / scaffolders and website is ready?

For the start:

• future packages to include the keyword, no matter as prefix or suffix
• already existing packages to force code and readme style
• in javascript context, package to be function that return the regex
• what for other languages?

I have a lot more Qs, but.. hm. Maybe I'll open new thread "General discussion", cuz they cover many related between them topcis and steps that we should do.