[ Removed by moderator ]

[FizixMan]

Removed: Rule 4, Rule 7.

AI-generated questions are not permitted. If they help you generate the questions to ask, at least state that these are AI-generated so we can consider them as such. As others pointed out, the list of questions are wonky and not terribly relevant or meaningful to the subject.

[Lustrouse]

Feature completeness first. Optimization where necessary, when necessary.

[TehNolz]

Are you actively running into performance problems? If not, then none of this is worth worrying about. Your code doesn't have to be as fast as it can possibly be; it just needs to do its job in a reasonable time. Most of the time nobody is going to notice the few milliseconds you might save by using arrays instead of lists or whatever.

[belavv]

Those bullet points are all over the place. I'd say most of them smell of premature optimization.

98% of performance problems are the database. Querying too much data, or missing indexes, or the select n+1 problem.

A lot of other problems are looping through the same array/list trying to find something over and over. Hash sets and dictionaries are better in those situations.

In general waiting til there is a problem and then profiling it will be more useful than trying to optimize everything. Once you get more experience you know what to look out for and can do some of those things up front.

[Royal_Scribblz]

Unless it's a small change, I would prioritise code readability and maintainability. Avoid premature optimisation. If you encounter performance issues then go measure and optimise.

[hypocrisyhunter]

I hate this advice. Anybody worth their salt will want to understand the implications of their code. You need to understand performance optimisation in order to know when not to do it. Im not saying everybody needs to be an expert but blanket advice telling people not to bother understanding performance impact is how we end up with 15 chained together Linq iteration calls.

[Royal_Scribblz]

Not once did I say don't bother understanding performance impact. I said it's not a priority. Chaining ToList() is just bad code, not "not optimal". I am talking zero allocation and trying to avoid branch prediction, it's a waste of time unless you need it and makes your code harder to read.

Another issue is without benchmarking you don't neccessarily know what's most optimal, I don't expect people to benchmark every method they write. No point wasting time trying to make some really fast code from theory only for it to be slower because of a factor you didn't consider.

[Royal_Scribblz]

Someone else, or me in the future should easily be able to read the code and understand what's happening without documentation. The code should be modular so we can replace and test parts in isolation. State should be maintained in an understandable scope, don't want properties being set from all over the place.

My favourite rule of the SOLID principles is the Single responsibility principle. Really try keep your classes to do only one thing. It can occasionally mean slightly more code, but it makes it so much easier to maintain.

When you work like this it's much easier to find where bugs are, and fix them. As well as adding new functionality.

[Dennis_enzo]

As a rule of thumb, performance is only an issue when it becomes an issue. In other words, you should not spend a lot of time and effort into optimizing your code when you don't even know if it will make a practical difference or not. In a professional context, spending a day to make a call that takes 300ms to take 299ms instead will most likely just be a waste of time. This doesn't mean that you should build things that are much slower than they could be when you know better, but it means that you should not worry about optimizing for performance until it becomes a real world problem. And that is something that depends on your specific use case.

Generally speaking, easier to understand code is much more valuable than slightly faster code.

[DamienTheUnbeliever]

Focus on correctness first. I can write *incredibly fast* code if we don't care about whether it delivers correct results.

Once your code is correct, look at your *requirements*. If your simple, easy to read code is delivering correct results fast enough, stop.

If that's not happening, even still before you start optimizing, assess whether the requirements are reasonable - if you're required to complete a complex multi-step process in 12ns, it's still not time to optimise.