Discussion on: 7 Tips For Clean Code

[JoelBonetR 🥇]

For the comments part It's not about commenting all declared vars, this is useless, the vars should have a syntactically understandable name.
If you end up with something like:

const optimusPrime = whatever;

You are doing something wrong and there's no lint that can help you here. The second point so, overrides the first.

---

Comments in functions and methods are good, at least to know what this function or method is supposed to do (super briefly), which args it requires and what it returns.

/*
 * Sums 2 numbers
 * num1, num2: Int
 * returns: Int
*/
function sum(num1, num2) {
  return num1 + num2;
}

---

There are many linters out there, all of them opinionated and require manual actions to adapt your code to it's opinionated rules. I would suggest to install and configure prettifier to your (the project) standard way to do the things (2 spaces, code line length and so on) so your code will be auto formatted on save.

I'm gonna take a try to this SonarJS to see how it works.

---

I see TypeScript as a dying tech. It was discussed tones of times so I'll place a little brief: it's a subset of JS (not a superset, it's something that compiles into js, so it cannot be a superset by definition) thus it obscures and limits what you can do with javascript while providing a fake peace of mind. Network calls, third party libs and so on have no way to communicate with TS. This is anyway, another discussion.

---

Finally the console warns and errors are intended for something. It's the same than saying hey, don't throw 404 error from backend when the route is not available, handle it on another way... hmm ok it can be done but errors are here by convention and cuz they help us find out what's going on on a certain situation.
You can, of course, log this errors -as long the execution didn't break apart- to a server instead, adding the required stack trace and so on but there are certain situations where this kind of console commands could be good.

It's not about console logging all your application steps, it's just handling the warning or error situations that you missed out or didn't even think possible to happen.

try {
  // do validated stuff
} catch(err) {
  // if something fails we'll get this message
  console.error(`Error: ${err.message() err.stack()}`;
  // of course as long as it does not break the execution flow we can do
  logger.send(err);
  // and send it to our logging server, but if this fails, we'll still available to replicate 
  the same issue and see the error through the console
}

[Akash Shyam]

Whoa! Controversial statement right there 😂, I agree with the fact that network calls, third party libs cant communicate with TS. Even though we need to write some extra code, it helps a lot in the long run. It just boosts vs code autocomplete so much that it's become difficult coding in vanilla javascript now 😅. People who are new to the codebase can figure out types of arguments/variables/functions etimmediately.

You know what, I'm going to post about this next time and discuss with you guys!

I see TypeScript as a dying tech. It was discussed tones of times so I'll place a little brief: it's a subset of JS (not a superset, it's something that compiles into js, so it cannot be a superset by definition) thus it obscures and limits what you can do with javascript while providing a fake peace of mind. Network calls, third party libs and so on have no way to communicate with TS. This is anyway, another discussion.

[JoelBonetR 🥇]

Hahaha it could be funny or a mess, let's see how this discussion ends :P

For the intellisense (autocompletion) you can use plugins for that as you are probably using for TS, either way the types are most of time not so important and not required on JS as long as you can create your own classes and types as well and you can ensure the data is of the type you want or need on any data flow.
You can of course, simply check types where's implicitly needed with typeof so no breaking benefits of having TS. As i said, you simply cannot do a single thing with TS that Is not available in JS while adding some throwbacks as the mentioned above so... I can see a clear #1 winner here 😂😂😂

[Akash Shyam]

But typescript offers some extra functionality that javascript does not have like Readonly variables, private/public/protected properties and methods in classes etc etc.

In the end, it all comes down to preference

[JoelBonetR 🥇]

As I said, there's NOTHING that you can do using TS that can't be implemented using JS.
stackoverflow.com/questions/242840...

For instance, there are things that you cannot do with TS that definitely are available on vanilla JS :D

Apart from that using a feature just because it's here is most of time a bad analysis of what do you really need to reach a given software solution, and anything that you feel missing or unexperienced/lazy to develop by your own, there will be a babel plugin or whatever that cover that need hahaha

[Akash Shyam]

Instead of continuing this discussion, here check out all my points and views here.

[JoelBonetR 🥇]

finished my text and commented on the proper discussion :D

[Akash Shyam]

Lol 😂

[srikanth597]

Ok, I may not be good JS dev as you,
Let me brief an example for you.

Accessing a prop on a nested object let's say obj.data.hasMyRecognitions which could always be array or object or array of objects I don't know them if I go with your Proper JS Road, I would most likely endup being atleast one error which any JS developer experience. i.e Can't read property of undefined.
We don't always want go and check that fix all over again.
In the end we all want time we want to spend on writing and debugging should be kept at minimum and send faster results.
I think TS is great, it definitely does improve DX.