camel casing

[cole-gillespie]

some have _ some are camel. some of the main attributes are camel case, some are not. can we switch all to camel for cleanliness and sanity?

lib/posts.js
  251:4   error  Identifier 'feed_url' is not in camel case  camelcase
  252:4   error  Identifier 'site_url' is not in camel case  camelcase

[dylang]

Great idea. This will be a major api breaking change unless we support both. How do current users feel about this change?

[cole-gillespie]

just added code that i think will support both @dylang

[cole-gillespie]

passing tests locally. i think this should work. maybe should make some new tests just to make sure.

[Mithgol]

How do current users feel about this change?

As one of the current users, the change feels fine as long as the major version is incremented.

The change should also be mentioned in the readme in some subsection called “Upgrading” or “Changelog” or “Breaking changes in 2.0.0” or in a similar fashion.

[mikemaccana]

Any news on V2? Just starting with this module and the case mixing's a bit confusing.

[ErisDS]

I have taken over maintenance of this module, and haven't yet sat down to look at it properly.

The current proposal is to add support for both snake case and camel case, I'd personally be in favour of picking ~~snake~~ camel case only. I'd also be interested to see if there's any names which can be moved closer to the RSS/atom spec, to make the API more easily 'guessable', and doing these as breaking changes for 2.0.0.

Any thoughts on this idea?

[mikemaccana]

Well it's node, JavaScript itself nearly always uses camelCase, and every JavaScript style guide uses camelCase.  Also : HI HANNAH 😃

On Mon, Jan 4, 2016 at 5:34 AM -0800, "Hannah Wolfe" [email protected] wrote:

I have taken over maintenance of this module, and haven't yet sat down to look at it properly.

The current proposal is to add support for both snake case and camel case, I'd personally be in favour of picking snake case only. I'd also be interested to see if there's any names which can be moved closer to the RSS/atom spec, to make the API more easily 'guessable', and doing these as breaking changes for 2.0.0.

Any thoughts on this idea?

— Reply to this email directly or view it on GitHub.

[ErisDS]

BACK AT YOU MIKE :grin:

That's basically what I'm thinking - supporting both is just prolonging agony. Can always do a 1.x version with deprecation warnings if it seems necessary, but I'd rather support one clear, sensible format than multiple formats when the lack of backwards compatibility can be managed with a major version bump and good docs.

[mikemaccana]

Slightly confused - you wrote " I'd personally be in favour of picking snake case only" but also "That's basically what I'm thinking" re: using camelCase since it's consistent with JS. 🤔

[ErisDS]

I'm not surprised you're confused! Sorry, that was a total brain fart... I meant camel case. Updated my comment.

[Mithgol]

I'm fine with camelCase as long as the breaking change causes an increment of the major version (see https://github.com/dylang/node-rss/issues/40#issuecomment-69469722 above).

An increment of the major version also means that you may break a few other things along the way (for example, you might consider rewriting the whole thing in ECMAScript 6 with arrow functions).

[sunknudsen]

Hey guys, stumbled upon this conversation and agree using a consistent naming convention would be amazing!

@dylang @ErisDS Who is generously maintaining this package finally?