pull down to refresh

117 sats \ 1 reply \ @k00b OP 17h
Nice set of rules at the end.
Combining the points discussed so far and merging/removing duplicates where possible, we end up with a list of 8 factors:
  1. Line/Operator/Operand count: Make smaller functions with fewer variables and operators, they are easier to read
  2. Novelty: Avoid novelty in function shapes, operators, or syntactic sugars; prefer reusing common patterns in a codebase
  3. Grouping: Split series of long function chains, iterators, or comprehensions into logical groupings via helper functions or intermediate variables
  4. Conditional simplicity: Keep conditional tests as short as possible and prefer sequences of the same logical operator over mixing operators within a conditional
  5. Gotos: Never use gotos unless you are following this one pattern, and even then only when the alternatives are worse
  6. Nesting: Minimize nested logic (aka avoid large variations in indentation). If deep nesting is required, isolate it in a function instead of deeply nesting inside a larger function
  7. Variable distinction: Always use descriptive and visually distinct variable names; avoid variable shadowing
  8. Variable liveness: Prefer shorter liveness durations for variables, especially with regard to function boundaries
reply
Til then, I’m just going to end with what a mentor once told me early in my career: “the person who is most likely to read your code a month from now is you.”
Even more true in academic codes...
reply