It comes naturally to create a function whenever needed, that should be true for all developers. But we all have different standards on when we cre...
For further actions, you may consider blocking this person and/or reporting abuse
I don't know how to put it in words, it "feels natural" after a while, I guess there are some general guidelines:
Note: These apply to procedural and OOP code.
Haven't thought of the math formula use case. One more thing to add to the list.
Do you look into the inner functions of the one that you are analyzing to see how hard it is to understand as whole? Or even better, do you look at the places where it has been used to see if it makes sense and it's not too difficult to understand just from the call?
I don't know really, I just follow some common sense rules, and usually I put myself in a junior dev shoes, would he understand this?
I was referring to inner functionalities like a sort before a search, or a normalization of a json before working with it. If that part is too ... messy I would extract it in a private function, or lambda or something to put a name on it. Like you rename a variable, I would encapsulate the piece of code.
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 VueJSPlease always use
functionas possible, and outsource thethis.I mean, instead of
use this
Yes this is based on the fact that member functions should only be added if they use private or protected declarations. Member functions that use only the public declarations of an aggregate are just bloating the aggregate. This can even, in some rare cases, have a performance penalty, for example if the language has virtual by default (yes this exists !) however most of the time it's just a matter of readability (especially for languages that don't separate the declarations from the implementation).
Which language is this?
It's just a pseudocode based on Ruby.
Interesting. Few languages have this feature. So does that make the
functionan actual method but outside the class?I edited by replacing
functionwithdefkeyword.Basically, instead of making
classas global, use morefunctionsas global primitives.And where do you put these functions?
Put those right in Ruby files. Then when you
requirethat file, you can use your functions.So just one extra file where you put all functions (or methods in this case) related to that class?
my_modules.rbMy primary goals are:
That's a great list so far.
What do you think about maintainability? Should you be reducing the amount of methods or functions you create to help maintainability?
You mean 10 longer methods instead of 20 shorter? Or something else?
Yes, too many can become a headache when trying to find if a functionality has already been implemented or simply when trying to debug a function, it's quite difficult to retain a lot of function calls.
It's really hard to tell. It's more like a process from less and longer methods (and less classes) to more and shorter, until its feels right.
How to find what was implemented? Put things on right place. So proper domain modelling, group helper methods to helper classes
I often think about methods in layers - public method is first layer. Do I need to check what called private methods do? Not so often.
Whenever I need to reuse code.
Even when the function is a one liner?
Yes.
I remember you're a fan of C. Do you have any source code I can look at? I had lots of problems with having too many functions that didn't really make sense outside the context they were used.
I'm surprised you see too many functions as a problem. I would think that points to a structural problem in your project organisation.
I rarely put more than 5 lines in a function and one liners are quite common.
That might be true.
Although breaking everything in even more functions does not help much. It just introduces even more confusion. Small comments are so much better even if they might get outdated at some point.
Are you the only person working on your projects or do you work on a team?
Oh it helps a lot. For example I can get all staff in one line of code.
I could just put it in my code with a comment.
Or I could put it as a function in a class that handles everything to do with staff.
Later on, I needed to handle errors, so it gets a try catch block around it, plus I add caching at the staff level. All is easy because I chose to separate it out earlier.
Why do you think
//Gets all staff
Is easier to understand than
GetAllStaff()
?
I have worked in teams and on my own and after twenty years of doing this I find it a much easier way to work.
Sorry for the confusion, I meant explicitly in my project in C.
Thanks for the response!
I do agree that creating functions instead of commenting out a block is better but, creating functions from code blocks that are already readable enough, albeit large but specific enough that they are never gonna be reused is what I think hurts a project. Just this specific case.
From some really good code you extract a function with a lot of parameters that is never going to be reused again will hurt maintainability.
I guess language makes a lot of difference.
Personally I would never create a function with more than two or three parameters, instead I would bundle them into a class.
This can seen like a lot of work but modern Ides can make it easy to do and it usually helps with understanding your problem domain better.
There is no difference in the language IMO (except Assembler and COBOL)... :-)
Hi!
I am creating functions for small and independent tasks, which do not need a context (eg removing characters from string), and methods (and their classes) when it's related to a more complex object (eg an array of Block representing a map in a game) and it needs to use a specific context.
To me, methods are better than functions when you need to give more than 4 or 5 arguments. In this situation, it means you need to create a class to handle those arguments (often, there isn't only one function doing stuff with those 4-5 (or more) arguments).
Great answer.
I have a question. If the method has 4-5 arguments and all can be modified then in which class do you put it? The most important argument?
I would create an abstract class using those arguments as attributes, if they are used in more than 1 function, to have all the data processing in the same place.
Usually, I choose a name related with how I play with those data and not regarding the most important argument.
This would work most of the time but wouldn't that create too many classes if there are many such methods?
It could, but if you can "group" methods playing with the sames arguments (but doing different things with those) it can be pretty efficient in reducing SLOC (physical lines of code) and code complexity (IMO, in some cases creating a function with more than 4-5 arguments is better than creating a class).
To me, the most interesting thing with a class is that it handle its resources on its own, all of them, in the same place.
Yup, that's why they were designed. Data with functionality. Just be careful not to group data with functionalities that don't actually deal with the data as whole but just parts of it. Or even worse, consider functionalities as objects and creating classes based on those. It can lead to so many headaches.
I try to stick to the concept of 'one function - one task'. If the function needs to perform some processing before performing the task, the pre-processing goes to a different task.
Isn't preprocessing of a task part of the task itself? Do you take into consideration the reusability of a function?
Again depends. Let's say you want to validate the data or format the data in the form the function accepts before processing it, you can move that logic to a function.
Interesting. A concern I have is how do you deal with all the parameters? Does the preprocessing function modifies all its parameters?
No. It does not need to. I just gave preprocessing as a example.
Let's just assume that the function accepts a parameter. Based on certain condition, it either needs to insert a record or update the existing one.
You can split up the logic of insert and update as two separate function. Here the main function almost acts as a wrapper. The main business logic resides in two different function, which can be reused elsewhere as required.
Hope that helps.
Thank you, that makes much more sense now.
For me, it's about readability and DRYness (DRY = Don't Repeat Yourself).
It doesn't always have to be something that will be called in more than one place, but wherever it would help to give a piece of functionality a name, even if it's one short line of functionality, it might be time for a function.
On the other hand, too many small functions could inhibit readability too. It depends on the code I'm working with.
Great response!
Personally, I don't see repeating yourself that much of a problem. Sure, if there are 5-10 lines of code repeated across your code you should create a function and use that, but I also encountered the opposite, introducing problems by creating functions and using them everywhere.
The problem was the function itself. It was fairly short (less than 5 lines of code) and it was almost certain that it will be modified in the future, but not for all calls, only for some. That's where creating a function can bite you.
I create functions whenever I can. My main concern is readability. Testability is entirely secondary, since a lot of my functions will remain private, and not directly tested.
Some key indicators you need a new function:
There are several exceptions. If adding a function would make the code more complex, then I tend not to do it. I also use a lot of lambda functions lately, grouping behaviour locally and making use of the same scope.
Are comments a rarity in your projects? Also, do you work on a team or alone?
I create methods if they make sense as a verb:
"send the file to the user when they specify the file to be sent" send, specify, when? stuff like that.
FactoryFactoryRefactorFactoryDetractor... no.
Interesting take on it. I always think you should start the name of the function with a verb but didn't take it that far. It does sound reasonable.
I'm sure there was a post about Factory/Manager/Something-er classes on here... can't find it at the moment.
I create a function whenever I need to repeat code. Other than that, why tempt fate with an inheritance error.
That's the first time I heard the term inheritance error. Do you mean you will not create any classes?
No, I create them out of habit anyway. However, consciously I know I need to create one whenever I need something that will repeat itself somewhere else.
I also said inheritance error when I think I meant scope error.
whatever it is, just give it a proper name.
When should you create a function?
That's how I roll as well. The hardest question is when does it increase complexity?