1125
The Six Stages of Code Grief (suppo.fi)
submitted 11 months ago by to c/programmer_humor@programming.dev
142 comments fedilink hide all child comments
 
you are viewing a single comment's thread
view the rest of the comments
[–] 34 points 11 months ago* (6 children)

  • if it's not in git / SVC, add it as is. Create a "refactor" branch, and liberally use commits

  • Treat it like a decompilation

Figure out what something does, and rename it (with a stupidly verbose name, if you have to). Use the IDE refactor tools to rename all instances of that identifier

  • Take a function, figure out what it does, and refactor it in a way that makes sense to you

  • Use the editor's diff mode to compare duplicate code, extract out anything different into a variable or callback, and combine the code into a function call. Vscode's "select for compare" and "compare with selected" are useful for this

  • Track what you're doing / keep notes in something like Obsidian. You can use [[Wikilinks]] syntax to link between notes, which lets you build a graph structure using your notes as nodes

  • be cognizant of "Side Effects"

For example, a function or property, or class might be invoked using Reflection, via a string literal (or even worse, a constructed string). And renaming it can cause a reflective invocation somewhere else random to fail

Or function or operator overloading/overiding doing something bizarre

Or two tightly coupled objects that mutate each other, and expect certain unstated invariants to be held (like, foo() can only be called once, or thingyA.len() must equal thingyB.len()

  • write tests if you can, either using a testing framework or custom Python scripts

You can use these to more thoroughly compare behavior between the original and a refactor

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 16 points 11 months ago (4 children)
    • if something feels too "heavy", like it's doing xml formatting, file manips, a db insert, and making coffee, all in a single class or function

    Separate out those "concerns", into their own object/interface, and pass them into the class / function at invocation (Dependency Injection)

    • use "if guards" and early returns to bail from a function, instead of wrapping the func body with an if
    
public Value? Func(String arg) {
  if (arg.IsEmpty()) {
    return null;
  }
  
  if (this.Bar == null) {
    return null;
  }

  // ...
  return new Value();


  /// instead of

  if (!arg.IsEmpty) {
    if (this.Bar != null) {
      // ...
      return new Value();
    }
  }
return null;
}
  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 1 point 11 months ago (2 children)

    I always feel bad about putting little ifs at the top of functions. Is it not bad practice? I like them because they're simple to implement modify and read, but I have this voice telling me I need to make things more impressive.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 11 months ago* (last edited 11 months ago)

    I started putting a helpful comment above the ifs as a seperator to cope with that.

    public Value? Func(String arg) { 
  // Sanitize.
  if (arg.IsEmpty()) return null; 
  if (this.Bar == null) return null; 
  // Get [that] and/or do [this].
  var foo = this.baz.foo;
  ...
  return new Value();
}
  • permalink
  • fedilink
  • source
  • parent
  • [–] 2 points 11 months ago

    Never make things more "impressive"

    Make them more comprehensible

    Reduce the cognitive load required to understand and reason about a piece of code. Honestly, the more you can express complicated ideas simply, the more impressive you are

  • permalink
  • fedilink
  • source
  • parent