search

hemanth / functional-programming-jargon

Jargon from the functional programming world in simple terms!
http://git.io/fp-jargons
MIT License
18.59k stars 1.02k forks source link

use js standard style #111

Closed jethrolarson closed 7 years ago

jethrolarson commented 8 years ago

While I recognize that this is no official standard I find it a useful preset.

https://github.com/feross/standard

We can mix this with something like https://github.com/eslint/eslint-plugin-markdown To enforce that code examples follow our standards.

Alhadis commented 7 years ago

Thanks for making it harder to read.

jethrolarson commented 7 years ago

Anytime

On Mon, Sep 19, 2016, 9:54 PM John Gardner notifications@github.com wrote:

Thanks for making it harder to read.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/hemanth/functional-programming-jargon/issues/111#issuecomment-248201245, or mute the thread https://github.com/notifications/unsubscribe-auth/AAB-4DqajbQ23MpbdHbaWycyqVyK4uHpks5qr2bngaJpZM4JxDpu .

sotojuan commented 7 years ago

As much as I love Standard the no semis is a big polarizing problem so it'd be better if we stick to xo or a regular esling config.

jethrolarson commented 7 years ago

You're probably right. I don't really mind losing the people that would drop sarcastic comments on an open source issue though

On Tue, Sep 20, 2016, 8:37 AM Juan Soto notifications@github.com wrote:

As much as I love Standard the no semis is a big polarizing problem so it'd be better if we stick to xo or a regular esling config.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/hemanth/functional-programming-jargon/issues/111#issuecomment-248339792, or mute the thread https://github.com/notifications/unsubscribe-auth/AAB-4JKhOc_zLLIJGpKr11v8vaIOuD4Fks5qr_2zgaJpZM4JxDpu .

Alhadis commented 7 years ago

Alright, here's an earnest one:

2-SPACE TABSTOPS ARE HARD TO READ.

At least for some of us. Seriously.

jethrolarson commented 7 years ago

Thanks. That's more informative. I was assuming you didn't like omitting semicolons

On Tue, Sep 20, 2016, 8:58 AM John Gardner notifications@github.com wrote:

Alright, here's an earnest one:

2-SPACE TABSTOPS ARE HARD TO READ.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/hemanth/functional-programming-jargon/issues/111#issuecomment-248346496, or mute the thread https://github.com/notifications/unsubscribe-auth/AAB-4Frw8WzIkZmgkaiwI8KkigIW9Dv4ks5qsAKtgaJpZM4JxDpu .

Alhadis commented 7 years ago

I don't like that either, but I can stand it more than cramped code.

sotojuan commented 7 years ago

I think since the code in this repo is generally small and only for examples, 4 spaces is fine.

jethrolarson commented 7 years ago

Yeah, that's true.

I'd hoped that the "standard" preset would prevent bikeshedding. Guess I chose wrong

On Tue, Sep 20, 2016, 9:13 AM Juan Soto notifications@github.com wrote:

I think since the code in this repo is generally small and only for examples, 4 spaces is fine.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/hemanth/functional-programming-jargon/issues/111#issuecomment-248351034, or mute the thread https://github.com/notifications/unsubscribe-auth/AAB-4IslmmlpxtlumvgprP9Nnl5f3F1hks5qsAYygaJpZM4JxDpu .

jethrolarson commented 7 years ago

I don't know why I left this issue open. Code was merged. If there are outstanding objections they can be new issues

Alhadis commented 7 years ago

@jethrolarson I believe what the "Standard" style means about "preventing bikeshedding" is to stop dev teams from disagreeing over stylistic differences. Forcing it on other people's codebases comes across as pushy and evangelical, and accomplishes absolutely nothing in the long term.

Having said that, I don't see any commits where one contributor has modified the formatting of another's contribution (aside from yours).

jethrolarson commented 7 years ago

I don't have merge perms so if hemanth wasn't willing to take the update he could have declined the PR. I'm not forcing anyone. This was a proposal, it was accepted. Having some standard is good for consistency, my pr here identified some actual errors too (thanks to eslint). I picked a standard, you disagree. That's fine, but I think your objections are preferential so I'm not inclined to change it.

If you have research stating that 4 spaces has been shown to be more easy to read then that'd be really cool and I think that would warrant submitting PRs to feross/standard and a bunch of others.

I'm just a fan of this project and want it to help people

On Wed, Nov 2, 2016, 1:07 AM John Gardner notifications@github.com wrote:

@jethrolarson https://github.com/jethrolarson I believe what the "Standard" style means about "preventing bikeshedding" is to stop dev teams from disagreeing over stylistic differences. Forcing it on other people's codebases comes across as pushy and evangelical, and accomplishes absolutely nothing in the long term.

Having said that, I don't see any commits where one contributor has modified the formatting of another's contribution (aside from yours).

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/hemanth/functional-programming-jargon/issues/111#issuecomment-257797734, or mute the thread https://github.com/notifications/unsubscribe-auth/AAB-4JzJuiEFpFb7G00K-8F0leqObbuZks5q6ETagaJpZM4JxDpu .

Alhadis commented 7 years ago

So, what stopped you fixing the errors without stylistic alterations?

Having some standard is good for consistency

What was inconsistent about the existing formatting? It was fine.

I'm just a fan of this project and want it to help people

Deciding what's good for readers doesn't strike me as benevolence, @jethrolarson.

jethrolarson commented 7 years ago

I was proposing a standard style for consistency so that there aren't stylistic differences between examples. There were already stylistic differences creeping in: semi-colon usage, parens around arguments, whitespace, etc. I wasn't even consistent with myself in my edits as I use different standards for work vs personal. I've gotten a lot of value out of eslint at work as it prevents style issues from coming up in PR (which are incrementally low value arguments to have), and it has prevented a slew of actual errors as well. I considered setting up a lint file for this repo that would roughly match what we seemed to already be doing, but I thought my choices on style there would be argued as being just my preferences. I remembered the "js standard style" preset and thought choosing a decently well used preset was preferable to getting into long winded arguments on spaces vs tabs. The setup was moderately easy and and could be validated as a build process.

Git push ; create pull-request I see merge

jethrolarson commented 7 years ago

What is the outcome you're seeking?

Alhadis commented 7 years ago

I'd argue that stylistic variation is a more organic and realistic approach to explaining functional programming to readers who're probably from all sorts of backgrounds, not just JavaScript.

In any case, if I'd done what you did, I would've deliberately altered the preset to retain as much of the original formatting as possible, while ironing out the discrepancies. E.g., if most of the lines ended in semicolons, then the ones which didn't had semicolons added. The reverse logic is true.