Answer the question
In order to leave comments, you need to log in
Why break the code into functions if the code is short (~30 lines) and there is no repeating code?
I write in Python for myself when at work I need to quickly generate another from one file, etc. I accidentally came across a question where a person showed an example of his code. The code copies files according to a certain attribute from one folder to another. The code is short. However, among the answers there is this:
"The code must be divided at least into functions, and not all in one heap"
Why? What will make him better? The code is written in a completely transparent and understandable way. There are no repeat pieces. Why functions?
Answer the question
In order to leave comments, you need to log in
You have a program that copies files according to a certain attribute from one folder to another, divided into the functions "determining a certain attribute" and "copying to another folder", and tomorrow you will need to make a program that will simply copy files from one folder to another, you take a ready-made function and don’t worry about looking for the right fragment in the code of the old program
Increased self-documentation.
It will not be necessary to break the code into parts in your mind to understand what they do. Anyway, at least 5-8 lines of code should perform a specific task, not just a general one
The code is more readable and easier to maintain. It's easier to run through 3 lines with function calls and understand what they do by their names than to analyze 30 lines of incomprehensible code.
The code needs to be divided at least into functions, and not all in one heap
The task of decomposition is to simplify the maintenance and development of the code. If support and development is not planned, then decomposition is not needed.
Code not yet written: break it down as it's easier to test and develop.
The code has already been written, but it will be developed: split, otherwise very soon your code will become overgrown with duplication, and it will be very difficult to find errors in it. With a large amount of code, only you can maintain it, it will not be easy to figure it out, making changes will require a deep understanding of the entire code.
The code is already written, works, does not contain errors and will not be developed: do not split, because this is labor costs that will not give anything.
The answers would be more specific, or they wouldn't be there at all if we saw the code.
Otherwise, all answers can be regarded as "sofa analytics."
I think...
If this is one crooked-clumsy, but working project that you forget about immediately after delivery, then you can not bathe. And if you are only engaged in the creation of such projects, then you can not read further and do not waste your time.
But if the project needs to be supported (from experience I can say that this or that function is forgotten after a month) or other people are working on it, or you want to go quietly on vacation, in which you do not want to be disturbed, then it’s better, of course, to write in such a way that one operation is performed in the function, or at least if there are several of them, then this should somehow be reflected in its name and, of course, it should be documented (almost all IDEs allow you to do this without much strain).
Good code is easy to read and understand, and most importantly, it takes much less time to add (change, remove) a new function than in a crooked code.
Of course, the crooked-clumsy code is used everywhere and can work without problems for years, until something needs to be changed ...
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question