The Shapes of Code
fluentcpp.com
The Shapes of Code
1–10 of 71 posts
Re: The Shapes of Code
#2Handy patterns, which could probably fairly easily be implemented as a high-level linter.
Re: The Shapes of Code
#3While the patterns themselves are interesting, the idea that all code must be rearranged in to smaller functions to be “refactored” seems a little juvenile.
Re: The Shapes of Code
#4I'm glad I'm not the only one who pays attention to this. This is completely unsubstantiated and coming from a relatively inexperienced programmer, but it's been my experience that better code tends to produce nicer shapes. An obvious example not mentioned in the article arises when code is nested too deeply and too thinly, creating jarring and disproportionate peaks.
Re: The Shapes of Code
#5Functional code would be totally different, I guess.
Re: The Shapes of Code
#6I hadn’t thought about the shape of code much as a refactoring heuristic, but it’s neat to see a post about the concept of code shape.
I found examining code shape to be an effective method for assisting in algorithm recall in some college courses. Now working with larger codebases in industry, I find it really useful for navigating around large files or remembering where to go for particular snippets of code.
I wonder if this phenomenon has anything to do with different spatial tricks people use for memorization and recall (the “memory palace” technique). I’ve never thought of myself as having good spatial reasoning at all, but this kind of thing makes me question the boundary between “spatial” and symbolic / verbal thinking.
Re: The Shapes of Code
#7While the patterns themselves are interesting, the idea that all code must be rearranged in to smaller functions to be “refactored” seems a little juvenile.
It seems antithetical to the intent of "Goto considered harmful":
> My second remark is that our intellectual powers are rather geared to master static relations and that our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible.
While Dijkstra later talks about using procedures to index into the call stack, needlessly adding to the depth of the callstack for single use functions seems excessive.
With this logic, I actually think "The paragraphs with headers" is the way to go since as TFA states: "You know that the algorithm operates in steps, and you know where the steps are located in code."
http://www.u.arizona.edu/~rubinson/copyright_violations/Go_T...
Re: The Shapes of Code
#8My favorite name for a shape of code I've heard is the "pyramid of doom" caused by excessive nesting- think lots of ifs or callback hell in something like node.js
It's easy to recognize, and the importance of recognizing it is right in the name.
Re: The Shapes of Code
#9I'm glad I'm not the only one who pays attention to this. This is completely unsubstantiated and coming from a relatively inexperienced programmer, but it's been my experience that better code tends to produce nicer shapes. An obvious example not mentioned in the article arises when code is nested too deeply and too thinly, creating jarring and disproportionate peaks.
Microsoft's docs have an interesting idea of what good nesting looks like:
https://docs.microsoft.com/en-us/previous-versions/windows/d...
Apparently 13 different indentation levels is good.
Re: The Shapes of Code
#10I'm glad I'm not the only one who pays attention to this. This is completely unsubstantiated and coming from a relatively inexperienced programmer, but it's been my experience that better code tends to produce nicer shapes. An obvious example not mentioned in the article arises when code is nested too deeply and too thinly, creating jarring and disproportionate peaks.
Good code should be tightly wrapped around the problem, and reflect the shape of the problem itself.
But sometimes, the shape can be deceptive: