Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
As senior dev/tech lead I would prefer to see, at least, @params and @return to avoid others loosing them time reading code that they'll forget in like 2 minutes.
The rule about not commenting the code is simply bullshit and needs a fallback which is "document your features and usecases" (which must be consultant's competence and not devs one) if you don't have one or another it will be harder to maintain the software even being 100% clean code.
Front end developer specialising in JavaScript and React. Experienced in all aspects of modern front end development. Passionate about making accessible, secure and performant software.
Completely agree. I consider "comments as documentation" good. They make the project easier for developers to work with because glancing over the documentation is much faster and easier than reading through the code.
On the other hand, I think "Inline commenting" is bad. That's used when the code needs explaining because it's difficult to understand.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
Sure! I'm talking just about the usual documentation above each function/method that defines the required information to work with this provided function/method without making you read the current implementation 😄
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
As senior dev/tech lead I would prefer to see, at least, @params and @return to avoid others loosing them time reading code that they'll forget in like 2 minutes.
The rule about not commenting the code is simply bullshit and needs a fallback which is "document your features and usecases" (which must be consultant's competence and not devs one) if you don't have one or another it will be harder to maintain the software even being 100% clean code.
Completely agree. I consider "comments as documentation" good. They make the project easier for developers to work with because glancing over the documentation is much faster and easier than reading through the code.
On the other hand, I think "Inline commenting" is bad. That's used when the code needs explaining because it's difficult to understand.
They're different things.
Sure! I'm talking just about the usual documentation above each function/method that defines the required information to work with this provided function/method without making you read the current implementation 😄