39:12 I believe it may mutate, cannot be seen from outside - depends what 'allocation.Find()' is returning but if it is standard List it returns just existing instance from Tables, then 'table.Reserve(r)' may mutate, but probably it returns new modified object, otherwise just calling table.Reserve(r) would be enough * and not sure why 'if (table is {}}', would 'if (table != null)' not work?
Sure: The code presented in this talk (which is pretty normal code out in the wild) is more procedural/structural than object-oriented. Even though it's written in an OO-First language. This is not a bad thing, it's just how it is.
4:00 - In natural languages, we tend to have particular rules of sentence length, paragraphs, chapters, headings, etc. That (mostly) apply to all (Western and West Asian at least) languages. In computing we still one set of rules that apply to Java and another set that apply to C#. It would be so much better is we could agree on what is readable for all the "curly bracket languages" and just shut up arguing and agree to that. A few years ago, I stopped writing by PHP in my own style and adopted PSR-12... for the first week or so my attitude was "agggh! this STUPID way of writing code, I HATE IT, I HATE IT!" but then I just stopped noticing. One of my Python friends had a similar experience of "Black".
The notion of not exceeding atmost Seven mutable objects or tasks per scope is important because more than three per scope likely contains a vulnerability and thus should be analyzed with care. Because someone less scrupulous always will.
39:12
I believe it may mutate, cannot be seen from outside - depends what 'allocation.Find()' is returning
but if it is standard List it returns just existing instance from Tables, then 'table.Reserve(r)' may mutate, but probably it returns new modified object,
otherwise just calling table.Reserve(r) would be enough
* and not sure why 'if (table is {}}', would 'if (table != null)' not work?
10:10 I think 7 is only possible under a high amount of concentration. Otherwise, I prefer 3-5 much more, it's much more comfortable for daily stuff.
As usually, great talk from Mark
Great talk - made me consider perceived notions. Stay for QA, solid.
Is this applicable to non-OO code, e.g. written in C?
Yes, at least that's what is written in the book
Sure: The code presented in this talk (which is pretty normal code out in the wild) is more procedural/structural than object-oriented. Even though it's written in an OO-First language. This is not a bad thing, it's just how it is.
Wonderful talk
8:00 if I were reading this code, the data race here would cause me to abend
4:00 - In natural languages, we tend to have particular rules of sentence length, paragraphs, chapters, headings, etc. That (mostly) apply to all (Western and West Asian at least) languages.
In computing we still one set of rules that apply to Java and another set that apply to C#. It would be so much better is we could agree on what is readable for all the "curly bracket languages" and just shut up arguing and agree to that. A few years ago, I stopped writing by PHP in my own style and adopted PSR-12... for the first week or so my attitude was "agggh! this STUPID way of writing code, I HATE IT, I HATE IT!" but then I just stopped noticing. One of my Python friends had a similar experience of "Black".
I've also heard that 80% of the cost of software is maintenance, once again undercutting efficiencies in production.
The notion of not exceeding atmost Seven mutable objects or tasks per scope is important because more than three per scope likely contains a vulnerability and thus should be analyzed with care. Because someone less scrupulous always will.
Sounds reasonable as a general idea.
About RAM, 100% agree lol
This is really interesting, but 17 minutes in he's said "sort of" about 200 times and it's definitely putting me off watching any further.