"It's all about writing a code" No Please!
It's about writing a good & readable code, refactoring a lot for better results, optimizing, struct...
For further actions, you may consider blocking this person and/or reporting abuse
Solid post. I would extend the comments section to include two types of comments. First is a hack comments for when you have to put a working, but bad code block in to meet a deadline. I try to isolate this code it it's own function or class so the comment doesn't interrupt the flow. Second is answering why the code has business logic that is abnormal or a deviation from the rules the rest of the code follows. There is always a stakeholder who requests weird things at the last minute.
I completely agree about the comments telling me what the code does. I always delete those when I see them. Too much effort to maintain code and a comment in that situation.
Yepp 100%, if a code has been written in a really good way, I believe the comments will be just a distraction
We need a downvote button urgently
Sorry about that. It's just the way I am and I am trying to change. Can you please tell me the first time?
This is my first interactions at a community and I want to get better at communication — The one thing I am bad at
could have directly returned, but not should. Depending on your IDE, separating the statement over 2 lines can help you set a breakpoint and step into it. So I'm standing behind the OP on this one.
Good point.
number 6 is actually bad code, but it's a demo so okay...
yep, the idea is to see the difference, which one is cleaner and easy to read it :)
I mean that you should have directly
returned.yes that can be done, I wanted to showcase more indentation
Comments are important specially in large and legacy codes. I would suggest to add comments every time you are doing something that is not obvious from the code.
Comments can be used true, but what you mean by "something that is not obvious from the code" (if it's doing something extra not related)? what I meant here is that a code shouldn't need comments from the start if it's written in a good way
For example, some time ago I was working on a legacy code that get information for a list of credit cards and for some reason in this code was removing a especific information for some type of cards. It was obvious from the code that he was removing this information, but it wasn't obvious why he did this. The coder was long gone and I had to spend ours trying to figure it out why he remove this type of cards.
Finally I much testing I understood that was becuase the info providers was sending the wrong information for this cards and the coder had to improvise (hack it). A comment would've save me time because you are documenting a decision that is not obvious from the code.
Good read 👏