Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

clean code #2289

Conversation

gabrielsimongianotti
Copy link
Contributor

Description

I made some changes to the code to make it cleaner and more readable

@@ -1,5 +1,4 @@
import getIn from 'lodash/get';
import isPlainObject from 'lodash/isPlainObject';
import { isPlainObject, get } from 'lodash';
Copy link
Contributor

@jimmywarting jimmywarting Oct 14, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, this is more of a pre build friendlier tree shaking thing.
using import isPlainObject from 'lodash/isPlainObject' is more browser friendly as a build-less solution

don't know which one i like the most. :P

ofc i would like to remove lodash entirely

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll go back as it was before

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but do you want to switch lodash to some other npm package?
tell me how it can get better, that I can make the changes

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there is an open issue to try and remove it #2187 and replace it with native solutions

like using typeof and optional chaining for get - as long as it's supported by the version swagger do support

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can I make these changes in another PR?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yep

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just for reference: doing this is OK. During building the release fragments we use babel-plugin-lodash and lodash-webpack-plugin.

Copy link
Contributor

@jimmywarting jimmywarting left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

src/helpers.js Outdated Show resolved Hide resolved
@char0n
Copy link
Member

char0n commented Oct 15, 2021

Hi @gabrielsimongianotti,

First of all thanks for the work!

Regarding renaming e -> error

This requires lot of changed files and IMHO doesn't provide much of a value. There are multiple conventions how to name the catched error. These includes: e (MDN), ex, error, err (typescript). How would renaming e to error makes code more readable? Both conventions are well known and accepted by the developer community. Choosing one convention and stick with (which brings consistency) is more important to this project. Do you have technical arguments for your change?

@jimmywarting
Copy link
Contributor

jimmywarting commented Oct 15, 2021

☝️ agree with you there, i hate linters that require one curtain way of doing things, i just want a linter to warn about errors and not change code style - it's so annoying. one thing doe... i don't like 1 letter variable, annoying do search & replace....

@char0n
Copy link
Member

char0n commented Oct 15, 2021

one thing doe... i don't like 1 letter variable, annoying do search & replace....

IMHO e in catch statement is one of the few exception I can think of where single letter variable is acceptable for me. Others include counters for loops named i or j or whatever. Personally in JavaScript projects I either use e or error and in TypeScript err.

@gabrielsimongianotti
Copy link
Contributor Author

I changed because in the clean code book, it says that it is bad practice to use letters as variables, I'm going back as it was

@char0n
Copy link
Member

char0n commented Oct 15, 2021

I changed because in the clean code book, it says that it is bad practice to use letters as variables, I'm going back as it was

Right. Clean code is a great book and I totally agree with what it says. But as mentioned above the catch (e) might just be the exception to the rule, as it's already well established convention in JavaScript community.

@@ -1,3 +1,5 @@
import { Buffer } from 'buffer';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why we added import to Buffer here? We got rid of it in e96702f

@@ -160,10 +160,10 @@ export function normalizeSwagger(parsedSpec) {

const opList = map[oid];
if (opList.length > 1) {
opList.forEach((o, i) => {
opList.forEach((op, key) => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why key here and not index? key is usually used in object context, not in array context

@@ -202,7 +202,7 @@ function formatKeyValue(key, input, skipEncoding = false) {
const { collectionFormat, allowEmptyValue, serializationOption, encoding } = input;
// `input` can be string
const value = typeof input === 'object' && !Array.isArray(input) ? input.value : input;
const encodeFn = skipEncoding ? (k) => k.toString() : (k) => encodeURIComponent(k);
const encodeFn = (k) => (skipEncoding ? k.toString() : encodeURIComponent(k));
Copy link
Member

@char0n char0n Oct 19, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering here what is the motivation and arguments behind your change? If I would to simplify this I'd probably go with the following:

Suggested change
const encodeFn = (k) => (skipEncoding ? k.toString() : encodeURIComponent(k));
const encodeFn = skipEncoding ? String : encodeURIComponent;

Explanation: it's a simple ternary that chooses an appropriate function to be used as value of encodeFn

@@ -290,8 +290,10 @@ function formatKeyValueBySerializationOption(key, value, skipEncoding, serializa
: serializationOption && serializationOption.allowReserved
? 'unsafe'
: 'reserved';
const encodeFn = (v) => encodeDisallowedCharacters(v, { escape });
const encodeKeyFn = skipEncoding ? (k) => k : (k) => encodeDisallowedCharacters(k, { escape });
const encodeFn = (str) => encodeDisallowedCharacters(str, { escape });
Copy link
Member

@char0n char0n Oct 19, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using str as variable name is consistent with https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/encodeURIComponent, so let's go for it.

If our goal is simplifying the cleaning the code what would you say to following?

Suggested change
const encodeFn = (str) => encodeDisallowedCharacters(str, { escape });
const identity = (v) => v;
const encodeFn = (str) => encodeDisallowedCharacters(str, { escape });
const encodeKeyFn = skipEncoding ? identity : encodeFn;

@@ -432,8 +434,8 @@ export function mergeInQueryOrForm(req = {}) {

// Wrap a http function ( there are otherways to do this, consider this deprecated )
export function makeHttp(httpFn, preFetch, postFetch) {
postFetch = postFetch || ((a) => a);
preFetch = preFetch || ((a) => a);
postFetch = postFetch || ((req) => req);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Regarding variable naming - yeah, great change!

(req) => req is an identity function. We already needed one in https://github.com/swagger-api/swagger-js/pull/2289/files#r731893085. Let's define an identity function in top of the file and just use it in my previous comment suggestion and in here.

@@ -97,7 +97,7 @@ class SpecMap {
return true;
}

return path.every((val, i) => val === tested[i]);
return path.every((val, key) => val === tested[key]);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

key is associated with objects. Arrays use index naming.

@@ -342,7 +342,7 @@ class SpecMap {

// A different plugin runs, wait for all promises to resolve, then retry
if (plugin !== this.currentPlugin && this.promisedPatches.length) {
const promises = this.promisedPatches.map((p) => p.value);
const promises = this.promisedPatches.map((parameter) => parameter.value);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

origina p represent a patch here and not parameter, or am I wrong?

Suggested change
const promises = this.promisedPatches.map((parameter) => parameter.value);
const promises = this.promisedPatches.map((patch) => patch.value);

@@ -6,9 +6,9 @@ export default {
const val = { ...properties };

// eslint-disable-next-line no-restricted-syntax, guard-for-in
for (const k in properties) {
for (const position in properties) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about changing k to key here? It actually says what the variable is in context of for in on object.

@char0n
Copy link
Member

char0n commented Nov 2, 2021

@gabrielsimongianotti why closing it? We had couple of things to discuss here, and the codebase would benefit from this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants