.NET MVC is really bad when it comes to this. I'm not sure what problem they were trying to solve, but referring to a specific controller-action by using Url.Action("Controller", "Action", "Area") was a really bad idea imo. This means that visual studio's 'find references' functionality doesn't work, and the project I'm working on has dozens of unused controllers (I think). It also means that developers can do stupid stuff like make links dynamically loaded from the database ('Controller', 'Action' fields that never change).

I also despise the whole concept of 'validators' in .NET MVC. Not only does it prevent you from using distinct validation for particular actions using the same model, it completely hides the fact that validation is used at all (if you trace the controller code). Why not just write a class that validates the model and use it in the controller? Is that 'too much code/too much coupling' for the controller? Ugh.

>This means that visual studio's 'find references' functionality doesn't work, and the project I'm working on has dozens of unused controllers

I know it's an annoying extra step to learn and do, but when doing anything with refactoring controller actions (e.g. changing action names or required parameters), Ctrl+Shift+F is really your friend. I have noticed references not getting picked up by the refactoring quick actions too, but it was sporadic.

Oh I know -- powershell's my weapon of choice here. And it doesn't help when the previous developers decided to store action/controller names in the database...lol.

This may also be a contributor to the fact that a lot of devs these days seem to make a clear distinction between the type of code they allow themselves to write and code they won't write. A lot of people stay within a narrow range of what their chosen framework allows and don't really experiment with doing complex stuff themselves. In my view someone who has worked with React or Node (example) for a while should have a fairly good idea how they are imlemented but it seems many people accept it as "magic" and don't look behind the scenes.

To me reading source of these frameworks helps realizing that whoever developed them are just human beings like the rest of us and write regular code that's really not special.

More than that, reading framework source often reveals that the code is very, very bad.

Because a lot of working code is very bad. Reading other people's code is a good to way calibrate expectations for code quality.

It's ambiguous what you mean there, expectations could be beliefs ("I expect code to be bad generally, so I don't assume anything") or what you'll accept ("I expect code in my system to be good, so I rejected the PR that added that garbage library").