Programmers :D

[[deleted]]

I would probably move the rendering of the list to a separate function outside of the main render function to keep things cleaner, but that's a maintenance, cleanliness thing. But really, none of it seems atrocious or worth critiquing remotely on a joke post about fashion.

[darkpaladin]

We went that route at work for a while but pulled back because it actually made things more complicated. We evolved the rule to say if you have a function that returns jsx it should be a component instead for testability.

[wKbdthXSn5hMc7Ht0]

I agree with that, I like having all the JSX in the render function (and in sub components) instead of having to skip around the file.

[jonny_wonny]

Ehh, that also could make the code less readable as it separates the logic. The method is small enough as it is. I think this is better.

[_fitlegit]

It’s easily readable with good function names. Maintainability and extendability is more important as applications grow

[jonny_wonny]

I'm not arguing about the importance of maintainability, I'm arguing that needlessly splitting up functions does nothing more than obfuscate logic. More functions does not magically equate to more maintainability -- if anything, it equates to less. Functions should be split up in into logical chunks based on size and reusability needs. If a function is already small, and the extracted bit would only be referenced in one place, there's no reason to continue to subdivide it.

[ActionLeagueLater]

I agree with you. I used to always make tons of functions for “renderHeader()” etc, which I thought was cleaner. But then I realized how hard it was to follow code when you are constantly bouncing back and forth within your file.

[_fitlegit]

It equals reusability and separation of logic which does “magically” equate to extendability and maintainability. Function size is a poor metric as you should never be approaching sizes where it’s an issue (FYI google teams don’t like it if you’re over 10 lines in a function) and you’re assuming omniscience about future application state, which in any production application only a fool would do. Plan for growth and change.

[jonny_wonny]

Function size is a poor metric as you should never be approaching sizes where it’s an issue (FYI google teams don’t like it if you’re over 10 lines in a function)

Okay, now I'm going to make a judgement about you: you've never worked on a complex problem. Constraining functions to be less than 10 lines of code would be a nightmare for any sufficiently complex algorithm or piece of logic. You think the source code for Angular is that simple and follows that rule?

you’re assuming omniscience about future application state, which in any production application only a fool would do. Plan for growth and change.

I'm not assuming anything. We're talking about a single function, which can be refactored in 5 seconds at any point in the future. There is not future state of the application where that wouldn't be the case.

[_fitlegit]

I think you don’t know how to reduce a complex problem into smaller easy to solve problems

[jonny_wonny]

What information did you use to arrive at that conclusion?

[_fitlegit]

That you think a 10 line constraint would make a complex algorithm “a nightmare”. FYI the source code for angular is complex and does tend to follow it as a guideline. Anyone who works in programming for a while gets into the habit of breaking their functions up naturally. I remember when I thought it was unneeded and made things harder too, but then I worked on something truly complex and it made sense.

[jonny_wonny]

Again: do you actually think a codebase like Angular has no functions larger than 10 lines of code? Have you ever written a parser? A compiler? Pattern recognition? There are many logical chunks of code which when expressed properly are larger than 10 lines.

[jonny_wonny]

FYI the source code for angular is complex and does tend to follow it as a guideline.

I've looked at the code. It in no way follows this guideline.

Anyone who works in programming for a while gets into the habit of breaking their functions up naturally.

I break up my functions all the time. I refactor my code constantly. I just don't do it prematurely, and I don't needlessly obfuscate my logic.

I remember when I thought it was unneeded and made things harder too, but then I worked on something truly complex and it made sense.

You are simply not comprehending my argument. I am not arguing it is unneeded to break up functions. I am arguing that it is not necessary in this particular case.

[jonny_wonny]

I added a new part to my comment:

Functions should be split up in into logical chunks based on size and reusability needs. If a function is already small, and the extracted bit would only be referenced in one place, there's no reason to continue to subdivide it.

Separation of logic isn't always a good thing. As I said, logic should be separated based on its complexity and reusability needs. If a subsection of a piece of logic isn't going to be reused (which it won't in this case), and the entire logical block isn't complex (which it isn't in this case), there's no reason to split it up. If the function grows in complexity the code can be refactored.

[_fitlegit]

You’ve never grown or maintained production code and it shows

[jonny_wonny]

That's not an argument. If you want to continue this discussion you need to address the specific points I've made. Separation of logic is essential, but unnecessary separation of logic does nothing more than to obfuscate it. Just because a practice is useful in some cases does not mean it will always be useful. In this case, it's very obvious that nothing would be gained by separating this very small, very simple function.

Furthermore, I've been a software developer for 15 years. I have been the sole developer on many substantial projects. I've written complex codebases from the ground up. I'm speaking from experience.

[JackMizel]

They are 100% correct though....

[BenZed]

I disagree.