Are you just repeating what's already been said before?
Where/when appropriate, are you correctly attributing others?
Does your comment add value?
Are you adding a new/different/unique perspective?
Have you read the other comments first?
Have you thought about who (possibly many people) will read the comment?
In the last few days MAUI App Accelerator passed ten thousand "official" unique installs.
This doesn't include the almost eight thousand installs included via the MAUI Essentials extension pack. (Installs via an extension pack are installed in a different way, which means they aren't included in the individual extension install count.)
While big numbers are nice (and apparently worth celebrating) I'm more interested in how it's used.
The numbers for that are lower, but still noteworthy.
It's currently used to create about 25 new apps each day. Which is nice.
I'm also trying to improve my ability to use App Insights so I can get other and better statistics too.
More updates are coming. Including the most potentially useful one...
I quite often use the phrase "I'm not smart enough to use this" when working with software tools.
This is actually a code for one or more of the following:
Do your users/customers ever say similar things?
Would they tell you?
Are you set up to hear them?
And ready to hear this?
Or will you tell me that I'm "holding it wrong"?
Should all the rules for formatting and structuring code used in automated tests always be the same as those used in the production code?
Of course, the answer is "it depends!"
I prefer my test methods to be as complete as possible. I don't want too many details hidden in "helper" methods, as this means the details of what's being tested get spread out.
As a broad generalization, I may have two helpers called from a test.
One to create the System Under Test.
And, one for any advanced assertions. These are usually to wrap multiple checks against complex objects or collections. I'll typically create these to provide more detailed (& specific) information if an assertion fails. (e.g. "These string arrays don't match" isn't very helpful. "The strings at index 12 are of different lengths" helps me identify where the difference is and what the problem may be much faster.)
A side-effect of this is that I may have lots of tests that call the same method. If the signature of that method needs to change, I *might* have to change it everywhere (all the tests) that call that method.
I could move some of these calls into other methods called by the tests and then only have to change the helpers, but I find this makes the tests harder to read on their own.
Instead, where possible, I create an overload of the changed method that uses the old signature, and which calls the new one.
If the old tests are still valid, we don't want to change them.
If the method signature has changed because of a new requirement, add new tests for the new requirements.
