Read John Carmack's writings on inlining (also discussed here on HN [1]) where inlining refers to keeping one function with all its work done in there, instead

Read John Carmack's writings on inlining (also discussed here on HN [1]) where inlining refers to keeping one function with all its work done in there, instead of calling out even to things like "myfuncstep1", "myfuncstep2", etc. I just hit a major bug due to that kind of thing, where stuff wasn't clear due to messy size of the code (customer insisted on C#). If the relevant sections had been sitting on screen, then I most likely would have noticed or never even made it in first place. I also started working with a new hire, one that isn't an FP proponent, and I'm shocked at the variable names. Even iterating a list of entry objects: I'd naturally write the list as 'es', and the current item 'e'. Versus 'entriesToProcess' and 'current entry'. Or even 'entries' and 'ent'. People's objections there seem to be that 'entries' is more readable than 'es'. While that may be true in isolation, I'm not sure it matters when working on a codebase above a few hundred lines. The amount if context is likely to be high enough that you're not going to be plucking one line out for changing, and the local context (and typing) should make it apparent it's a plural of e.g. entries, not employees. 1 https://news.ycombinator.com/item?id=8374345 https://news.ycombinator.com/item?id=8374345