Dylan Sather (Pipedream) : That’s right, the JavaScript convention is camel case, which is why we follow that
SERW2039 : Ok got it on the came calse convetion. So what I am doing, as I work with the changes to the PR is renaming the variables as suggested by , and following this convention, and only have the API parameters as required for making the reddit API request, and this would be the only instance when the convention is not followed (that is in the config/data-body object of the request). Thanks @UR84EMEUT @UMT4G7E5P
Dylan Sather (Pipedream) : Makes sense thanks
Jay Vercellone : There isn’t a standard on this regard when it comes to the interfaces around the different API’s.
I always try to write these interfaces so that they provide an abstraction layer for developers to use without having to go to the API docs themselves and figure out the purpose of the different variables.
Besides, there’s times when there’s no 1:1 relationship between the interface arguments and the API parameters, or maybe you want to hide or restrict some parameters as well. For instance:
const axios = require("axios");
module.exports = {
methods: {
_apiUrl() {
return "http://example.com/api/v1";
},
async *scanVideos({ limitId }) {
const url = this._apiUrl();
let page;
do {
const config = {
params : {
page,
sort_order: "desc",
sort_field: "id",
type: "videos",
},
};
const { data } = await axios.get(url, config);
const {
next_page: nextPage,
items: videos,
} = data;
for (const video of videos) {
if (video.id === limitId) return;
yield video;
}
page = nextPage;
} while (page);
},
},
};
In this case, the details about the API parameters and the pagination are hidden behind the interface, so that if for example you want to call a different version of the API that has a different set of input parameters then the dependencies are not affected, only the abstraction function:
module.exports = {
async run() {
const lastVideoId = this.db.get("lastVideoId");
const videosStream = this.app.scanVideos({
limitId: lastVideoId,
});
for await (const video of videosStream) {
this.$emit(video);
}
},
};
Jay Vercellone : The current state of the codebase reflects different approaches since it’s been maintained by different people at different times without any mechanism to standardise it. I think sooner rather than later we might need to tackle this so that we stop thinking about this and just focus on the actual business logic.
One thing that we can do first is to have some linting in the project (although there’s probably going to be a discussion about the linting rules themselves, but that’s a different topic 
)
SERW2039 : Yes, totally I agree and see. Depending on the different layers of abstractions that are added around a API the correlation between API parameters name and variables eventually being datasource upstream for said parameters can be totally different. As of the code standardization, linting point , I think it will be wise to have a code guide, best practices docs, because for what I know, it is expected that any Pipedream user can create code for their own components.
Jay Vercellone : Exactly
Dylan Sather (Pipedream) : We’re actually working on a source dev guide now that we’ll send over to y’all for a review - would love to get your input on that
Michelle Bergeron : I’d love to see that as well.