FizzyOrange

Honestly I would take a look through a good standard library that provides a lot of algorithms (e.g. C++ or Rust). That has the basics, especially for data structures.

Also have a go at some hacker rank tests. Especially if you want to learn dynamic programming (abysmal name), they absolutely love that.

Linters 100% won't. A static type checker is not a linter.

Yes because you used static type annotations. This thread was about code that doesn't use static types (or static type annotations/hints).

It's an example to demonstrate that linters cannot reliably detect variable name typos - you need static types. None of the stuff you mentioned is relevant.

The typo in your example is also undetectable by linters. I think you're missing the point.

What's awful about this example? The only thing I do is access an object member. Does your code not do that??

Yes you can use static type hinting and the static type checker (Mypy or Pyright) will catch that. Linters (Pylint) won't.

If you use VSCode, open both files and then ctrl-shift-P "Compare active file with ..."

You're welcome.

def foo(x):
  return x.whatevr

No linter is going to catch that.

...for people who refuse to use static types.

Hilarious.

This is the sort of thing you have to learn by experience, like how you can't really learn good coding taste from reading a list of rules (though some lists are helpful).

Anyway in my experience documentation is quite different in public (i.e. seen by customers) and private (inside your company). For internal stuff there's a much smaller incentive to document things because:

1. documentation tends to be inconsistent (as you discovered), so people give up looking for it. Instead they just ask other people. This actually works fairly well inside a company because you can generally easily access whoever is responsible (as long as they haven't left).
2. there aren't customers to keep happy and away from support.

I think the best thing to do is to accept that people aren't going to expect documentation internally. There's zero point writing guides to tools on your company wiki or whatever, because nobody will even try to look for it - they'll assume it doesn't exist.

Instead you should try to keep your documentation as close to the user as possible. That means, don't have a separate docs folder in your repo - put your docs as comments in the code.

Don't put deployment instructions on your wiki - add a ./deploy.sh script. It can just echo the instructions initially.

Yeah, honestly you should stick to if/else until you're really sure you want to do something more complex.