Item — HN Reader

This resonates with my latest experience. I am working on a 3D game simulation and I have two player entities (Batter/Pitcher) who run on the ground. The running is done between to predefined control points/nodes in the scene graph which in turn is converted into a path. Every frame update I get the current location and move to the next location.

// func buildPath(pathName): // builds a path between start and end control nodes fetched from the scene graph

// func updateFrame(timeElapsed): // gets current location and move to next location using timeElapsed

Now both these functions are not too big, but not too small either. However a reviewer mentioned I should split and I refused because they don one thing and do it succinctly.

This useless dumb fascination with test practices and being rigid about it, causes grief, both for the code and the coder!!!

2 comments

As GP wrote,

> that has to be balanced against locality of reference and context.

I'm also against splitting stuff like crazy, even though I tend to write small functions. For me, the primary concern is "how easy is this function to understand"? Sometimes splitting out code into separate functions actually hinders readability - especially if it makes reader jump around, or uses state passed implicitly between many small functions.

I find good functions to be structured like good explanations - the function body should give you a general and complete understanding of what it does, and low-level details get outsourced to helper functions, that you can recursively review if needed.

I think part of the problem comes from the term "split". Some may assume you are a referring to splitting a function into two or more functions that are called from the original call point, while others may assume what you are referring to here, the separate of concerns inside the function into small sub-functions (which can also sometimes make them reusable) to encapsulate concern.

I think the former is of limited use if any, while the latter is an invaluable tool to managing complexity of a code base. That people may assume the former when the latter is meant is unfortunate.

Side question! Are you working on an OSS baseball simulator? Very interested in helping if you are :)

For now it is an iOS closed source app. I will ask my team if we can get you added as private contributor, if you are OK with it.

My email is my profile. If you can reach out with what you would like to contribute with in case you have anything specific in mind, great. Else just ping, we can talk about potential contributions you make.