4 ms·
The author is really overthinking this. Small functions, big functions, long variables, short variables... none of this matters. The goal of programming is to e
by chatmasta 9y ago
The author is really overthinking this. Small functions, big functions, long variables, short variables... none of this matters. The goal of programming is to express a solution to a domain-specific problem, using a general programming language. The job of a programmer is to arrange a set of logical building blocks (the general programming language) into the domain-specific solution. Good code will be naturally express its domain specific logic in a way that is both readable and maintainable.
Readability is most strongly related to the ease of following all possigle code paths from a given entry point. That is, can I start reading in main() and iteratively follow the possible code paths given a specific input?
The answer to this question is more related to separation of scopes than it is to function size. If a single scope contains many possible branches and code paths, then it will be difficult for a reader to follow a specific code path amongst the noise of irrelevant functions (short or long).
All else equal, the length of a function is primarily a matter of style and preference. The priority of code should be expressiveness and clarity. If small functions enhance expressiveness, then they are the tool for the job. If big functions add clarity or aide in separating scopes, then they are also a tool for the job. Sometimes you need both.
Worrying about anything other than readability, maintainability and correctness is needless dogma.
- andybak 9y ago> The author is really overthinking this. Isn't the author trying to correct a dogma, just as you are?
- falcolas 9y agoHere's the problem - dogma already exists, and it exists in the name of readability, maintainability, and correctness. DRY is the particular bit of dogma which has been taken to the extreme. And this is the thing about extremes - to get back to the center, you have to push towards the opposite extreme (and hope your push has the right magnitude to not overshoot the proper location). It's why the title is extreme, and the article is not. "Small Functions Considered Harmful" is easy to remember, and a soundbyte which can compete at the same level of "Don't Repeat Yourself".
- chatmasta 9y agoExactly. The problem is not Dogma A or B, but rather the use of any dogma as a crutch in determining if code is readable. Here's the thing... code is either readable and maintainable, or it's not. You don't evaluate the readability of code with some kind of dogmatic checklist. You just read it and see if it makes sense. Dogmas are good for rules of thumb, which are mental shortcuts with safe error margins. Shortcuts are helpful in that they provide cover for knowledge gaps. But they are a short term solution. The long term solution is to develop adaptable instincts that provide better guidance than any dogma or rule of thumb. Looking at dogma this way, as a shortcut to cover knowledge gaps, its no surprise that adherence to dogmatism appears to be inversely correlated with programming experience. Newbies who haven't seen many contexts will cling to dogmas. But as they gain experience, they find situations where dogmas don't necessarily yield the best solution. Slowly that experience develops into instincts, which replace the crude dogmatic ways of thinking. But instincts only come with experience, and nobody is an expert in every domain, so dogmas have their place. But reliance on them should be a temporary solution, not a long term guiding principle.
- sopooneo 9y ago"You have to lean into the wind to stand up straight"
- marcosdumay 9y agoThat's just too bad. Because such pushes into the other extrema practically always overshoot, and because the author can not anymore push the line that dogmatic programmers are not good programmers.
- majewsky 9y agoIt's like politics all over again.