1. Thou shalt name things properly
As you probably know, naming things is hard, but it isn't impossible and as long as the name of the...
For further actions, you may consider blocking this person and/or reporting abuse
I can't speak for Paul, but I think that the point he was leaving towards was to remove as many external dependencies as you feel comfortable with.
If you want to use jQuery, then got right ahead. But you might be able to achieve whatever you're doing without having to include it. And the same can be said for the hundreds of megabytes of npm packages that you're pulling in.
It's all about taste and comfort, if you'd prefer to use npm and/or jQuery then go right ahead. The way that I take point 7 is that you should think about what dependencies you're bringing on board when you bring them in, rather than just adding any and every package under the sun. The point being that you might be able to do it easier, with your own code.
Then again, like I say, it's all about taste and comfort levels.
On a personal level, I prefer to not use jQuery where possible because I remember a time when the most common answer for any JavaScript related question on Stack Overflow was "use jQuery". It's a useful library, to be sure. But I (personally) think that to many people use it as a crutch.
Again, just my two cents, and meant in a positive way in the hopes of fuelling discussion 😊
I'm getting to where I really love having configs for most of my "constants". .NET makes it so easy to provide them via file, environment, or command line...why not! But uh, yeah...stop those hard-coded values from spreading before it's too late. Great read!
appsettings.json is one of my favourite things in Core.
--8. Avoiding tightly coupled and focusing on TDD adds extra layer of abstraction which then again adds complexity which leads to complications and unreadable code which was the thing that was being avoided in the first place.
Just because Uncle Bob said so doesn't mean it's good. Really check out the code written before by you or colleges. Did it actually help remove complexity or added shadowing and more spaghetti code. Controller->Interface->Service->Interface->Repository->Function1->Extra function->Function1->Function2->Function1... This is SOLID principle add interfaces all the way to abstract stuff and avoid repeating code which leads to numerous calls to other stuff and makes debugging harder. "Well we have tests" - no you don't you pass the tests which in the first place should not be isolated from the context and tested as unit/alone and proof to this is how much extra bugs do you discover after manually testing while all the other unit test are green? From my experience it's too much.
Instead of following some buzzwords like loosely coupled or TDD let's thing before writing code. If thing is bound to context and tightly coupled in real world it's supposed to be that way in the code or else it's going to get too abstracted and no new developers will be able to join project without spending month or even more to get understanding of the project. Don't interface everything and don't write too many layers or else we're going to continue creating patterns, architecture and philosophy about something that can be easily solved by thinking with your own head.
Now if you wonder why people are switching to FP I think this is the main reason too much "right ways" to do stuff which in the end appears not be so right. But I'm not sure about them to they also have too much complications lately: monad, monoid, haemorrhoids... Let's just write code: it's craftsmanship not engineering really.
Our teams production secrets/credentials are never exposed outside of their production runtime memory (that includes never being written down anywhere). We never commit unencrypted secrets (open source or not). And when encrypted we of course commit them to open source, since we need them that way to deploy to package managers (for instance).
I suggest updating the commandment ~_.
... 10. In compiled languages. Real „const“s are inlined as if you would have spread it directly in your code. So there is no reason not to do it.
I'd add a bit to #8. Untestable code is instant legacy code!
I like it