Recently I read a book(CleanCode)
in this book,
FUNCTION SHOULD DO ONE THING. THEY SHOULD DO IT WELL. THEY SHOULD DO IT ONLY.
and function should be small.
But I think the function in javascript.
If I split big function to small things, the code is getting longer and It takes more time to render.
Is it better to make function small even in javascript?
What is your opinion
In general you should always strive to make your functions small and concise. Not so much for performance reasons, which will be negligible, but so that your code is clean, readable, and maintainable.
Micro-optimizations are not worthwhile. Maintainability is far more important. For actually serving the code to the browser, you can use a JavaScript minifier.
Unless you are writing a very time critical part, usually "easy for maintance" (which implies small function in your case) is far more important then code size.
You should always start by writing small functions and then optimize (by merging or rewriting) those you think too slow.
Hi,
The book is exactly right.
A function should be a simple as possible. That should be a habit. Maybe for a very simple webpage you won't notice any difference, but as you go on to develop more and more complex systems you will find that by making functions simple you will avoid a heap of unnecessary bugs.
It's much easier to find issues with separate functions that each perform a single, easily measurable task. And as a bonus, you will find it much easier to reuse portions of your code and prevent duplication. Each piece of functionality should only be coded once, otherwise when you need to change how something is calculated, for example, you have to hunt through your code to find all the places that need to be changed.
And the rendering time (or rather the download time) difference is insignificant compared to the added maintainability of your code.
The line is blurring a bit in Javascript, since functions double as classes, objects, constructors and closures. Your outermost function may be ginormous, but only because it namespaces other big functions which act as objects/constructors which contain even more callbacks which contain closures.
At its fundamental level though, the rule that a function (a functionally self containing block of code) should be as lean as possible holds true in any case and any language.
If I split big function to small things, ...
It doesn't say "do small things", it says "do one thing only" and "small function".
That doesn't mean one-liners, to do 'one thing well' it could easily be 10-50 lines and still be concise and 'one thing'.
I don't believe in the mantra "functions should be small, doing one thing and one thing only". I think that was true in the era of procedural language programming, and it was what got a lot of hyped up OO proselytizers in trouble. Why? Because in those languages you could not use inline or anonymous functions. The path to readability in those early procedural languages was in short, well-named functions because then you could make your code more semantic. Code was generally shorter in those days too, with fewer supporting libraries and components. The iteration time on the build-debug cycle was several minutes--today, I think many would find that unacceptable.
Nowadays, the main enemy to maintainability is not being able to decipher a program's flow. If you don't know what or where to code is, or where it's coming from, or what the name of that thing you're supposed to call is--you have a nightmare on your hands in short order. Having (1) a simple, non-polluted namespace easy to think about and (2) having a section of code very close to other code it impacts is going to get you a lot more mileage on the maintainability front than the "lots of small single-purpose functions" thing.