Thank you for stopping by! I am a full-stack developer that combines the power of entrepreneurship and programming to make the lives of programmers easier.
Thank you for stopping by! I am a full-stack developer that combines the power of entrepreneurship and programming to make the lives of programmers easier.
Totally agree with that last line, you are right, most of the time they do and they are really confusing.
I am mostly against comments in such cases but, creating another private function might complicate the problem even further... I think creating functions that have almost no reusability is a problem.
Although, the local lambda could be the best option there. The biggest problem is the way you read it. You have to over the lambda code until it is being used and then come back to it. Can be quite tricky.
Reusability is a rare reason for creating new functions, most of them are called for one place and used to separate the concerns and have small functions, so a lower cognitive load.
Thank you for stopping by! I am a full-stack developer that combines the power of entrepreneurship and programming to make the lives of programmers easier.
Reusability is the primary reason I create functions. Interesting to see a completely different view.
How do you deal with such complexity? I mean, from what you told me, you can have tons of functions that are hard to understand on their own. Isn't that a problem?
I think you are taking everything I say to an extreme, without a concrete example there are just guidelines.
You can read some open source code and see that re usability is not usually a concern for new functions, most would prefer a WET code than a 200LOC function.
Here are a few random examples: cleanGlobPath function is a private function just to take the "load" off the Glob public function. doubleCapacity function is a similar example, it can fit in the addFunction but is better to extract it.
Another reason I forgot about is when you want to protect a functionality to be overridden by an ancestor you can move it to a private function and let the function that can be overridden empty, just a proxy for the private one.
Thank you for stopping by! I am a full-stack developer that combines the power of entrepreneurship and programming to make the lives of programmers easier.
Yes unfortunately in JS there is a preference to use lambda/ functions inside a public function, instead of declaring them outside, mainly because of the lack of language features (private functions ando/or modules support), but hopefully things will change in the next few years.
Anyway I don't normally bring JS in discussions about good/clean code because I haven't found yet a project or library that has one (in my oppinion). Even in large common libraries is custom to have 2-3 nested functions, 100LOC functions (random example Vue, createComponent function does at least 3-4 things, instead of 1), acute lack of defensive programming and other "bad practices".
PS: If you want to have nightmares go trough the NPM source.
Thank you for stopping by! I am a full-stack developer that combines the power of entrepreneurship and programming to make the lives of programmers easier.
I don't think large functions by themselves are really a problem. Large function that do way too many things without any structure or good flow could easily become a problem though.
Also, yeah, that createComponent function is difficult to understand... but maybe because I don't know much about VueJS
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.
Wouldn't it be better to just comment that code block and tell the reader what it does?
I don't know, it depends, we'll see when we get there :D
If that piece of code has also 3 temporary variables and some loops, a comment would not suffice, if is a one liner maybe.
Comments can be tricky because they usually remain outdated.
Totally agree with that last line, you are right, most of the time they do and they are really confusing.
I am mostly against comments in such cases but, creating another private function might complicate the problem even further... I think creating functions that have almost no reusability is a problem.
Although, the local lambda could be the best option there. The biggest problem is the way you read it. You have to over the lambda code until it is being used and then come back to it. Can be quite tricky.
Reusability is a rare reason for creating new functions, most of them are called for one place and used to separate the concerns and have small functions, so a lower cognitive load.
Reusability is the primary reason I create functions. Interesting to see a completely different view.
How do you deal with such complexity? I mean, from what you told me, you can have tons of functions that are hard to understand on their own. Isn't that a problem?
I think you are taking everything I say to an extreme, without a concrete example there are just guidelines.
You can read some open source code and see that re usability is not usually a concern for new functions, most would prefer a WET code than a 200LOC function.
Here are a few random examples:
cleanGlobPath function is a private function just to take the "load" off the Glob public function.
doubleCapacity function is a similar example, it can fit in the addFunction but is better to extract it.
Another reason I forgot about is when you want to protect a functionality to be overridden by an ancestor you can move it to a private function and let the function that can be overridden empty, just a proxy for the private one.
Alright. I understand now. Maybe I'm just too used to weakly typed languages. Thanks for the great examples!
Yes unfortunately in JS there is a preference to use lambda/ functions inside a public function, instead of declaring them outside, mainly because of the lack of language features (private functions ando/or modules support), but hopefully things will change in the next few years.
Anyway I don't normally bring JS in discussions about good/clean code because I haven't found yet a project or library that has one (in my oppinion). Even in large common libraries is custom to have 2-3 nested functions, 100LOC functions (random example Vue, createComponent function does at least 3-4 things, instead of 1), acute lack of defensive programming and other "bad practices".
PS: If you want to have nightmares go trough the NPM source.
I don't think large functions by themselves are really a problem. Large function that do way too many things without any structure or good flow could easily become a problem though.
Also, yeah, that
createComponentfunction is difficult to understand... but maybe because I don't know much about VueJS