I just inherited my first codebase a few months ago. It's like this everywhere and original developer was fired, so what should sometimes be a simple fix turns into a full day of finding what needs to change. Any recommendations on fixing/maintaining code like this or should I just make it the next person's problem?

[–] Lightfire228@pawb.social 34 points 1 day ago* (last edited 1 day ago) (2 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

[–] Lightfire228@pawb.social 17 points 1 day ago (2 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;
}

[–] jjjalljs@ttrpg.network 2 points 21 hours ago

Lowering indent levels is nice in functions. Early returns mean you don't have to think as much. "If it got here, I know foo isn't null because it already would have returned".

[–] clay_pidgin@sh.itjust.works 1 points 1 day 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.

[–] Jankatarch@lemmy.world 2 points 1 day ago* (last edited 1 day 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();
}

[–] Lightfire228@pawb.social 2 points 20 hours 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

[–] clay_pidgin@sh.itjust.works 1 points 1 day ago

I use sentences as variable names sometimes, because I necessarily end up with lots of similar-sounding variables or functions.

List_of_foo_dicts = Get_foo_from_bar_api()

[–] hex123456@sh.itjust.works 14 points 1 day ago

Add comments as you go

[–] mad_lentil@lemmy.ca 4 points 1 day ago* (last edited 19 hours ago)

You're going to want to follow the "campsite rule" everywhere you go, and also sneak in positive refactors into your feature changes (if business is not willing to commit time to improving the maintainability of the codebase).

Read up on good software design principles. I don't know you experience level, but for instance, everyone agrees that appropriate abstraction, and encapsulation make code easier and more enjoyable to work with, and will let you run tests on isolated sections of the code without having to do a full end-to-end testsuite run.

Having tests that you trust, especially if they execute quickly, will increase your "developer velocity" and let you to code fearlessly--knowing that your changes are reasonably safe to deploy. (Bugs and escaped defects will happen, but you just fix them and continue on.)

Good luck!